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

[Arnd Bergmann <arnd@xxxxxxxx>]

On Tue, Jul 24, 2018 at 6:14 PM, Boris Brezillon
<boris.brezillon@xxxxxxxxxxx> wrote:
> On Tue, 24 Jul 2018 17:58:29 +0200
> Arnd Bergmann <arnd@xxxxxxxx> wrote:
>
>> On Tue, Jul 24, 2018 at 5:46 PM, Geert Uytterhoeven
>> <geert@xxxxxxxxxxxxxx> wrote:
>> > On Tue, Jul 24, 2018 at 5:40 PM Arnd Bergmann <arnd@xxxxxxxx> wrote:
>> >> On Tue, Jul 24, 2018 at 5:15 PM, Geert Uytterhoeven
>> >> <geert@xxxxxxxxxxxxxx> wrote:
>> >> > On Tue, Jul 24, 2018 at 5:05 PM Arnd Bergmann <arnd@xxxxxxxx> 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?

>> 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?

     Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html