On Wed, 2013-07-31 at 16:56 +0100, Mark Rutland wrote: > > Ah, I guess the question more: Do we want generic bindings that describe > > the low-level details of the HW in a completely generic fashion so that > > new HW can be supported with zero kernel changes, or do we want a simple > > driver with a lookup table that maps from compatible value to the HW > > configuration? One of the potential benefits of DT is to be able to > > support new HW without code changes, although perhaps that's more > > typically considered in the context of new boards rather than new IP > > blocks or SoCs. ... or FPGAs that can be synthesized with random collection of standard IP blocks. With Xilinx's Zynq and Altera's SOCFPGA this is getting simpler and simpler... > I think that going forward it would be better to have have a compatible > string per different device. As Olof pointed out, we're leaking the way > we currently handle things in Linux into the binding, rather than > precisely describing the hardware (with a unique compatible string). I'm > not sure if this is much better than embedding a bytecode describing how > to poke devices. > > Certainly there should be more-specific bindings for each device, so we > can later improve support for them. If we have that anyway, I think it > would be nicer to have the mapping from that compatible string to some > internal data passed to the simple-gpio driver, rather than explicitly > stating that the current version of the Linux simple-gpio driver is > capable of driving the device. This is one of the important decisions we may have to make going forward... Do we only accept bindings for "real" blocks of IP? (and how we define "real"?) If so, why does the "simple-bus"? Frankly speaking I don't know where to draw the line, but I feel that in this particular case - a "generic" GPIO binding - is worth the effort. SOCs are literally littered with control registers driving random bits. My favourite example - Versatile Express ;-) - have random registers representing things like LEDs or MMC status lines. Depending on the motherboard/FPGA version they can live in different places. And yes, I can have a Versatile Express "platform" driver registering different set of them depending on the particular variant of the FPGA bitfile. Or try to represent them in the tree... And yes, I've actually came with a patch almost identical to Alexander's one. No, I won't feel depressed if it doesn't get in :-) > I think the issue is that we're describing a hardware block in general, > rather than the instance of the hardware block, and that limits how > flexibly we can use the data in the description. So if I went and designed a parametrized, synthesizeble, memory-mapped GPIO "controller" matching the binding in question, would it change the situation? > > If we reject this driver, we surely have to get rid of pinctrl-single, > > and perhaps some others? > > That's certainly something we need to consider. However, those bindings > are in active use, and this is not yet. I don't think that we should > necessarily follow that style of binding. I think we should tell Mike Turquette about this, as his bindings for basic clock components definitely fall into the same category: http://thread.gmane.org/gmane.linux.kernel/1513049/ Pawel -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
