[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180724185415.6126751e@bbrezillon>
Date: Tue, 24 Jul 2018 18:54:15 +0200
From: Boris Brezillon <boris.brezillon@...tlin.com>
To: Arnd Bergmann <arnd@...db.de>
Cc: Geert Uytterhoeven <geert@...ux-m68k.org>,
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>, Przemyslaw Gaj <pgaj@...ence.com>
Subject: Re: [PATCH v6 00/10] Add the I3C subsystem
On Tue, 24 Jul 2018 18:25:22 +0200
Arnd Bergmann <arnd@...db.de> wrote:
> On Tue, Jul 24, 2018 at 6:14 PM, Boris Brezillon
> <boris.brezillon@...tlin.com> wrote:
> > On Tue, 24 Jul 2018 17:58:29 +0200
> > Arnd Bergmann <arnd@...db.de> wrote:
> >
> >> On Tue, Jul 24, 2018 at 5:46 PM, Geert Uytterhoeven
> >> <geert@...ux-m68k.org> wrote:
> >> > 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:
> >> The second case is the one that started the discussion, and
> >> this is where I said I'd prefer to associate each slave with at
> >> most one master at boot time, while the current v6 patch
> >> is prepared for having one slave be accessed alternatingly
> >> by multiple masters using the master handover, though so
> >> far nobody has been able to describe exactly how we'd pick
> >> which master is active at what point,
> >
> > Even if it's not yet implemented, I have everything in place to figure
> > this out (see the ->cur_master field in the i3c_bus object). Now,
> > what's missing is a list of possible masters attached to an i3c device
> > so that the framework can pick the most appropriate one at runtime and
> > initiate mastership handover if required (if the selected master is not
> > the currently active one).
> >
> > The selection logic should look like this:
> >
> > if (active_master supports requested feature)
> > use active master
> > else
> > pick an inactive one that has relevant caps and initiate
> > mastership handover (+ update bus->cur_master)
>
> How would you deal with soft requirements like performance?
> E.g. if you have one master that can do large transfers faster
> through a special DMA engine, and other master that can
> be faster for small transfers, but both support all capabilities
> for that device, won't you need some complex logic to avoid
> being stuck with a slow master indefinitely?
True.
>
> >> or what specific scenario
> >> would require it.
> >
> > I think I described a scenario (masters having different
> > capabilities all connected to the same bus), though I don't know how
> > likely this use case is :-/.
>
> I was looking for something more specific here. What (lack of)
> capabilities could two i3c controllers have that require you to
> use both of them for the same device, rather than picking
> a master for each slave with the right feature set?
Hehe, if I had a clear answer to this question we wouldn't have this
discussion :-). I gave you an example:
- master A supporting IBIs but not HDR transactions
- master B supporting HDR modes but not IBIs
but as I said, I'm not sure how likely this example is...
The question is more, should we design things so that we can at some
point implement a solution to support those funky setups, or should we
just ignore it and risk breaking sysfs/DT ABI when/if we have to support
that?
This is really an open question. I initially went for the former, but
have no objection switching to the latter.
Powered by blists - more mailing lists