From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
To: Hans de Goede <hdegoede@redhat.com>
Cc: Darren Hart <dvhart@infradead.org>,
Andy Shevchenko <andy@infradead.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Guenter Roeck <linux@roeck-us.net>,
platform-driver-x86@vger.kernel.org, linux-usb@vger.kernel.org
Subject: Re: [PATCH 2/3] usb: typec: tcpm: Add support for configuring DP altmode through device-properties
Date: Mon, 21 Oct 2019 09:55:49 +0300 [thread overview]
Message-ID: <20191021065549.GA28049@kuha.fi.intel.com> (raw)
In-Reply-To: <20191018195719.94634-2-hdegoede@redhat.com>
Hi Hans,
On Fri, Oct 18, 2019 at 09:57:18PM +0200, Hans de Goede wrote:
> Add support for configuring display-port altmode through device-properties.
>
> We could try to add a generic mechanism for describing altmodes in
> device-properties, but various altmodes will likely need altmode specific
> configuration. E.g. the display-port altmode needs some way to describe
> which set of DP pins on the GPU is connected to the USB Type-C connector.
>
> As such it is better to have a separate set of altmode specific properties
> per altmode and this commit adds a property for basic display-port altmode
> support.
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
> .../bindings/connector/usb-connector.txt | 3 ++
> drivers/usb/typec/tcpm/tcpm.c | 33 +++++++++++++++++++
> 2 files changed, 36 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/connector/usb-connector.txt b/Documentation/devicetree/bindings/connector/usb-connector.txt
> index d357987181ee..7bae3cc9c76a 100644
> --- a/Documentation/devicetree/bindings/connector/usb-connector.txt
> +++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
> @@ -38,6 +38,9 @@ Optional properties for usb-c-connector:
> or Try.SRC, should be "sink" for Try.SNK or "source" for Try.SRC.
> - data-role: should be one of "host", "device", "dual"(DRD) if typec
> connector supports USB data.
> +- displayport-vdo: The presenence of this property indicates that the
> + usb-connector supports displayport-altmode (svid 0xff01), the value of
> + this property is an u32 with the vdo value for the displayport-altmode,
No, let's not take this approach.
Every alternate mode a connector supports will need to have its own
"sub-fwnode" under the connector fwnode. I thought we agreed this
earlier?
In any case, those sub-nodes will have default device properties named
"svid" and "vdo". If the alternate mode still needs some other
details, it can have other device properties that are specific to it,
but note that displayport alt mode does not need anything extra. The
"vdo" will already tells which pin configurations the connector
supports and that is all that the driver needs to know.
After we have the sub-nodes, it's not a big deal to walk through the
child-nodes the port has during port registration and register the
port alternate modes at the same time. That we can do in
typec_register_port(), so we do not need to do it in every driver
separately.
thanks,
--
heikki
next prev parent reply other threads:[~2019-10-21 6:55 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-18 19:57 [PATCH 1/3] usb: typec: tcpm: Remove tcpc_config configuration mechanism Hans de Goede
2019-10-18 19:57 ` [PATCH 2/3] usb: typec: tcpm: Add support for configuring DP altmode through device-properties Hans de Goede
2019-10-20 23:55 ` Guenter Roeck
2019-10-21 6:55 ` Heikki Krogerus [this message]
2019-11-14 11:16 ` Hans de Goede
2019-11-15 14:07 ` Heikki Krogerus
2019-10-18 19:57 ` [PATCH 3/3] platform/x86/intel_cht_int33fe: Add displayport-vdo property to the connector node Hans de Goede
2019-10-20 23:47 ` [PATCH 1/3] usb: typec: tcpm: Remove tcpc_config configuration mechanism Guenter Roeck
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=20191021065549.GA28049@kuha.fi.intel.com \
--to=heikki.krogerus@linux.intel.com \
--cc=andy@infradead.org \
--cc=dvhart@infradead.org \
--cc=gregkh@linuxfoundation.org \
--cc=hdegoede@redhat.com \
--cc=linux-usb@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=platform-driver-x86@vger.kernel.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).