Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1636438
| From | Peter Ujfalusi <peter.ujfalusi@ti.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH 4/4] usb: musb: tusb6010_omap: Convert to DMAengine API |
| Date | 2017-05-05 17:20 +0200 |
| Message-ID | <tDNbs-3rG-5@gated-at.bofh.it> (permalink) |
| References | <tD0aJ-4bC-21@gated-at.bofh.it> <tD0aK-4bC-27@gated-at.bofh.it> <tDuVc-7WB-17@gated-at.bofh.it> <tDwaC-tB-7@gated-at.bofh.it> <tDLCG-2l3-13@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On 2017-05-05 16:37, Peter Ujfalusi wrote:
> Tony,
>
> On 2017-05-05 00:05, Tony Lindgren wrote:
>> * Tony Lindgren <tony@atomide.com> [170504 12:43]:
>>> Hi,
>>>
>>> * Peter Ujfalusi <peter.ujfalusi@ti.com> [170503 04:00]:
>>>> With the port_window support in DMAengine and the sDMA driver we can
>>>> convert the driver to DMAengine.
>>>
>>> Actually looks like this patch still has some issues.. Pinging
>>> the n8x0 with for example ping -s1 causes things to stop working.
>>
>> Sorry it's actually ping -s2048, not -s1. Here's what happens
>> on n8x0 with first ping -s2048 with 4/4 applied:
>>
>> musb-hdrc musb-hdrc.1.auto: Busy rx dma, not using: 00000010
>> g_ether gadget: invalid EEM CRC
>> g_ether gadget: invalid EEM CRC
>> musb-hdrc musb-hdrc.1.auto: ep1 rx dma: 0x86803842 len: 512(512)
>> packet_sz: 512(512)
>> musb-hdrc musb-hdrc.1.auto: ep1 rx using 16-bit async dma from
>> 0x02000620 to 0x86803842
>> musb-hdrc musb-hdrc.1.auto: ep1 rx dma callback
>> musb-hdrc musb-hdrc.1.auto: DMA remaining 448/512
>> musb-hdrc musb-hdrc.1.auto: Busy rx dma, not using: 000001c0
>> musb-hdrc musb-hdrc.1.auto: Busy rx dma, not using: 00000008
>> musb-hdrc musb-hdrc.1.auto: ep1 rx dma: 0x869fdc02 len: 512(512)
>> packet_sz: 512(512)
>> musb-hdrc musb-hdrc.1.auto: ep1 rx using 16-bit async dma from
>> 0x02000620 to 0x869fdc02
>> musb-hdrc musb-hdrc.1.auto: ep1 rx dma callback
>> musb-hdrc musb-hdrc.1.auto: DMA remaining 448/512
>> musb-hdrc musb-hdrc.1.auto: Busy rx dma, not using: 000001c0
>> musb-hdrc musb-hdrc.1.auto: Busy rx dma, not using: 00000008
>> musb-hdrc musb-hdrc.1.auto: ep1 rx dma: 0x869fc642 len: 512(512)
>> packet_sz: 512(512)
>> musb-hdrc musb-hdrc.1.auto: ep1 rx using 16-bit async dma from
>> 0x02000620 to 0x869fc642
>> musb-hdrc musb-hdrc.1.auto: ep1 rx dma callback
>> musb-hdrc musb-hdrc.1.auto: Corrupt rx XFR_SIZE: 0x7ffffec0
>> musb-hdrc musb-hdrc.1.auto: DMA remaining 0/512
>> musb-hdrc musb-hdrc.1.auto: Busy rx dma, not using: 7ffffec0
>> musb-hdrc musb-hdrc.1.auto: Busy rx dma, not using: 00000008
>> musb-hdrc musb-hdrc.1.auto: Busy rx dma, not using: 00000010
>> musb-hdrc musb-hdrc.1.auto: Busy rx dma, not using: 7ffffcf0
>>
>> It seems the hardware dmareq line is not triggering anything
>> above?
>>
>> Also with just ping with no size specified, it seems every other
>> packet is missed or DMA interrupts are not properly triggering
>> as I'm getting these:
>>
>> g_ether gadget: invalid EEM CRC
>>
>>> This is when using only with the async gpmc access as the sync
>>> gpmc access seems to have a regression not related to this series.
>>> I'll try to track down that sync gpmc issue as that most likely
>>> hints to something being wrong in the gpmc code in general.
>>
>> And this sync gpmc issue seems to be timing related. Setting
>> DEBUG in tusb6010_omap.c makes it happen easily while without
>> it it's much harder to trigger. So probably some kind of issue
>> with GPMC sync timings.
>
> Indeed there are some interesting things happening...
> As I said, I was testing with g_cdc (CDC Composite (ECM + ACM)) and I
> found it pretty stable with DMAengine. But short story long:
>
> With the series applied and getting rid of the dma_addr & 0x2, plus
> setting the set the quirk_avoids_skb_reserve flag:
> g_cdc (ECM + ACM) boots to nfsroot most of the time, ping, scp works
> g_ether (ECM) does not boot to nfsroot, ping does not work. However if I
> disable the rx DMA with:
>
> diff --git a/drivers/usb/musb/tusb6010_omap.c
> b/drivers/usb/musb/tusb6010_omap.c
> index 8b43c4b99f04..8e0a19b47132 100644
> --- a/drivers/usb/musb/tusb6010_omap.c
> +++ b/drivers/usb/musb/tusb6010_omap.c
> @@ -512,6 +512,12 @@ tusb_omap_dma_allocate(struct dma_controller *c,
> return NULL;
> }
>
> + if (!tx) {
> + dev_err(musb->controller, "Not allowing RX DMA for ep%i %s\n",
> + chdat->epnum);
Remove the %s and s/chdat/hw_ep
and the kernel will not crash :( But still not booting with DMAengine
when RX DMA is disabled :o
> + return NULL;
> + }
> +
> for (i = 0; i < MAX_DMAREQ; i++) {
> struct dma_channel *ch = dma_channel_pool[i];
> if (ch->status == MUSB_DMA_STATUS_UNKNOWN) {
>
>
> nfsroot works, ping and scp also - TX is using DMA.
>
> g_ncm (NCM): not booting to nfsroot, no ping, but if I disable the RX
> DMA, then I have NULL pointer dereference :o
> Something is wrong for sure.
>
> But to see what I have been comparing to, I have reverted my series and
> added the dma_addr & 2 and the quirk:
>
> g_cdc (ECM + ACM): no nfsroot, no ping
> g_ether (ECM): no nfsroot, no ping
> g_ncm (NCM): no nfsroot, no ping, disabling RX DMA allow it to boot up,
> but ping kills the USB
>
> None of this is issue I think currently as the DMA is effectively
> disabled for tusb by the dma_addr & 0x2 check, but it is somehow
> bothersome...
>
> I'll try to pin-point out what is going on.
>
> As reference, my configs are:
> https://github.com/omap-audio/linux-audio/blob/peter/linux-next-wip/arch/arm/configs/nokia_n810_cdc_defconfig
>
>
> https://github.com/omap-audio/linux-audio/blob/peter/linux-next-wip/arch/arm/configs/nokia_n810_ether_defconfig
>
>
> https://github.com/omap-audio/linux-audio/blob/peter/linux-next-wip/arch/arm/configs/nokia_n810_ncm_defconfig
>
>
> - Péter
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
- Péter
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[PATCH 4/4] usb: musb: tusb6010_omap: Convert to DMAengine API Peter Ujfalusi <peter.ujfalusi@ti.com> - 2017-05-03 13:00 +0200
Re: [PATCH 4/4] usb: musb: tusb6010_omap: Convert to DMAengine API Tony Lindgren <tony@atomide.com> - 2017-05-04 21:50 +0200
Re: [PATCH 4/4] usb: musb: tusb6010_omap: Convert to DMAengine API Tony Lindgren <tony@atomide.com> - 2017-05-04 23:10 +0200
Re: [PATCH 4/4] usb: musb: tusb6010_omap: Convert to DMAengine API Peter Ujfalusi <peter.ujfalusi@ti.com> - 2017-05-05 15:40 +0200
Re: [PATCH 4/4] usb: musb: tusb6010_omap: Convert to DMAengine API Peter Ujfalusi <peter.ujfalusi@ti.com> - 2017-05-05 17:20 +0200
Re: [PATCH 4/4] usb: musb: tusb6010_omap: Convert to DMAengine API Tony Lindgren <tony@atomide.com> - 2017-05-06 01:00 +0200
Re: [PATCH 4/4] usb: musb: tusb6010_omap: Convert to DMAengine API Peter Ujfalusi <peter.ujfalusi@ti.com> - 2017-05-08 17:20 +0200
Re: [PATCH 4/4] usb: musb: tusb6010_omap: Convert to DMAengine API Tony Lindgren <tony@atomide.com> - 2017-05-08 17:40 +0200
csiph-web