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:

quoted

quoted

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...

quoted

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"?

Agreed. I suspect this is going to be a bit messy.

I'd argue that "simple-bus" is at least special in that compatibility
implies nothing: It's more an annotation that the configuration logic
for some bus is ignorable, and can be used without being poked in any
way whatsoever. It's also useful for sharing blocks of components that
might be mapped in different areas in different dts using ranges, but
that's probably another point of contention ;)

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.

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 :-)

quoted

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?

It would certainly muddy the waters a bit.

quoted

quoted

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/

Definitely.

It would be useful for the other maintainers to share their opinions
here. This is a rather important policy decision.

Thanks,
Mark.