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