Re: [RFCv3 0/6] TI camera serdes and I2C address translation (Was: [RFCv3 0/6] Hi,)

[Vaittinen, Matti]

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@xxxxxxxxxxxxxxxx/ 
> 
> 
> 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.

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.

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.

Thanks for showing the way for the rest of us Luca & others! It's much 
easier to follow than lead the way ;)

Best Regards
	--Matti

-- 
The Linux Kernel guy at ROHM Semiconductors

Matti Vaittinen, Linux device drivers
ROHM Semiconductors, Finland SWDC
Kiviharjunlenkki 1E
90220 OULU
FINLAND

~~ this year is the year of a signature writers block ~~