From mboxrd@z Thu Jan 1 00:00:00 1970 From: Boris Brezillon Subject: Re: [PATCH v6 00/10] Add the I3C subsystem Date: Tue, 24 Jul 2018 18:54:15 +0200 Message-ID: <20180724185415.6126751e@bbrezillon> References: <20180719152930.3715-1-boris.brezillon@bootlin.com> <2ab0ab75-2df0-2714-f007-c33b25481016@axentia.se> <20180720101206.tv7nsoanwo5ftnia@ninjato> <21b269c5-a3a7-c5de-c81e-c9c9301ae13e@axentia.se> <20180720151751.242d4809@bbrezillon> <20180724162806.318a92c6@bbrezillon> <20180724181437.1d1b27a8@bbrezillon> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Arnd Bergmann Cc: Geert Uytterhoeven , Peter Rosin , Wolfram Sang , Linux I2C , Jonathan Corbet , "open list:DOCUMENTATION" , Greg KH , Przemyslaw Sroka , Arkadiusz Golec , Alan Douglas , Bartosz Folta , Damian Kos , Alicja Jurasik-Urbaniak , Cyprian Wronka , Suresh Punnoose , Rafal Ciepiela , Thomas Petazzoni , Nishanth Menon , Rob Herring , Pawel Moll List-Id: devicetree@vger.kernel.org On Tue, 24 Jul 2018 18:25:22 +0200 Arnd Bergmann wrote: > On Tue, Jul 24, 2018 at 6:14 PM, Boris Brezillon > wrote: > > On Tue, 24 Jul 2018 17:58:29 +0200 > > Arnd Bergmann wrote: > > > >> On Tue, Jul 24, 2018 at 5:46 PM, Geert Uytterhoeven > >> wrote: > >> > On Tue, Jul 24, 2018 at 5:40 PM Arnd Bergmann wrote: > >> >> On Tue, Jul 24, 2018 at 5:15 PM, Geert Uytterhoeven > >> >> wrote: > >> >> > On Tue, Jul 24, 2018 at 5:05 PM Arnd Bergmann 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.