Re: [PATCH 0/1] I2C: I2C controller driver for Intel Moorestown platform

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 23 Apr 2009 17:55:42 +0800, Wang, Wen W wrote:
> Hi Jean,
> 
> >-----Original Message-----
> >From: Jean Delvare [mailto:khali@xxxxxxxxxxxx]
> >Sent: 2009年4月23日 17:30
> >To: Wang, Wen W
> >Cc: linux-i2c@xxxxxxxxxxxxxxx
> >Subject: Re: [PATCH 0/1] I2C: I2C controller driver for Intel Moorestown platform
> >
> >Hi Wen,
> >
> >On Thu, 23 Apr 2009 17:00:56 +0800, Wang, Wen W wrote:
> >> Hi Jean,
> >>
> >> This is a description for the patch:
> >> 1. Patch for I2C controller driver for Intel low power platform "Moorestown".
> >> 2. The driver depends on a GPIO driver for Intel Moorestown platform.
> >> 3. The patch will:
> >> 	a. Add i2c_mrst.c and i2c_mrst.h to kernel directory "drivers/i2c/busses"
> >
> >Why such a cryptic name? You know, this isn't MS-DOS, names can be
> >longer than 8 characters ;)
> 
> :-) I can change the name to i2c_moorestown.c

Yes, please.

> >> 	b. Add items into kernel files "drivers/i2c/busses/Kconfig" and
> >"drivers/i2c/Makefile".
> >> 	c. Modify i2c-boardinfo.c to export i2c_register_board_info() function and add
> >code to detect if a device is already in i2c_board_list.
> >
> >This last item should go to a separate patch, so that it can be
> 
> I will separate the patch into two.

Thanks.

> >discussed. It is not clear to me why you would need to export functions
> >nobody else needed to export. It will be easier to review and merge
> >your code if the bus driver itself is in one patch and any required
> >integration changes are in another.
> 
> This is because:
> 1. The I2C driver need to call i2c_register_board_info() to register I2C device info table when loaded.
> 2. To support loadable module, I made such change to i2c_register_board_info().
> 
> I know it’s quite ugly there, but I really can't find a way to do so. Please feel free to teach me.

Which I2C devices are present on the bus, depends on the platform /
system. This really shouldn't go in the bus driver itself, but rather
somewhere in arch/. This is what all other platforms are doing. Just
grep the kernel source tree for "i2c_register_board_info" and you'll
see.

Now I would need to know more about the Moorestown platform.
Traditionally, PC platforms never registered I2C devices at the
platform level because it all depended on the vendor and specific
mainboard model and there were simply too many out there to list them
all. There are a few exceptions to this rule but generally we have been
relying on detection for most I2C devices (EEPROM and hardware
monitoring chips, mainly) on PC SMBus. This approach has its problems
(I2C doesn't have any official detection/identification mechanism) but
overall it works fine.

I would like to understand what makes you believe that the Moorestown
platform is so different from other Intel-based PC systems, that we
should list the I2C devices on all of them and add this knowledge to
the I2C bus driver (or somewhere else in the kernel).

Would Intel be willing to send me one of these Moorestown systems, so
that I can help more with the reviewing/testing of the i2c-moorestown
driver and the implementation of any infrastructure change possibly
required for this platform? This would speed up things a lot, I believe.

-- 
Jean Delvare
--
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

[Index of Archives]     [Linux GPIO]     [Linux SPI]     [Linux Hardward Monitoring]     [LM Sensors]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux