Re: [PATCH v7 0/7] i2c-atr and FPDLink

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 20/01/2023 18:17, Luca Ceresoli wrote:
Hi Andy,

On Fri, 20 Jan 2023 18:00:02 +0200
Andy Shevchenko <andriy.shevchenko@xxxxxxxxx> wrote:

On Thu, Jan 19, 2023 at 09:43:58AM +0100, Luca Ceresoli wrote:
On Wed, 18 Jan 2023 19:43:23 +0200
Andy Shevchenko <andriy.shevchenko@xxxxxxxxx> wrote:
On Wed, Jan 18, 2023 at 07:28:20PM +0200, Tomi Valkeinen wrote:
On 18/01/2023 18:01, Andy Shevchenko wrote:
On Wed, Jan 18, 2023 at 02:40:24PM +0200, Tomi Valkeinen wrote:

...

Can you clarify what you mean here?

The i2c_clients are not aware of the i2c-atr. They are normal i2c clients.
The FPD-Link drivers are aware of the ATR, as the FPD-Link hardware contains
the ATR support.

Can't that hardware be represented as I2C adapter? In such case the ATR specifics
can be hidden from the client (drivers).

I'm worrying about code duplication and other things that leak into drivers as
ATR callbacks.

Which callbacks do you refer to? i2c_atr_ops? I don't think we can do
without the attach/detach_client ones, it's where the driver-specific
implementation is hooked for the generic ATR infra to call it.

However now I noticed the select/deselect ops are still there. IIRC
they are not used by any driver and in the past the plan was to just
remove them. Tomi, do you think there is a good reason to keep them?
It might be that I didn't get how hw exactly functioning on this
level and why we need those callbacks.

As far as "how hw exactly works", in case you haven't seen that, the
best explanation I was able to give is in my ELCE 2019 talk, at minute
~22. It's a 2-3 minute watch. The slides have pointers to other talks
and discussion.

Probably I have missed the URL in the discussion, care to resend?

I hadn't sent any URL :)

Here's the shortcut to go straight to the ATR description:
https://youtu.be/7hLv6fYAW-E?t=1350

Slides:
https://elinux.org/images/f/fc/Ceresoli-elce2019-video-serdes-linux.pdf

A small note: the current implementation doesn't match the slides, as the adapter is now (at least kind of) in the serializer (the "ideal solution" in the slides.

 Tomi




[Index of Archives]     [Linux GPIO]     [Linux SPI]     [Linux Hardward Monitoring]     [LM Sensors]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux