On Tue, 24 Jul 2018 18:25:22 +0200 Arnd Bergmann <arnd@xxxxxxxx> wrote: > 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? 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. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
