> >>>>>> 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.
> >>
> >> I don't see that as a problem.
> >>
> >> A particular DT file provides a description of an interface to HW. To my
> >> mind, if that particular DT doesn't describe everything about a
> >> particular HW module (e.g. some advanced feature can't be enabled),
> >> that's basically equivalent to not describing aspect of the board/system
> >> (so e.g. some I2C device isn't represented at all, and hence some
> >> temperature probe can't be monitored).
> >
> > My concern is simply that if people can get basic functionality with the
> > generic driver they won't bother describing the details of the more
> > specific binding, and you'll never be able to use the board with a
> > better driver without having to modify the dt later.
> >
> > I guess the question boils down to how much we care about that
> > situation.
>
> I personally think it's fine. If people only want to expose the basic
> functionality and can do so with simple-gpio, I don't see any problem at
> all with that. (Why should we care that a binding doesn't expose all
> features of the device? I'm sure there are many undocumented features,
> e.g. debug/backdoor, in HW that we don't even know exist and so don't
> know aren't exposed by various bindings)
>
> If someone later finds it useful to expose more functionality than is
> sensible to expose through simple-gpio, then a HW-specific binding can
> be added for that purpose, and the .dts file amended to use that.
>
> The more I think about this, the more I think that simply having
> disjoint simple and HW-specific bindings makes sense.
>
> In that case, the new DT won't be compatible with an old kernel, but I
> think that's reasonable, since it was explicitly changed to implement
> new features.
>
> I think we should resolve this aspect first before considering the
> details. I'm curious what other DT maintainers and users think about
> this topic?
I want to add from myself that the ability to use a simple-gpio interface
makes things very simple :) As an example, I cite one of the architectures
on which I work. ARM CLPS711X. I can freely use a simple-gpio driver instead
of the special driver, since the architecture does not have any other capacity
for the pins (interrupts, etc.).
But mostly, I intended to use this driver for such things like PLD, 74HC24x,
74HC57x, etc. on the bus.
---
��.n��������+%������w��{.n����z�{��ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
