Hi Jean, Sorry for my slow response. Just been off last week. Intel Moorestown platform is designed for MID which is quite different from traditional PC. So I2C devices are present on the bus depended on the platform/system. I will discuss with our team to see if we can move this part to arch/. Then will get back to you. For the device, due to the platform has not released, so I have to ask legal first. Thanks Wen >-----Original Message----- >From: Jean Delvare [mailto:khali@xxxxxxxxxxxx] >Sent: 2009年4月23日 19:22 >To: Wang, Wen W >Cc: linux-i2c@xxxxxxxxxxxxxxx >Subject: Re: [PATCH 0/1] I2C: I2C controller driver for Intel Moorestown platform > >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 ?韬{.n?????%??檩??w?{.n???{炳-?)?骅w* jg????????G??⒏ ⒎?:+v???????? ????＂??????
