Re: USB Type-C hub detection is flaky

[Timur Kristóf]

On Thu, 2018-07-05 at 15:58 +0300, Heikki Krogerus wrote:

> > > 
> > > Did you have a change to test if the problem can be reproduced in
> > > Windows too?
> > 
> > Sorry, not yet but I will get around to it next week.
> > (The XPS is my primary work machine so I will have to back up
> > everything before trying my luck with Windows.)
> 
> Oh, ic. In that case, perhaps somebody else could test this with
> Windows?
> 
> Mario! Can you guys test if self powered USB hubs get enumerated
> normally in Windows on XPS 9370?
> 

Hi Heikki & Mario,

Have you guys managed to test this under Windows?
If not, I can still do it.

Thanks & best regards,
Tim

Re: USB Type-C hub detection is flaky

[Timur Kristóf]

Hi Heikki,

On Fri, 2018-06-29 at 14:42 +0300, Heikki Krogerus wrote:
> Hi Tim,
> 
> On Tue, Jun 26, 2018 at 02:10:57PM +0200, Timur Krist?f wrote:
> > > Can you send the dmesg output after you have plugged the powered
> > > and
> > > non-powered hubs:
> > 
> > Right now I have the Dell Type-C to USB 3.0 Type-A adapter with the
> > USB
> > 2.0 hub here. There is a Logitech received plugged into the hub.
> > (So I
> > can quickly see if it works or not.)
> > 
> > After some trial-and-error I figured out when it works and when
> > not.
> > Tests were performed on Fedora 28 with kernel 4.17.2.
> > 
> > Basically it always works just on the first try. In other words,
> > when I
> > power up the USB 2.0 hub and plug it in, then it works. If I plug
> > it
> > out, but keep it powered and plug it back in again, it stops
> > working.
> 
> I wonder if the PD controller or EC firmware is seeing the
> disconnection. Perhaps we can test it.

How does the PD controller come into the picture?
(Assuming you mean PD = Power Delivery?)

The device I was talking about does not (and should not) deliver any
power to the laptop. Again this is a powered USB 2.0 hub with the Dell
Type-C to Type-A adapter, so it does not support PD.

(Next week I will buy a Type-C hub with PD support so will be able to
test with that too.)

> 
> Can you check if have the USB Type-C ports and partners in sysfs
> folder /sys/class/typec?
> 
> % ls /sys/class/typec/
> port0  port0-partner port1

On kernel 4.17.2 (as packaged by Fedora 28), that directory is empty,
even though I have something plugged in to all ports.

> It may be that you need to cherry-pick a few patches from Greg's
> tree [1][2] that fix an issue we had with the UCSI device on those
> Dell laptops. Can you build your own kernel?
> 
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/co
> mmit/?h=usb-linus=d2d2e3c46be5d6dd8001d0eebdf7cafb9bc7006b
> [2] https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/co
> mmit/?h=usb-linus=1f9f9d168ce619608572b01771c47a41b15429e6

How I usually build a kernel is I just use Fedora's config and tools,
ie. I patch the latest Fedora kernel and build it using 'fedpkg'
locally. Hope this approach is OK.

Now I got the latest from the f28 branch (which is 4.17.3 with some
patches). I added the two patches from above.

With the patched kernel, the directory is non-empty but it does not
correctly react to hotplugging and unplugging.

> But if you can see the ports and partners under that sysfs folder,
> after you unplug the device, does the port-partner disappears?

When I have something in every port on bootup I see this:

$ ls /sys/class/typec/
port0  port0-partner  port1  port1-partner  port2  port2-partner

But when I boot the machine with nothing plugged in, and then plug the
things in later:

- Type-C adapter with the USB 2.0 hub does not get a "partner" when it
is hotplugged, only when it is plugged in at boot time. The partner
correctly disappears when I plug it out but never appears again.

- Type-C charger appears as a "partner" when hot-plugged, but the
partner does not disappear even if I plug it out. Despite this,
charging continues to work when I plug it back in to any port. Though
no other partner gets created when I plug it into a different port.

Note that despite the presence of the "partner" Linux still recognizes
that the laptop is not charging, when the charger is plugged out.

- Type-C to DisplayPort adapter also shows up as a partner only when it
is present at boot time. Otherwise not. However it still works with any
of the three Type-C ports.

> 
> > If it was plugged into another computer but kept powered, it does
> > not
> > work with this laptop either. (Until I power the hub off and on
> > again.)
> > 
> > It appears that the Thunderbolt and non-Thunderbolt ports behave
> > slightly differently, and the same testcases leave wildly different
> > messages in dmesg. So I will describe what I did and what output I
> > got
> > from dmesg.
> 
> Did you have a change to test if the problem can be reproduced in
> Windows too?

Sorry, not yet but I will get around to it next week.
(The XPS is my primary work machine so I will have to back up
everything before trying my luck with Windows.)

> FYI. I'll be travelling next week, so expect delays in my answers.

I hope you have a great time!

Best regards,
Tim
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB Type-C hub detection is flaky

[Timur Kristóf]

On Tue, 2018-06-26 at 13:52 +0300, Heikki Krogerus wrote:
> On Tue, Jun 26, 2018 at 12:10:56PM +0200, Timur Krist?f wrote:
> > On Tue, 2018-06-26 at 11:29 +0300, Heikki Krogerus wrote:
> > > On Mon, Jun 25, 2018 at 01:09:32PM +0200, Timur Krist?f wrote:
> > > > On Mon, 2018-06-25 at 13:11 +0300, Heikki Krogerus wrote:
> > > > > +Mika
> > > > > 
> > > > > On Fri, Jun 22, 2018 at 10:12:10AM +0200, Timur Krist?f
> > > > > wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > I have a Dell XPS 13 9370, which has just Type-C ports.
> > > > > > Currently
> > > > > > running kernel 4.17.2. I found that plugging in a powered
> > > > > > USB
> > > > > > hub
> > > > > > into
> > > > > > the Type-C port does not work.
> > > > > > 
> > > > > > Please let me know if this isn't the correct place to
> > > > > > report
> > > > > > this
> > > > > > problem. Not sure if this is a Dell-specific issue or a
> > > > > > Linux-
> > > > > > specific
> > > > > > issue, so I'm also CCing Mario from Dell.
> > > > > > 
> > > > > > The following test cases were tried:
> > > > > > 
> > > > > > 1. When I plug in the hub to the laptop, and then plug in
> > > > > > the
> > > > > > peripherals, it works as expected. (This is OK.)
> > > > > > 
> > > > > > 2. But when I plug peripherals into the hub, and then plug
> > > > > > it
> > > > > > into
> > > > > > the
> > > > > > laptop, it takes at least 10-30 seconds to detect them.
> > > > > > (Until
> > > > > > then
> > > > > > they don't show up in lsusb.)
> > > > > > 
> > > > > > 3. If the hub is powered and power is connected to the hub
> > > > > > before
> > > > > > plugging it in, it is not detected at all. Sometimes it is
> > > > > > detected
> > > > > > after being plugged in for a very long time, but not
> > > > > > always.
> > > > > > 
> > > > > > I tried with various different configurations:
> > > > > > 
> > > > > > A. Dell USB Type-C to Type-A adapter with a Speedlink USB
> > > > > > 2.0
> > > > > > hub.
> > > > > > 
> > > > > > B. Same Dell C-to-A adapter with the built-in USB 2.0 hub
> > > > > > of a
> > > > > > Dell
> > > > > > P2414H monitor.
> > > > > > 
> > > > > > C. Qoltec USB Type-C to USB 3.0 hub
> > > > > > 
> > > > > > All of these exhibited the same behaviour. When the hub was
> > > > > > powered
> > > > > > before plugging it in, then they were not recognized at
> > > > > > all,
> > > > > > when
> > > > > > unpowered they were recognized in ~ 30 seconds (which is
> > > > > > still
> > > > > > too
> > > > > > long
> > > > > > though).
> > > > > > 
> > > > > > Note that the USB 2.0 hubs both worked correctly with other
> > > > > > machines
> > > > > > which just had a USB-A port. When plugged into a USB-A
> > > > > > port,
> > > > > > all
> > > > > > the
> > > > > > connected peripherals were immediately detected as soon as
> > > > > > the
> > > > > > hub
> > > > > > was
> > > > > > plugged in.
> > > > > > 
> > > > > > What might be the issue here? How can I help debug this
> > > > > > further?
> > > > > 
> > > > > This could be a problem with the Thunderbolt controller.
> > > > > Mika, do
> > > > > you
> > > > > know if there are any known problems when using self powered
> > > > > USB
> > > > > hubs?
> > > > > 
> > > > 
> > > > The issue also happens with the non-Thunderbolt USB Type-C
> > > > port, at
> > > > least on this laptop.
> &g

Re: USB Type-C hub detection is flaky

[Timur Kristóf]

On Tue, 2018-06-26 at 11:29 +0300, Heikki Krogerus wrote:
> On Mon, Jun 25, 2018 at 01:09:32PM +0200, Timur Krist?f wrote:
> > On Mon, 2018-06-25 at 13:11 +0300, Heikki Krogerus wrote:
> > > +Mika
> > > 
> > > On Fri, Jun 22, 2018 at 10:12:10AM +0200, Timur Krist?f wrote:
> > > > Hi,
> > > > 
> > > > I have a Dell XPS 13 9370, which has just Type-C ports.
> > > > Currently
> > > > running kernel 4.17.2. I found that plugging in a powered USB
> > > > hub
> > > > into
> > > > the Type-C port does not work.
> > > > 
> > > > Please let me know if this isn't the correct place to report
> > > > this
> > > > problem. Not sure if this is a Dell-specific issue or a Linux-
> > > > specific
> > > > issue, so I'm also CCing Mario from Dell.
> > > > 
> > > > The following test cases were tried:
> > > > 
> > > > 1. When I plug in the hub to the laptop, and then plug in the
> > > > peripherals, it works as expected. (This is OK.)
> > > > 
> > > > 2. But when I plug peripherals into the hub, and then plug it
> > > > into
> > > > the
> > > > laptop, it takes at least 10-30 seconds to detect them. (Until
> > > > then
> > > > they don't show up in lsusb.)
> > > > 
> > > > 3. If the hub is powered and power is connected to the hub
> > > > before
> > > > plugging it in, it is not detected at all. Sometimes it is
> > > > detected
> > > > after being plugged in for a very long time, but not always.
> > > > 
> > > > I tried with various different configurations:
> > > > 
> > > > A. Dell USB Type-C to Type-A adapter with a Speedlink USB 2.0
> > > > hub.
> > > > 
> > > > B. Same Dell C-to-A adapter with the built-in USB 2.0 hub of a
> > > > Dell
> > > > P2414H monitor.
> > > > 
> > > > C. Qoltec USB Type-C to USB 3.0 hub
> > > > 
> > > > All of these exhibited the same behaviour. When the hub was
> > > > powered
> > > > before plugging it in, then they were not recognized at all,
> > > > when
> > > > unpowered they were recognized in ~ 30 seconds (which is still
> > > > too
> > > > long
> > > > though).
> > > > 
> > > > Note that the USB 2.0 hubs both worked correctly with other
> > > > machines
> > > > which just had a USB-A port. When plugged into a USB-A port,
> > > > all
> > > > the
> > > > connected peripherals were immediately detected as soon as the
> > > > hub
> > > > was
> > > > plugged in.
> > > > 
> > > > What might be the issue here? How can I help debug this
> > > > further?
> > > 
> > > This could be a problem with the Thunderbolt controller. Mika, do
> > > you
> > > know if there are any known problems when using self powered USB
> > > hubs?
> > > 
> > 
> > The issue also happens with the non-Thunderbolt USB Type-C port, at
> > least on this laptop.
> 
> Ah, ic. XPS 9360 has two thunderbolt ports and a standard-A port on
> the other side. I can see that the standard-A port has been replaced
> with the USB Type-C port on XPS 9370.
> 

9360 (2017 model) has two USB 3.0 Type-A ports and one Thunderbolt 3
Type-C (with 2 PCI-E lanes).

9370 (2018 model) has one USB 3.1 Type-C, and two Thunderbolt 3 Type-C
ports (with 4 PCI-E lanes). No Type-A ports. This is what I've got.

> Are you able to test if the problem can been seen also in Windows?

I don't have Windows with this machine (it came with Ubuntu). But I
guess I could try with an evaluation version of Windows, if that is
helpful.

Thanks & best regards,
Tim

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB Type-C hub detection is flaky

[Timur Kristóf]

On Mon, 2018-06-25 at 13:11 +0300, Heikki Krogerus wrote:
> +Mika
> 
> On Fri, Jun 22, 2018 at 10:12:10AM +0200, Timur Krist?f wrote:
> > Hi,
> > 
> > I have a Dell XPS 13 9370, which has just Type-C ports. Currently
> > running kernel 4.17.2. I found that plugging in a powered USB hub
> > into
> > the Type-C port does not work.
> > 
> > Please let me know if this isn't the correct place to report this
> > problem. Not sure if this is a Dell-specific issue or a Linux-
> > specific
> > issue, so I'm also CCing Mario from Dell.
> > 
> > The following test cases were tried:
> > 
> > 1. When I plug in the hub to the laptop, and then plug in the
> > peripherals, it works as expected. (This is OK.)
> > 
> > 2. But when I plug peripherals into the hub, and then plug it into
> > the
> > laptop, it takes at least 10-30 seconds to detect them. (Until then
> > they don't show up in lsusb.)
> > 
> > 3. If the hub is powered and power is connected to the hub before
> > plugging it in, it is not detected at all. Sometimes it is detected
> > after being plugged in for a very long time, but not always.
> > 
> > I tried with various different configurations:
> > 
> > A. Dell USB Type-C to Type-A adapter with a Speedlink USB 2.0 hub.
> > 
> > B. Same Dell C-to-A adapter with the built-in USB 2.0 hub of a Dell
> > P2414H monitor.
> > 
> > C. Qoltec USB Type-C to USB 3.0 hub
> > 
> > All of these exhibited the same behaviour. When the hub was powered
> > before plugging it in, then they were not recognized at all, when
> > unpowered they were recognized in ~ 30 seconds (which is still too
> > long
> > though).
> > 
> > Note that the USB 2.0 hubs both worked correctly with other
> > machines
> > which just had a USB-A port. When plugged into a USB-A port, all
> > the
> > connected peripherals were immediately detected as soon as the hub
> > was
> > plugged in.
> > 
> > What might be the issue here? How can I help debug this further?
> 
> This could be a problem with the Thunderbolt controller. Mika, do you
> know if there are any known problems when using self powered USB
> hubs?
> 

The issue also happens with the non-Thunderbolt USB Type-C port, at
least on this laptop.

Tim
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

USB Type-C hub detection is flaky

[Timur Kristóf]

Hi,

I have a Dell XPS 13 9370, which has just Type-C ports. Currently
running kernel 4.17.2. I found that plugging in a powered USB hub into
the Type-C port does not work.

Please let me know if this isn't the correct place to report this
problem. Not sure if this is a Dell-specific issue or a Linux-specific
issue, so I'm also CCing Mario from Dell.

The following test cases were tried:

1. When I plug in the hub to the laptop, and then plug in the
peripherals, it works as expected. (This is OK.)

2. But when I plug peripherals into the hub, and then plug it into the
laptop, it takes at least 10-30 seconds to detect them. (Until then
they don't show up in lsusb.)

3. If the hub is powered and power is connected to the hub before
plugging it in, it is not detected at all. Sometimes it is detected
after being plugged in for a very long time, but not always.

I tried with various different configurations:

A. Dell USB Type-C to Type-A adapter with a Speedlink USB 2.0 hub.

B. Same Dell C-to-A adapter with the built-in USB 2.0 hub of a Dell
P2414H monitor.

C. Qoltec USB Type-C to USB 3.0 hub

All of these exhibited the same behaviour. When the hub was powered
before plugging it in, then they were not recognized at all, when
unpowered they were recognized in ~ 30 seconds (which is still too long
though).

Note that the USB 2.0 hubs both worked correctly with other machines
which just had a USB-A port. When plugged into a USB-A port, all the
connected peripherals were immediately detected as soon as the hub was
plugged in.

What might be the issue here? How can I help debug this further?

Thanks & best regards,
Tim


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] usb: xhci: force all memory allocations to node

[Timur Tabi]

On 5/22/18 1:55 PM, Adam Wallis wrote:

+   struct device *dev = xhci_to_hcd(xhci)->self.sysdev;


Since you only use 'dev' to get the NUMA node, you might want to 
consider this instead:


int node = dev_to_node(xhci_to_hcd(xhci)->self.sysdev);

--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc.  Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4] usb: xhci: allow imod-interval to be configurable

[Timur Tabi]

On 12/04/2017 09:48 AM, Adam Wallis wrote:

As noted in the patch description, xhci-plat devices will use a default of
40,000, while MTK devices will use a default of 5,000. This is also documented
in the probe for each relevant driver. This is further confirmed in the
description for each driver's binding TXT file.


Serves me right for reviewing patches before I've had my morning coffee.

--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc.  Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4] usb: xhci: allow imod-interval to be configurable

[Timur Tabi]

On 12/4/17 8:27 AM, Adam Wallis wrote:

If no interval is specified, the default of 40,000ns (IMOD=160) will be
used.


...


+ - imod-interval-ns: default interrupt moderation interval is 5000ns


...


+  - imod-interval-ns: default interrupt moderation interval is 5000ns


...


+   xhci->imod_interval = 5000;


...


+   xhci->imod_interval = 4;


...


+   xhci->imod_interval = 4;


Is the default 5,000 or 40,000?  I can't tell.

--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc.  Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4.10-rc3 08/13] net: emac: fix build errors when linux/phy*.h is removed from net/dsa.h

[Timur Tabi]

On 01/31/2017 01:19 PM, Russell King wrote:

drivers/net/ethernet/qualcomm/emac/emac-sgmii.c:58:12: error: dereferencing 
pointer to incomplete type 'struct phy_device'

Add linux/phy.h to emac-sgmii.c

Signed-off-by: Russell King 
---
 drivers/net/ethernet/qualcomm/emac/emac-sgmii.c | 1 +


The version of emac-sgmii.c on net-next does not need this fixed.  I already 
removed all references to phy_device in commit "net: qcom/emac: always use 
autonegotiation to configure the SGMII link".


--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc.  Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/6] usb: make xhci platform driver use 64 bit or 32 bit DMA

[Timur Tabi]

On Tue, Mar 8, 2016 at 8:59 AM, Timur Tabi <ti...@codeaurora.org> wrote:
>> +   /* Try setting the coherent_dma_mask to 64 bits, then try 32 bits
>> */
>> +   ret = dma_set_mask_and_coherent(>dev, DMA_BIT_MASK(64));
>> +   if (ret) {
>> +   ret = dma_set_mask_and_coherent(>dev,
>> DMA_BIT_MASK(32));
>> +   if (ret)
>> +   return ret;
>> +   }
>
>
> I still do not understand what situation would cause a 64-bit mask to fail,
> but a 32-bit mask to succeed.  If the driver says that the device can
> support 64-bit DMA, why would that ever fail?  That means that the device
> can DMA anywhere, so there are no restrictions.

Can anyone help me understand this?  It's been a month since I posted
this question, and I haven't gotten an answer.  I see the whole
try-64-and-then-32-bit-masks code in a number of places, but I've
never understood why it's necessary.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/6] usb: make xhci platform driver use 64 bit or 32 bit DMA

[Timur Tabi]

Mathias Nyman wrote:




Evolution of the patch can be found in this thread:

http://www.spinics.net/lists/linux-usb/msg128495.html

I think version 8 was the final one.


I couldn't find any answers to my questions in that thread.  The key 
change to the patch was made between v1 and v2:



+   /* Try setting the coherent_dma_mask to 64 bits, then try 32 bits */
+   ret = dma_set_mask_and_coherent(>dev, DMA_BIT_MASK(64));
+   if (ret) {
+   ret = dma_set_mask_and_coherent(>dev, DMA_BIT_MASK(32));
+   if (ret)
+   return ret;
+   }


I still do not understand what situation would cause a 64-bit mask to 
fail, but a 32-bit mask to succeed.  If the driver says that the device 
can support 64-bit DMA, why would that ever fail?  That means that the 
device can DMA anywhere, so there are no restrictions.


--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the
Code Aurora Forum, hosted by The Linux Foundation.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/6] usb: make xhci platform driver use 64 bit or 32 bit DMA

[Timur Tabi]

On Fri, Oct 9, 2015 at 5:30 AM, Mathias Nyman
 wrote:
> The xhci platform driver needs to work on systems that
> either only support 64-bit DMA or only support 32-bit DMA.
> Attempt to set a coherent dma mask for 64-bit DMA, and
> attempt again with 32-bit DMA if that fails.

I know this patch is a few months old and has already been merged, but
I have a question about how it works, because we're thinking about
doing something similar for another driver.

> +   /* Try to set 64-bit DMA first */
> +   if (WARN_ON(!pdev->dev.dma_mask))
> +   /* Platform did not initialize dma_mask */
> +   ret = dma_coerce_mask_and_coherent(>dev,
> +  DMA_BIT_MASK(64));
> else
> -   dma_set_mask(>dev, DMA_BIT_MASK(32));
> +   ret = dma_set_mask_and_coherent(>dev, DMA_BIT_MASK(64));
> +
> +   /* If seting 64-bit DMA mask fails, fall back to 32-bit DMA mask */
> +   if (ret) {
> +   ret = dma_set_mask_and_coherent(>dev, DMA_BIT_MASK(32));
> +   if (ret)
> +   return ret;
> +   }

I don't understand why this is necessary.  I was under the impression
that when a driver calls dma_set_mask_xxx, all it's doing is telling
the kernel what DMA ranges the device is capable of. If a device is
physically capable of DMA'ing to all of RAM (let's assume everything
is coherent), then it should set the mask to 64 and leave it at that.
If the platform has some other DMA address range limitation, the
driver shouldn't have to worry about that.  It should still set the
mask to 64, and something else will figure out that the *real* mask is
less than that.  Then when the driver calls dma_alloc_coherent(), it
will always get a DMA buffer from low memory, but that's okay.

But apparently, that's not how it really works, which is why this
patch exists.  And that's why I'm confused.

I have a few other related questions.  Let's say that we have a device
that is normally capable of 64-bit DMA.  But on one particular
platform, only 32 bits of the address bus is wired up, so effectively
the device is only capable of 32-bit DMA.  This information is hidden
from the device, so the driver cannot query the device itself to
discover this.  What is the proper way to handle this?  We probably
don't want to add platform-specific code to the driver (like an MIDR
check on ARM systems).

Thanks in advance for any answers.  DMA-API-HOWTO.txt says this:

"Rather, it may fail in this case simply because 32-bit
addressing is done more efficiently than 64-bit addressing."

But that doesn't apply in our situation.  And even then, this seems
like an odd reason to fail.  Wouldn't it make more sense for the
dma_set_mask_xxx() API to just automatically adjust the mask to a
smaller value, and return success?
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/5] [v2] usb: host: ehci-msm: Allow LS devices to work

[Timur Tabi]

Timur Tabi wrote:

From: Jack Pham <ja...@codeaurora.org>

Disable the silicon quirk which is normally enabled for HSIC
host mode. This would otherwise prevent low speed devices
from enumerating properly.

Signed-off-by: Jack Pham <ja...@codeaurora.org>
Signed-off-by: Timur Tabi <ti...@codeaurora.org>


Felipe, any change that these five patches can make it into 4.5?

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4/5] [v2] usb: host: ehci-msm: Fix register initialization

[Timur Tabi]

From: Jack Pham <ja...@codeaurora.org>

The default value for the 'transceiver select' field of
the PORTSC register may not always be correct. Previously
the phy-msm-usb driver would do this for us, but since
ehci-msm can now be instantiated standalone without any PHY
driver, the register needs to be explicitly initialized to
ULPI mode to properly communicate with the PHY.

This is not readily apparent, as firmware or bootloader code
also happen to pre-initialize this for us. However, it can
manifest when performing a driver unbind/rebind as follows:

 cd /sys/bus/platform/drivers/msm_hsusb_host
 echo QCOM8040:00 > unbind
 echo QCOM8040:00 > bind

The EHCI core executes a controller reset as part of this,
and as a result the register in question would revert to
its default state and must be re-initialized properly.
Furthermore this may be useful in the future when adding
PM suspend/resume support.

Signed-off-by: Jack Pham <ja...@codeaurora.org>
Signed-off-by: Timur Tabi <ti...@codeaurora.org>
---
 drivers/usb/host/ehci-msm.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/usb/host/ehci-msm.c b/drivers/usb/host/ehci-msm.c
index 102837e..b71947d 100644
--- a/drivers/usb/host/ehci-msm.c
+++ b/drivers/usb/host/ehci-msm.c
@@ -56,6 +56,8 @@ static int ehci_msm_reset(struct usb_hcd *hcd)
if (retval)
return retval;
 
+   /* select ULPI phy and clear other status/control bits in PORTSC */
+   writel(PORTSC_PTS_ULPI, USB_PORTSC);
/* bursts of unspecified length. */
writel(0, USB_AHBBURST);
/* Use the AHB transactor, allow posted data writes */
-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/5] [v2] usb: host: ehci-msm: Remove dependency on OTG PHY

[Timur Tabi]

From: Jack Pham <ja...@codeaurora.org>

Currently the EHCI MSM driver has a hard dependency to be created
by an OTG layer, namely the phy-msm-usb driver. In some cases or
board configurations we want to allow the EHCI host to be
instantiated without OTG capability. Instead, relax the dependency
on having an OTG PHY being present and call usb_add_hcd() directly.

Signed-off-by: Jack Pham <ja...@codeaurora.org>
Signed-off-by: Timur Tabi <ti...@codeaurora.org>
---
 drivers/usb/host/ehci-msm.c | 53 ++---
 1 file changed, 31 insertions(+), 22 deletions(-)

diff --git a/drivers/usb/host/ehci-msm.c b/drivers/usb/host/ehci-msm.c
index aed499d..e1004bc 100644
--- a/drivers/usb/host/ehci-msm.c
+++ b/drivers/usb/host/ehci-msm.c
@@ -106,9 +106,9 @@ static int ehci_msm_probe(struct platform_device *pdev)
}
 
/*
-* OTG driver takes care of PHY initialization, clock management,
-* powering up VBUS, mapping of registers address space and power
-* management.
+* If there is an OTG driver, let it take care of PHY initialization,
+* clock management, powering up VBUS, mapping of registers address
+* space and power management.
 */
if (pdev->dev.of_node)
phy = devm_usb_get_phy_by_phandle(>dev, "usb-phy", 0);
@@ -116,27 +116,35 @@ static int ehci_msm_probe(struct platform_device *pdev)
phy = devm_usb_get_phy(>dev, USB_PHY_TYPE_USB2);
 
if (IS_ERR(phy)) {
-   dev_err(>dev, "unable to find transceiver\n");
-   ret = -EPROBE_DEFER;
-   goto put_hcd;
-   }
-
-   ret = otg_set_host(phy->otg, >self);
-   if (ret < 0) {
-   dev_err(>dev, "unable to register with transceiver\n");
-   goto put_hcd;
+   if (PTR_ERR(phy) == -EPROBE_DEFER) {
+   dev_err(>dev, "unable to find transceiver\n");
+   ret = -EPROBE_DEFER;
+   goto put_hcd;
+   }
+   phy = NULL;
}
 
hcd->usb_phy = phy;
device_init_wakeup(>dev, 1);
-   /*
-* OTG device parent of HCD takes care of putting
-* hardware into low power mode.
-*/
-   pm_runtime_no_callbacks(>dev);
-   pm_runtime_enable(>dev);
 
-   /* FIXME: need to call usb_add_hcd() here? */
+   if (phy && phy->otg) {
+   /*
+* MSM OTG driver takes care of adding the HCD and
+* placing hardware into low power mode via runtime PM.
+*/
+   ret = otg_set_host(phy->otg, >self);
+   if (ret < 0) {
+   dev_err(>dev, "unable to register with 
transceiver\n");
+   goto put_hcd;
+   }
+
+   pm_runtime_no_callbacks(>dev);
+   pm_runtime_enable(>dev);
+   } else {
+   ret = usb_add_hcd(hcd, hcd->irq, IRQF_SHARED);
+   if (ret)
+   goto put_hcd;
+   }
 
return 0;
 
@@ -154,9 +162,10 @@ static int ehci_msm_remove(struct platform_device *pdev)
pm_runtime_disable(>dev);
pm_runtime_set_suspended(>dev);
 
-   otg_set_host(hcd->usb_phy->otg, NULL);
-
-   /* FIXME: need to call usb_remove_hcd() here? */
+   if (hcd->usb_phy && hcd->usb_phy->otg)
+   otg_set_host(hcd->usb_phy->otg, NULL);
+   else
+   usb_remove_hcd(hcd);
 
usb_put_hcd(hcd);
 
-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/5] [v2] usb: host: ehci-msm: Add support for ACPI probing

[Timur Tabi]

From: Jack Pham <ja...@codeaurora.org>

Allow the EHCI MSM driver to probe against an ACPI enumerated
device with ID QCOM8040.

Signed-off-by: Jack Pham <ja...@codeaurora.org>
Signed-off-by: Timur Tabi <ti...@codeaurora.org>
---
 drivers/usb/host/ehci-msm.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/usb/host/ehci-msm.c b/drivers/usb/host/ehci-msm.c
index e1004bc..102837e 100644
--- a/drivers/usb/host/ehci-msm.c
+++ b/drivers/usb/host/ehci-msm.c
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "ehci.h"
 
@@ -202,6 +203,12 @@ static const struct dev_pm_ops ehci_msm_dev_pm_ops = {
.resume  = ehci_msm_pm_resume,
 };
 
+static const struct acpi_device_id msm_ehci_acpi_ids[] = {
+   { "QCOM8040", 0 },
+   { }
+};
+MODULE_DEVICE_TABLE(acpi, msm_ehci_acpi_ids);
+
 static const struct of_device_id msm_ehci_dt_match[] = {
{ .compatible = "qcom,ehci-host", },
{}
@@ -215,6 +222,7 @@ static struct platform_driver ehci_msm_driver = {
   .name = "msm_hsusb_host",
   .pm = _msm_dev_pm_ops,
   .of_match_table = msm_ehci_dt_match,
+  .acpi_match_table = ACPI_PTR(msm_ehci_acpi_ids),
},
 };
 
-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/5] [v2] usb: host: ehci-msm: Allow LS devices to work

[Timur Tabi]

From: Jack Pham <ja...@codeaurora.org>

Disable the silicon quirk which is normally enabled for HSIC
host mode. This would otherwise prevent low speed devices
from enumerating properly.

Signed-off-by: Jack Pham <ja...@codeaurora.org>
Signed-off-by: Timur Tabi <ti...@codeaurora.org>
---
 drivers/usb/host/ehci-msm.c  | 2 ++
 include/linux/usb/msm_hsusb_hw.h | 1 +
 2 files changed, 3 insertions(+)

diff --git a/drivers/usb/host/ehci-msm.c b/drivers/usb/host/ehci-msm.c
index c23e285..aed499d 100644
--- a/drivers/usb/host/ehci-msm.c
+++ b/drivers/usb/host/ehci-msm.c
@@ -61,6 +61,8 @@ static int ehci_msm_reset(struct usb_hcd *hcd)
writel(0x8, USB_AHBMODE);
/* Disable streaming mode and select host mode */
writel(0x13, USB_USBMODE);
+   /* Disable ULPI_TX_PKT_EN_CLR_FIX which is valid only for HSIC */
+   writel(readl(USB_GENCONFIG_2) & ~ULPI_TX_PKT_EN_CLR_FIX, 
USB_GENCONFIG_2);
 
return 0;
 }
diff --git a/include/linux/usb/msm_hsusb_hw.h b/include/linux/usb/msm_hsusb_hw.h
index e159b39..974c379 100644
--- a/include/linux/usb/msm_hsusb_hw.h
+++ b/include/linux/usb/msm_hsusb_hw.h
@@ -22,6 +22,7 @@
 #define USB_AHBBURST (MSM_USB_BASE + 0x0090)
 #define USB_AHBMODE  (MSM_USB_BASE + 0x0098)
 #define USB_GENCONFIG_2  (MSM_USB_BASE + 0x00a0)
+#define ULPI_TX_PKT_EN_CLR_FIX BIT(19)
 
 #define USB_CAPLENGTH(MSM_USB_BASE + 0x0100) /* 8 bit */
 
-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 5/5] [v2] usb: host: ehci-msm: Register usb shutdown function

[Timur Tabi]

From: Azriel Samson <asam...@codeaurora.org>

Registering usb_hcd_platform_shutdown to be called during
shutdown. This is a generic function that performs the
generic host stack's shutdown. It ensures that USB
operations do not continue while kexec boots a new kernel.

Signed-off-by: Azriel Samson <asam...@codeaurora.org>
Signed-off-by: Timur Tabi <ti...@codeaurora.org>
---
 drivers/usb/host/ehci-msm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/host/ehci-msm.c b/drivers/usb/host/ehci-msm.c
index b71947d..3e226ef 100644
--- a/drivers/usb/host/ehci-msm.c
+++ b/drivers/usb/host/ehci-msm.c
@@ -220,6 +220,7 @@ MODULE_DEVICE_TABLE(of, msm_ehci_dt_match);
 static struct platform_driver ehci_msm_driver = {
.probe  = ehci_msm_probe,
.remove = ehci_msm_remove,
+   .shutdown = usb_hcd_platform_shutdown,
.driver = {
   .name = "msm_hsusb_host",
   .pm = _msm_dev_pm_ops,
-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] usb: host: ehci-msm: Use posted data writes on AHB

[Timur Tabi]

On Fri, Nov 6, 2015 at 12:04 AM, Andy Gross <agr...@codeaurora.org> wrote:
> This patch sets the AHBMODE to allow for posted data writes.  This
> results in higher performance.
>
> Signed-off-by: Andy Gross <agr...@codeaurora.org>

I know it's a little late, but ...

Acked-by: Timur Tabi <ti...@codeaurora.org>

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/5] usb: ehci-msm: Add support for ACPI probing

[Timur Tabi]

From: Jack Pham <ja...@codeaurora.org>

Allow the EHCI MSM driver to probe against an ACPI enumerated
device with ID QCOM8040.

Signed-off-by: Jack Pham <ja...@codeaurora.org>
Signed-off-by: Timur Tabi <ti...@codeaurora.org>
---
 drivers/usb/host/ehci-msm.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/usb/host/ehci-msm.c b/drivers/usb/host/ehci-msm.c
index 0a86b8e..fc666ef 100644
--- a/drivers/usb/host/ehci-msm.c
+++ b/drivers/usb/host/ehci-msm.c
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "ehci.h"
 
@@ -202,6 +203,12 @@ static const struct dev_pm_ops ehci_msm_dev_pm_ops = {
.resume  = ehci_msm_pm_resume,
 };
 
+static const struct acpi_device_id msm_ehci_acpi_ids[] = {
+   { "QCOM8040", 0 },
+   { }
+};
+MODULE_DEVICE_TABLE(acpi, msm_ehci_acpi_ids);
+
 static const struct of_device_id msm_ehci_dt_match[] = {
{ .compatible = "qcom,ehci-host", },
{}
@@ -215,6 +222,7 @@ static struct platform_driver ehci_msm_driver = {
   .name = "msm_hsusb_host",
   .pm = _msm_dev_pm_ops,
   .of_match_table = msm_ehci_dt_match,
+  .acpi_match_table = ACPI_PTR(msm_ehci_acpi_ids),
},
 };
 
-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 5/5] usb: ehci-msm: Register usb shutdown function

[Timur Tabi]

From: Azriel Samson <asam...@codeaurora.org>

Registering usb_hcd_platform_shutdown to be called during
shutdown. This is a generic function that performs the
generic host stack's shutdown. It ensures that USB
operations do not continue while kexec boots a new kernel.

Signed-off-by: Azriel Samson <asam...@codeaurora.org>
Signed-off-by: Timur Tabi <ti...@codeaurora.org>
---
 drivers/usb/host/ehci-msm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/host/ehci-msm.c b/drivers/usb/host/ehci-msm.c
index b8c0df0..cde3d18 100644
--- a/drivers/usb/host/ehci-msm.c
+++ b/drivers/usb/host/ehci-msm.c
@@ -220,6 +220,7 @@ MODULE_DEVICE_TABLE(of, msm_ehci_dt_match);
 static struct platform_driver ehci_msm_driver = {
.probe  = ehci_msm_probe,
.remove = ehci_msm_remove,
+   .shutdown = usb_hcd_platform_shutdown,
.driver = {
   .name = "msm_hsusb_host",
   .pm = _msm_dev_pm_ops,
-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/5] usb: ehci-msm: Remove dependency on OTG PHY

[Timur Tabi]

From: Jack Pham <ja...@codeaurora.org>

Currently the EHCI MSM driver has a hard dependency to be created
by an OTG layer, namely the phy-msm-usb driver. In some cases or
board configurations we want to allow the EHCI host to be
instantiated without OTG capability. Instead, relax the dependency
on having an OTG PHY being present and call usb_add_hcd() directly.

Signed-off-by: Jack Pham <ja...@codeaurora.org>
Signed-off-by: Timur Tabi <ti...@codeaurora.org>
---
 drivers/usb/host/ehci-msm.c | 53 ++---
 1 file changed, 31 insertions(+), 22 deletions(-)

diff --git a/drivers/usb/host/ehci-msm.c b/drivers/usb/host/ehci-msm.c
index d3ed6c9..0a86b8e 100644
--- a/drivers/usb/host/ehci-msm.c
+++ b/drivers/usb/host/ehci-msm.c
@@ -106,9 +106,9 @@ static int ehci_msm_probe(struct platform_device *pdev)
}
 
/*
-* OTG driver takes care of PHY initialization, clock management,
-* powering up VBUS, mapping of registers address space and power
-* management.
+* If there is an OTG driver, let it take care of PHY initialization,
+* clock management, powering up VBUS, mapping of registers address
+* space and power management.
 */
if (pdev->dev.of_node)
phy = devm_usb_get_phy_by_phandle(>dev, "usb-phy", 0);
@@ -116,27 +116,35 @@ static int ehci_msm_probe(struct platform_device *pdev)
phy = devm_usb_get_phy(>dev, USB_PHY_TYPE_USB2);
 
if (IS_ERR(phy)) {
-   dev_err(>dev, "unable to find transceiver\n");
-   ret = -EPROBE_DEFER;
-   goto put_hcd;
-   }
-
-   ret = otg_set_host(phy->otg, >self);
-   if (ret < 0) {
-   dev_err(>dev, "unable to register with transceiver\n");
-   goto put_hcd;
+   if (PTR_ERR(phy) == -EPROBE_DEFER) {
+   dev_err(>dev, "unable to find transceiver\n");
+   ret = -EPROBE_DEFER;
+   goto put_hcd;
+   }
+   phy = NULL;
}
 
hcd->usb_phy = phy;
device_init_wakeup(>dev, 1);
-   /*
-* OTG device parent of HCD takes care of putting
-* hardware into low power mode.
-*/
-   pm_runtime_no_callbacks(>dev);
-   pm_runtime_enable(>dev);
 
-   /* FIXME: need to call usb_add_hcd() here? */
+   if (phy && phy->otg) {
+   /*
+* MSM OTG driver takes care of adding the HCD and
+* placing hardware into low power mode via runtime PM.
+*/
+   ret = otg_set_host(phy->otg, >self);
+   if (ret < 0) {
+   dev_err(>dev, "unable to register with 
transceiver\n");
+   goto put_hcd;
+   }
+
+   pm_runtime_no_callbacks(>dev);
+   pm_runtime_enable(>dev);
+   } else {
+   ret = usb_add_hcd(hcd, hcd->irq, IRQF_SHARED);
+   if (ret)
+   goto put_hcd;
+   }
 
return 0;
 
@@ -154,9 +162,10 @@ static int ehci_msm_remove(struct platform_device *pdev)
pm_runtime_disable(>dev);
pm_runtime_set_suspended(>dev);
 
-   otg_set_host(hcd->usb_phy->otg, NULL);
-
-   /* FIXME: need to call usb_remove_hcd() here? */
+   if (hcd->usb_phy && hcd->usb_phy->otg)
+   otg_set_host(hcd->usb_phy->otg, NULL);
+   else
+   usb_remove_hcd(hcd);
 
usb_put_hcd(hcd);
 
-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/5] usb: ehci-msm: Allow LS devices to work

[Timur Tabi]

From: Jack Pham <ja...@codeaurora.org>

Disable the silicon quirk which is normally enabled for HSIC
host mode. This would otherwise prevent low speed devices
from enumerating properly.

Signed-off-by: Jack Pham <ja...@codeaurora.org>
Signed-off-by: Timur Tabi <ti...@codeaurora.org>
---
 drivers/usb/host/ehci-msm.c  | 2 ++
 include/linux/usb/msm_hsusb_hw.h | 1 +
 2 files changed, 3 insertions(+)

diff --git a/drivers/usb/host/ehci-msm.c b/drivers/usb/host/ehci-msm.c
index c4f84c8..d3ed6c9 100644
--- a/drivers/usb/host/ehci-msm.c
+++ b/drivers/usb/host/ehci-msm.c
@@ -61,6 +61,8 @@ static int ehci_msm_reset(struct usb_hcd *hcd)
writel(0, USB_AHBMODE);
/* Disable streaming mode and select host mode */
writel(0x13, USB_USBMODE);
+   /* Disable ULPI_TX_PKT_EN_CLR_FIX which is valid only for HSIC */
+   writel(readl(USB_GENCONFIG_2) & ~ULPI_TX_PKT_EN_CLR_FIX, 
USB_GENCONFIG_2);
 
return 0;
 }
diff --git a/include/linux/usb/msm_hsusb_hw.h b/include/linux/usb/msm_hsusb_hw.h
index e159b39..974c379 100644
--- a/include/linux/usb/msm_hsusb_hw.h
+++ b/include/linux/usb/msm_hsusb_hw.h
@@ -22,6 +22,7 @@
 #define USB_AHBBURST (MSM_USB_BASE + 0x0090)
 #define USB_AHBMODE  (MSM_USB_BASE + 0x0098)
 #define USB_GENCONFIG_2  (MSM_USB_BASE + 0x00a0)
+#define ULPI_TX_PKT_EN_CLR_FIX BIT(19)
 
 #define USB_CAPLENGTH(MSM_USB_BASE + 0x0100) /* 8 bit */
 
-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4/5] usb: ehci-msm: Fix register initialization

[Timur Tabi]

From: Jack Pham <ja...@codeaurora.org>

The default value for the 'transceiver select' field of
the PORTSC register may not always be correct. Previously
the phy-msm-usb driver would do this for us, but since
ehci-msm can now be instantiated standalone without any PHY
driver, the register needs to be explicitly initialized to
ULPI mode to properly communicate with the PHY.

This is not readily apparent, as firmware or bootloader code
also happen to pre-initialize this for us. However, it can
manifest when performing a driver unbind/rebind as follows:

 cd /sys/bus/platform/drivers/msm_hsusb_host
 echo QCOM8040:00 > unbind
 echo QCOM8040:00 > bind

The EHCI core executes a controller reset as part of this,
and as a result the register in question would revert to
its default state and must be re-initialized properly.
Furthermore this may be useful in the future when adding
PM suspend/resume support.

Also, update to use the correct value of AHBMODE to allow
data transfers to be posted AHB transactions. This aligns
with the value used in the downstream MSM kernel.

Signed-off-by: Jack Pham <ja...@codeaurora.org>
Signed-off-by: Timur Tabi <ti...@codeaurora.org>
---
 drivers/usb/host/ehci-msm.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/host/ehci-msm.c b/drivers/usb/host/ehci-msm.c
index fc666ef..b8c0df0 100644
--- a/drivers/usb/host/ehci-msm.c
+++ b/drivers/usb/host/ehci-msm.c
@@ -56,10 +56,12 @@ static int ehci_msm_reset(struct usb_hcd *hcd)
if (retval)
return retval;
 
+   /* select ULPI phy and clear other status/control bits in PORTSC */
+   writel(PORTSC_PTS_ULPI, USB_PORTSC);
/* bursts of unspecified length. */
writel(0, USB_AHBBURST);
/* Use the AHB transactor */
-   writel(0, USB_AHBMODE);
+   writel(0x8, USB_AHBMODE);
/* Disable streaming mode and select host mode */
writel(0x13, USB_USBMODE);
/* Disable ULPI_TX_PKT_EN_CLR_FIX which is valid only for HSIC */
-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/5] usb: ehci-msm: Fix register initialization

[Timur Tabi]

Jack Pham wrote:

Andy already sent a patch for just this register change.
http://marc.info/?l=linux-usb=144678991912202=2

I see it's already been queued on Greg's usb-next. I think it would be
good to rebase.


Ok, I will do that in my next patch version.

--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the
Code Aurora Forum, hosted by The Linux Foundation.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Tegra3 ehci_suspend and ehci_resume

[Timur]

On 12/12/2012 07:34 PM, Alan Stern wrote:


Okay.  Then how about this: Unplug both the power connector and the
slave connector.  After the N7 goes into deep sleep, plug the power
connector back in but leave the slave unplugged.  Then a few seconds
later, plug in the slave.


This always fails (-71 / SET_ADDRESS). The issues can then only be 
solved, by unplugging the OTG adapter. In other words, by switching to 
peripheral mode (and back).



Also try doing the same thing, but don't wait for the N7 to go into
deep sleep.  If this works but the other test doesn't, then clearly the
slave is working correctly and the problem lies in the host controller.


This works well most of the time. Some issues in a few cases, not sure 
why. (It is possible to debug over WiFi. But doing so would prevent LP0.)


Timur

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Tegra3 ehci_suspend and ehci_resume

[Timur]

On 12.12.2012 16:20, Alan Stern wrote:

On Wed, 12 Dec 2012, Timur wrote:


- Unplugging and re-plugging the slave device works well.
- Unplugging the Y-cable (disconnecting slave and external power at the
same time) then re-plugging the Y-cable works well.
- Disconnecting external power to both devices, then waiting for the
host screen to go off and waiting for up to 20 seconds longer (staying
in light sleep) does also work well. Please note: slave device was
completely off power for roughly 20 seconds and is not causing any issues.

The problem only occurs, when I pull external power, wait for the host
screen to go off, then wait another 60s or 10 minutes, this way making
sure the host will indeed transition into deep sleep. Plugging external
power then will wake both devices, but the host can no longer talk to
the slave.


What happens if you: pull external power, wait for the host screen to
go off, then wait another 60s or 10 minutes, then plug external power
back to both devices (but leave the USB connection between the host and
slave unplugged), then wait 10 seconds, then plug in the USB
connection?


Nexus 7 and USB slave get their power via USB cable. This makes it a 
little difficult to connect power, but leave the USB connection 
unplugged. I'm not sure how to proceed with this.


This is the USB Y-adapter I am using: 
https://sites.google.com/site/sonicboomworld/_/rsrc/1345753009582/my-projects/otg-diagrams/Y_OTG_CABLE.png


A photo of all components (USB cables excluded): 
http://mehrvarz.github.com/img/n7-otg-power.png



Is this not strong evidence the problem is with the host?


Yes, it is.  Can you force the host to go into deep sleep while the
external power remains connected?

Alan Stern


I investigated this. Unfortunately, the answer seems to be no. I cannot 
convince the Nexus 7 to move into deep sleep mode (LP0), when a powered 
USB cable is connected to it (despite WiFi, Bt, ADB, etc. being off).


A new finding: when the N7 is coming out of deep sleep (in the 
problematic scenario), I see that method hub_port_reset() is being 
called. It seems to succeed. Because the following shows up in the log: 
usb 2-1: new full speed USB device number 3 using tegra-ehci. However, 
this is then followed by hub_set_address() failing and tegra-ehci 
tegra-ehci.0: detected XactErr len 0/8 retry x and device not 
accepting address 3, error -71 being logged.


I ran this modified test: while the N7 was in deep sleep, I unplugged 
(stole) the USB slave. Then I plugged external power and this time 
hub_port_reset() did not succeed and no entry usb 2-1: new full speed 
USB device number 3 using tegra-ehci was logged. I think this shows 
that, after LP0, a connected USB slave device _is_ still detectable. The 
problem strikes a moment later, when the host tries to set the address.


Can I try anything in code, to reset the slave, so it will accept an 
address?


Timur

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Tegra3 ehci_suspend and ehci_resume

[Timur]

On 12/11/2012 04:34 PM, Alan Stern wrote:

On Mon, 10 Dec 2012, Timur wrote:


N7 is not using a vanilla kernel. It is one thing to apply modifications
to the given code base. It would be far more difficult (I think) to
replace the kernel as a whole. Maybe I should back port just as little
code as possible? Or maybe I should try to back port some full building
blocks? Where to make the cut? I also wonder how to make the system take
advantage of ehci_suspend() and ehci_resume(), both marked as
__maybe_unused. Who is calling these methods?

Why are you concerned about those routines?  The problem most likely
lies in your slave devices -- they don't recover properly from a sudden
power loss.  You should try unplugging the slave, waiting a few
seconds, and then plugging it back in again.

Alan Stern



Thank you for your response. Yes, unplugging helps. But host and slave 
should also function in a fixed installation setup, where cables are 
hidden. I tried different slave devices and they are all not accepting 
address xx, error -71 after power was lost.


I think it is the host causing the issue, not working properly through 
it's deep sleep cycle. Something is wrong or missing in N7's 
tegra_ehci_resume() / tegra_ehci_suspend() methods. These methods exist 
(found them!) and they are being called:


https://github.com/mehrvarz/android_kernel_grouper/blob/android-tegra3-grouper-3.1-jb-mr0/drivers/usb/host/ehci-tegra.c#L1246

Timur

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Tegra3 ehci_suspend and ehci_resume

[Timur]

On 12/11/2012 06:36 PM, Timur wrote:

On 12/11/2012 04:34 PM, Alan Stern wrote:

On Mon, 10 Dec 2012, Timur wrote:

N7 is not using a vanilla kernel. It is one thing to apply 
modifications

to the given code base. It would be far more difficult (I think) to
replace the kernel as a whole. Maybe I should back port just as little
code as possible? Or maybe I should try to back port some full building
blocks? Where to make the cut? I also wonder how to make the system 
take

advantage of ehci_suspend() and ehci_resume(), both marked as
__maybe_unused. Who is calling these methods?

Why are you concerned about those routines?  The problem most likely
lies in your slave devices -- they don't recover properly from a sudden
power loss.  You should try unplugging the slave, waiting a few
seconds, and then plugging it back in again.

Alan Stern



Thank you for your response. Yes, unplugging helps. But host and slave 
should also function in a fixed installation setup, where cables are 
hidden. I tried different slave devices and they are all not 
accepting address xx, error -71 after power was lost.


I think it is the host causing the issue, not working properly through 
it's deep sleep cycle. Something is wrong or missing in N7's 
tegra_ehci_resume() / tegra_ehci_suspend() methods. These methods 
exist (found them!) and they are being called:


https://github.com/mehrvarz/android_kernel_grouper/blob/android-tegra3-grouper-3.1-jb-mr0/drivers/usb/host/ehci-tegra.c#L1246 



A power loss of under 20s will make the host only go into light sleep 
and does not result in error -71.


--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Tegra3 ehci_suspend and ehci_resume

[Timur]

On 12/11/2012 08:13 PM, Alan Stern wrote:

On Tue, 11 Dec 2012, Timur wrote:


Thank you for your response. Yes, unplugging helps. But host and slave
should also function in a fixed installation setup, where cables are
hidden. I tried different slave devices and they are all not
accepting address xx, error -71 after power was lost.

I think it is the host causing the issue, not working properly through
it's deep sleep cycle. Something is wrong or missing in N7's
tegra_ehci_resume() / tegra_ehci_suspend() methods. These methods
exist (found them!) and they are being called:

https://github.com/mehrvarz/android_kernel_grouper/blob/android-tegra3-grouper-3.1-jb-mr0/drivers/usb/host/ehci-tegra.c#L1246


A power loss of under 20s will make the host only go into light sleep
and does not result in error -71.

Are you talking about a loss of power to the host or a loss of power to
the slave?

What is the cause of this power loss?

If you think this problem is specifically related to the Tegra, why not
ask the person responsible for maintaining the Tegra code?  (Hint: Look
in the MAINTAINERS file at the top level of the kernel source code.)

Alan Stern


I am talking about both devices loosing external power at the same time. 
The N7 will then switch to it's internal battery.
I guess anything could cause a loss of power. Turning off the car 
ignition, for example.


Good hint. I found a reference to linux-tegra and will contact them.

Allow me to say that I got a little scared when you told me to try 
unplugging the slave as a solution. Maybe you weren't all serious with 
a list newbie?


Timur

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Tegra3 ehci_suspend and ehci_resume

[Timur]

On 12/11/2012 11:24 PM, Alan Stern wrote:

On Tue, 11 Dec 2012, Timur wrote:


I am talking about both devices loosing external power at the same time.

Losing external power is different from losing power.


I'm trying to be as precise as I can.


The N7 will then switch to it's internal battery.

Right.  It will continue running, because the battery continues to
supply power.  There is no interruption in the power flow.


Correct. Due to the internal battery, there is at no time an 
interruption in the power flow of the host.





I guess anything could cause a loss of power. Turning off the car
ignition, for example.

What happens if the N7 doesn't lose its external power but the slave
does?  If there's still a problem, that's a pretty good indication that
the N7 is working okay but the slave isn't.


I am using a regular OTG Y-cable. Both devices are using the same 
external power source. When I disconnect and reconnect only the slave 
(USB wise), there is no problem (see below).



Good hint. I found a reference to linux-tegra and will contact them.

Allow me to say that I got a little scared when you told me to try
unplugging the slave as a solution. Maybe you weren't all serious with
a list newbie?

I was perfectly serious.  It's a legitimate debugging technique.
Unplug the USB cable, then plug it back in, then see what happens.


I got this wrong. It was your last sentence and I thought you were 
suggesting this as a solution to the problem. I'm very sorry for 
misreading you.


- Unplugging and re-plugging the slave device works well.
- Unplugging the Y-cable (disconnecting slave and external power at the 
same time) then re-plugging the Y-cable works well.
- Disconnecting external power to both devices, then waiting for the 
host screen to go off and waiting for up to 20 seconds longer (staying 
in light sleep) does also work well. Please note: slave device was 
completely off power for roughly 20 seconds and is not causing any issues.


The problem only occurs, when I pull external power, wait for the host 
screen to go off, then wait another 60s or 10 minutes, this way making 
sure the host will indeed transition into deep sleep. Plugging external 
power then will wake both devices, but the host can no longer talk to 
the slave.


Is this not strong evidence the problem is with the host?

Timur

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Tegra3 ehci_suspend and ehci_resume

[Timur]

Hi. I created a replacement kernel for the Nexus 7. Together with a USB 
Y-cable, this mod enables charging the N7, while running the device in 
USB host mode. People are using this to operate N7 + USB DAC devices in 
their cars and other things. It's a fun project.


I'm currently trying to solve an issue with slave devices not being 
detectable after a sudden power loss. Slave devices will restart, when 
external power comes back, but will be not accepting address xx, error 
-71. Would it make sense to try to back port some code from a newer 
versions of ehci-hcd.c, including ehci_suspend() and ehci_resume(), not 
existing in the 3.1.10 kernel of the N7?


Thanks a lot.
Timur

Can you charge  USB Host mode simultaneously?
http://rootzwiki.com/forum/512-nexus-7

Project on github:
http://mehrvarz.github.com/usb-host-mode-power-management-nexus7

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Tegra3 ehci_suspend and ehci_resume

[Timur]

On 12/10/2012 11:08 PM, Greg KH wrote:

On Mon, Dec 10, 2012 at 10:42:50PM +0100, Timur wrote:

Hi. I created a replacement kernel for the Nexus 7. Together with a
USB Y-cable, this mod enables charging the N7, while running the
device in USB host mode. People are using this to operate N7 + USB
DAC devices in their cars and other things. It's a fun project.

I'm currently trying to solve an issue with slave devices not being
detectable after a sudden power loss. Slave devices will restart,
when external power comes back, but will be not accepting address
xx, error -71. Would it make sense to try to back port some code
from a newer versions of ehci-hcd.c, including ehci_suspend() and
ehci_resume(), not existing in the 3.1.10 kernel of the N7?

Why not just try a newer kernel and see if that works properly for you
or not?  There's nothing forcing the N7 to use the 3.1 kernel, is there?

greg k-h
N7 is not using a vanilla kernel. It is one thing to apply modifications 
to the given code base. It would be far more difficult (I think) to 
replace the kernel as a whole. Maybe I should back port just as little 
code as possible? Or maybe I should try to back port some full building 
blocks? Where to make the cut? I also wonder how to make the system take 
advantage of ehci_suspend() and ehci_resume(), both marked as 
__maybe_unused. Who is calling these methods?


Timur
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Tegra3 ehci_suspend and ehci_resume

[Timur]

On 12/11/2012 12:04 AM, Greg KH wrote:

On Mon, Dec 10, 2012 at 11:53:27PM +0100, Timur wrote:


N7 is not using a vanilla kernel.

Yes, I know that quite well :)


It is one thing to apply
modifications to the given code base. It would be far more difficult
(I think) to replace the kernel as a whole. Maybe I should back port
just as little code as possible? Or maybe I should try to back port
some full building blocks? Where to make the cut? I also wonder how
to make the system take advantage of ehci_suspend() and
ehci_resume(), both marked as __maybe_unused. Who is calling these
methods?

Look at the newer kernels for what is going on there.

As for which is easier, that's up to you, there has been a lot of work
to integrate the out-of-tree tegra and android code and get it merged to
the main kernel since 3.1 was released over a year ago, so it depends on
what you feel comfortable with doing.


Wow, I was not aware of this. Can you please point me to a N7-compatible 
configuration for a more recent kernel?



However, unless you are running the latest kernel.org release, there's
usually not much we can help you out with here, as we don't know, or
remember, what is going on in that very old release + odd-random-android
patches.

good luck,


Thank you.
Timur


greg k-h


--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] powerpc/usb: fix bug of CPU hang when missing USB PHY clock

[Tabi Timur-B04825]

On Fri, Aug 10, 2012 at 5:48 AM, Shengzhou Liu
shengzhou@freescale.com wrote:

 +   for (timeout = 1000; timeout  0; timeout--) {
 +   /* check PHY_CLK_VALID to get phy clk valid */
 +   if (in_be32(non_ehci + FSL_SOC_USB_CTRL)
 +PHY_CLK_VALID)
 +   break;
 +   udelay(1);
 +   }

Use spin_event_timeout() instead.

-- 
Timur Tabi
Linux kernel developer at Freescale
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html