devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mats Karrman <mats.dev.list@gmail.com>
To: Heikki Krogerus <heikki.krogerus@linux.intel.com>,
	Hans de Goede <hdegoede@redhat.com>,
	Andrzej Hajda <a.hajda@samsung.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-usb@vger.kernel.org, devicetree@vger.kernel.org
Subject: USB role switches, usb-connector, typec and device trees
Date: Wed, 6 Jun 2018 23:36:49 +0200	[thread overview]
Message-ID: <6c379a23-5c63-9b49-9444-e16d6a8082a6@gmail.com> (raw)

Hello Gentlemen,

I'm trying to get my head around USB role switches in connection with Type-C ports
and device-trees. So far I have not found much documentation, e.g. there are no
device-tree bindings documented and really no good examples in existing device
trees, although there has been some attempts, e.g. [1] and [2]. Anyway, so I send
you a couple of questions instead:

1) tcpm uses the port device struct to find a single usb_role_switch but there is
room for three USB busses in the Type-C connector; one high speed and two (?) super-
speed. These would not all come from the same controller (there might even be
separate controllers for host and device mode for each bus).
The case I am working on now only have a single USB2 otg controller so it should
be possible to make that driver register a role switch but for other cases?
I imagine it would be possible to create a composite driver as a proxy for all role
switches but that would probably be different for every platform/product - not
very elegant. Could the role switch infrastructure be extended to handle arbitrary
sets of coordinated switches?

2) How should the connection between the Type-C port and the switches best be
expressed in a device tree? Using graph I presume, but should it be mixed into the
existing "usb-connector" or should this be a separate block?
I think it is unfortunate that the graph use numeric addresses that need to be
fixed by documentation and already I see problems with the current assignment
(0=HS, 1=SS, 2=SBU), e.g. if the host and device mode are handled by different
controllers. Graph do support multiple endpoints for one port but then we have
another level of magic numbers which does not exactly make things easier
(e.g. 0=dual or host controller, 1=device controller, 2=mode switch).

What are your thoughts on this? Please tell me I missed something and that there is
a simple solution :-)

BR // Mats

[1] https://www.spinics.net/lists/linux-usb/msg168071.html
[2] https://www.spinics.net/lists/linux-usb/msg168072.html


             reply	other threads:[~2018-06-06 21:36 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20180606213655epcas1p3e3f704633baa3100e28ff7e02ed85eab@epcas1p3.samsung.com>
2018-06-06 21:36 ` Mats Karrman [this message]
2018-06-07  7:22   ` USB role switches, usb-connector, typec and device trees Hans de Goede
2018-06-07 12:01     ` Heikki Krogerus
2018-06-12 17:16       ` Mats Karrman
2018-06-13 13:51         ` Heikki Krogerus
2018-06-15 21:51           ` Mats Karrman
2018-06-18 12:00             ` Heikki Krogerus
2018-06-07 11:40   ` Andrzej Hajda
2018-06-12 17:33     ` Mats Karrman
2018-06-13  7:06       ` Andrzej Hajda
2018-06-14 17:25         ` Mats Karrman

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=6c379a23-5c63-9b49-9444-e16d6a8082a6@gmail.com \
    --to=mats.dev.list@gmail.com \
    --cc=a.hajda@samsung.com \
    --cc=devicetree@vger.kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hdegoede@redhat.com \
    --cc=heikki.krogerus@linux.intel.com \
    --cc=linux-usb@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).