Re: Fwd: dwc2 and ping protocol
Hi Nick, In DMA mode handling NAKs internally by hardware performing starting from core v2.71a. Before v2.71a handling NAKs should be performed by driver. Your core is 2.65a. Thanks, Minas On 3/11/2017 7:14 PM, Nick Hudson wrote: > Hi, > > I'm using a mostly unmodified older version of the dwc2 driver in NetBSD > taken from > >git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > > > Import latest dwc2 sources > > commit 192cb07f7928e8cb09a9851e6c0f7478baa3bc6d > Author: John Youn mailto:john.y...@synopsys.com>> > Date: Mon Jan 11 16:32:28 2016 -0800 > > > and it would appear that the hardware isn't handling the device NAKs in > DMA mode. I understand from the code that in DMA mode the NAKs should be > handled in hardware and not generate interrupts. Is this the case? > > > Any pointers? > > > Thanks, > Nick > > > dwctwo0: dwc2_hc_init() > dwctwo0: DMA enabled > dwctwo0: desc DMA disabled > dwctwo0: set HCINTMSK to 0006 > dwctwo0: set HAINTMSK to 0080 > dwctwo0: set GINTMSK to f3000806 > dwctwo0: set HCCHAR(7) to 00881200 > dwctwo0: dwc2_hc_init: Channel 7 > dwctwo0: Dev Addr: 2 > dwctwo0: Ep Num: 2 > dwctwo0: Is In: 0 > dwctwo0: Is Low Speed: 0 > dwctwo0: Ep Type: 2 > dwctwo0: Max Pkt: 512 > dwctwo0: Queue non-periodic transactions > dwctwo0: NP Tx Req Queue Space Avail (before queue): 8 > dwctwo0: NP Tx FIFO Space Avail (before queue): 912 > dwctwo0: dwc2_hc_start_transfer() > dwctwo0: ping, DMA > dwctwo0: no split > dwctwo0: Wrote 80401000 to HCTSIZ(7) > dwctwo0: dwc2_hc_start_transfer: Channel 7 > dwctwo0: Xfer Size: 4096 > dwctwo0: Num Pkts: 8 > dwctwo0: Start PID: 0 > dwctwo0: Multi Cnt: 1 > dwctwo0: Wrote 80981200 to HCCHAR(7) > dwctwo0: --Host Channel Interrupt--, Channel 7 > dwctwo0: hcint 0x0012, hcintmsk 0x0002, hcint&hcintmsk 0x0002 > dwctwo0: --Host Channel 7 Interrupt: Channel Halted-- > dwctwo0: --Host Channel 7 Interrupt: DMA Channel Halted-- > dwctwo0: --Host Channel 7 Interrupt: NAK Received-- > dwctwo0: DWC_otg: dwc2_update_urb_state_abn: OUT, channel 7 > dwctwo0: chan->start_pkt_count 8 > dwctwo0: hctsiz.pktcnt 8 > dwctwo0: chan->max_packet 512 > dwctwo0: bytes_transferred 0 > dwctwo0: urb->actual_length 0 > dwctwo0: urb->transfer_buffer_length 4096 > dwctwo0: dwc2_halt_channel() > dwctwo0: DMA enabled > dwctwo0: dwc2_release_channel: channel 7, halt_status 4 > dwctwo0: dwc2_deactivate_qh(0x8d046808,0x8cf6bce0,0) > dwctwo0: dwc2_hcd_qh_deactivate() > dwctwo0: dwc2_hcd_qh_unlink() > dwctwo0: dwc2_hcd_qh_add() > dwctwo0: dwc2_assign_and_init_hc(0x8d046808,0x8cf6bce0) > dwctwo0: dwc2_hc_init() > dwctwo0: DMA enabled > dwctwo0: desc DMA disabled > dwctwo0: set HCINTMSK to 0006 > dwctwo0: set HAINTMSK to 0001 > dwctwo0: set GINTMSK to f3000806 > dwctwo0: set HCCHAR(0) to 00881200 > dwctwo0: dwc2_hc_init: Channel 0 > dwctwo0: Dev Addr: 2 > dwctwo0: Ep Num: 2 > dwctwo0: Is In: 0 > dwctwo0: Is Low Speed: 0 > dwctwo0: Ep Type: 2 > dwctwo0: Max Pkt: 512 > dwctwo0: Queue non-periodic transactions > dwctwo0: NP Tx Req Queue Space Avail (before queue): 8 > dwctwo0: NP Tx FIFO Space Avail (before queue): 912 > dwctwo0: dwc2_hc_start_transfer() > dwctwo0: ping, DMA > dwctwo0: no split > dwctwo0: Wrote 80401000 to HCTSIZ(0) > dwctwo0: dwc2_hc_start_transfer: Channel 0 > dwctwo0: Xfer Size: 4096 > dwctwo0: Num Pkts: 8 > dwctwo0: Start PID: 0 > dwctwo0: Multi Cnt: 1 > dwctwo0: Wrote 80981200 to HCCHAR(0) > dwctwo0: --Host Channel Interrupt--, Channel 0 > dwctwo0: hcint 0x0012, hcintmsk 0x0002, hcint&hcintmsk 0x0002 > dwctwo0: --Host Channel 0 Interrupt: Channel Halted-- > dwctwo0: --Host Channel 0 Interrupt: DMA Channel Halted-- > dwctwo0: --Host Channel 0 Interrupt: NAK Received-- > dwctwo0: DWC_otg: dwc2_update_urb_state_abn: OUT, channel 0 > dwctwo0: chan->start_pkt_count 8 > dwctwo0: hctsiz.pktcnt 8 > dwctwo0: chan->max_packet 512 > dwctwo0: bytes_transferred 0 > dwctwo0: urb->actual_length 0 > dwctwo0: urb->transfer_buffer_length 4096 > dwctwo0: dwc2_halt_channel() > dwctwo0: DMA enabled > dwctwo0: dwc2_release_channel: channel 0, halt_status 4 > dwctwo0: dwc2_deactivate_qh(0x8d046808,0x8cf6bce0,0) > dwctwo0: dwc2_hcd_qh_deactivate() > dwctwo0: dwc2_hcd_qh_unlink() > dwctwo0: dwc2_hcd_qh_add() > dwctwo0: dwc2_assign_and_init_hc(0x8d046808,0x8cf6bce0) > dwctwo0: dwc2_hc_init() > > > > > -- 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] dwc2: gadget: Fix in control write transfers
After data out stage gadget driver should not initate ZLP on control EP,
because it is up to function driver.
Signed-off-by: Minas Harutyunyan
---
drivers/usb/dwc2/gadget.c | 20 ++--
1 file changed, 6 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 98a4a79e7f6e..b7520fa3725b 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -1369,6 +1369,11 @@ static int dwc2_hsotg_ep_queue(struct usb_ep *ep, struct
usb_request *req,
return 0;
}
+ /* Change EP direction if status phase request is after data out */
+ if (!hs_ep->index && !req->length && !hs_ep->dir_in &&
+ (hs->ep0_state == DWC2_EP0_DATA_OUT))
+ hs_ep->dir_in = 1;
+
if (first) {
if (!hs_ep->isochronous) {
dwc2_hsotg_start_req(hs, hs_ep, hs_req, false);
@@ -2327,14 +2332,6 @@ static void dwc2_hsotg_handle_outdone(struct dwc2_hsotg
*hsotg, int epnum)
*/
}
- /* DDMA IN status phase will start from StsPhseRcvd interrupt */
- if (!using_desc_dma(hsotg) && epnum == 0 &&
- hsotg->ep0_state == DWC2_EP0_DATA_OUT) {
- /* Move to STATUS IN */
- dwc2_hsotg_ep0_zlp(hsotg, true);
- return;
- }
-
/*
* Slave mode OUT transfers do not go through XferComplete so
* adjust the ISOC parity here.
@@ -2997,14 +2994,9 @@ static void dwc2_hsotg_epint(struct dwc2_hsotg *hsotg,
unsigned int idx,
}
}
- if (ints & DXEPINT_STSPHSERCVD) {
+ if (ints & DXEPINT_STSPHSERCVD)
dev_dbg(hsotg->dev, "%s: StsPhseRcvd\n", __func__);
- /* Move to STATUS IN for DDMA */
- if (using_desc_dma(hsotg))
- dwc2_hsotg_ep0_zlp(hsotg, true);
- }
-
if (ints & DXEPINT_BACK2BACKSETUP)
dev_dbg(hsotg->dev, "%s: B2BSetup/INEPNakEff\n", __func__);
--
2.11.0
--
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] dwc2: gadget: Fix in control write transfers
Hi, On 3/30/2017 2:42 PM, Felipe Balbi wrote: > > Hi, > > Minas Harutyunyan writes: >> After data out stage gadget driver should not initate ZLP on control EP, >> because it is up to function driver. > > not true always, depends on return value from ->setup(). Which problem > did you have? Which gadget driver? How did you reproduce? Which other > tests did you run on this patch? > This required for delayed status support. Tested with Synopsys test gadget. As host used USB tracer traffic generator (different control transfers scenarios). Also performed smoke tests with mass storage function to detect any side effects. Thanks, Minas -- 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: dwc2_hc_chhltd_intr_dma - ChHltd set errors?
Hi, On 4/3/2017 9:23 AM, John Youn wrote: > On 03/31/2017 04:04 PM, John Stultz wrote: >> On Thu, Mar 2, 2017 at 12:00 PM, John Stultz wrote: >>> Hey John, >>> We've noticed that when using usb ethernet adapters on HiKey, we >>> occasionally see errors like: >>> >>> dwc2 f72c.usb: dwc2_hc_chhltd_intr_dma: Channel 0 - ChHltd set, >>> but reason is unknown >>> dwc2 f72c.usb: hcint 0x0002, intsts 0x06200029 >>> >>> dwc2 f72c.usb: dwc2_hc_chhltd_intr_dma: Channel 11 - ChHltd set, >>> but reason is unknown >>> dwc2 f72c.usb: hcint 0x0002, intsts 0x04200029 >>> >>> Sometimes followed up by a usb error in the driver, something like: >>> asix 1-1.2:1.0 eth0: asix_rx_fixup() Bad Header Length 0x36000807, offset 68 >>> >>> Curious if you've seen any reports like this? >> >> Hey John, >> Just wanted to check in again on this to see if you've seen anything >> like it? I've not had too much time to debug it, but my attempts so >> far haven't been productive. >> > > I don't think I've seen that. > > We'll try to take a look this week. > > Thanks, > John > > > The core version is less than 2.71a, am I right? Please send full debug log to do more investigation. Also send us regdump after connecting ethernet adapter. Thanks, Minas -- 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: dwc2_hc_chhltd_intr_dma - ChHltd set errors?
Hi, On 4/4/2017 7:04 AM, John Stultz wrote: > On Mon, Apr 3, 2017 at 5:54 AM, Minas Harutyunyan > wrote: >> On 4/3/2017 9:23 AM, John Youn wrote: >>> On 03/31/2017 04:04 PM, John Stultz wrote: >>>> On Thu, Mar 2, 2017 at 12:00 PM, John Stultz >>>> wrote: >>>>> Hey John, >>>>> We've noticed that when using usb ethernet adapters on HiKey, we >>>>> occasionally see errors like: >>>>> >>>>> dwc2 f72c.usb: dwc2_hc_chhltd_intr_dma: Channel 0 - ChHltd set, >>>>> but reason is unknown >>>>> dwc2 f72c.usb: hcint 0x0002, intsts 0x06200029 >>>>> >>>>> dwc2 f72c.usb: dwc2_hc_chhltd_intr_dma: Channel 11 - ChHltd set, >>>>> but reason is unknown >>>>> dwc2 f72c.usb: hcint 0x0002, intsts 0x04200029 >>>>> >>>>> Sometimes followed up by a usb error in the driver, something like: >>>>> asix 1-1.2:1.0 eth0: asix_rx_fixup() Bad Header Length 0x36000807, offset >>>>> 68 >>>>> >>>>> Curious if you've seen any reports like this? >> >> The core version is less than 2.71a, am I right? > > So it looks like its reporting 0x4f54300a for hsotg->regs + GSNPSID > which looks like DWC2_CORE_REV_3_00a > >> Please send full debug log to do more investigation. > > Full dmesg, or is there special debugging you want me to enable? Full dmesg around issue. > >> Also send us regdump after connecting ethernet adapter. > > Sorry, can you clarify how to generate this? cat regdump. To locate dwc2 regdump file: cd /; find -name regdump > > thanks > -john > Thanks, Minas -- 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: dwc2_hc_chhltd_intr_dma - ChHltd set errors?
Hi,
On 4/4/2017 11:03 PM, John Stultz wrote:
> On Tue, Apr 4, 2017 at 12:38 AM, Felipe Balbi
> wrote:
>>
>> Hi,
>>
>> Minas Harutyunyan writes:
>>>>>>>> We've noticed that when using usb ethernet adapters on HiKey, we
>>>>>>>> occasionally see errors like:
>>>>>>>>
>>>>>>>> dwc2 f72c.usb: dwc2_hc_chhltd_intr_dma: Channel 0 - ChHltd set,
>>>>>>>> but reason is unknown
>>>>>>>> dwc2 f72c.usb: hcint 0x0002, intsts 0x06200029
>>>>>>>>
>>>>>>>> dwc2 f72c.usb: dwc2_hc_chhltd_intr_dma: Channel 11 - ChHltd set,
>>>>>>>> but reason is unknown
>>>>>>>> dwc2 f72c.usb: hcint 0x0002, intsts 0x04200029
>>>>>>>>
>>>>>>>> Sometimes followed up by a usb error in the driver, something like:
>>>>>>>> asix 1-1.2:1.0 eth0: asix_rx_fixup() Bad Header Length 0x36000807,
>>>>>>>> offset 68
>>>>>>>>
>>>>>>>> Curious if you've seen any reports like this?
>>>>>
>>>>> The core version is less than 2.71a, am I right?
>>>>
>>>> So it looks like its reporting 0x4f54300a for hsotg->regs + GSNPSID
>>>> which looks like DWC2_CORE_REV_3_00a
>>>>
>>>>> Please send full debug log to do more investigation.
>>>>
>>>> Full dmesg, or is there special debugging you want me to enable?
>>>
>>> Full dmesg around issue.
>>>>
>>>>> Also send us regdump after connecting ethernet adapter.
>>>>
>>>> Sorry, can you clarify how to generate this?
>>>
>>> cat regdump. To locate dwc2 regdump file: cd /; find -name regdump
>>
>> this won't work if his distro doesn't mount debugfs. Please give
>> complete instructions ;-)
>>
>> # mkdir -p /d
>> # mount -t debugfs none /d
>> # cd /d
>> # find . -name regdump
>>
>> The directory name is the same name as the dwc2 device name, AFAICT. So,
>> check your DTS for the name of the device.
>
> Thanks for the extra details! I didn't have DEBUG_FS built in, so this
> helped clue me in.
>
> Attached are dmesg including the issue and the regdump.
>
> I did notice when cating the regdump file, I saw:
> dwc2 f72c.usb: Mode Mismatch Interrupt: currently in Host mode
> twice. (You'll see it 4 times in the dmesg around 1077 as I cat'ed
> regdump again to verify it wasn't just chance).
>
> Let me know if there is anything else you need!
>
> thanks
> -john
>
Could you please apply attached patch and try again.
Thanks,
Minas
From 412bf7e3dad8a20af937f3682a08116b654deb02 Mon Sep 17 00:00:00 2001
Message-Id:
<412bf7e3dad8a20af937f3682a08116b654deb02.1491410224.git.hmi...@synopsys.com>
From: Minas Harutyunyan
Date: Mon, 11 Jul 2016 03:31:17 -0700
Subject: [PATCH] usb: dwc2: hcd: Fix host channel halt flow
According databook in Buffer and External DMA mode
non-split periodic channels can't be halted.
Change-Id: I7c7c4e16309dda7a3b5af34020d46366c357ed49
Signed-off-by: Minas Harutyunyan
---
drivers/usb/dwc2/hcd.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index f4ef159b538e..4e6ee398efb7 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -979,6 +979,25 @@ void dwc2_hc_halt(struct dwc2_hsotg *hsotg, struct
dwc2_host_chan *chan,
if (dbg_hc(chan))
dev_vdbg(hsotg->dev, "%s()\n", __func__);
+
+ /*
+* In buffer DMA or external DMA mode channel can't be halted
+* for non-split periodic channels. At the end of the next
+* uframe/frame (in the worst case), the core generates a channel
+* halted and disables the channel automatically.
+*/
+ if ((hsotg->core_params->dma_enable > 0 &&
+hsotg->core_params->dma_desc_enable <= 0) ||
+ (hsotg->hw_params.arch == GHWCFG2_EXT_DMA_ARCH)) {
+ if (!chan->do_split &&
+ (chan->ep_type == USB_ENDPOINT_XFER_ISOC ||
+chan->ep_type == USB_ENDPOINT_XFER_INT)) {
+ dev_err(hsotg->dev, "%s() Channel can't be halted\n",
+ __func__);
+ return;
+ }
+ }
+
if (halt_status == DWC2_HC_XFER_NO_HALT_STATUS)
dev_err(hsotg->dev, "!!! halt_status = %d !!!\n", halt_status);
--
2.11.0
Re: dwc2_hc_chhltd_intr_dma - ChHltd set errors?
On 4/6/2017 1:03 AM, John Stultz wrote: > > > On Wed, Apr 5, 2017 at 5:58 AM, Minas Harutyunyan > mailto:minas.harutyun...@synopsys.com>> > wrote: >> On 4/4/2017 11:03 PM, John Stultz wrote: >>> >>> I did notice when cating the regdump file, I saw: >>> dwc2 f72c.usb: Mode Mismatch Interrupt: currently in Host mode >>> twice. (You'll see it 4 times in the dmesg around 1077 as I cat'ed >>> regdump again to verify it wasn't just chance). >>> >>> Let me know if there is anything else you need! >>> >> >> Could you please apply attached patch and try again. > > Thanks for sending this out! > > So it didn't build against mainline, but I tweaked it a bit: > - if ((hsotg->core_params->dma_enable > 0 && > -hsotg->core_params->dma_desc_enable <= 0) || > + if ((hsotg->params.host_dma > 0 && > +hsotg->params.dma_desc_enable <= 0) || > > > But I'm still seeing similar behavior: > [ 91.517417] dwc2 f72c.usb: dwc2_hc_chhltd_intr_dma: Channel 5 - > ChHltd set, but reason is unknown > [ 91.526693] dwc2 f72c.usb: hcint 0x0002, intsts 0x0429 > [ 91.533613] asix 1-1.2:1.0 eth0: asix_rx_fixup() Bad Header Length > 0x8003a0cc, offset 1302 > [ 91.534102] asix 1-1.2:1.0 eth0: asix_rx_fixup() Bad Header Length > 0x73ff5a7d, offset 4 > [ 169.116866] dwc2 f72c.usb: dwc2_hc_chhltd_intr_dma: Channel 1 - > ChHltd set, but reason is unknown > [ 169.126146] dwc2 f72c.usb: hcint 0x0002, intsts 0x06200029 > [ 170.699334] asix 1-1.2:1.0 eth0: asix_rx_fixup() Bad Header Length > 0x36000807, offset 68 > > And I'm not seeing the "Channel can't be halted" error from the new logic. > > Full dmesg and regdump attached. > > Let me know if there is something else I should try. > > thanks > -john Ok. To enable full dwc2 debug messages, please set USB_DWC2_DEBUG and USB_DWC2_VERBOSE in Kernel configuration file. Also provide the topology of connected devices(class, speed) to dwc2 root hub. Thanks, Minas -- 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] usb: dwc2: Delayed status support
Added delayed status support for Control transfers.
Tested in all 3 modes: Slave, BDMA and DDMA.
Performed tests: USB CV (Ch9 and MSC), Control Read/Write tests
using Synopsys USB test environment function driver.
Signed-off-by: Minas Harutyunyan
---
drivers/usb/dwc2/core.h | 2 ++
drivers/usb/dwc2/gadget.c | 31 +++
2 files changed, 29 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 30bab8463c96..b4071d9bfbc8 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -991,6 +991,7 @@ struct dwc2_hregs_backup {
* @ctrl_buff: Buffer for EP0 control requests.
* @ctrl_req: Request for EP0 control packets.
* @ep0_state: EP0 control transfers state
+ * @delayed_status:true when gadget driver asks for delayed status
* @test_mode: USB test mode requested by the host
* @remote_wakeup_allowed: True if device is allowed to wake-up host by
* remote-wakeup signalling
@@ -1172,6 +1173,7 @@ struct dwc2_hsotg {
void *ep0_buff;
void *ctrl_buff;
enum dwc2_ep0_state ep0_state;
+ unsigned delayed_status : 1;
u8 test_mode;
dma_addr_t setup_desc_dma[2];
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 6812a8a3a98b..8bc44071bb9b 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -27,6 +27,8 @@
#include
#include
#include
+#include
+
#include "core.h"
#include "hw.h"
@@ -1446,6 +1448,11 @@ static int dwc2_hsotg_ep_queue(struct usb_ep *ep, struct
usb_request *req,
return 0;
}
+ /* Change EP direction if status phase request is after data out */
+ if (!hs_ep->index && !req->length && !hs_ep->dir_in &&
+ hs->ep0_state == DWC2_EP0_DATA_OUT)
+ hs_ep->dir_in = 1;
+
if (first) {
if (!hs_ep->isochronous) {
dwc2_hsotg_start_req(hs, hs_ep, hs_req, false);
@@ -1938,6 +1945,10 @@ static void dwc2_hsotg_process_control(struct dwc2_hsotg
*hsotg,
dev_dbg(hsotg->dev, "driver->setup() ret %d\n", ret);
}
+ hsotg->delayed_status = false;
+ if (ret == USB_GADGET_DELAYED_STATUS)
+ hsotg->delayed_status = true;
+
/*
* the request is either unhandlable, or is not formatted correctly
* so respond with a STALL for the status stage to indicate failure.
@@ -2387,8 +2398,8 @@ static void dwc2_hsotg_handle_outdone(struct dwc2_hsotg
*hsotg, int epnum)
if (!using_desc_dma(hsotg) && epnum == 0 &&
hsotg->ep0_state == DWC2_EP0_DATA_OUT) {
/* Move to STATUS IN */
- dwc2_hsotg_ep0_zlp(hsotg, true);
- return;
+ if (!hsotg->delayed_status)
+ dwc2_hsotg_ep0_zlp(hsotg, true);
}
/*
@@ -3053,8 +3064,20 @@ static void dwc2_hsotg_epint(struct dwc2_hsotg *hsotg,
unsigned int idx,
/* Safety check EP0 state when STSPHSERCVD asserted */
if (hsotg->ep0_state == DWC2_EP0_DATA_OUT) {
/* Move to STATUS IN for DDMA */
- if (using_desc_dma(hsotg))
- dwc2_hsotg_ep0_zlp(hsotg, true);
+ if (using_desc_dma(hsotg)) {
+ if (!hsotg->delayed_status)
+ dwc2_hsotg_ep0_zlp(hsotg, true);
+ else
+ /* In case of 3 stage Control Write with delayed
+* status, when Status IN transfer started
+* before STSPHSERCVD asserted, NAKSTS bit not
+* cleared by CNAK in dwc2_hsotg_start_req()
+* function. Clear now NAKSTS to allow complete
+* transfer.
+*/
+ dwc2_set_bit(hsotg, DIEPCTL(0),
+DXEPCTL_CNAK);
+ }
}
}
--
2.11.0
REGRESSION: usb: dwc2: gadget: Add scatter-gather mode
Hi, SB CV MSC tests failed starting from Test Case 6 with BNA interrupt on ep1in. It's first BULK IN transaction after GET MAXLUN. [319523.955339] dwc2 dwc2.1.auto: dwc2_hsotg_irq: 04088028 0008 (d88c3cc4) retry 8 [319523.955357] dwc2 dwc2.1.auto: dwc2_hsotg_irq: daint=0002 [319523.955366] dwc2 dwc2.1.auto: dwc2_hsotg_epint: ep1(out) DxEPINT=0x0001 [319523.955372] dwc2 dwc2.1.auto: dwc2_hsotg_epint: XferCompl: DxEPCTL=0x00098200, DXEPTSIZ=15c7d486 [319523.955377] dwc2 dwc2.1.auto: complete: ep b58e703a ep1out, req bde78704, 0 => 2620ceb8 [319523.955396] dwc2 dwc2.1.auto: ep1in: req acdadb34: 36@450496f9, noi=0, zero=0, snok=0 [319523.955403] dwc2 dwc2.1.auto: dwc2_hsotg_start_req: DxEPCTL=0x004a8200, ep 1, dir in [319523.955406] dwc2 dwc2.1.auto: ureq->length:36 ureq->actual:0 [319523.955408] dwc2 dwc2.1.auto: dwc2_hsotg_start_req: 1@36/36, 0x20080024 => 0x0930 [319523.955410] dwc2 dwc2.1.auto: dwc2_hsotg_start_req: 36cbc000 pad => 0x0934 [319523.955412] dwc2 dwc2.1.auto: ep0 state:0 [319523.955413] dwc2 dwc2.1.auto: dwc2_hsotg_start_req: DxEPCTL=0x844a8200 [319523.955420] dwc2 dwc2.1.auto: dwc2_hsotg_start_req: DXEPCTL=0x80488200 [319523.955425] dwc2 dwc2.1.auto: ep1in: req f74873bc: 13@7a860fd2, noi=0, zero=0, snok=0 [319523.955446] dwc2 dwc2.1.auto: dwc2_hsotg_irq: 04048028 0004 (d88c3cc4) retry 8 [319523.955451] dwc2 dwc2.1.auto: dwc2_hsotg_irq: daint=0002 [319523.955460] dwc2 dwc2.1.auto: dwc2_hsotg_epint: ep1(in) DxEPINT=0x0200 [319523.955462] dwc2 dwc2.1.auto: dwc2_hsotg_epint: BNA interrupt [319553.987219] dwc2 dwc2.1.auto: dwc2_hsotg_irq: 04008428 0400 (d88c3cc4) retry 8 Meantime it's passing smoke test with mass storage function connected to Linux host. Thanks, Minas
[PATCH] usb: dwc2: Set actual frame number for completed ISOC transfer
On ISOC transfer completion, in DDMA mode, set actual frame number returning to function driver in usb_request. Due to core limitation, returning frame number is 11-bit wide. Signed-off-by: Minas Harutyunyan --- drivers/usb/dwc2/gadget.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c index 6812a8a3a98b..7e05032fbd87 100644 --- a/drivers/usb/dwc2/gadget.c +++ b/drivers/usb/dwc2/gadget.c @@ -2157,6 +2157,11 @@ static void dwc2_gadget_complete_isoc_request_ddma(struct dwc2_hsotg_ep *hs_ep) */ if (!hs_ep->dir_in && ureq->length & 0x3) ureq->actual += 4 - (ureq->length & 0x3); + + /* Set actual frame number for completed transfers */ + ureq->frame_number = + (desc_sts & DEV_DMA_ISOC_FRNUM_MASK) >> + DEV_DMA_ISOC_FRNUM_SHIFT; } dwc2_hsotg_complete_request(hsotg, hs_ep, hs_req, 0); -- 2.11.0
Re: REGRESSION: usb: dwc2: gadget: Add scatter-gather mode
Hi Andrzej, On 3/12/2019 3:39 PM, Andrzej Pietrasiewicz wrote: > Hi Minas, > > > W dniu 12.03.2019 o 08:54, Minas Harutyunyan pisze: >> Hi, >> >> SB CV MSC tests failed starting from Test Case 6 with BNA interrupt on >> ep1in. It's first BULK IN transaction after GET MAXLUN. >> > Can you help me reproduce the problem? I have an Odroid U3. 1. Download from usb.org USB CV tool. Install on MS Windows. 2. Setup your Odroid U3 as mass storage and connect to MS Windows. 3. Run USB CV. Choose MSC tests to run. I used "USB 3 Gen X Command Verifier". > >> >> Meantime it's passing smoke test with mass storage function connected to >> Linux host. > > So the "real" use case with mass storage works, right? > Yes, it's works. Actually, USB CV use another OS and host driver which can be reason of fail, but mass storage should pass all CV MSC tests besides smoke tests with Linux. > Andrzej > Thanks, Minas
[PATCH] usb: dwc2: gadget: Increase descriptors count for ISOC's
Some function drivers queueing more than 128 ISOC requests at a time.
To avoid "descriptor chain full" cases, increasing descriptors count
from MAX_DMA_DESC_NUM_GENERIC to MAX_DMA_DESC_NUM_HS_ISOC for ISOC's
only.
Signed-off-by: Minas Harutyunyan
---
drivers/usb/dwc2/gadget.c | 27 +++
1 file changed, 15 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 6812a8a3a98b..a749de7604c6 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -714,13 +714,11 @@ static unsigned int dwc2_gadget_get_chain_limit(struct
dwc2_hsotg_ep *hs_ep)
unsigned int maxsize;
if (is_isoc)
- maxsize = hs_ep->dir_in ? DEV_DMA_ISOC_TX_NBYTES_LIMIT :
- DEV_DMA_ISOC_RX_NBYTES_LIMIT;
+ maxsize = (hs_ep->dir_in ? DEV_DMA_ISOC_TX_NBYTES_LIMIT :
+ DEV_DMA_ISOC_RX_NBYTES_LIMIT) *
+ MAX_DMA_DESC_NUM_HS_ISOC;
else
- maxsize = DEV_DMA_NBYTES_LIMIT;
-
- /* Above size of one descriptor was chosen, multiple it */
- maxsize *= MAX_DMA_DESC_NUM_GENERIC;
+ maxsize = DEV_DMA_NBYTES_LIMIT * MAX_DMA_DESC_NUM_GENERIC;
return maxsize;
}
@@ -932,7 +930,7 @@ static int dwc2_gadget_fill_isoc_desc(struct dwc2_hsotg_ep
*hs_ep,
/* Update index of last configured entry in the chain */
hs_ep->next_desc++;
- if (hs_ep->next_desc >= MAX_DMA_DESC_NUM_GENERIC)
+ if (hs_ep->next_desc >= MAX_DMA_DESC_NUM_HS_ISOC)
hs_ep->next_desc = 0;
return 0;
@@ -964,7 +962,7 @@ static void dwc2_gadget_start_isoc_ddma(struct
dwc2_hsotg_ep *hs_ep)
}
/* Initialize descriptor chain by Host Busy status */
- for (i = 0; i < MAX_DMA_DESC_NUM_GENERIC; i++) {
+ for (i = 0; i < MAX_DMA_DESC_NUM_HS_ISOC; i++) {
desc = &hs_ep->desc_list[i];
desc->status = 0;
desc->status |= (DEV_DMA_BUFF_STS_HBUSY
@@ -2162,7 +2160,7 @@ static void dwc2_gadget_complete_isoc_request_ddma(struct
dwc2_hsotg_ep *hs_ep)
dwc2_hsotg_complete_request(hsotg, hs_ep, hs_req, 0);
hs_ep->compl_desc++;
- if (hs_ep->compl_desc > (MAX_DMA_DESC_NUM_GENERIC - 1))
+ if (hs_ep->compl_desc > (MAX_DMA_DESC_NUM_HS_ISOC - 1))
hs_ep->compl_desc = 0;
desc_sts = hs_ep->desc_list[hs_ep->compl_desc].status;
}
@@ -3899,6 +3897,7 @@ static int dwc2_hsotg_ep_enable(struct usb_ep *ep,
unsigned int i, val, size;
int ret = 0;
unsigned char ep_type;
+ int desc_num;
dev_dbg(hsotg->dev,
"%s: ep %s: a 0x%02x, attr 0x%02x, mps 0x%04x, intr %d\n",
@@ -3945,11 +3944,15 @@ static int dwc2_hsotg_ep_enable(struct usb_ep *ep,
dev_dbg(hsotg->dev, "%s: read DxEPCTL=0x%08x from 0x%08x\n",
__func__, epctrl, epctrl_reg);
+ if (using_desc_dma(hsotg) && ep_type == USB_ENDPOINT_XFER_ISOC)
+ desc_num = MAX_DMA_DESC_NUM_HS_ISOC;
+ else
+ desc_num = MAX_DMA_DESC_NUM_GENERIC;
+
/* Allocate DMA descriptor chain for non-ctrl endpoints */
if (using_desc_dma(hsotg) && !hs_ep->desc_list) {
hs_ep->desc_list = dmam_alloc_coherent(hsotg->dev,
- MAX_DMA_DESC_NUM_GENERIC *
- sizeof(struct dwc2_dma_desc),
+ desc_num * sizeof(struct dwc2_dma_desc),
&hs_ep->desc_list_dma, GFP_ATOMIC);
if (!hs_ep->desc_list) {
ret = -ENOMEM;
@@ -4092,7 +4095,7 @@ static int dwc2_hsotg_ep_enable(struct usb_ep *ep,
error2:
if (ret && using_desc_dma(hsotg) && hs_ep->desc_list) {
- dmam_free_coherent(hsotg->dev, MAX_DMA_DESC_NUM_GENERIC *
+ dmam_free_coherent(hsotg->dev, desc_num *
sizeof(struct dwc2_dma_desc),
hs_ep->desc_list, hs_ep->desc_list_dma);
hs_ep->desc_list = NULL;
--
2.11.0
Re: REGRESSION: usb: dwc2: gadget: Add scatter-gather mode
Hi Andrzej, On 3/15/2019 3:32 PM, Andrzej Pietrasiewicz wrote: > Hi again, > > sorry for long lines. Reformatted now. > > Hi Minas, > > > W dniu 12.03.2019 o 08:54, Minas Harutyunyan pisze: >> Hi, >> >> SB CV MSC tests failed starting from Test Case 6 with BNA interrupt on >> ep1in. It's first BULK IN transaction after GET MAXLUN. >> > > Thank you for reporting. > > I bisected and identified my own > > commit 10209abe87f5ebfd482a00323f5236d6094d0865 > Author: Andrzej Pietrasiewicz > Date: Mon Jan 21 14:44:47 2019 +0100 > > usb: dwc2: gadget: Add scatter-gather mode > > as the one introducing the regression. > > At this moment I don't know how to fix it. I will lokk into it next week. > > @colleagues from Samsung: can you have a look at the 4412 datasheet > and verify that in this patch all bits are properly set for > scatter-gather mode? > > > Andrzej > > PS. @Minas: Is there any reliable way to switch back and forth between > running CV software and regular usage of USB? What an aggressive piece > of software the USB 3 Gen X Command Verifier is! Its installer warns > "not to run the application" in case you use devices connected to the chosen > Host Controller because it will take over that HC. I thought this > referred to > the application being installed and that as long I didn't run the tests > (i.e. the installed application) everything would be fine. How wrong I was! > The warning should have clearly indicated that it refers to the > installer itself! > I was then unable to use keyboard/mouse connected to the docking station > even if I uninstalled the CV software. I use Linux 99% of the time, but > for the > remaining 1% I want my Windows installation to be working, I don't know how > to repair Windows. I somehow managed to recover but I am not going to > install this on my laptop again. I managed to get some other laptop which > is not used with a docking station, but still with this software it is > best to have > a dedicated machine only for that purpose. Maybe it is the Windows itself > and the application is implemented the only possible way, I don't know. > Yes, using personal laptop for USB CV testing is not good idea. We use lab machine for this kind of testing. Thanks, Minas
Re: [PATCH] usb: dwc2: gadget: add scatter-gather mode
Hi Andrzej,
On 3/29/2019 6:05 PM, Andrzej Pietrasiewicz wrote:
> From: Andrzej Pietrasiewicz
>
> NOT FOR MERGING
>
> @Minas: can you please test with this patch instead of the original one?
>
Tested new version. No issue seen by running USB CV (Ch9, MSC) tests.
Could you please elaborate which else tests you performed?
> @Marek: can you please verify if null pointer bug exists in this version?
>
> This patch adds support for transferring requests, which are
> non-contiguous in physical memory, i.e. the data buffer is described by
> a scatter-list. This allows transferring large requests without relying
> on error-prone contiguous buffer allocations. This way of allocating
> requests is already implemented in functionfs and TCM USB functions and
> automatically used if UDC driver advertises scatter-gather suppport.
>
> Signed-off-by: Andrzej Pietrasiewicz
> [mszyprow: fixed null pointer issue, rewrote commit message]
> Signed-off-by: Marek Szyprowski
> [andrzej.p: improved handling zlps]
> Signed-off-by: Andrzej Pietrasiewicz
> ---
> drivers/usb/dwc2/gadget.c | 107 +++---
> 1 file changed, 76 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
> index e15d8a462085..e76b2e040b4c 100644
> --- a/drivers/usb/dwc2/gadget.c
> +++ b/drivers/usb/dwc2/gadget.c
> @@ -768,22 +768,13 @@ static u32 dwc2_gadget_get_desc_params(struct
> dwc2_hsotg_ep *hs_ep, u32 *mask)
> return desc_size;
> }
>
> -/*
> - * dwc2_gadget_config_nonisoc_xfer_ddma - prepare non ISOC DMA desc chain.
> - * @hs_ep: The endpoint
> - * @dma_buff: DMA address to use
> - * @len: Length of the transfer
> - *
> - * This function will iterate over descriptor chain and fill its entries
> - * with corresponding information based on transfer data.
> - */
> -static void dwc2_gadget_config_nonisoc_xfer_ddma(struct dwc2_hsotg_ep *hs_ep,
> +static void dwc2_gadget_fill_nonisoc_xfer_ddma_one(struct dwc2_hsotg_ep
> *hs_ep,
> + struct dwc2_dma_desc **desc,
>dma_addr_t dma_buff,
> - unsigned int len)
> + unsigned int len,
> + bool true_last)
> {
> - struct dwc2_hsotg *hsotg = hs_ep->parent;
> int dir_in = hs_ep->dir_in;
> - struct dwc2_dma_desc *desc = hs_ep->desc_list;
> u32 mps = hs_ep->ep.maxpacket;
> u32 maxsize = 0;
> u32 offset = 0;
> @@ -798,41 +789,82 @@ static void dwc2_gadget_config_nonisoc_xfer_ddma(struct
> dwc2_hsotg_ep *hs_ep,
> hs_ep->desc_count = 1;
>
> for (i = 0; i < hs_ep->desc_count; ++i) {
> - desc->status = 0;
> - desc->status |= (DEV_DMA_BUFF_STS_HBUSY
> + (*desc)->status = 0;
> + (*desc)->status |= (DEV_DMA_BUFF_STS_HBUSY
><< DEV_DMA_BUFF_STS_SHIFT);
>
> if (len > maxsize) {
> if (!hs_ep->index && !dir_in)
> - desc->status |= (DEV_DMA_L | DEV_DMA_IOC);
> + (*desc)->status |= (DEV_DMA_L | DEV_DMA_IOC);
>
> - desc->status |= (maxsize <<
> - DEV_DMA_NBYTES_SHIFT & mask);
> - desc->buf = dma_buff + offset;
> + (*desc)->status |=
> + maxsize << DEV_DMA_NBYTES_SHIFT & mask;
> + (*desc)->buf = dma_buff + offset;
>
> len -= maxsize;
> offset += maxsize;
> } else {
> - desc->status |= (DEV_DMA_L | DEV_DMA_IOC);
> + if (true_last)
> + (*desc)->status |= (DEV_DMA_L | DEV_DMA_IOC);
>
> if (dir_in)
> - desc->status |= (len % mps) ? DEV_DMA_SHORT :
> - ((hs_ep->send_zlp) ? DEV_DMA_SHORT : 0);
> - if (len > maxsize)
> - dev_err(hsotg->dev, "wrong len %d\n", len);
> + (*desc)->status |= (len % mps) ? DEV_DMA_SHORT :
> + ((hs_ep->send_zlp && true_last) ?
> + DEV_DMA_SHORT : 0);
>
> - desc->status |=
> + (*desc)->status |=
> len << DEV_DMA_NBYTES_SHIFT & mask;
> - desc->buf = dma_buff + offset;
> + (*desc)->buf = dma_buff + offset;
> }
>
> - desc->status &= ~DEV_DMA_BUFF_STS_MASK;
> - desc->status |= (DEV_DMA_BUFF_STS_HREADY
> + (*desc)->status &= ~DEV_DMA_BUFF_STS_MASK;
> + (*desc)->status |= (DEV_DMA_BUFF_STS_
Re: [PATCH] usb: gadget: dwc2: fix zlp handling
On 4/1/2019 2:51 PM, Andrzej Pietrasiewicz wrote:
> The patch 10209abe87f5ebfd482a00323f5236d6094d0865
> usb: dwc2: gadget: Add scatter-gather mode
>
> avoided a NULL pointer dereference (hs_ep->req == NULL) by
> calling dwc2_gadget_fill_nonisoc_xfer_dma_one() directly instead of through
> the dwc2_gadget_config_nonisoc_xfer_ddma() wrapper, which unconditionally
> dereferenced the said pointer.
>
> However, this was based on an incorrect assumption that in the context of
> dwc2_hsotg_program_zlp() the pointer is always NULL, which is not the case.
> The result were SB CV MSC tests failing starting from Test Case 6.
>
> Instead, this patch reverts to calling the wrapper and adds a check for
> the pointer being NULL inside the wrapper.
>
> Fixes: 10209abe87f5 (usb: dwc2: gadget: Add scatter-gather mode)
> Signed-off-by: Andrzej Pietrasiewicz
Acked-by: Minas Harutyunyan
> ---
> drivers/usb/dwc2/gadget.c | 20
> 1 file changed, 12 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
> index 6812a8a3a98b..e76b2e040b4c 100644
> --- a/drivers/usb/dwc2/gadget.c
> +++ b/drivers/usb/dwc2/gadget.c
> @@ -835,19 +835,22 @@ static void
> dwc2_gadget_fill_nonisoc_xfer_ddma_one(struct dwc2_hsotg_ep *hs_ep,
>* with corresponding information based on transfer data.
>*/
> static void dwc2_gadget_config_nonisoc_xfer_ddma(struct dwc2_hsotg_ep
> *hs_ep,
> - struct usb_request *ureq,
> - unsigned int offset,
> + dma_addr_t dma_buff,
>unsigned int len)
> {
> + struct usb_request *ureq = NULL;
> struct dwc2_dma_desc *desc = hs_ep->desc_list;
> struct scatterlist *sg;
> int i;
> u8 desc_count = 0;
>
> + if (hs_ep->req)
> + ureq = &hs_ep->req->req;
> +
> /* non-DMA sg buffer */
> - if (!ureq->num_sgs) {
> + if (!ureq || !ureq->num_sgs) {
> dwc2_gadget_fill_nonisoc_xfer_ddma_one(hs_ep, &desc,
> - ureq->dma + offset, len, true);
> + dma_buff, len, true);
> return;
> }
>
> @@ -1135,7 +1138,7 @@ static void dwc2_hsotg_start_req(struct dwc2_hsotg
> *hsotg,
> offset = ureq->actual;
>
> /* Fill DDMA chain entries */
> - dwc2_gadget_config_nonisoc_xfer_ddma(hs_ep, ureq, offset,
> + dwc2_gadget_config_nonisoc_xfer_ddma(hs_ep, ureq->dma + offset,
>length);
>
> /* write descriptor chain address to control register */
> @@ -2028,12 +2031,13 @@ static void dwc2_hsotg_program_zlp(struct dwc2_hsotg
> *hsotg,
> dev_dbg(hsotg->dev, "Receiving zero-length packet on ep%d\n",
> index);
> if (using_desc_dma(hsotg)) {
> + /* Not specific buffer needed for ep0 ZLP */
> + dma_addr_t dma = hs_ep->desc_list_dma;
> +
> if (!index)
> dwc2_gadget_set_ep0_desc_chain(hsotg, hs_ep);
>
> - /* Not specific buffer needed for ep0 ZLP */
> - dwc2_gadget_fill_nonisoc_xfer_ddma_one(hs_ep, &hs_ep->desc_list,
> - hs_ep->desc_list_dma, 0, true);
> + dwc2_gadget_config_nonisoc_xfer_ddma(hs_ep, dma, 0);
> } else {
> dwc2_writel(hsotg, DXEPTSIZ_MC(1) | DXEPTSIZ_PKTCNT(1) |
> DXEPTSIZ_XFERSIZE(0),
>
Re: problem with Synopsys DesignWare Core SuperSpeed USB driver
Hi, On 4/1/2019 9:01 PM, Felipe Balbi wrote: > > Hi, > > (I can't answer private queries. Please, always Cc the public mailing > list) > > Antonio Santagiuliana writes: > >> Hello >> I am using RaspberryPI for a project and we want to connect 16 USB to UART >> bridges ( at the moment we are using 8 dual UART cp2105 from Silicon Labs ). >> I have seen your page at : >> https://urldefense.proofpoint.com/v2/url?u=https-3A__dri.freedesktop.org_docs_drm_driver-2Dapi_usb_dwc3.html&d=DwIBAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=cQBKt4q-qzNVC53rNAwuwplH23V61rHQhhULvdLA0U8&m=RfK-uhEeZZ8yf79ch5you3BpE1JNPDHRzgmOGkeLBss&s=rGrgFKpJ6-CEmAtR-hiae64T80Z7oCTx3r4xHn-lf4I&e= >> so I was trying to get tracefs output. >> Problem is that on the /t/events subfolder I cannot find the >> dwc3/enable because >> there is not any /dwc3 in /t/events. >> Because of this I cannot set echo 1 > /t/events/dwc3/enable >> as instead your page says I should do. >> I can only find */t/events/enable* should I activate that ? >> running usb-devices command I get this about the drivers loaded : >> >> T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 1 >> D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1 >> P: Vendor=1d6b ProdID=0002 Rev=04.14 >> S: Manufacturer=Linux 4.14.39 dwc_otg_hcd > > You're not using dwc3. That's dwc2, instead. Also, dwc3 tracepoints are > peripheral side only. Host side is a standard xhci, so you would use > xhci tracepoints for that. > > Still, you're using dwc2 from what I can tell. Minas is the maintainer > of that driver. > > It's not dwc2 driver. It's dwc_otg Synopsys reference driver which supplying along with HSOTG core. But what the issue? > > > > >> S: Product=DWC OTG Controller >> S: SerialNumber=3f98.usb >> C: #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=0mA >> I: If#=0x0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub >> >> T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=480 MxCh= 5 >> D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=02 MxPS=64 #Cfgs= 1 >> P: Vendor=0424 ProdID=9514 Rev=02.00 >> C: #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=2mA >> I: If#=0x0 Alt= 1 #EPs= 1 Cls=09(hub ) Sub=00 Prot=02 Driver=hub >> >> T: Bus=01 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 3 Spd=480 MxCh= 0 >> D: Ver= 2.00 Cls=ff(vend.) Sub=00 Prot=01 MxPS=64 #Cfgs= 1 >> P: Vendor=0424 ProdID=ec00 Rev=02.00 >> C: #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=2mA >> I: If#=0x0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=ff Driver=smsc95xx >> >> T: Bus=01 Lev=02 Prnt=02 Port=01 Cnt=02 Dev#= 14 Spd=480 MxCh= 4 >> D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1 >> P: Vendor=0409 ProdID=005a Rev=01.00 >> C: #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=100mA >> I: If#=0x0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub >> >> T: Bus=01 Lev=03 Prnt=14 Port=00 Cnt=01 Dev#= 15 Spd=12 MxCh= 0 >> D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 >> P: Vendor=10c4 ProdID=ea70 Rev=01.00 >> S: Manufacturer=Silicon Labs >> S: Product=CP2105 Dual USB to UART Bridge Controller >> S: SerialNumber=008714B9 >> C: #Ifs= 2 Cfg#= 1 Atr=80 MxPwr=100mA >> I: If#=0x0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=vcpsilabs >> I: If#=0x1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=vcpsilabs >> >> T: Bus=01 Lev=03 Prnt=14 Port=01 Cnt=02 Dev#= 16 Spd=12 MxCh= 0 >> D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 >> P: Vendor=10c4 ProdID=ea70 Rev=01.00 >> S: Manufacturer=Silicon Labs >> S: Product=CP2105 Dual USB to UART Bridge Controller >> S: SerialNumber=0086F956 >> C: #Ifs= 2 Cfg#= 1 Atr=80 MxPwr=100mA >> I: If#=0x0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=vcpsilabs >> I: If#=0x1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=vcpsilabs >> >> T: Bus=01 Lev=03 Prnt=14 Port=02 Cnt=03 Dev#= 17 Spd=12 MxCh= 0 >> D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 >> P: Vendor=10c4 ProdID=ea70 Rev=01.00 >> S: Manufacturer=Silicon Labs >> S: Product=CP2105 Dual USB to UART Bridge Controller >> S: SerialNumber=00870FBD >> C: #Ifs= 2 Cfg#= 1 Atr=80 MxPwr=100mA >> I: If#=0x0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=vcpsilabs >> I: If#=0x1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=vcpsilabs >> >> T: Bus=01 Lev=03 Prnt=14 Port=03 Cnt=04 Dev#= 18 Spd=480 MxCh= 4 >> D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1 >> P: Vendor=0409 ProdID=005a Rev=01.00 >> C: #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=100mA >> I: If#=0x0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub >> >> T: Bus=01 Lev=04 Prnt=18 Port=00 Cnt=01 Dev#= 19 Spd=12 MxCh= 0 >> D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 >> P: Vendor=10c4 ProdID=ea70 Rev=01.00 >> S: Manufacturer=Silicon Labs >> S: Product=CP2105 Dual USB to UART Bridge Controller >> S: SerialNumber=00870E54 >> C: #Ifs= 2 Cfg#= 1 Atr=80 MxPwr=100mA >> I: If#=0x0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=vcpsilabs >> I: If#=0x1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=vcpsilabs >> >
Re: problem with Synopsys DesignWare Core SuperSpeed USB driver
Hi Antonio, On 4/2/2019 3:06 PM, Antonio Santagiuliana wrote: > Hello, sending again in plain text mode.. > > > On Tue, Apr 2, 2019 at 11:37 AM Antonio Santagiuliana > wrote: >> >> Hello, >> thank you for the reply. >> We transmit at 46800 bps from 16 devices to the UART side of the UART to USB >> bridges ( at the moment cp2105 UART to USB bridges ) . >> If we transmit from all of these devices at low throughput small packets of >> some bytes ( 16 to 64 bytes ) let's say every 20 ms , at the receiver side >> on the USB host device ( Raspberry PI ) we can follow all of the messages >> from all of the 16 UART to USB bridges without any problem. >> We can then activate a particular mode by which 1 of the devices connected >> to one of the UART to USB bridges starts sending data still at the same >> baudrate, but at much higher throughput, sending packets of 1460 bytes with >> silence interval between packets of around 20 ms. >> When this happens the normal messages from the other 15 devices appear to be >> retrieved correctly while these longer messages from the high throughput >> mode device sometimes miss some bytes , let's say I receive fewer bytes than >> expected. >> It doesn't appear the problem is the latency of the application layer as I >> verified it wakes up with short delay. >> if I connect only 1 or 2 devices rather than all of 16 and I activate this >> high throughput mode on one device , then the system works perfectly. >> Problem happens when all of the 16 devices are connected and high throughput >> mode on one device is enabled. >> So I was wondering if we got into a limitation of USB system due to polling >> rate from the host linked to the fact that the buffers USB 2.0 specified >> inside these UART-USB bridges are very limited in size ( I think 64 bytes >> and 32 bytes on the two USB ports of the UART to USB dual bridge ) and the >> are also translation buffers on the USB hub that could delay further the >> whole thing. >> I was wondering also if I could raise priority of USB polling that >> particular device more frequently from the host rather than lopping to the >> others and I was checking if it could be useful to log events so to see if I >> can get some clues of what is going on. >> any idea would be welcome. >> thank you >> >> Looks like really bandwidth limitation issue. Actually to analyze that you need to record USB trace to understand what going on the bus. Record debug log to see any delays in transfer starting, etc. Don't think that I can help you with this because it more probably not a bug. Thanks, Minas >> >> On Tue, Apr 2, 2019 at 8:56 AM Minas Harutyunyan >> wrote: >>> >>> Hi, >>> >>> On 4/1/2019 9:01 PM, Felipe Balbi wrote: >>>> >>>> Hi, >>>> >>>> (I can't answer private queries. Please, always Cc the public mailing >>>> list) >>>> >>>> Antonio Santagiuliana writes: >>>> >>>>> Hello >>>>> I am using RaspberryPI for a project and we want to connect 16 USB to UART >>>>> bridges ( at the moment we are using 8 dual UART cp2105 from Silicon Labs >>>>> ). >>>>> I have seen your page at : >>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__dri.freedesktop.org_docs_drm_driver-2Dapi_usb_dwc3.html&d=DwIBAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=cQBKt4q-qzNVC53rNAwuwplH23V61rHQhhULvdLA0U8&m=RfK-uhEeZZ8yf79ch5you3BpE1JNPDHRzgmOGkeLBss&s=rGrgFKpJ6-CEmAtR-hiae64T80Z7oCTx3r4xHn-lf4I&e= >>>>> so I was trying to get tracefs output. >>>>> Problem is that on the /t/events subfolder I cannot find the >>>>> dwc3/enable because >>>>> there is not any /dwc3 in /t/events. >>>>> Because of this I cannot set echo 1 > /t/events/dwc3/enable >>>>> as instead your page says I should do. >>>>> I can only find */t/events/enable* should I activate that ? >>>>> running usb-devices command I get this about the drivers loaded : >>>>> >>>>> T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 1 >>>>> D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1 >>>>> P: Vendor=1d6b ProdID=0002 Rev=04.14 >>>>> S: Manufacturer=Linux 4.14.39 dwc_otg_hcd >>>> >>>> You're not using dwc3. That's dwc2, instead. Also, dwc3 tracepoints are >>>> peripheral side only. Host side is a standard xhci, so you would use &
dwc2 patches
Hi Felipe, When you plan to merge my follow patches: [PATCH] dwc2: gadget: Fix completed transfer size calculation in DDMA [PATCH] usb: dwc2: Set lpm mode parameters depend on HW configuration [PATCH] usb: dwc2: Fix channel disable flow [PATCH] usb: dwc2: Delayed status support [PATCH] usb: dwc2: Set actual frame number for completed ISOC transfer [PATCH] usb: dwc2: gadget: Increase descriptors count for ISOC's Additionally need to merge patch for fixing scatter-gather mode from Andrzej Pietrasiewicz : [PATCH] usb: gadget: dwc2: fix zlp handling Thanks, Minas
Re: Kernel oops when using multiple V4L cameras on ODroid-C2 meson: 9600004f in dwc2_unmap_urb_for_dma+0x1c/0x28
Hi Wayne, On 4/4/2019 10:27 PM, Wayne Piekarski wrote: > Hi everyone, > > I have three USB H.264 cameras connected to an ODroid-C2 running a > latest Armbian nightly build, with what appears to be kernel 5.0.5. > > When trying to access these cameras via V4L, I immediately get a kernel > oops and the device reboots. > > It appears as though the problem occurs in > dwc2_unmap_urb_for_dma+0x1c/0x28 which is in drivers/usb/dwc2. > > I'm not a kernel developer so not sure what other information I can > provide apart from the oops dump. I can provide other information if needed. > Could you please provide register dump (debugfs: regdump) before start playing and provide verbose debug log after start playing till oops. Which is speed of your camera? Did you connected directly to root hub? Thanks, Minas > thanks! > > [ 204.624452] Internal error: Oops: 964f [#1] PREEMPT SMP > [ 204.635515] Modules linked in: snd_soc_hdmi_codec dw_hdmi_i2s_audio > dw_hdmi_cec meson_vdec uvcvideo videobuf2_dma_contig videobuf2_vmalloc > v4l2_mem2mem videobuf2_memops lz4hc videobuf2_v4l2 lz4hc_compress ao_cec > videobuf2_common meson_dw_hdmi meson_rng meson_ir dw_hdmi meson_drm > rng_core rc_core videodev drm_kms_helper cec snd_soc_meson_aiu_spdif > snd_soc_meson_aiu_i2s drm media meson_canvas snd_soc_meson_audio_core > meson_gxbb_wdt drm_panel_orientation_quirks zram snd_usb_audio > snd_soc_simple_card snd_hwdep snd_usbmidi_lib snd_soc_simple_card_utils > snd_soc_core snd_rawmidi snd_seq_device snd_pcm_dmaengine snd_pcm > snd_timer snd scpi_hwmon soundcore ip_tables x_tables realtek > [ 204.728202] CPU: 2 PID: 0 Comm: swapper/2 Tainted: G W > 5.0.5-meson64 #5.77.190401 > [ 204.745037] Hardware name: Hardkernel ODROID-C2 (DT) > [ 204.758748] pstate: 8005 (Nzcv daif -PAN -UAO) > [ 204.772475] pc : __memcpy+0xa0/0x180 > [ 204.786168] lr : dwc2_free_dma_aligned_buffer+0x78/0x80 > [ 204.799988] sp : 10013da0 > [ 204.813726] x29: 10013da0 x28: > [ 204.827504] x27: 0038 x26: 10e960c0 > [ 204.841198] x25: 0101 x24: 0020 > [ 204.854820] x23: 10e9d000 x22: 80006b378594 > [ 204.868394] x21: x20: 80006a124f79 > [ 204.881902] x19: 80007e6f1800 x18: 0098090c > [ 204.895494] x17: x16: > [ 204.909050] x15: 014d x14: 0400 > [ 204.922531] x13: x12: 0001 > [ 204.935862] x11: 0047f7f9 x10: 0040 > [ 204.948999] x9 : 0002 x8 : 10eb82a0 > [ 204.962085] x7 : 0002 x6 : 80006a124f79 > [ 204.975122] x5 : x4 : 00800200 > [ 204.988041] x3 : 01f4 x2 : 0002 > [ 205.000822] x1 : 80007edbf202 x0 : 80006a124f79 > [ 205.013627] Process swapper/2 (pid: 0, stack limit = 0x35e14788) > [ 205.027581] Call trace: > [ 205.040442] __memcpy+0xa0/0x180 > [ 205.053332] dwc2_unmap_urb_for_dma+0x1c/0x28 > [ 205.066319] unmap_urb_for_dma+0x18/0x28 > [ 205.079213] __usb_hcd_giveback_urb+0x38/0xe0 > [ 205.092009] usb_giveback_urb_bh+0xac/0x108 > [ 205.104753] tasklet_action_common.isra.2+0x7c/0x168 > [ 205.117479] tasklet_action+0x24/0x30 > [ 205.130030] __do_softirq+0x10c/0x220 > [ 205.142521] irq_exit+0xac/0xc0 > [ 205.154950] __handle_domain_irq+0x60/0xb0 > [ 205.167376] gic_handle_irq+0x58/0xa8 > [ 205.179784] el1_irq+0xb0/0x128 > [ 205.192121] arch_cpu_idle+0x10/0x18 > [ 205.204478] do_idle+0x1dc/0x2a0 > [ 205.216787] cpu_startup_entry+0x24/0x28 > [ 205.229051] secondary_start_kernel+0x19c/0x1d8 > [ 205.241263] Code: b8404423 b80044c3 36080062 78402423 (780024c3) > [ 205.253985] ---[ end trace 156b59abcb22f143 ]--- > [ 205.266298] Kernel panic - not syncing: Fatal exception in interrupt > [ 205.279479] SMP: stopping secondary CPUs > [ 205.291947] Kernel Offset: disabled > [ 205.304384] CPU features: 0x002,24002004 > [ 205.316867] Memory Limit: none > [ 205.329314] Rebooting in 10 seconds.. > >
RE: lan78xx: About 8000 usb interrupts per second when idle
Hi Stefan, > Hi Minas, > > Am 09.04.19 um 08:54 schrieb Jisheng Zhang: >> On Mon, 8 Apr 2019 16:05:51 +0800 Jisheng Zhang wrote: >> >>> Hi Stefan, >>> >>> On Mon, 8 Apr 2019 09:57:14 +0200 Stefan Wahren wrote: >>> Hi Jisheng, thanks for sending this patch. I already reported this issue last year [1], but Microchip wasn't able to provide a fix. I will give it a try. > The second one: 8000 usb interrupts per second when idle. > This is abnormal. any idea? Is it due to the lan78xx? Does this downstream patch [2] improve your situation? >>> Thanks a lot. Will try the patch tonight. >> I tried this patch, it doesn't help. One more observation: if I >> ifconfig eth0 down, I can still get 8000 usb interrupts per second. >> Not sure whether this is usb issue or not. > > Jisheng reports a lot of USB interrupts while the lan78xx driver on > Raspberry Pi 3B+ is in idle. > > Any suggestions to narrow this down? dwc2 in host mode enable SOF interrupts if any periodic EP are in use. So, 8000 interrupts per second is expectant behavior. > > Stefan > >> >> Thanks >>
Re: [PATCH v2 0/5] usb: dwc2: Improve gadget phy init
On 4/5/2019 5:36 PM, Jules Maselbas wrote: > Hi, > > Theses patches tries to clean a bit dwc2's phy initialization and > fix an issue in gadget mode where the utmi phy width is set > regardless of utmi being used or not. > > I believe that when using ulpi a phy width of 8 bits must be used, > but this wasn't the case as the variable phyif was set by default > to 16 bits. > > In this second patch-set version the last two patches are optionnal, > from my point of view they are not essential for me but I hope they > can improve this driver. > > Best regards, > Jules > --- > Changes in v2: >- Changed patches order >- dwc2_init_fs_ls_pclk_sel is now declared in core.h (to be used in hcd.c) >- Fix patch `Replace phyif with phy_utmi_width` (wrong value set to usbcfg) >- Add check for utmi phy type in patch `Replace phyif with phy_utmi_width` > > --- > Jules Maselbas (5): >usb: dwc2: Move UTMI_PHY_DATA defines closer >usb: dwc2: gadget: Remove duplicated phy init >usb: dwc2: gadget: Replace phyif with phy_utmi_width >usb: dwc2: Move phy init into core >usb: dwc2: gadget: Move gadget phy init into core phy init > > drivers/usb/dwc2/core.c | 199 > drivers/usb/dwc2/core.h | 4 +- > drivers/usb/dwc2/gadget.c | 36 ++- > drivers/usb/dwc2/hcd.c | 190 -- > drivers/usb/dwc2/hw.h | 6 +- > drivers/usb/dwc2/platform.c | 5 +- > 6 files changed, 213 insertions(+), 227 deletions(-) > Acked-by: Minas Harutyunyan
[PATCH] usb: dwc2: gadget: Reject LPM token during Control transfers
Avoiding switch to L1 state in any stage of control transfers. Send NYET handshake to LPM token. Renamed GLPMCFG_LPM_ACCEPT_CTRL_ISOC to GLPMCFG_LPM_REJECT_CTRL_CONTROL because by setting this bit core reject LPM token. Signed-off-by: Minas Harutyunyan --- drivers/usb/dwc2/gadget.c | 1 + drivers/usb/dwc2/hw.h | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c index 6812a8a3a98b..6ac850d6ad44 100644 --- a/drivers/usb/dwc2/gadget.c +++ b/drivers/usb/dwc2/gadget.c @@ -5073,6 +5073,7 @@ void dwc2_gadget_init_lpm(struct dwc2_hsotg *hsotg) val |= hsotg->params.lpm_clock_gating ? GLPMCFG_ENBLSLPM : 0; val |= hsotg->params.hird_threshold << GLPMCFG_HIRD_THRES_SHIFT; val |= hsotg->params.besl ? GLPMCFG_ENBESL : 0; + val |= GLPMCFG_LPM_REJECT_CTRL_CONTROL; val |= GLPMCFG_LPM_ACCEPT_CTRL_ISOC; dwc2_writel(hsotg, val, GLPMCFG); dev_dbg(hsotg->dev, "GLPMCFG=0x%08x\n", dwc2_readl(hsotg, GLPMCFG)); diff --git a/drivers/usb/dwc2/hw.h b/drivers/usb/dwc2/hw.h index 98af924a9a5c..1bc394dcfa9d 100644 --- a/drivers/usb/dwc2/hw.h +++ b/drivers/usb/dwc2/hw.h @@ -333,7 +333,7 @@ #define GLPMCFG_SNDLPM BIT(24) #define GLPMCFG_RETRY_CNT_MASK (0x7 << 21) #define GLPMCFG_RETRY_CNT_SHIFT21 -#define GLPMCFG_LPM_ACCEPT_CTRL_CONTROLBIT(21) +#define GLPMCFG_LPM_REJECT_CTRL_CONTROLBIT(21) #define GLPMCFG_LPM_ACCEPT_CTRL_ISOC BIT(22) #define GLPMCFG_LPM_CHNL_INDX_MASK (0xf << 17) #define GLPMCFG_LPM_CHNL_INDX_SHIFT17 -- 2.11.0
Re: usb: dwc2: Usb wifi dongle fails to initialize with Frame Overrun errors
Hi Hal, On 4/19/2019 11:41 PM, Hal Emmerich wrote: Hello all, I have a ar9271 wireless dongle which is known to not work well with dwc2. When inserted, it may initialize properly if the system was just rebooted but after that will error out. With dwc2 verbose debug enabled, I see a bulk transfer followed by a frame overrun interrupt. The log of this is below. I attempted to get a verbose log of it functioning, but was unable to. Not sure if that might indicate a race condition since it does sometimes work when verbose debug is disabled? Is the frame overrun error indicating the message was received after the frame? Or is it saying one of the dma buffers is full? I can't find a reference to frame overrun errors in the usb error list. I also recorded the transactions with wireshark and can provide those if it would help. Description for frame overrun from databook: --- 3.7 Selecting the Queue Depth Choose the Periodic and Non-periodic Request Queue depths carefully to match the number of periodic or non-periodic endpoints accessed. The Non-periodic Request Queue depth affects the performance of non-periodic transfers. The deeper the queue (along with sufficient FIFO size), the more often the controller is able to pipeline non-periodic transfers. If the queue size is small, the controller is able to put in new requests only when the queue space is freed up. The controller’s Periodic Request Queue depth is critical to performing periodic transfers as scheduled. Select the periodic queue depth, based on the number of periodic transfers scheduled in a microframe. In Slave mode, however, the application must also take into account the disable entry that must be put into the queue. So, if there are two non-high-bandwidth periodic endpoints, the Periodic Request Queue depth must be at least 4. If at least one high-bandwidth endpoint supported, the queue depth must be 8. If the Periodic Request Queue depth is smaller than the periodic transfers scheduled in a microframe, a frame overrun condition results. --- Actually, this interrupt should not be asserted because in your case started just one periodic (Interrupt IN) transfer in microframe and before starting queue depth checked - there are enough space to start transfer: P Tx Req Queue Space Avail (before queue): 8 Thanks, Minas [ 93.104662] usb 2-1: ath9k_htc: Transferred FW: ath9k_htc/htc_9271-1.4.0.fw, size: 51008 [ 93.113803] dwc2 ff58.usb: DWC OTG HCD URB Enqueue [ 93.119568] dwc2 ff58.usb: urb_enqueue, urb 1032f3a7 [ 93.125510] dwc2 ff58.usb: Device address: 2 [ 93.130917] dwc2 ff58.usb: Endpoint: 2, IN [ 93.136088] dwc2 ff58.usb: Endpoint type: BULK IN (IN) [ 93.142429] dwc2 ff58.usb: Speed: HIGH [ 93.147209] dwc2 ff58.usb: Max packet size: 512 [ 93.152865] dwc2 ff58.usb: Data buffer length: 16384 [ 93.159005] dwc2 ff58.usb: Transfer buffer: 56fd7fba, Transfer DMA: 2beb [ 93.167476] dwc2 ff58.usb: Setup buffer: (null), Setup DMA: [ 93.175362] dwc2 ff58.usb: Interval: 0 [ 93.180145] dwc2 ff58.usb: addr=2, ep_num=2, ep_dir=80, ep_type=2, mps=512 [ 93.188228] dwc2 ff58.usb: dwc2_hcd_qh_add() [ 93.193384] dwc2 ff58.usb: dwc2_assign_and_init_hc(bd1a24cd,024930b4) [ 93.200966] dwc2 ff58.usb: dwc2_hc_init() [ 93.205819] dwc2 ff58.usb: DMA enabled [ 93.210389] dwc2 ff58.usb: desc DMA disabled [ 93.215542] dwc2 ff58.usb: set HCINTMSK to 0006 [ 93.221374] dwc2 ff58.usb: set HAINTMSK to 0040 [ 93.227206] dwc2 ff58.usb: set GINTMSK to f3000806 [ 93.232941] dwc2 ff58.usb: set HCCHAR(6) to 00889200 [ 93.238871] dwc2 ff58.usb: dwc2_hc_init: Channel 6 [ 93.244606] dwc2 ff58.usb: Dev Addr: 2 [ 93.249369] dwc2 ff58.usb: Ep Num: 2 [ 93.253940] dwc2 ff58.usb: Is In: 1 [ 93.258412] dwc2 ff58.usb: Is Low Speed: 0 [ 93.263565] dwc2 ff58.usb: Ep Type: 2 [ 93.268231] dwc2 ff58.usb: Max Pkt: 512 [ 93.273093] dwc2 ff58.usb: Queue non-periodic transactions [ 93.279606] dwc2 ff58.usb: NP Tx Req Queue Space Avail (before queue): 8 [ 93.287672] dwc2 ff58.usb: NP Tx FIFO Space Avail (before queue): 128 [ 93.295447] dwc2 ff58.usb: dwc2_hc_start_transfer() [ 93.301280] dwc2 ff58.usb: no split [ 93.305559] dwc2 ff58.usb: Wrote 01004000 to HCTSIZ(6) [ 93.311683] dwc2 ff58.usb: dwc2_hc_start_transfer: Channel 6 [ 93.318389] dwc2 ff58.usb: Xfer Size: 16384 [ 93.323639] dwc2 ff58.usb: Num Pkts: 32 [ 93.328501] dwc2 ff58.usb: Start PID: 0 [ 93.62] dwc2 ff58.usb: Wrote 2beb to HCDMA(6) [ 93.339390] dwc2 ff58.usb: Multi Cnt: 1 [ 93.344251] dwc2 ff58.usb: Wrote 80989200 to HCCHAR(6) [ 93.350434] dwc2 ff58.usb: DWC OTG HCD URB Enqueue [ 93.356189] dwc2 ff58.usb: urb_enqueue, urb 92464acd [ 93.362146] dwc2
[PATCH] usb: dwc2: Set actual frame number for completed ISOC transfer for none DDMA
On ISOC OUT transfer completion, in none DDMA mode, set actual frame number returning to function driver in usb_request. Signed-off-by: Minas Harutyunyan --- drivers/usb/dwc2/gadget.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c index 6812a8a3a98b..608e0b1331c5 100644 --- a/drivers/usb/dwc2/gadget.c +++ b/drivers/usb/dwc2/gadget.c @@ -2402,6 +2402,10 @@ static void dwc2_hsotg_handle_outdone(struct dwc2_hsotg *hsotg, int epnum) dwc2_gadget_incr_frame_num(hs_ep); } + /* Set actual frame number for completed transfers */ + if (!using_desc_dma(hsotg) && hs_ep->isochronous) + req->frame_number = hsotg->frame_number; + dwc2_hsotg_complete_request(hsotg, hs_ep, hs_req, result); } -- 2.11.0
Re: [PATCH] usb: gadget: dwc2: fix zlp handling
Hi Felipe,
On 4/1/2019 3:33 PM, Minas Harutyunyan wrote:
On 4/1/2019 2:51 PM, Andrzej Pietrasiewicz wrote:
The patch 10209abe87f5ebfd482a00323f5236d6094d0865
usb: dwc2: gadget: Add scatter-gather mode
avoided a NULL pointer dereference (hs_ep->req == NULL) by
calling dwc2_gadget_fill_nonisoc_xfer_dma_one() directly instead of through
the dwc2_gadget_config_nonisoc_xfer_ddma() wrapper, which unconditionally
dereferenced the said pointer.
However, this was based on an incorrect assumption that in the context of
dwc2_hsotg_program_zlp() the pointer is always NULL, which is not the case.
The result were SB CV MSC tests failing starting from Test Case 6.
Instead, this patch reverts to calling the wrapper and adds a check for
the pointer being NULL inside the wrapper.
Fixes: 10209abe87f5 (usb: dwc2: gadget: Add scatter-gather mode)
Signed-off-by: Andrzej Pietrasiewicz
Acked-by: Minas Harutyunyan
---
drivers/usb/dwc2/gadget.c | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 6812a8a3a98b..e76b2e040b4c 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -835,19 +835,22 @@ static void dwc2_gadget_fill_nonisoc_xfer_ddma_one(struct
dwc2_hsotg_ep *hs_ep,
* with corresponding information based on transfer data.
*/
static void dwc2_gadget_config_nonisoc_xfer_ddma(struct dwc2_hsotg_ep *hs_ep,
-struct usb_request *ureq,
-unsigned int offset,
+dma_addr_t dma_buff,
unsigned int len)
{
+ struct usb_request *ureq = NULL;
struct dwc2_dma_desc *desc = hs_ep->desc_list;
struct scatterlist *sg;
int i;
u8 desc_count = 0;
+ if (hs_ep->req)
+ ureq = &hs_ep->req->req;
+
/* non-DMA sg buffer */
- if (!ureq->num_sgs) {
+ if (!ureq || !ureq->num_sgs) {
dwc2_gadget_fill_nonisoc_xfer_ddma_one(hs_ep, &desc,
- ureq->dma + offset, len, true);
+ dma_buff, len, true);
return;
}
@@ -1135,7 +1138,7 @@ static void dwc2_hsotg_start_req(struct dwc2_hsotg *hsotg,
offset = ureq->actual;
/* Fill DDMA chain entries */
- dwc2_gadget_config_nonisoc_xfer_ddma(hs_ep, ureq, offset,
+ dwc2_gadget_config_nonisoc_xfer_ddma(hs_ep, ureq->dma + offset,
length);
/* write descriptor chain address to control register */
@@ -2028,12 +2031,13 @@ static void dwc2_hsotg_program_zlp(struct dwc2_hsotg
*hsotg,
dev_dbg(hsotg->dev, "Receiving zero-length packet on ep%d\n",
index);
if (using_desc_dma(hsotg)) {
+ /* Not specific buffer needed for ep0 ZLP */
+ dma_addr_t dma = hs_ep->desc_list_dma;
+
if (!index)
dwc2_gadget_set_ep0_desc_chain(hsotg, hs_ep);
- /* Not specific buffer needed for ep0 ZLP */
- dwc2_gadget_fill_nonisoc_xfer_ddma_one(hs_ep, &hs_ep->desc_list,
- hs_ep->desc_list_dma, 0, true);
+ dwc2_gadget_config_nonisoc_xfer_ddma(hs_ep, dma, 0);
} else {
dwc2_writel(hsotg, DXEPTSIZ_MC(1) | DXEPTSIZ_PKTCNT(1) |
DXEPTSIZ_XFERSIZE(0),
This patch is fix for "usb: dwc2: gadget: Add scatter-gather mode" patch
to allow pass USB CV.
Could you please merge to your testing/next this patch also.
Thanks,
Minas
Re: [PATCH v2] usb: dwc2: Use generic PHY width in params setup
On 5/9/2019 1:16 PM, Jules Maselbas wrote:
Setting params.phy_utmi_width in dwc2_lowlevel_hw_init() is pointless since
it's value will be overwritten by dwc2_init_params().
This change make sure to take in account the generic PHY width information
during paraminitialisation, done in dwc2_set_param_phy_utmi_width().
By doing so, the phy_utmi_width params can still be overrided by
devicetree specific params and will also be checked against hardware
capabilities.
Fixes: 707d80f0a3c5 ("usb: dwc2: gadget: Replace phyif with phy_utmi_width")
Tested-by: Marek Szyprowski
Signed-off-by: Jules Maselbas
Acked-by: Minas Harutyunyan
---
v2: Fix typo in commit message. Add Fixes and Tested-by tags.
---
drivers/usb/dwc2/params.c | 9 +
drivers/usb/dwc2/platform.c | 9 -
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/dwc2/params.c b/drivers/usb/dwc2/params.c
index 6900eea57526..5949262ff669 100644
--- a/drivers/usb/dwc2/params.c
+++ b/drivers/usb/dwc2/params.c
@@ -253,6 +253,15 @@ static void dwc2_set_param_phy_utmi_width(struct
dwc2_hsotg *hsotg)
val = (hsotg->hw_params.utmi_phy_data_width ==
GHWCFG4_UTMI_PHY_DATA_WIDTH_8) ? 8 : 16;
+ if (hsotg->phy) {
+ /*
+* If using the generic PHY framework, check if the PHY bus
+* width is 8-bit and set the phyif appropriately.
+*/
+ if (phy_get_bus_width(hsotg->phy) == 8)
+ val = 8;
+ }
+
hsotg->params.phy_utmi_width = val;
}
diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index d10a7f8daec3..e98d7812da2d 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -271,15 +271,6 @@ static int dwc2_lowlevel_hw_init(struct dwc2_hsotg *hsotg)
hsotg->plat = dev_get_platdata(hsotg->dev);
- if (hsotg->phy) {
- /*
-* If using the generic PHY framework, check if the PHY bus
-* width is 8-bit and set the phyif appropriately.
-*/
- if (phy_get_bus_width(hsotg->phy) == 8)
- hsotg->params.phy_utmi_width = 8;
- }
-
/* Clock */
hsotg->clk = devm_clk_get_optional(hsotg->dev, "otg");
if (IS_ERR(hsotg->clk)) {
Re: [PATCH v1] usb: dwc2: Switch to use device_property_count_u32()
On 7/23/2019 11:17 PM, Andy Shevchenko wrote:
Use use device_property_count_u32() directly, that makes code neater.
Signed-off-by: Andy Shevchenko
---
Acked-by: Minas Harutyunyan
drivers/usb/dwc2/params.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/usb/dwc2/params.c b/drivers/usb/dwc2/params.c
index 55f841a54015..31e090ac9f1e 100644
--- a/drivers/usb/dwc2/params.c
+++ b/drivers/usb/dwc2/params.c
@@ -404,10 +404,7 @@ static void dwc2_get_device_properties(struct dwc2_hsotg
*hsotg)
device_property_read_u32(hsotg->dev, "g-np-tx-fifo-size",
&p->g_np_tx_fifo_size);
- num = device_property_read_u32_array(hsotg->dev,
-"g-tx-fifo-size",
-NULL, 0);
-
+ num = device_property_count_u32(hsotg->dev, "g-tx-fifo-size");
if (num > 0) {
num = min(num, 15);
memset(p->g_tx_fifo_size, 0,
[PATCH 1/3] usb: dwc2: Enable BNA interrupt for IN endpoints
In DDMA mode required to enable BNA interrupt for
both directions.
Signed-off-by: Minas Harutyunyan
---
drivers/usb/dwc2/gadget.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 6c32bf26e48e..c231321656f9 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -3320,8 +3320,10 @@ void dwc2_hsotg_core_init_disconnected(struct dwc2_hsotg
*hsotg,
hsotg->regs + DOEPMSK);
/* Enable BNA interrupt for DDMA */
- if (using_desc_dma(hsotg))
+ if (using_desc_dma(hsotg)) {
dwc2_set_bit(hsotg->regs + DOEPMSK, DOEPMSK_BNAMSK);
+ dwc2_set_bit(hsotg->regs + DIEPMSK, DIEPMSK_BNAININTRMSK);
+ }
dwc2_writel(0, hsotg->regs + DAINTMSK);
--
2.11.0
--
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 0/3] usb: dwc2: gadget: Update ISOC DDMA flow.
This series fully update existing ISOC DDMA flow which initially based on 2 descriptor chains. Switching between desc chains performing based on BNA interrupt. Because of BNA interrupt few packets can be lost. 1/3 patch unmask ISOC IN BNA interrupt only. 2/3 patch changing ISOC IN/OUT flow as described above. 3/3 patch add High bandwidth ISOC OUT transfers support. All patches were tested on HAPS-DX7 platform using internal USB test tool. Minas Harutyunyan (3): usb: dwc2: Enable BNA interrupt for IN endpoints usb: dwc2: Change ISOC DDMA flow usb: dwc2: Add High Bandwidth ISOC OUT support drivers/usb/dwc2/core.h | 2 - drivers/usb/dwc2/gadget.c | 505 -- 2 files changed, 359 insertions(+), 148 deletions(-) -- 2.11.0 -- 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/3] usb: dwc2: Change ISOC DDMA flow
Changed existing two descriptor-chain flow to one chain.
In two-chain implementation BNA interrupt used for switching between
two chains. BNA interrupt asserted because of returning to
beginning of the chain based on L-bit of last descriptor.
Because of that we lose packets. This issue resolved by using one
desc-chain.
Removed all staff related to two desc-chain flow from
DDMA ISOC related functions.
Removed request length checking from dwc2_gadget_fill_isoc_desc()
function. Request length checking added to dwc2_hsotg_ep_queue()
function. If request length greater than descriptor limits then
request not added to queue. Additional checking done for High
Bandwidth ISOC OUT's which not supported by driver. In
dwc2_gadget_fill_isoc_desc() function also checked desc-chain
status (full or not) to avoid of reusing not yet processed
descriptors.
In dwc2_gadget_start_isoc_ddma() function creation of desc-chain
always started from descriptor 0. Before filling descriptors, they
were initialized by HOST BUSY status.
In dwc2_gadget_complete_isoc_request_ddma() added checking for
desc-chain rollover. Also added checking completion status.
Request completed successfully if DEV_DMA_STS is DEV_DMA_STS_SUCC,
otherwise complete with -ETIMEDOUT.
Actually removed dwc2_gadget_start_next_isoc_ddma() function because
now driver use only one desc-chain and instead that function added
dwc2_gadget_handle_isoc_bna() function for handling BNA interrupts.
Handling BNA interrupt done by flushing TxFIFOs for OUT EPs,
completing request with -EIO and resetting desc-chain number and
target frame to initial values for restarting transfers.
On handling NAK request completed with -ENODATA. Incremented target
frame to allow fill desc chain and start transfers.
In DDMA mode avoided of frame number incrementing, because tracking
of frame number performed in dwc2_gadget_fill_isoc_desc() function.
When core assert XferCompl along with BNA, we should ignore XferCompl
in dwc2_hsotg_epint() function.
On BNA interrupt replaced dwc2_gadget_start_next_isoc_ddma() by above
mentioned BNA handler.
In dwc2_hsotg_ep_enable() function added sanity check of bInterval
for ISOC IN in DDMA mode, because HW not supported EP's with
bInterval more than 12.
Signed-off-by: Minas Harutyunyan
---
drivers/usb/dwc2/core.h | 2 -
drivers/usb/dwc2/gadget.c | 235 ++
2 files changed, 113 insertions(+), 124 deletions(-)
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index d83be5651f87..093d078adaf4 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -178,7 +178,6 @@ struct dwc2_hsotg_req;
* @desc_list_dma: The DMA address of descriptor chain currently in use.
* @desc_list: Pointer to descriptor DMA chain head currently in use.
* @desc_count: Count of entries within the DMA descriptor chain of EP.
- * @isoc_chain_num: Number of ISOC chain currently in use - either 0 or 1.
* @next_desc: index of next free descriptor in the ISOC chain under SW
control.
* @total_data: The total number of data bytes done.
* @fifo_size: The size of the FIFO (for periodic IN endpoints)
@@ -231,7 +230,6 @@ struct dwc2_hsotg_ep {
struct dwc2_dma_desc*desc_list;
u8 desc_count;
- unsigned char isoc_chain_num;
unsigned intnext_desc;
charname[10];
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index c231321656f9..1b9c84cb58fb 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -793,9 +793,7 @@ static void dwc2_gadget_config_nonisoc_xfer_ddma(struct
dwc2_hsotg_ep *hs_ep,
* @dma_buff: usb requests dma buffer.
* @len: usb request transfer length.
*
- * Finds out index of first free entry either in the bottom or up half of
- * descriptor chain depend on which is under SW control and not processed
- * by HW. Then fills that descriptor with the data of the arrived usb request,
+ * Fills next free descriptor with the data of the arrived usb request,
* frame info, sets Last and IOC bits increments next_desc. If filled
* descriptor is not the first one, removes L bit from the previous descriptor
* status.
@@ -810,34 +808,17 @@ static int dwc2_gadget_fill_isoc_desc(struct
dwc2_hsotg_ep *hs_ep,
u32 mask = 0;
maxsize = dwc2_gadget_get_desc_params(hs_ep, &mask);
- if (len > maxsize) {
- dev_err(hsotg->dev, "wrong len %d\n", len);
- return -EINVAL;
- }
-
- /*
-* If SW has already filled half of chain, then return and wait for
-* the other chain to be processed by HW.
-*/
- if (hs_ep->next_desc == MAX_DMA_DESC_NUM_GENERIC / 2)
- return -EBUSY;
- /* Increment frame number by interval for IN */
- if (hs_ep->dir_in)
- dwc2_gadget_incr_frame_num(hs_ep);
-
- index = (M
[PATCH 3/3] usb: dwc2: Add High Bandwidth ISOC OUT support
Updated checking of chain full condition based on mult count.
For each packet in uframe (dpi) created new desc by
setting size of transfer to mps. Buffer addresses in descs
differ by mps in function dwc2_gadget_fill_isoc_desc().
In function dwc2_gadget_start_isoc_ddma() upadted loop
boundaries according to desc chain length.
In function dwc2_hsotg_ep_queue() added request length
checking for HB ISOC OUT transfers. Added dword aligned
limitation on maxpacket size for HB ISOC OUT's.
In function dwc2_gadget_complete_isoc_request_ddma()
separated processing of descs for HB ISOC OUT.
If completed descs PID equal MDATA do nothing, else
get remaining for frame descs and process them.
Actual length accumulated based on descs. Break
execution of the loop if data packet PID not MDATA.
If host sends less than mult data packets then skipping
unused desc for current uframe by restarting ISOC transfers.
In function dwc2_hsotg_ep_enable() desc chain allocation/
deallocation increased by mult times. Added bInterval
limit checking for HB ISOC OUT because on completion frame
number from desc used to check frame elapsed or no.
Signed-off-by: Minas Harutyunyan
---
drivers/usb/dwc2/gadget.c | 348 +-
1 file changed, 284 insertions(+), 64 deletions(-)
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 1b9c84cb58fb..6f081b456e61 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -806,55 +806,82 @@ static int dwc2_gadget_fill_isoc_desc(struct
dwc2_hsotg_ep *hs_ep,
u32 index;
u32 maxsize = 0;
u32 mask = 0;
+ int dpi, i;
+ /* Get descritor length limits */
maxsize = dwc2_gadget_get_desc_params(hs_ep, &mask);
index = hs_ep->next_desc;
- desc = &hs_ep->desc_list[index];
+
+ dpi = 1;
+ if (!hs_ep->dir_in)
+ dpi = hs_ep->mc;
/* Check if descriptor chain full */
- if ((desc->status >> DEV_DMA_BUFF_STS_SHIFT) ==
- DEV_DMA_BUFF_STS_HREADY) {
- dev_dbg(hsotg->dev, "%s: desc chain full\n", __func__);
- return 1;
+ for (i = 0; i < dpi; i++) {
+ /* Check descriptor chain rollover */
+ if ((index + i) >= dpi * MAX_DMA_DESC_NUM_GENERIC)
+ index = -1;
+
+ desc = &hs_ep->desc_list[index + i];
+ if ((desc->status >> DEV_DMA_BUFF_STS_SHIFT) ==
+ DEV_DMA_BUFF_STS_HREADY) {
+ dev_dbg(hsotg->dev, "%s: desc chain full\n", __func__);
+ return 1;
+ }
}
- /* Clear L bit of previous desc if more than one entries in the chain */
- if (hs_ep->next_desc)
- hs_ep->desc_list[index - 1].status &= ~DEV_DMA_L;
+ for (i = 0; i < dpi; i++) {
+ index = hs_ep->next_desc;
- dev_dbg(hsotg->dev, "%s: Filling ep %d, dir %s isoc desc # %d\n",
- __func__, hs_ep->index, hs_ep->dir_in ? "in" : "out", index);
+ /* Clear L bit of previous desc if more
+* than one entries in the chain
+*/
+ if (hs_ep->next_desc)
+ hs_ep->desc_list[index - 1].status &= ~DEV_DMA_L;
- desc->status = 0;
- desc->status |= (DEV_DMA_BUFF_STS_HBUSY << DEV_DMA_BUFF_STS_SHIFT);
+ desc = &hs_ep->desc_list[index];
- desc->buf = dma_buff;
- desc->status |= (DEV_DMA_L | DEV_DMA_IOC |
-((len << DEV_DMA_NBYTES_SHIFT) & mask));
+ dev_dbg(hsotg->dev, "%s: Filling ep %d, dir %s isoc desc #
%d\n",
+ __func__, hs_ep->index, hs_ep->dir_in ? "in" : "out",
+ index);
- if (hs_ep->dir_in) {
- desc->status |= ((hs_ep->mc << DEV_DMA_ISOC_PID_SHIFT) &
-DEV_DMA_ISOC_PID_MASK) |
- ((len % hs_ep->ep.maxpacket) ?
-DEV_DMA_SHORT : 0) |
- ((hs_ep->target_frame <<
- DEV_DMA_ISOC_FRNUM_SHIFT) &
-DEV_DMA_ISOC_FRNUM_MASK);
- }
+ desc->status = 0;
+ desc->status |= (DEV_DMA_BUFF_STS_HBUSY <<
+ DEV_DMA_BUFF_STS_SHIFT);
- desc->status &= ~DEV_DMA_BUFF_STS_MASK;
- desc->status |= (DEV_DMA_BUFF_STS_HREADY << DEV_DMA_BUFF_STS_SHIFT);
+ desc->buf = dma_buff + i * hs_ep->ep.maxpacket;
+ desc->status |= (DEV_DMA_L | DEV_DMA_IOC);
+ if (hs_ep->dir_in)
+
Re: [PATCH v2] usb: dwc3: Prevent indefinite sleep in _dwc3_set_mode during suspend/resume
Hi, On 3/16/2018 3:03 PM, Roger Quadros wrote: > On 16/03/18 13:00, Felipe Balbi wrote: >> >> Hi, >> >> Roger Quadros writes: >> >>> Hi Felipe, >>> >>> On 09/03/18 14:47, Roger Quadros wrote: In the following test we get stuck by sleeping forever in _dwc3_set_mode() after which dual-role switching doesn't work. On dra7-evm's dual-role port, - Load g_zero gadget driver and enumerate to host - suspend to mem - disconnect USB cable to host and connect otg cable with Pen drive in it. - resume system - we sleep indefinitely in _dwc3_set_mode due to. dwc3_gadget_exit()->usb_del_gadget_udc()->udc_stop()-> dwc3_gadget_stop()->wait_event_lock_irq() To fix this instead of waiting indefinitely with wait_event_lock_irq() we use wait_event_interruptible_lock_irq_timeout() and print and error message if there was a timeout. Signed-off-by: Roger Quadros >>> >>> Thanks for picking this for -next. >>> Is it better to have this in v4.16-rc fixes? >>> and also stable? v4.12+ >> >> Well, there was no "Fixes: foobar" or "Cc: stable" lines in the commit >> log ;-) >> >> The best we can do now, is wait for -rc1 and manually send the commit to >> stable. >> > > That's fine. Thanks. > Same issue seen in dwc3_gadget_ep_dequeue() function where also used wait_event_lock_irq() - as result infinite loop. Actually to fix this issue I updated condition of wait function from: !(dep->flags & DWC3_EP_END_TRANSFER_PENDING) to: !(dep->flags & DWC3_EP_END_TRANSFER_PENDING & DWC3_EP_ENABLED) Not, sure that this fix is fully correct because I'm familiar with dwc3, but this fix allow us to go forward with request dequeue. I think, need deeper investigation of infinite loop to catch root cause of it, before accept any of fixes. Thanks, Minas -- 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: dwc3: Prevent indefinite sleep in _dwc3_set_mode during suspend/resume
Hi, On 3/16/2018 4:25 PM, Felipe Balbi wrote: > > Hi, > > Minas Harutyunyan writes: >>>>> On 09/03/18 14:47, Roger Quadros wrote: >>>>>> In the following test we get stuck by sleeping forever in >>>>>> _dwc3_set_mode() >>>>>> after which dual-role switching doesn't work. >>>>>> >>>>>> On dra7-evm's dual-role port, >>>>>> - Load g_zero gadget driver and enumerate to host >>>>>> - suspend to mem >>>>>> - disconnect USB cable to host and connect otg cable with Pen drive in >>>>>> it. >>>>>> - resume system >>>>>> - we sleep indefinitely in _dwc3_set_mode due to. >>>>>> dwc3_gadget_exit()->usb_del_gadget_udc()->udc_stop()-> >>>>>> dwc3_gadget_stop()->wait_event_lock_irq() >>>>>> >>>>>> To fix this instead of waiting indefinitely with wait_event_lock_irq() >>>>>> we use wait_event_interruptible_lock_irq_timeout() and print >>>>>> and error message if there was a timeout. >>>>>> >>>>>> Signed-off-by: Roger Quadros >>>>> >>>>> Thanks for picking this for -next. >>>>> Is it better to have this in v4.16-rc fixes? >>>>> and also stable? v4.12+ >>>> >>>> Well, there was no "Fixes: foobar" or "Cc: stable" lines in the commit >>>> log ;-) >>>> >>>> The best we can do now, is wait for -rc1 and manually send the commit to >>>> stable. >>>> >>> >>> That's fine. Thanks. >>> >> >> Same issue seen in dwc3_gadget_ep_dequeue() function where also used >> wait_event_lock_irq() - as result infinite loop. > > how did this happen? During rmmod dwc3? Or, perhaps, after you unloaded > a gadget driver? > No, not during rmmod's. We using our internal USB testing tool. Test case; ISOC OUT, transfer size N frames. When host starts ISOC OUT traffic then the dwc3 based on "Transfer not ready" event in frame F starts transfers staring from frame F+4 (for bInterval=1) as result 4 requests, which already queued on device side, remain incomplete. Function driver on some timeout trying dequeue these 4 requests (without disabling EP) to complete test. For IN ISOC's these requests completed on MISSED ISOC event, but for ISOC OUT required call dequeue on some timeout. >> Actually to fix this issue I updated condition of wait function >> from: >> !(dep->flags & DWC3_EP_END_TRANSFER_PENDING) >> to: >> !(dep->flags & DWC3_EP_END_TRANSFER_PENDING & DWC3_EP_ENABLED) > > you're not fixing anything. You're, essentially, removing the entire > end transfer pending logic. yes, you are right, but how to overcome this infinite loop? Replace wait_event_lock_irq() by wait_event_interruptible_lock_irq_timeout()? The whole idea of this is that we can > disable the endpoint and wait for the End Transfer interrupt. When you > add a check for the endpoint being enabled, then that code will never > run and, thus, never wait for the End Transfer IRQ. > > If you manage to find a more reliable way of reproducing this, then make > sure to capture dwc3 tracepoints (see the documentation for details) and > let's start trying to figure out what's going on. > > cheers > -- 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 v1 0/3] usb: dwc2: gadget: Update ISOC DDMA flow.
This series fully update existing ISOC DDMA flow which initially based on 2 descriptor chains. Switching between desc chains performing based on BNA interrupt. Because of BNA interrupt few packets can be lost. 1/3 patch unmask ISOC IN BNA interrupt only. 2/3 patch changing ISOC IN/OUT flow as described above. 3/3 patch add High bandwidth ISOC OUT transfers support. All patches were tested on HAPS-DX7 platform using internal USB test tool. Changes from version 0: Fix kbuild test robot warnings on idents. Minas Harutyunyan (3): usb: dwc2: Enable BNA interrupt for IN endpoints usb: dwc2: Change ISOC DDMA flow usb: dwc2: Add High Bandwidth ISOC OUT support drivers/usb/dwc2/core.h | 2 - drivers/usb/dwc2/gadget.c | 505 -- 2 files changed, 359 insertions(+), 148 deletions(-) -- 2.11.0 -- 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 v1 2/3] usb: dwc2: Change ISOC DDMA flow
Changed existing two descriptor-chain flow to one chain.
In two-chain implementation BNA interrupt used for switching between
two chains. BNA interrupt asserted because of returning to
beginning of the chain based on L-bit of last descriptor.
Because of that we lose packets. This issue resolved by using one
desc-chain.
Removed all staff related to two desc-chain flow from
DDMA ISOC related functions.
Removed request length checking from dwc2_gadget_fill_isoc_desc()
function. Request length checking added to dwc2_hsotg_ep_queue()
function. If request length greater than descriptor limits then
request not added to queue. Additional checking done for High
Bandwidth ISOC OUT's which not supported by driver. In
dwc2_gadget_fill_isoc_desc() function also checked desc-chain
status (full or not) to avoid of reusing not yet processed
descriptors.
In dwc2_gadget_start_isoc_ddma() function creation of desc-chain
always started from descriptor 0. Before filling descriptors, they
were initialized by HOST BUSY status.
In dwc2_gadget_complete_isoc_request_ddma() added checking for
desc-chain rollover. Also added checking completion status.
Request completed successfully if DEV_DMA_STS is DEV_DMA_STS_SUCC,
otherwise complete with -ETIMEDOUT.
Actually removed dwc2_gadget_start_next_isoc_ddma() function because
now driver use only one desc-chain and instead that function added
dwc2_gadget_handle_isoc_bna() function for handling BNA interrupts.
Handling BNA interrupt done by flushing TxFIFOs for OUT EPs,
completing request with -EIO and resetting desc-chain number and
target frame to initial values for restarting transfers.
On handling NAK request completed with -ENODATA. Incremented target
frame to allow fill desc chain and start transfers.
In DDMA mode avoided of frame number incrementing, because tracking
of frame number performed in dwc2_gadget_fill_isoc_desc() function.
When core assert XferCompl along with BNA, we should ignore XferCompl
in dwc2_hsotg_epint() function.
On BNA interrupt replaced dwc2_gadget_start_next_isoc_ddma() by above
mentioned BNA handler.
In dwc2_hsotg_ep_enable() function added sanity check of bInterval
for ISOC IN in DDMA mode, because HW not supported EP's with
bInterval more than 12.
Signed-off-by: Minas Harutyunyan
---
drivers/usb/dwc2/core.h | 2 -
drivers/usb/dwc2/gadget.c | 235 ++
2 files changed, 113 insertions(+), 124 deletions(-)
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index d83be5651f87..093d078adaf4 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -178,7 +178,6 @@ struct dwc2_hsotg_req;
* @desc_list_dma: The DMA address of descriptor chain currently in use.
* @desc_list: Pointer to descriptor DMA chain head currently in use.
* @desc_count: Count of entries within the DMA descriptor chain of EP.
- * @isoc_chain_num: Number of ISOC chain currently in use - either 0 or 1.
* @next_desc: index of next free descriptor in the ISOC chain under SW
control.
* @total_data: The total number of data bytes done.
* @fifo_size: The size of the FIFO (for periodic IN endpoints)
@@ -231,7 +230,6 @@ struct dwc2_hsotg_ep {
struct dwc2_dma_desc*desc_list;
u8 desc_count;
- unsigned char isoc_chain_num;
unsigned intnext_desc;
charname[10];
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index c231321656f9..1b9c84cb58fb 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -793,9 +793,7 @@ static void dwc2_gadget_config_nonisoc_xfer_ddma(struct
dwc2_hsotg_ep *hs_ep,
* @dma_buff: usb requests dma buffer.
* @len: usb request transfer length.
*
- * Finds out index of first free entry either in the bottom or up half of
- * descriptor chain depend on which is under SW control and not processed
- * by HW. Then fills that descriptor with the data of the arrived usb request,
+ * Fills next free descriptor with the data of the arrived usb request,
* frame info, sets Last and IOC bits increments next_desc. If filled
* descriptor is not the first one, removes L bit from the previous descriptor
* status.
@@ -810,34 +808,17 @@ static int dwc2_gadget_fill_isoc_desc(struct
dwc2_hsotg_ep *hs_ep,
u32 mask = 0;
maxsize = dwc2_gadget_get_desc_params(hs_ep, &mask);
- if (len > maxsize) {
- dev_err(hsotg->dev, "wrong len %d\n", len);
- return -EINVAL;
- }
-
- /*
-* If SW has already filled half of chain, then return and wait for
-* the other chain to be processed by HW.
-*/
- if (hs_ep->next_desc == MAX_DMA_DESC_NUM_GENERIC / 2)
- return -EBUSY;
- /* Increment frame number by interval for IN */
- if (hs_ep->dir_in)
- dwc2_gadget_incr_frame_num(hs_ep);
-
- index = (M
[PATCH v1 3/3] usb: dwc2: Add High Bandwidth ISOC OUT support
Updated checking of chain full condition based on mult count.
For each packet in uframe (dpi) created new desc by
setting size of transfer to mps. Buffer addresses in descs
differ by mps in function dwc2_gadget_fill_isoc_desc().
In function dwc2_gadget_start_isoc_ddma() upadted loop
boundaries according to desc chain length.
In function dwc2_hsotg_ep_queue() added request length
checking for HB ISOC OUT transfers. Added dword aligned
limitation on maxpacket size for HB ISOC OUT's.
In function dwc2_gadget_complete_isoc_request_ddma()
separated processing of descs for HB ISOC OUT.
If completed descs PID equal MDATA do nothing, else
get remaining for frame descs and process them.
Actual length accumulated based on descs. Break
execution of the loop if data packet PID not MDATA.
If host sends less than mult data packets then skipping
unused desc for current uframe by restarting ISOC transfers.
In function dwc2_hsotg_ep_enable() desc chain allocation/
deallocation increased by mult times. Added bInterval
limit checking for HB ISOC OUT because on completion frame
number from desc used to check frame elapsed or no.
Signed-off-by: Minas Harutyunyan
---
drivers/usb/dwc2/gadget.c | 348 +-
1 file changed, 284 insertions(+), 64 deletions(-)
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 1b9c84cb58fb..a0de8f2eb0d8 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -806,55 +806,82 @@ static int dwc2_gadget_fill_isoc_desc(struct
dwc2_hsotg_ep *hs_ep,
u32 index;
u32 maxsize = 0;
u32 mask = 0;
+ int dpi, i;
+ /* Get descritor length limits */
maxsize = dwc2_gadget_get_desc_params(hs_ep, &mask);
index = hs_ep->next_desc;
- desc = &hs_ep->desc_list[index];
+
+ dpi = 1;
+ if (!hs_ep->dir_in)
+ dpi = hs_ep->mc;
/* Check if descriptor chain full */
- if ((desc->status >> DEV_DMA_BUFF_STS_SHIFT) ==
- DEV_DMA_BUFF_STS_HREADY) {
- dev_dbg(hsotg->dev, "%s: desc chain full\n", __func__);
- return 1;
+ for (i = 0; i < dpi; i++) {
+ /* Check descriptor chain rollover */
+ if ((index + i) >= dpi * MAX_DMA_DESC_NUM_GENERIC)
+ index = -1;
+
+ desc = &hs_ep->desc_list[index + i];
+ if ((desc->status >> DEV_DMA_BUFF_STS_SHIFT) ==
+ DEV_DMA_BUFF_STS_HREADY) {
+ dev_dbg(hsotg->dev, "%s: desc chain full\n", __func__);
+ return 1;
+ }
}
- /* Clear L bit of previous desc if more than one entries in the chain */
- if (hs_ep->next_desc)
- hs_ep->desc_list[index - 1].status &= ~DEV_DMA_L;
+ for (i = 0; i < dpi; i++) {
+ index = hs_ep->next_desc;
- dev_dbg(hsotg->dev, "%s: Filling ep %d, dir %s isoc desc # %d\n",
- __func__, hs_ep->index, hs_ep->dir_in ? "in" : "out", index);
+ /* Clear L bit of previous desc if more
+* than one entries in the chain
+*/
+ if (hs_ep->next_desc)
+ hs_ep->desc_list[index - 1].status &= ~DEV_DMA_L;
- desc->status = 0;
- desc->status |= (DEV_DMA_BUFF_STS_HBUSY << DEV_DMA_BUFF_STS_SHIFT);
+ desc = &hs_ep->desc_list[index];
- desc->buf = dma_buff;
- desc->status |= (DEV_DMA_L | DEV_DMA_IOC |
-((len << DEV_DMA_NBYTES_SHIFT) & mask));
+ dev_dbg(hsotg->dev, "%s: Filling ep %d, dir %s isoc desc #
%d\n",
+ __func__, hs_ep->index, hs_ep->dir_in ? "in" : "out",
+ index);
- if (hs_ep->dir_in) {
- desc->status |= ((hs_ep->mc << DEV_DMA_ISOC_PID_SHIFT) &
-DEV_DMA_ISOC_PID_MASK) |
- ((len % hs_ep->ep.maxpacket) ?
-DEV_DMA_SHORT : 0) |
- ((hs_ep->target_frame <<
- DEV_DMA_ISOC_FRNUM_SHIFT) &
-DEV_DMA_ISOC_FRNUM_MASK);
- }
+ desc->status = 0;
+ desc->status |= (DEV_DMA_BUFF_STS_HBUSY <<
+ DEV_DMA_BUFF_STS_SHIFT);
- desc->status &= ~DEV_DMA_BUFF_STS_MASK;
- desc->status |= (DEV_DMA_BUFF_STS_HREADY << DEV_DMA_BUFF_STS_SHIFT);
+ desc->buf = dma_buff + i * hs_ep->ep.maxpacket;
+ desc->status |= (DEV_DMA_L | DEV_DMA_IOC);
+ if (hs_ep->dir_in)
+
[PATCH v1 1/3] usb: dwc2: Enable BNA interrupt for IN endpoints
In DDMA mode required to enable BNA interrupt for
both directions.
Signed-off-by: Minas Harutyunyan
---
drivers/usb/dwc2/gadget.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 6c32bf26e48e..c231321656f9 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -3320,8 +3320,10 @@ void dwc2_hsotg_core_init_disconnected(struct dwc2_hsotg
*hsotg,
hsotg->regs + DOEPMSK);
/* Enable BNA interrupt for DDMA */
- if (using_desc_dma(hsotg))
+ if (using_desc_dma(hsotg)) {
dwc2_set_bit(hsotg->regs + DOEPMSK, DOEPMSK_BNAMSK);
+ dwc2_set_bit(hsotg->regs + DIEPMSK, DIEPMSK_BNAININTRMSK);
+ }
dwc2_writel(0, hsotg->regs + DAINTMSK);
--
2.11.0
--
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 v1 2/3] usb: dwc2: Change ISOC DDMA flow
Hi Zengtao, You email not received by linux-usb@vger.kernel.org. I suspect it rejected due to your email format have some issues, violate linux-usb@vger.kernel.org rules. I think you received email from linux-usb similar to this: : host vger.kernel.org[209.132.180.67] said: 550 5.7.1 Content-Policy reject msg: Your message is highly unlikely to be accepted here BF:; S1751783AbeCPIS1 (in reply to end of DATA command) Kindly request you to correct your email and resend. I will reply you as soon as will be received by linux-usb and will be seen archive. It's important that our communication archived. Thanks, Minas -- 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: dwc3: Prevent indefinite sleep in _dwc3_set_mode during suspend/resume
Hi, On 3/19/2018 12:55 PM, Felipe Balbi wrote: > > Hi, > > Minas Harutyunyan writes: >>>>>>> Thanks for picking this for -next. >>>>>>> Is it better to have this in v4.16-rc fixes? >>>>>>> and also stable? v4.12+ >>>>>> >>>>>> Well, there was no "Fixes: foobar" or "Cc: stable" lines in the commit >>>>>> log ;-) >>>>>> >>>>>> The best we can do now, is wait for -rc1 and manually send the commit to >>>>>> stable. >>>>>> >>>>> >>>>> That's fine. Thanks. >>>>> >>>> >>>> Same issue seen in dwc3_gadget_ep_dequeue() function where also used >>>> wait_event_lock_irq() - as result infinite loop. >>> >>> how did this happen? During rmmod dwc3? Or, perhaps, after you unloaded >>> a gadget driver? >>> >> No, not during rmmod's. >> We using our internal USB testing tool. Test case; ISOC OUT, transfer >> size N frames. When host starts ISOC OUT traffic then the dwc3 based on >> "Transfer not ready" event in frame F starts transfers staring from >> frame F+4 (for bInterval=1) as result 4 requests, which already queued >> on device side, remain incomplete. Function driver on some timeout >> trying dequeue these 4 requests (without disabling EP) to complete test. >> For IN ISOC's these requests completed on MISSED ISOC event, but for >> ISOC OUT required call dequeue on some timeout. > > okay > >>>> Actually to fix this issue I updated condition of wait function >>>> from: >>>> !(dep->flags & DWC3_EP_END_TRANSFER_PENDING) >>>> to: >>>> !(dep->flags & DWC3_EP_END_TRANSFER_PENDING & DWC3_EP_ENABLED) >>> >>> you're not fixing anything. You're, essentially, removing the entire >>> end transfer pending logic. >> yes, you are right, but how to overcome this infinite loop? Replace >> wait_event_lock_irq() by wait_event_interruptible_lock_irq_timeout()? > > The best way here would be to figure why we're missing command complete > IRQ in those cases. According to documentation, we *should* receive that > interrupt, so why is it missing? > Additional info on test. Core configuration is HS only mode, test speed HS, core version v2.90a. Maybe it will help to understand cause of issue. BTW, currently to pass above describe ISOC OUT test we just commented wait_event_lock_irq() in dwc3_gadget_ep_dequeue() function and successfully received request completion in function driver. Thanks, Minas -- 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: dwc3: Prevent indefinite sleep in _dwc3_set_mode during suspend/resume
Hi, On 3/19/2018 3:36 PM, Minas Harutyunyan wrote: > Hi, > > On 3/19/2018 12:55 PM, Felipe Balbi wrote: >> >> Hi, >> >> Minas Harutyunyan writes: >>>>>>>> Thanks for picking this for -next. >>>>>>>> Is it better to have this in v4.16-rc fixes? >>>>>>>> and also stable? v4.12+ >>>>>>> >>>>>>> Well, there was no "Fixes: foobar" or "Cc: stable" lines in the commit >>>>>>> log ;-) >>>>>>> >>>>>>> The best we can do now, is wait for -rc1 and manually send the commit to >>>>>>> stable. >>>>>>> >>>>>> >>>>>> That's fine. Thanks. >>>>>> >>>>> >>>>> Same issue seen in dwc3_gadget_ep_dequeue() function where also used >>>>> wait_event_lock_irq() - as result infinite loop. >>>> >>>> how did this happen? During rmmod dwc3? Or, perhaps, after you unloaded >>>> a gadget driver? >>>> >>> No, not during rmmod's. >>> We using our internal USB testing tool. Test case; ISOC OUT, transfer >>> size N frames. When host starts ISOC OUT traffic then the dwc3 based on >>> "Transfer not ready" event in frame F starts transfers staring from >>> frame F+4 (for bInterval=1) as result 4 requests, which already queued >>> on device side, remain incomplete. Function driver on some timeout >>> trying dequeue these 4 requests (without disabling EP) to complete test. >>> For IN ISOC's these requests completed on MISSED ISOC event, but for >>> ISOC OUT required call dequeue on some timeout. >> >> okay >> >>>>> Actually to fix this issue I updated condition of wait function >>>>> from: >>>>> !(dep->flags & DWC3_EP_END_TRANSFER_PENDING) >>>>> to: >>>>> !(dep->flags & DWC3_EP_END_TRANSFER_PENDING & DWC3_EP_ENABLED) >>>> >>>> you're not fixing anything. You're, essentially, removing the entire >>>> end transfer pending logic. >>> yes, you are right, but how to overcome this infinite loop? Replace >>> wait_event_lock_irq() by wait_event_interruptible_lock_irq_timeout()? >> >> The best way here would be to figure why we're missing command complete >> IRQ in those cases. According to documentation, we *should* receive that >> interrupt, so why is it missing? >> > > Additional info on test. Core configuration is HS only mode, test speed > HS, core version v2.90a. Maybe it will help to understand cause of issue. > BTW, currently to pass above describe ISOC OUT test we just commented > wait_event_lock_irq() in dwc3_gadget_ep_dequeue() function and > successfully received request completion in function driver. > Thanks, > Minas > One more info: while function driver call dequeue, host periodically send control read command to get status of test from function - test In Progress or Finished. Thanks, Minas -- 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] MAINTAINERS: Update maintainer for dwc2
On 3/20/2018 10:34 AM, Greg Kroah-Hartman wrote: > On Mon, Mar 19, 2018 at 01:06:02PM -0700, John Youn wrote: >> Update to show Minas Harutyunyan as the new maintainer for dwc2. >> >> Signed-off-by: John Youn >> --- >> MAINTAINERS | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/MAINTAINERS b/MAINTAINERS >> index 93a12af4f180..fc23eb016198 100644 >> --- a/MAINTAINERS >> +++ b/MAINTAINERS >> @@ -4119,7 +4119,7 @@ S: Supported >> F: drivers/mtd/nand/denali* >> >> DESIGNWARE USB2 DRD IP DRIVER >> -M: John Youn >> +M: Minas Harutyunyan > > Would be nice to get an ack from the new maintainer for this :) > > thanks, > > greg k-h > Acked-by: Minas Harutyunyan Done :-) Thanks, Minas -- 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 v1 2/3] usb: dwc2: Change ISOC DDMA flow
Hi Zengtao,
On 3/20/2018 6:01 AM, Zengtao (B) wrote:
> Hi Minas:
>
>
>
> A few minor comments:
>
>
>
>> -Original Message-
>
>> From: linux-usb-ow...@vger.kernel.org
>
>> [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Minas Harutyunyan
>
>> Sent: Saturday, March 17, 2018 5:10 PM
>
>> To: John Youn ; Felipe Balbi ;
>
>> Greg Kroah-Hartman ; linux-usb@vger.kernel.org
>
>> Cc: Minas Harutyunyan
>
>> Subject: [PATCH v1 2/3] usb: dwc2: Change ISOC DDMA flow
>
>>
>
>> Changed existing two descriptor-chain flow to one chain.
>
>>
>
>> In two-chain implementation BNA interrupt used for switching between two
>
>> chains. BNA interrupt asserted because of returning to beginning of the chain
>
>> based on L-bit of last descriptor.
>
>>
>
>> Because of that we lose packets. This issue resolved by using one desc-chain.
>
>>
>
>> Removed all staff related to two desc-chain flow from DDMA ISOC related
>
>> functions.
>
>>
>
>> Removed request length checking from dwc2_gadget_fill_isoc_desc() function.
>
>> Request length checking added to dwc2_hsotg_ep_queue() function. If request
>
>> length greater than descriptor limits then request not added to queue.
>
>> Additional checking done for High Bandwidth ISOC OUT's which not supported by
>
>> driver. In
>
>> dwc2_gadget_fill_isoc_desc() function also checked desc-chain status (full
>> or not)
>
>> to avoid of reusing not yet processed descriptors.
>
>>
>
>> In dwc2_gadget_start_isoc_ddma() function creation of desc-chain always
>
>> started from descriptor 0. Before filling descriptors, they were initialized
>> by
>
>> HOST BUSY status.
>
>>
>
>> In dwc2_gadget_complete_isoc_request_ddma() added checking for desc-chain
>
>> rollover. Also added checking completion status.
>
>> Request completed successfully if DEV_DMA_STS is DEV_DMA_STS_SUCC,
>
>> otherwise complete with -ETIMEDOUT.
>
>>
>
>> Actually removed dwc2_gadget_start_next_isoc_ddma() function because now
>
>> driver use only one desc-chain and instead that function added
>
>> dwc2_gadget_handle_isoc_bna() function for handling BNA interrupts.
>
>>
>
>> Handling BNA interrupt done by flushing TxFIFOs for OUT EPs, completing
>
>> request with -EIO and resetting desc-chain number and target frame to initial
>
>> values for restarting transfers.
>
>>
>
>> On handling NAK request completed with -ENODATA. Incremented target frame
>
>> to allow fill desc chain and start transfers.
>
>> In DDMA mode avoided of frame number incrementing, because tracking of
>
>> frame number performed in dwc2_gadget_fill_isoc_desc() function.
>
>>
>
>> When core assert XferCompl along with BNA, we should ignore XferCompl in
>
>> dwc2_hsotg_epint() function.
>
>>
>
>> On BNA interrupt replaced dwc2_gadget_start_next_isoc_ddma() by above
>
>> mentioned BNA handler.
>
>>
>
>> In dwc2_hsotg_ep_enable() function added sanity check of bInterval for ISOC
>> IN
>
>> in DDMA mode, because HW not supported EP's with bInterval more than 12.
>
>>
>
>> Signed-off-by: Minas Harutyunyan
>
>> ---
>
>> drivers/usb/dwc2/core.h | 2 -
>
>> drivers/usb/dwc2/gadget.c | 235
>> ++
>
>> 2 files changed, 113 insertions(+), 124 deletions(-)
>
>>
>
>> diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h index
>
>> d83be5651f87..093d078adaf4 100644
>
>> --- a/drivers/usb/dwc2/core.h
>
>> +++ b/drivers/usb/dwc2/core.h
>
>> @@ -178,7 +178,6 @@ struct dwc2_hsotg_req;
>
>> * @desc_list_dma: The DMA address of descriptor chain currently in use.
>
>> * @desc_list: Pointer to descriptor DMA chain head currently in use.
>
>> * @desc_count: Count of entries within the DMA descriptor chain of EP.
>
>> - * @isoc_chain_num: Number of ISOC chain currently in use - either 0 or 1.
>
>> * @next_desc: index of next free descriptor in the ISOC chain under SW
>
>> control.
>
>> * @total_data: The total number of data bytes done.
>
>> * @fifo_size: The size of the FIFO (for periodic IN endpoints) @@ -231,7
>
>> +230,6 @@ struct dwc2_hsotg_ep {
>
>> struct dwc2_dma_desc*desc_list;
>
>> u8 desc_count;
&g
Re: [PATCH v1 2/3] usb: dwc2: Change ISOC DDMA flow
Hi Zengtao, On 3/21/2018 6:17 AM, Zengtao (B) wrote: >> -Original Message- > >> From: linux-usb-ow...@vger.kernel.org > >> [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Minas Harutyunyan > >> Sent: Tuesday, March 20, 2018 10:40 PM > >> To: Zengtao (B) ; Minas Harutyunyan > >> ; John Youn ; > >> Felipe Balbi ; Greg Kroah-Hartman > >> ; linux-usb@vger.kernel.org > >> Subject: Re: [PATCH v1 2/3] usb: dwc2: Change ISOC DDMA flow > >> > >> Hi Zengtao, > >> > >> On 3/20/2018 6:01 AM, Zengtao (B) wrote: > >>> Hi Minas: > >>> > >>> > >>> > >>> A few minor comments: > >>> > >>> > >>> > >>>> -Original Message- > >>> > >>>> From: linux-usb-ow...@vger.kernel.org > >>> > >>>> [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Minas > >>>> Harutyunyan > >>> > >>>> Sent: Saturday, March 17, 2018 5:10 PM > >>> > >>>> To: John Youn ; Felipe Balbi > >>>> ; > >>> > >>>> Greg Kroah-Hartman ; > >>>> linux-usb@vger.kernel.org > >>> > >>>> Cc: Minas Harutyunyan > >>> > >>>> Subject: [PATCH v1 2/3] usb: dwc2: Change ISOC DDMA flow > >>> > >>>> > >>> > >>>> Changed existing two descriptor-chain flow to one chain. > >>> > >>>> > >>> > >>>> In two-chain implementation BNA interrupt used for switching between > >>>> two > >>> > >>>> chains. BNA interrupt asserted because of returning to beginning of > >>>> the chain > >>> > >>>> based on L-bit of last descriptor. > >>> > >>>> > >>> > >>>> Because of that we lose packets. This issue resolved by using one >>>> desc-chain. > >>> > >>>> > >>> > >>>> Removed all staff related to two desc-chain flow from DDMA ISOC > >>>> related > >>> > >>>> functions. > >>> > >>>> > >>> > >>>> Removed request length checking from dwc2_gadget_fill_isoc_desc() > >> function. > >>> > >>>> Request length checking added to dwc2_hsotg_ep_queue() function. If > >>>> request > >>> > >>>> length greater than descriptor limits then request not added to queue. > >>> > >>>> Additional checking done for High Bandwidth ISOC OUT's which not > >>>> supported by > >>> > >>>> driver. In > >>> > >>>> dwc2_gadget_fill_isoc_desc() function also checked desc-chain status > >>>> (full or not) > >>> > >>>> to avoid of reusing not yet processed descriptors. > >>> > >>>> > >>> > >>>> In dwc2_gadget_start_isoc_ddma() function creation of desc-chain > >>>> always > >>> > >>>> started from descriptor 0. Before filling descriptors, they were > >>>> initialized by > >>> > >>>> HOST BUSY status. > >>> > >>>> > >>> > >>>> In dwc2_gadget_complete_isoc_request_ddma() added checking for > >>>> desc-chain > >>> > >>>> rollover. Also added checking completion status. > >>> > >>>> Request completed successfully if DEV_DMA_STS is DEV_DMA_STS_SUCC, > >>> > >>>> otherwise complete with -ETIMEDOUT. > >>> > >>>> > >>> > >>>> Actually removed dwc2_gadget_start_next_isoc_ddma() function because > >>>> now > >>> > >>>> driver use only one desc-chain and instead that function added > >>> > >>>> dwc2_gadget_handle_isoc_bna() function for handling BNA interrupts. > >>> > >>>> > >>> > >>>> Handling BNA interrupt done by flushing TxFIFOs for OUT EPs, > >>>> completing > >>> > >>>> request with -EIO and resetting desc-chain number and target frame to > >>>> initial > >>> > >>>> values for res
Re: [PATCH v1 0/3] usb: dwc2: gadget: Update ISOC DDMA flow.
Hi Filipe, On 3/17/2018 1:08 PM, Minas Harutyunyan wrote: > This series fully update existing ISOC DDMA flow which initially based on > 2 descriptor chains. Switching between desc chains performing based on BNA > interrupt. Because of BNA interrupt few packets can be lost. > > 1/3 patch unmask ISOC IN BNA interrupt only. > 2/3 patch changing ISOC IN/OUT flow as described above. > 3/3 patch add High bandwidth ISOC OUT transfers support. > > All patches were tested on HAPS-DX7 platform using internal USB test tool. > > Changes from version 0: > > Fix kbuild test robot warnings on idents. > > > Minas Harutyunyan (3): >usb: dwc2: Enable BNA interrupt for IN endpoints >usb: dwc2: Change ISOC DDMA flow >usb: dwc2: Add High Bandwidth ISOC OUT support > > drivers/usb/dwc2/core.h | 2 - > drivers/usb/dwc2/gadget.c | 505 > -- > 2 files changed, 359 insertions(+), 148 deletions(-) > I need your advise on this patch series. My question is related to requests completion codes in different cases. In patch series I used follow completion codes: 1. In case of BNA. Request completed with status code -EIO; 2. In case of IN-NAK and OUT-EPDis. Request completed with status code -NODATA; 3. In case of XferComplete. Request completed with status code -NODATA or -ETIMEDOUT depend on descriptor error status: buffer flush, uf number, DPID's, etc. Are these status codes acceptable from function driver point of view? Or maybe dwc2 should complete the requests for above cases with "0" status code and function driver should rely on actual data size, not on completion code? Thanks, Minas -- 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 v1 2/3] usb: dwc2: Change ISOC DDMA flow
Hi Zengtao, On 3/21/2018 2:45 PM, Zengtao (B) wrote: > Hi Minas: > >> -Original Message----- >> From: Minas Harutyunyan [mailto:minas.harutyun...@synopsys.com] >> Sent: Wednesday, March 21, 2018 4:08 PM >> To: Zengtao (B) ; Minas Harutyunyan >> ; John Youn ; >> Felipe Balbi ; Greg Kroah-Hartman >> ; linux-usb@vger.kernel.org >> Subject: Re: [PATCH v1 2/3] usb: dwc2: Change ISOC DDMA flow >> >> Hi Zengtao, >> >> On 3/21/2018 6:17 AM, Zengtao (B) wrote: >>>> -Original Message- >>> >>>> From: linux-usb-ow...@vger.kernel.org >>> >>>> [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Minas >>>> Harutyunyan >>> >>>> Sent: Tuesday, March 20, 2018 10:40 PM >>> >>>> To: Zengtao (B) ; Minas Harutyunyan >>> >>>> ; John Youn >> ; >>> >>>> Felipe Balbi ; Greg Kroah-Hartman >>> >>>> ; linux-usb@vger.kernel.org >>> >>>> Subject: Re: [PATCH v1 2/3] usb: dwc2: Change ISOC DDMA flow >>> >>>> >>> >>>> Hi Zengtao, >>> >>>> >>> >>>> On 3/20/2018 6:01 AM, Zengtao (B) wrote: >>> >>>>> Hi Minas: >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> A few minor comments: >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>>> -Original Message- >>> >>>>> >>> >>>>>> From: linux-usb-ow...@vger.kernel.org >>> >>>>> >>> >>>>>> [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Minas >>> >>>>>> Harutyunyan >>> >>>>> >>> >>>>>> Sent: Saturday, March 17, 2018 5:10 PM >>> >>>>> >>> >>>>>> To: John Youn ; Felipe Balbi >>> >>>>>> ; >>> >>>>> >>> >>>>>> Greg Kroah-Hartman ; >>> >>>>>> linux-usb@vger.kernel.org >>> >>>>> >>> >>>>>> Cc: Minas Harutyunyan >>> >>>>> >>> >>>>>> Subject: [PATCH v1 2/3] usb: dwc2: Change ISOC DDMA flow >>> >>>>> >>> >>>>>> >>> >>>>> >>> >>>>>> Changed existing two descriptor-chain flow to one chain. >>> >>>>> >>> >>>>>> >>> >>>>> >>> >>>>>> In two-chain implementation BNA interrupt used for switching >>>>>> between >>> >>>>>> two >>> >>>>> >>> >>>>>> chains. BNA interrupt asserted because of returning to beginning of >>> >>>>>> the chain >>> >>>>> >>> >>>>>> based on L-bit of last descriptor. >>> >>>>> >>> >>>>>> >>> >>>>> >>> >>>>>> Because of that we lose packets. This issue resolved by using one >> desc-chain. >>> >>>>> >>> >>>>>> >>> >>>>> >>> >>>>>> Removed all staff related to two desc-chain flow from DDMA ISOC >>> >>>>>> related >>> >>>>> >>> >>>>>> functions. >>> >>>>> >>> >>>>>> >>> >>>>> >>> >>>>>> Removed request length checking from dwc2_gadget_fill_isoc_desc() >>> >>>> function. >>> >>>>> >>> >>>>>> Request length checking added to dwc2_hsotg_ep_queue() function. If >>> >>>>>> request >>> >>>>> >>> >>>>>> length greater than descriptor limits then request not added to queue. >>> >>>>> >>> >>>>>> Additional checking done for High Bandwidth ISOC OUT's which not >>> >>>>>> supported by >>> >>>>> >>> >>>>>> driver. In >>> >>>>> >>> >>>>>> dwc2_gadget_fill_isoc_desc() function also checked desc-chain >>>>>&g
Re: [PATCH v1 2/3] usb: dwc2: Change ISOC DDMA flow
Hi Zengtao, On 3/22/2018 1:36 PM, Zengtao (B) wrote: > Hi Minas: > >> -Original Message----- >> From: Minas Harutyunyan [mailto:minas.harutyun...@synopsys.com] >> Sent: Thursday, March 22, 2018 4:06 PM >> To: Zengtao (B) ; Minas Harutyunyan >> ; John Youn ; >> Felipe Balbi ; Greg Kroah-Hartman >> ; linux-usb@vger.kernel.org >> Subject: Re: [PATCH v1 2/3] usb: dwc2: Change ISOC DDMA flow >> >> Hi Zengtao, >> >> On 3/21/2018 2:45 PM, Zengtao (B) wrote: >>> Hi Minas: >>> >>>> -Original Message- >>>> From: Minas Harutyunyan [mailto:minas.harutyun...@synopsys.com] >>>> Sent: Wednesday, March 21, 2018 4:08 PM >>>> To: Zengtao (B) ; Minas Harutyunyan >>>> ; John Youn >> ; >>>> Felipe Balbi ; Greg Kroah-Hartman >>>> ; linux-usb@vger.kernel.org >>>> Subject: Re: [PATCH v1 2/3] usb: dwc2: Change ISOC DDMA flow >>>> >>>> Hi Zengtao, >>>> >>>> On 3/21/2018 6:17 AM, Zengtao (B) wrote: >>>>>> -Original Message- >>>>> >>>>>> From: linux-usb-ow...@vger.kernel.org >>>>> >>>>>> [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Minas >>>>>> Harutyunyan >>>>> >>>>>> Sent: Tuesday, March 20, 2018 10:40 PM >>>>> >>>>>> To: Zengtao (B) ; Minas Harutyunyan >>>>> >>>>>> ; John Youn >>>> ; >>>>> >>>>>> Felipe Balbi ; Greg Kroah-Hartman >>>>> >>>>>> ; linux-usb@vger.kernel.org >>>>> >>>>>> Subject: Re: [PATCH v1 2/3] usb: dwc2: Change ISOC DDMA flow >>>>> >>>>>> >>>>> >>>>>> Hi Zengtao, >>>>> >>>>>> >>>>> >>>>>> On 3/20/2018 6:01 AM, Zengtao (B) wrote: >>>>> >>>>>>> Hi Minas: >>>>> >>>>>>> >>>>> >>>>>>> >>>>> >>>>>>> >>>>> >>>>>>> A few minor comments: >>>>> >>>>>>> >>>>> >>>>>>> >>>>> >>>>>>> >>>>> >>>>>>>> -Original Message- >>>>> >>>>>>> >>>>> >>>>>>>> From: linux-usb-ow...@vger.kernel.org >>>>> >>>>>>> >>>>> >>>>>>>> [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Minas >>>>> >>>>>>>> Harutyunyan >>>>> >>>>>>> >>>>> >>>>>>>> Sent: Saturday, March 17, 2018 5:10 PM >>>>> >>>>>>> >>>>> >>>>>>>> To: John Youn ; Felipe Balbi >>>>> >>>>>>>> ; >>>>> >>>>>>> >>>>> >>>>>>>> Greg Kroah-Hartman ; >>>>> >>>>>>>> linux-usb@vger.kernel.org >>>>> >>>>>>> >>>>> >>>>>>>> Cc: Minas Harutyunyan >>>>> >>>>>>> >>>>> >>>>>>>> Subject: [PATCH v1 2/3] usb: dwc2: Change ISOC DDMA flow >>>>> >>>>>>> >>>>> >>>>>>>> >>>>> >>>>>>> >>>>> >>>>>>>> Changed existing two descriptor-chain flow to one chain. >>>>> >>>>>>> >>>>> >>>>>>>> >>>>> >>>>>>> >>>>> >>>>>>>> In two-chain implementation BNA interrupt used for switching >>>>>>>> between >>>>> >>>>>>>> two >>>>> >>>>>>> >>>>> >>>>>>>> chains. BNA interrupt asserted because of returning to beginning >>>>>>>> of >>>>> >>>>>>>> the chain >>>>> >>>>>>> >>>>> >>>>>>>> based on L-bit of last descriptor. >>>>> >>>>>>> >>>>> >>&g
Re: [PATCH v1 0/3] usb: dwc2: gadget: Update ISOC DDMA flow.
Hi Filipe, On 3/22/2018 1:05 PM, Felipe Balbi wrote: > Minas Harutyunyan writes: > >> Hi Filipe, >> >> On 3/17/2018 1:08 PM, Minas Harutyunyan wrote: >>> This series fully update existing ISOC DDMA flow which initially based on >>> 2 descriptor chains. Switching between desc chains performing based on BNA >>> interrupt. Because of BNA interrupt few packets can be lost. >>> >>> 1/3 patch unmask ISOC IN BNA interrupt only. >>> 2/3 patch changing ISOC IN/OUT flow as described above. >>> 3/3 patch add High bandwidth ISOC OUT transfers support. >>> >>> All patches were tested on HAPS-DX7 platform using internal USB test tool. >>> >>> Changes from version 0: >>> >>> Fix kbuild test robot warnings on idents. >>> >>> >>> Minas Harutyunyan (3): >>> usb: dwc2: Enable BNA interrupt for IN endpoints >>> usb: dwc2: Change ISOC DDMA flow >>> usb: dwc2: Add High Bandwidth ISOC OUT support >>> >>>drivers/usb/dwc2/core.h | 2 - >>>drivers/usb/dwc2/gadget.c | 505 >>> -- >>>2 files changed, 359 insertions(+), 148 deletions(-) >>> >> >> I need your advise on this patch series. >> >> My question is related to requests completion codes in different cases. >> In patch series I used follow completion codes: >> 1. In case of BNA. Request completed with status code -EIO; >> 2. In case of IN-NAK and OUT-EPDis. Request completed with status code >> -NODATA; >> 3. In case of XferComplete. Request completed with status code -NODATA >> or -ETIMEDOUT depend on descriptor error status: buffer flush, uf >> number, DPID's, etc. >> Are these status codes acceptable from function driver point of view? Or >> maybe dwc2 should complete the requests for above cases with "0" status >> code and function driver should rely on actual data size, not on >> completion code? > > I can't find it now, but we had documentation on accepted status codes > from usb_request completion. EINPROGRESS is used when you just queued > the request and it hasn't completed yet, ESHUTDOWN is when a disconnect > is seen, ECONNRESET is for STALL conditions or DMA aborts, or things > like that, EOVERFLOW for cases when host sends more data than promised, > 0 is for success. These are the ones I use and remember off the top of > my head and I think they are the only ones used. > Thank you for feedback. I think to update all, used by me, status codes (-EIO, -NODATA, -ETIMEDOUT) to 0 to keep consistency with original code for other non-DDMA modes. Let's function driver rely on actual size. Actually, in this error cases dwc2 served requests for some frames and to function driver will complete by status 0, which will mean request served successfully, but actual data length can be 0. Any objections? Thanks, Minas -- 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 v2 1/3] usb: dwc2: Enable BNA interrupt for IN endpoints
In DDMA mode required to enable BNA interrupt for
both directions.
Signed-off-by: Minas Harutyunyan
---
drivers/usb/dwc2/gadget.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 6c32bf26e48e..c231321656f9 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -3320,8 +3320,10 @@ void dwc2_hsotg_core_init_disconnected(struct dwc2_hsotg
*hsotg,
hsotg->regs + DOEPMSK);
/* Enable BNA interrupt for DDMA */
- if (using_desc_dma(hsotg))
+ if (using_desc_dma(hsotg)) {
dwc2_set_bit(hsotg->regs + DOEPMSK, DOEPMSK_BNAMSK);
+ dwc2_set_bit(hsotg->regs + DIEPMSK, DIEPMSK_BNAININTRMSK);
+ }
dwc2_writel(0, hsotg->regs + DAINTMSK);
--
2.11.0
--
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 v2 0/3] usb: dwc2: gadget: Update ISOC DDMA flow.
This series fully update existing ISOC DDMA flow which initially based on 2 descriptor chains. Switching between desc chains performing based on BNA interrupt. Because of BNA interrupt few packets can be lost. 1/3 patch unmask ISOC IN BNA interrupt only. 2/3 patch changing ISOC IN/OUT flow as described above. 3/3 patch add High bandwidth ISOC OUT transfers support. All patches were tested on HAPS-DX7 platform using internal USB test tool. Changes from version 1: In patch 2/3 removed redundant warning print in dwc2_hsotg_ep_queue() (Zengtao (B) ) In patch 2/3 replace loop counter from 'ret' to 'i' in dwc2_gadget_start_isoc_ddma() (Zengtao (B) ) In patch 3/3 fix 2 kbuild test robot warnings. In patch 3/3 updated target_frame number width from 11-bit to 14-bit. In patches 2/3 and 3/3 updated all requests completion status codes to 0 instead of error codes (ENODATA, EIO, ETIMEDOUT). In case of errors, set request actual length to 0, to keep consistency with original code. Changes from version 0: Fix kbuild test robot warnings on idents. Minas Harutyunyan (3): usb: dwc2: Enable BNA interrupt for IN endpoints usb: dwc2: Change ISOC DDMA flow usb: dwc2: Add High Bandwidth ISOC OUT support drivers/usb/dwc2/core.h | 2 - drivers/usb/dwc2/gadget.c | 498 -- 2 files changed, 348 insertions(+), 152 deletions(-) -- 2.11.0 -- 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 v2 2/3] usb: dwc2: Change ISOC DDMA flow
Changed existing two descriptor-chain flow to one chain.
In two-chain implementation BNA interrupt used for switching between
two chains. BNA interrupt asserted because of returning to
beginning of the chain based on L-bit of last descriptor.
Because of that we lose packets. This issue resolved by using one
desc-chain.
Removed all staff related to two desc-chain flow from
DDMA ISOC related functions.
Removed request length checking from dwc2_gadget_fill_isoc_desc()
function. Request length checking added to dwc2_hsotg_ep_queue()
function. If request length greater than descriptor limits then
request not added to queue. Additional checking done for High
Bandwidth ISOC OUT's which not supported by driver. In
dwc2_gadget_fill_isoc_desc() function also checked desc-chain
status (full or not) to avoid of reusing not yet processed
descriptors.
In dwc2_gadget_start_isoc_ddma() function creation of desc-chain
always started from descriptor 0. Before filling descriptors, they
were initialized by HOST BUSY status.
In dwc2_gadget_complete_isoc_request_ddma() added checking for
desc-chain rollover. Also added checking completion status.
Request completed successfully if DEV_DMA_STS is DEV_DMA_STS_SUCC,
otherwise complete with actual=0.
Actually removed dwc2_gadget_start_next_isoc_ddma() function because
now driver use only one desc-chain and instead that function added
dwc2_gadget_handle_isoc_bna() function for handling BNA interrupts.
Handling BNA interrupt done by flushing TxFIFOs for OUT EPs,
completing request with actual=0 and resetting desc-chain number and
target frame to initial values for restarting transfers.
On handling NAK request completed with actual=0. Incremented target
frame to allow fill desc chain and start transfers.
In DDMA mode avoided of frame number incrementing, because tracking
of frame number performed in dwc2_gadget_fill_isoc_desc() function.
When core assert XferCompl along with BNA, we should ignore XferCompl
in dwc2_hsotg_epint() function.
On BNA interrupt replaced dwc2_gadget_start_next_isoc_ddma() by above
mentioned BNA handler.
In dwc2_hsotg_ep_enable() function added sanity check of bInterval
for ISOC IN in DDMA mode, because HW not supported EP's with
bInterval more than 12.
Signed-off-by: Minas Harutyunyan
---
drivers/usb/dwc2/core.h | 2 -
drivers/usb/dwc2/gadget.c | 234 +-
2 files changed, 109 insertions(+), 127 deletions(-)
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index d83be5651f87..093d078adaf4 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -178,7 +178,6 @@ struct dwc2_hsotg_req;
* @desc_list_dma: The DMA address of descriptor chain currently in use.
* @desc_list: Pointer to descriptor DMA chain head currently in use.
* @desc_count: Count of entries within the DMA descriptor chain of EP.
- * @isoc_chain_num: Number of ISOC chain currently in use - either 0 or 1.
* @next_desc: index of next free descriptor in the ISOC chain under SW
control.
* @total_data: The total number of data bytes done.
* @fifo_size: The size of the FIFO (for periodic IN endpoints)
@@ -231,7 +230,6 @@ struct dwc2_hsotg_ep {
struct dwc2_dma_desc*desc_list;
u8 desc_count;
- unsigned char isoc_chain_num;
unsigned intnext_desc;
charname[10];
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index c231321656f9..d6a57606e49f 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -793,9 +793,7 @@ static void dwc2_gadget_config_nonisoc_xfer_ddma(struct
dwc2_hsotg_ep *hs_ep,
* @dma_buff: usb requests dma buffer.
* @len: usb request transfer length.
*
- * Finds out index of first free entry either in the bottom or up half of
- * descriptor chain depend on which is under SW control and not processed
- * by HW. Then fills that descriptor with the data of the arrived usb request,
+ * Fills next free descriptor with the data of the arrived usb request,
* frame info, sets Last and IOC bits increments next_desc. If filled
* descriptor is not the first one, removes L bit from the previous descriptor
* status.
@@ -810,34 +808,17 @@ static int dwc2_gadget_fill_isoc_desc(struct
dwc2_hsotg_ep *hs_ep,
u32 mask = 0;
maxsize = dwc2_gadget_get_desc_params(hs_ep, &mask);
- if (len > maxsize) {
- dev_err(hsotg->dev, "wrong len %d\n", len);
- return -EINVAL;
- }
-
- /*
-* If SW has already filled half of chain, then return and wait for
-* the other chain to be processed by HW.
-*/
- if (hs_ep->next_desc == MAX_DMA_DESC_NUM_GENERIC / 2)
- return -EBUSY;
- /* Increment frame number by interval for IN */
- if (hs_ep->dir_in)
- dwc2_gadget_incr_frame_num(hs_ep);
-
- index = (M
[PATCH v2 3/3] usb: dwc2: Add High Bandwidth ISOC OUT support
Updated checking of chain full condition based on mult count.
For each packet in uframe (dpi) created new desc by
setting size of transfer to mps. Buffer addresses in descs
differ by mps in function dwc2_gadget_fill_isoc_desc().
In function dwc2_gadget_start_isoc_ddma() upadted loop
boundaries according to desc chain length.
In function dwc2_hsotg_ep_queue() added request length
checking for HB ISOC OUT transfers. Added dword aligned
limitation on maxpacket size for HB ISOC OUT's.
In function dwc2_gadget_complete_isoc_request_ddma()
separated processing of descs for HB ISOC OUT.
If completed descs PID equal MDATA do nothing, else
get remaining for frame descs and process them.
Actual length accumulated based on descs. Break
execution of the loop if data packet PID not MDATA.
If host sends less than mult data packets then skipping
unused desc for current uframe by restarting ISOC transfers.
In function dwc2_hsotg_ep_enable() desc chain allocation/
deallocation increased by mult times. Added bInterval
limit checking for HB ISOC OUT because on completion frame
number from desc used to check frame elapsed or no.
Signed-off-by: Minas Harutyunyan
---
drivers/usb/dwc2/gadget.c | 344 +-
1 file changed, 278 insertions(+), 66 deletions(-)
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index d6a57606e49f..c0db308e3665 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -806,55 +806,82 @@ static int dwc2_gadget_fill_isoc_desc(struct
dwc2_hsotg_ep *hs_ep,
u32 index;
u32 maxsize = 0;
u32 mask = 0;
+ u8 dpi, i;
+ /* Get descritor length limits */
maxsize = dwc2_gadget_get_desc_params(hs_ep, &mask);
index = hs_ep->next_desc;
- desc = &hs_ep->desc_list[index];
+
+ dpi = 1;
+ if (!hs_ep->dir_in)
+ dpi = hs_ep->mc;
/* Check if descriptor chain full */
- if ((desc->status >> DEV_DMA_BUFF_STS_SHIFT) ==
- DEV_DMA_BUFF_STS_HREADY) {
- dev_dbg(hsotg->dev, "%s: desc chain full\n", __func__);
- return 1;
+ for (i = 0; i < dpi; i++) {
+ /* Check descriptor chain rollover */
+ if ((index + i) >= dpi * MAX_DMA_DESC_NUM_GENERIC)
+ index = -1;
+
+ desc = &hs_ep->desc_list[index + i];
+ if ((desc->status >> DEV_DMA_BUFF_STS_SHIFT) ==
+ DEV_DMA_BUFF_STS_HREADY) {
+ dev_dbg(hsotg->dev, "%s: desc chain full\n", __func__);
+ return 1;
+ }
}
- /* Clear L bit of previous desc if more than one entries in the chain */
- if (hs_ep->next_desc)
- hs_ep->desc_list[index - 1].status &= ~DEV_DMA_L;
+ for (i = 0; i < dpi; i++) {
+ index = hs_ep->next_desc;
- dev_dbg(hsotg->dev, "%s: Filling ep %d, dir %s isoc desc # %d\n",
- __func__, hs_ep->index, hs_ep->dir_in ? "in" : "out", index);
+ /* Clear L bit of previous desc if more
+* than one entries in the chain
+*/
+ if (hs_ep->next_desc)
+ hs_ep->desc_list[index - 1].status &= ~DEV_DMA_L;
- desc->status = 0;
- desc->status |= (DEV_DMA_BUFF_STS_HBUSY << DEV_DMA_BUFF_STS_SHIFT);
+ desc = &hs_ep->desc_list[index];
- desc->buf = dma_buff;
- desc->status |= (DEV_DMA_L | DEV_DMA_IOC |
-((len << DEV_DMA_NBYTES_SHIFT) & mask));
+ dev_dbg(hsotg->dev, "%s: Filling ep %d, dir %s isoc desc #
%d\n",
+ __func__, hs_ep->index, hs_ep->dir_in ? "in" : "out",
+ index);
- if (hs_ep->dir_in) {
- desc->status |= ((hs_ep->mc << DEV_DMA_ISOC_PID_SHIFT) &
-DEV_DMA_ISOC_PID_MASK) |
- ((len % hs_ep->ep.maxpacket) ?
-DEV_DMA_SHORT : 0) |
- ((hs_ep->target_frame <<
- DEV_DMA_ISOC_FRNUM_SHIFT) &
-DEV_DMA_ISOC_FRNUM_MASK);
- }
+ desc->status = 0;
+ desc->status |= (DEV_DMA_BUFF_STS_HBUSY <<
+ DEV_DMA_BUFF_STS_SHIFT);
- desc->status &= ~DEV_DMA_BUFF_STS_MASK;
- desc->status |= (DEV_DMA_BUFF_STS_HREADY << DEV_DMA_BUFF_STS_SHIFT);
+ desc->buf = dma_buff + i * hs_ep->ep.maxpacket;
+ desc->status |= (DEV_DMA_L | DEV_DMA_IOC);
+ if (hs_ep->dir_in)
+
Re: [PATCH -next] usb: dwc2: pci: Fix error return code in dwc2_pci_probe()
On 3/30/2018 11:35 AM, Grigor Tovmasyan wrote:
> On 3/28/2018 5:36 PM, Wei Yongjun wrote:
>> Fix to return error code -ENOMEM from the alloc fail error handling
>> case instead of 0, as done elsewhere in this function.
>>
>> Fixes: ecd29dabb2ba ("usb: dwc2: pci: Handle error cleanup in probe")
>> Signed-off-by: Wei Yongjun
>
> Reviewed-by: Grigor Tovmasyan
Acked-by: Minas Harutyunyan
>
>> ---
>>drivers/usb/dwc2/pci.c | 4 +++-
>>1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/usb/dwc2/pci.c b/drivers/usb/dwc2/pci.c
>> index 7f21747..bea2e8e 100644
>> --- a/drivers/usb/dwc2/pci.c
>> +++ b/drivers/usb/dwc2/pci.c
>> @@ -141,8 +141,10 @@ static int dwc2_pci_probe(struct pci_dev *pci,
>> goto err;
>>
>> glue = devm_kzalloc(dev, sizeof(*glue), GFP_KERNEL);
>> -if (!glue)
>> +if (!glue) {
>> +ret = -ENOMEM;
>> goto err;
>> +}
>>
>> ret = platform_device_add(dwc2);
>> if (ret) {
>>
>> --
>> 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
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__vger.kernel.org_majordomo-2Dinfo.html&d=DwICAw&c=DPL6_X_6JkXFx7AXWqB0tg&r=K1ULVL1slpLXpMJJlAXSOxws4tRq0IkTBqxDkyW2hUQ&m=6vLEHiNG2gKkx9F-l1Yy77Kde75g7qA8Aw3fKXaQgCI&s=rFkdkzcIhy-tbIL8_skjqNXbFvj1Iolbh9CZ4-LNt4U&e=
>>
>
>
--
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: dwc2: dwc2_vbus_supply_init: fix error check
Hi Tomeu,
On 3/26/2018 1:01 PM, Tomeu Vizoso wrote:
> devm_regulator_get_optional returns -ENODEV if the regulator isn't
> there, so if that's the case we have to make sure not to leave -ENODEV
> in the regulator pointer.
>
> Also, make sure we return 0 in that case, but correctly propagate any
> other errors. Also propagate the error from _dwc2_hcd_start.
>
> Fixes: 531ef5ebea96 ("usb: dwc2: add support for host mode external vbus
> supply")
> Cc: Amelie Delaunay
> Signed-off-by: Tomeu Vizoso
>
> ---
>
> v2: Only overwrite the error in the pointer after checking it (Heiko
> Stübner )
> v3: Remove hunks that shouldn't be in this patch
> v4: Don't overwrite the error code before returning it (kbuild test
> robot )
> ---
> drivers/usb/dwc2/hcd.c | 13 -
> 1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
> index 190f95964000..c51b73b3e048 100644
> --- a/drivers/usb/dwc2/hcd.c
> +++ b/drivers/usb/dwc2/hcd.c
> @@ -358,9 +358,14 @@ static void dwc2_gusbcfg_init(struct dwc2_hsotg *hsotg)
>
> static int dwc2_vbus_supply_init(struct dwc2_hsotg *hsotg)
> {
> + int ret;
> +
> hsotg->vbus_supply = devm_regulator_get_optional(hsotg->dev, "vbus");
> - if (IS_ERR(hsotg->vbus_supply))
> - return 0;
> + if (IS_ERR(hsotg->vbus_supply)) {
> + ret = PTR_ERR(hsotg->vbus_supply);
> + hsotg->vbus_supply = NULL;
> + return ret == -ENODEV ? 0 : ret;
> + }
>
> return regulator_enable(hsotg->vbus_supply);
> }
> @@ -4342,9 +4347,7 @@ static int _dwc2_hcd_start(struct usb_hcd *hcd)
>
> spin_unlock_irqrestore(&hsotg->lock, flags);
>
> - dwc2_vbus_supply_init(hsotg);
> -
> - return 0;
> + return dwc2_vbus_supply_init(hsotg);
> }
>
> /*
>
Not able to apply patch. Please rebase to balbi/next
Thanks,
Minas
--
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: dwc2: dwc2_vbus_supply_init: fix error check
On 4/5/2018 12:59 PM, Grigor Tovmasyan wrote:
> On 3/26/2018 1:01 PM, Tomeu Vizoso wrote:
>> devm_regulator_get_optional returns -ENODEV if the regulator isn't
>> there, so if that's the case we have to make sure not to leave -ENODEV
>> in the regulator pointer.
>>
>> Also, make sure we return 0 in that case, but correctly propagate any
>> other errors. Also propagate the error from _dwc2_hcd_start.
>>
>> Fixes: 531ef5ebea96 ("usb: dwc2: add support for host mode external vbus
>> supply")
>> Cc: Amelie Delaunay
>> Signed-off-by: Tomeu Vizoso
>>
>> ---
>>
>> v2: Only overwrite the error in the pointer after checking it (Heiko
>> Stübner )
>> v3: Remove hunks that shouldn't be in this patch
>> v4: Don't overwrite the error code before returning it (kbuild test
>> robot )
>> ---
>>drivers/usb/dwc2/hcd.c | 13 -
>>1 file changed, 8 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
>> index 190f95964000..c51b73b3e048 100644
>> --- a/drivers/usb/dwc2/hcd.c
>> +++ b/drivers/usb/dwc2/hcd.c
>> @@ -358,9 +358,14 @@ static void dwc2_gusbcfg_init(struct dwc2_hsotg *hsotg)
>>
>>static int dwc2_vbus_supply_init(struct dwc2_hsotg *hsotg)
>>{
>> +int ret;
>> +
>> hsotg->vbus_supply = devm_regulator_get_optional(hsotg->dev, "vbus");
>> -if (IS_ERR(hsotg->vbus_supply))
>> -return 0;
>> +if (IS_ERR(hsotg->vbus_supply)) {
>> +ret = PTR_ERR(hsotg->vbus_supply);
>> +hsotg->vbus_supply = NULL;
>> +return ret == -ENODEV ? 0 : ret;
>> +}
>>
>> return regulator_enable(hsotg->vbus_supply);
>> }
>> @@ -4342,9 +4347,7 @@ static int _dwc2_hcd_start(struct usb_hcd *hcd)
>>
>> spin_unlock_irqrestore(&hsotg->lock, flags);
>>
>> -dwc2_vbus_supply_init(hsotg);
>> -
>> -return 0;
>> +return dwc2_vbus_supply_init(hsotg);
>>}
>>
>>/*
>>
>
> Reviewed-by: Grigor Tovmasyan
>
Acked-by: Minas Harutyunyan
--
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: dwc2: Fix kernel doc's warnings.
mode
> + * @isoc_td_last:Index of last activated isochronous transfer
> + * descriptor in Descriptor DMA mode
>*
>* A Queue Transfer Descriptor (QTD) holds the state of a bulk, control,
>* interrupt, or isochronous transfer. A single QTD is created for each URB
> diff --git a/drivers/usb/dwc2/hcd_ddma.c b/drivers/usb/dwc2/hcd_ddma.c
> index 28c8898b3b66..74f11c823f79 100644
> --- a/drivers/usb/dwc2/hcd_ddma.c
> +++ b/drivers/usb/dwc2/hcd_ddma.c
> @@ -332,6 +332,7 @@ static void dwc2_release_channel_ddma(struct dwc2_hsotg
> *hsotg,
>*
>* @hsotg: The HCD state structure for the DWC OTG controller
>* @qh:The QH to init
> + * @mem_flags: Indicates the type of memory allocation
>*
>* Return: 0 if successful, negative error code otherwise
>*
> diff --git a/drivers/usb/dwc2/hcd_intr.c b/drivers/usb/dwc2/hcd_intr.c
> index a5dfd9d8bd9a..fbea5e3fb947 100644
> --- a/drivers/usb/dwc2/hcd_intr.c
> +++ b/drivers/usb/dwc2/hcd_intr.c
> @@ -478,6 +478,12 @@ static u32 dwc2_get_actual_xfer_length(struct dwc2_hsotg
> *hsotg,
>* of the URB based on the number of bytes transferred via the host channel.
>* Sets the URB status if the data transfer is finished.
>*
> + * @hsotg: Programming view of the DWC_otg controller
> + * @chan: Programming view of host channel
> + * @chnum: Channel number
> + * @urb: Processing URB
> + * @qtd: Queue transfer descriptor
> + *
>* Return: 1 if the data transfer specified by the URB is completely
> finished,
>* 0 otherwise
>*/
> @@ -566,6 +572,12 @@ void dwc2_hcd_save_data_toggle(struct dwc2_hsotg *hsotg,
>* halt_status. Completes the Isochronous URB if all the URB frames have
> been
>* completed.
>*
> + * @hsotg: Programming view of the DWC_otg controller
> + * @chan: Programming view of host channel
> + * @chnum: Channel number
> + * @halt_status: Reason for halting a host channel
> + * @qtd: Queue transfer descriptor
> + *
>* Return: DWC2_HC_XFER_COMPLETE if there are more frames remaining to be
>* transferred in the URB. Otherwise return DWC2_HC_XFER_URB_COMPLETE.
>*/
> diff --git a/drivers/usb/dwc2/hcd_queue.c b/drivers/usb/dwc2/hcd_queue.c
> index e34ad5e65350..d7c3d6c776d8 100644
> --- a/drivers/usb/dwc2/hcd_queue.c
> +++ b/drivers/usb/dwc2/hcd_queue.c
> @@ -679,6 +679,7 @@ static int dwc2_hs_pmap_schedule(struct dwc2_hsotg
> *hsotg, struct dwc2_qh *qh,
>*
>* @hsotg: The HCD state structure for the DWC OTG controller.
>* @qh: QH for the periodic transfer.
> + * @index: Transfer index
>*/
> static void dwc2_hs_pmap_unschedule(struct dwc2_hsotg *hsotg,
> struct dwc2_qh *qh, int index)
> @@ -1276,7 +1277,7 @@ static void dwc2_do_unreserve(struct dwc2_hsotg *hsotg,
> struct dwc2_qh *qh)
>* release the reservation. This worker is called after the appropriate
>* delay.
>*
> - * @work: Pointer to a qh unreserve_work.
> + * @t: Address to a qh unreserve_work.
>*/
> static void dwc2_unreserve_timer_fn(struct timer_list *t)
> {
> @@ -1631,7 +1632,7 @@ static void dwc2_qh_init(struct dwc2_hsotg *hsotg,
> struct dwc2_qh *qh,
>* @hsotg:The HCD state structure for the DWC OTG controller
>* @urb: Holds the information about the device/endpoint needed
>*to initialize the QH
> - * @atomic_alloc: Flag to do atomic allocation if needed
> + * @mem_flags: Flags for allocating memory.
>*
>* Return: Pointer to the newly allocated QH, or NULL on error
>*/
> diff --git a/drivers/usb/dwc2/params.c b/drivers/usb/dwc2/params.c
> index b3871fcafe1e..4766c3d4dcbd 100644
> --- a/drivers/usb/dwc2/params.c
> +++ b/drivers/usb/dwc2/params.c
> @@ -269,6 +269,9 @@ static void dwc2_set_param_power_down(struct dwc2_hsotg
> *hsotg)
> /**
>* dwc2_set_default_params() - Set all core parameters to their
>* auto-detected default values.
> + *
> + * @hsotg: Programming view of the DWC_otg controller
> + *
>*/
> static void dwc2_set_default_params(struct dwc2_hsotg *hsotg)
> {
> @@ -338,6 +341,8 @@ static void dwc2_set_default_params(struct dwc2_hsotg
> *hsotg)
> /**
>* dwc2_get_device_properties() - Read in device properties.
>*
> + * @hsotg: Programming view of the DWC_otg controller
> + *
>* Read in the device properties and adjust core parameters if needed.
>*/
> static void dwc2_get_device_properties(struct dwc2_hsotg *hsotg)
> @@ -688,6 +693,9 @@ static void dwc2_get_dev_hwparams(struct dwc2_hsotg
> *hsotg)
> /**
>* During device initialization, read various hardware configuration
>* registers and interpret the contents.
> + *
> + * @hsotg: Programming view of the DWC_otg controller
> + *
>*/
> int dwc2_get_hwparams(struct dwc2_hsotg *hsotg)
> {
> diff --git a/drivers/usb/dwc2/pci.c b/drivers/usb/dwc2/pci.c
> index 7f21747007f1..e9e26f021a89 100644
> --- a/drivers/usb/dwc2/pci.c
> +++ b/drivers/usb/dwc2/pci.c
> @@ -77,6 +77,12 @@ static int dwc2_pci_quirks(struct pci_dev *pdev, struct
> platform_device *dwc2)
> return 0;
> }
>
> +/**
> + * dwc2_pci_probe() - Provides the cleanup entry points for the DWC_otg PCI
> + * driver
> + *
> + * @pci: The programming view of DWC_otg PCI
> + */
> static void dwc2_pci_remove(struct pci_dev *pci)
> {
> struct dwc2_pci_glue *glue = pci_get_drvdata(pci);
>
Acked-by: Minas Harutyunyan
--
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: dwc3: Prevent indefinite sleep in _dwc3_set_mode during suspend/resume
Hi Filipe, On 3/19/2018 5:53 PM, Minas Harutyunyan wrote: > Hi, > > On 3/19/2018 3:36 PM, Minas Harutyunyan wrote: >> Hi, >> >> On 3/19/2018 12:55 PM, Felipe Balbi wrote: >>> >>> Hi, >>> >>> Minas Harutyunyan writes: >>>>>>>>> Thanks for picking this for -next. >>>>>>>>> Is it better to have this in v4.16-rc fixes? >>>>>>>>> and also stable? v4.12+ >>>>>>>> >>>>>>>> Well, there was no "Fixes: foobar" or "Cc: stable" lines in the commit >>>>>>>> log ;-) >>>>>>>> >>>>>>>> The best we can do now, is wait for -rc1 and manually send the commit >>>>>>>> to >>>>>>>> stable. >>>>>>>> >>>>>>> >>>>>>> That's fine. Thanks. >>>>>>> >>>>>> >>>>>> Same issue seen in dwc3_gadget_ep_dequeue() function where also used >>>>>> wait_event_lock_irq() - as result infinite loop. >>>>> >>>>> how did this happen? During rmmod dwc3? Or, perhaps, after you unloaded >>>>> a gadget driver? >>>>> >>>> No, not during rmmod's. >>>> We using our internal USB testing tool. Test case; ISOC OUT, transfer >>>> size N frames. When host starts ISOC OUT traffic then the dwc3 based on >>>> "Transfer not ready" event in frame F starts transfers staring from >>>> frame F+4 (for bInterval=1) as result 4 requests, which already queued >>>> on device side, remain incomplete. Function driver on some timeout >>>> trying dequeue these 4 requests (without disabling EP) to complete test. >>>> For IN ISOC's these requests completed on MISSED ISOC event, but for >>>> ISOC OUT required call dequeue on some timeout. >>> >>> okay >>> >>>>>> Actually to fix this issue I updated condition of wait function >>>>>> from: >>>>>> !(dep->flags & DWC3_EP_END_TRANSFER_PENDING) >>>>>> to: >>>>>> !(dep->flags & DWC3_EP_END_TRANSFER_PENDING & DWC3_EP_ENABLED) >>>>> >>>>> you're not fixing anything. You're, essentially, removing the entire >>>>> end transfer pending logic. >>>> yes, you are right, but how to overcome this infinite loop? Replace >>>> wait_event_lock_irq() by wait_event_interruptible_lock_irq_timeout()? >>> >>> The best way here would be to figure why we're missing command complete >>> IRQ in those cases. According to documentation, we *should* receive that >>> interrupt, so why is it missing? >>> >> >> Additional info on test. Core configuration is HS only mode, test speed >> HS, core version v2.90a. Maybe it will help to understand cause of issue. >> BTW, currently to pass above describe ISOC OUT test we just commented >> wait_event_lock_irq() in dwc3_gadget_ep_dequeue() function and >> successfully received request completion in function driver. >> Thanks, >> Minas >> > > One more info: while function driver call dequeue, host periodically > send control read command to get status of test from function - test In > Progress or Finished. > Thanks, > Minas > Your last dwc3 patch series allow us to successfully dequeuing remaining requests without falling in to infinite loop. Thank you, Minas -- 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: dwc2: dwc2_vbus_supply_init: fix error check
Hi Heiko,
On 4/10/2018 4:28 PM, Heiko Stuebner wrote:
> Am Montag, 26. März 2018, 11:00:01 CEST schrieb Tomeu Vizoso:
>> devm_regulator_get_optional returns -ENODEV if the regulator isn't
>> there, so if that's the case we have to make sure not to leave -ENODEV
>> in the regulator pointer.
>>
>> Also, make sure we return 0 in that case, but correctly propagate any
>> other errors. Also propagate the error from _dwc2_hcd_start.
>>
>> Fixes: 531ef5ebea96 ("usb: dwc2: add support for host mode external vbus
>> supply")
>> Cc: Amelie Delaunay
>> Signed-off-by: Tomeu Vizoso
>
> The patch that gets fixed here also breaks display-output on dwc2-based
> Rockchip devices (likely even more), probably due to making the regulator
> framework hickup.
>
Could you please elaborate what mean "breaks display-output".
On which Kernel version you apply this patch?
Thanks,
Minas
> With this patch applied, apart from not seeing the NULL-ptr, I also get
> display output on my rk3288-veycron Chromebook again, so
>
> Tested-by: Heiko Stuebner
>
>
>> v2: Only overwrite the error in the pointer after checking it (Heiko
>> Stübner )
>> v3: Remove hunks that shouldn't be in this patch
>> v4: Don't overwrite the error code before returning it (kbuild test
>> robot )
>> ---
>> drivers/usb/dwc2/hcd.c | 13 -
>> 1 file changed, 8 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
>> index 190f95964000..c51b73b3e048 100644
>> --- a/drivers/usb/dwc2/hcd.c
>> +++ b/drivers/usb/dwc2/hcd.c
>> @@ -358,9 +358,14 @@ static void dwc2_gusbcfg_init(struct dwc2_hsotg *hsotg)
>>
>> static int dwc2_vbus_supply_init(struct dwc2_hsotg *hsotg)
>> {
>> +int ret;
>> +
>> hsotg->vbus_supply = devm_regulator_get_optional(hsotg->dev, "vbus");
>> -if (IS_ERR(hsotg->vbus_supply))
>> -return 0;
>> +if (IS_ERR(hsotg->vbus_supply)) {
>> +ret = PTR_ERR(hsotg->vbus_supply);
>> +hsotg->vbus_supply = NULL;
>> +return ret == -ENODEV ? 0 : ret;
>> +}
>>
>> return regulator_enable(hsotg->vbus_supply);
>> }
>> @@ -4342,9 +4347,7 @@ static int _dwc2_hcd_start(struct usb_hcd *hcd)
>>
>> spin_unlock_irqrestore(&hsotg->lock, flags);
>>
>> -dwc2_vbus_supply_init(hsotg);
>> -
>> -return 0;
>> +return dwc2_vbus_supply_init(hsotg);
>> }
>>
>> /*
>>
>
>
>
--
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: dwc2: dwc2_vbus_supply_init: fix error check
Hi Heiko,
On 4/10/2018 7:37 PM, Heiko Stübner wrote:
> Am Dienstag, 10. April 2018, 15:52:25 CEST schrieb Minas Harutyunyan:
>> Hi Heiko,
>>
>> On 4/10/2018 4:28 PM, Heiko Stuebner wrote:
>>> Am Montag, 26. März 2018, 11:00:01 CEST schrieb Tomeu Vizoso:
>>>> devm_regulator_get_optional returns -ENODEV if the regulator isn't
>>>> there, so if that's the case we have to make sure not to leave -ENODEV
>>>> in the regulator pointer.
>>>>
>>>> Also, make sure we return 0 in that case, but correctly propagate any
>>>> other errors. Also propagate the error from _dwc2_hcd_start.
>>>>
>>>> Fixes: 531ef5ebea96 ("usb: dwc2: add support for host mode external vbus
>>>> supply") Cc: Amelie Delaunay
>>>> Signed-off-by: Tomeu Vizoso
>>>
>>> The patch that gets fixed here also breaks display-output on dwc2-based
>>> Rockchip devices (likely even more), probably due to making the regulator
>>> framework hickup.
>>
>> Could you please elaborate what mean "breaks display-output".
>> On which Kernel version you apply this patch?
>
> I think I may have written that poorly. _Without_ this patch I get
> display breakage on the most recent torvalds/master (merge-window)
> where "usb: dwc2: add support for host mode external vbus supply" is
> applied and this patch fixes the issue.
>
> "breaks display output" means both hdmi + edp output are missing
> also including the backlight staying off.
>
> The patch we're fixing here, causes a null-pointer dereference in the
> regulator framework, which seems to also cause issues when other
> regulators are enabled, which I think is what I'm seeing here.
>
>
Thank you for clarification. Earlier you added "reviewed" tag, this
feedback can assumed as "tested" tag.
Thanks,
Minas
> Heiko
>
>>
>> Thanks,
>> Minas
>>
>>> With this patch applied, apart from not seeing the NULL-ptr, I also get
>>> display output on my rk3288-veycron Chromebook again, so
>>>
>>> Tested-by: Heiko Stuebner
>>>
>>>> v2: Only overwrite the error in the pointer after checking it (Heiko
>>>>
>>>> Stübner )
>>>>
>>>> v3: Remove hunks that shouldn't be in this patch
>>>> v4: Don't overwrite the error code before returning it (kbuild test
>>>>
>>>> robot )
>>>>
>>>> ---
>>>>
>>>>drivers/usb/dwc2/hcd.c | 13 -
>>>>1 file changed, 8 insertions(+), 5 deletions(-)
>>>>
>>>> diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
>>>> index 190f95964000..c51b73b3e048 100644
>>>> --- a/drivers/usb/dwc2/hcd.c
>>>> +++ b/drivers/usb/dwc2/hcd.c
>>>> @@ -358,9 +358,14 @@ static void dwc2_gusbcfg_init(struct dwc2_hsotg
>>>> *hsotg)>>
>>>>static int dwc2_vbus_supply_init(struct dwc2_hsotg *hsotg)
>>>>{
>>>>
>>>> + int ret;
>>>> +
>>>>
>>>>hsotg->vbus_supply = devm_regulator_get_optional(hsotg->dev,
>>>> "vbus");
>>>>
>>>> - if (IS_ERR(hsotg->vbus_supply))
>>>> - return 0;
>>>> + if (IS_ERR(hsotg->vbus_supply)) {
>>>> + ret = PTR_ERR(hsotg->vbus_supply);
>>>> + hsotg->vbus_supply = NULL;
>>>> + return ret == -ENODEV ? 0 : ret;
>>>> + }
>>>>
>>>>return regulator_enable(hsotg->vbus_supply);
>>>>
>>>>}
>>>>
>>>> @@ -4342,9 +4347,7 @@ static int _dwc2_hcd_start(struct usb_hcd *hcd)
>>>>
>>>>spin_unlock_irqrestore(&hsotg->lock, flags);
>>>>
>>>> - dwc2_vbus_supply_init(hsotg);
>>>> -
>>>> - return 0;
>>>> + return dwc2_vbus_supply_init(hsotg);
>>>>
>>>>}
>>>>
>>>>/*
>
>
>
--
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 v1 0/2] usb: dwc2: gadget: Fixes for LPM
On 4/10/2018 2:21 PM, Grigor Tovmasyan wrote: > Here are two little fixes for LPM feature. > > First one is coverity warning fix. > > The Second one was asserted by Stefan Wahren. > > Changes from version 0: > > 1/2: > - Instead of converting parameter in the CHECK_RANGE macro > to int, changed hird_threshold type from u8 to int. > > > Grigor Tovmasyan (2): >usb: dwc2: gadget: Fix coverity issue >usb: dwc2: gadget: Change LPM default values > > drivers/usb/dwc2/core.h | 2 +- > drivers/usb/dwc2/params.c | 8 > 2 files changed, 5 insertions(+), 5 deletions(-) > Acked-by: Minas Harutyunyan -- 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: dwc2 ff540000.usb: dwc2_hc_chhltd_intr_dma: Channel 11 - ChHltd set, but reason is unknown
Hi Rodrigo, On 4/16/2018 7:27 PM, Rodrigo Stuffs wrote: > Hi there Minas / linux-usb ; > > I have a good ole APC Back-UPS ES 600N that from time to time resolves > that it should stop talking to my SBCs. > > This issue happened in my Raspberry Pi, and when it stopped I had the > following printk: > > Apr 11 14:10:15 localhost kernel: [9416331.806123] hid-generic > 0003:051D:0002.000A: usb_submit_urb(ctrl) failed: -1 > > All I had to do is monitor the graphics and when it flatlined, unplug > and plug the UPS usb port. Until the next occurrence. Well, I lived > with it for some good years. > > Last weekend I changed the Raspberry Pi with a TinkerBoard. And the > cranky UPS is also tickling TinkerBoard's USB port. Now the issue > manifests in a slightly different way: > > == DEVICE ENUMERATION == > [56529.462106] usb 1-1.1.3: new low-speed USB device number 9 using dwc2 > [56530.222538] usb 1-1.1.3: New USB device found, idVendor=051d, > idProduct=0002 > [56530.222638] usb 1-1.1.3: New USB device strings: Mfr=3, Product=1, > SerialNumber=2 > [56530.222697] usb 1-1.1.3: Product: Back-UPS ES 600N FW:876.Q1j.D USB FW:Q1j > [56530.222772] usb 1-1.1.3: Manufacturer: APC > [56530.222821] usb 1-1.1.3: SerialNumber: 5B1017T20483 > [56535.075030] hid-generic 0003:051D:0002.0003: hiddev0,hidraw1: USB > HID v1.10 Device [APC Back-UPS ES 600N FW:876.Q1j.D USB FW:Q1j] on > usb-ff54.usb-1.1.3/input0 > > == KERNEL WHINES == > [105243.156331] dwc2 ff54.usb: dwc2_hc_chhltd_intr_dma: Channel 11 > - ChHltd set, but reason is unknown > [105243.156414] dwc2 ff54.usb: hcint 0x0002, intsts 0x06600029 > [105273.536188] dwc2 ff54.usb: dwc2_hc_chhltd_intr_dma: Channel 13 > - ChHltd set, but reason is unknown > [105273.536268] dwc2 ff54.usb: hcint 0x0002, intsts 0x06600029 > > Well, in spirit to getting things going nicely in the new system, I > have found the thread: > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.spinics.net_lists_linux-2Dusb_msg161854.html&d=DwIFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=cQBKt4q-qzNVC53rNAwuwplH23V61rHQhhULvdLA0U8&m=YSUQg6kIP4Y-Gp3eOPRqJsOKFEqJhfwK5i4u4G3GSx4&s=dlmTJf4doonVjjhkGKKAInIpIaKQuPrpIpmCm5eEKGM&e= > > Where Minas suggests a patch to tackle it. > > I tried to backport the patch to my 4.4 Kernel and it was not really > happy about it: > > == COMPILE BARFS == >CC drivers/usb/dwc2/hcd.o > drivers/usb/dwc2/hcd.c: In function ‘dwc2_core_init’: > drivers/usb/dwc2/hcd.c:2191:22: error: ‘trdtrim’ undeclared (first use > in this function); did you mean ‘strstrip’? >u32 usbcfg, otgctl; trdtrim; Your backport is wrong, you used semicolon instead of comma. Should be: u32 usbcfg, otgctl, trdtrim; Thanks, Minas >^~~ >strstrip > drivers/usb/dwc2/hcd.c:2191:22: note: each undeclared identifier is > reported only once for each function it appears in > drivers/usb/dwc2/hcd.c:2192:2: warning: ISO C90 forbids mixed > declarations and code [-Wdeclaration-after-statement] > error, forbidden warning: hcd.c:2192 > scripts/Makefile.build:277: recipe for target 'drivers/usb/dwc2/hcd.o' failed > make[3]: *** [drivers/usb/dwc2/hcd.o] Error 1 > scripts/Makefile.build:484: recipe for target 'drivers/usb/dwc2' failed > make[2]: *** [drivers/usb/dwc2] Error 2 > scripts/Makefile.build:484: recipe for target 'drivers/usb' failed > make[1]: *** [drivers/usb] Error 2 > Makefile:1016: recipe for target 'drivers' failed > make: *** [drivers] Error 2 > > > > Patchset: > https://urldefense.proofpoint.com/v2/url?u=https-3A__pastebin.com_v1ink6fJ&d=DwIFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=cQBKt4q-qzNVC53rNAwuwplH23V61rHQhhULvdLA0U8&m=YSUQg6kIP4Y-Gp3eOPRqJsOKFEqJhfwK5i4u4G3GSx4&s=c0BOzNW40WKgpIngxNKxkJ4qY2bN3h7R2a2DnIBLv3Q&e= > > == QUESTIONS == > 1. What are the odds that the OP patchset will also help my issue? > 2. IF 1 == true ; then what am I doing wrong in my patch? :-) > > Appreciate your time. > -- 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 0/3] usb: dwc2: gadget: Update ISOC DDMA flow.
Hi Filipe, On 3/29/2018 6:28 PM, Minas Harutyunyan wrote: > This series fully update existing ISOC DDMA flow which initially based on > 2 descriptor chains. Switching between desc chains performing based on BNA > interrupt. Because of BNA interrupt few packets can be lost. > > 1/3 patch unmask ISOC IN BNA interrupt only. > 2/3 patch changing ISOC IN/OUT flow as described above. > 3/3 patch add High bandwidth ISOC OUT transfers support. > > All patches were tested on HAPS-DX7 platform using internal USB test tool. > > Changes from version 1: > > In patch 2/3 removed redundant warning print in dwc2_hsotg_ep_queue() > (Zengtao (B) ) > > In patch 2/3 replace loop counter from 'ret' to 'i' in > dwc2_gadget_start_isoc_ddma() (Zengtao (B) ) > > In patch 3/3 fix 2 kbuild test robot warnings. > > In patch 3/3 updated target_frame number width from 11-bit to 14-bit. > > In patches 2/3 and 3/3 updated all requests completion status codes to 0 > instead of error codes (ENODATA, EIO, ETIMEDOUT). In case of errors, > set request actual length to 0, to keep consistency with original code. > > Changes from version 0: > > Fix kbuild test robot warnings on idents. > > > Minas Harutyunyan (3): >usb: dwc2: Enable BNA interrupt for IN endpoints >usb: dwc2: Change ISOC DDMA flow >usb: dwc2: Add High Bandwidth ISOC OUT support > > drivers/usb/dwc2/core.h | 2 - > drivers/usb/dwc2/gadget.c | 498 > -- > 2 files changed, 348 insertions(+), 152 deletions(-) > Please ignore this patch set because I'm going to improve it to consider systems with high IRQ latency. Thanks, Minas -- 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: Kernel Oops when downloading data from a 4G modem connected via USB
Hi, On 4/29/2018 4:44 PM, Amr Bekhit wrote: > Hello, > > We're working with an embedded system that uses the RK3188 SoC and has a > Quectel EC25 4G modem connected via USB. We're using Buildroot 2018.02.1 to > compile the kernel (4.15.16 using the radxarock_defconfig) and root file > system. The system enumerates the USB just fine and Quectel's quectel-CM > executable is then used to start QMI and connect to the 4G network. The > connection is successful, and I can ping websites just fine. However, when > I come to download a large file, a kernel oops occurs. This happens > consistently. Here's an example log: > > # wget > https://urldefense.proofpoint.com/v2/url?u=http-3A__speedtest.tele2.net_100MB.zip&d=DwIBaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=cQBKt4q-qzNVC53rNAwuwplH23V61rHQhhULvdLA0U8&m=jJJIamtosvad_neUIcXyUCTtHjH3ue9cRjgWDi0hOTs&s=sAsFiRlSCGgMQbB2kirQXr2nURDLZn1rEGlMX5JvJ3k&e= > --2018-04-27 14:54:54-- > https://urldefense.proofpoint.com/v2/url?u=http-3A__speedtest.tele2.net_100MB.zip&d=DwIBaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=cQBKt4q-qzNVC53rNAwuwplH23V61rHQhhULvdLA0U8&m=jJJIamtosvad_neUIcXyUCTtHjH3ue9cRjgWDi0hOTs&s=sAsFiRlSCGgMQbB2kirQXr2nURDLZn1rEGlMX5JvJ3k&e= > Resolving speedtest.tele2.net... 90.130.70.73, 2a00:800:1010::1 > Connecting to speedtest.tele2.net|90.130.70.73|:80... connected. > HTTP request sent, awaiting response... 200 OK > Length: 104857600 (100M) [application/zip] > Saving to: '100MB.zip' > > 100MB.zip0%[ > >] 358.58K 1.72MB/s dwc2 101c.usb: > dwc2_hc_chhltd_intr_dma: Channel 1 - ChHltd set, but reason is unknown > dwc2 101c.usb: hcint 0x0002, intsts 0x0429 > dwc2 101c.usb: dwc2_update_urb_state_abn(): trimming xfer length > dwc2 101c.usb: dwc2_update_urb_state(): trimming xfer length > Unable to handle kernel paging request at virtual address 2f0cf7d0 > pgd = e12e3a71 > [2f0cf7d0] *pgd= > Internal error: Oops: 5 [#1] SMP ARM > Modules linked in: > CPU: 1 PID: 196 Comm: wget Not tainted 4.15.16 #2 > Hardware name: Rockchip (Device Tree) > PC is at kfree_skb_list+0x18/0x28 > LR is at skb_release_data+0x40/0x134 > pc : []lr : []psr: 2013 > sp : ef085d60 ip : ef085d78 fp : ef085d74 > r10: r9 : r8 : ee4a1084 > r7 : ef085df8 r6 : r5 : ee9b9780 r4 : eeae7f40 > r3 : r2 : 1b40 r1 : 1380 r0 : 2f0cf7d0 > Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none > Control: 10c5387d Table: 8e45804a DAC: 0051 > Process wget (pid: 196, stack limit = 0x11d0fd5f) > Stack: (0xef085d60 to 0xef086000) > 5d60: eeae7f40 ee9b9780 ef085d94 ef085d78 c05098f8 c0508f4c ee9b9780 > 1600 > 5d80: ee9b9780 ef085df8 ef085dac ef085d98 c0508ec0 c05098c4 ee9b9780 > 1600 > 5da0: ef085dc4 ef085db0 c0508ed8 c0508ea4 ee4a0cc0 1600 ef085e4c > ef085dc8 > 5dc0: c055b948 c0508ed0 effba620 eeede0b0 0004 ef085e20 > ee4a0d5c > 5de0: 0001 ee4a115c 0001 ef085e90 0a00 5ae339c0 > 1c015810 > 5e00: ef085ef0 7fff 5ae339c0 1c015810 ef085e28 ef085e2c > > 5e20: 0008 ef085e90 c055b304 ee9bdc00 eeea5500 2000 ef084000 > > 5e40: ef085e74 ef085e50 c0582410 c055b310 ef085e5c ef085edc > > 5e60: c05823c8 2000 ef085e8c ef085e78 c04fdb38 c05823d4 ef085ef0 > 2000 > 5e80: ef085edc ef085e90 c04fdbc4 c04fdb24 > 1600 > 5ea0: 0a00 ef085ee8 0001 0002 > ef085f08 > 5ec0: ee9bdc00 ef085f80 ef085f4c ef085ee0 c01eaf88 > c04fdb48 > 5ee0: 2000 00e25b18 2000 2000 > ef085ee8 > 5f00: 0001 0002 ee9bdc00 > > 5f20: be9243e0 ee9bdc00 2000 00e25b18 > ef085f80 > 5f40: ef085f7c ef085f50 c01eb044 c01eae94 c02072ac c020720c ef085f7c > ee9bdc00 > 5f60: ee9bdc00 00e25b18 2000 c0107c84 ef085fa4 ef085f80 c01eb4b0 > c01eafb8 > 5f80: 0003 0008ce08 0003 > ef085fa8 > 5fa0: c0107aa0 c01eb474 0003 0003 00e25b18 2000 > > 5fc0: 0003 0008ce08 0003 2000 000bf64d > > 5fe0: 000850a4 be924470 000164e0 b6cacaf8 6010 0003 > > Backtrace: > [] (kfree_skb_list) from [] > (skb_release_data+0x40/0x134) >r5:ee9b9780 r4:eeae7f40 > [] (skb_release_data) from [] > (skb_release_all+0x28/0x2c) >r7:ef085df8 r6:ee9b9780 r5:1600 r4:ee9b9780 > [] (skb_release_all) from [] (__kfree_skb+0x14/0x20) >r5:1600 r4:ee9b9780 > [] (__kfree_skb) from [] (tcp_recvmsg+0x644/0x8c8) >r5:1600 r4:ee4a0cc0 > [] (tcp_recvmsg) from [] (inet_recvmsg+0x48/0xc4) >r10: r9:ef084000 r8:2000 r7:eeea5500 r6:ee9bdc00 r5:c055b304 >r4:ef085e90 > [] (inet_recvmsg) from [] (sock_recvmsg+0x20/0x24) >r5:2000 r4:c05823c8 > [] (sock_recvmsg) from [] (sock_read_iter+0
Re: dwc2: enumeration issue with audio dongle connected to USB hub
Hi, On 4/27/2018 10:03 AM, Stefan Wahren wrote: > Hi, > during my tests with a Raspberry Pi 2 B with an C-Media audio dongle > connected to a powered USB hub, i noticed the enumeration errors below (the > device gets finally ernumerated). I tested yesterdays linux-next, 4.17-rc2 > and 4.14 but all of them show this behavior, if i plugin the audio dongle > into the USB hub. > > /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M > |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/5p, 480M > |__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, > Driver=smsc95xx, 480M > |__ Port 2: Dev 4, If 0, Class=Hub, Driver=hub/4p, 480M > |__ Port 3: Dev 8, If 2, Class=Audio, Driver=snd-usb-audio, 12M > |__ Port 3: Dev 8, If 0, Class=Audio, Driver=snd-usb-audio, 12M > |__ Port 3: Dev 8, If 3, Class=Human Interface Device, > Driver=usbhid, 12M > |__ Port 3: Dev 8, If 1, Class=Audio, Driver=snd-usb-audio, 12M > |__ Port 1: Dev 5, If 0, Class=Hub, Driver=hub/4p, 480M > |__ Port 4: Dev 7, If 1, Class=Human Interface Device, > Driver=usbhid, 1.5M > |__ Port 4: Dev 7, If 0, Class=Human Interface Device, > Driver=usbhid, 1.5M > > The verbose version can be found here: > https://urldefense.proofpoint.com/v2/url?u=https-3A__gist.github.com_lategoodbye_baa0f8890325f8698664aeb60ecedfd5&d=DwICaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=cQBKt4q-qzNVC53rNAwuwplH23V61rHQhhULvdLA0U8&m=oor4Ij_LNZepp0TZuefnbqFJacQjGXIOEk_BRVa4Vf8&s=qbdE3PnqX9pigSEbMTqXPeSItGUGJTIOVUapC-fZXdg&e= > > Here is an example dmesg after plugin the audio dongle: > [ 1176.382877] usb 1-1.2.1.3: new full-speed USB device number 14 using dwc2 > [ 1176.516254] dwc2 2098.usb: dwc2_hc_chhltd_intr_dma: Channel 1 - ChHltd > set, but reason is unknown > [ 1176.516284] dwc2 2098.usb: hcint 0x0402, intsts 0x0429 > [ 1176.516355] dwc2 2098.usb: dwc2_hc_chhltd_intr_dma: Channel 4 - ChHltd > set, but reason is unknown > [ 1176.516372] dwc2 2098.usb: hcint 0x0402, intsts 0x0429 > [ 1176.516427] dwc2 2098.usb: dwc2_hc_chhltd_intr_dma: Channel 6 - ChHltd > set, but reason is unknown > [ 1176.516442] dwc2 2098.usb: hcint 0x0402, intsts 0x0421 > [ 1176.518435] dwc2 2098.usb: dwc2_hc_chhltd_intr_dma: Channel 5 - ChHltd > set, but reason is unknown > [ 1176.518464] dwc2 2098.usb: hcint 0x0402, intsts 0x0421 > [ 1176.518532] dwc2 2098.usb: dwc2_hc_chhltd_intr_dma: Channel 3 - ChHltd > set, but reason is unknown > [ 1176.518549] dwc2 2098.usb: hcint 0x0402, intsts 0x0421 > [ 1176.518605] dwc2 2098.usb: dwc2_hc_chhltd_intr_dma: Channel 1 - ChHltd > set, but reason is unknown > [ 1176.518623] dwc2 2098.usb: hcint 0x0402, intsts 0x0429 > [ 1176.520704] dwc2 2098.usb: dwc2_hc_chhltd_intr_dma: Channel 3 - ChHltd > set, but reason is unknown > [ 1176.520734] dwc2 2098.usb: hcint 0x0402, intsts 0x0421 > [ 1176.520802] dwc2 2098.usb: dwc2_hc_chhltd_intr_dma: Channel 1 - ChHltd > set, but reason is unknown > [ 1176.520820] dwc2 2098.usb: hcint 0x0402, intsts 0x0421 > [ 1176.520887] dwc2 2098.usb: dwc2_hc_chhltd_intr_dma: Channel 6 - ChHltd > set, but reason is unknown > [ 1176.520905] dwc2 2098.usb: hcint 0x0402, intsts 0x0421 > [ 1176.521127] usb 1-1.2.1.3: unable to read config index 0 descriptor/all > [ 1176.521197] usb 1-1.2.1.3: can't read configurations, error -71 > [ 1176.632956] usb 1-1.2.1.3: new full-speed USB device number 15 using dwc2 > [ 1176.763789] dwc2 2098.usb: dwc2_hc_chhltd_intr_dma: Channel 6 - ChHltd > set, but reason is unknown > [ 1176.763820] dwc2 2098.usb: hcint 0x0402, intsts 0x0421 > [ 1176.763890] dwc2 2098.usb: dwc2_hc_chhltd_intr_dma: Channel 5 - ChHltd > set, but reason is unknown > [ 1176.763909] dwc2 2098.usb: hcint 0x0402, intsts 0x0421 > [ 1176.763998] dwc2 2098.usb: dwc2_hc_chhltd_intr_dma: Channel 2 - ChHltd > set, but reason is unknown > [ 1176.764016] dwc2 2098.usb: hcint 0x0402, intsts 0x0429 > [ 1177.012371] input: C-Media Electronics Inc. USB PnP Sound Device as > /devices/platform/soc/2098.usb/usb1/1-1/1-1.2/1-1.2.1/1-1.2.1.3/1-1.2.1.3:1.3/0003:0D8C:013C.0008/input/input7 > [ 1177.088948] hid-generic 0003:0D8C:013C.0008: input: USB HID v1.00 Device > [C-Media Electronics Inc. USB PnP Sound Device] on > usb-2098.usb-1.2.1.3/input3 > > Best regards > Could you please apply follow patches from linux-usb mailing list: 1. usb: dwc2: hcd: Fix host channel halt flow 2. usb: dwc2: host: Fix transaction errors in host mode and test again. Thanks, Minas -- 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: Kernel Oops when downloading data from a 4G modem connected via USB
Hi Amr, On 5/2/2018 3:57 PM, Amr Bekhit wrote: >> Could you please apply follow patches from linux-usb mailing list: >> 1. usb: dwc2: hcd: Fix host channel halt flow >> 2. usb: dwc2: host: Fix transaction errors in host mode >> and test again. > > Thanks for your response. I've tried applying the above patches (taken from > https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.kernel.org_patch_10096209_&d=DwIFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=6z9Al9FrHR_ZqbbtSAsD16pvOL2S3XHxQnSzq8kusyI&m=pm_ejbHE3SzUg3PIMfP1w4oXRQ0fr7_DBiQdmIqqmmM&s=mxPCG_fQabXNnlZ018dj25jCjn1Y9G9vEoaniEVwUUM&e= > and > https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.kernel.org_patch_10104403_&d=DwIFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=6z9Al9FrHR_ZqbbtSAsD16pvOL2S3XHxQnSzq8kusyI&m=pm_ejbHE3SzUg3PIMfP1w4oXRQ0fr7_DBiQdmIqqmmM&s=r5y16b0B30KsR6tzs43Ebhl8UUAq1IPbWt-5k3mehnI&e=) > to kernel 4.15.16. The > compilation failed with the following error: > > drivers/usb/dwc2/hcd.c: In function ‘dwc2_hc_halt’: > drivers/usb/dwc2/hcd.c:995:12: error: ‘struct dwc2_hsotg’ has no member > named ‘core_params’; did you mean ‘hw_params’? > if ((hsotg->core_params->dma_enable > 0 && > ^~ > drivers/usb/dwc2/hcd.c:996:12: error: ‘struct dwc2_hsotg’ has no member > named ‘core_params’; did you mean ‘hw_params’? > hsotg->core_params->dma_desc_enable <= 0) || > ^~ > drivers/usb/dwc2/hcd.c: In function ‘dwc2_core_host_init’: > drivers/usb/dwc2/hcd.c:2339:34: warning: unused variable ‘val’ > [-Wunused-variable] > u32 hcfg, hfir, otgctl, usbcfg, val; > ^~~ > scripts/Makefile.build:324: recipe for target 'drivers/usb/dwc2/hcd.o' > failed > > I tried to manually get the patch working by looking at the struct > definitions in core.h and modified lines hcd.c lines 995-996 as follows > (changing core_params to params and dma_enable to host_dma): > > if ((hsotg->params.host_dma > 0 && >hsotg->params.dma_desc_enable <= 0) || > > This compiles, but doesn't solve the problem. The kernel oops still occurs > with the following trace (full dmesg trace can be found at > https://urldefense.proofpoint.com/v2/url?u=https-3A__paste.ee_p_R8Ccj&d=DwIFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=6z9Al9FrHR_ZqbbtSAsD16pvOL2S3XHxQnSzq8kusyI&m=pm_ejbHE3SzUg3PIMfP1w4oXRQ0fr7_DBiQdmIqqmmM&s=3noSNdgD4z7wCWDc9Y3aNiPeRVHwYmSzh6qowy0S2fQ&e=): > > [ 50.520879] dwc2 101c.usb: --Host Channel 5 Interrupt: Transaction > Error-- > [ 57.760866] dwc2 101c.usb: --Host Channel 10 Interrupt: Transaction > Error-- > [ 57.846752] dwc2 101c.usb: --Host Channel 15 Interrupt: Transaction > Error-- > [ 57.912946] dwc2 101c.usb: --Host Channel 2 Interrupt: Transaction > Error-- > [ 57.920037] dwc2 101c.usb: --Host Channel 13 Interrupt: Transaction > Error-- > [ 57.926534] dwc2 101c.usb: --Host Channel 10 Interrupt: Transaction > Error-- > [ 57.926588] dwc2 101c.usb: dwc2_hc_chhltd_intr_dma: Channel 7 - > ChHltd set, but reason is unknown > [ 57.935448] dwc2 101c.usb: hcint 0x0002, intsts 0x0429 > [ 57.940901] dwc2 101c.usb: dwc2_update_urb_state_abn(): trimming > xfer length > [ 57.947796] dwc2 101c.usb: dwc2_update_urb_state(): trimming xfer > length > [ 57.985245] dwc2 101c.usb: --Host Channel 15 Interrupt: Transaction > Error-- > [ 57.988891] dwc2 101c.usb: --Host Channel 10 Interrupt: Transaction > Error-- > [ 57.989236] dwc2 101c.usb: --Host Channel 14 Interrupt: Transaction > Error-- > [ 58.005362] dwc2 101c.usb: --Host Channel 3 Interrupt: Transaction > Error-- > [ 58.005486] dwc2 101c.usb: --Host Channel 10 Interrupt: Transaction > Error-- > [ 58.005666] dwc2 101c.usb: --Host Channel 15 Interrupt: Transaction > Error-- > [ 58.006000] dwc2 101c.usb: --Host Channel 14 Interrupt: Transaction > Error-- > [ 58.006143] dwc2 101c.usb: --Host Channel 1 Interrupt: Transaction > Error-- > [ 58.006308] dwc2 101c.usb: --Host Channel 15 Interrupt: Transaction > Error-- > [ 58.006415] dwc2 101c.usb: --Host Channel 0 Interrupt: Transaction > Error-- > [ 58.006574] dwc2 101c.usb: --Host Channel 14 Interrupt: Transaction > Error-- > [ 58.006749] dwc2 101c.usb: --Host Channel 10 Interrupt: Transaction > Error-- > [ 58.020865] Unable to handle kernel paging request at virtual address > 76ad3ad7 > [ 58.027491] pgd = 7da1f8f3 > [ 58.029054] [76ad3ad7] *pgd= > [ 58.031650] Internal error: Oops: 5 [#1] SMP ARM > [ 58.035354] Modules linked in: > [ 58.037311] CPU: 2 PID: 175 Comm: wget Not tainted 4.15.16 #2 > [ 58.042274] Hardware name: Rockchip (Device Tree) > [ 58.046086] PC is at kfree_skb_list+0x18/0x28 > [ 58.049493] LR is at skb_release_data+0x40/0x134 > [ 58.053187] pc : []lr : []psr: 200d0013 > [ 58.058733] sp : eeb1dd60 ip : eeb1dd78 fp : eeb1dd74 > [ 58.063114] r10: r9 : r8 : ee630404 > [ 58.067497] r7 : eeb1ddf8 r6 :
[PATCH] usb: dwc2: Change ISOC DDMA flow
Changed existing two descriptor-chain flow to one chain.
In two-chain implementation BNA interrupt used for switching between
two chains. BNA interrupt asserted because of returning to
beginning of the chain based on L-bit of last descriptor.
Because of that we lose packets. This issue resolved by using one
desc-chain.
Removed all staff related to two desc-chain flow from
DDMA ISOC related functions.
Removed request length checking from dwc2_gadget_fill_isoc_desc()
function. Request length checking added to dwc2_hsotg_ep_queue()
function. If request length greater than descriptor limits then
request not added to queue. Additional checking done for High
Bandwidth ISOC OUT's which not supported by driver. In
dwc2_gadget_fill_isoc_desc() function also checked desc-chain
status (full or not) to avoid of reusing not yet processed
descriptors.
In dwc2_gadget_start_isoc_ddma() function creation of desc-chain
always started from descriptor 0. Before filling descriptors, they
were initialized by HOST BUSY status.
In dwc2_gadget_complete_isoc_request_ddma() added checking for
desc-chain rollover. Also added checking completion status.
Request completed successfully if DEV_DMA_STS is DEV_DMA_STS_SUCC,
otherwise complete with actual=0. For systems with high IRQ latency
added pointer compl_desc to next descriptor to be completed by
XferCompl interrupt. This pointer replace descriptor index calculation
based on DxEPDMA register. On descriptor completion interrupt
processing all descriptors starting from compl_desc till descriptor
which Buffer Status field not equal DMA_DONE status.
Actually removed dwc2_gadget_start_next_isoc_ddma() function because
now driver use only one desc-chain and instead that function added
dwc2_gadget_handle_isoc_bna() function for handling BNA interrupts.
Handling BNA interrupt done by flushing TxFIFOs for OUT EPs,
completing request with actual=0 and resetting desc-chain number and
target frame to initial values for restarting transfers.
On handling NAK request completed with actual=0. Incremented target
frame to allow fill desc chain and start transfers.
In DDMA mode avoided of frame number incrementing, because tracking
of frame number performed in dwc2_gadget_fill_isoc_desc() function.
When core assert XferCompl along with BNA, we should ignore XferCompl
in dwc2_hsotg_epint() function.
On BNA interrupt replaced dwc2_gadget_start_next_isoc_ddma() by above
mentioned BNA handler.
In dwc2_hsotg_ep_enable() function added sanity check of bInterval
for ISOC IN in DDMA mode, because HW doesn't supported EP's with
bInterval more than 10 and check for mc for ISOC OUT transfers,
because core doesn't support high bandwidth transfers.
Signed-off-by: Minas Harutyunyan
---
drivers/usb/dwc2/core.h | 4 +-
drivers/usb/dwc2/gadget.c | 279 +++---
2 files changed, 139 insertions(+), 144 deletions(-)
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index d83be5651f87..274bf0a83ae4 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -178,8 +178,8 @@ struct dwc2_hsotg_req;
* @desc_list_dma: The DMA address of descriptor chain currently in use.
* @desc_list: Pointer to descriptor DMA chain head currently in use.
* @desc_count: Count of entries within the DMA descriptor chain of EP.
- * @isoc_chain_num: Number of ISOC chain currently in use - either 0 or 1.
* @next_desc: index of next free descriptor in the ISOC chain under SW
control.
+ * @compl_desc: index of next descriptor to be completed by xFerComplete
* @total_data: The total number of data bytes done.
* @fifo_size: The size of the FIFO (for periodic IN endpoints)
* @fifo_load: The amount of data loaded into the FIFO (periodic IN)
@@ -231,8 +231,8 @@ struct dwc2_hsotg_ep {
struct dwc2_dma_desc*desc_list;
u8 desc_count;
- unsigned char isoc_chain_num;
unsigned intnext_desc;
+ unsigned intcompl_desc;
charname[10];
};
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index c231321656f9..403e99026c52 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -793,9 +793,7 @@ static void dwc2_gadget_config_nonisoc_xfer_ddma(struct
dwc2_hsotg_ep *hs_ep,
* @dma_buff: usb requests dma buffer.
* @len: usb request transfer length.
*
- * Finds out index of first free entry either in the bottom or up half of
- * descriptor chain depend on which is under SW control and not processed
- * by HW. Then fills that descriptor with the data of the arrived usb request,
+ * Fills next free descriptor with the data of the arrived usb request,
* frame info, sets Last and IOC bits increments next_desc. If filled
* descriptor is not the first one, removes L bit from the previous descriptor
* status.
@@ -810,34 +808,17 @@ static int dwc2_gadget_fill_isoc_desc(struct
dwc2_hsotg_ep *hs_
[PATCH] usb: dwc2: Enable BNA interrupt for IN endpoints
In DDMA mode required to enable BNA interrupt for
both directions.
Signed-off-by: Minas Harutyunyan
---
drivers/usb/dwc2/gadget.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 6c32bf26e48e..c231321656f9 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -3320,8 +3320,10 @@ void dwc2_hsotg_core_init_disconnected(struct dwc2_hsotg
*hsotg,
hsotg->regs + DOEPMSK);
/* Enable BNA interrupt for DDMA */
- if (using_desc_dma(hsotg))
+ if (using_desc_dma(hsotg)) {
dwc2_set_bit(hsotg->regs + DOEPMSK, DOEPMSK_BNAMSK);
+ dwc2_set_bit(hsotg->regs + DIEPMSK, DIEPMSK_BNAININTRMSK);
+ }
dwc2_writel(0, hsotg->regs + DAINTMSK);
--
2.11.0
--
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] usb: dwc2: debugfs: Don't touch RX FIFO during register dump
On 5/4/2018 10:09 PM, Stefan Wahren wrote:
> Dumping the registers via debugfs makes USB on Raspberry Pi completely
> unusable. The read of register GRXSTSP ("Receive Status Read and Pop
> Register") is responsible for this behaviour, because it pops the RX FIFO.
> So avoid this by omitting the relevant register.
>
> CC: Mian Yousaf Kaukab
> Fixes: 563cf017c443 ("usb: dwc2: debugfs: add support for complete register
> dump")
> Signed-off-by: Stefan Wahren
> ---
Acked-by: Minas Harutyunyan
> drivers/usb/dwc2/debugfs.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/usb/dwc2/debugfs.c b/drivers/usb/dwc2/debugfs.c
> index 58c691f..d4c0589 100644
> --- a/drivers/usb/dwc2/debugfs.c
> +++ b/drivers/usb/dwc2/debugfs.c
> @@ -368,7 +368,7 @@ static const struct debugfs_reg32 dwc2_regs[] = {
> dump_register(GINTSTS),
> dump_register(GINTMSK),
> dump_register(GRXSTSR),
> - dump_register(GRXSTSP),
> + /* Omit GRXSTSP */
> dump_register(GRXFSIZ),
> dump_register(GNPTXFSIZ),
> dump_register(GNPTXSTS),
>
--
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: dwc2 (on Meson8b) doesn't detect "hot-plugged" USB devices
Hi Martin, On 5/7/2018 12:28 AM, Martin Blumenstingl wrote: > Hello, > > I was a bit surprised to see that hot-plugging USB devices on Amlogic > Meson8b (for example: Odroid-C1) is broken. > to be fair: I *think* it worked before, but I cannot guarantee it nor > can I say when it broke > > all examples below are from an Odroid-C1 board with Amlogic Meson8b (S805) > SoC. > this connects a (fixed, soldered down) 4-port USB hub to the dwc2 > controller (which is in "host" mode) > > during boot I see: > [1.651687] dwc2 c90c.usb: c90c.usb supply vusb_d not > found, using dummy regulator > [1.654434] dwc2 c90c.usb: c90c.usb supply vusb_a not > found, using dummy regulator > [1.732374] dwc2 c90c.usb: dwc2_check_params: Invalid parameter lpm=1 > [1.733526] dwc2 c90c.usb: dwc2_check_params: Invalid parameter > lpm_clock_gating=1 > [1.741427] dwc2 c90c.usb: dwc2_check_params: Invalid parameter besl=1 > [1.748305] dwc2 c90c.usb: dwc2_check_params: Invalid parameter > hird_threshold_en=1 > [1.756491] dwc2 c90c.usb: DWC OTG Controller > [1.760993] dwc2 c90c.usb: new USB bus registered, assigned bus number > 1 > [1.768046] dwc2 c90c.usb: irq 24, io mem 0xc90c > [1.773947] hub 1-0:1.0: USB hub found > [1.777063] hub 1-0:1.0: 1 port detected > ... > [2.212432] usb 1-1: new high-speed USB device number 2 using dwc2 > [2.464742] hub 1-1:1.0: USB hub found > [2.465118] hub 1-1:1.0: 4 ports detected > > if a USB device is plugged into one of the four USB ports during boot > then it is detected automatically. > if I plug in devices later they are not detected automatically (I have > to run "lsusb -v" due to some reason, then hot-plugged devices are > being detected) > un-plugging USB devices is recognized instantly (no "lsusb" trickery > is required) > > is this a known issue? how can I help debugging? > any help is appreciated! > > below is the output of all dwc2 debugfs files. > > > Regards > Martin > > > [rootodroidc1 c90c.usb]# cat dr_mode > host > [rootodroidc1 c90c.usb]# cat fifo > Non-periodic FIFOs: > RXFIFO: Size 0 > NPTXFIFO: Size 0, Start 0x > > Periodic TXFIFOs: > [rootodroidc1 c90c.usb]# cat hw_params > op_mode : 5 > arch : 2 > dma_desc_enable : 1 > enable_dynamic_fifo : 1 > en_multiple_tx_fifo : 0 > rx_fifo_size : 2048 > host_nperio_tx_fifo_size : 2048 > dev_nperio_tx_fifo_size : 0 > host_perio_tx_fifo_size : 2048 > nperio_tx_q_depth : 4 > host_perio_tx_q_depth : 4 > dev_token_q_depth : 8 > max_transfer_size : 524287 > max_packet_count : 1023 > host_channels : 16 > hs_phy_type : 1 > fs_phy_type : 0 > i2c_enable: 0 > num_dev_ep: 2 > num_dev_perio_in_ep : 0 > total_fifo_size : 1984 > power_optimized : 1 > utmi_phy_data_width : 1 > snpsid: 0x4f54310a > dev_ep_dirs : 0x0 > [rootodroidc1 c90c.usb]# cat params > otg_cap : 2 > dma_desc_enable : 0 > dma_desc_fs_enable: 0 > speed : 0 > enable_dynamic_fifo : 1 > en_multiple_tx_fifo : 0 > host_rx_fifo_size : 512 > host_nperio_tx_fifo_size : 500 > host_perio_tx_fifo_size : 500 > max_transfer_size : 524287 > max_packet_count : 1023 > host_channels : 16 > phy_type : 1 > phy_utmi_width: 16 > phy_ulpi_ddr : 0 > phy_ulpi_ext_vbus : 0 > i2c_enable: 0 > ulpi_fs_ls: 0 > host_support_fs_ls_low_power : 0 > host_ls_low_power_phy_clk : 0 > ts_dline : 0 > reload_ctl: 1 > ahbcfg: 0xa > uframe_sched : 0 > external_id_pin_ctl : 0 > power_down: 1 > lpm : 0 > lpm_clock_gating : 0 > besl : 0 > hird_threshold_en : 0 > hird_threshold: 4 > host_dma : 1 > g_dma : 0 > g_dma_desc: 0 > g_rx_fifo_size: 0 > g_np_tx_fifo_size : 0 > g_tx_fifo_size[0] : 0 > g_tx_fifo_size[1] : 0 > g_tx_fifo_size[2] : 0 > g_tx_fifo_size[3] : 0 > g_tx_fifo_size[4] : 0 > g_tx_fifo_size[5] : 0 > g_tx_fifo_size[6] : 0 > g_tx_fifo_size[7] : 0 > g_tx_fifo_size[8] : 0 > g_tx_fifo_size[9] : 0 > g_tx_fifo_size[10]: 0 > g_tx_fifo_size[11]: 0 > g_tx_fif
Re: [PATCH 1/4] usb: dwc2: Move dwc2_readl/writel functions after hsotg structure
Hi Filipe, On 5/15/2018 11:19 AM, Felipe Balbi wrote: > Gevorg Sahakya writes: > >> From: Gevorg Sahakyan >> >> Moved dwc2_readl/writel functions after hsotg declaration for >> adding hsotg structure to dwc2_readl/writel function prototypes. >> >> Signed-off-by: Gevorg Sahakyan >> Signed-off-by: Gevorg Sahakya > > Why two signed-off-by for the same person? > Second signed-off added wrongly. Should Gevorg re-submit the patch with 1 signed-off? Thanks, Minas -- 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] usb: dwc2: Fix crash in incomplete isoc intr handlers.
On 5/5/2018 12:30 PM, Artur Petrosyan wrote:
> Crash caused by going out of "eps_out" array range.
> Iteration on "eps_out" changed to less than "num_of_eps".
>
> Signed-off-by: Artur Petrosyan
> ---
Acked-by: Minas Harutyunyan
> drivers/usb/dwc2/gadget.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
> index 6c32bf26e48e..010cfbca962a 100644
> --- a/drivers/usb/dwc2/gadget.c
> +++ b/drivers/usb/dwc2/gadget.c
> @@ -3427,7 +3427,7 @@ static void
> dwc2_gadget_handle_incomplete_isoc_in(struct dwc2_hsotg *hsotg)
>
> daintmsk = dwc2_readl(hsotg->regs + DAINTMSK);
>
> - for (idx = 1; idx <= hsotg->num_of_eps; idx++) {
> + for (idx = 1; idx < hsotg->num_of_eps; idx++) {
> hs_ep = hsotg->eps_in[idx];
> /* Proceed only unmasked ISOC EPs */
> if (!hs_ep->isochronous || (BIT(idx) & ~daintmsk))
> @@ -3473,7 +3473,7 @@ static void
> dwc2_gadget_handle_incomplete_isoc_out(struct dwc2_hsotg *hsotg)
> daintmsk = dwc2_readl(hsotg->regs + DAINTMSK);
> daintmsk >>= DAINT_OUTEP_SHIFT;
>
> - for (idx = 1; idx <= hsotg->num_of_eps; idx++) {
> + for (idx = 1; idx < hsotg->num_of_eps; idx++) {
> hs_ep = hsotg->eps_out[idx];
> /* Proceed only unmasked ISOC EPs */
> if (!hs_ep->isochronous || (BIT(idx) & ~daintmsk))
> @@ -3647,7 +3647,7 @@ static irqreturn_t dwc2_hsotg_irq(int irq, void *pw)
> dwc2_writel(gintmsk, hsotg->regs + GINTMSK);
>
> dev_dbg(hsotg->dev, "GOUTNakEff triggered\n");
> - for (idx = 1; idx <= hsotg->num_of_eps; idx++) {
> + for (idx = 1; idx < hsotg->num_of_eps; idx++) {
> hs_ep = hsotg->eps_out[idx];
> /* Proceed only unmasked ISOC EPs */
> if (!hs_ep->isochronous || (BIT(idx) & ~daintmsk))
>
--
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] usb: dwc2: Change reading of current frame number flow.
On 5/5/2018 5:46 PM, Artur Petrosyan wrote:
> The current frame_number is read from core for both
> device and host modes. Reading of the current frame
> number needs to be performed ASAP due to IRQ latency's.
> This is why, it is moved to common interrupt handler.
>
> Accordingly updated dwc2_gadget_target_frame_elapsed()
> function which uses stored frame_number instead of
> reading frame number.
>
> In cases when target frame value is incremented
> the frame_number is required to read again.
>
> Signed-off-by: Artur Petrosyan
> ---
Acked-by: Minas Harutyunyan
> drivers/usb/dwc2/core.h | 7 ---
> drivers/usb/dwc2/core_intr.c | 8
> drivers/usb/dwc2/gadget.c| 13 +++--
> 3 files changed, 23 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
> index d83be5651f87..a435db4fe948 100644
> --- a/drivers/usb/dwc2/core.h
> +++ b/drivers/usb/dwc2/core.h
> @@ -813,6 +813,9 @@ struct dwc2_hregs_backup {
>* @gadget_enabled Peripheral mode sub-driver initialization indicator.
>* @ll_hw_enabled Status of low-level hardware resources.
>* @hibernated: True if core is hibernated
> + * @frame_number: Frame number read from the core. For both device
> + * and host modes. The value ranges are from 0
> + * to HFNUM_MAX_FRNUM.
>* @phy:The otg phy transceiver structure for phy control.
>* @uphy: The otg phy transceiver structure for old USB phy
>* control.
> @@ -886,8 +889,6 @@ struct dwc2_hregs_backup {
>* @hs_periodic_bitmap: Bitmap used by the microframe scheduler any time the
>* host is in high speed mode; low speed schedules are
>* stored elsewhere since we need one per TT.
> - * @frame_number: Frame number read from the core at SOF. The value
> ranges
> - * from 0 to HFNUM_MAX_FRNUM.
>* @periodic_qh_count: Count of periodic QHs, if using several eps. Used
> for
>* SOF enable/disable.
>* @free_hc_list: Free host channels in the controller. This is a
> list of
> @@ -954,6 +955,7 @@ struct dwc2_hsotg {
> unsigned int gadget_enabled:1;
> unsigned int ll_hw_enabled:1;
> unsigned int hibernated:1;
> + u16 frame_number;
>
> struct phy *phy;
> struct usb_phy *uphy;
> @@ -1027,7 +1029,6 @@ struct dwc2_hsotg {
> u16 periodic_usecs;
> unsigned long hs_periodic_bitmap[
> DIV_ROUND_UP(DWC2_HS_SCHEDULE_US, BITS_PER_LONG)];
> - u16 frame_number;
> u16 periodic_qh_count;
> bool bus_suspended;
> bool new_connection;
> diff --git a/drivers/usb/dwc2/core_intr.c b/drivers/usb/dwc2/core_intr.c
> index 2982a155734d..cc90b58b6b3c 100644
> --- a/drivers/usb/dwc2/core_intr.c
> +++ b/drivers/usb/dwc2/core_intr.c
> @@ -778,6 +778,14 @@ irqreturn_t dwc2_handle_common_intr(int irq, void *dev)
> goto out;
> }
>
> + /* Reading current frame number value in device or host modes. */
> + if (dwc2_is_device_mode(hsotg))
> + hsotg->frame_number = (dwc2_readl(hsotg->regs + DSTS)
> +& DSTS_SOFFN_MASK) >> DSTS_SOFFN_SHIFT;
> + else
> + hsotg->frame_number = (dwc2_readl(hsotg->regs + HFNUM)
> +& HFNUM_FRNUM_MASK) >> HFNUM_FRNUM_SHIFT;
> +
> gintsts = dwc2_read_common_intr(hsotg);
> if (gintsts & ~GINTSTS_PRTINT)
> retval = IRQ_HANDLED;
> diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
> index 6c32bf26e48e..f7343cda3234 100644
> --- a/drivers/usb/dwc2/gadget.c
> +++ b/drivers/usb/dwc2/gadget.c
> @@ -1235,7 +1235,7 @@ static bool dwc2_gadget_target_frame_elapsed(struct
> dwc2_hsotg_ep *hs_ep)
> {
> struct dwc2_hsotg *hsotg = hs_ep->parent;
> u32 target_frame = hs_ep->target_frame;
> - u32 current_frame = dwc2_hsotg_read_frameno(hsotg);
> + u32 current_frame = hsotg->frame_number;
> bool frame_overrun = hs_ep->frame_overrun;
>
> if (!frame_overrun && current_frame >= target_frame)
> @@ -1350,8 +1350,15 @@ static int dwc2_hsotg_ep_queue(struct usb_ep *ep,
> struct usb_request *req,
> return 0;
> }
>
> - while (dwc2_gadget_target_frame_elapsed(hs_ep))
> + /* Update current frame number value. */
> + hs->frame_number = dwc2_hsotg_read_frameno(hs);
> + while (dwc2_g
Re: [PATCH] usb: dwc2: Add Interpacket Gap(IPG) feature support
On 5/5/2018 12:18 PM, Grigor Tovmasyan wrote:
> Added GHWCFG4_IPG_ISOC_SUPPORTED and DCFG_IPG_ISOC_SUPPORDED
> bits definitions to enable/disable IPG feature.
>
> Added ipg_isoc_en core parameter which will indicate IPG support
> enable/disable and initialize it.
>
> Signed-off-by: Grigor Tovmasyan
> ---
Acked-by: Minas Harutyunyan
> drivers/usb/dwc2/core.h| 11 +++
> drivers/usb/dwc2/debugfs.c | 1 +
> drivers/usb/dwc2/gadget.c | 3 +++
> drivers/usb/dwc2/hw.h | 2 ++
> drivers/usb/dwc2/params.c | 3 +++
> 5 files changed, 20 insertions(+)
>
> diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
> index d83be5651f87..cacc6badfd6f 100644
> --- a/drivers/usb/dwc2/core.h
> +++ b/drivers/usb/dwc2/core.h
> @@ -380,6 +380,9 @@ enum dwc2_ep0_state {
>* is FS.
>* 0 - No (default)
>* 1 - Yes
> + * @ipg_isoc_en Indicates the IPG supports is enabled or disabled.
> + * 0 - Disable (default)
> + * 1 - Enable
>* @ulpi_fs_ls: Make ULPI phy operate in FS/LS mode only
>* 0 - No (default)
>* 1 - Yes
> @@ -511,6 +514,7 @@ struct dwc2_core_params {
> bool hird_threshold_en;
> u8 hird_threshold;
> bool activate_stm_fs_transceiver;
> + bool ipg_isoc_en;
> u16 max_packet_count;
> u32 max_transfer_size;
> u32 ahbcfg;
> @@ -560,6 +564,12 @@ struct dwc2_core_params {
>* 0 - Slave only
>* 1 - External DMA
>* 2 - Internal DMA
> + * @ipg_isoc_en This feature indicates that the controller supports
> + * the worst-case scenario of Rx followed by Rx
> + * Interpacket Gap (IPG) (32 bitTimes) as per the utmi
> + * specification for any token following ISOC OUT token.
> + * 0 - Don't support
> + * 1 - Support
>* @power_optimized Are power optimizations enabled?
>* @num_dev_ep Number of device endpoints available
>* @num_dev_in_eps Number of device IN endpoints available
> @@ -622,6 +632,7 @@ struct dwc2_hw_params {
> unsigned hibernation:1;
> unsigned utmi_phy_data_width:2;
> unsigned lpm_mode:1;
> + unsigned ipg_isoc_en:1;
> u32 snpsid;
> u32 dev_ep_dirs;
> u32 g_tx_fifo_size[MAX_EPS_CHANNELS];
> diff --git a/drivers/usb/dwc2/debugfs.c b/drivers/usb/dwc2/debugfs.c
> index 58c691f882a8..5897333600a7 100644
> --- a/drivers/usb/dwc2/debugfs.c
> +++ b/drivers/usb/dwc2/debugfs.c
> @@ -710,6 +710,7 @@ static int params_show(struct seq_file *seq, void *v)
> print_param(seq, p, phy_ulpi_ddr);
> print_param(seq, p, phy_ulpi_ext_vbus);
> print_param(seq, p, i2c_enable);
> + print_param(seq, p, ipg_isoc_en);
> print_param(seq, p, ulpi_fs_ls);
> print_param(seq, p, host_support_fs_ls_low_power);
> print_param(seq, p, host_ls_low_power_phy_clk);
> diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
> index 6c32bf26e48e..70a7ae84eb53 100644
> --- a/drivers/usb/dwc2/gadget.c
> +++ b/drivers/usb/dwc2/gadget.c
> @@ -3259,6 +3259,9 @@ void dwc2_hsotg_core_init_disconnected(struct
> dwc2_hsotg *hsotg,
> dcfg |= DCFG_DEVSPD_HS;
> }
>
> + if (hsotg->params.ipg_isoc_en)
> + dcfg |= DCFG_IPG_ISOC_SUPPORDED;
> +
> dwc2_writel(dcfg, hsotg->regs + DCFG);
>
> /* Clear any pending OTG interrupts */
> diff --git a/drivers/usb/dwc2/hw.h b/drivers/usb/dwc2/hw.h
> index 38391e48351f..0ca8e7bc7aaf 100644
> --- a/drivers/usb/dwc2/hw.h
> +++ b/drivers/usb/dwc2/hw.h
> @@ -311,6 +311,7 @@
> #define GHWCFG4_UTMI_PHY_DATA_WIDTH_MASK(0x3 << 14)
> #define GHWCFG4_UTMI_PHY_DATA_WIDTH_SHIFT 14
> #define GHWCFG4_ACG_SUPPORTED BIT(12)
> +#define GHWCFG4_IPG_ISOC_SUPPORTED BIT(11)
> #define GHWCFG4_UTMI_PHY_DATA_WIDTH_8 0
> #define GHWCFG4_UTMI_PHY_DATA_WIDTH_16 1
> #define GHWCFG4_UTMI_PHY_DATA_WIDTH_8_OR_16 2
> @@ -424,6 +425,7 @@
> #define DCFG_EPMISCNT_SHIFT 18
> #define DCFG_EPMISCNT_LIMIT 0x1f
> #define DCFG_EPMISCNT(_x) ((_x) << 18)
> +#define DCFG_IPG_ISOC_SUPPORDED BIT(17)
> #define DCFG_PERFRINT_MASK (0x3 << 11)
> #define DCFG_PERFRINT_SHIFT 11
> #define DCFG_PERFRINT_LIMIT 0x3
> diff --git a/drivers/usb/dwc2/params.c b/drivers/u
Re: [PATCH] usb: dwc2: gadget: Fix memory leak in dwc2_gadget_init()
On 4/16/2018 2:16 PM, Grigor Tovmasyan wrote: > In dwc2_gadget_init() we allocate EP0 request via > dwc2_hsotg_ep_alloc_request(). After that there are > usb_add_gadget_udc() call and if it failed, then > ctrl_req will not be freed and will cause memory leak. > > Reordered function calls in gadget_init: moved up usb_add_gadget_udc() > before dwc2_hsotg_ep_alloc_request(). > > Tested using kmemleak. > > Cc: Stefan Wahren > Signed-off-by: Grigor Tovmasyan > --- Acked-by: Minas Harutyunyan > drivers/usb/dwc2/gadget.c | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c > index 6c32bf26e48e..24000bda5c20 100644 > --- a/drivers/usb/dwc2/gadget.c > +++ b/drivers/usb/dwc2/gadget.c > @@ -4679,6 +4679,10 @@ int dwc2_gadget_init(struct dwc2_hsotg *hsotg) > INIT_LIST_HEAD(&hsotg->gadget.ep_list); > hsotg->gadget.ep0 = &hsotg->eps_out[0]->ep; > > + ret = usb_add_gadget_udc(dev, &hsotg->gadget); > + if (ret) > + return ret; > + > /* allocate EP0 request */ > > hsotg->ctrl_req = dwc2_hsotg_ep_alloc_request(&hsotg->eps_out[0]->ep, > @@ -4698,10 +4702,6 @@ int dwc2_gadget_init(struct dwc2_hsotg *hsotg) > epnum, 0); > } > > - ret = usb_add_gadget_udc(dev, &hsotg->gadget); > - if (ret) > - return ret; > - > dwc2_hsotg_dump(hsotg); > > return 0; > -- 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: dwc2: Fix kernel doc's warnings.
Hi Filipe,
Please pickup this patch to your testing/next.
Thanks,
Minas
On 4/10/2018 9:59 AM, Minas Harutyunyan wrote:
> Hi,
>
> On 4/3/2018 5:15 PM, Grigor Tovmasyan wrote:
>> Added descriptions for all not described parameters.
>> Fix all kernel doc's warnings.
>>
>> Signed-off-by: Grigor Tovmasyan
>> ---
>> Changes from version 1:
>>
>> Fix minor kernel-doc style issue.
>>
>> Changes from version 0:
>>
>> Rebased to balbi/next.
>> Fixed new kernel-doc warnings which cames from new patches.
>> ---
>>drivers/usb/dwc2/core.c | 7 ++
>>drivers/usb/dwc2/core.h | 166
>> +++
>>drivers/usb/dwc2/debug.h | 2 +-
>>drivers/usb/dwc2/debugfs.c | 19 ++---
>>drivers/usb/dwc2/gadget.c| 29 +---
>>drivers/usb/dwc2/hcd.c | 3 +-
>>drivers/usb/dwc2/hcd.h | 14 ++--
>>drivers/usb/dwc2/hcd_ddma.c | 1 +
>>drivers/usb/dwc2/hcd_intr.c | 12
>>drivers/usb/dwc2/hcd_queue.c | 5 +-
>>drivers/usb/dwc2/params.c| 8 +++
>>drivers/usb/dwc2/pci.c | 6 ++
>>12 files changed, 213 insertions(+), 59 deletions(-)
>>
>> diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
>> index 18a0a1771289..1c36a6a9dd63 100644
>> --- a/drivers/usb/dwc2/core.c
>> +++ b/drivers/usb/dwc2/core.c
>> @@ -419,6 +419,8 @@ static void dwc2_wait_for_mode(struct dwc2_hsotg *hsotg,
>>/**
>> * dwc2_iddig_filter_enabled() - Returns true if the IDDIG debounce
>> * filter is enabled.
>> + *
>> + * @hsotg: Programming view of DWC_otg controller
>> */
>>static bool dwc2_iddig_filter_enabled(struct dwc2_hsotg *hsotg)
>>{
>> @@ -564,6 +566,9 @@ int dwc2_core_reset(struct dwc2_hsotg *hsotg, bool
>> skip_wait)
>> * If a force is done, it requires a IDDIG debounce filter delay if
>> * the filter is configured and enabled. We poll the current mode of
>> * the controller to account for this delay.
>> + *
>> + * @hsotg: Programming view of DWC_otg controller
>> + * @host: Host mode flag
>> */
>>void dwc2_force_mode(struct dwc2_hsotg *hsotg, bool host)
>>{
>> @@ -610,6 +615,8 @@ void dwc2_force_mode(struct dwc2_hsotg *hsotg, bool host)
>> * or not because the value of the connector ID status is affected by
>> * the force mode. We only need to call this once during probe if
>> * dr_mode == OTG.
>> + *
>> + * @hsotg: Programming view of DWC_otg controller
>> */
>>static void dwc2_clear_force_mode(struct dwc2_hsotg *hsotg)
>>{
>> diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
>> index d83be5651f87..c2c08cbbc19b 100644
>> --- a/drivers/usb/dwc2/core.h
>> +++ b/drivers/usb/dwc2/core.h
>> @@ -164,12 +164,11 @@ struct dwc2_hsotg_req;
>> * and has yet to be completed (maybe due to data move, or simply
>> * awaiting an ack from the core all the data has been completed).
>> * @debugfs: File entry for debugfs file for this endpoint.
>> - * @lock: State lock to protect contents of endpoint.
>> * @dir_in: Set to true if this endpoint is of the IN direction, which
>> * means that it is sending data to the Host.
>> * @index: The index for the endpoint registers.
>> * @mc: Multi Count - number of transactions per microframe
>> - * @interval - Interval for periodic endpoints, in frames or microframes.
>> + * @interval: Interval for periodic endpoints, in frames or microframes.
>> * @name: The name array passed to the USB core.
>> * @halted: Set if the endpoint has been halted.
>> * @periodic: Set if this is a periodic ep, such as Interrupt
>> @@ -182,6 +181,7 @@ struct dwc2_hsotg_req;
>> * @next_desc: index of next free descriptor in the ISOC chain under SW
>> control.
>> * @total_data: The total number of data bytes done.
>> * @fifo_size: The size of the FIFO (for periodic IN endpoints)
>> + * @fifo_index: For Dedicated FIFO operation, only FIFO0 can be used for
>> EP0.
>> * @fifo_load: The amount of data loaded into the FIFO (periodic IN)
>> * @last_load: The offset of data for the last start of request.
>> * @size_loaded: The last loaded size for DxEPTSIZE for periodic IN
>> @@ -380,6 +380,9 @@ enum dwc2_ep0_state {
>> * is FS.
>> * 0 - No (default)
>> * 1 - Yes
>> + * @acg_enable: Fo
Re: [PATCH v3] usb: dwc2: Fix kernel doc's warnings.
On 5/16/2018 12:04 PM, Grigor Tovmasyan wrote:
> Added descriptions for all not described parameters.
> Fix all kernel doc's warnings.
>
> Signed-off-by: Grigor Tovmasyan
> ---
Acked-by: Minas Harutyunyan
> drivers/usb/dwc2/core.c | 7 ++
> drivers/usb/dwc2/core.h | 170
> ++-
> drivers/usb/dwc2/debug.h | 2 +-
> drivers/usb/dwc2/debugfs.c | 19 ++---
> drivers/usb/dwc2/gadget.c| 29 +---
> drivers/usb/dwc2/hcd.c | 3 +-
> drivers/usb/dwc2/hcd.h | 14 ++--
> drivers/usb/dwc2/hcd_ddma.c | 1 +
> drivers/usb/dwc2/hcd_intr.c | 12 +++
> drivers/usb/dwc2/hcd_queue.c | 5 +-
> drivers/usb/dwc2/params.c| 8 ++
> drivers/usb/dwc2/pci.c | 6 ++
> 12 files changed, 215 insertions(+), 61 deletions(-)
>
> diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
> index 18a0a1771289..1c36a6a9dd63 100644
> --- a/drivers/usb/dwc2/core.c
> +++ b/drivers/usb/dwc2/core.c
> @@ -419,6 +419,8 @@ static void dwc2_wait_for_mode(struct dwc2_hsotg *hsotg,
> /**
>* dwc2_iddig_filter_enabled() - Returns true if the IDDIG debounce
>* filter is enabled.
> + *
> + * @hsotg: Programming view of DWC_otg controller
>*/
> static bool dwc2_iddig_filter_enabled(struct dwc2_hsotg *hsotg)
> {
> @@ -564,6 +566,9 @@ int dwc2_core_reset(struct dwc2_hsotg *hsotg, bool
> skip_wait)
>* If a force is done, it requires a IDDIG debounce filter delay if
>* the filter is configured and enabled. We poll the current mode of
>* the controller to account for this delay.
> + *
> + * @hsotg: Programming view of DWC_otg controller
> + * @host: Host mode flag
>*/
> void dwc2_force_mode(struct dwc2_hsotg *hsotg, bool host)
> {
> @@ -610,6 +615,8 @@ void dwc2_force_mode(struct dwc2_hsotg *hsotg, bool host)
>* or not because the value of the connector ID status is affected by
>* the force mode. We only need to call this once during probe if
>* dr_mode == OTG.
> + *
> + * @hsotg: Programming view of DWC_otg controller
>*/
> static void dwc2_clear_force_mode(struct dwc2_hsotg *hsotg)
> {
> diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
> index 2438480e4496..6d304e91c20e 100644
> --- a/drivers/usb/dwc2/core.h
> +++ b/drivers/usb/dwc2/core.h
> @@ -164,12 +164,11 @@ struct dwc2_hsotg_req;
>* and has yet to be completed (maybe due to data move, or simply
>* awaiting an ack from the core all the data has been completed).
>* @debugfs: File entry for debugfs file for this endpoint.
> - * @lock: State lock to protect contents of endpoint.
>* @dir_in: Set to true if this endpoint is of the IN direction, which
>* means that it is sending data to the Host.
>* @index: The index for the endpoint registers.
>* @mc: Multi Count - number of transactions per microframe
> - * @interval - Interval for periodic endpoints, in frames or microframes.
> + * @interval: Interval for periodic endpoints, in frames or microframes.
>* @name: The name array passed to the USB core.
>* @halted: Set if the endpoint has been halted.
>* @periodic: Set if this is a periodic ep, such as Interrupt
> @@ -182,6 +181,7 @@ struct dwc2_hsotg_req;
>* @compl_desc: index of next descriptor to be completed by xFerComplete
>* @total_data: The total number of data bytes done.
>* @fifo_size: The size of the FIFO (for periodic IN endpoints)
> + * @fifo_index: For Dedicated FIFO operation, only FIFO0 can be used for EP0.
>* @fifo_load: The amount of data loaded into the FIFO (periodic IN)
>* @last_load: The offset of data for the last start of request.
>* @size_loaded: The last loaded size for DxEPTSIZE for periodic IN
> @@ -380,9 +380,12 @@ enum dwc2_ep0_state {
>* is FS.
>* 0 - No (default)
>* 1 - Yes
> - * @ipg_isoc_en Indicates the IPG supports is enabled or disabled.
> + * @ipg_isoc_en:Indicates the IPG supports is enabled or disabled.
>* 0 - Disable (default)
>* 1 - Enable
> + * @acg_enable: For enabling Active Clock Gating in the
> controller
> + * 0 - No
> + * 1 - Yes
>* @ulpi_fs_ls: Make ULPI phy operate in FS/LS mode only
>* 0 - No (default)
>* 1 - Yes
> @@ -552,7 +555,7 @@ struct dwc2_core_params {
>*
>* The values that are not in dwc2_core_params are documented below.
>*
> - * @op_mode Mode of Operation
> + * @op
Re: [PATCH] usb: dwc2: Fix HiKey regression caused by power_down feature
Hi John,
On 5/19/2018 4:49 AM, John Stultz wrote:
> In 4.17-rc, commit 03ea6d6e9e1f ("usb: dwc2: Enable power down")
> caused the HiKey board to not correctly handle switching between
> usb-gadget and usb-host mode.
>
> Unplugging the OTG port would result in:
> [ 42.240973] dwc2 f72c.usb: dwc2_restore_host_registers: no host
> registers to restore
> [ 42.249066] dwc2 f72c.usb: dwc2_host_exit_hibernation: failed to
> restore host registers
>
> And the USB-host ports would not function.
>
> And plugging in the OTG port, we would see:
> [ 46.046557] WARNING: CPU: 3 PID: 6 at drivers/usb/dwc2/gadget.c:260
> dwc2_hsotg_init_fifo+0x194/0x1a0
> [ 46.055761] CPU: 3 PID: 6 Comm: kworker/u16:0 Not tainted
> 4.17.0-rc5-00030-ge67da8c #231
> [ 46.055767] Hardware name: HiKey Development Board (DT)
> [ 46.055784] Workqueue: dwc2 dwc2_conn_id_status_change
> ...
>
Could you please send full log to debug.
> Thus, this patch sets the hisi params to disable the power_down
> flag by default, and gets thing working again.
>
> Cc: John Youn
> Cc: Vardan Mikayelyan
> Cc: Artur Petrosyan
> Cc: Grigor Tovmasyan
> Cc: Felipe Balbi
> Cc: linux-usb@vger.kernel.org
> Signed-off-by: John Stultz
> ---
> drivers/usb/dwc2/params.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/usb/dwc2/params.c b/drivers/usb/dwc2/params.c
> index f03e418..96b1b25 100644
> --- a/drivers/usb/dwc2/params.c
> +++ b/drivers/usb/dwc2/params.c
> @@ -70,6 +70,7 @@ static void dwc2_set_his_params(struct dwc2_hsotg *hsotg)
> GAHBCFG_HBSTLEN_SHIFT;
> p->uframe_sched = false;
> p->change_speed_quirk = true;
> + p->power_down = false;
power_down declared as int, suggested to update as follow:
p->power_down = DWC2_POWER_DOWN_PARAM_NONE;
This can be accepted as temporary solution until we will fully debug
hibernation feature for HiKey platform.
> }
>
> static void dwc2_set_rk_params(struct dwc2_hsotg *hsotg)
>
--
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] usb: dwc2: Fix HiKey regression caused by power_down feature
Hi John,
Please provide log with debug enabled configuration.
On 5/21/2018 11:41 PM, John Stultz wrote:
> On Mon, May 21, 2018 at 1:45 AM, Minas Harutyunyan
> wrote:
>> Hi John,
>>
>> On 5/19/2018 4:49 AM, John Stultz wrote:
>>> In 4.17-rc, commit 03ea6d6e9e1f ("usb: dwc2: Enable power down")
>>> caused the HiKey board to not correctly handle switching between
>>> usb-gadget and usb-host mode.
>>>
>>> Unplugging the OTG port would result in:
OTG port you mean MicroAB, Correct?
dwc2 driver loaded when some device connected to OTG port?
And below message printed after disconnect the device from OTG port?
>>> [ 42.240973] dwc2 f72c.usb: dwc2_restore_host_registers: no host
>>> registers to restore
>>> [ 42.249066] dwc2 f72c.usb: dwc2_host_exit_hibernation: failed to
>>> restore host registers
>>>
>>> And the USB-host ports would not function.
USB-host ports - you mean 2 USB A-ports, connected to TS3USB221 HUB?
Switching ports between OTG and Host ports via TS3USB221 Switch
performing automatically or by some SW tool?
>>>
>>> And plugging in the OTG port, we would see:
>>> [ 46.046557] WARNING: CPU: 3 PID: 6 at drivers/usb/dwc2/gadget.c:260
>>> dwc2_hsotg_init_fifo+0x194/0x1a0
>>> [ 46.055761] CPU: 3 PID: 6 Comm: kworker/u16:0 Not tainted
>>> 4.17.0-rc5-00030-ge67da8c #231
>>> [ 46.055767] Hardware name: HiKey Development Board (DT)
>>> [ 46.055784] Workqueue: dwc2 dwc2_conn_id_status_change
>>> ...
>>>
>> Could you please send full log to debug.
>
> Full dmesg log attached.
>
> I unplugged the usb-otg port at 136
> and replugged it back in at 141
>
>
>>>p->uframe_sched = false;
>>>p->change_speed_quirk = true;
>>> + p->power_down = false;
>>
>> power_down declared as int, suggested to update as follow:
>> p->power_down = DWC2_POWER_DOWN_PARAM_NONE;
>>
>> This can be accepted as temporary solution until we will fully debug
>> hibernation feature for HiKey platform.
>
> Ok, will re-send with the suggested change above.
>
> thanks
> -john
>
--
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 0/4] usb: dwc2: Make dwc2 endianness agnostic
Hi Filipe, This patch series changing dwc2_readl/dwc2_writel functions prototypes. To avoid multiple re-basing, preferable to merge this series to your next branch as soon as possible. Do you have any objections? Thanks, Minas Acked-by: Minas Harutyunyan On 5/23/2018 11:54 AM, Gevorg Sahakyan wrote: > This series contains patches which are make dwc2 core endianness agnostic > > Changes from v1: > > Rebased to latest balbi/next. > > Changes from v0: > > Moved dwc2_check_core_endianness() call after devm_ioremap_resource() > to avoid ioread32() call on null pointer. > > > > Gevorg Sahakyan (4): >usb: dwc2: Move dwc2_readl/writel functions after hsotg structure >usb: dwc2: Modify dwc2_readl/writel functions prototype >usb: dwc2: replace ioread32/iowrite32_rep with dwc2_readl/writel_rep >usb: dwc2: Make dwc2_readl/writel functions endianness-agnostic. > > drivers/usb/dwc2/core.c | 241 ++-- > drivers/usb/dwc2/core.h | 115 +- > drivers/usb/dwc2/core_intr.c | 118 +- > drivers/usb/dwc2/debugfs.c | 55 +++-- > drivers/usb/dwc2/gadget.c| 514 > +-- > drivers/usb/dwc2/hcd.c | 461 +++--- > drivers/usb/dwc2/hcd.h | 10 +- > drivers/usb/dwc2/hcd_ddma.c | 10 +- > drivers/usb/dwc2/hcd_intr.c | 96 > drivers/usb/dwc2/hcd_queue.c | 10 +- > drivers/usb/dwc2/params.c| 20 +- > drivers/usb/dwc2/platform.c | 19 ++ > 12 files changed, 843 insertions(+), 826 deletions(-) > -- 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] dwc2: gadget: Fix ISOC IN DDMA PID bitfield value calculation
PID bitfield in descriptor should be set based on particular request
length, not based on EP's mc value. PID value can't be set to 0 even
request length is 0.
Signed-off-by: Minas Harutyunyan
---
drivers/usb/dwc2/gadget.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 6c32bf26e48e..9c79919a0a49 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -808,6 +808,7 @@ static int dwc2_gadget_fill_isoc_desc(struct dwc2_hsotg_ep
*hs_ep,
u32 index;
u32 maxsize = 0;
u32 mask = 0;
+ u8 pid = 0;
maxsize = dwc2_gadget_get_desc_params(hs_ep, &mask);
if (len > maxsize) {
@@ -853,7 +854,11 @@ static int dwc2_gadget_fill_isoc_desc(struct dwc2_hsotg_ep
*hs_ep,
((len << DEV_DMA_NBYTES_SHIFT) & mask));
if (hs_ep->dir_in) {
- desc->status |= ((hs_ep->mc << DEV_DMA_ISOC_PID_SHIFT) &
+ if (len)
+ pid = DIV_ROUND_UP(len, hs_ep->ep.maxpacket);
+ else
+ pid = 1;
+ desc->status |= ((pid << DEV_DMA_ISOC_PID_SHIFT) &
DEV_DMA_ISOC_PID_MASK) |
((len % hs_ep->ep.maxpacket) ?
DEV_DMA_SHORT : 0) |
--
2.11.0
--
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] usb: dwc2: gadget: ISOC's starting flow improvement
To start ISOC transfers in handlers dwc2_gadget_handle_nak() and
dwc2_gadget_handle_out_token_ep_disabled() driver reads current frame
number, based on which, set target frame number to start first ISOC
transfer.
In case if system's high IRQ latency and multiple EP's asserted
interrupt in same frame, there are high probability that when reading
current frame number in EP's handlers, actual frame number can be
increased. As result for bInterval > 1, starting target frame
will be set wrongly and all ISOC packets will be dropped.
In patch "usb: dwc2: Change reading of current frame number flow"
reading of current frame number done ASAP in common interrupt handler.
This frame number stored in frame_number variable which used as
starting frame number for ISOC EP's in above mentioned handlers.
Signed-off-by: Minas Harutyunyan
---
drivers/usb/dwc2/gadget.c | 19 ---
1 file changed, 4 insertions(+), 15 deletions(-)
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 676712159980..fedf4dd65cc5 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -2749,23 +2749,16 @@ static void
dwc2_gadget_handle_out_token_ep_disabled(struct dwc2_hsotg_ep *ep)
struct dwc2_hsotg *hsotg = ep->parent;
int dir_in = ep->dir_in;
u32 doepmsk;
- u32 tmp;
if (dir_in || !ep->isochronous)
return;
- /*
-* Store frame in which irq was asserted here, as
-* it can change while completing request below.
-*/
- tmp = dwc2_hsotg_read_frameno(hsotg);
-
dwc2_hsotg_complete_request(hsotg, ep, get_ep_head(ep), 0);
if (using_desc_dma(hsotg)) {
if (ep->target_frame == TARGET_FRAME_INITIAL) {
/* Start first ISO Out */
- ep->target_frame = tmp;
+ ep->target_frame = hsotg->frame_number;
dwc2_gadget_start_isoc_ddma(ep);
}
return;
@@ -2773,11 +2766,9 @@ static void
dwc2_gadget_handle_out_token_ep_disabled(struct dwc2_hsotg_ep *ep)
if (ep->interval > 1 &&
ep->target_frame == TARGET_FRAME_INITIAL) {
- u32 dsts;
u32 ctrl;
- dsts = dwc2_readl(hsotg->regs + DSTS);
- ep->target_frame = dwc2_hsotg_read_frameno(hsotg);
+ ep->target_frame = hsotg->frame_number;
dwc2_gadget_incr_frame_num(ep);
ctrl = dwc2_readl(hsotg->regs + DOEPCTL(ep->index));
@@ -2813,25 +2804,23 @@ static void dwc2_gadget_handle_nak(struct dwc2_hsotg_ep
*hs_ep)
{
struct dwc2_hsotg *hsotg = hs_ep->parent;
int dir_in = hs_ep->dir_in;
- u32 tmp;
if (!dir_in || !hs_ep->isochronous)
return;
if (hs_ep->target_frame == TARGET_FRAME_INITIAL) {
- tmp = dwc2_hsotg_read_frameno(hsotg);
if (using_desc_dma(hsotg)) {
dwc2_hsotg_complete_request(hsotg, hs_ep,
get_ep_head(hs_ep), 0);
- hs_ep->target_frame = tmp;
+ hs_ep->target_frame = hsotg->frame_number;
dwc2_gadget_incr_frame_num(hs_ep);
dwc2_gadget_start_isoc_ddma(hs_ep);
return;
}
- hs_ep->target_frame = tmp;
+ hs_ep->target_frame = hsotg->frame_number;
if (hs_ep->interval > 1) {
u32 ctrl = dwc2_readl(hsotg->regs +
DIEPCTL(hs_ep->index));
--
2.11.0
--
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] usb: gadget: dwc2: fix memory leak in gadget_init()
Acked-by: Minas Harutyunyan
On 5/24/2018 6:22 PM, Grigor Tovmasyan wrote:
> Freed allocated request for ep0 to prevent memory leak in case when
> dwc2_driver_probe() failed.
>
> Signed-off-by: Grigor Tovmasyan
> Cc: Stefan Wahren
> Cc: Marek Szyprowski
> ---
> drivers/usb/dwc2/gadget.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
> index f0d9ccf1d665..7ccf56da1e50 100644
> --- a/drivers/usb/dwc2/gadget.c
> +++ b/drivers/usb/dwc2/gadget.c
> @@ -4739,9 +4739,11 @@ int dwc2_gadget_init(struct dwc2_hsotg *hsotg)
> }
>
> ret = usb_add_gadget_udc(dev, &hsotg->gadget);
> - if (ret)
> + if (ret) {
> + dwc2_hsotg_ep_free_request(&hsotg->eps_out[0]->ep,
> +hsotg->ctrl_req);
> return ret;
> -
> + }
> dwc2_hsotg_dump(hsotg);
>
> return 0;
> @@ -4755,6 +4757,7 @@ int dwc2_gadget_init(struct dwc2_hsotg *hsotg)
> int dwc2_hsotg_remove(struct dwc2_hsotg *hsotg)
> {
> usb_del_gadget_udc(&hsotg->gadget);
> + dwc2_hsotg_ep_free_request(&hsotg->eps_out[0]->ep, hsotg->ctrl_req);
>
> return 0;
> }
>
--
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 v1] dwc2: gadget: Fix ISOC IN DDMA PID bitfield value calculation
PID bitfield in descriptor should be set based on particular request
length, not based on EP's mc value. PID value can't be set to 0 even
request length is 0.
If request length is 0 then SP bit should be set along PID.
Signed-off-by: Minas Harutyunyan
---
drivers/usb/dwc2/gadget.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index f0d9ccf1d665..ff7f23218642 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -812,6 +812,8 @@ static int dwc2_gadget_fill_isoc_desc(struct dwc2_hsotg_ep
*hs_ep,
u32 index;
u32 maxsize = 0;
u32 mask = 0;
+ u8 pid = 0;
+ u8 sp = 0;
maxsize = dwc2_gadget_get_desc_params(hs_ep, &mask);
@@ -840,10 +842,15 @@ static int dwc2_gadget_fill_isoc_desc(struct
dwc2_hsotg_ep *hs_ep,
((len << DEV_DMA_NBYTES_SHIFT) & mask));
if (hs_ep->dir_in) {
- desc->status |= ((hs_ep->mc << DEV_DMA_ISOC_PID_SHIFT) &
-DEV_DMA_ISOC_PID_MASK) |
- ((len % hs_ep->ep.maxpacket) ?
-DEV_DMA_SHORT : 0) |
+ if (len) {
+ pid = DIV_ROUND_UP(len, hs_ep->ep.maxpacket);
+ sp = (len % hs_ep->ep.maxpacket) ? DEV_DMA_SHORT : 0;
+ } else {
+ pid = 1;
+ sp = DEV_DMA_SHORT;
+ }
+ desc->status |= ((pid << DEV_DMA_ISOC_PID_SHIFT) &
+DEV_DMA_ISOC_PID_MASK) | sp |
((hs_ep->target_frame <<
DEV_DMA_ISOC_FRNUM_SHIFT) &
DEV_DMA_ISOC_FRNUM_MASK);
--
2.11.0
--
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 v2] dwc2: gadget: Fix ISOC IN DDMA PID bitfield value calculation
PID bitfield in descriptor should be set based on particular request
length, not based on EP's mc value. PID value can't be set to 0 even
request length is 0.
If request length is 0 then SP bit should be set along PID.
Signed-off-by: Minas Harutyunyan
---
drivers/usb/dwc2/gadget.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index f0d9ccf1d665..20b04c00e626 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -812,6 +812,8 @@ static int dwc2_gadget_fill_isoc_desc(struct dwc2_hsotg_ep
*hs_ep,
u32 index;
u32 maxsize = 0;
u32 mask = 0;
+ u32 sp = 0;
+ u8 pid = 0;
maxsize = dwc2_gadget_get_desc_params(hs_ep, &mask);
@@ -840,10 +842,15 @@ static int dwc2_gadget_fill_isoc_desc(struct
dwc2_hsotg_ep *hs_ep,
((len << DEV_DMA_NBYTES_SHIFT) & mask));
if (hs_ep->dir_in) {
- desc->status |= ((hs_ep->mc << DEV_DMA_ISOC_PID_SHIFT) &
-DEV_DMA_ISOC_PID_MASK) |
- ((len % hs_ep->ep.maxpacket) ?
-DEV_DMA_SHORT : 0) |
+ if (len) {
+ pid = DIV_ROUND_UP(len, hs_ep->ep.maxpacket);
+ sp = (len % hs_ep->ep.maxpacket) ? DEV_DMA_SHORT : 0;
+ } else {
+ pid = 1;
+ sp = DEV_DMA_SHORT;
+ }
+ desc->status |= ((pid << DEV_DMA_ISOC_PID_SHIFT) &
+DEV_DMA_ISOC_PID_MASK) | sp |
((hs_ep->target_frame <<
DEV_DMA_ISOC_FRNUM_SHIFT) &
DEV_DMA_ISOC_FRNUM_MASK);
--
2.11.0
--
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] usb: dwc2: Fix host exit from hibernation flow.
Acked-by: Minas Harutyunyan On 5/23/2018 5:25 PM, Artur Petrosyan wrote: > In case when a hub is connected to DWC2 host > auto suspend occurs and host goes to > hibernation. When any device connected to hub > host hibernation exiting incorrectly. > > - Added dwc2_hcd_rem_wakeup() function call to >exit from suspend state by remote wakeup. > > - Increase timeout value for port suspend bit to be set. > > Signed-off-by: Artur Petrosyan > --- > drivers/usb/dwc2/hcd.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c > index 1faefea16cec..736dcc816abf 100644 > --- a/drivers/usb/dwc2/hcd.c > +++ b/drivers/usb/dwc2/hcd.c > @@ -5434,7 +5434,7 @@ int dwc2_host_enter_hibernation(struct dwc2_hsotg > *hsotg) > dwc2_writel(hprt0, hsotg->regs + HPRT0); > > /* Wait for the HPRT0.PrtSusp register field to be set */ > - if (dwc2_hsotg_wait_bit_set(hsotg, HPRT0, HPRT0_SUSP, 300)) > + if (dwc2_hsotg_wait_bit_set(hsotg, HPRT0, HPRT0_SUSP, 3000)) > dev_warn(hsotg->dev, "Suspend wasn't generated\n"); > > /* > @@ -5615,6 +5615,8 @@ int dwc2_host_exit_hibernation(struct dwc2_hsotg > *hsotg, int rem_wakeup, > return ret; > } > > + dwc2_hcd_rem_wakeup(hsotg); > + > hsotg->hibernated = 0; > hsotg->bus_suspended = 0; > hsotg->lx_state = DWC2_L0; > -- 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] usb: dwc2: gadget: fix packet drop issue for ISOC OUT transfers
In ISOC OUT transfer, when the OUT token received while EP disabled,
we shouldn't complete a usb request. The current flow completed one
usb request, this will lead to a packet drop to function driver.
Signed-off-by: Minas Harutyunyan
---
drivers/usb/dwc2/gadget.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 7c71d5aba765..7a5e265f48f7 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -2755,8 +2755,6 @@ static void
dwc2_gadget_handle_out_token_ep_disabled(struct dwc2_hsotg_ep *ep)
if (dir_in || !ep->isochronous)
return;
- dwc2_hsotg_complete_request(hsotg, ep, get_ep_head(ep), 0);
-
if (using_desc_dma(hsotg)) {
if (ep->target_frame == TARGET_FRAME_INITIAL) {
/* Start first ISO Out */
--
2.11.0
--
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] usb: dwc2: gadget: Fix issue in dwc2_gadget_start_isoc()
In case of requests queue is empty reset EP target_frame to
initial value.
This allow restarting ISOC traffic in case when function
driver queued requests with interruptions.
Signed-off-by: Minas Harutyunyan
---
drivers/usb/dwc2/gadget.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 7a5e265f48f7..24d23025be77 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -891,6 +891,7 @@ static void dwc2_gadget_start_isoc_ddma(struct
dwc2_hsotg_ep *hs_ep)
struct dwc2_dma_desc *desc;
if (list_empty(&hs_ep->queue)) {
+ hs_ep->target_frame = TARGET_FRAME_INITIAL;
dev_dbg(hsotg->dev, "%s: No requests in queue\n", __func__);
return;
}
--
2.11.0
--
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: [RESEND x2][PATCH 0/3] dwc2 fixes for edge cases on hikey
On 9/30/2017 9:13 PM, John Youn wrote: > On 09/20/2017 12:57 PM, John Stultz wrote: >> So here are a few dwc2 fixes that I've been using with HiKey. >> I'm not totally sure these are all ideal, but they avoid edge case >> issues that we have been running into with switching between >> gadget mode and host mode. >> >> I'd guess the first two are potentially -stable material, and >> the last might be worth sending to -stable too, as its a relatively >> simple fix, but to my understanding the UDC state tracking has >> always been broken so its not really a regression. But still. >> >> I'd love to get some feedback on the patches and consideration >> to be merged upstream. >> >> thanks >> -john >> >> Cc: Wei Xu >> Cc: Guodong Xu >> Cc: Amit Pundir >> Cc: YongQin Liu >> Cc: John Youn >> Cc: Minas Harutyunyan >> Cc: Douglas Anderson >> Cc: Chen Yu >> Cc: Felipe Balbi >> Cc: Greg Kroah-Hartman >> Cc: linux-usb@vger.kernel.org >> >> John Stultz (3): >> usb: dwc2: Improve gadget state disconnection handling >> usb: dwc2: Error out of dwc2_hsotg_ep_disable() if we're in host mode >> usb: dwc2: Fix UDC state tracking >> >> drivers/usb/dwc2/gadget.c | 7 +++ >> drivers/usb/dwc2/hcd.c| 8 ++-- >> 2 files changed, 13 insertions(+), 2 deletions(-) >> > > Hi John, > > I think we have something that fixes these issues. > > Minas, > > Could you take a look at this? I was not able to find the patches we > talked about. If possible, please post them so that John can try them > out. > > Thanks, > John > Hi John Stultz, Could you please apply patch from Vardan Mikayelyan "usb: dwc2: Fix dwc2_hsotg_core_init_disconnected()" submitted at 02/25/2017 (https://marc.info/?l=linux-usb&m=148801589931039&w=2) instead of your "usb: dwc2: Improve gadget state disconnection handling" and test again failing scenario. Other 2 patches from series "[PATCH 0/3] dwc2 fixes for edge cases on hikey" are Ok. Thanks, Minas -- 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: [RESEND x2][PATCH 2/3] usb: dwc2: Error out of dwc2_hsotg_ep_disable() if we're in host mode
On 9/20/2017 11:57 PM, John Stultz wrote:
> We've found that while in host mode, using Android, if one runs
> the command:
> stop adbd
>
> The existing usb devices being utilized in host mode are disconnected.
> This is most visible with usb networking devices.
>
> This seems to be due to adbd closing the file:
> /dev/usb-ffs/adb/ep0
> Which calls ffs_ep0_release() and the following backtrace:
>
> [] dwc2_hsotg_ep_disable+0x148/0x150
> [] dwc2_hsotg_udc_stop+0x60/0x110
> [] usb_gadget_remove_driver+0x58/0x78
> [] usb_gadget_unregister_driver+0x74/0xe8
> [] unregister_gadget+0x28/0x58
> [] unregister_gadget_item+0x2c/0x40
> [] ffs_data_clear+0xe8/0xf8
> [] ffs_data_reset+0x20/0x58
> [] ffs_data_closed+0x98/0xe8
> [] ffs_ep0_release+0x20/0x30
>
> Then when dwc2_hsotg_ep_disable() is called, we call
> kill_all_requests() which causes a bunch of the following
> messages:
>
> dwc2 f72c.usb: Mode Mismatch Interrupt: currently in Host mode
> dwc2 f72c.usb: Mode Mismatch Interrupt: currently in Host mode
> dwc2 f72c.usb: Mode Mismatch Interrupt: currently in Host mode
> dwc2 f72c.usb: Mode Mismatch Interrupt: currently in Host mode
> dwc2 f72c.usb: Mode Mismatch Interrupt: currently in Host mode
> dwc2 f72c.usb: Mode Mismatch Interrupt: currently in Host mode
> dwc2 f72c.usb: Mode Mismatch Interrupt: currently in Host mode
> dwc2 f72c.usb: Mode Mismatch Interrupt: currently in Host mode
> init: Service 'adbd' (pid 1915) killed by signal 9
> init: Sending signal 9 to service 'adbd' (pid 1915) process group...
> init: Successfully killed process cgroup uid 0 pid 1915 in 0ms
> init: processing action (init.svc.adbd=stopped) from
> (/init.usb.configfs.rc:15)
> dwc2 f72c.usb: dwc2_hc_chhltd_intr_dma: Channel 8 - ChHltd set, but
> reason is unknown
> dwc2 f72c.usb: hcint 0x0002, intsts 0x04200029
> dwc2 f72c.usb: dwc2_hc_chhltd_intr_dma: Channel 12 - ChHltd set, but
> reason is unknown
> dwc2 f72c.usb: hcint 0x0002, intsts 0x04200029
> dwc2 f72c.usb: dwc2_hc_chhltd_intr_dma: Channel 15 - ChHltd set, but
> reason is unknown
> dwc2 f72c.usb: hcint 0x0002, intsts 0x04200029
> dwc2 f72c.usb: dwc2_hc_chhltd_intr_dma: Channel 3 - ChHltd set, but
> reason is unknown
> dwc2 f72c.usb: hcint 0x0002, intsts 0x04200029
> dwc2 f72c.usb: dwc2_hc_chhltd_intr_dma: Channel 4 - ChHltd set, but
> reason is unknown
> dwc2 f72c.usb: hcint 0x0002, intsts 0x04200029
> dwc2 f72c.usb: dwc2_update_urb_state_abn(): trimming xfer length
>
> And the usb devices connected are basically hung at this point.
>
> It seems like if we're in host mode, we probably shouldn't run
> the dwc2_hostg_ep_disable logic, so this patch returns an error
> in that case.
>
> With this patch (along with the two previous patches mailed out
> earlier:
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lkml.org_lkml_2017_8_3_1008&d=DwIBAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=6z9Al9FrHR_ZqbbtSAsD16pvOL2S3XHxQnSzq8kusyI&m=YbED3GZFyun_ID3-6Off3kdvd9xTUepWt4lzd2__ZSs&s=65BnVw7lagEfnyuD2WHnFlGTUnjvPHWyFiwL_F1vwfE&e=
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lkml.org_lkml_2017_8_3_1010&d=DwIBAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=6z9Al9FrHR_ZqbbtSAsD16pvOL2S3XHxQnSzq8kusyI&m=YbED3GZFyun_ID3-6Off3kdvd9xTUepWt4lzd2__ZSs&s=MdrOhV0i6kRrV2mHK5zHIwE1eF21MsTkHIjvsV2k7uw&e=
> ), we avoid the mismatched interrupts and connected usb devices
> continue to function.
>
> I'm not sure if some other solution would be better here, but this seems
> to work, so I wanted to send it out for input on what the right approach
> should be.
>
> Cc: Wei Xu
> Cc: Guodong Xu
> Cc: Amit Pundir
> Cc: YongQin Liu
> Cc: John Youn
> Cc: Minas Harutyunyan
> Cc: Douglas Anderson
> Cc: Chen Yu
> Cc: Felipe Balbi
> Cc: Greg Kroah-Hartman
> Cc: linux-usb@vger.kernel.org
> Reported-by: YongQin Liu
> Signed-off-by: John Stultz
> ---
> drivers/usb/dwc2/gadget.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
> index 0d8e09c..7fd0e38 100644
> --- a/drivers/usb/dwc2/gadget.c
> +++ b/drivers/usb/dwc2/gadget.c
> @@ -4004,6 +4004,11 @@ static int dwc2_hsotg_ep_disable(struct usb_ep *ep)
> return -EINVAL;
> }
>
> + if (hsotg->op_state != OTG_STATE_B_PERIPHERAL) {
> + dev_err(hsotg->dev, "%s: called in host mode?\n", __func__);
> + return -EINVAL;
> + }
> +
> epctrl_reg = dir_in ? DIEPCTL(index) : DOEPCTL(index);
>
> spin_lock_irqsave(&hsotg->lock, flags);
>
Tested by: Minas Harutyunyan
--
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: [RESEND x2][PATCH 3/3] usb: dwc2: Fix UDC state tracking
On 9/20/2017 11:57 PM, John Stultz wrote: > It has been noticed that the dwc2 udc state reporting doesn't > seem to work (at least on HiKey boards). Where after the initial > setup, the sysfs /sys/class/udc/f72c.usb/state file would > report "configured" no matter the state of the OTG port. > > This patch adds a call so that we report to the UDC layer when > the gadget device is disconnected. > > Cc: Wei Xu > Cc: Guodong Xu > Cc: Amit Pundir > Cc: YongQin Liu > Cc: John Youn > Cc: Minas Harutyunyan > Cc: Douglas Anderson > Cc: Chen Yu > Cc: Felipe Balbi > Cc: Greg Kroah-Hartman > Cc: linux-usb@vger.kernel.org > Reported-by: Amit Pundir > Signed-off-by: John Stultz > --- > drivers/usb/dwc2/gadget.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c > index 7fd0e38..603c216 100644 > --- a/drivers/usb/dwc2/gadget.c > +++ b/drivers/usb/dwc2/gadget.c > @@ -3202,6 +3202,8 @@ void dwc2_hsotg_disconnect(struct dwc2_hsotg *hsotg) > > call_gadget(hsotg, disconnect); > hsotg->lx_state = DWC2_L3; > + > + usb_gadget_set_state(&hsotg->gadget, USB_STATE_NOTATTACHED); > } > > /** > Tested by: Minas Harutyunyan -- 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: dwc2 - ChHltd set, but reason is unknown
Hi Anders, On 10/9/2017 5:15 PM, Anders Montonen wrote: > Hi, > > We have a custom Altera Cyclone V SoCFPGA board, where connecting a > particular brand of USB memory sticks produces and enless stream of > console errors messages until it is removed from the system. > > On the board, the SoC has a fixed connection to a Microchip LAN9152 > Ethernet/hub device with two downstream ports. Apart from this issue, > every other device we have connected appears to work fine. > > The sticks are "Intenso Rainbow Line"-branded generic memory sticks using > an Alcor Micro controller with VID/PID 0x058f/0x6387. The device > descriptor has a bcdDevice field of 1.ff, but otherwise look valid. The > sticks work fine on every other host I've tried, both Windows and desktop > and embedded Linux (none with the dwc2 controller though). The stick also > works with our board if I add another USB hub in between. > > I've reproduced this with kernels 4.9.39 and 4.13.5. The controller is > configured as host-only. Any suggestions on how to proceed? I noticed that > unusual_devs.h contained an entry for another device with the same VID/PID > pair, but adding the same quirks for this device did not help. > > Regards, > Anders Montonen > > usb 1-1.2: new high-speed USB device number 4 using dwc2 > dwc2 ffb4.usb: dwc2_hc_chhltd_intr_dma: Channel 13 - ChHltd set, but > reason is unknown > dwc2 ffb4.usb: hcint 0x0002, intsts 0x0469 > dwc2 ffb4.usb: dwc2_update_urb_state_abn(): trimming xfer length > dwc2 ffb4.usb: dwc2_hc_chhltd_intr_dma: Channel 5 - ChHltd set, but > reason is unknown > dwc2 ffb4.usb: hcint 0x0002, intsts 0x0469 > dwc2 ffb4.usb: dwc2_hc_chhltd_intr_dma: Channel 11 - ChHltd set, but > reason is unknown > dwc2 ffb4.usb: hcint 0x0002, intsts 0x0469 > dwc2 ffb4.usb: dwc2_hc_chhltd_intr_dma: Channel 7 - ChHltd set, but > reason is unknown > dwc2 ffb4.usb: hcint 0x0002, intsts 0x04600029 > usb 1-1.2: New USB device found, idVendor=058f, idProduct=6387 > usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 > usb 1-1.2: Product: Intenso Rainbow Line > usb 1-1.2: Manufacturer: 6989 > usb 1-1.2: SerialNumber: 194D3F5F > usb-storage 1-1.2:1.0: USB Mass Storage device detected > scsi host0: usb-storage 1-1.2:1.0 > dwc2 ffb4.usb: dwc2_hc_chhltd_intr_dma: Channel 5 - ChHltd set, but > reason is unknown > dwc2 ffb4.usb: hcint 0x0002, intsts 0x0469 > dwc2 ffb4.usb: dwc2_update_urb_state_abn(): trimming xfer length > dwc2 ffb4.usb: dwc2_update_urb_state(): trimming xfer length > dwc2 ffb4.usb: dwc2_hc_chhltd_intr_dma: Channel 11 - ChHltd set, but > reason is unknown > dwc2 ffb4.usb: hcint 0x0002, intsts 0x0469 > dwc2 ffb4.usb: dwc2_hc_chhltd_intr_dma: Channel 12 - ChHltd set, but > reason is unknown > dwc2 ffb4.usb: hcint 0x0002, intsts 0x0469 > dwc2 ffb4.usb: dwc2_hc_chhltd_intr_dma: Channel 1 - ChHltd set, but > reason is unknown > dwc2 ffb4.usb: hcint 0x0002, intsts 0x0469 > dwc2 ffb4.usb: dwc2_hc_chhltd_intr_dma: Channel 15 - ChHltd set, but > reason is unknown > dwc2 ffb4.usb: hcint 0x0002, intsts 0x0469 > dwc2 ffb4.usb: dwc2_hc_chhltd_intr_dma: Channel 14 - ChHltd set, but > reason is unknown > dwc2 ffb4.usb: hcint 0x0002, intsts 0x0469 > dwc2 ffb4.usb: dwc2_hc_chhltd_intr_dma: Channel 11 - ChHltd set, but > reason is unknown > dwc2 ffb4.usb: hcint 0x0002, intsts 0x0469 > dwc2 ffb4.usb: dwc2_hc_chhltd_intr_dma: Channel 0 - ChHltd set, but > reason is unknown > dwc2 ffb4.usb: hcint 0x0002, intsts 0x0469 > dwc2 ffb4.usb: dwc2_hc_chhltd_intr_dma: Channel 8 - ChHltd set, but > reason is unknown > dwc2 ffb4.usb: hcint 0x0002, intsts 0x06600029 > dwc2 ffb4.usb: dwc2_hc_chhltd_intr_dma: Channel 11 - ChHltd set, but > reason is unknown > dwc2 ffb4.usb: hcint 0x0002, intsts 0x0469 > dwc2 ffb4.usb: dwc2_hc_chhltd_intr_dma: Channel 8 - ChHltd set, but > reason is unknown > dwc2 ffb4.usb: hcint 0x0002, intsts 0x0469 > dwc2 ffb4.usb: dwc2_hc_chhltd_intr_dma: Channel 8 - ChHltd set, but > reason is unknown > dwc2 ffb4.usb: hcint 0x0002, intsts 0x0469 > dwc2 ffb4.usb: dwc2_hc_chhltd_intr_dma: Channel 7 - ChHltd set, but > reason is unknown > dwc2 ffb4.usb: hcint 0x0002, intsts 0x0469 > dwc2 ffb4.usb: dwc2_hc_chhltd_intr_dma: Channel 7 - ChHltd set, but > reason is unknown > dwc2 ffb4.usb: hcint 0x0002, intsts 0x0469 > dwc2 ffb4.usb: dwc2_hc_chhltd_intr_dma: Channel 5 - ChHltd set, but > reason is unknown > dwc2 ffb4.usb: hcint 0x0002, intsts 0x0469 > dwc2 ffb4.usb: dwc2_hc_chhltd_intr_dma: Channel 2 - ChHltd set, but > reason is unknown > dwc2 ffb4.usb: hcint 0x0002, intsts 0x0469 > dwc2 ffb4.usb: dwc2_hc_chhltd_intr_dma: Channel 10 - ChHltd set, but > reason is unknown > dwc2 ffb4.usb: hcint 0x0002
Re: [RESEND x2][PATCH 0/3] dwc2 fixes for edge cases on hikey
On 10/10/2017 1:50 AM, John Stultz wrote: > On Tue, Oct 3, 2017 at 2:58 AM, Minas Harutyunyan > wrote: >> >> Could you please apply patch from Vardan Mikayelyan "usb: dwc2: Fix >> dwc2_hsotg_core_init_disconnected()" submitted at 02/25/2017 >> (https://urldefense.proofpoint.com/v2/url?u=https-3A__marc.info_-3Fl-3Dlinux-2Dusb-26m-3D148801589931039-26w-3D2&d=DwIBaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=6z9Al9FrHR_ZqbbtSAsD16pvOL2S3XHxQnSzq8kusyI&m=4y4_kSoJQIp-rJkvFNu8yXR67QxLLQrbFkjlyytMUCE&s=3Gmh7tVGk7ncQfBNUjkVdpRa1XX_jf7lWga7kR1O9bQ&e=) >> instead of your >> "usb: dwc2: Improve gadget state disconnection handling" and test again >> failing scenario. > > I may be misunderstanding htings, but I don't believe that patch > addresses the same issue I'm trying to fix (I've tested with it, and > it doesn't cause any trouble for me, but it also doesn't seem to > address the corner-cases I'm hitting). > > My "Improve gadget state disconnection handling" patch handles the > fact that when we switch from B/gadget mode to A/Host mode, we don't > always go through a gadget disconnect path. > > So instead of calling the dwc2_hsotg_disconnect() path initially when > switching to gadget mode (to avoid the state complaining that we set > it up twice), we should instead be calling dwc2_hsotg_disconnect() > when we are setting up the A/host mode. > > So for example, the follow-on fix to the UDC state won't properly work > without my "Improve gadget state disconnection handling" patch, and > "cat /sys/class/udc/f72c.usb/state" will always return configured > (assuming gadget mode was used once) regardless of the gadget state, > since we don't actually call dwc2_hsotg_disconnect when the otg plug > is removed. > >> Other 2 patches from series "[PATCH 0/3] dwc2 fixes for edge cases on >> hikey" are Ok. > > Thanks for the review/feedback! > > thanks > -john > Hi John Stultz, 1. Vardan's patch fixing issue when dwc2 switched from host to device mode. It's allow to make functional device after reconnecting without tracking UDC state. 2. I suppose that your patch "[RESEND x2][PATCH 1/3] usb: dwc2: Improve gadget state disconnection handling" not a good way to set correct UDC state. You added calling device mode functions dwc2_hsotg_disconnect() and dwc2_hsotg_core_init_disconnected() while core in Host mode and as result additional unwanted "mode mismatch" interrupts will be asserted. 3. Function dwc2_conn_id_status_change() called when connector ID status changed. This interrupt asserted only when A-plug connected or disconnected. Connecting/disconnecting B-plug doesn't assert this interrupt. Thanks, Minas -- 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: dwc2 - ChHltd set, but reason is unknown
On 10/10/2017 4:35 PM, Anders Montonen wrote: > Hi, > > On Mon, 9 Oct 2017, Minas Harutyunyan wrote: >> On 10/9/2017 5:15 PM, Anders Montonen wrote: > >>> We have a custom Altera Cyclone V SoCFPGA board, where connecting a >>> particular brand of USB memory sticks produces and enless stream of >>> console errors messages until it is removed from the system. >> Could you please provide log with enabled VERBOSE debug messages. > > I uploaded a log to > <https://urldefense.proofpoint.com/v2/url?u=http-3A__iki.fi_Anders.Montonen_verbose-2Dlog.gz&d=DwIBAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=6z9Al9FrHR_ZqbbtSAsD16pvOL2S3XHxQnSzq8kusyI&m=AedxxCtXGQmPyStoa4WGjTAFyMn0W2g6C8eQyM1o4fQ&s=IzVYoYrlpdBxTcydNmySAXt7Im3MnAe9QhC_tluwULI&e=>. > > Regards, > Anders > Hi Anders, 1. Lot of "Transaction Error--" seen in log related to mentioned by you mass storage device (addr=4 and addr=5). 2. In log seen 2 additional devices with addresses 2 and 3 (Control transfers). Could you please elaborate what kind of devices? Did you connected any hub to dwc2 root hub? Or any internal to board hub's connected to dwc2? Thanks, Minas -- 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: dwc2 - ChHltd set, but reason is unknown
On 10/16/2017 12:12 PM, Anders Montonen wrote: > On Mon, 16 Oct 2017, Minas Harutyunyan wrote: >> On 10/10/2017 4:35 PM, Anders Montonen wrote: >>> On Mon, 9 Oct 2017, Minas Harutyunyan wrote: >>>> On 10/9/2017 5:15 PM, Anders Montonen wrote: >>> >>>>> We have a custom Altera Cyclone V SoCFPGA board, where connecting a >>>>> particular brand of USB memory sticks produces and enless stream of >>>>> console errors messages until it is removed from the system. >>>> Could you please provide log with enabled VERBOSE debug messages. >>> I uploaded a log to >>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__iki.fi_Anders.Montonen_verbose-2Dlog.gz&d=DwIBAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=6z9Al9FrHR_ZqbbtSAsD16pvOL2S3XHxQnSzq8kusyI&m=AedxxCtXGQmPyStoa4WGjTAFyMn0W2g6C8eQyM1o4fQ&s=IzVYoYrlpdBxTcydNmySAXt7Im3MnAe9QhC_tluwULI&e=>. >> Hi Anders, >> 1. Lot of "Transaction Error--" seen in log related to mentioned by you >> mass storage device (addr=4 and addr=5). >> 2. In log seen 2 additional devices with addresses 2 and 3 (Control >> transfers). Could you please elaborate what kind of devices? Did you >> connected any hub to dwc2 root hub? Or any internal to board hub's >> connected to dwc2? > > Hi, > > Thanks for taking a look at this. As I mentioned in the original post, the > dwc2 root hub is connected to a Microchip LAN9152 combined USB > hub/Ethernet MAC. This is a fixed (PCB trace) connection. > <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.microchip.com_wwwproducts_en_LAN9500&d=DwIBAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=6z9Al9FrHR_ZqbbtSAsD16pvOL2S3XHxQnSzq8kusyI&m=IBDYO-V4EMAKQ3O5HXYKgUyy7TnTj4yYn-waXJTHwbE&s=4w01BQ13PgwR1hgzJEV1ZrXaIj3h1DYeSpw785nUDP8&e=> > > Regards, > Anders Montonen > Hi, Could you please also send register dump. Thanks, Minas -- 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: [RESEND x2][PATCH 0/3] dwc2 fixes for edge cases on hikey
On 10/12/2017 10:06 PM, John Stultz wrote: > On Thu, Oct 12, 2017 at 12:59 AM, Minas Harutyunyan > wrote: >> >> 1. Vardan's patch fixing issue when dwc2 switched from host to device >> mode. It's allow to make functional device after reconnecting without >> tracking UDC state. > > While I'm sure Vardan's patch is useful, I worry that its resolving a > different issue then what I'm trying to address, as it doesn't seem to > help the problems I'm seeing. > >> 2. I suppose that your patch "[RESEND x2][PATCH 1/3] usb: dwc2: Improve >> gadget state disconnection handling" not a good way to set correct UDC >> state. You added calling device mode functions dwc2_hsotg_disconnect() >> and dwc2_hsotg_core_init_disconnected() while core in Host mode and as >> result additional unwanted "mode mismatch" interrupts will be asserted. > > Apologies, I'm not sure I'm understanding you here. Forgive me if I'm > misinterpreting your feedback. > > So, the "usb: dwc2: Improve gadget state disconnection handling" isn't > itself doing the UDC state handling. > > Personally I see it as improving a previously applied fix > (dad3f793f20f - usb: dwc2: Make sure we disconnect the gadget state). > So instead of calling dwc2_hsotg_disconnect() in > dwc2_conn_id_status_change() when transitioning INTO device/B mode, > which was added due to earlier problems with state tracking (as when > we unplug the gadget cable, nothing else triggers the hsotg_disconnect > code), I'm instead suggesting we call dwc2_hsotg_disconnect() when we > transition into host/A mode. > > This only allows us to do proper UDC state handling later, since we > properly run the disconnect code for device when we switch into host > mode. > > If I'm understanding you, you seem to be objecting to this, as calling > dwc2_hsotg_disconnect() while we are transitioning to host mode can > cause "mode mismatch" interrupts. I've not seen this in practice with > this patch, but you know the logic better and it could be possible. > > Now, I'm of course open to other approaches, but it seems that we need > *something* to call dwc2_hsotg_disconnect() when the otg cable is > removed (which currently just doesn't happen). The earlier patch > calling dwc2_hsotg_disconnect() when we are entering device/B mode > avoids the state tracking warnings but, doesn't seem correct (nor does > it allow for things like proper UDC state handling). > >> 3. Function dwc2_conn_id_status_change() called when connector ID status >> changed. This interrupt asserted only when A-plug connected or >> disconnected. Connecting/disconnecting B-plug doesn't assert this interrupt. > > Ok. What I'm seeing may be somewhat hardware specific then, as on > HiKey, we have a switch that enables a on-board USB hub when the OTG > plug is removed. This may be the root of the issue, but I guess I'm > at a loss for how things should be handled here. > > When the b-plug is disconnected, we need to do something to signal to > the core that we aren't connected, no? > > And it seems that your point that the conn_id_status_change logic only > runs on the A-plug connect/disconnect mirrors the usage for the B plug > (ie: if A is disconnected, we enter B mode, thus if A is connected, > shouldn't we disable/disconnect B mode?). I suspect there's something > more subtle to your statement though, so if you could expand a bit so > I could better understand I'd appreciate it. > > thanks > -john > Hi John Stultz, On b-plug disconnect should asserted GOTGINT.SesEndDet interrupt. According previously sent by you register dump (GHWCFG2 = 0x23affc70) your core OTG_MODE=0. Bellow fragment from programming guide on Device disconnect: "7.3Device Disconnection The device session ends when the USB cable is disconnected or if the VBUS is switched off by the Host. The device disconnect flow varies depending on the value of the OTG_MODE configuration parameter. When OTG_MODE = 0,1, or 3 When OTG_MODE is set to 0,1, or 3, the device disconnect flow is as follows: 1. When the USB cable is unplugged or when the VBUS is switched off by the Host, the Device core trigger GINTSTS.OTGInt [bit 2] interrupt bit. 2. When the device application detects GINTSTS.OTGInt interrupt, it checks that the GOTGINT.SesEndDet (Session End Detected) bit is set to 1’b1." So, you should receive and handle "Session End Detected". In function dwc2_handle_otg_intr() on this interrupt (in device mode) calling dwc2_hsotg_disconnect() function. By adding your patch "[PATCH 3/3] usb: dwc2: Fix UDC state tracking" state changed to not attached as required. Thanks, Minas -- 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: [RESEND x2][PATCH 0/3] dwc2 fixes for edge cases on hikey
On 10/17/2017 1:34 AM, John Stultz wrote: > On Mon, Oct 16, 2017 at 1:36 AM, Minas Harutyunyan > wrote: >> On b-plug disconnect should asserted GOTGINT.SesEndDet interrupt. >> According previously sent by you register dump (GHWCFG2 = 0x23affc70) >> your core OTG_MODE=0. >> Bellow fragment from programming guide on Device disconnect: >> >> "7.3Device Disconnection >> The device session ends when the USB cable is disconnected or if the >> VBUS is switched off by the Host. The >> device disconnect flow varies depending on the value of the OTG_MODE >> configuration parameter. >> >> When OTG_MODE = 0,1, or 3 >> When OTG_MODE is set to 0,1, or 3, the device disconnect flow is as follows: >> 1. When the USB cable is unplugged or when the VBUS is switched off by >> the Host, the Device core >> trigger GINTSTS.OTGInt [bit 2] interrupt bit. >> 2. When the device application detects GINTSTS.OTGInt interrupt, it >> checks that the >> GOTGINT.SesEndDet (Session End Detected) bit is set to 1’b1." >> >> So, you should receive and handle "Session End Detected". In function >> dwc2_handle_otg_intr() on this interrupt (in device mode) calling >> dwc2_hsotg_disconnect() function. By adding your patch "[PATCH 3/3] usb: >> dwc2: Fix UDC state tracking" state changed to not attached as required. > > > So, on the HiKey board (using 4.14-rc5 + Vardan's patch), I'm not > seeing the GOTGINT_SES_END_DET in dwc2_handle_otg_intr() when I remove > the USB OTG cable. > > In fact, I'm not seeing any calls to dwc2_handle_otg_intr()... which > seems... odd maybe? Any clues as to what might be going wrong then? > > thanks > -john > Hi John Stultz, So, on Hikey board on unplug B connector GOTGINT.SesEndDet interrupt not asserted, instead asserted GINTSTS_CONIDSTSCHNG. Please, confirm. In this case without your patch "[PATCH 1/3] usb: dwc2: Improve gadget state disconnection handling" but by applying your patch "[PATCH 3/3] usb: dwc2: Fix UDC state tracking": 1. On B plug connect UDC state will be set to "configured" 2. On B plug disconnect - "not attached". Is it Ok for you? Meantime, I'll check with HW team why GOTGINT.SesEndDet interrupt not asserted on unplug B connector. Thanks, Minas -- 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] usb: dwc2: disable erroneous overcurrent condition
On 10/16/2017 8:40 PM, Marek Vasut wrote:
> On 10/16/2017 03:57 PM, Dinh Nguyen wrote:
>> For the case where an external VBUS is used, we should enable the external
>> VBUS comparator in the driver. This would prevent an unnecessary
>> overcurrent error which would then disable the host port.
>>
>> This patch uses the standard 'disable-over-current' binding to allow of the
>> option of disabling the over-current condition.
>>
>> Signed-off-by: Dinh Nguyen
>
> Reviewed-by: Marek Vasut
>
> Similar patch was in U-Boot for two years now and it does the trick indeed.
>
>> ---
>> drivers/usb/dwc2/core.h | 4
>> drivers/usb/dwc2/hcd.c| 5 +
>> drivers/usb/dwc2/params.c | 3 +++
>> 3 files changed, 12 insertions(+)
>>
>> diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
>> index 8367d4f9..730d7eb 100644
>> --- a/drivers/usb/dwc2/core.h
>> +++ b/drivers/usb/dwc2/core.h
>> @@ -395,6 +395,9 @@ enum dwc2_ep0_state {
>>* (default when phy_type is UTMI+ or ULPI)
>>* 1 - 6 MHz
>>* (default when phy_type is Full Speed)
>> + * @oc_disable: Flag to disable overcurrent condition.
>> + * 0 - Allow overcurrent condition to get detected
>> + * 1 - Disable overcurrent condtion to get detected
>>* @ts_dline: Enable Term Select Dline pulsing
>>* 0 - No (default)
>>* 1 - Yes
>> @@ -492,6 +495,7 @@ struct dwc2_core_params {
>> bool dma_desc_fs_enable;
>> bool host_support_fs_ls_low_power;
>> bool host_ls_low_power_phy_clk;
>> +bool oc_disable;
>>
>> u8 host_channels;
>> u16 host_rx_fifo_size;
>> diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
>> index c263114..5e20336 100644
>> --- a/drivers/usb/dwc2/hcd.c
>> +++ b/drivers/usb/dwc2/hcd.c
>> @@ -213,6 +213,11 @@ static int dwc2_hs_phy_init(struct dwc2_hsotg *hsotg,
>> bool select_phy)
>> usbcfg &= ~(GUSBCFG_PHYIF16 | GUSBCFG_DDRSEL);
>> if (hsotg->params.phy_ulpi_ddr)
>> usbcfg |= GUSBCFG_DDRSEL;
>> +
>> +/* Set external VBUS indicator as needed. */
>> +if (hsotg->params.oc_disable)
>> +usbcfg |= (GUSBCFG_ULPI_INT_VBUS_IND |
>> + GUSBCFG_INDICATORPASSTHROUGH);
>> break;
>> case DWC2_PHY_TYPE_PARAM_UTMI:
>> /* UTMI+ interface */
>> diff --git a/drivers/usb/dwc2/params.c b/drivers/usb/dwc2/params.c
>> index a3ffe97..39e02cd 100644
>> --- a/drivers/usb/dwc2/params.c
>> +++ b/drivers/usb/dwc2/params.c
>> @@ -335,6 +335,9 @@ static void dwc2_get_device_properties(struct dwc2_hsotg
>> *hsotg)
>> num);
>> }
>> }
>> +
>> +if (of_find_property(hsotg->dev->of_node, "disable-over-current", NULL))
>> +p->oc_disable = true;
>> }
>>
>> static void dwc2_check_param_otg_cap(struct dwc2_hsotg *hsotg)
>>
>
>
Hi John Youn, I checked with HW team - patch is OK.
Acked-by: Minas Harutyunyan
--
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: [RESEND x2][PATCH 0/3] dwc2 fixes for edge cases on hikey
On 10/17/2017 12:41 PM, Minas Harutyunyan wrote:
> On 10/17/2017 1:34 AM, John Stultz wrote:
>> On Mon, Oct 16, 2017 at 1:36 AM, Minas Harutyunyan
>> wrote:
>>> On b-plug disconnect should asserted GOTGINT.SesEndDet interrupt.
>>> According previously sent by you register dump (GHWCFG2 = 0x23affc70)
>>> your core OTG_MODE=0.
>>> Bellow fragment from programming guide on Device disconnect:
>>>
>>> "7.3Device Disconnection
>>> The device session ends when the USB cable is disconnected or if the
>>> VBUS is switched off by the Host. The
>>> device disconnect flow varies depending on the value of the OTG_MODE
>>> configuration parameter.
>>>
>>> When OTG_MODE = 0,1, or 3
>>> When OTG_MODE is set to 0,1, or 3, the device disconnect flow is as follows:
>>> 1. When the USB cable is unplugged or when the VBUS is switched off by
>>> the Host, the Device core
>>> trigger GINTSTS.OTGInt [bit 2] interrupt bit.
>>> 2. When the device application detects GINTSTS.OTGInt interrupt, it
>>> checks that the
>>> GOTGINT.SesEndDet (Session End Detected) bit is set to 1’b1."
>>>
>>> So, you should receive and handle "Session End Detected". In function
>>> dwc2_handle_otg_intr() on this interrupt (in device mode) calling
>>> dwc2_hsotg_disconnect() function. By adding your patch "[PATCH 3/3] usb:
>>> dwc2: Fix UDC state tracking" state changed to not attached as required.
>>
>>
>> So, on the HiKey board (using 4.14-rc5 + Vardan's patch), I'm not
>> seeing the GOTGINT_SES_END_DET in dwc2_handle_otg_intr() when I remove
>> the USB OTG cable.
>>
>> In fact, I'm not seeing any calls to dwc2_handle_otg_intr()... which
>> seems... odd maybe? Any clues as to what might be going wrong then?
>>
>> thanks
>> -john
>>
> Hi John Stultz,
> So, on Hikey board on unplug B connector GOTGINT.SesEndDet interrupt not
> asserted, instead asserted GINTSTS_CONIDSTSCHNG. Please, confirm.
>
> In this case without your patch "[PATCH 1/3] usb: dwc2: Improve gadget
> state disconnection handling" but by applying your patch "[PATCH 3/3]
> usb: dwc2: Fix UDC state tracking":
> 1. On B plug connect UDC state will be set to "configured"
> 2. On B plug disconnect - "not attached".
> Is it Ok for you?
>
> Meantime, I'll check with HW team why GOTGINT.SesEndDet interrupt not
> asserted on unplug B connector.
>
> Thanks,
> Minas
>
Hi John Stultz,
Could you please apply this patch. Please not apply your patch series
"[PATCH 0/3] dwc2 fixes for edge cases on hikey" to check only below patch.
If you confirm that this patch fix your issue with "Transaction Error"
and " ChHltd set, but reason is unknown" I'll submit to LKML as final patch.
Then can be applied your patch series, without patch 1/3 (changing in
connector id status change) to correctly set UDC states.
diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c index
f4ef159b538e..7da22152df68 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -331,6 +331,9 @@ static void dwc2_gusbcfg_init(struct dwc2_hsotg *hsotg)
usbcfg = dwc2_readl(hsotg->regs + GUSBCFG);
usbcfg &= ~(GUSBCFG_HNPCAP | GUSBCFG_SRPCAP);
+ /* Set HS/FS Timeout Calibration */
+ usbcfg |= GUSBCFG_TOUTCAL(7);
+
switch (hsotg->hw_params.op_mode) {
case GHWCFG2_OP_MODE_HNP_SRP_CAPABLE:
if (hsotg->params.otg_cap ==
Thanks,
Minas
--
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: dwc2 - ChHltd set, but reason is unknown
On 10/16/2017 7:16 PM, Anders Montonen wrote: > On Mon, 16 Oct 2017, Minas Harutyunyan wrote: >> On 10/16/2017 12:12 PM, Anders Montonen wrote: >>> On Mon, 16 Oct 2017, Minas Harutyunyan wrote: >>>> On 10/10/2017 4:35 PM, Anders Montonen wrote: >>>>> On Mon, 9 Oct 2017, Minas Harutyunyan wrote: >>>>>> On 10/9/2017 5:15 PM, Anders Montonen wrote: >>>>> >>>>>>> We have a custom Altera Cyclone V SoCFPGA board, where connecting a >>>>>>> particular brand of USB memory sticks produces and enless stream of >>>>>>> console errors messages until it is removed from the system. >>>>>> Could you please provide log with enabled VERBOSE debug messages. >>>>> I uploaded a log to >>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__iki.fi_Anders.Montonen_verbose-2Dlog.gz&d=DwIBAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=6z9Al9FrHR_ZqbbtSAsD16pvOL2S3XHxQnSzq8kusyI&m=AedxxCtXGQmPyStoa4WGjTAFyMn0W2g6C8eQyM1o4fQ&s=IzVYoYrlpdBxTcydNmySAXt7Im3MnAe9QhC_tluwULI&e=>. >>>> Hi Anders, >>>> 1. Lot of "Transaction Error--" seen in log related to mentioned by you >>>> mass storage device (addr=4 and addr=5). >>>> 2. In log seen 2 additional devices with addresses 2 and 3 (Control >>>> transfers). Could you please elaborate what kind of devices? Did you >>>> connected any hub to dwc2 root hub? Or any internal to board hub's >>>> connected to dwc2? >>> Thanks for taking a look at this. As I mentioned in the original post, the >>> dwc2 root hub is connected to a Microchip LAN9152 combined USB >>> hub/Ethernet MAC. This is a fixed (PCB trace) connection. >>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.microchip.com_wwwproducts_en_LAN9500&d=DwIBAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=6z9Al9FrHR_ZqbbtSAsD16pvOL2S3XHxQnSzq8kusyI&m=IBDYO-V4EMAKQ3O5HXYKgUyy7TnTj4yYn-waXJTHwbE&s=4w01BQ13PgwR1hgzJEV1ZrXaIj3h1DYeSpw785nUDP8&e=> >> Hi, >> Could you please also send register dump. > > I made two dumps, before inserting the USB stick and with the memory stick > inserted. > > Before: > GOTGCTL = 0x002c0001 > GOTGINT = 0x > GAHBCFG = 0x0027 > GUSBCFG = 0x21101710 > GRSTCTL = 0x8000 > GINTSTS = 0x04200021 > GINTMSK = 0xf300080e > GRXSTSR = 0x3ea8c000 > GRXSTSP = 0x3ea8c000 > GRXFSIZ = 0x0214 > GNPTXFSIZ = 0x01000214 > GNPTXSTS = 0x08080100 > GI2CCTL = 0x > GPVNDCTL = 0x > GGPIO = 0x > GUID = 0x12345678 > GSNPSID = 0x4f54293a > GHWCFG1 = 0x > GHWCFG2 = 0x238ffc90 > GHWCFG3 = 0x1f8002e8 > GHWCFG4 = 0xfe0f0020 > GLPMCFG = 0x > GPWRDN = 0x > GDFIFOCFG = 0x06142000 > ADPCTL = 0x > HPTXFSIZ = 0x03000314 > DPTXFSIZN(1) = 0x03000314 > DPTXFSIZN(2) = 0x03000314 > DPTXFSIZN(3) = 0x03000314 > DPTXFSIZN(4) = 0x03000314 > DPTXFSIZN(5) = 0x03000314 > DPTXFSIZN(6) = 0x03000314 > DPTXFSIZN(7) = 0x03000314 > DPTXFSIZN(8) = 0x03000314 > DPTXFSIZN(9) = 0x03000314 > DPTXFSIZN(10) = 0x03000314 > DPTXFSIZN(11) = 0x03000314 > DPTXFSIZN(12) = 0x03000314 > DPTXFSIZN(13) = 0x03000314 > DPTXFSIZN(14) = 0x03000314 > DPTXFSIZN(15) = 0x03000314 > DCFG = 0x > DCTL = 0x > DSTS = 0x00018c02 > DIEPMSK = 0x > DOEPMSK = 0x > DAINT = 0x > DAINTMSK = 0x > DTKNQR1 = 0x > DTKNQR2 = 0x > DTKNQR3 = 0x0c100020 > DTKNQR4 = 0x > DVBUSDIS = 0x00011d4b > DVBUSPULSE = 0x05b8 > DIEPCTL(0) = 0x00d00040 > DIEPCTL(1) = 0x00d08040 > DIEPCTL(2) = 0x00d00040 > DIEPCTL(3) = 0x00d00040 > DIEPCTL(4) = 0x00d08040 > DIEPCTL(5) = 0x00d00040 > DIEPCTL(6) = 0x00d00040 > DIEPCTL(7) = 0x00d00040 > DIEPCTL(8) = 0x00dc9810 > DIEPCTL(9) = 0x00d00040 > DIEPCTL(10) = 0x00d08040 > DIEPCTL(11) = 0x00d00040 > DIEPCTL(12) = 0x00dc9810 > DIEPCTL(13) = 0x00d00040 > DIEPCTL(14) = 0x00d08040 > DIEPCTL(15) = 0x20dc9810 > DOEPCTL(0) = 0x00d00040 > DOEPCTL(1) = 0x00d08040 > DOEPCTL(2) = 0x00d00040 > DOEPCTL(3) = 0x00d00040 > DOEPCTL(4) = 0x00d08040 > DOEPCTL(5) = 0x00d00040 > DOEPCTL(6) = 0x00d00040 > DOEPCTL(7) = 0x00d00040 > DOEPCTL(8) = 0x00dc9810 > DOEPCTL(9) = 0x00d00040 > DOEPCTL(10) = 0x00d08040 > DOEPCTL(11) = 0x00d00040 > DOEPCTL(12) = 0x00dc9810 > DOEPCTL(13) = 0x00d00040 > DOEPCTL(14) = 0x00d08040 > DOEPCTL(15) = 0x20dc9810 > DIEPINT(0) = 0x0080 > DIEPINT(1) = 0x > DIEPINT(2) = 0x > DIEPINT(3) = 0x > DIEPINT(4) = 0x > DIEPINT(5) = 0x > DIEPINT(
Re: dwc2 - ChHltd set, but reason is unknown
On 10/19/2017 2:22 PM, Anders Montonen wrote:
> On Thu, 19 Oct 2017, Minas Harutyunyan wrote:
>
>> Could you please apply this patch.
>> If you confirm that this patch fix your issue with "Transaction Error"
>> and " ChHltd set, but reason is unknown" I'll submit to LKML as final patch.
>>
>> diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c index
>> f4ef159b538e..7da22152df68 100644
>> --- a/drivers/usb/dwc2/hcd.c
>> +++ b/drivers/usb/dwc2/hcd.c
>> @@ -331,6 +331,9 @@ static void dwc2_gusbcfg_init(struct dwc2_hsotg *hsotg)
>> usbcfg = dwc2_readl(hsotg->regs + GUSBCFG);
>> usbcfg &= ~(GUSBCFG_HNPCAP | GUSBCFG_SRPCAP);
>>
>> + /* Set HS/FS Timeout Calibration */
>> + usbcfg |= GUSBCFG_TOUTCAL(7);
>> +
>> switch (hsotg->hw_params.op_mode) {
>> case GHWCFG2_OP_MODE_HNP_SRP_CAPABLE:
>> if (hsotg->params.otg_cap ==
>
> Hi Minas,
>
> The patch clearly reduced the amount of errors logged, but did not fully
> fix the problem. This was with kernel 4.9.39, I can also try with a 4.13
> kernel.
>
> Regards,
> Anders Montonen
>
Hi Anders,
In addition to above patch please apply new one:
@@ -2311,10 +2314,17 @@ static int dwc2_core_init(struct dwc2_hsotg
*hsotg, bool initial_setup)
*/
static void dwc2_core_host_init(struct dwc2_hsotg *hsotg)
{
- u32 hcfg, hfir, otgctl;
+ u32 hcfg, hfir, otgctl, usbcfg, trdtrim;
dev_dbg(hsotg->dev, "%s(%p)\n", __func__, hsotg);
+ /* Set USBTrdTim value */
+ usbcfg = dwc2_readl(hsotg->regs + GUSBCFG);
+ usbcfg &= ~GUSBCFG_USBTRDTIM_MASK;
+ trdtrim = (hsotg->phyif == GUSBCFG_PHYIF8) ? 9 : 5;
+ usbcfg |= (trdtrim << GUSBCFG_USBTRDTIM_SHIFT);
+ dwc2_writel(usbcfg, hsotg->regs + GUSBCFG);
+
/* Restart the Phy Clock */
dwc2_writel(0, hsotg->regs + PCGCTL);
Thanks,
Minas
--
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: [RESEND x2][PATCH 0/3] dwc2 fixes for edge cases on hikey
Hi John Stultz, On 10/20/2017 12:06 AM, John Stultz wrote: > On Tue, Oct 17, 2017 at 1:41 AM, Minas Harutyunyan > wrote: >> On 10/17/2017 1:34 AM, John Stultz wrote: >>> On Mon, Oct 16, 2017 at 1:36 AM, Minas Harutyunyan >>> wrote: >>>> On b-plug disconnect should asserted GOTGINT.SesEndDet interrupt. >>>> According previously sent by you register dump (GHWCFG2 = 0x23affc70) >>>> your core OTG_MODE=0. >>>> Bellow fragment from programming guide on Device disconnect: >>>> >>>> "7.3Device Disconnection >>>> The device session ends when the USB cable is disconnected or if the >>>> VBUS is switched off by the Host. The >>>> device disconnect flow varies depending on the value of the OTG_MODE >>>> configuration parameter. >>>> >>>> When OTG_MODE = 0,1, or 3 >>>> When OTG_MODE is set to 0,1, or 3, the device disconnect flow is as >>>> follows: >>>> 1. When the USB cable is unplugged or when the VBUS is switched off by >>>> the Host, the Device core >>>> trigger GINTSTS.OTGInt [bit 2] interrupt bit. >>>> 2. When the device application detects GINTSTS.OTGInt interrupt, it >>>> checks that the >>>> GOTGINT.SesEndDet (Session End Detected) bit is set to 1’b1." >>>> >>>> So, you should receive and handle "Session End Detected". In function >>>> dwc2_handle_otg_intr() on this interrupt (in device mode) calling >>>> dwc2_hsotg_disconnect() function. By adding your patch "[PATCH 3/3] usb: >>>> dwc2: Fix UDC state tracking" state changed to not attached as required. >>> >>> >>> So, on the HiKey board (using 4.14-rc5 + Vardan's patch), I'm not >>> seeing the GOTGINT_SES_END_DET in dwc2_handle_otg_intr() when I remove >>> the USB OTG cable. >>> >>> In fact, I'm not seeing any calls to dwc2_handle_otg_intr()... which >>> seems... odd maybe? Any clues as to what might be going wrong then? >>> >>> thanks >>> -john >>> >> Hi John Stultz, >> So, on Hikey board on unplug B connector GOTGINT.SesEndDet interrupt not >> asserted, instead asserted GINTSTS_CONIDSTSCHNG. Please, confirm. > > Correct. On B unplug, I see: > dwc2_handle_conn_id_status_change_intr: ++Connector ID Status Change > Interrupt++ (Host) I can't understand how on B unplug connector id status changed to host! More probable it's board design issue. Please investigate hikey design. Electrically Connector ID pin status changed when plugged A connector and when unplugged A connector because of in A connector internally ConnID pin connected to ground. In B connector ConnID pin floating. > > And I never see any calls to dwc2_handle_otg_intr(). > >> In this case without your patch "[PATCH 1/3] usb: dwc2: Improve gadget >> state disconnection handling" but by applying your patch "[PATCH 3/3] >> usb: dwc2: Fix UDC state tracking": >> 1. On B plug connect UDC state will be set to "configured" >> 2. On B plug disconnect - "not attached". >> Is it Ok for you? > On our setup I tested your patch 3/3 without patches 1/3 and 2/3 and its changed state correctly. > So this is what I expect, but I don't see it. Since without my patch, > nothing seems to call disconenct when the B plug is disconnected, I > still see: ># cat /sys/class/udc/f72c.usb/state >configured > > thanks > -john > -- 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
