From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Date: Tue, 23 Jul 2013 08:40:42 -0700 Subject: [U-Boot] [Ac100] [PATCH 3/3] ARM: tegra: paz00: enable nveckeyboardsupport In-Reply-To: <3316781.OqtWDWHhXR@fb07-iapwap2.physik.uni-giessen.de> References: <1374223663-8576-1-git-send-email-danindrey@mail.ru> <3638195.7GdG5goTgS@ax5200p> <51EB5394.3090401@wwwdotorg.org> <3316781.OqtWDWHhXR@fb07-iapwap2.physik.uni-giessen.de> Message-ID: <51EEA3FA.2010804@wwwdotorg.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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?