On Tue, Oct 25, 2011 at 7:06 AM, Stephen Warren <swarren@xxxxxxxxxx> wrote: > Marc Dietrich wrote at Saturday, October 22, 2011 2:17 PM: >> This adds support for the embedded controller known as NVEC. The driver >> lives currently in the staging tree and we aim to promote it one level >> higher in the near future. >> >> The NVEC driver uses the I2C resources of the master controller for now >> until slave support is added to the i2c-tegra driver. > > I'm in two minds about this: > > The fact that the nvec driver accesses the I2C HW directly is a hack; that > should all happen in the I2C driver, and the nvec code should /just/ handle > the protocol to talk to the microcontroller. > > To that end, we're starting to bring on some more engineers internally who > will aim to upstream more of our downstream kernel. Part of this includes > upstreaming the I2C slave support in a more palatable fashion. I know those > engineers are keen in general to get started, but I can't yet estimate a > timescale for when this particular change will be ready. > > That said, I'm not sure that I want to block progress on getting nvec > and the AC100 support going. Olof, do you have any input here? Thanks. Yeah, let's not hold up ac100 based on not-yet-ready code, especially since the driver is in staging. If the i2c slave driver could be done in time to be there before nvec graduates from staging, that would probably be ideal. That being said, let's do it reasonably clean -- Marc, if you guys are up for trying to define device-tree bindings for this that would be awesome, and move to that for driver probing. That avoids adding an include/linux/platform_data header file. -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
