Re: [PATCH 0/3] i2c: i2c-imx-hdmi: add support of iMX6 HDMI DDC I2C bus

[Vladimir Zapolskiy <vladimir_zapolskiy-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>]

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