[i2c] mixed-speed I2C system

[Syed Mohammed, Khasim]

Hi Jean,

Few inputs & clarifications (required) below.

>-----Original Message-----
>From: Jean Delvare [mailto:khali at linux-fr.org]
>Sent: Thursday, April 05, 2007 2:43 PM
>
>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.
>

Actually we don't have a global I2C config structure to pass the clock /
config info as platform_data.

I was proposing the below one.

static int omap2_i2c2_clkrate = 400;

static struct platform_device omap_i2c_device2 = {
        .name           = "i2c_omap",
        .id             = 2,
        .num_resources  = ARRAY_SIZE(i2c_resources2),
        .resource       = i2c_resources2,
        .dev            = {
                .platform_data = &omap2_i2c2_clkrate,
        },
};

Can we add a config structure like the one for SPI shown below,

static struct omap2_mcspi_platform_config omap2_mcspi2_config = {
        .num_cs         = 2,
};

struct platform_device omap2_mcspi2 = {
        .name           = "omap2_mcspi",
        .id             = 2,
        .num_resources  = ARRAY_SIZE(omap2_mcspi2_resources),
        .resource       = omap2_mcspi2_resources,
        .dev            = {
                .platform_data = &omap2_mcspi2_config,
        },
};

Nishanth was proposing IORESOURCE_IO. But I feel it will change the
actual meaning. Using IORESOURCE_IO for clock parameter might be bit
confusing.

+		.end		= 3400,
+		.flags		= IORESOURCE_IO,
+	},
+	{

At this moment for my work on OMAP HSI2C, I don't expect more than this
from I2C subsystem. But I am ok to go with any generic approach that we
decide.

>> 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.
>
Yes, agreed. I have to redo some reading before commenting here :(

>--
>Jean Delvare

Please suggest the correct approach to be adopted.

Thanks & Regards,
Khasim