[U-Boot] [Ac100] [PATCH 3/3] ARM: tegra: paz00: enable nveckeyboardsupport

[Stephen Warren]

On 07/22/2013 01:09 AM, Marc Dietrich wrote:
> Am Samstag, 20. Juli 2013, 21:20:52 schrieb Stephen Warren:
>> 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 at 7000c500 {

>>> 	#address-cells = <1>;
>>> 	#size-cells = <0>;

>>> 	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.
> 
> you mean 
> 
> nvec at 87 {
> 		reg = <0x87>;
> 		...
> } ?

Yes.

> I think that's ok. Didn't know that Tegra can support multiple slave 
> addresses. To make the binding as general as possible, we could support multi-
> slave for the binding, but only support single slave in the code for now.

Tegra can't, but that doesn't mean some future Tegra or some other SoC
can't/won't. Putting the slave address inside the child node makes sure
the same DT schema will work in other situations, and hence be consistent.

> I guess that also warrants a "simple-bus" compatibility in the i2c-slave node.
> 
>>
>>> 		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?
> 
> The GPIO is optional, but SMBUS is required. Maybe to support master initiated 
> communications only. To get rid of the ugly protocol property, we could just 
> check if a valid gpio is given. I think that's what the downstream kernel also 
> does.

Yes, I believe nvidia,nvec implies everything about the protocol then,
except for the optional GPIO which can be checked directly.

> The nvec still needs to tell the slave driver which protocol to use, but
> that can be hard coded.

I'm not sure what that means. At the controller/HW level, aren't I2C and
SMBUS the same; it's just the data within the transactions that may be
more defined by one or the other?