[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMuHMdXJ_FGXXwNx8h0ZfskJGRWES1xLuTQpD59Vw1Smp6FTRg@mail.gmail.com>
Date: Tue, 24 Jul 2018 17:46:09 +0200
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Arnd Bergmann <arnd@...db.de>
Cc: Boris Brezillon <boris.brezillon@...tlin.com>,
Peter Rosin <peda@...ntia.se>,
Wolfram Sang <wsa@...-dreams.de>,
Linux I2C <linux-i2c@...r.kernel.org>,
Jonathan Corbet <corbet@....net>,
"open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
Greg KH <gregkh@...uxfoundation.org>,
Przemyslaw Sroka <psroka@...ence.com>,
Arkadiusz Golec <agolec@...ence.com>,
Alan Douglas <adouglas@...ence.com>,
Bartosz Folta <bfolta@...ence.com>,
Damian Kos <dkos@...ence.com>,
Alicja Jurasik-Urbaniak <alicja@...ence.com>,
Cyprian Wronka <cwronka@...ence.com>,
Suresh Punnoose <sureshp@...ence.com>,
Rafal Ciepiela <rafalc@...ence.com>,
Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
Nishanth Menon <nm@...com>, Rob Herring <robh+dt@...nel.org>,
Pawel Moll <pawel.moll@....com>,
Mark Rutland <mark.rutland@....com>,
Ian Campbell <ijc+devicetree@...lion.org.uk>,
Kumar Gala <galak@...eaurora.org>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Vitor Soares <Vitor.Soares@...opsys.com>,
Linus Walleij <linus.walleij@...aro.org>,
Xiang Lin <Xiang.Lin@...aptics.com>,
"open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
Sekhar Nori <nsekhar@...com>, pgaj@...ence.com
Subject: Re: [PATCH v6 00/10] Add the I3C subsystem
Hi Arnd,
On Tue, Jul 24, 2018 at 5:40 PM Arnd Bergmann <arnd@...db.de> wrote:
> On Tue, Jul 24, 2018 at 5:15 PM, Geert Uytterhoeven
> <geert@...ux-m68k.org> wrote:
> > On Tue, Jul 24, 2018 at 5:05 PM Arnd Bergmann <arnd@...db.de> wrote:
>
> >> That's not the case I was describing here, I was thinking of what
> >> Wolfram described with the Renesas SoC that has two i2c masters
> >> multiplexed through the pinmux layer. I would assume that we
> >> can still do the same thing in i3c by shutting down the current
> >> master without a handover, and reprobing everything from scratch.
> >
> > The major disadvantage of reprobing is that it may cause visual disturbances
> > when i2c slaves are involved with e.g. the display pipeline (think HDMI encoders
> > etc.).
>
> Do you mean we should reuse the device pointer and association with
> the driver even when we switch out the i3c master using the pinmux?
>
> Or do you mean we need to be prepared for driving a single
> slave through multiple masters over the lifetime of that device,
> but using the i3c master handover protocol?
> In the second case, how do we decide which master to use
> for accessing a device for a given request?
I'll have to defer to Wolfram. He's the i2c and muxing expert.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Powered by blists - more mailing lists