From: Stephen Warren <swarren@wwwdotorg.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] ARM: tegra: TrimSlice: add support for USB1 port
Date: Fri, 02 Nov 2012 10:06:58 -0600 [thread overview]
Message-ID: <5093EFA2.9000007@wwwdotorg.org> (raw)
In-Reply-To: <1351870215.19243.10.camel@tellur>
On 11/02/2012 09:30 AM, Lucas Stach wrote:
> Am Freitag, den 02.11.2012, 08:45 -0600 schrieb Stephen Warren:
>> On 11/01/2012 05:34 PM, Lucas Stach wrote:
>>> Am Donnerstag, den 01.11.2012, 17:30 -0600 schrieb Stephen Warren:
>>>> On 11/01/2012 05:17 PM, Lucas Stach wrote:
>>>>> Hi Stephen,
>>>>>
>>>>> Am Donnerstag, den 01.11.2012, 16:14 -0600 schrieb Stephen Warren:
>>>>>> From: Stephen Warren <swarren@nvidia.com>
>>>>>>
>>>>>> TrimSlice's USB1 port has two purposes; it either acts as a device port
>>>>>> hosting Tegra's USB recovery protocol, or acts as a host port connected
>>>>>> to the internal USB->SATA bridge chip, which may in turn be connected to
>>>>>> an SSD or HDD. Add the appropriate device tree and board configuration
>>>>>> options to enable this port as a host port, and route the port to the
>>>>>> SATA bridge using the VBUS GPIO.
>>>>>>
>>>>> Hm, I don't really like to abuse the VBUS GPIO for this function. As the
>>>>> GPIO controlled routing is more a sort of pinmux can't you just add the
>>>>> GPIO enable to pin_mux_usb()?
>>>>
>>>> I don't know, I think it's fine. It's certainly this way in the kernel.
>>>> And for all I know, this GPIO does actually affect VBUS as well as
>>>> flipping any mux (and the more I think about that, the more likely it
>>>> is) although I can't actually know for sure since I don't have the
>>>> schematics.
>>>
>>> If it's really triggering VBUS I'm fine with this, but then the comment
>>> in pin_mux_usb() is a bit off.
>>
>> Sorry, I don't see anything inaccurate about it. What's wrong?
>
> In which way is it "masquerades as a VBUS GPIO"? If it triggers VBUS it
> _is_ a VBUS GPIO. So the comment should rather state that switching on
> VBUS also muxes the port to the internal bridge.
The GPIO definitely flips some form of bus mux. It's unclear whether it
is a also VBUS GPIO for the internal device or not. My suspicion is that
it must be, but without schematics I can't confirm. Either way, the
comment seems quite accurate and descriptive, and this seems a perfectly
reasonable solution.
next prev parent reply other threads:[~2012-11-02 16:06 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-01 22:14 [U-Boot] [PATCH] ARM: tegra: TrimSlice: add support for USB1 port Stephen Warren
2012-11-01 23:17 ` Lucas Stach
2012-11-01 23:30 ` Stephen Warren
2012-11-01 23:34 ` Lucas Stach
2012-11-02 14:45 ` Stephen Warren
2012-11-02 15:30 ` Lucas Stach
2012-11-02 16:06 ` Stephen Warren [this message]
2012-11-02 2:14 ` Simon Glass
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=5093EFA2.9000007@wwwdotorg.org \
--to=swarren@wwwdotorg.org \
--cc=u-boot@lists.denx.de \
/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.