On 07/20/2013 03:12 AM, Marc Dietrich wrote:
> On Friday 19 July 2013 13:14:13 Stephen Warren wrote:
...
> Let's skip how this may actually look like in software. Given the discussions 
> we had in the past, I propose the following binding:
> 
> i2c-slave@7000c500 {
>       compatible = "nvidia,tegra20-i2c-slave";
>       reg = <0x7000c500 0x100>;
>       interrupts = <0 92 0x04>;
>       #address-cells = <1>;
>       #size-cells = <0>;
>       clock-frequency = <80000>;
>       slave-addr = <138>;

Hex would be more common, but that's a minor issue.

>       clocks = <&tegra_car 67>, <&tegra_car 124>;
>       clock-names = "div-clk", "fast-clk";
> 
>       nvec {

Above, it says #address-cells=<1>, which means this node needs a reg
property. Perhaps slave-addr should be part of the child nodes (and the
Tegra I2C controller binding would limit itself to supporting only a
single node), so that the same binding style could be applicable to I2C
slave devices that support multiple slave addresses.

>               compatible = "nvidia,nvec", "simple-bus";
>               protocol = "smbus-request-gpio";

What is that property for; doesn't compatible="nvidia,nvec" already
imply this, or does the NVEC spec define multiple different protocols?

>               request-gpios = <&gpio 170 0>; /* gpio PV2 */

We should use the C pre-processor to provide named constants there,
although I guess U-Boot isn't set up for that yet. The kernel is once
this is ported there, and once the 2013.07 release is out, U-Boot should
be able to support this very soon too.

>               keyboard {

Simple-bus might require a reg property; I forget. Does the NVEC
protocol include any form of "virtual device address" that it would make
sense to put into a reg property?

>                       compatible = "nvidia,nvec-keyboard";
>               };
>       };
> };
> 
> Does this looks better?

Yes, overall much better.

New DT bindings should be sent to devicet...@vger.kernel.org for review.
Note that's a branch new list (it moved from a different server), so it
might be best to wait a few days for people to subscribe before sending
mail to it.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Reply via email to