From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Wolfram Sang <wsa@the-dreams.de>
Cc: Akinobu Mita <akinobu.mita@gmail.com>,
linux-media@vger.kernel.org,
"open list:OPEN FIRMWARE AND..." <devicetree@vger.kernel.org>,
Jacopo Mondi <jacopo+renesas@jmondi.org>,
Hans Verkuil <hans.verkuil@cisco.com>,
Sakari Ailus <sakari.ailus@linux.intel.com>,
Mauro Carvalho Chehab <mchehab@s-opensource.com>
Subject: Re: [PATCH v3 02/11] media: ov772x: allow i2c controllers without I2C_FUNC_PROTOCOL_MANGLING
Date: Mon, 23 Apr 2018 23:21:30 +0300 [thread overview]
Message-ID: <6809346.dy34v3ukH6@avalon> (raw)
In-Reply-To: <20180423201121.cgcg6isobtku7swy@ninjato>
Hi Wolfram,
On Monday, 23 April 2018 23:11:21 EEST Wolfram Sang wrote:
> > How about i2c_smbus_xfer_emulated() ? The tricky part will be to handle
> > the I2C adapters that implement .smbus_xfer(), as those won't go through
> > i2c_smbus_xfer_emulated(). i2c_smbus_xfer_emulated() relies on
> > i2c_transfer(), which itself relies on the I2C adapter's .master_xfer()
> > operation. We're thus only concerned about the drivers that implement
> > both .smbus_xfer() and master_xfer(), and there's only 4 of them
> > (i2c-opal, i2c-pasemi, i2c-powermac and i2c-zx2967). Maybe the simplest
> > solution would be to force the emulation path if I2C_CLIENT_SCCB &&
> > !I2C_FUNC_PROTOCOL_MANGLING && ->master_xfer != NULL ?
> >
> > Wolfram, what do you think ?
>
> I think it is a mess :)
>
> Further: I don't think we will ever see an SMBus controller which allows
> mangling. SMBus is way more precisely defined than I2C, so HW can then
> do much more things automatically. They will always do a REP_START, so I
> don't think you can connect SCCB devices to SMBus.
>
> As a result, we shouldn't do SMBus calls for SCCB. Maybe we should
> introduce sccb_byte_read? SCCB didn't specify much more than byte read
> IIRC, or? The implementation here with two seperate messages makes much
> sense to me then.
>
> I could argue that the sccb_* helpers should live in drivers/media since
> it is probably only Omnivision trying to work around I2C licensing here?
>
> But if it is not too heavy, maybe we could take it into i2c as well.
>
> Makes sense or did I miss something?
SCCB helpers would work too. It would be easy to just move the functions
defined in this patch to helpers and be done with it. However, there are I2C
adapters that have native SCCB support, so to take advantage of that feature
we need to forward native SCCB calls all the way down the stack in that case.
That's why I thought an implementation in the I2C subsystem would be better.
Furthermore, as SCCB is really a slightly mangled version of I2C, I think the
I2C subsystem would be a natural location for the implementation. It shouldn't
be too much work, it's just a matter of deciding what the call stacks should
be for the native vs. emulated cases.
--
Regards,
Laurent Pinchart
next prev parent reply other threads:[~2018-04-23 20:21 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-22 15:56 [PATCH v3 00/11] media: ov772x: support media controller, device tree probing, etc Akinobu Mita
2018-04-22 15:56 ` [PATCH v3 01/11] media: dt-bindings: ov772x: add device tree binding Akinobu Mita
2018-04-23 9:17 ` Laurent Pinchart
2018-04-23 15:54 ` Akinobu Mita
2018-04-25 16:19 ` Akinobu Mita
2018-04-25 22:40 ` Laurent Pinchart
2018-04-26 16:17 ` Akinobu Mita
2018-04-26 18:11 ` jacopo mondi
2018-04-26 21:34 ` Laurent Pinchart
2018-04-27 17:15 ` Akinobu Mita
2018-04-22 15:56 ` [PATCH v3 02/11] media: ov772x: allow i2c controllers without I2C_FUNC_PROTOCOL_MANGLING Akinobu Mita
2018-04-23 9:18 ` Laurent Pinchart
2018-04-23 15:55 ` Akinobu Mita
2018-04-23 19:41 ` Laurent Pinchart
2018-04-23 20:11 ` Wolfram Sang
2018-04-23 20:21 ` Laurent Pinchart [this message]
2018-04-23 20:36 ` Wolfram Sang
2018-04-23 20:51 ` Laurent Pinchart
2018-04-24 10:04 ` Sakari Ailus
2018-04-26 12:32 ` Wolfram Sang
2018-04-22 15:56 ` [PATCH v3 03/11] media: ov772x: add checks for register read errors Akinobu Mita
2018-04-22 15:56 ` [PATCH v3 04/11] media: ov772x: add media controller support Akinobu Mita
2018-04-22 15:56 ` [PATCH v3 05/11] media: ov772x: use generic names for reset and powerdown gpios Akinobu Mita
2018-04-22 15:56 ` [PATCH v3 06/11] media: ov772x: support device tree probing Akinobu Mita
2018-04-22 15:56 ` [PATCH v3 07/11] media: ov772x: handle nested s_power() calls Akinobu Mita
2018-04-23 8:35 ` jacopo mondi
2018-04-27 17:20 ` Akinobu Mita
2018-04-22 15:56 ` [PATCH v3 08/11] media: ov772x: reconstruct s_frame_interval() Akinobu Mita
2018-04-22 15:56 ` [PATCH v3 09/11] media: ov772x: avoid accessing registers under power saving mode Akinobu Mita
2018-04-22 15:56 ` [PATCH v3 10/11] media: ov772x: make set_fmt() return -EBUSY while streaming Akinobu Mita
2018-04-22 15:56 ` [PATCH v3 11/11] media: ov772x: create subdevice device node Akinobu Mita
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6809346.dy34v3ukH6@avalon \
--to=laurent.pinchart@ideasonboard.com \
--cc=akinobu.mita@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=hans.verkuil@cisco.com \
--cc=jacopo+renesas@jmondi.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@s-opensource.com \
--cc=sakari.ailus@linux.intel.com \
--cc=wsa@the-dreams.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).