UIO / of_genirq driver
in [Kernel]
|
Prev: PROBLEM: reproducible crash KVM+nf_conntrack all recent 2.6 kernels
Next: linux-next:als tree build failure
From: John Williams on 28 Jan 2010 02:20 Hi, I came across this thread/patchset from around June last year: http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-June/073086.html where Wolfgang proposed a generic OF-driven UIO driver. The discussion seemed to stall after Grant Likely indicated he didn't like the use of a linux-specific compatible binding in the device tree (compatible="generic-uio"). I guess I have a couple of questions: * did this patchset go anywhere? I've been using it here the last few days and it works great. and more generally: * Is there a better way to handle the OF bindings for this sort of thing? Grant's complaint seems to come up often - when you have generic controllers in a system (SPI/I2C also spring to mind), we need a way of signalling somehow to the kernel that each instance has a particular usage intended. However, the device-tree guys complain whenever anyone tries to encode anything non-hardware related into the DTS itself. I guess I'd like to just open up a discussion, see if there's been any progress towards a general solution. Thanks, John -- John Williams PetaLogix - Linux Solutions for a Reconfigurable World w: www.petalogix.com p: +61-7-30090663 f: +61-7-30090663 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Wolfram Sang on 28 Jan 2010 05:50
John, > I came across this thread/patchset from around June last year: > > http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-June/073086.html > > where Wolfgang proposed a generic OF-driven UIO driver. The Wolfram, please ;) > discussion seemed to stall after Grant Likely indicated he didn't like > the use of a linux-specific compatible binding in the device tree > (compatible="generic-uio"). I agree with him on that. > I guess I have a couple of questions: > > * did this patchset go anywhere? I've been using it here the last > few days and it works great. The idea was to create a mechanism to instantiate bindings at runtime, similar to new_id for PCI/PCMCIA, e.g.: $ echo "commodore,c64" > /sys/bus/of_platform/drivers/of_uio_genirq/new_compatible so we don't have to maintain an ever growing list of hardcoded compatible-properties for those UIO-devices. > * Is there a better way to handle the OF bindings for this sort of thing? Run-time instantiation might help in a couple of other cases; still, in the progress of unifying/extending the OF-support, it was discussed if it was possible to get rid of of_platform entirely. It looks like a very challenging task, but seems to be favoured designwise (at least I do). > However, the device-tree guys complain whenever anyone tries to encode > anything non-hardware related into the DTS itself. Well, if I get a device tree including special properties for Linux and BSD and whatever may follow, that could get quite confusing :) > I guess I'd like to just open up a discussion, see if there's been any > progress towards a general solution. I decided to wait for the outcome of the of_platform-removal-idea. Though, I have to admit that in the last weeks I haven't followed of-related things due to other commitments. Regards, Wolfram -- Pengutronix e.K. | Wolfram Sang | Industrial Linux Solutions | http://www.pengutronix.de/ | |