On 08/07/2013 08:07 AM, Mark Rutland wrote: > On Tue, Aug 06, 2013 at 12:00:50PM +0100, Pawel Moll wrote: >> 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. This really isn't leaking information about how Linux handles the device. It's simply saying that there is a GPIO controller whose HW is able to be described by a simple/generic binding, and that binding provides full details of the register layout. Other OSs can handle this differently; see below ... ... >> 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... > > I worry that going down that route encourages bindings to describe a > single way to use a given device, rather than describing the device > itself and allowing the OS to decide how to use it. This limits what we > can do in future, and I worry about how we can handle quirks sanely if > we describe devices in this way. Well, each DT node that uses this binding must still have a compatible property that fully defines the exact instance of the HW. In other words, assuming this binding worked fine for Tegra, the DT must contain: compatible = "nvidia,tegra20-gpio", "simple-gpio"; and not just: compatible = "simple-gpio"; In that case, an OS could choose to match on "nvidia,tegra20-gpio" and ignore most of the other properties to instantiate a more "custom" driver, or to enable HW-specific quirks. -- 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
