Date:   Thu, 14 Nov 2019 13:00:42 -0800
From:   Jon Flatley <jflat@...omium.org>
To:     Heikki Krogerus <heikki.krogerus@...ux.intel.com>
Cc:     Jon Flatley <jflat@...omium.org>, Benson Leung <bleung@...gle.com>,
        enric.balletbo@...labora.com,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Benson Leung <bleung@...omium.org>, groeck@...omium.org,
        sre@...nel.org, Prashant Malani <pmalani@...omium.org>
Subject: Re: [PATCH 0/3] ChromeOS EC USB-C Connector Class

On Thu, Nov 14, 2019 at 7:24 AM Heikki Krogerus
<heikki.krogerus@...ux.intel.com> wrote:
>
> Hi Jon,
>
> On Wed, Nov 13, 2019 at 05:09:56PM -0800, Jon Flatley wrote:
> > > I'll go over these tomorrow, but I have one question already. Can you
> > > guys influence what goes to the ACPI tables?
> > >
> > > Ideally every Type-C connector is always described in its own ACPI
> > > node (or DT node if DT is used). Otherwise getting the correct
> > > capabilities and especially connections to other devices (like the
> > > muxes) for every port may get difficult.
> >
> > Hey Heikki, thank you for your quick response!
> >
> > In general we do have control over the ACPI tables and over DT. The
> > difference for ChromeOS is that the PD implementation and policy
> > decisions are handled by the embedded controller. This includes
> > alternate mode transitions and control over the muxes. I don't believe
> > there is any information about port capabilities in ACPI or DT, that's
> > all handled by the EC. With current EC firmware we are mostly limited
> > to querying the EC for port capabilities and state. There may be some
> > exceptions to this, such as with Rockchip platforms, but even then the
> > EC is largely in control.
>
> The capabilities here mean things like is the port: source, sink or
> DRP; host, device or DRD; etc. So static information.
>
> I do understand that the EC is in control of the Port Controller (or
> PD controller), the muxes, the policy decisions and what have you, and
> that is fine. My point is that the operating system should not have to
> get also the hardware description from the EC. That part should always
> come from ACPI tables or DT, even when the components are attached to
> the EC instead of the host CPU. Otherwise we loose scalability for no
> good reason.
>
> Note. The device properties for the port capabilities are already
> documented in kernel:
> Documentation/devicetree/bindings/connector/usb-connector.txt (the
> same properties work in ACPI as well).
>
> > I think you raise a valid point, but such a change is probably out of
> > scope for this implementation.
>
> This implementation should already be made so that it works with a
> properly prepared ACPI tables or DT. If there are already boards that
> don't supply the nodes in ACPI tables for the ports, then software
> nodes can be used with those, but all new boards really should have a
> real firmware node represeting every Type-C port.

Hey Heikki,

I spoke with Benson and Prashant and you raise a good point. Moving
forward we should probably be describing these capabilities in ACPI.
We do want to support existing devices, and making changes to the ACPI
tables would mean firmware modifications for each and every one, which
is a complicated process.

To date the port capabilities on all ChromeOS devices have been the
same. I recall now that we don't (and with current firmware can't)
query the port capabilities from the EC; they're just hard coded into
the driver. In the absence of these nodes in the ACPI tables we can
populate these capabilities in software nodes. This would allow us to
support existing systems without the expensive firmware change, and I
think it still provides the scalability you're asking for.

Are you suggesting that every port on the device gets its own ACPI/DT node?

Thanks,
-Jon

>
> thanks,

>
> --
> heikki

Powered by blists - more mailing lists