linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
To: Stephen Boyd <swboyd@chromium.org>
Cc: Prashant Malani <pmalani@chromium.org>,
	linux-kernel@vger.kernel.org, enric.balletbo@collabora.com,
	bleung@chromium.org, devicetree@vger.kernel.org,
	Guenter Roeck <groeck@chromium.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Rob Herring <robh+dt@kernel.org>
Subject: Re: [PATCH v3 1/4] dt-bindings: Add cros-ec Type C port driver
Date: Thu, 27 Feb 2020 18:38:25 +0200	[thread overview]
Message-ID: <20200227163825.GB18240@kuha.fi.intel.com> (raw)
In-Reply-To: <158279287307.177367.4599344664477592900@swboyd.mtv.corp.google.com>

Hi Stephen,

On Thu, Feb 27, 2020 at 12:41:13AM -0800, Stephen Boyd wrote:
> > +examples:
> > +  - |+
> > +    cros_ec: ec@0 {
> > +      compatible = "google,cros-ec-spi";
> > +
> > +      typec {
> > +        compatible = "google,cros-ec-typec";
> > +
> > +        usb_con: connector {
> > +          compatible = "usb-c-connector";
> > +          port-number = <0>;
> > +          power-role = "dual";
> > +          data-role = "dual";
> > +          try-power-role = "source";
> > +        };
> 
> I thought that perhaps this would be done with the OF graph APIs instead
> of being a child of the ec node. I don't see how the usb connector is
> anything besides a child of the top-level root node because it's
> typically on the board. We put board level components at the root.

No.

The above follows the usb-connector bindings, so it is correct:
Documentation/devicetree/bindings/connector/usb-connector.txt

So the connector is always a child of the "CC controller" with the USB
Type-C connectors, which in this case is the EC (from operating systems
perspective). The "CC controller" controls connectors, and it doesn't
actually do anything else. So placing the connectors under the
"connector controller" is also logically correct.

> Yes, the connector is intimately involved with the EC here, but I would
> think that we would have an OF graph connection from the USB controller
> on the SoC to the USB connector, traversing through anything that may be
> in that path, such as a USB hub. Maybe the connector node itself can
> point to the EC type-c controller with some property like

I think your idea here is that there should be only a single node for
each connector that is then linked with every component that it is
physically connected to (right?), but please note that that is not
enough. Every component attached to the connector must have its own
child node that represents the "port" that is physically connected to
the USB Type-C connector.

So for example, the USB controller nodes have child nodes for every
USB2 port as well as for every USB3 port. Similarly, the GPU
controllers have child node for every DisplayPort, etc. And I believe
that is already how it has been done in DT (and also in ACPI).

Those "port" nodes then just need to be linked with the "connector"
node. I think for that the idea was to use OF graph, but I'm really
sceptical about that. The problem is that with the USB Type-C
connectors we have to be able to identify the connections, i.e. which
endpoint is the USB2 port, which is the DisplayPort and so on, and OF
graph does not give any means to do that on its own. We will have to
rely on separate device properties in order to do the identification.
Currently it is not documented anywhere which property should be used
for that.

For ACPI we are going to propose that with every type of connection,
there should be a device property that returns a reference to the
appropriate port. That way there are no problems identifying the
connections. All we need to do is to define the property names for
every type of connection. "usb2-port" for the USB2 or high speed port,
"usb3-port" for USB3, etc.


thanks,

-- 
heikki

  reply	other threads:[~2020-02-27 16:38 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-20  0:30 [PATCH v3 0/4] platform/chrome: Add Type C connector class driver Prashant Malani
2020-02-20  0:30 ` [PATCH v3 1/4] dt-bindings: Add cros-ec Type C port driver Prashant Malani
2020-02-27  8:41   ` Stephen Boyd
2020-02-27 16:38     ` Heikki Krogerus [this message]
2020-02-27 22:07       ` Stephen Boyd
2020-02-28 16:24         ` Heikki Krogerus
2020-02-29  0:43           ` Stephen Boyd
2020-03-05 16:57             ` Heikki Krogerus
2020-02-27 15:12   ` Heikki Krogerus
2020-02-27 23:15     ` Rob Herring
2020-03-04 17:53       ` Prashant Malani
2020-02-20  0:30 ` [PATCH v3 2/4] platform/chrome: Add Type C connector class driver Prashant Malani
2020-02-27 14:25   ` Heikki Krogerus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200227163825.GB18240@kuha.fi.intel.com \
    --to=heikki.krogerus@linux.intel.com \
    --cc=bleung@chromium.org \
    --cc=devicetree@vger.kernel.org \
    --cc=enric.balletbo@collabora.com \
    --cc=groeck@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=pmalani@chromium.org \
    --cc=robh+dt@kernel.org \
    --cc=swboyd@chromium.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).