Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Thu, 18 Jun 2020 11:59:18 -0700
From:   Prashant Malani <pmalani@chromium.org>
To:     Heikki Krogerus <heikki.krogerus@linux.intel.com>
Cc:     Rob Herring <robh@kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Tim Wawrzynczak <twawrzynczak@chromium.org>,
        Benson Leung <bleung@chromium.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@vger.kernel.org>,
        Enric Balletbo i Serra <enric.balletbo@collabora.com>,
        Guenter Roeck <groeck@chromium.org>,
        Rajmohan Mani <rajmohan.mani@intel.com>
Subject: Re: [PATCH 1/2] dt-bindings: chrome: Add cros-ec-typec mux props
Message-ID: <20200618185918.GB255826@google.com>
References: <CAL_JsqJ2pbh5BbjGd9eEiD6-sV94=omk6o+mLXjCYiVnUOtO=g@mail.gmail.com>
 <CACeCKadiiokPdPB2Q5WBQFrPuxjpm3TiDgaaerncVR_Z7Z0nvg@mail.gmail.com>
 <CAL_Jsq+MM3-ugLvSGc_wc6RvHVyxyDUD0DkvwQaQJMYCCFpfHg@mail.gmail.com>
 <20200609235740.GA154315@google.com>
 <20200610153356.GC3213128@kuha.fi.intel.com>
 <CAL_JsqKsObFhC+J6gK2EDXdpBLO6t+rswXDipnjt4uMr2Qx2zg@mail.gmail.com>
 <CACeCKadq6tuqzR_6DuiZeL+=aOMb05EWd4o0sNyGOcZJ=dYx8g@mail.gmail.com>
 <CAL_JsqJQb5P26JC-KqkeHoWxAb63N+_XRK==b-WWJ+pYpdHO8Q@mail.gmail.com>
 <CACeCKacUa1-ttBmKS_Q_xZCsArgGWkB4s9eG0c5Lc5RHa1W35Q@mail.gmail.com>
 <20200615132207.GG3213128@kuha.fi.intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200615132207.GG3213128@kuha.fi.intel.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi Heikki and Rob,

(trimming text):
On Mon, Jun 15, 2020 at 04:22:07PM +0300, Heikki Krogerus wrote:
> On Fri, Jun 12, 2020 at 10:34:06AM -0700, Prashant Malani wrote:
> > Hi Rob,
> > > Yes, but let's stop calling it a mux. It's a "USB Type C signal routing blob".
> > 
> > Ack.
> > 
> > Let's go with "-switch" ? That's what the connector class uses and it
> > conveys the meaning (unless that is a reserved keyword in DT).
> 
> Just as a clarification here, we should not be even talking about
> signal routing here. We are talking about functions that an external
> components perform from the connector's perspective. It depends on the
> platform does that function require changing the routing of the lines
> from the connector. For example, data role swapping does not require
> muxing on platforms that have single dual-role USB controller, but
> platforms that have separate IPs for the USB host and USB device
> controllers will need a mux.
> 
> Note, that it is even possible that switching from USB to DisplayPort
> mode does not require any pin reconfiguration from the mux, even if
> the platform has one, because the PHY can be shared between USB3 and
> DP. Then the PHY just needs to be told that it is now in DP mode when
> DP alt mode is entered instead of the mux.
> 
> > > > Would this block the addition of the "*-switch" properties? IIUC the
> > > > two are related but not dependent on each other.
> > > >
> > > > The *-switch properties are phandles which the Type C connector class
> > > > framework expects (and uses to get handles to those switches).
> > > > These would point to the "mux" or "group of mux" abstractions as noted earlier.
> > >
> > > You don't need them though. Walk the graph. You get the connector
> > > port@1 remote endpoint and then get its parent.
> > >
> > 
> > I see; would it be something along the lines of this? (DT example
> > follows; search for "example_end" to jump to bottom):
> 
> I just realized that you have in practice placed the mux-agent into
> the graph below, right? That we can not do, because it is not
> physically connected to the connector.

Is this a requirement? I read through the graph.txt file [1] and I couldn't
find anything stating that a physical connection between two devices was
required (but I may be misinterpreting that document)

[1]:
https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/graph.txt

> 
> > <example_start>
> > 
> > <example_end>
> > 
> > Would this be conformant to OF graph and usb-connector bindings
> > requirements? We'll certainly send out a format PATCH/RFC series for
> > this, but I was hoping to gauge whether we're thinking along the right lines.
> > 
> > So, in effect this would mean:
> > - New bindings(and compatible strings) to be added for:
> >   typec-{orientation,data-role,mode}-switch.
> > - Handling in Type C connector class to parse switches from OF graph.
> > - Handling in Type C connector class for distinct switches for port@1
> >   (SS lines) and port@2 (SBU lines).
> > 
> > The only thing I'm confused about is how we can define these switch
> > remote-endpoint bindings in usb-connector.yaml; the port can have an
> > remote-endpoint, but can we specify what the parent of the remote-endpoint
> > should have as a compatible string? Or do we not need to?
> 
> thanks,
> 
> -- 
> heikki

Best regards,

-Prashant