Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp7094924imm; Tue, 24 Jul 2018 08:18:08 -0700 (PDT) X-Google-Smtp-Source: AAOMgpe/nJ6pxE7AuzrbrEzKggt+xKe9uCsIQtKpEOYBohxe6nKmpOcU0NEOMWipTFCsTdgDJC1z X-Received: by 2002:a62:455b:: with SMTP id s88-v6mr18128667pfa.203.1532445488236; Tue, 24 Jul 2018 08:18:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532445488; cv=none; d=google.com; s=arc-20160816; b=tBrtK44mw3LcQoqU2qvXu3I2jK7F3HsgQ36YUGEO6TKe0jqr/C3jS1C9AFvmLxNWxV QNCyxxqC/yyk6ZWrxxwMXd8SXuNJkw3HsnCXENKqXYbyhnNNjw1JSxNqueexalqOEANM dIeADKUztQHFblWyiv5eaNKPbUEzZegH6yedD60dIUGnd3pvlBV3kzsZQ+suE1xxWFce VhpcLYsYtimCYF3xpPRh/Yu+DhQpwcRjVfXjgrjhU7oaDHv6ODjYGMCN8m4Q9IL/BF0R OCorqciuiuwsOs//RCiTEWoRsgGauceCzz+hH4/jIXhYR6AQXQNhI7LG09+BeuehktEV as4w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:arc-authentication-results; bh=k/XpYZ9gPWMhLH10ZDNqCIR0cUhfKNwuqICAPldKfQc=; b=rl2+aV+b9jWZ8LlZacHkXZXlgdmdYmu+/xShmI1vPZSXXIPdBgNdel7/ZlqBHGo2XQ CN9WEwyaecq/AuUkKeIXmYtljHkWbukeNKRgl9HKJfyqsVhsi237ofjHPg5qlFJNqPB+ Lo3/8Xwwt9RHF722wa3ihKmx9XGejBouhE51i7vuwuHsELQ88+1KkiDq0dOtf//tLwk4 v9Y5ZoNI7uMFqNSFjsCGcVVof1DZuePLaNe/2ArsHuox0GpAO/L/pTVtJW0gnd3CIuPy id5DNGerJC3L6B7z4N69CYTeht5pwL7HBDJkmtZgIfVpy9Vdn89Jobze6KjL/hamVwwf bIMg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 44-v6si11116864plb.376.2018.07.24.08.17.53; Tue, 24 Jul 2018 08:18:08 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388420AbeGXQXF (ORCPT + 99 others); Tue, 24 Jul 2018 12:23:05 -0400 Received: from mail-vk0-f67.google.com ([209.85.213.67]:36961 "EHLO mail-vk0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388298AbeGXQXE (ORCPT ); Tue, 24 Jul 2018 12:23:04 -0400 Received: by mail-vk0-f67.google.com with SMTP id v72-v6so2211424vkd.4; Tue, 24 Jul 2018 08:16:06 -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=k/XpYZ9gPWMhLH10ZDNqCIR0cUhfKNwuqICAPldKfQc=; b=CZ/T/GghEH/XmsuNedu4bapwu3UXIrCMtQ6vOJV7/YigbA0QNluv3knc72/som9iiB kxU2cV13BSO96tRsYCttZet3lzd7q2BEG8XXW9W//3J3QF0teOi29w+8oXrqS/uvSzIg 0C2a/yD9tzboRQDLj44wwseXOxvicX5HLHk2RfE+JjpAm7blMaU1tLIwAAKMj/KW+DR6 lD+wFbdBh4ZJ30f1lGyP+/6QV1FNapkBtms/ZwE6lhGZd4aYbxCZMA0OuJENkTTMXXu0 lg0sFt/liTWfjcqWO3wIK96RNVcBv0AMKLq/Os1zFTsFHG38sj0jW7rR2YwQypjhdnde JtmQ== X-Gm-Message-State: AOUpUlHmoLRvTemxTlizyegSlq8oW68lInykt4ZHlzEExX7Cc7tJ5K4d oLRhH6KR1uNMW68jwE3vYDtoOGEG66owNIMCsJZd6g== X-Received: by 2002:a1f:420d:: with SMTP id p13-v6mr10715856vka.10.1532445366167; Tue, 24 Jul 2018 08:16:06 -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:15:53 +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:05 PM Arnd Bergmann wrote: > On Tue, Jul 24, 2018 at 4:28 PM, Boris Brezillon > wrote: > > On Tue, 24 Jul 2018 16:03:38 +0200 > > Arnd Bergmann wrote: > >> On Fri, Jul 20, 2018 at 3:17 PM, Boris Brezillon > >> wrote: > >> > On Fri, 20 Jul 2018 13:28:10 +0200 Arnd Bergmann wrote: > >> >> On Fri, Jul 20, 2018 at 1:13 PM, Peter Rosin wrote: > >> >> > On 2018-07-20 12:57, Arnd Bergmann wrote: > >> >> >> * What I understand from reading i2c-demux-pinctrl.c, a slave device > >> >> >> will only ever be observable from one master at a time, when you > >> >> >> switch over, all children get removed on one master and added to > >> >> >> the other one, to be probed again by their respective drivers. > >> >> >> I can see this as a useful feature on i3c as well, in particular to > >> >> >> deal with the situation where we have i2c slaves connected to a > >> >> >> pinmux that can switch them between an i3c master and an > >> >> >> i2c-only master (possibly a gpio based one). That particular use > >> >> >> case however doesn't seem to fix well in the current code, which > >> >> >> is structure around i3c buses. > >> >> > > >> >> > It's pretty easy to come up with examples where this reprobing is > >> >> > not desirable at all. E.g. if one of the involved I2C devices is > >> >> > a HDMI encoder (I have a TDA19988 here) sitting in the middle of the > >> >> > graphics pipeline. Blink-blink on the screen because some *other* > >> >> > unrelated device needed to be accessed by an alternative master. Not > >> >> > pretty. > >> >> > >> >> Agreed, we definitely don't want to reprobe all devices during normal > >> >> operation for i3c master handover. > >> >> > >> > > >> > Re-probing would not happen, no matter the solution we choose. It's > >> > that, in one case, you would have X virtual/linux devices representing > >> > the same physical device and in the other case, you would just have > >> > one, and everytime a transfer is requested by the driver, the core > >> > would pick the appropriate master to do it (most likely the one in > >> > control of the bus at that time) > >> > >> I think this is one of the cases I'd want to avoid: controlling multiple > >> masters that are active at the same time without going through > >> the handover. > > > > That's simply not possible, the I3C protocol forbids it. There can only > > be one active master on the bus at any point in time. > > Ok, it sounded like that's what you wanted to do here. > > >> If we have an actual pinmux between two masters and only one > >> of them can even see the bus, I think we should go through a > >> complete remove/probe cycle the way that the i2c-demux-pinctrl > >> does today. If OTOH we a primary/secondary master pair with > >> handover capability, I would prefer to not see one slave on > >> both devices at the same time, or (ideally) only use one of the > >> two masters and disable the other one completely. > > > > Again, you don't have a choice because it's part of the protocol. At > > any time, you only have one active master on the bus, and other masters > > are acting as slaves until they gain bus ownership (if they ever do). > > Say that device A wants to do an HDR transfer on the bus, and HDR is > > only supported by master X, but master Y is currently owning the bus. > > Master X will first have to request bus ownership before doing the > > transfer requested by device A. > > > > Now, imagine that device A wants to do an SDR transfer which is > > supported by both master X and master Y, and master Y is in control. > > Instead of requesting a bus handover, the framework would just > > automatically decide to do the transfer through master Y. That's the > > sort of things this separate bus/master representation allows. > > 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.). 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