From: "Vaittinen, Matti" <Matti.Vaittinen@fi.rohmeurope.com>
To: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>,
Luca Ceresoli <luca@lucaceresoli.net>,
"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
"linux-i2c@vger.kernel.org" <linux-i2c@vger.kernel.org>
Cc: "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Wolfram Sang <wsa@the-dreams.de>,
Sakari Ailus <sakari.ailus@linux.intel.com>,
Hans Verkuil <hverkuil-cisco@xs4all.nl>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Kieran Bingham <kieran.bingham@ideasonboard.com>,
Jacopo Mondi <jacopo@jmondi.org>,
Vladimir Zapolskiy <vz@mleia.com>, Peter Rosin <peda@axentia.se>,
Mauro Carvalho Chehab <mchehab@kernel.org>
Subject: Re: [RFCv3 0/6] TI camera serdes and I2C address translation (Was: [RFCv3 0/6] Hi,)
Date: Mon, 7 Feb 2022 13:21:02 +0000 [thread overview]
Message-ID: <5aa3e282-3056-2088-9741-6d17273701b4@fi.rohmeurope.com> (raw)
In-Reply-To: <7e5af144-bd5f-cd0e-2109-49b318449a78@ideasonboard.com>
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.
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 ~~
next prev parent reply other threads:[~2022-02-07 13:52 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-06 11:59 [RFCv3 0/6] Hi, Luca Ceresoli
2022-02-06 11:59 ` [RFCv3 1/6] i2c: core: let adapters be notified of client attach/detach Luca Ceresoli
2022-02-06 11:59 ` [RFCv3 2/6] i2c: add I2C Address Translator (ATR) support Luca Ceresoli
2022-02-08 11:16 ` Andy Shevchenko
2022-02-16 8:40 ` Luca Ceresoli
2022-02-17 5:12 ` Vaittinen, Matti
2022-03-16 14:11 ` Vaittinen, Matti
2022-03-16 14:25 ` Luca Ceresoli
2022-02-06 11:59 ` [RFCv3 3/6] media: dt-bindings: add DS90UB953-Q1 video serializer Luca Ceresoli
2022-02-07 21:48 ` Rob Herring
2022-02-06 11:59 ` [RFCv3 4/6] media: dt-bindings: add DS90UB954-Q1 video deserializer Luca Ceresoli
2022-02-06 18:46 ` Rob Herring
2022-02-07 19:39 ` Rob Herring
2022-02-06 11:59 ` [RFCv3 5/6] media: ds90ub954: new driver for TI " Luca Ceresoli
2022-02-06 11:59 ` [RFCv3 6/6] media: ds90ub953: new driver for TI DS90UB953-Q1 video serializer Luca Ceresoli
2022-02-06 12:05 ` [RFCv3 0/6] TI camera serdes and I2C address translation Luca Ceresoli
2022-02-07 12:06 ` [RFCv3 0/6] TI camera serdes and I2C address translation (Was: [RFCv3 0/6] Hi,) Tomi Valkeinen
2022-02-07 13:21 ` Vaittinen, Matti [this message]
2022-02-07 14:07 ` Luca Ceresoli
2022-02-07 14:38 ` Vaittinen, Matti
2022-02-07 16:23 ` Tomi Valkeinen
2022-02-08 6:40 ` Vaittinen, Matti
2022-02-08 8:28 ` Tomi Valkeinen
2022-02-08 9:36 ` Vaittinen, Matti
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=5aa3e282-3056-2088-9741-6d17273701b4@fi.rohmeurope.com \
--to=matti.vaittinen@fi.rohmeurope.com \
--cc=devicetree@vger.kernel.org \
--cc=hverkuil-cisco@xs4all.nl \
--cc=jacopo@jmondi.org \
--cc=kieran.bingham@ideasonboard.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=luca@lucaceresoli.net \
--cc=mark.rutland@arm.com \
--cc=mchehab@kernel.org \
--cc=peda@axentia.se \
--cc=robh+dt@kernel.org \
--cc=sakari.ailus@linux.intel.com \
--cc=tomi.valkeinen@ideasonboard.com \
--cc=vz@mleia.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).