From mboxrd@z Thu Jan 1 00:00:00 1970 From: Geert Uytterhoeven Subject: Re: [PATCH v6 00/10] Add the I3C subsystem Date: Tue, 24 Jul 2018 17:46:09 +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> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Arnd Bergmann Cc: Boris Brezillon , 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 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. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds 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 0B91EECDFB8 for ; Tue, 24 Jul 2018 15:46:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C611C20856 for ; Tue, 24 Jul 2018 15:46:26 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C611C20856 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-m68k.org 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 S2388480AbeGXQx2 (ORCPT ); Tue, 24 Jul 2018 12:53:28 -0400 Received: from mail-vk0-f67.google.com ([209.85.213.67]:43278 "EHLO mail-vk0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388300AbeGXQx2 (ORCPT ); Tue, 24 Jul 2018 12:53:28 -0400 Received: by mail-vk0-f67.google.com with SMTP id s17-v6so2261671vke.10; Tue, 24 Jul 2018 08:46:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oa7UlTiloXoc6U/EcthojwxasXcOuDWL7biSXvLmbsM=; b=WtAqTPQfUXQ91k0phXSxk3yV/V4TOTpOK1TmqZPn/W6T6qCmH3WeMWqqWttaBbmMsR vzlySAzAeTdy4+wVMldnQRH/evW7kd4KjNAcqXn3vhBZO/jAYMxn/c5XFwlSpVYbAHAV Ji40kI4bkrLcdFs7KYo/eRGTYQojmkn+htuYwyysHF+mZfwLODtT/eDJvr4uXxCrcsN4 2SzjSw/ENkjhtaDmWYR7TPWV2ekFGnVS72Rub1nOXNGr0sO2XAYxQm0ikRbuJTwZ23Zn 33QlHPtx3ZW7v79PYMJxw2tBKv1Iipx2tQcKTKw5v//P+bSjxGclIELnkM8zJJL430aH enSg== X-Gm-Message-State: AOUpUlGB0PL7hp2ittyiHuoH8ywaweSE/wVePF8NAb2io/8Alu3ZImDQ oqTDWUA9FQZErcvbzYNw+CiMMZv0s2wBoUXLMg8= X-Google-Smtp-Source: AAOMgpcU60zKK0qSYG0cTym8Png/z7Ymcjt9IAF/gltFoVGGagMcKNO5pc9zoawf8PGQRMGuLaL1cBW36dAdM14BVPY= X-Received: by 2002:a1f:8948:: with SMTP id l69-v6mr11025960vkd.132.1532447182109; Tue, 24 Jul 2018 08:46:22 -0700 (PDT) MIME-Version: 1.0 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> In-Reply-To: From: Geert Uytterhoeven Date: Tue, 24 Jul 2018 17:46:09 +0200 Message-ID: Subject: Re: [PATCH v6 00/10] Add the I3C subsystem To: Arnd Bergmann Cc: Boris Brezillon , 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 , pgaj@cadence.com 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 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. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds 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=ham 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 A13F27D071 for ; Tue, 24 Jul 2018 15:46:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388402AbeGXQx2 (ORCPT ); Tue, 24 Jul 2018 12:53:28 -0400 Received: from mail-vk0-f67.google.com ([209.85.213.67]:43278 "EHLO mail-vk0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388300AbeGXQx2 (ORCPT ); Tue, 24 Jul 2018 12:53:28 -0400 Received: by mail-vk0-f67.google.com with SMTP id s17-v6so2261671vke.10; Tue, 24 Jul 2018 08:46:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oa7UlTiloXoc6U/EcthojwxasXcOuDWL7biSXvLmbsM=; b=WtAqTPQfUXQ91k0phXSxk3yV/V4TOTpOK1TmqZPn/W6T6qCmH3WeMWqqWttaBbmMsR vzlySAzAeTdy4+wVMldnQRH/evW7kd4KjNAcqXn3vhBZO/jAYMxn/c5XFwlSpVYbAHAV Ji40kI4bkrLcdFs7KYo/eRGTYQojmkn+htuYwyysHF+mZfwLODtT/eDJvr4uXxCrcsN4 2SzjSw/ENkjhtaDmWYR7TPWV2ekFGnVS72Rub1nOXNGr0sO2XAYxQm0ikRbuJTwZ23Zn 33QlHPtx3ZW7v79PYMJxw2tBKv1Iipx2tQcKTKw5v//P+bSjxGclIELnkM8zJJL430aH enSg== X-Gm-Message-State: AOUpUlGB0PL7hp2ittyiHuoH8ywaweSE/wVePF8NAb2io/8Alu3ZImDQ oqTDWUA9FQZErcvbzYNw+CiMMZv0s2wBoUXLMg8= X-Google-Smtp-Source: AAOMgpcU60zKK0qSYG0cTym8Png/z7Ymcjt9IAF/gltFoVGGagMcKNO5pc9zoawf8PGQRMGuLaL1cBW36dAdM14BVPY= X-Received: by 2002:a1f:8948:: with SMTP id l69-v6mr11025960vkd.132.1532447182109; Tue, 24 Jul 2018 08:46:22 -0700 (PDT) MIME-Version: 1.0 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> In-Reply-To: From: Geert Uytterhoeven Date: Tue, 24 Jul 2018 17:46:09 +0200 Message-ID: Subject: Re: [PATCH v6 00/10] Add the I3C subsystem To: Arnd Bergmann Cc: Boris Brezillon , 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 , pgaj@cadence.com 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 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. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds -- 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