On Wed, Aug 07, 2013 at 05:12:12PM +0100, Stephen Warren wrote: > 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 ... I worry that it doesn't provide a full description, but rather a description of the subset of the hardware used by the driver. > > ... > >> 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. In that case, does the "nvidia,tegra20-gpio" require any extra reg fields for registers not used by the "simple-gpio" binding? If peopel are given a shortcut, I don't see why they'd bother to describe the hardware they're not using. What about the case where some mfd IP block can act as a gpio controller, compatbile with simple-gpio, and also provides some other functionality requiring a separate driver? I suspect people will describe this as two devices, mirroring the Linux driver model, rather than describing the hardware itself. As I see it, a "simple-gpio" compatible string says "I can be driven by the Linux simple-gpio driver", and the rest of the description is a reflection of the structure of the simple-gpio driver rather than the device. Thanks, Mark. -- 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
