Hi Wolfram, On 24.11.2014 14:20, Wolfram Sang wrote: > On Sat, Nov 15, 2014 at 07:49:16PM +0200, Vladimir Zapolskiy wrote: >> Please review a proposed iMX6 HDMI DDC controller driver written on >> top of I2C framework. >> >> Changes from RFC to v1 version: >> * added I2C bus ducumentation, >> * updated iMX6 HDMI device tree bindings documentation, >> * device resource information is collected from parent HDMI phandle, >> * minor clean-ups. >> >> The driver intends to support HDMI on-controller I2C master bus with >> limited cababilities, however by nature of the sub-device it seems >> reasonable to separate it into a stand-alone driver, which also can be >> used independently on general HDMI controller driver, for example as >> an additional I2C bus on a board, but please be aware that the bus is >> not compliant to I2C specification. >> >> In my practice I've met iMX6Q boards, where HDMI DDC lines are >> connected to iMX6 HDMI DDC pins and not to any of 3 I2C busses, so >> support of iMX6 HDMI I2C bus is important to have. >> >> Main issues with the device/driver: >> * iMX6 HDMI controller becomes a shared device (both interrupt and >> memory region) between HDMI driver itself and this I2C bus driver. >> * Only two patterns of I2C transactions are supported due to hardware >> limitation, these patters are described in driver's code header. >> * The bus controller supports one more multi-byte read pattern (so >> called Extended Read Mode), but Freescale documentation is too vague >> to easily add this mode into the driver. >> >> The bus driver may be used independently on presence/absence of iMX6 >> HDMI controller driver, so build dependeny is not set. thank you for review. > I think there are now 3 drivers in my queue which are not fully I2C > compatible but more supporting the very minimum to, say, read an eeprom. > I am not feeling well to allow them to use I2C_FUNC_I2C. So, I want to > think about ways how to communicate deficiencies like "only 255 byte" or > "only WRRD messages" to users of that I2C controller. This is most > likely not happening before 3.19. But assistance is very welcome. > Yeah, it sounds absolutely correct *not* to allow such drivers (and this one in particular) to provide naked I2C_FUNC_I2C. Is there any chance to extend I2C_FUNC_* list? It still has some free bits, not so many though. Probably it might be possible to create another list of quirks or exceptions (in opposite to functionality) and export quirks of a particular I2C bus to userspace over some userspace to kernel channel (e.g. adding one more ioctl). -- With best wishes, Vladimir -- 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
