On my Exynos 5 based Arndale system, I need to pull the reset line down
and then let it go up again to actually perform a reset. Without that
reset, I can't find any USB hubs on my bus, rendering the USB controller
useless.
So this patch implements the above logic, making EHCI and OHCI work on
Arndale systems for me.
Signed-off-by: Alexander Graf <[email protected]>
CC: Vivek Gautam <[email protected]>
CC: Jingoo Han <[email protected]>
CC: Alan Stern <[email protected]>
CC: Kukjin Kim <[email protected]>
CC: Felipe Balbi <[email protected]>
CC: Greg Kroah-Hartman <[email protected]>
---
As this affects 3.9, this patch should definitely be considered for inclusion
there.
---
drivers/usb/host/ehci-s5p.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/ehci-s5p.c b/drivers/usb/host/ehci-s5p.c
index 20ebf6a..c6d67e4 100644
--- a/drivers/usb/host/ehci-s5p.c
+++ b/drivers/usb/host/ehci-s5p.c
@@ -103,9 +103,15 @@ static void s5p_setup_vbus_gpio(struct platform_device *pdev)
if (!gpio_is_valid(gpio))
return;
- err = gpio_request_one(gpio, GPIOF_OUT_INIT_HIGH, "ehci_vbus_gpio");
- if (err)
+ /* reset pulls the line down, then up again */
+ err = gpio_request_one(gpio, GPIOF_OUT_INIT_LOW, "ehci_vbus_gpio");
+ if (err) {
dev_err(&pdev->dev, "can't request ehci vbus gpio %d", gpio);
+ return;
+ }
+ mdelay(1);
+ __gpio_set_value(gpio, 1);
+ gpio_free(gpio);
}
static u64 ehci_s5p_dma_mask = DMA_BIT_MASK(32);
--
1.7.12.4
On Wed, 13 Mar 2013, Alexander Graf wrote:
> On my Exynos 5 based Arndale system, I need to pull the reset line down
> and then let it go up again to actually perform a reset. Without that
> reset, I can't find any USB hubs on my bus, rendering the USB controller
> useless.
>
> So this patch implements the above logic, making EHCI and OHCI work on
> Arndale systems for me.
>
> Signed-off-by: Alexander Graf <[email protected]>
> CC: Vivek Gautam <[email protected]>
> CC: Jingoo Han <[email protected]>
> CC: Alan Stern <[email protected]>
> CC: Kukjin Kim <[email protected]>
> CC: Felipe Balbi <[email protected]>
> CC: Greg Kroah-Hartman <[email protected]>
>
> ---
>
> As this affects 3.9, this patch should definitely be considered for inclusion
> there.
> ---
> drivers/usb/host/ehci-s5p.c | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/host/ehci-s5p.c b/drivers/usb/host/ehci-s5p.c
> index 20ebf6a..c6d67e4 100644
> --- a/drivers/usb/host/ehci-s5p.c
> +++ b/drivers/usb/host/ehci-s5p.c
> @@ -103,9 +103,15 @@ static void s5p_setup_vbus_gpio(struct platform_device *pdev)
> if (!gpio_is_valid(gpio))
> return;
>
> - err = gpio_request_one(gpio, GPIOF_OUT_INIT_HIGH, "ehci_vbus_gpio");
> - if (err)
> + /* reset pulls the line down, then up again */
> + err = gpio_request_one(gpio, GPIOF_OUT_INIT_LOW, "ehci_vbus_gpio");
> + if (err) {
> dev_err(&pdev->dev, "can't request ehci vbus gpio %d", gpio);
> + return;
> + }
> + mdelay(1);
> + __gpio_set_value(gpio, 1);
> + gpio_free(gpio);
> }
>
> static u64 ehci_s5p_dma_mask = DMA_BIT_MASK(32);
Acked-by: Alan Stern <[email protected]>
Alexander,
On Tue, Mar 12, 2013 at 6:09 PM, Alexander Graf <[email protected]> wrote:
> - err = gpio_request_one(gpio, GPIOF_OUT_INIT_HIGH, "ehci_vbus_gpio");
> - if (err)
> + /* reset pulls the line down, then up again */
> + err = gpio_request_one(gpio, GPIOF_OUT_INIT_LOW, "ehci_vbus_gpio");
> + if (err) {
> dev_err(&pdev->dev, "can't request ehci vbus gpio %d", gpio);
> + return;
> + }
> + mdelay(1);
> + __gpio_set_value(gpio, 1);
> + gpio_free(gpio);
Freeing the gpio is a little on the iffy side since you actually care
about keeping the value. Perhaps you can change this to
devm_gpio_request_one() and avoid the free? I was about to submit a
patch to do just that (since otherwise you run into trouble if you
ever defer the probe) but then ran across your patch.
Thanks!
-Doug
On 13.03.2013, at 18:28, Doug Anderson wrote:
> Alexander,
>
> On Tue, Mar 12, 2013 at 6:09 PM, Alexander Graf <[email protected]> wrote:
>> - err = gpio_request_one(gpio, GPIOF_OUT_INIT_HIGH, "ehci_vbus_gpio");
>> - if (err)
>> + /* reset pulls the line down, then up again */
>> + err = gpio_request_one(gpio, GPIOF_OUT_INIT_LOW, "ehci_vbus_gpio");
>> + if (err) {
>> dev_err(&pdev->dev, "can't request ehci vbus gpio %d", gpio);
>> + return;
>> + }
>> + mdelay(1);
>> + __gpio_set_value(gpio, 1);
>> + gpio_free(gpio);
>
> Freeing the gpio is a little on the iffy side since you actually care
> about keeping the value. Perhaps you can change this to
> devm_gpio_request_one() and avoid the free? I was about to submit a
> patch to do just that (since otherwise you run into trouble if you
> ever defer the probe) but then ran across your patch.
I could also just return it when the function exits and only free it when we exit the probe function with a negative value. The reason I put it in here was that on probe deferral, the pin simply gets blocked.
However, I could probably also just completely take the gpio_free() out of this patch and resubmit, as it should be pretty much unrelated. Then you can patch it properly.
Alex
>
> Thanks!
>
> -Doug
Alexander,
On Wed, Mar 13, 2013 at 10:45 AM, Alexander Graf <[email protected]> wrote:
>
>>> + gpio_free(gpio);
>>
>> Freeing the gpio is a little on the iffy side since you actually care
>> about keeping the value. Perhaps you can change this to
>> devm_gpio_request_one() and avoid the free? I was about to submit a
>> patch to do just that (since otherwise you run into trouble if you
>> ever defer the probe) but then ran across your patch.
>
> I could also just return it when the function exits and only free it when we exit the probe function with a negative value. The reason I put it in here was that on probe deferral, the pin simply gets blocked.
>
> However, I could probably also just completely take the gpio_free() out of this patch and resubmit, as it should be pretty much unrelated. Then you can patch it properly.
Sure, if you want to resubmit without the gpio_free() I'll submit a
new patch atop yours with the change to devm and people can see if
they like it...
On 13.03.2013, at 18:59, Doug Anderson wrote:
> Alexander,
>
> On Wed, Mar 13, 2013 at 10:45 AM, Alexander Graf <[email protected]> wrote:
>>
>>>> + gpio_free(gpio);
>>>
>>> Freeing the gpio is a little on the iffy side since you actually care
>>> about keeping the value. Perhaps you can change this to
>>> devm_gpio_request_one() and avoid the free? I was about to submit a
>>> patch to do just that (since otherwise you run into trouble if you
>>> ever defer the probe) but then ran across your patch.
>>
>> I could also just return it when the function exits and only free it when we exit the probe function with a negative value. The reason I put it in here was that on probe deferral, the pin simply gets blocked.
>>
>> However, I could probably also just completely take the gpio_free() out of this patch and resubmit, as it should be pretty much unrelated. Then you can patch it properly.
>
> Sure, if you want to resubmit without the gpio_free() I'll submit a
> new patch atop yours with the change to devm and people can see if
> they like it...
Hrm. So when I remove the gpio_free() again, I can't find the USB hub anymore. If I however postpone the whole reset procedure until after the potential deferral, it works (see patch below).
Any idea what is going on here?
Alex
diff --git a/drivers/usb/host/ehci-s5p.c b/drivers/usb/host/ehci-s5p.c
index f692f70..b29b2b8 100644
--- a/drivers/usb/host/ehci-s5p.c
+++ b/drivers/usb/host/ehci-s5p.c
@@ -136,8 +136,6 @@ static int s5p_ehci_probe(struct platform_device *pdev)
if (!pdev->dev.coherent_dma_mask)
pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
- s5p_setup_vbus_gpio(pdev);
-
s5p_ehci = devm_kzalloc(&pdev->dev, sizeof(struct s5p_ehci_hcd),
GFP_KERNEL);
if (!s5p_ehci)
@@ -157,6 +155,8 @@ static int s5p_ehci_probe(struct platform_device *pdev)
s5p_ehci->otg = phy->otg;
}
+ s5p_setup_vbus_gpio(pdev);
+
s5p_ehci->dev = &pdev->dev;
hcd = usb_create_hcd(&s5p_ehci_hc_driver, &pdev->dev,-