From: Sergei Shtylyov <sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
To: David Laight
<David.Laight-ZS65k/vG3HxXrIkS9f7CXA@public.gmane.org>,
'Ben Dooks' <ben.dooks-4yDnlxn2s6sWdaTGBSpHTA@public.gmane.org>,
Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>,
Alan Stern
<stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org>
Cc: "gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org"
<gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>,
"linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"Peter.Chen-KZfg59tc24xl57MIdRCFDg@public.gmane.org"
<Peter.Chen-KZfg59tc24xl57MIdRCFDg@public.gmane.org>,
"thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org"
<thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
"balbi-l0cyMroinI0@public.gmane.org"
<balbi-l0cyMroinI0@public.gmane.org>,
"linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"linux-sh-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-sh-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"magnus.damm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org"
<magnus.damm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Subject: Re: [PATCH 1/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'
Date: Thu, 10 Apr 2014 16:40:39 +0400 [thread overview]
Message-ID: <53469147.50802@cogentembedded.com> (raw)
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D0F6F44A4-VkEWCZq2GCInGFn1LkZF6NBPR1lH4CV8@public.gmane.org>
On 10-04-2014 15:14, David Laight wrote:
>>>>> It doesn't do any pin muxing. It switches SoC internal USB
>>>>> signals between
>>>>> USB controllers. The pins remain the same.
>>>> Doesn't something like that already happen for the companion USB1
>>>> controllers for USB2 ports?
>>> Did you mean USB 1.1 and USB 2.0 controllers by USB1 and USB2?
> Yes.
> Why do you care which USB controller is driving the pins?
Because the controllers the driver switches between are not companions.
The multiplexing is between PCI EHCI/OHCI and Renesas USBHS (high speed device
controller in this case) controllers on port 0 and between PCI EHCI/OHCI and
non-PCI xHCI controller on port 2.
>>>> That also doesn't sound like you are changing the PHY.
>>> I am changing one of the PHY registers that controls USB port
>>> (Renesas calls it channel) multiplexing.
>>>> I'd have thought that would happen if you had a single controller
>>>> that select between multiply PHY.
>>> No, it's not the case.
> I realised that wasn't what you were doing, but at first it did seem
> to be what you were doing.
The PHY really does belong to the USBHS controller but that multiplexing
register inside it controls routing of the ports 0 and 2; USBHS itself is on
port 0.
>> There is an interesting case, the USB3 shares a PHY with a SATA
>> and the PCIE and SATA also share a PHY on the R8A7790.
> Some of those look like pcb design decisions - so there is no dynamic
> changing, just config time plumbing.
No, there are also host/device mode DIP switches on the boards which
control port 0 signals (and the port 0 connector is micro-AB, so both a host
and device can be connected). The second board also has OTG chip on port 0
thru which USB ID pin can be read from the micro-AB connector.
> David
WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
To: David Laight
<David.Laight-ZS65k/vG3HxXrIkS9f7CXA@public.gmane.org>,
'Ben Dooks' <ben.dooks-4yDnlxn2s6sWdaTGBSpHTA@public.gmane.org>,
Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>,
Alan Stern
<stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org>
Cc: "gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org"
<gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>,
"linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"Peter.Chen-KZfg59tc24xl57MIdRCFDg@public.gmane.org"
<Peter.Chen-KZfg59tc24xl57MIdRCFDg@public.gmane.org>,
"thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org"
<thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
"balbi-l0cyMroinI0@public.gmane.org"
<balbi-l0cyMroinI0@public.gmane.org>,
"linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"linux-sh-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-sh-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"magnus.damm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org"
<magnus.damm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Subject: Re: [PATCH 1/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'
Date: Thu, 10 Apr 2014 12:40:39 +0000 [thread overview]
Message-ID: <53469147.50802@cogentembedded.com> (raw)
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D0F6F44A4-VkEWCZq2GCInGFn1LkZF6NBPR1lH4CV8@public.gmane.org>
On 10-04-2014 15:14, David Laight wrote:
>>>>> It doesn't do any pin muxing. It switches SoC internal USB
>>>>> signals between
>>>>> USB controllers. The pins remain the same.
>>>> Doesn't something like that already happen for the companion USB1
>>>> controllers for USB2 ports?
>>> Did you mean USB 1.1 and USB 2.0 controllers by USB1 and USB2?
> Yes.
> Why do you care which USB controller is driving the pins?
Because the controllers the driver switches between are not companions.
The multiplexing is between PCI EHCI/OHCI and Renesas USBHS (high speed device
controller in this case) controllers on port 0 and between PCI EHCI/OHCI and
non-PCI xHCI controller on port 2.
>>>> That also doesn't sound like you are changing the PHY.
>>> I am changing one of the PHY registers that controls USB port
>>> (Renesas calls it channel) multiplexing.
>>>> I'd have thought that would happen if you had a single controller
>>>> that select between multiply PHY.
>>> No, it's not the case.
> I realised that wasn't what you were doing, but at first it did seem
> to be what you were doing.
The PHY really does belong to the USBHS controller but that multiplexing
register inside it controls routing of the ports 0 and 2; USBHS itself is on
port 0.
>> There is an interesting case, the USB3 shares a PHY with a SATA
>> and the PCIE and SATA also share a PHY on the R8A7790.
> Some of those look like pcb design decisions - so there is no dynamic
> changing, just config time plumbing.
No, there are also host/device mode DIP switches on the boards which
control port 0 signals (and the port 0 connector is micro-AB, so both a host
and device can be connected). The second board also has OTG chip on port 0
thru which USB ID pin can be read from the micro-AB connector.
> David
WBR, Sergei
next prev parent reply other threads:[~2014-04-10 12:40 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-09 13:57 [PATCH 1/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver' Sergei Shtylyov
2014-04-09 13:57 ` Sergei Shtylyov
2014-04-09 15:31 ` Stephen Warren
2014-04-09 15:31 ` Stephen Warren
2014-04-09 16:27 ` Sergei Shtylyov
2014-04-09 16:27 ` Sergei Shtylyov
2014-04-09 16:48 ` Stephen Warren
2014-04-09 16:48 ` Stephen Warren
[not found] ` <534579D5.10306-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2014-04-09 16:53 ` Sergei Shtylyov
2014-04-09 16:53 ` Sergei Shtylyov
2014-04-09 17:37 ` Stephen Warren
2014-04-09 17:37 ` Stephen Warren
2014-04-09 17:52 ` Sergei Shtylyov
2014-04-09 17:52 ` Sergei Shtylyov
2014-04-09 17:56 ` Alan Stern
2014-04-09 17:56 ` Alan Stern
2014-04-09 18:16 ` Sergei Shtylyov
2014-04-09 18:16 ` Sergei Shtylyov
[not found] ` <53458E95.4080505-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
2014-04-09 19:01 ` Stephen Warren
2014-04-09 19:01 ` Stephen Warren
[not found] ` <534598EF.3010102-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2014-04-09 19:06 ` Sergei Shtylyov
2014-04-09 19:06 ` Sergei Shtylyov
2014-04-10 9:20 ` David Laight
2014-04-10 10:49 ` Sergei Shtylyov
2014-04-10 10:49 ` Sergei Shtylyov
2014-04-10 11:01 ` Ben Dooks
2014-04-10 11:01 ` Ben Dooks
2014-04-10 11:14 ` David Laight
2014-04-10 11:20 ` Ben Dooks
2014-04-10 11:20 ` Ben Dooks
[not found] ` <063D6719AE5E284EB5DD2968C1650D6D0F6F44A4-VkEWCZq2GCInGFn1LkZF6NBPR1lH4CV8@public.gmane.org>
2014-04-10 12:40 ` Sergei Shtylyov [this message]
2014-04-10 12:40 ` Sergei Shtylyov
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=53469147.50802@cogentembedded.com \
--to=sergei.shtylyov-m4dtvfq/zs1mrggop+s0pdbpr1lh4cv8@public.gmane.org \
--cc=David.Laight-ZS65k/vG3HxXrIkS9f7CXA@public.gmane.org \
--cc=Peter.Chen-KZfg59tc24xl57MIdRCFDg@public.gmane.org \
--cc=balbi-l0cyMroinI0@public.gmane.org \
--cc=ben.dooks-4yDnlxn2s6sWdaTGBSpHTA@public.gmane.org \
--cc=gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org \
--cc=linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-sh-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=magnus.damm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org \
--cc=swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org \
--cc=thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.