Re: [PATCH v6 00/10] Add the I3C subsystem

[Boris Brezillon <boris.brezillon@bootlin.com>]

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.