From: John Youn <John.Youn@synopsys.com>
To: Chen Yu <chenyu56@huawei.com>, John Youn <John.Youn@synopsys.com>,
"John Stultz" <john.stultz@linaro.org>,
lkml <linux-kernel@vger.kernel.org>
Cc: "wangbinghui@hisilicon.com" <wangbinghui@hisilicon.com>,
Wei Xu <xuwei5@hisilicon.com>, Guodong Xu <guodong.xu@linaro.org>,
Amit Pundir <amit.pundir@linaro.org>,
Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Douglas Anderson <dianders@chromium.org>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>
Subject: Re: [RFC][PATCH 2/2] usb: dwc2: Add a quirk to allow speed negotiation for Hisilicon Hi6220
Date: Tue, 18 Oct 2016 15:21:18 -0700 [thread overview]
Message-ID: <3ab39230-0d6b-509e-e26f-b7f7d8549369@synopsys.com> (raw)
In-Reply-To: <3d9a84ee-f17e-e93a-17a2-d2dac3be9e58@huawei.com>
On 10/16/2016 7:42 PM, Chen Yu wrote:
>
>
> On 2016/10/15 3:37, John Youn wrote:
>> On 10/13/2016 4:36 PM, John Stultz wrote:
>>> From: Chen Yu <chenyu56@huawei.com>
>>>
>>> The Hi6220's usb controller is limited in that it does not
>>> automatically autonegotiate the usb speed. Thus it requires a
>>> quirk so that we can manually negotiate the best usb speed for
>>> the attached device.
>>
>> Hi,
>>
>> Could you expand more on this by explaining what exactly is the
>> limitation and the workaround?
>>
>
> The USB host limitation of Hisilicon Hi6220 is full-speed and low-speed
> devices can not be enumerated when gets plugged behind a hub.
>
>> [snip]
>>
>>> +/*
>>> + * HPRT0_SPD_HIGH_SPEED: high speed
>>> + * HPRT0_SPD_FULL_SPEED: full speed
>>> + */
>>> +static void dwc2_change_bus_speed(struct usb_hcd *hcd, int speed)
>>> +{
>>> + struct dwc2_hsotg *hsotg = dwc2_hcd_to_hsotg(hcd);
>>> +
>>> + if (hsotg->core_params->speed == speed)
>>> + return;
>>> +
>>> + hsotg->core_params->speed = speed;
>>> + queue_work(hsotg->wq_otg, &hsotg->wf_otg);
>>> +}
>>> +
>>> +static int dwc2_alloc_dev(struct usb_hcd *hcd, struct usb_device *udev)
>>> +{
>>> + struct dwc2_hsotg *hsotg = dwc2_hcd_to_hsotg(hcd);
>>> +
>>> + if (!hsotg->change_speed_quirk)
>>> + return 1;
>>> +
>>> + hsotg->device_count++;
>>
>> Why do you need to track the device count?
>>
>>> + dev_info(hsotg->dev, "Device count is %u after alloc dev\n",
>>> + hsotg->device_count);
>>> +
>>> + return 1;
>>> +}
>>> +
>>> +static void dwc2_free_dev(struct usb_hcd *hcd, struct usb_device *udev)
>>> +{
>>> + struct dwc2_hsotg *hsotg = dwc2_hcd_to_hsotg(hcd);
>>> +
>>> + if (!hsotg->change_speed_quirk)
>>> + return;
>>> +
>>> + if (hsotg->device_count)
>>> + hsotg->device_count--;
>>> +
>>> + dev_info(hsotg->dev, "Device count is %u after free dev\n",
>>> + hsotg->device_count);
>>> +
>>> + if (hsotg->device_count == 1 && udev->parent &&
>>> + udev->parent->speed > USB_SPEED_UNKNOWN &&
>>> + udev->parent->speed < USB_SPEED_HIGH) {
>>> + dev_info(hsotg->dev, "Set speed to default high-speed\n");
>>> + dwc2_change_bus_speed(hcd, HPRT0_SPD_HIGH_SPEED);
>>> + }
>>> +}
>>> +
>>> +static int dwc2_reset_device(struct usb_hcd *hcd, struct usb_device *udev)
>>> +{
>>> + struct dwc2_hsotg *hsotg = dwc2_hcd_to_hsotg(hcd);
>>> +
>>> + if (!hsotg->change_speed_quirk)
>>> + return 0;
>>> +
>>> + if (udev->speed == USB_SPEED_HIGH) {
>>> + dev_info(hsotg->dev, "Set speed to high-speed\n");
>>> + dwc2_change_bus_speed(hcd, HPRT0_SPD_HIGH_SPEED);
>>> + } else if (udev->speed == USB_SPEED_FULL
>>> + || udev->speed == USB_SPEED_LOW) {
>>> + dev_info(hsotg->dev, "Set speed to full-speed\n");
>>> + dwc2_change_bus_speed(hcd, HPRT0_SPD_FULL_SPEED);
>>> + }
>>
>> It seems you are reinitializing the core every time a device is reset
>> and the udev->speed does not match the core_param speed. But how is
>> the udev->speed being set correctly if the hw cannot negotiate the
>> speed in the first place?
>>
>
> The hardware can negotiate the speed, but communication with a full-speed or
> low-speed device behind a hub is the problem.
>
>> Also should it be for every device? What about if a device gets
>> plugged in behind a hub? I don't think you want to execute this code
>> in that case.
>>
>> This should only affect devices plugged into the root hub, correct?
>> And the hsotg controller only has one root hub port. It seems things
>> could be simplified a bit.
>>
>
> The patch is initially written for Hikey Hi6220 board, and there is a
> hub always connected to root hub, so the patch sets the configuration to
> HPRT0_SPD_HIGH_SPEED when there is only one device(the hub).
Ok, I see.
>
> Thanks for your suggestions, the patch needs modified in these aspect:
> 1. Change the speed setting only when the device is behind a hub in dwc2_reset_device.
I still think you will have issues with multiple devices. Since you
have a built-in hub after root hub, it will always be behind the
hub. So whenver you need to change speeds, it will always reset every
device in the tree. Have you tested with multiple devices and also
multiple levels of hubs?
> 2. Change the speed to HPRT0_SPD_HIGH_SPEED only when the last device is a hub.
>
> What do you think about the fix? Any suggestions will be appreciate!
I'm not sure if any fix can work for all cases. Has this problem
always been there?
Regards,
John
next prev parent reply other threads:[~2016-10-18 22:21 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-13 23:29 [RFC][PATCH 0/2] dwc2 fixes for HiKey John Stultz
2016-10-13 23:29 ` [RFC][PATCH 1/2] usb: dwc2: Force port resume on switching to device mode John Stultz
2016-10-13 23:29 ` [RFC][PATCH 2/2] usb: dwc2: Add a quirk to allow speed negotiation for Hisilicon Hi6220 John Stultz
2016-10-13 23:51 ` John Stultz
2016-10-14 15:00 ` Rob Herring
2016-10-14 18:22 ` John Stultz
2016-10-14 19:37 ` John Youn
2016-10-17 2:41 ` Chen Yu
2016-10-18 22:21 ` John Youn [this message]
2016-10-21 0:39 ` Chen Yu
2016-10-21 20:00 ` John Youn
2016-10-22 0:56 ` Chen Yu
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=3ab39230-0d6b-509e-e26f-b7f7d8549369@synopsys.com \
--to=john.youn@synopsys.com \
--cc=amit.pundir@linaro.org \
--cc=chenyu56@huawei.com \
--cc=dianders@chromium.org \
--cc=gregkh@linuxfoundation.org \
--cc=guodong.xu@linaro.org \
--cc=john.stultz@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=robh+dt@kernel.org \
--cc=wangbinghui@hisilicon.com \
--cc=xuwei5@hisilicon.com \
/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
all inboxes | Powered by JetHome®