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:14:37 +0200 Message-ID: <20180724181437.1d1b27a8@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> 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 17:58:29 +0200 Arnd Bergmann wrote: > On Tue, Jul 24, 2018 at 5:46 PM, Geert Uytterhoeven > wrote: > > Hi Arnd, > > > > 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: > >> > >> >> That's not the case I was describing here, I was thinking of what > >> >> Wolfram described with the Renesas SoC that has two i2c masters > >> >> multiplexed through the pinmux layer. I would assume that we > >> >> can still do the same thing in i3c by shutting down the current > >> >> master without a handover, and reprobing everything from scratch. > >> > > >> > The major disadvantage of reprobing is that it may cause visual disturbances > >> > when i2c slaves are involved with e.g. the display pipeline (think HDMI encoders > >> > etc.). > >> > >> Do you mean we should reuse the device pointer and association with > >> the driver even when we switch out the i3c master using the pinmux? > >> > >> Or do you mean we need to be prepared for driving a single > >> slave through multiple masters over the lifetime of that device, > >> but using the i3c master handover protocol? > >> In the second case, how do we decide which master to use > >> for accessing a device for a given request? > > > > I'll have to defer to Wolfram. He's the i2c and muxing expert. > > On i2c, we only have the first case, and Wolfram said that it > intentionally does the reprobe to avoid the problems we discussed. > The question is what to do about this if it happens again on i3c. > Peter seemed to think that it was possibly something we might > have to handle, while Boris said that it wouldn't be because it's > not coverered by the i3c spec. > > 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) > 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 :-/. 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 47C76ECDFB8 for ; Tue, 24 Jul 2018 16:14:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 07E8D20880 for ; Tue, 24 Jul 2018 16:14:43 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 07E8D20880 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 S2388560AbeGXRVx (ORCPT ); Tue, 24 Jul 2018 13:21:53 -0400 Received: from mail.bootlin.com ([62.4.15.54]:39383 "EHLO mail.bootlin.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388289AbeGXRVx (ORCPT ); Tue, 24 Jul 2018 13:21:53 -0400 Received: by mail.bootlin.com (Postfix, from userid 110) id 39AC220733; Tue, 24 Jul 2018 18:14:38 +0200 (CEST) Received: from bbrezillon (91-160-177-164.subs.proxad.net [91.160.177.164]) by mail.bootlin.com (Postfix) with ESMTPSA id 73211203D9; Tue, 24 Jul 2018 18:14:37 +0200 (CEST) Date: Tue, 24 Jul 2018 18:14:37 +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: <20180724181437.1d1b27a8@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> 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 17:58:29 +0200 Arnd Bergmann wrote: > On Tue, Jul 24, 2018 at 5:46 PM, Geert Uytterhoeven > wrote: > > Hi Arnd, > > > > 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: > >> > >> >> That's not the case I was describing here, I was thinking of what > >> >> Wolfram described with the Renesas SoC that has two i2c masters > >> >> multiplexed through the pinmux layer. I would assume that we > >> >> can still do the same thing in i3c by shutting down the current > >> >> master without a handover, and reprobing everything from scratch. > >> > > >> > The major disadvantage of reprobing is that it may cause visual disturbances > >> > when i2c slaves are involved with e.g. the display pipeline (think HDMI encoders > >> > etc.). > >> > >> Do you mean we should reuse the device pointer and association with > >> the driver even when we switch out the i3c master using the pinmux? > >> > >> Or do you mean we need to be prepared for driving a single > >> slave through multiple masters over the lifetime of that device, > >> but using the i3c master handover protocol? > >> In the second case, how do we decide which master to use > >> for accessing a device for a given request? > > > > I'll have to defer to Wolfram. He's the i2c and muxing expert. > > On i2c, we only have the first case, and Wolfram said that it > intentionally does the reprobe to avoid the problems we discussed. > The question is what to do about this if it happens again on i3c. > Peter seemed to think that it was possibly something we might > have to handle, while Boris said that it wouldn't be because it's > not coverered by the i3c spec. > > 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) > 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 :-/. 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 B97017D085 for ; Tue, 24 Jul 2018 16:14:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388553AbeGXRVx (ORCPT ); Tue, 24 Jul 2018 13:21:53 -0400 Received: from mail.bootlin.com ([62.4.15.54]:39383 "EHLO mail.bootlin.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388289AbeGXRVx (ORCPT ); Tue, 24 Jul 2018 13:21:53 -0400 Received: by mail.bootlin.com (Postfix, from userid 110) id 39AC220733; Tue, 24 Jul 2018 18:14:38 +0200 (CEST) Received: from bbrezillon (91-160-177-164.subs.proxad.net [91.160.177.164]) by mail.bootlin.com (Postfix) with ESMTPSA id 73211203D9; Tue, 24 Jul 2018 18:14:37 +0200 (CEST) Date: Tue, 24 Jul 2018 18:14:37 +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: <20180724181437.1d1b27a8@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> 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 17:58:29 +0200 Arnd Bergmann wrote: > On Tue, Jul 24, 2018 at 5:46 PM, Geert Uytterhoeven > wrote: > > Hi Arnd, > > > > 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: > >> > >> >> That's not the case I was describing here, I was thinking of what > >> >> Wolfram described with the Renesas SoC that has two i2c masters > >> >> multiplexed through the pinmux layer. I would assume that we > >> >> can still do the same thing in i3c by shutting down the current > >> >> master without a handover, and reprobing everything from scratch. > >> > > >> > The major disadvantage of reprobing is that it may cause visual disturbances > >> > when i2c slaves are involved with e.g. the display pipeline (think HDMI encoders > >> > etc.). > >> > >> Do you mean we should reuse the device pointer and association with > >> the driver even when we switch out the i3c master using the pinmux? > >> > >> Or do you mean we need to be prepared for driving a single > >> slave through multiple masters over the lifetime of that device, > >> but using the i3c master handover protocol? > >> In the second case, how do we decide which master to use > >> for accessing a device for a given request? > > > > I'll have to defer to Wolfram. He's the i2c and muxing expert. > > On i2c, we only have the first case, and Wolfram said that it > intentionally does the reprobe to avoid the problems we discussed. > The question is what to do about this if it happens again on i3c. > Peter seemed to think that it was possibly something we might > have to handle, while Boris said that it wouldn't be because it's > not coverered by the i3c spec. > > 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) > 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 :-/. -- 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