From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnd Bergmann Subject: Re: [PATCH v6 00/10] Add the I3C subsystem Date: Tue, 24 Jul 2018 18:25:22 +0200 Message-ID: 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="UTF-8" Return-path: In-Reply-To: <20180724181437.1d1b27a8@bbrezillon> Sender: linux-kernel-owner@vger.kernel.org To: Boris Brezillon 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, 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? >> 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 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.6 required=3.0 tests=DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS,T_DKIM_INVALID, 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 193B0C6778A for ; Tue, 24 Jul 2018 16:25:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B52EE20874 for ; Tue, 24 Jul 2018 16:25:26 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="K+v5q77r" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B52EE20874 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arndb.de 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 S2388473AbeGXRcj (ORCPT ); Tue, 24 Jul 2018 13:32:39 -0400 Received: from mail-qt0-f193.google.com ([209.85.216.193]:36806 "EHLO mail-qt0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388324AbeGXRci (ORCPT ); Tue, 24 Jul 2018 13:32:38 -0400 Received: by mail-qt0-f193.google.com with SMTP id t5-v6so4703943qtn.3; Tue, 24 Jul 2018 09:25:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=qjm3UTnBUv3UROMnMrmq856i4dxEjJaSH4PR6XPxztc=; b=K+v5q77ro0nfMqrSyjPeXZsGbz5tWt7QDMjrQao8EnLZ6ijnb6h198HOEhWB0AzFJ1 RQFkTqGh7EZ66Wu6trEUyeAWaglIe5z4GUTBfH0xRnDW+EoLDaegDnwQ5TnusXNLt8i5 ZIm3sCMed2v0rNkxhwMMpYG2DjKsu2IlPxN+Tmmve/XYJsreBFWeIIlIw26D24vvYzDU RoX7yRAhF+4irX5vRRZKVM1MgyWq5I3uBCBQSgW8/4NZn9PI4Qk4OTMgGdkIt7/TyzOS VIS/zkgGPlb4NehX3EP30EbmjVj5+GEILw1KFHwQZTDzAAUuKaVLVdP+mKsDCkr3Fzvd 3eTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=qjm3UTnBUv3UROMnMrmq856i4dxEjJaSH4PR6XPxztc=; b=ZULomDu/QrkP87mQe65UVmg0WffD+Yn21pi4ccCt4vTPhf9aS8h/bVMLvLIvbgs3Pe Qw6PGDC16TZBPqss80DgQ09URsCNqe/VWIPrELwe034vM/HZcWtjduyfGd/ryyW07Nzb mgtiMtk5gqa2XXtHVxyd1bCBqrPn908hZAE9BUsmnV4tEwykAHQUbBTrYfeKcZvD/PE3 1IsO91UBcdncyf0F+ks1LAOKQQMUxtLwXp2gsa+I4TljvQ0i/lwKdvP+TkjJOlA3FFkA EjJMcW1wQ751/4S2fNjKFXCVMEhCbxUJHSeOCzuvegxcyZrfvDrDJ6pgxlT/LPR1eBbp u7XQ== X-Gm-Message-State: AOUpUlEVCaCeaxcTFEW3Gj73jkGG/51IWPt7R9iY1ZSZulQZ6Vp26zbB MsUv9ZDBOkbqKbV0I/NIYG85WfIK9flF3Iz0i+g= X-Google-Smtp-Source: AAOMgpd1Exn+wzv4wBDHMKm31K9OWfHwbFS8ajZORAf/qe6KQ+8MvvmzTLbA03qghLsbedWHeLWGAck7UQyZFncGE1Q= X-Received: by 2002:a0c:f804:: with SMTP id r4-v6mr15663606qvn.156.1532449523052; Tue, 24 Jul 2018 09:25:23 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a0c:967d:0:0:0:0:0 with HTTP; Tue, 24 Jul 2018 09:25:22 -0700 (PDT) In-Reply-To: <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> <20180724181437.1d1b27a8@bbrezillon> From: Arnd Bergmann Date: Tue, 24 Jul 2018 18:25:22 +0200 X-Google-Sender-Auth: tB-CBZse7BgubK89aIV1551LF9I Message-ID: Subject: Re: [PATCH v6 00/10] Add the I3C subsystem To: Boris Brezillon 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 Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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? >> 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 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.6 required=5.0 tests=DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI, T_DKIM_INVALID 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 A82C97D085 for ; Tue, 24 Jul 2018 16:25:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388409AbeGXRcj (ORCPT ); Tue, 24 Jul 2018 13:32:39 -0400 Received: from mail-qt0-f193.google.com ([209.85.216.193]:36806 "EHLO mail-qt0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388324AbeGXRci (ORCPT ); Tue, 24 Jul 2018 13:32:38 -0400 Received: by mail-qt0-f193.google.com with SMTP id t5-v6so4703943qtn.3; Tue, 24 Jul 2018 09:25:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=qjm3UTnBUv3UROMnMrmq856i4dxEjJaSH4PR6XPxztc=; b=K+v5q77ro0nfMqrSyjPeXZsGbz5tWt7QDMjrQao8EnLZ6ijnb6h198HOEhWB0AzFJ1 RQFkTqGh7EZ66Wu6trEUyeAWaglIe5z4GUTBfH0xRnDW+EoLDaegDnwQ5TnusXNLt8i5 ZIm3sCMed2v0rNkxhwMMpYG2DjKsu2IlPxN+Tmmve/XYJsreBFWeIIlIw26D24vvYzDU RoX7yRAhF+4irX5vRRZKVM1MgyWq5I3uBCBQSgW8/4NZn9PI4Qk4OTMgGdkIt7/TyzOS VIS/zkgGPlb4NehX3EP30EbmjVj5+GEILw1KFHwQZTDzAAUuKaVLVdP+mKsDCkr3Fzvd 3eTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=qjm3UTnBUv3UROMnMrmq856i4dxEjJaSH4PR6XPxztc=; b=ZULomDu/QrkP87mQe65UVmg0WffD+Yn21pi4ccCt4vTPhf9aS8h/bVMLvLIvbgs3Pe Qw6PGDC16TZBPqss80DgQ09URsCNqe/VWIPrELwe034vM/HZcWtjduyfGd/ryyW07Nzb mgtiMtk5gqa2XXtHVxyd1bCBqrPn908hZAE9BUsmnV4tEwykAHQUbBTrYfeKcZvD/PE3 1IsO91UBcdncyf0F+ks1LAOKQQMUxtLwXp2gsa+I4TljvQ0i/lwKdvP+TkjJOlA3FFkA EjJMcW1wQ751/4S2fNjKFXCVMEhCbxUJHSeOCzuvegxcyZrfvDrDJ6pgxlT/LPR1eBbp u7XQ== X-Gm-Message-State: AOUpUlEVCaCeaxcTFEW3Gj73jkGG/51IWPt7R9iY1ZSZulQZ6Vp26zbB MsUv9ZDBOkbqKbV0I/NIYG85WfIK9flF3Iz0i+g= X-Google-Smtp-Source: AAOMgpd1Exn+wzv4wBDHMKm31K9OWfHwbFS8ajZORAf/qe6KQ+8MvvmzTLbA03qghLsbedWHeLWGAck7UQyZFncGE1Q= X-Received: by 2002:a0c:f804:: with SMTP id r4-v6mr15663606qvn.156.1532449523052; Tue, 24 Jul 2018 09:25:23 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a0c:967d:0:0:0:0:0 with HTTP; Tue, 24 Jul 2018 09:25:22 -0700 (PDT) In-Reply-To: <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> <20180724181437.1d1b27a8@bbrezillon> From: Arnd Bergmann Date: Tue, 24 Jul 2018 18:25:22 +0200 X-Google-Sender-Auth: tB-CBZse7BgubK89aIV1551LF9I Message-ID: Subject: Re: [PATCH v6 00/10] Add the I3C subsystem To: Boris Brezillon 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 Content-Type: text/plain; charset="UTF-8" Sender: linux-doc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org 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? >> 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-doc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html