On Wed, 2016-06-15 at 16:42 +0300, Jarkko Nikula wrote:
> On 06/15/2016 01:55 AM, Andy Shevchenko wrote:
> > On some platforms, such as Intel Medfield, the I2C slave devices are
> > enumerated
> > through SFI tables where bus numbering is expected to be defined in
> > the OS.
> > Make the bus number allocation robust for such platforms.
> > ...
> > - [medfield_3] = {
> > - .bus_num = 3,
> > - .bus_cfg = INTEL_MID_STD_CFG |
> > DW_IC_CON_SPEED_STD,
> > + [medfield] = {
> > + .bus_num = -1,
> > .bus_cfg = INTEL_MID_STD_CFG |
> > DW_IC_CON_SPEED_FAST,
> Now bus 3 speed is pumped up to fast speed. Can it cause problems?
Oh, I have no idea, so, I would leave it at lower speed.
While we are here, what are your recommendations to put ->setup() call
in the ->probe()? Currently it is located somewhere in the middle of
assignments. I think the workflow has to be the following:
1. Take static controller data from platform based on ID's
2. Call controller->setup() if defined
3. Re-assign i2c device parameters with data in controller
--
Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx>
Intel Finland Oy
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
