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: linux-gpio@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. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3CB79ECDFB8 for ; Tue, 24 Jul 2018 16:54:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E9CE420856 for ; Tue, 24 Jul 2018 16:54:21 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E9CE420856 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=bootlin.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388525AbeGXSBm (ORCPT ); Tue, 24 Jul 2018 14:01:42 -0400 Received: from mail.bootlin.com ([62.4.15.54]:41270 "EHLO mail.bootlin.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388322AbeGXSBl (ORCPT ); Tue, 24 Jul 2018 14:01:41 -0400 Received: by mail.bootlin.com (Postfix, from userid 110) id E1B8D2072C; Tue, 24 Jul 2018 18:54:16 +0200 (CEST) Received: from bbrezillon (91-160-177-164.subs.proxad.net [91.160.177.164]) by mail.bootlin.com (Postfix) with ESMTPSA id 20107206A6; Tue, 24 Jul 2018 18:54:16 +0200 (CEST) Date: Tue, 24 Jul 2018 18:54:15 +0200 From: Boris Brezillon 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 , Mark Rutland , Ian Campbell , Kumar Gala , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Linux Kernel Mailing List , Vitor Soares , Linus Walleij , Xiang Lin , "open list:GPIO SUBSYSTEM" , Sekhar Nori , Przemyslaw Gaj Subject: Re: [PATCH v6 00/10] Add the I3C subsystem Message-ID: <20180724185415.6126751e@bbrezillon> In-Reply-To: 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> X-Mailer: Claws Mail 3.15.0-dirty (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@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. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on archive.lwn.net X-Spam-Level: X-Spam-Status: No, score=-5.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI autolearn=unavailable autolearn_force=no version=3.4.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by archive.lwn.net (Postfix) with ESMTP id 0D8F37D071 for ; Tue, 24 Jul 2018 16:54:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388431AbeGXSBm (ORCPT ); Tue, 24 Jul 2018 14:01:42 -0400 Received: from mail.bootlin.com ([62.4.15.54]:41270 "EHLO mail.bootlin.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388322AbeGXSBl (ORCPT ); Tue, 24 Jul 2018 14:01:41 -0400 Received: by mail.bootlin.com (Postfix, from userid 110) id E1B8D2072C; Tue, 24 Jul 2018 18:54:16 +0200 (CEST) Received: from bbrezillon (91-160-177-164.subs.proxad.net [91.160.177.164]) by mail.bootlin.com (Postfix) with ESMTPSA id 20107206A6; Tue, 24 Jul 2018 18:54:16 +0200 (CEST) Date: Tue, 24 Jul 2018 18:54:15 +0200 From: Boris Brezillon 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 , Mark Rutland , Ian Campbell , Kumar Gala , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Linux Kernel Mailing List , Vitor Soares , Linus Walleij , Xiang Lin , "open list:GPIO SUBSYSTEM" , Sekhar Nori , Przemyslaw Gaj Subject: Re: [PATCH v6 00/10] Add the I3C subsystem Message-ID: <20180724185415.6126751e@bbrezillon> In-Reply-To: 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> X-Mailer: Claws Mail 3.15.0-dirty (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-doc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-doc@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. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html