[i2c] mixed-speed I2C system

[Jean Delvare]

Hi Kashim,

On Tue, 3 Apr 2007 19:59:44 -0500, Syed Mohammed, Khasim wrote:
> >Not really. For a given hardware setup, the max speed is a physical
> >attribute of the whole bus, basically defined as the minimum of the
> >maximum speed supported by each device. This holds whether or not a
> >device has been created in the device driver model. So attaching a
> >speed value to the devices will not cover all the possible cases. It
> >will fail as soon as there are additional devices connected on the bus
> >for which Linux doesn't have/need a driver, and in particular in the
> >multi-master case.
> >
> >So I don't think that there is any way to enable fast-mode I2C
> >automatically. Instead I believe we need to default to standard I2C (as
> >we do now) and let the user explicitly switch to fast-mode I2C if
> >he/she knows that his/her bus setup will support it. I was thinking of
> >a sysfs attribute. I don't know if we also need an in-kernel interface.
> 
> This is exactly true, to achieve the same, I was using board related
> files to take the decision of clock. The platform structure can pass the
> clock information for every I2C bus on a particular board/processor. In
> probe will check for the clock required for a particular bus and
> configure the required modules to generate the same.

Is there anything the i2c subsystem could do to help? Platform data
sounds like the right place to pass board-specific parameters, I'm not
sure if there is any benefit in doing it differently.

> But this is not dynamic in nature, and I am under the assumption that
> when hardware is designed all FS ones will be hooked on a one of the I2C
> buses, and all HS ones will be hooked on to other (atleast for OMAP due
> to multiple I2C interface support). 

Could be, but mixing fast-mode devices with HS-mode devices wouldn't be
a problem. The problem is when mixing standard-mode and fast-mode
devices on a given segment, because the former slow down the latter.

-- 
Jean Delvare