Re: [PATCH] staging: dwc2: Make dwc2_hw_params.host_channels large enough

2013-10-03 Thread Matthijs Kooijman
Hi Paul, By the way, it looks like 'num_dev_ep' would have the same problem, I don't think so, since the hardware doesn't do the off-by-one trick there (presumably because having 0 endpoints make sense, but 0 host channels doesn't): hw-num_dev_ep = (hwcfg2 GHWCFG2_NUM_DEV_EP_MASK)

[PATCH] staging: dwc2: Make dwc2_hw_params.host_channels large enough

2013-10-03 Thread Matthijs Kooijman
-by: Matthijs Kooijman matth...@stdin.nl Acked-by: Paul Zimmerman pa...@synopsys.com --- This is exactly the same patch as before, but with updated tags in the commit message. drivers/staging/dwc2/core.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/dwc2/core.h b

Re: [PATCHv2] staging: dwc2: Fix code that gets the nummber of host channels

2013-10-01 Thread Matthijs Kooijman
On Tue, Oct 01, 2013 at 10:05:17AM +0300, Dan Carpenter wrote: On Tue, Oct 01, 2013 at 01:21:28AM +, Paul Zimmerman wrote: From: Dan Carpenter [mailto:dan.carpen...@oracle.com] Sent: Monday, September 30, 2013 6:09 PM Yeah. I guess it's fine... I was going to suggest adding the

Re: [PATCHv2] staging: dwc2: Fix code that gets the nummber of host channels

2013-10-01 Thread Matthijs Kooijman
Hi Dinh, Somehow I assumed that was fixed by the hardware, but I see now that you are right. Yes, making the definition larger is better than moving the + 1. This was my original fix to the problem, but I thought that it would be confusing when reading the code. I also thought about the +1

Re: [PATCHv2] staging: dwc2: Fix code that gets the nummber of host channels

2013-10-01 Thread Matthijs Kooijman
Hey Dan, Dinh, [resend]: previous reply didn't include Matthijs He sets his Mail-Followup-To: so that we don't CC him on replies. I assume it's deliberate because he only wants the copy from the mailing list? Exactly, I just set that for whatever mailing list I subscribe to. However,

Re: [PATCH 2/3] staging: dwc2: add NAK holdoff patch from downstream Pi kernel

2013-08-21 Thread Matthijs Kooijman
Hi Paul, @@ -365,6 +366,7 @@ struct dwc2_hsotg { u8 otg_port; u32 *frame_list; dma_addr_t frame_list_dma; + int next_sched_frame; This variable is still not really used, I think. Most of the mentions in the patch are assignments, except for these two: +

Re: [PATCH 2/3] staging: dwc2: add NAK holdoff patch from downstream Pi kernel

2013-08-12 Thread Matthijs Kooijman
Hi Paul, Add the NAK holdoff patch from the downstream Raspberry Pi kernel. This allows the transfer scheduler to better handle cheeky devices that just hold off using NAKs. @@ -365,6 +366,7 @@ struct dwc2_hsotg { u8 otg_port; u32 *frame_list; dma_addr_t frame_list_dma;

Re: [PATCH 0/3] staging: dwc2: 2nd try at uframe scheduler patch

2013-08-12 Thread Matthijs Kooijman
Hi Paul, Matthijs' concern about periodic endpoints with bInterval=1 seems to be unfounded. I tried a webcam, which uses a bInterval=1 isoc endpoint, on my PCI-based dev board, and it still works fine with this patch applied. For the record, I still think this concern actually exists, but you

Re: [PATCH] staging: dwc2: add microframe scheduler from downstream Pi kernel

2013-07-25 Thread Matthijs Kooijman
Hi Paul, Furthermore, I wonder about how this scheduler works exactly. What I see is: - the number usecs needed for a single transfer in a periodic qh is calculated - When the qh is scheduled, the first of the 8 microframes with enough usecs available is picked for this qh