From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vladimir Zapolskiy Subject: Re: [PATCH 0/3] i2c: i2c-imx-hdmi: add support of iMX6 HDMI DDC I2C bus Date: Mon, 24 Nov 2014 21:15:19 +0200 Message-ID: <547383C7.8000705@mentor.com> References: <1416073759-19939-1-git-send-email-vladimir_zapolskiy@mentor.com> <20141124122052.GI3733@katana> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20141124122052.GI3733@katana> Sender: linux-i2c-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Wolfram Sang Cc: Philipp Zabel , linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: linux-i2c@vger.kernel.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