misc: Add Tunnel creek In-Vehicle I2C loader driver
cover misc: Add Tunnel creek In-Vehicle I2C loader driver
To follow is a patch adding a driver which adds devices to the I2C bus on tunnel creek in-vehicle development boards.
I hope the driver can be upstreamed via the I2C mailing list, since I can't find any specific misc mailing list.
Thanks
--Richard
Quoted 2 lines · Richard Röjfors
To follow is a patch adding a driver which adds devices to the I2C bus on tunnel creek in-vehicle development boards.
I never got any feedback on my patch.
It doesn't seem like misc has it own mailinglist so I suppose this is where it should be posted(?)
The reason for the driver is the lack of board config in X86 so there is simply no way to define the devices on the I2C bus. It can not be done from the user space, since GPIO pins need to be turned into interrupts numbers and passed in the platform data to the I2C devices.
Any suggestions how to move forward to get such driver into the kernel?
Regards
Richard
A message that is not in the archive (sent off-list or not yet received): [email protected]
Hi Richard,
Quoted 9 lines · Richard Röjfors
Quoted 2 lines · Richard Röjfors
To follow is a patch adding a driver which adds devices to the I2C bus on tunnel creek in-vehicle development boards.
I never got any feedback on my patch.
It doesn't seem like misc has it own mailinglist so I suppose this is where it should be posted(?)
Quoted 6 lines
The reason for the driver is the lack of board config in X86 so there is simply no way to define the devices on the I2C bus. It can not be done from the user space, since GPIO pins need to be turned into interrupts numbers and passed in the platform data to the I2C devices.
Any suggestions how to move forward to get such driver into the kernel?
I don't like the idea of such "loader" drivers. If we need to have such a separate driver for every embedded x86 system, things will get pretty ugly quickly. I know we already have at least two somewhat similar drivers (i2c-amd756-s4882 and i2c-nforce2-s4985) but I really would like to get rid of them, not add more of the same type.
My impression is that x86 doesn't have board config because it wasn't so far an architecture used for embedded systems. But times are changing, and now x86 starts being used for embedded systems. Instead of coming up with a new way of handling I2C device instantiation ("loader" drivers), I think we simply want to add board config support to x86 as many other architectures already have.
As a matter of fact, I have been discussing this with Intel people recently:
http://marc.info/?t=128683908500001&r=1&w=2
It is pretty clear that Intel have added board config support to x86 already, even though that change may not be public yet. So I can only encourage you to discuss this with Jacob Pan, Feng Tang and Alan Cox.
If you need a temporary solution until then, I encourage you to simply add your code to the I2C bus driver your system is using. We already have examples of this in i2c-i801, i2c-ocores, i2c-powermac, i2c-taos-evm and i2c-xiic, so at least you wouldn't be doing something new.
Signature · 1 line
Jean Delvare
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 6 lines · Jean Delvare
As a matter of fact, I have been discussing this with Intel people recently:
http://marc.info/?t=128683908500001&r=1&w=2
It is pretty clear that Intel have added board config support to x86 already, even though that change may not be public yet. So I can only encourage you to discuss this with Jacob Pan, Feng Tang and Alan Cox.
That stuff is very specific to the Moorestown CPUs and a new BIOS type they have, the board_info part was posted on lkml about two weeks ago if you search through the archives.
A message that is not in the archive (sent off-list or not yet received): [email protected]
Hi Mark
Quoted 9 lines · Mark Brown
Quoted 6 lines · Jean Delvare
As a matter of fact, I have been discussing this with Intel people recently:
http://marc.info/?t=128683908500001&r=1&w=2
It is pretty clear that Intel have added board config support to x86 already, even though that change may not be public yet. So I can only encourage you to discuss this with Jacob Pan, Feng Tang and Alan Cox.
Quoted 3 lines
That stuff is very specific to the Moorestown CPUs and a new BIOS type they have, the
board_infopart was posted on lkml about two weeks ago if you search through the archives.
My point still holds, regardless of what exactly Intel has in the
works: if board config is now needed on some x86 systems, then support for it should be added in the same way other architectures did before. I can't see any reason why x86 would be different.
Signature · 1 line
Jean Delvare
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 4 lines · Jean Delvare
My point still holds, regardless of what exactly Intel has in the
works: if board config is now needed on some x86 systems, then support for it should be added in the same way other architectures did before. I can't see any reason why x86 would be different.
Oh, absolutely - I'm just saying that the existing Intel work isn't useful for this as it's tied to Moorestown and SFI.