lkml.org 
[lkml]   [2018]   [Jul]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v6 00/10] Add the I3C subsystem
On Tue, 24 Jul 2018 18:25:22 +0200
Arnd Bergmann <arnd@arndb.de> wrote:

> On Tue, Jul 24, 2018 at 6:14 PM, Boris Brezillon
> <boris.brezillon@bootlin.com> wrote:
> > On Tue, 24 Jul 2018 17:58:29 +0200
> > Arnd Bergmann <arnd@arndb.de> wrote:
> >
> >> On Tue, Jul 24, 2018 at 5:46 PM, Geert Uytterhoeven
> >> <geert@linux-m68k.org> wrote:
> >> > On Tue, Jul 24, 2018 at 5:40 PM Arnd Bergmann <arnd@arndb.de> wrote:
> >> >> On Tue, Jul 24, 2018 at 5:15 PM, Geert Uytterhoeven
> >> >> <geert@linux-m68k.org> wrote:
> >> >> > On Tue, Jul 24, 2018 at 5:05 PM Arnd Bergmann <arnd@arndb.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.

\
 
 \ /
  Last update: 2018-07-24 18:55    [W:0.124 / U:0.232 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site