Message-ID: <74bacec6-35e5-346a-fb05-09ae44fc5592@lucaceresoli.net>
Date:   Mon, 7 Feb 2022 15:07:57 +0100
From:   Luca Ceresoli <luca@...aceresoli.net>
To:     "Vaittinen, Matti" <Matti.Vaittinen@...rohmeurope.com>,
        Tomi Valkeinen <tomi.valkeinen@...asonboard.com>,
        "linux-media@...r.kernel.org" <linux-media@...r.kernel.org>,
        "linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>
Cc:     "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Wolfram Sang <wsa@...-dreams.de>,
        Sakari Ailus <sakari.ailus@...ux.intel.com>,
        Hans Verkuil <hverkuil-cisco@...all.nl>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        Kieran Bingham <kieran.bingham@...asonboard.com>,
        Jacopo Mondi <jacopo@...ndi.org>,
        Vladimir Zapolskiy <vz@...ia.com>,
        Peter Rosin <peda@...ntia.se>,
        Mauro Carvalho Chehab <mchehab@...nel.org>
Subject: Re: [RFCv3 0/6] TI camera serdes and I2C address translation (Was:
 [RFCv3 0/6] Hi,)

Hi Matti,

On 07/02/22 14:21, Vaittinen, Matti wrote:
> Hi dee Ho peeps,
> 
> On 2/7/22 14:06, Tomi Valkeinen wrote:
>> Hi Luca,
>>
>> On 06/02/2022 13:59, Luca Ceresoli wrote:
>>> this RFCv3, codename "FOSDEM Fries", of RFC patches to support the TI
>>> DS90UB9xx serializer/deserializer chipsets with I2C address translation.
> 
> ..snip
> 
>>> Even with the above limitations I felt I'd send this v3 anyway since
>>> several people have contacted me since v2 asking whether this
>>> implementation has made progress towards mainline. Some even improved on
>>> top of my code it their own forks. As I cannot afford to work on this 
>>> topic
>>> in the near future, here is the latest and greatest version I can 
>>> produce,
>>> with all the improvements I made so far.
>>
>> I've discussed with Luca in private emails, but I'll add a short status 
>> about my work in this thread:
> 
> Thanks for CC:ing me Luca. We had a small chat during the FOSDEM.
> 
>> About a year ago I took Luca's then-latest-patches and started working 
>> on them. The aim was to get full multiplexed streams support to v4l2 so 
>> that we could support CSI-2 bus with multiple virtual channels and 
>> embedded data, and after that, add support for fpdlink devices.
>>
>> Since then I have sent multiple versions of the v4l2 work (no drivers 
>> yet, only the framework changes) to upstream lists. Some pieces have 
>> already been merged to upstream (e.g. subdev state), but most of it is 
>> still under work. Here's a link to v10 of the streams series:
>>
>> https://lore.kernel.org/all/20211130141536.891878-1-tomi.valkeinen@ideasonboard.com/ 
>>
>>
>> It has a link to my (now slightly outdated) git branch which contains 
>> the driver work too.
> 
> I have fetched this tree from Tomi and done some experimenting on 
> another SERDES. That SERDES in not from TI or Maxim, some of you may 
> guess the company though :) Unfortunately I can't publish the details or 
> the code for now - I am discussing what I am allowed to publish. My 
> personal goal is to see if I could write a Linux driver for this 
> yet-another-Video-SERDES and see if it can one day get merged to 
> upstream for anyone interested to play with.
> 
>> The fpdlink drivers have diverged from Luca's version quite a bit. The 
>> most obvious difference is the support for multiplexed streams, of 
>> course, but there are lots of other changes too. The drivers support 
>> DS90UB960 (no UB954 at the moment), DS90UB953 and DS90UB913. UB960 
>> supports all the inputs and outputs.
> 
> For the record, the SERDES I am working with does also support 
> connecting 4 cameras (4 SERs) to one DES which provides two CSI-2 
> outputs. As far as I understand the virtual channel support is also 
> there (in the HW).
> 
>   I have also dropped some code which
>> I did not need and which I wasn't sure if it's correctly implemented, to 
>> make it easier to work on the multiplexed streams version. Some of that 
>> code may need to be added back.
>>
>> I have not changed the i2c-atr driver, and my fpdlink driver uses  it 
>> more or less the same way as in Luca's version.
>>
> 
> I have also used the ATR driver as is. The SERDES I am working with does 
> also the I2C address translation.
> 
>> Considering that you're not able to work on this, my suggestion is to 
>> review the i2c-atr patches here (or perhaps send those patches in a 
>> separate series?),
> 
> It would be _really_ cool to get the ATR upstream.
> 
>   but afaics the fpdlink drivers without multiplexed
>> streams is a dead-end, as they can only support a single camera (and no 
>> embedded data), so I don't see much point in properly reviewing them.
>>
>> However, I will go through the fpdlink drivers in this series and 
>> cherry-pick the changes that make sense. I was about to start working on 
>> proper fpdlink-clock-rate and clkout support, but I see you've already 
>> done that work =).
> 
> I am not sure if I am poking in the nest of the wasps - but there's one 
> major difference with the work I've done and with Toni's / Luca's work.

You are. ;)

> The TI DES drivers (like ub960 driver) packs pretty much everything 
> under single driver at media/i2c - which (in my opinion) makes the 
> driver pretty large one.
> 
> My approach is/was to utilize MFD - and prepare the regmap + IRQs in the 
> MFD (as is pretty usual) - and parse that much of the device-tree that 
> we see how many SER devices are there - and that I get the non I2C 
> related DES<=>SER link parameters set. After that I do kick alive the 
> separate MFD cells for ATR, pinctrl/GPIO and media.
> 
> The ATR driver instantiates the SER I2C devices like Toni's ub960 does. 
> The SER compatible is once again matched in MFD (for SER) - which again 
> provides regmap for SER, does initial I2C writes so SER starts 
> responding to I2C reads and then kicks cells for media and pinctrl/gpio.
> 
> I believe splitting the functionality to MFD subdevices makes drivers 
> slightly clearer. You'll get GPIOs/pinctrl under pinctrl as usual, 
> regmaps/IRQ-chips under MFD and only media/v4l2 related parts under media.

There has been quite a fiery discussion about this in the past, you can
grab some popcorn and read
https://lore.kernel.org/linux-media/20181008211205.2900-1-vz@mleia.com/T/#m9b01af81665ac956af3c6d57810239420c3f8cee

TL;DR: there have been strong opposition the the MFD idea.

I personally don't have a super strong opinion: I wrote this as a
monolithic driver because it looked like the most natural implementation
and found it was working fine for me, I never really explored the MFD idea.

> Anyways - I opened the mail client to just say that the ATR has worked 
> nicely for me and seems pretty stable - so to me it sounds like a goof 
> idea to get ATR reviewed/merged even before the drivers have been finalized.

Sounds like a... what...? A "good idea"? Or a "goofy idea"? :-D

-- 
Luca

Powered by blists - more mailing lists