[PATCH v2] usb: musb: Fix urb->hcpriv value
urb->hcpriv != NULL is used to indicate that the URB is queued [1].
Also see __usb_hcd_giveback_urb() and usb_hcd_submit_urb() for
the reference.
In this code path, the URB is actually queued and valid qh is hep->hcpriv.
[1] https://lkml.org/lkml/2019/1/25/750
Fixes: 714bc5ef3eda ("musb: potential use after free")
Signed-off-by: Matwey V. Kornilov
---
drivers/usb/musb/musb_host.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index b59ce9ad14ce..a60d52c7e112 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -2302,7 +2302,7 @@ static int musb_urb_enqueue(
* odd, rare, error prone, but legal.
*/
kfree(qh);
- qh = NULL;
+ qh = hep->hcpriv;
ret = 0;
} else
ret = musb_schedule(musb, qh,
--
2.16.4
Re: [PATCH] usb: musb: Fix potential NULL dereference
сб, 26 янв. 2019 г. в 00:37, Alan Stern :
>
> On Fri, 25 Jan 2019, Bin Liu wrote:
>
> > On Thu, Jan 24, 2019 at 09:47:02PM +0300, Matwey V. Kornilov wrote:
> > > By the way, why do we need to store the qh in urb->hcpriv?
> > > qh can always be accessible through urb->ep->hcpriv
> > > Wouldn't it be better to drop entire urb->hcpriv usage?
> >
> > I am not sure why. The code is there since the first commit in a decade
> > ago. But I tend to agree with you.
> >
> > In a quick search for urb->hcpriv and urb->ep->hcpriv, based on the
> > usage in core/hcd.c, it seems to me that urb->hcpriv should not be
> > changed in each controller driver, but I see both have been used in most
> > controller drivers. I will leave this to others to educate me.
>
> In some of the older HCDs, urb->hcpriv != NULL is used to indicate that
> urb is on an endpoint queue. Perhaps that usage was copied.
>
> Alan Stern
>
Hi,
Thank you for the explanation. I think that It would be great to
document it somewhere. Such a purpose for variable named `hcpriv' is
not entirely obvious.
Now it is clear to me, why __usb_hcd_giveback_urb() sets urb->hcpriv to NULL.
Returning to my initial patch. I think that it is still valid, though
I admit that the commit message must be rewritten.
In this code path we successfully queued the new urb, so urb->hcpriv
should be NOT NULL indicating that the urb is queued according to Alan
explanation.
musb_urb_enqueue(), musb_host.c line 2345:
if (ret == 0) {
urb->hcpriv = qh;
/* FIXME set urb->start_frame for iso/intr, it's tested in
* musb_start_urb(), but otherwise only konicawc cares ...
*/
}
--
With best regards,
Matwey V. Kornilov
Re: [PATCH] usb: musb: Fix potential NULL dereference
By the way, why do we need to store the qh in urb->hcpriv?
qh can always be accessible through urb->ep->hcpriv
Wouldn't it be better to drop entire urb->hcpriv usage?
ср, 23 янв. 2019 г. в 20:52, Matwey V. Kornilov :
>
> We assign "urb->hcpriv = qh;" a few lines down. The valid qh for the urb is
> hep->hcpriv in this code path.
>
> Fixes: 714bc5ef3eda ("musb: potential use after free")
> Signed-off-by: Matwey V. Kornilov
> ---
> drivers/usb/musb/musb_host.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
> index c6118a962d37..6f267716768e 100644
> --- a/drivers/usb/musb/musb_host.c
> +++ b/drivers/usb/musb/musb_host.c
> @@ -2336,7 +2336,7 @@ static int musb_urb_enqueue(
> * odd, rare, error prone, but legal.
> */
> kfree(qh);
> - qh = NULL;
> + qh = hep->hcpriv;
> ret = 0;
> } else
> ret = musb_schedule(musb, qh,
> --
> 2.16.4
>
--
With best regards,
Matwey V. Kornilov
[PATCH] usb: musb: Fix potential NULL dereference
We assign "urb->hcpriv = qh;" a few lines down. The valid qh for the urb is
hep->hcpriv in this code path.
Fixes: 714bc5ef3eda ("musb: potential use after free")
Signed-off-by: Matwey V. Kornilov
---
drivers/usb/musb/musb_host.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index c6118a962d37..6f267716768e 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -2336,7 +2336,7 @@ static int musb_urb_enqueue(
* odd, rare, error prone, but legal.
*/
kfree(qh);
- qh = NULL;
+ qh = hep->hcpriv;
ret = 0;
} else
ret = musb_schedule(musb, qh,
--
2.16.4
Re: musb: asix ethernet incoming UDP loss
2018-03-22 20:11 GMT+03:00 Bin Liu : > On Thu, Mar 22, 2018 at 07:31:59PM +0300, Matwey V. Kornilov wrote: >> Hi, >> >> I am running 4.16-rc6 and see the following issue with ASIX >> usb-ethernet dongle running on BeagleBoneBlack (TI AM335x). > > Does the issue also happen on older kernels? > >> My device is 100Mbps USB 2.0 dongle (ASIX AX88772 USB 2.0 Ethernet >> idVendor=0b95, idProduct=7720). I've also tried 1Gbps USB 3.0 ASIX >> dongle, that shows the same behavior. >> >> When I start iperf server on the host, and start remote client in UDP >> (iperf3 -c ip -b 100M -u). The following I see at BeagleBoneBlack >> side. > > If this is not a regression in v4.16, please try with lower '-b', musb > rx is kinda slow right now. > >> >> --- >> Server listening on 5201 >> --- >> Accepted connection from 192.168.185.4, port 38624 >> [ 5] local 192.168.185.218 port 5201 connected to 192.168.185.4 port 38088 >> [ ID] Interval Transfer Bitrate Jitter >> Lost/Total Datagrams >> [ 5] 0.00-12.09 sec 1.33 MBytes 921 Kbits/sec 1742978.415 ms >> 317/487 (65%) >> [ 5] 12.10-13.00 sec 24.0 KBytes 218 Kbits/sec 1436810.214 ms 0/3 >> (0%) >> [ 5] 13.00-13.37 sec 0.00 Bytes 0.00 bits/sec 1436810.214 ms 0/0 (0%) >> - - - - - - - - - - - - - - - - - - - - - - - - - >> [ ID] Interval Transfer Bitrate Jitter >> Lost/Total Datagrams >> [ 5] 0.00-13.37 sec 1.35 MBytes 848 Kbits/sec 1436810.214 ms >> 317/490 (65%) receiver >> --- >> Server listening on 5201 >> --- > > I will try to reproduce it when I get some time. I've just found that the issue depends on cpufreq governor. For me it appears when ondemand is used. > >> Kernel config is attached here. >> >> -- >> With best regards, >> Matwey V. Kornilov > > Regards, > -Bin. -- With best regards, Matwey V. Kornilov -- 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: musb: asix ethernet incoming UDP loss
2018-03-22 20:11 GMT+03:00 Bin Liu : > On Thu, Mar 22, 2018 at 07:31:59PM +0300, Matwey V. Kornilov wrote: >> Hi, >> >> I am running 4.16-rc6 and see the following issue with ASIX >> usb-ethernet dongle running on BeagleBoneBlack (TI AM335x). > > Does the issue also happen on older kernels? > >> My device is 100Mbps USB 2.0 dongle (ASIX AX88772 USB 2.0 Ethernet >> idVendor=0b95, idProduct=7720). I've also tried 1Gbps USB 3.0 ASIX >> dongle, that shows the same behavior. >> >> When I start iperf server on the host, and start remote client in UDP >> (iperf3 -c ip -b 100M -u). The following I see at BeagleBoneBlack >> side. > > If this is not a regression in v4.16, please try with lower '-b', musb > rx is kinda slow right now. Well, there are no packet loss with -b 3M. However, the jitter is little strange. --- Server listening on 5201 --- Accepted connection from 192.168.185.4, port 34518 [ 5] local 192.168.185.218 port 5201 connected to 192.168.185.4 port 49426 [ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams [ 5] 0.00-1.00 sec 336 KBytes 2.75 Mbits/sec 6745923728.386 ms 0/42 (0%) [ 5] 1.00-2.00 sec 360 KBytes 2.95 Mbits/sec 369614384.845 ms 0/45 (0%) [ 5] 2.00-3.00 sec 368 KBytes 3.01 Mbits/sec 18985742.538 ms 0/46 (0%) [ 5] 3.00-4.00 sec 368 KBytes 3.01 Mbits/sec 975228.606 ms 0/46 (0%) [ 5] 4.00-5.00 sec 368 KBytes 3.01 Mbits/sec 50094.216 ms 0/46 (0%) [ 5] 5.00-6.00 sec 368 KBytes 3.01 Mbits/sec 2573.393 ms 0/46 (0%) [ 5] 6.00-7.00 sec 360 KBytes 2.95 Mbits/sec 141.420 ms 0/45 (0%) [ 5] 7.00-8.00 sec 368 KBytes 3.01 Mbits/sec 7.744 ms 0/46 (0%) [ 5] 8.00-9.00 sec 368 KBytes 3.01 Mbits/sec 0.668 ms 0/46 (0%) [ 5] 9.00-10.00 sec 368 KBytes 3.01 Mbits/sec 0.307 ms 0/46 (0%) - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams [ 5] 0.00-10.04 sec 3.55 MBytes 2.96 Mbits/sec 0.307 ms 0/454 (0%) receiver --- Server listening on 5201 --- > >> >> --- >> Server listening on 5201 >> --- >> Accepted connection from 192.168.185.4, port 38624 >> [ 5] local 192.168.185.218 port 5201 connected to 192.168.185.4 port 38088 >> [ ID] Interval Transfer Bitrate Jitter >> Lost/Total Datagrams >> [ 5] 0.00-12.09 sec 1.33 MBytes 921 Kbits/sec 1742978.415 ms >> 317/487 (65%) >> [ 5] 12.10-13.00 sec 24.0 KBytes 218 Kbits/sec 1436810.214 ms 0/3 >> (0%) >> [ 5] 13.00-13.37 sec 0.00 Bytes 0.00 bits/sec 1436810.214 ms 0/0 (0%) >> - - - - - - - - - - - - - - - - - - - - - - - - - >> [ ID] Interval Transfer Bitrate Jitter >> Lost/Total Datagrams >> [ 5] 0.00-13.37 sec 1.35 MBytes 848 Kbits/sec 1436810.214 ms >> 317/490 (65%) receiver >> --- >> Server listening on 5201 >> ------- > > I will try to reproduce it when I get some time. > >> Kernel config is attached here. >> >> -- >> With best regards, >> Matwey V. Kornilov > > Regards, > -Bin. -- With best regards, Matwey V. Kornilov -- 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: [BUG] musb: broken isochronous transfer at TI AM335x platform
2018-02-16 19:27 GMT+03:00 Tony Lindgren : > * Matwey V. Kornilov [180215 17:55]: >> [] 7.219456 d= 0.000997 [181.0 + 3.667] [ 3] IN : 4.5 >> [T ] 7.219459 d= 0.03 [181.0 + 7.083] [800] DATA0: 53 da >> ... >> [] 7.220456 d= 0.000997 [182 + 3.667] [ 3] IN : 4.5 >> [T ] 7.220459 d= 0.03 [182 + 7.000] [800] DATA0: 13 36 >> ... >> [] 7.222456 d= 0.001997 [184 + 3.667] [ 3] IN : 4.5 >> [] 7.222459 d= 0.03 [184 + 7.000] [ 3] DATA0: 00 00 >> [] 7.223456 d= 0.000997 [185.0 + 3.667] [ 3] IN : 4.5 >> [] 7.223459 d= 0.03 [185.0 + 7.000] [ 3] DATA0: 00 00 >> >> Please note, that the time moment "7.221456" has missed IN request >> packet which must be sent out every 1ms in this low-speed USB case. >> Then, all incoming packets became empty ones. Such moments coincide >> with frame discarding in pwc driver. > > Well sounds like you may be able to fix it since you have a test > case for it :) Well, I am not an USB expert and I need some guidance and advice to find acceptable solution. No doubts I could implement and test it, but I would like to spend time for something known to be useful. > >> Even though IN sending is usually handled by USB host hardware, it is >> not fully true for MUSB. Every IN is triggered by musb kernel driver >> (see MUSB_RXCSR_H_REQPKT usage in musb_host_packet_rx() and >> musb_ep_program()) since auto IN is not used. Rather complicated logic >> is incorporated to decide whether IN packet has to be sent. First, >> musb_host_packet_rx() handles IN sending when current URB is not >> completed (i.e. current URB has another packet which has to be >> received next). Second, musb_advance_schedule() (via musb_start_urb()) >> handles the case when current URB is completed but there is another >> URB pending. It seems that there is a hardware logic to fire IN packet >> in a way to have exactly 1ms between two consequent INs. So, >> MUSB_RXCSR_H_REQPKT is considered as IN requesting flag. > > Yeah this is a known issue with musb, there is not much ISO support > currently really. The regression should be fixed though. > > Sorry I don't have much ideas on how to improve things here. One > way might be to attempt to split the large musb functions into > smaller functions and see if that then allows finer grained control. > > Just to try to come up with some new ideas.. Maybe there's some way > to swap the hardware EP config dynamically and have some packets > mostly preconfigured and waiting to be triggered? > > Regards, > > Tony > -- With best regards, Matwey V. Kornilov. Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia 119234, Moscow, Universitetsky pr-k 13, +7 (495) 9392382 -- 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
[BUG] musb: broken isochronous transfer at TI AM335x platform
back.
I proposed a patch to swap time-consuming urb->giveback() and
MUSB_RXCSR_H_REQPKT writing but the patch has not been accepted since
it complicates IN-requesting logic even more. [5]
However, there is another level in this issue, the performance of
urb->giveback (pwc_isoc_handler()) itself. It takes 350us for the
handler to be executed that seems to be too much to copy 9560 bytes of
the data from urb->transmit_buffer to internal pwc data structures.
Using trace event points I measured exact timings in two cases. [6]
The median memcpy() performance is 28 MBps. Given CPU frequency at
lowest possible state in 'ondemand' cpufreq policy, it roughly equals
to 10 CPU cycles per byte. Reverting commit
63c5b4ca7d0d ("usb: musb: do not change dev's dma_mask")
raises the rate to 280 MBps (~ 1 cycle per byte) and fully fixes the
issue when PIO in musb is used.
The reason is the following. pwc uses usb_alloc_coherent() to allocate
memory for urb->transfer_buffer. It seems to be a common practice
among webcam drivers: uvc, gspca and others do the same, though it is
not clear what is the reason to use so strict requirement as full
coherence here. Internally, usb_alloc_coherent() does
dma_alloc_coherent() or kmalloc() (when dev->dma_mask is NULL). In
case of MUSB, usb_alloc_coherent() always behaves as
dma_alloc_coherent() (mind 63c5b4ca7d0d, dma_mask is always set). At
the same time AFAIU AM335x doesn't have truly coherent DMA and it is
emulated in the kernel by pgprot nocache flags in the pages table. So,
we always have uncacheable (slow) memory for urb->transfer_buffer.
In conclusion, I think there is possibility to fix the issue (because
there are known cases when things work), though the way is not clear
to me. memcpy() is "slow" for uncacheable memory (not sure that
something can be done with it). usb_alloc_coherent() is probably
misused in pwc and a number of USB peripherial drivers. musb_host_rx()
interrupt handler performs less important things (urb->giveback) prior
to more important (writing MUSB_RXCSR_H_REQPKT).
References:
[1] https://www.spinics.net/lists/linux-usb/msg143956.html
[2] https://www.spinics.net/lists/linux-usb/msg145747.html
[3] http://openvizsla.org/
[4] https://www.spinics.net/lists/linux-usb/msg156107.html
[5] https://www.spinics.net/lists/linux-usb/msg156486.html
[6]
https://github.com/matwey/linux/commit/2b36e1add5aaf552923c8c1340e50bd7c2050fde
--
With best regards,
Matwey V. Kornilov.
Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia
119234, Moscow, Universitetsky pr-k 13, +7 (495) 9392382
--
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: musb: musb_host: Introduce postponed URB giveback
2017-11-16 19:32 GMT+03:00 Bin Liu : > Hi, > > On Wed, Nov 15, 2017 at 06:19:08PM +0300, Matwey V. Kornilov wrote: >> The issue is also present in 4.9.60-ti-r75 >> >> 2017-11-04 17:05 GMT+03:00 Matwey V. Kornilov : >> > Hi Bin, >> > >> > I've just checked that the issue is still present in 4.13.10. > > I am not aware of any work having been done for this yet. Well, please tell If I can help somehow. > > Regards, > -Bin. > -- With best regards, Matwey V. Kornilov. Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia 119234, Moscow, Universitetsky pr-k 13, +7 (495) 9392382 -- 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: musb: musb_host: Introduce postponed URB giveback
The issue is also present in 4.9.60-ti-r75
2017-11-04 17:05 GMT+03:00 Matwey V. Kornilov :
> Hi Bin,
>
> I've just checked that the issue is still present in 4.13.10.
>
> 2017-04-27 13:20 GMT+03:00 Matwey V. Kornilov :
>> This commit changes the order of actions undertaken in
>> musb_advance_schedule() in order to overcome issue with broken
>> isochronous transfer [1].
>>
>> There is no harm to split musb_giveback into two pieces. The first
>> unlinks finished urb, the second givebacks it. The issue here that
>> givebacking may be quite time-consuming due to urb->complete() call.
>> As it happens in case of pwc-driven web cameras. It may take about 0.5
>> ms to call __musb_giveback() that calls urb->callback() internally.
>> Under specific circumstances setting MUSB_RXCSR_H_REQPKT in subsequent
>> musb_start_urb() for the next urb will be too late to produce physical
>> IN packet. Since auto req is not used by this module the exchange
>> would be as the following:
>>
>> [] 7.220456 d= 0.000997 [182 + 3.667] [ 3] IN : 4.5
>> [T ] 7.220459 d= 0.03 [182 + 7.000] [800] DATA0: [skipped]
>> [] 7.222456 d= 0.001997 [184 + 3.667] [ 3] IN : 4.5
>> [] 7.222459 d= 0.03 [184 + 7.000] [ 3] DATA0: 00 00
>>
>> It is known that missed IN in isochronous mode makes some
>> perepherial broken. For instance, pwc-driven or uvc-driven
>> web cameras.
>> In order to workaround this issue we postpone calling
>> urb->callback() after setting MUSB_RXCSR_H_REQPKT for the
>> next urb if there is the next urb pending in queue.
>>
>> [1] https://www.spinics.net/lists/linux-usb/msg145747.html
>>
>> Fixes: f551e1352983 ("Revert "usb: musb: musb_host: Enable HCD_BH flag to
>> handle urb return in bottom half"")
>> Signed-off-by: Matwey V. Kornilov
>> ---
>> drivers/usb/musb/musb_host.c | 54
>> +---
>> 1 file changed, 46 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
>> index ac3a4952abb4..b590c2555dab 100644
>> --- a/drivers/usb/musb/musb_host.c
>> +++ b/drivers/usb/musb/musb_host.c
>> @@ -299,19 +299,24 @@ musb_start_urb(struct musb *musb, int is_in, struct
>> musb_qh *qh)
>> }
>> }
>>
>> -/* Context: caller owns controller lock, IRQs are blocked */
>> -static void musb_giveback(struct musb *musb, struct urb *urb, int status)
>> +static void __musb_giveback(struct musb *musb, struct urb *urb, int status)
>> __releases(musb->lock)
>> __acquires(musb->lock)
>> {
>> - trace_musb_urb_gb(musb, urb);
>> -
>> - usb_hcd_unlink_urb_from_ep(musb->hcd, urb);
>> spin_unlock(&musb->lock);
>> usb_hcd_giveback_urb(musb->hcd, urb, status);
>> spin_lock(&musb->lock);
>> }
>>
>> +/* Context: caller owns controller lock, IRQs are blocked */
>> +static void musb_giveback(struct musb *musb, struct urb *urb, int status)
>> +{
>> + trace_musb_urb_gb(musb, urb);
>> +
>> + usb_hcd_unlink_urb_from_ep(musb->hcd, urb);
>> + __musb_giveback(musb, urb, status);
>> +}
>> +
>> /* For bulk/interrupt endpoints only */
>> static inline void musb_save_toggle(struct musb_qh *qh, int is_in,
>> struct urb *urb)
>> @@ -346,6 +351,7 @@ static void musb_advance_schedule(struct musb *musb,
>> struct urb *urb,
>> struct musb_hw_ep *ep = qh->hw_ep;
>> int ready = qh->is_ready;
>> int status;
>> + int postponed_giveback = 0;
>>
>> status = (urb->status == -EINPROGRESS) ? 0 : urb->status;
>>
>> @@ -361,9 +367,35 @@ static void musb_advance_schedule(struct musb *musb,
>> struct urb *urb,
>> break;
>> }
>>
>> - qh->is_ready = 0;
>> - musb_giveback(musb, urb, status);
>> - qh->is_ready = ready;
>> + usb_hcd_unlink_urb_from_ep(musb->hcd, urb);
>> +
>> + /* It may take about 0.5 ms to call __musb_giveback() that
>> +* calls urb->callback() internally. Under specific circumstances
>> +* setting MUSB_RXCSR_H_REQPKT in subsequent musb_start_urb() for the
>> +* next urb will be too late to produce physical IN packet. Since
>> +* auto req is not used by this modu
Re: [PATCH] usb: musb: musb_host: Introduce postponed URB giveback
Hi Bin,
I've just checked that the issue is still present in 4.13.10.
2017-04-27 13:20 GMT+03:00 Matwey V. Kornilov :
> This commit changes the order of actions undertaken in
> musb_advance_schedule() in order to overcome issue with broken
> isochronous transfer [1].
>
> There is no harm to split musb_giveback into two pieces. The first
> unlinks finished urb, the second givebacks it. The issue here that
> givebacking may be quite time-consuming due to urb->complete() call.
> As it happens in case of pwc-driven web cameras. It may take about 0.5
> ms to call __musb_giveback() that calls urb->callback() internally.
> Under specific circumstances setting MUSB_RXCSR_H_REQPKT in subsequent
> musb_start_urb() for the next urb will be too late to produce physical
> IN packet. Since auto req is not used by this module the exchange
> would be as the following:
>
> [] 7.220456 d= 0.000997 [182 + 3.667] [ 3] IN : 4.5
> [T ] 7.220459 d= 0.03 [182 + 7.000] [800] DATA0: [skipped]
> [] 7.222456 d= 0.001997 [184 + 3.667] [ 3] IN : 4.5
> [] 7.222459 d= 0.03 [184 + 7.000] [ 3] DATA0: 00 00
>
> It is known that missed IN in isochronous mode makes some
> perepherial broken. For instance, pwc-driven or uvc-driven
> web cameras.
> In order to workaround this issue we postpone calling
> urb->callback() after setting MUSB_RXCSR_H_REQPKT for the
> next urb if there is the next urb pending in queue.
>
> [1] https://www.spinics.net/lists/linux-usb/msg145747.html
>
> Fixes: f551e1352983 ("Revert "usb: musb: musb_host: Enable HCD_BH flag to
> handle urb return in bottom half"")
> Signed-off-by: Matwey V. Kornilov
> ---
> drivers/usb/musb/musb_host.c | 54
> +---
> 1 file changed, 46 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
> index ac3a4952abb4..b590c2555dab 100644
> --- a/drivers/usb/musb/musb_host.c
> +++ b/drivers/usb/musb/musb_host.c
> @@ -299,19 +299,24 @@ musb_start_urb(struct musb *musb, int is_in, struct
> musb_qh *qh)
> }
> }
>
> -/* Context: caller owns controller lock, IRQs are blocked */
> -static void musb_giveback(struct musb *musb, struct urb *urb, int status)
> +static void __musb_giveback(struct musb *musb, struct urb *urb, int status)
> __releases(musb->lock)
> __acquires(musb->lock)
> {
> - trace_musb_urb_gb(musb, urb);
> -
> - usb_hcd_unlink_urb_from_ep(musb->hcd, urb);
> spin_unlock(&musb->lock);
> usb_hcd_giveback_urb(musb->hcd, urb, status);
> spin_lock(&musb->lock);
> }
>
> +/* Context: caller owns controller lock, IRQs are blocked */
> +static void musb_giveback(struct musb *musb, struct urb *urb, int status)
> +{
> + trace_musb_urb_gb(musb, urb);
> +
> + usb_hcd_unlink_urb_from_ep(musb->hcd, urb);
> + __musb_giveback(musb, urb, status);
> +}
> +
> /* For bulk/interrupt endpoints only */
> static inline void musb_save_toggle(struct musb_qh *qh, int is_in,
> struct urb *urb)
> @@ -346,6 +351,7 @@ static void musb_advance_schedule(struct musb *musb,
> struct urb *urb,
> struct musb_hw_ep *ep = qh->hw_ep;
> int ready = qh->is_ready;
> int status;
> + int postponed_giveback = 0;
>
> status = (urb->status == -EINPROGRESS) ? 0 : urb->status;
>
> @@ -361,9 +367,35 @@ static void musb_advance_schedule(struct musb *musb,
> struct urb *urb,
> break;
> }
>
> - qh->is_ready = 0;
> - musb_giveback(musb, urb, status);
> - qh->is_ready = ready;
> + usb_hcd_unlink_urb_from_ep(musb->hcd, urb);
> +
> + /* It may take about 0.5 ms to call __musb_giveback() that
> +* calls urb->callback() internally. Under specific circumstances
> +* setting MUSB_RXCSR_H_REQPKT in subsequent musb_start_urb() for the
> +* next urb will be too late to produce physical IN packet. Since
> +* auto req is not used by this module the exchange would be as the
> +* following:
> +*
> +* [] 7.220456 d= 0.000997 [182 + 3.667] [ 3] IN :
> 4.5
> +* [T ] 7.220459 d= 0.03 [182 + 7.000] [800] DATA0:
> [skipped]
> +* [] 7.222456 d= 0.001997 [184 + 3.667] [ 3] IN :
> 4.5
> +* [] 7.222459 d= 0.03 [184 + 7.000] [ 3] DATA0:
> 00 00
> +*
> +
Re: ftdi_sio: timing issue while setting ASYNC_LOW_LATENCY from user space
Hi all,
I've just realized what is the reason for such long delays (~250ms)
between setting ASYNC_LOW_LATENCY and starting receiving incoming
data. Setting ASYNC_LOW_LATENCY leads to setting FTDI latency timer
limit which is expressed in ms and allowed to be between 1ms and
255ms. Current default timer limit is 16ms, ASYNC_LOW_LATENCY writes
the limit to be 1ms (old default). And I feel that we cannot just
write the timer limit while timer itself is running. It looks like
there is 8-bit counter register in FT232, which is incremented by 1ms
clocks until limit is reached, then the data transfer is enforced.
Then, imagine that at the some specific time moment the counter is
lower that 16 and greater than 1 (Obviously, It happens with high
probability), say it is 8. Imagine, that PC issues
FTDI_SIO_SET_LATENCY_TIMER to set new limit to be 1ms at this moment.
Then, the criteria (counter == limit) happens only when counter will
overflow over 255 and happens to be 1 again. This explains observed
~250ms timeouts.
But I agree that increment counter is not obvious option for hardware.
If I had developed FT232, I would have made decrement counter,
counting downwards from the limit to zero. In this case I would have
really seen ~16 ms timeouts, but when measured, they appeared to be
larger than I expected in the first mail.
Nevertheless, 250ms is huge delay, it is enough to even run setserial
/dev/ttyUSB0 low_latency, then start new application process which
happens to fail with timeout due to missed input. It must be handled
inside the driver.
2017-08-28 12:32 GMT+03:00 Matwey V. Kornilov :
> 2017-08-28 11:22 GMT+03:00 Matwey V. Kornilov :
>> Hi all,
>>
>> I have an issue with the following patch:
>> c6dce2626606 ("USB: serial: ftdi_sio: fix extreme low-latency setting")
>>
>> I really need sub 16-ms latency for my peripheral and while I have no
>> problems with idea of setting ASYNC_LOW_LATENCY I would like point out
>> that it doesn't work as expected and probably need to be fixed.
>>
>> My user space code snipped is simple enough
>>
>> if (ioctl(fd, TIOCGSERIAL, &old_serial) == 0) {
>> struct serial_struct new_serial = old_serial;
>> new_serial.flags |= ASYNC_LOW_LATENCY;
>>
>> if (ioctl(fd, TIOCSSERIAL, &new_serial) < 0) {
>> return -1;
>> }
>> }
>>
>> My hardware is
>>
>> 0403:6001 Future Technology Devices International, Ltd FT232
>> USB-Serial (UART) IC
>>
>> However, currently I see that
>>
>> 1) Application of ASYNC LOW_LATENCY is not taken immediately. That is
>> what I see from incoming data which arrives with considerable delays
>> after I TIOCSSERIAL. I suppose that latency timer is applied after the
>> end of currently running period. I.e I need to wait ~16ms and only
>> after then 1ms latency started. 16ms is quite considerable time for
>> nowadays user-space application.
>
> Well, from what I see from experiments with usbmon, the transition
> time is ~250ms.
> FTDI starts sending first BULK IN 250ms after TIOCSSERIAL (and then
> repeat every 1ms). I am sure that there is incoming data in FTDI's
> internal buffer all this time. Such delay is long enough.
>
>> 2) There is no generic reliable user-space way to wait until latency
>> settings are actually applied. I haven't find the way to determine
>> from user-space that it is ftdi_sio-driven tty-device and I need to
>> apply msleep-based quirks.
>>
>> So, my suggestion is that TIOCSSERIAL must block until latency
>> settings are actually applied which can be checked internally in the
>> driver.
>>
>> --
>> With best regards,
>> Matwey V. Kornilov
>
>
>
> --
> With best regards,
> Matwey V. Kornilov
--
With best regards,
Matwey V. Kornilov
--
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: ftdi_sio: timing issue while setting ASYNC_LOW_LATENCY from user space
2017-08-28 11:22 GMT+03:00 Matwey V. Kornilov :
> Hi all,
>
> I have an issue with the following patch:
> c6dce2626606 ("USB: serial: ftdi_sio: fix extreme low-latency setting")
>
> I really need sub 16-ms latency for my peripheral and while I have no
> problems with idea of setting ASYNC_LOW_LATENCY I would like point out
> that it doesn't work as expected and probably need to be fixed.
>
> My user space code snipped is simple enough
>
> if (ioctl(fd, TIOCGSERIAL, &old_serial) == 0) {
> struct serial_struct new_serial = old_serial;
> new_serial.flags |= ASYNC_LOW_LATENCY;
>
> if (ioctl(fd, TIOCSSERIAL, &new_serial) < 0) {
> return -1;
> }
> }
>
> My hardware is
>
> 0403:6001 Future Technology Devices International, Ltd FT232
> USB-Serial (UART) IC
>
> However, currently I see that
>
> 1) Application of ASYNC LOW_LATENCY is not taken immediately. That is
> what I see from incoming data which arrives with considerable delays
> after I TIOCSSERIAL. I suppose that latency timer is applied after the
> end of currently running period. I.e I need to wait ~16ms and only
> after then 1ms latency started. 16ms is quite considerable time for
> nowadays user-space application.
Well, from what I see from experiments with usbmon, the transition
time is ~250ms.
FTDI starts sending first BULK IN 250ms after TIOCSSERIAL (and then
repeat every 1ms). I am sure that there is incoming data in FTDI's
internal buffer all this time. Such delay is long enough.
> 2) There is no generic reliable user-space way to wait until latency
> settings are actually applied. I haven't find the way to determine
> from user-space that it is ftdi_sio-driven tty-device and I need to
> apply msleep-based quirks.
>
> So, my suggestion is that TIOCSSERIAL must block until latency
> settings are actually applied which can be checked internally in the
> driver.
>
> --
> With best regards,
> Matwey V. Kornilov
--
With best regards,
Matwey V. Kornilov
--
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: ftdi_sio: timing issue while setting ASYNC_LOW_LATENCY from user space
2017-08-28 11:49 GMT+03:00 Greg KH :
> On Mon, Aug 28, 2017 at 11:22:48AM +0300, Matwey V. Kornilov wrote:
>> Hi all,
>>
>> I have an issue with the following patch:
>> c6dce2626606 ("USB: serial: ftdi_sio: fix extreme low-latency setting")
>>
>> I really need sub 16-ms latency for my peripheral and while I have no
>> problems with idea of setting ASYNC_LOW_LATENCY I would like point out
>> that it doesn't work as expected and probably need to be fixed.
>>
>> My user space code snipped is simple enough
>>
>> if (ioctl(fd, TIOCGSERIAL, &old_serial) == 0) {
>> struct serial_struct new_serial = old_serial;
>> new_serial.flags |= ASYNC_LOW_LATENCY;
>>
>> if (ioctl(fd, TIOCSSERIAL, &new_serial) < 0) {
>> return -1;
>> }
>> }
>>
>> My hardware is
>>
>> 0403:6001 Future Technology Devices International, Ltd FT232
>> USB-Serial (UART) IC
>>
>> However, currently I see that
>>
>> 1) Application of ASYNC LOW_LATENCY is not taken immediately. That is
>> what I see from incoming data which arrives with considerable delays
>> after I TIOCSSERIAL. I suppose that latency timer is applied after the
>> end of currently running period. I.e I need to wait ~16ms and only
>> after then 1ms latency started. 16ms is quite considerable time for
>> nowadays user-space application.
>
> But this is USB, you have to wait for a time for stuff like this to get
> out to the device. You just do it once at open() time and you should be
> fine, right?
Hi Greg,
Sorry, I am not sure that I understand you correctly.
Patch c6dce2626606 ("USB: serial: ftdi_sio: fix extreme low-latency
setting") changed default serial info flags.
Before the patch, there was ASYNC_LOW_LATENCY set at open() time by
default, after the patch it is unset at open(), so I have to set it
manually by ioctl() after I opened the device.
Do you say that I don't need 1ms latency? 1ms and 16ms latencies are
considerable different both from USB layer and user-space layer point
of view. 1ms is long enough time interval.
>
> And low-latency with a USB device? You know you have no guarantee at
> all from the hardware that this will happen, you are playing with fire
> here...
>
>> 2) There is no generic reliable user-space way to wait until latency
>> settings are actually applied. I haven't find the way to determine
>> from user-space that it is ftdi_sio-driven tty-device and I need to
>> apply msleep-based quirks.
>
> Why not always just do this at open() time and you should be fine?
>
> thanks,
>
> greg k-h
--
With best regards,
Matwey V. Kornilov
--
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
ftdi_sio: timing issue while setting ASYNC_LOW_LATENCY from user space
Hi all,
I have an issue with the following patch:
c6dce2626606 ("USB: serial: ftdi_sio: fix extreme low-latency setting")
I really need sub 16-ms latency for my peripheral and while I have no
problems with idea of setting ASYNC_LOW_LATENCY I would like point out
that it doesn't work as expected and probably need to be fixed.
My user space code snipped is simple enough
if (ioctl(fd, TIOCGSERIAL, &old_serial) == 0) {
struct serial_struct new_serial = old_serial;
new_serial.flags |= ASYNC_LOW_LATENCY;
if (ioctl(fd, TIOCSSERIAL, &new_serial) < 0) {
return -1;
}
}
My hardware is
0403:6001 Future Technology Devices International, Ltd FT232
USB-Serial (UART) IC
However, currently I see that
1) Application of ASYNC LOW_LATENCY is not taken immediately. That is
what I see from incoming data which arrives with considerable delays
after I TIOCSSERIAL. I suppose that latency timer is applied after the
end of currently running period. I.e I need to wait ~16ms and only
after then 1ms latency started. 16ms is quite considerable time for
nowadays user-space application.
2) There is no generic reliable user-space way to wait until latency
settings are actually applied. I haven't find the way to determine
from user-space that it is ftdi_sio-driven tty-device and I need to
apply msleep-based quirks.
So, my suggestion is that TIOCSSERIAL must block until latency
settings are actually applied which can be checked internally in the
driver.
--
With best regards,
Matwey V. Kornilov
--
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: musb: musb_host: Introduce postponed URB giveback
2017-04-29 17:24 GMT+03:00 Matwey V. Kornilov :
> 2017-04-29 11:16 GMT+03:00 Matwey V. Kornilov :
>> 2017-04-28 16:30 GMT+03:00 Bin Liu :
>>> On Fri, Apr 28, 2017 at 04:15:09PM +0300, Matwey V. Kornilov wrote:
>>>> 2017-04-28 15:43 GMT+03:00 Bin Liu :
>>>> > On Fri, Apr 28, 2017 at 03:13:55PM +0300, Matwey V. Kornilov wrote:
>>>> >> which i
>>>> >>
>>>> >> 2017-04-28 14:58 GMT+03:00 Bin Liu :
>>>> >> > On Fri, Apr 28, 2017 at 10:04:30AM +0300, Matwey V. Kornilov wrote:
>>>> >> >> 2017-04-27 20:13 GMT+03:00 Bin Liu :
>>>> >> >> > On Thu, Apr 27, 2017 at 07:26:31PM +0300, Matwey V. Kornilov wrote:
>>>> >> >> >> 2017-04-27 18:35 GMT+03:00 Bin Liu :
>>>> >> >> >> > Hi Matwey,
>>>> >> >> >> >
>>>> >> >> >> > On Thu, Apr 27, 2017 at 01:20:33PM +0300, Matwey V. Kornilov
>>>> >> >> >> > wrote:
>>>> >> >> >> >> This commit changes the order of actions undertaken in
>>>> >> >> >> >> musb_advance_schedule() in order to overcome issue with broken
>>>> >> >> >> >> isochronous transfer [1].
>>>> >> >> >> >>
>>>> >> >> >> >> There is no harm to split musb_giveback into two pieces. The
>>>> >> >> >> >> first
>>>> >> >> >> >> unlinks finished urb, the second givebacks it. The issue here
>>>> >> >> >> >> that
>>>> >> >> >> >> givebacking may be quite time-consuming due to urb->complete()
>>>> >> >> >> >> call.
>>>> >> >> >> >> As it happens in case of pwc-driven web cameras. It may take
>>>> >> >> >> >> about 0.5
>>>> >> >> >> >> ms to call __musb_giveback() that calls urb->callback()
>>>> >> >> >> >> internally.
>>>> >> >> >> >> Under specific circumstances setting MUSB_RXCSR_H_REQPKT in
>>>> >> >> >> >> subsequent
>>>> >> >> >> >> musb_start_urb() for the next urb will be too late to produce
>>>> >> >> >> >> physical
>>>> >> >> >> >> IN packet. Since auto req is not used by this module the
>>>> >> >> >> >> exchange
>>>> >> >> >> >> would be as the following:
>>>> >> >> >> >>
>>>> >> >> >> >> [] 7.220456 d= 0.000997 [182 + 3.667] [ 3] IN
>>>> >> >> >> >> : 4.5
>>>> >> >> >> >> [T ] 7.220459 d= 0.03 [182 + 7.000] [800]
>>>> >> >> >> >> DATA0: [skipped]
>>>> >> >> >> >> [] 7.222456 d= 0.001997 [184 + 3.667] [ 3] IN
>>>> >> >> >> >> : 4.5
>>>> >> >> >> >> [] 7.222459 d= 0.03 [184 + 7.000] [ 3]
>>>> >> >> >> >> DATA0: 00 00
>>>> >> >> >> >>
>>>> >> >> >> >> It is known that missed IN in isochronous mode makes some
>>>> >> >> >> >> perepherial broken. For instance, pwc-driven or uvc-driven
>>>> >> >> >> >> web cameras.
>>>> >> >> >> >> In order to workaround this issue we postpone calling
>>>> >> >> >> >> urb->callback() after setting MUSB_RXCSR_H_REQPKT for the
>>>> >> >> >> >> next urb if there is the next urb pending in queue.
>>>> >> >> >> >>
>>>> >> >> >> >> [1] https://www.spinics.net/lists/linux-usb/msg145747.html
>>>> >> >> >> >>
>>>> >> >> >> >> Fixes: f551e1352983 ("Revert "usb: musb: musb_host: Enable
>>>> >> >> >> >> HCD_BH flag to handle urb return in bottom half"")
>>>> >> >> >> >> Signed-off-by: Matwey V. Kornilov
>>>> >> >>
Re: [PATCH] usb: musb: musb_host: Introduce postponed URB giveback
2017-04-29 11:16 GMT+03:00 Matwey V. Kornilov :
> 2017-04-28 16:30 GMT+03:00 Bin Liu :
>> On Fri, Apr 28, 2017 at 04:15:09PM +0300, Matwey V. Kornilov wrote:
>>> 2017-04-28 15:43 GMT+03:00 Bin Liu :
>>> > On Fri, Apr 28, 2017 at 03:13:55PM +0300, Matwey V. Kornilov wrote:
>>> >> which i
>>> >>
>>> >> 2017-04-28 14:58 GMT+03:00 Bin Liu :
>>> >> > On Fri, Apr 28, 2017 at 10:04:30AM +0300, Matwey V. Kornilov wrote:
>>> >> >> 2017-04-27 20:13 GMT+03:00 Bin Liu :
>>> >> >> > On Thu, Apr 27, 2017 at 07:26:31PM +0300, Matwey V. Kornilov wrote:
>>> >> >> >> 2017-04-27 18:35 GMT+03:00 Bin Liu :
>>> >> >> >> > Hi Matwey,
>>> >> >> >> >
>>> >> >> >> > On Thu, Apr 27, 2017 at 01:20:33PM +0300, Matwey V. Kornilov
>>> >> >> >> > wrote:
>>> >> >> >> >> This commit changes the order of actions undertaken in
>>> >> >> >> >> musb_advance_schedule() in order to overcome issue with broken
>>> >> >> >> >> isochronous transfer [1].
>>> >> >> >> >>
>>> >> >> >> >> There is no harm to split musb_giveback into two pieces. The
>>> >> >> >> >> first
>>> >> >> >> >> unlinks finished urb, the second givebacks it. The issue here
>>> >> >> >> >> that
>>> >> >> >> >> givebacking may be quite time-consuming due to urb->complete()
>>> >> >> >> >> call.
>>> >> >> >> >> As it happens in case of pwc-driven web cameras. It may take
>>> >> >> >> >> about 0.5
>>> >> >> >> >> ms to call __musb_giveback() that calls urb->callback()
>>> >> >> >> >> internally.
>>> >> >> >> >> Under specific circumstances setting MUSB_RXCSR_H_REQPKT in
>>> >> >> >> >> subsequent
>>> >> >> >> >> musb_start_urb() for the next urb will be too late to produce
>>> >> >> >> >> physical
>>> >> >> >> >> IN packet. Since auto req is not used by this module the
>>> >> >> >> >> exchange
>>> >> >> >> >> would be as the following:
>>> >> >> >> >>
>>> >> >> >> >> [] 7.220456 d= 0.000997 [182 + 3.667] [ 3] IN
>>> >> >> >> >> : 4.5
>>> >> >> >> >> [T ] 7.220459 d= 0.03 [182 + 7.000] [800]
>>> >> >> >> >> DATA0: [skipped]
>>> >> >> >> >> [] 7.222456 d= 0.001997 [184 + 3.667] [ 3] IN
>>> >> >> >> >> : 4.5
>>> >> >> >> >> [] 7.222459 d= 0.03 [184 + 7.000] [ 3]
>>> >> >> >> >> DATA0: 00 00
>>> >> >> >> >>
>>> >> >> >> >> It is known that missed IN in isochronous mode makes some
>>> >> >> >> >> perepherial broken. For instance, pwc-driven or uvc-driven
>>> >> >> >> >> web cameras.
>>> >> >> >> >> In order to workaround this issue we postpone calling
>>> >> >> >> >> urb->callback() after setting MUSB_RXCSR_H_REQPKT for the
>>> >> >> >> >> next urb if there is the next urb pending in queue.
>>> >> >> >> >>
>>> >> >> >> >> [1] https://www.spinics.net/lists/linux-usb/msg145747.html
>>> >> >> >> >>
>>> >> >> >> >> Fixes: f551e1352983 ("Revert "usb: musb: musb_host: Enable
>>> >> >> >> >> HCD_BH flag to handle urb return in bottom half"")
>>> >> >> >> >> Signed-off-by: Matwey V. Kornilov
>>> >> >> >> >
>>> >> >> >> > Thanks for the effort of working on this long standing issue, I
>>> >> >> >> > know you
>>> >> >> >> > have spent alot of time on it, but what I am thinking is
Re: [PATCH] usb: musb: musb_host: Introduce postponed URB giveback
2017-04-28 16:30 GMT+03:00 Bin Liu :
> On Fri, Apr 28, 2017 at 04:15:09PM +0300, Matwey V. Kornilov wrote:
>> 2017-04-28 15:43 GMT+03:00 Bin Liu :
>> > On Fri, Apr 28, 2017 at 03:13:55PM +0300, Matwey V. Kornilov wrote:
>> >> which i
>> >>
>> >> 2017-04-28 14:58 GMT+03:00 Bin Liu :
>> >> > On Fri, Apr 28, 2017 at 10:04:30AM +0300, Matwey V. Kornilov wrote:
>> >> >> 2017-04-27 20:13 GMT+03:00 Bin Liu :
>> >> >> > On Thu, Apr 27, 2017 at 07:26:31PM +0300, Matwey V. Kornilov wrote:
>> >> >> >> 2017-04-27 18:35 GMT+03:00 Bin Liu :
>> >> >> >> > Hi Matwey,
>> >> >> >> >
>> >> >> >> > On Thu, Apr 27, 2017 at 01:20:33PM +0300, Matwey V. Kornilov
>> >> >> >> > wrote:
>> >> >> >> >> This commit changes the order of actions undertaken in
>> >> >> >> >> musb_advance_schedule() in order to overcome issue with broken
>> >> >> >> >> isochronous transfer [1].
>> >> >> >> >>
>> >> >> >> >> There is no harm to split musb_giveback into two pieces. The
>> >> >> >> >> first
>> >> >> >> >> unlinks finished urb, the second givebacks it. The issue here
>> >> >> >> >> that
>> >> >> >> >> givebacking may be quite time-consuming due to urb->complete()
>> >> >> >> >> call.
>> >> >> >> >> As it happens in case of pwc-driven web cameras. It may take
>> >> >> >> >> about 0.5
>> >> >> >> >> ms to call __musb_giveback() that calls urb->callback()
>> >> >> >> >> internally.
>> >> >> >> >> Under specific circumstances setting MUSB_RXCSR_H_REQPKT in
>> >> >> >> >> subsequent
>> >> >> >> >> musb_start_urb() for the next urb will be too late to produce
>> >> >> >> >> physical
>> >> >> >> >> IN packet. Since auto req is not used by this module the exchange
>> >> >> >> >> would be as the following:
>> >> >> >> >>
>> >> >> >> >> [] 7.220456 d= 0.000997 [182 + 3.667] [ 3] IN :
>> >> >> >> >> 4.5
>> >> >> >> >> [T ] 7.220459 d= 0.03 [182 + 7.000] [800] DATA0:
>> >> >> >> >> [skipped]
>> >> >> >> >> [] 7.222456 d= 0.001997 [184 + 3.667] [ 3] IN :
>> >> >> >> >> 4.5
>> >> >> >> >> [] 7.222459 d= 0.03 [184 + 7.000] [ 3] DATA0:
>> >> >> >> >> 00 00
>> >> >> >> >>
>> >> >> >> >> It is known that missed IN in isochronous mode makes some
>> >> >> >> >> perepherial broken. For instance, pwc-driven or uvc-driven
>> >> >> >> >> web cameras.
>> >> >> >> >> In order to workaround this issue we postpone calling
>> >> >> >> >> urb->callback() after setting MUSB_RXCSR_H_REQPKT for the
>> >> >> >> >> next urb if there is the next urb pending in queue.
>> >> >> >> >>
>> >> >> >> >> [1] https://www.spinics.net/lists/linux-usb/msg145747.html
>> >> >> >> >>
>> >> >> >> >> Fixes: f551e1352983 ("Revert "usb: musb: musb_host: Enable
>> >> >> >> >> HCD_BH flag to handle urb return in bottom half"")
>> >> >> >> >> Signed-off-by: Matwey V. Kornilov
>> >> >> >> >
>> >> >> >> > Thanks for the effort of working on this long standing issue, I
>> >> >> >> > know you
>> >> >> >> > have spent alot of time on it, but what I am thinking is instead
>> >> >> >> > of
>> >> >> >> > workaround the problem we need to understand the root cause - why
>> >> >> >> > uvc-video takes longer to exec the urb callback, why only am335x
>> >> >> >> > reported this issue. This is on my backlo
Re: [PATCH] usb: musb: musb_host: Introduce postponed URB giveback
2017-04-28 15:43 GMT+03:00 Bin Liu :
> On Fri, Apr 28, 2017 at 03:13:55PM +0300, Matwey V. Kornilov wrote:
>> which i
>>
>> 2017-04-28 14:58 GMT+03:00 Bin Liu :
>> > On Fri, Apr 28, 2017 at 10:04:30AM +0300, Matwey V. Kornilov wrote:
>> >> 2017-04-27 20:13 GMT+03:00 Bin Liu :
>> >> > On Thu, Apr 27, 2017 at 07:26:31PM +0300, Matwey V. Kornilov wrote:
>> >> >> 2017-04-27 18:35 GMT+03:00 Bin Liu :
>> >> >> > Hi Matwey,
>> >> >> >
>> >> >> > On Thu, Apr 27, 2017 at 01:20:33PM +0300, Matwey V. Kornilov wrote:
>> >> >> >> This commit changes the order of actions undertaken in
>> >> >> >> musb_advance_schedule() in order to overcome issue with broken
>> >> >> >> isochronous transfer [1].
>> >> >> >>
>> >> >> >> There is no harm to split musb_giveback into two pieces. The first
>> >> >> >> unlinks finished urb, the second givebacks it. The issue here that
>> >> >> >> givebacking may be quite time-consuming due to urb->complete() call.
>> >> >> >> As it happens in case of pwc-driven web cameras. It may take about
>> >> >> >> 0.5
>> >> >> >> ms to call __musb_giveback() that calls urb->callback() internally.
>> >> >> >> Under specific circumstances setting MUSB_RXCSR_H_REQPKT in
>> >> >> >> subsequent
>> >> >> >> musb_start_urb() for the next urb will be too late to produce
>> >> >> >> physical
>> >> >> >> IN packet. Since auto req is not used by this module the exchange
>> >> >> >> would be as the following:
>> >> >> >>
>> >> >> >> [] 7.220456 d= 0.000997 [182 + 3.667] [ 3] IN : 4.5
>> >> >> >> [T ] 7.220459 d= 0.03 [182 + 7.000] [800] DATA0:
>> >> >> >> [skipped]
>> >> >> >> [] 7.222456 d= 0.001997 [184 + 3.667] [ 3] IN : 4.5
>> >> >> >> [] 7.222459 d= 0.03 [184 + 7.000] [ 3] DATA0: 00
>> >> >> >> 00
>> >> >> >>
>> >> >> >> It is known that missed IN in isochronous mode makes some
>> >> >> >> perepherial broken. For instance, pwc-driven or uvc-driven
>> >> >> >> web cameras.
>> >> >> >> In order to workaround this issue we postpone calling
>> >> >> >> urb->callback() after setting MUSB_RXCSR_H_REQPKT for the
>> >> >> >> next urb if there is the next urb pending in queue.
>> >> >> >>
>> >> >> >> [1] https://www.spinics.net/lists/linux-usb/msg145747.html
>> >> >> >>
>> >> >> >> Fixes: f551e1352983 ("Revert "usb: musb: musb_host: Enable HCD_BH
>> >> >> >> flag to handle urb return in bottom half"")
>> >> >> >> Signed-off-by: Matwey V. Kornilov
>> >> >> >
>> >> >> > Thanks for the effort of working on this long standing issue, I know
>> >> >> > you
>> >> >> > have spent alot of time on it, but what I am thinking is instead of
>> >> >> > workaround the problem we need to understand the root cause - why
>> >> >> > uvc-video takes longer to exec the urb callback, why only am335x
>> >> >> > reported this issue. This is on my backlog, just seems never got time
>> >> >> > for it...
>> >> >>
>> >> >> Have you tried other SoCs with Invetra MUSB?
>> >> >
>> >> > That is the plan, I got an A20 board, but haven't bring it up yet.
>> >> >
>> >> >>
>> >> >> >
>> >> >> > Ideally MUSB driver should be just using HCD_BH flag and let the
>> >> >> > core to
>> >> >> > handle the urb callback, regardless the usb transfer types.
>> >> >>
>> >> >> I think the only reason why everything worked before with HCD_BH is
>> >> >> that execution of urb->callback() was placed after musb_start(). The
>> >> >> order of operations matters.
>> >> >> However, you said that something was also wrong with HCD_BH and o
Re: [PATCH] usb: musb: musb_host: Introduce postponed URB giveback
which i
2017-04-28 14:58 GMT+03:00 Bin Liu :
> On Fri, Apr 28, 2017 at 10:04:30AM +0300, Matwey V. Kornilov wrote:
>> 2017-04-27 20:13 GMT+03:00 Bin Liu :
>> > On Thu, Apr 27, 2017 at 07:26:31PM +0300, Matwey V. Kornilov wrote:
>> >> 2017-04-27 18:35 GMT+03:00 Bin Liu :
>> >> > Hi Matwey,
>> >> >
>> >> > On Thu, Apr 27, 2017 at 01:20:33PM +0300, Matwey V. Kornilov wrote:
>> >> >> This commit changes the order of actions undertaken in
>> >> >> musb_advance_schedule() in order to overcome issue with broken
>> >> >> isochronous transfer [1].
>> >> >>
>> >> >> There is no harm to split musb_giveback into two pieces. The first
>> >> >> unlinks finished urb, the second givebacks it. The issue here that
>> >> >> givebacking may be quite time-consuming due to urb->complete() call.
>> >> >> As it happens in case of pwc-driven web cameras. It may take about 0.5
>> >> >> ms to call __musb_giveback() that calls urb->callback() internally.
>> >> >> Under specific circumstances setting MUSB_RXCSR_H_REQPKT in subsequent
>> >> >> musb_start_urb() for the next urb will be too late to produce physical
>> >> >> IN packet. Since auto req is not used by this module the exchange
>> >> >> would be as the following:
>> >> >>
>> >> >> [] 7.220456 d= 0.000997 [182 + 3.667] [ 3] IN : 4.5
>> >> >> [T ] 7.220459 d= 0.03 [182 + 7.000] [800] DATA0:
>> >> >> [skipped]
>> >> >> [] 7.222456 d= 0.001997 [184 + 3.667] [ 3] IN : 4.5
>> >> >> [] 7.222459 d= 0.03 [184 + 7.000] [ 3] DATA0: 00 00
>> >> >>
>> >> >> It is known that missed IN in isochronous mode makes some
>> >> >> perepherial broken. For instance, pwc-driven or uvc-driven
>> >> >> web cameras.
>> >> >> In order to workaround this issue we postpone calling
>> >> >> urb->callback() after setting MUSB_RXCSR_H_REQPKT for the
>> >> >> next urb if there is the next urb pending in queue.
>> >> >>
>> >> >> [1] https://www.spinics.net/lists/linux-usb/msg145747.html
>> >> >>
>> >> >> Fixes: f551e1352983 ("Revert "usb: musb: musb_host: Enable HCD_BH flag
>> >> >> to handle urb return in bottom half"")
>> >> >> Signed-off-by: Matwey V. Kornilov
>> >> >
>> >> > Thanks for the effort of working on this long standing issue, I know you
>> >> > have spent alot of time on it, but what I am thinking is instead of
>> >> > workaround the problem we need to understand the root cause - why
>> >> > uvc-video takes longer to exec the urb callback, why only am335x
>> >> > reported this issue. This is on my backlog, just seems never got time
>> >> > for it...
>> >>
>> >> Have you tried other SoCs with Invetra MUSB?
>> >
>> > That is the plan, I got an A20 board, but haven't bring it up yet.
>> >
>> >>
>> >> >
>> >> > Ideally MUSB driver should be just using HCD_BH flag and let the core to
>> >> > handle the urb callback, regardless the usb transfer types.
>> >>
>> >> I think the only reason why everything worked before with HCD_BH is
>> >> that execution of urb->callback() was placed after musb_start(). The
>> >> order of operations matters.
>> >> However, you said that something was also wrong with HCD_BH and other
>> >> peripherals.
>> >
>> > HCD_BH flag cause some issues which are docummented in the commit log of
>> > f551e1352983.
>> > But even with HCD_BH flag, it didn't work for uvc webcams, it still misses
>> > IN tokens. It might helps pwc webcams though.
>>
>> pwc webcams work with HCD_BH fine indeed.
>
> yeah, this is what you told long time ago.
>
>>
>> >
>> >> > The MUSB drivers are already messy and complicated enough for
>> >> > maintenance, I'd like to understand the root cause of the delay first
>> >> > before decide how to solve the issue.
>> >> >
>> >>
>> >> I feel from playing with OpenVizsla that REQPKT should be set well in
>> >> advance. So, time window to set the flag is a
Re: [PATCH] usb: musb: musb_host: Introduce postponed URB giveback
2017-04-27 20:13 GMT+03:00 Bin Liu :
> On Thu, Apr 27, 2017 at 07:26:31PM +0300, Matwey V. Kornilov wrote:
>> 2017-04-27 18:35 GMT+03:00 Bin Liu :
>> > Hi Matwey,
>> >
>> > On Thu, Apr 27, 2017 at 01:20:33PM +0300, Matwey V. Kornilov wrote:
>> >> This commit changes the order of actions undertaken in
>> >> musb_advance_schedule() in order to overcome issue with broken
>> >> isochronous transfer [1].
>> >>
>> >> There is no harm to split musb_giveback into two pieces. The first
>> >> unlinks finished urb, the second givebacks it. The issue here that
>> >> givebacking may be quite time-consuming due to urb->complete() call.
>> >> As it happens in case of pwc-driven web cameras. It may take about 0.5
>> >> ms to call __musb_giveback() that calls urb->callback() internally.
>> >> Under specific circumstances setting MUSB_RXCSR_H_REQPKT in subsequent
>> >> musb_start_urb() for the next urb will be too late to produce physical
>> >> IN packet. Since auto req is not used by this module the exchange
>> >> would be as the following:
>> >>
>> >> [] 7.220456 d= 0.000997 [182 + 3.667] [ 3] IN : 4.5
>> >> [T ] 7.220459 d= 0.03 [182 + 7.000] [800] DATA0: [skipped]
>> >> [] 7.222456 d= 0.001997 [184 + 3.667] [ 3] IN : 4.5
>> >> [] 7.222459 d= 0.03 [184 + 7.000] [ 3] DATA0: 00 00
>> >>
>> >> It is known that missed IN in isochronous mode makes some
>> >> perepherial broken. For instance, pwc-driven or uvc-driven
>> >> web cameras.
>> >> In order to workaround this issue we postpone calling
>> >> urb->callback() after setting MUSB_RXCSR_H_REQPKT for the
>> >> next urb if there is the next urb pending in queue.
>> >>
>> >> [1] https://www.spinics.net/lists/linux-usb/msg145747.html
>> >>
>> >> Fixes: f551e1352983 ("Revert "usb: musb: musb_host: Enable HCD_BH flag to
>> >> handle urb return in bottom half"")
>> >> Signed-off-by: Matwey V. Kornilov
>> >
>> > Thanks for the effort of working on this long standing issue, I know you
>> > have spent alot of time on it, but what I am thinking is instead of
>> > workaround the problem we need to understand the root cause - why
>> > uvc-video takes longer to exec the urb callback, why only am335x
>> > reported this issue. This is on my backlog, just seems never got time
>> > for it...
>>
>> Have you tried other SoCs with Invetra MUSB?
>
> That is the plan, I got an A20 board, but haven't bring it up yet.
>
>>
>> >
>> > Ideally MUSB driver should be just using HCD_BH flag and let the core to
>> > handle the urb callback, regardless the usb transfer types.
>>
>> I think the only reason why everything worked before with HCD_BH is
>> that execution of urb->callback() was placed after musb_start(). The
>> order of operations matters.
>> However, you said that something was also wrong with HCD_BH and other
>> peripherals.
>
> HCD_BH flag cause some issues which are docummented in the commit log of
> f551e1352983.
> But even with HCD_BH flag, it didn't work for uvc webcams, it still misses
> IN tokens. It might helps pwc webcams though.
pwc webcams work with HCD_BH fine indeed.
>
>> > The MUSB drivers are already messy and complicated enough for
>> > maintenance, I'd like to understand the root cause of the delay first
>> > before decide how to solve the issue.
>> >
>>
>> I feel from playing with OpenVizsla that REQPKT should be set well in
>> advance. So, time window to set the flag is actually smaller than 1
>> ms.
>> urb->callback() is never takes longer than 0.4 ms for pwc driver, but
>> INs are skipped.
>
> Setting REQPKT in advance might be the solution, but I'd like to
> understand why only Isoch transfer shows such issue, and why only am335x
> reports this issue. The later concerns me more if this would be a
> system issue not only in usb module.
0.4 ms is about 10 CPU cycles given that CPU is running at 275Mhz
(which is the lowest cpufreq). Long time ago, I run pwc webcam with
SIS Vortex86 at 200Mhz It worked fine. I would not say that it is
extraordinary value.
Do you think that somewhere CPU cycles are wasted globally for some reason?
>
>> At the same time musb_host doesn't utilize AutoReq here. I think many
>> other USB host controllers (OHCI?) just rely on hardware to send IN
>> packets in time.
>
> For Isoch transfer, MUSB has to be programmed for every transaction, but
> urb callback takes too long with spinlock held, which cause MUSB misses
> issuing IN tokens.
>
> Regards,
> -Bin.
>
--
With best regards,
Matwey V. Kornilov.
Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia
119234, Moscow, Universitetsky pr-k 13, +7 (495) 9392382
--
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: musb: musb_host: Introduce postponed URB giveback
2017-04-27 18:35 GMT+03:00 Bin Liu :
> Hi Matwey,
>
> On Thu, Apr 27, 2017 at 01:20:33PM +0300, Matwey V. Kornilov wrote:
>> This commit changes the order of actions undertaken in
>> musb_advance_schedule() in order to overcome issue with broken
>> isochronous transfer [1].
>>
>> There is no harm to split musb_giveback into two pieces. The first
>> unlinks finished urb, the second givebacks it. The issue here that
>> givebacking may be quite time-consuming due to urb->complete() call.
>> As it happens in case of pwc-driven web cameras. It may take about 0.5
>> ms to call __musb_giveback() that calls urb->callback() internally.
>> Under specific circumstances setting MUSB_RXCSR_H_REQPKT in subsequent
>> musb_start_urb() for the next urb will be too late to produce physical
>> IN packet. Since auto req is not used by this module the exchange
>> would be as the following:
>>
>> [] 7.220456 d= 0.000997 [182 + 3.667] [ 3] IN : 4.5
>> [T ] 7.220459 d= 0.03 [182 + 7.000] [800] DATA0: [skipped]
>> [] 7.222456 d= 0.001997 [184 + 3.667] [ 3] IN : 4.5
>> [] 7.222459 d= 0.03 [184 + 7.000] [ 3] DATA0: 00 00
>>
>> It is known that missed IN in isochronous mode makes some
>> perepherial broken. For instance, pwc-driven or uvc-driven
>> web cameras.
>> In order to workaround this issue we postpone calling
>> urb->callback() after setting MUSB_RXCSR_H_REQPKT for the
>> next urb if there is the next urb pending in queue.
>>
>> [1] https://www.spinics.net/lists/linux-usb/msg145747.html
>>
>> Fixes: f551e1352983 ("Revert "usb: musb: musb_host: Enable HCD_BH flag to
>> handle urb return in bottom half"")
>> Signed-off-by: Matwey V. Kornilov
>
> Thanks for the effort of working on this long standing issue, I know you
> have spent alot of time on it, but what I am thinking is instead of
> workaround the problem we need to understand the root cause - why
> uvc-video takes longer to exec the urb callback, why only am335x
> reported this issue. This is on my backlog, just seems never got time
> for it...
Have you tried other SoCs with Invetra MUSB?
>
> Ideally MUSB driver should be just using HCD_BH flag and let the core to
> handle the urb callback, regardless the usb transfer types.
I think the only reason why everything worked before with HCD_BH is
that execution of urb->callback() was placed after musb_start(). The
order of operations matters.
However, you said that something was also wrong with HCD_BH and other
peripherals.
>
> The MUSB drivers are already messy and complicated enough for
> maintenance, I'd like to understand the root cause of the delay first
> before decide how to solve the issue.
>
I feel from playing with OpenVizsla that REQPKT should be set well in
advance. So, time window to set the flag is actually smaller than 1
ms.
urb->callback() is never takes longer than 0.4 ms for pwc driver, but
INs are skipped.
At the same time musb_host doesn't utilize AutoReq here. I think many
other USB host controllers (OHCI?) just rely on hardware to send IN
packets in time.
> Regards,
> -Bin.
>
>> ---
>> drivers/usb/musb/musb_host.c | 54
>> +---
>> 1 file changed, 46 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
>> index ac3a4952abb4..b590c2555dab 100644
>> --- a/drivers/usb/musb/musb_host.c
>> +++ b/drivers/usb/musb/musb_host.c
>> @@ -299,19 +299,24 @@ musb_start_urb(struct musb *musb, int is_in, struct
>> musb_qh *qh)
>> }
>> }
>>
>> -/* Context: caller owns controller lock, IRQs are blocked */
>> -static void musb_giveback(struct musb *musb, struct urb *urb, int status)
>> +static void __musb_giveback(struct musb *musb, struct urb *urb, int status)
>> __releases(musb->lock)
>> __acquires(musb->lock)
>> {
>> - trace_musb_urb_gb(musb, urb);
>> -
>> - usb_hcd_unlink_urb_from_ep(musb->hcd, urb);
>> spin_unlock(&musb->lock);
>> usb_hcd_giveback_urb(musb->hcd, urb, status);
>> spin_lock(&musb->lock);
>> }
>>
>> +/* Context: caller owns controller lock, IRQs are blocked */
>> +static void musb_giveback(struct musb *musb, struct urb *urb, int status)
>> +{
>> + trace_musb_urb_gb(musb, urb);
>> +
>> + usb_hcd_unlink_urb_from_ep(musb->hcd, urb);
>> + __musb_giveback(musb, urb, status);
>> +}
>> +
>> /* For bulk/interrupt endpoints only */
>> static
[PATCH] usb: musb: musb_host: Introduce postponed URB giveback
This commit changes the order of actions undertaken in
musb_advance_schedule() in order to overcome issue with broken
isochronous transfer [1].
There is no harm to split musb_giveback into two pieces. The first
unlinks finished urb, the second givebacks it. The issue here that
givebacking may be quite time-consuming due to urb->complete() call.
As it happens in case of pwc-driven web cameras. It may take about 0.5
ms to call __musb_giveback() that calls urb->callback() internally.
Under specific circumstances setting MUSB_RXCSR_H_REQPKT in subsequent
musb_start_urb() for the next urb will be too late to produce physical
IN packet. Since auto req is not used by this module the exchange
would be as the following:
[] 7.220456 d= 0.000997 [182 + 3.667] [ 3] IN : 4.5
[T ] 7.220459 d= 0.03 [182 + 7.000] [800] DATA0: [skipped]
[] 7.222456 d= 0.001997 [184 + 3.667] [ 3] IN : 4.5
[] 7.222459 d= 0.03 [184 + 7.000] [ 3] DATA0: 00 00
It is known that missed IN in isochronous mode makes some
perepherial broken. For instance, pwc-driven or uvc-driven
web cameras.
In order to workaround this issue we postpone calling
urb->callback() after setting MUSB_RXCSR_H_REQPKT for the
next urb if there is the next urb pending in queue.
[1] https://www.spinics.net/lists/linux-usb/msg145747.html
Fixes: f551e1352983 ("Revert "usb: musb: musb_host: Enable HCD_BH flag to
handle urb return in bottom half"")
Signed-off-by: Matwey V. Kornilov
---
drivers/usb/musb/musb_host.c | 54 +---
1 file changed, 46 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index ac3a4952abb4..b590c2555dab 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -299,19 +299,24 @@ musb_start_urb(struct musb *musb, int is_in, struct
musb_qh *qh)
}
}
-/* Context: caller owns controller lock, IRQs are blocked */
-static void musb_giveback(struct musb *musb, struct urb *urb, int status)
+static void __musb_giveback(struct musb *musb, struct urb *urb, int status)
__releases(musb->lock)
__acquires(musb->lock)
{
- trace_musb_urb_gb(musb, urb);
-
- usb_hcd_unlink_urb_from_ep(musb->hcd, urb);
spin_unlock(&musb->lock);
usb_hcd_giveback_urb(musb->hcd, urb, status);
spin_lock(&musb->lock);
}
+/* Context: caller owns controller lock, IRQs are blocked */
+static void musb_giveback(struct musb *musb, struct urb *urb, int status)
+{
+ trace_musb_urb_gb(musb, urb);
+
+ usb_hcd_unlink_urb_from_ep(musb->hcd, urb);
+ __musb_giveback(musb, urb, status);
+}
+
/* For bulk/interrupt endpoints only */
static inline void musb_save_toggle(struct musb_qh *qh, int is_in,
struct urb *urb)
@@ -346,6 +351,7 @@ static void musb_advance_schedule(struct musb *musb, struct
urb *urb,
struct musb_hw_ep *ep = qh->hw_ep;
int ready = qh->is_ready;
int status;
+ int postponed_giveback = 0;
status = (urb->status == -EINPROGRESS) ? 0 : urb->status;
@@ -361,9 +367,35 @@ static void musb_advance_schedule(struct musb *musb,
struct urb *urb,
break;
}
- qh->is_ready = 0;
- musb_giveback(musb, urb, status);
- qh->is_ready = ready;
+ usb_hcd_unlink_urb_from_ep(musb->hcd, urb);
+
+ /* It may take about 0.5 ms to call __musb_giveback() that
+* calls urb->callback() internally. Under specific circumstances
+* setting MUSB_RXCSR_H_REQPKT in subsequent musb_start_urb() for the
+* next urb will be too late to produce physical IN packet. Since
+* auto req is not used by this module the exchange would be as the
+* following:
+*
+* [] 7.220456 d= 0.000997 [182 + 3.667] [ 3] IN : 4.5
+* [T ] 7.220459 d= 0.03 [182 + 7.000] [800] DATA0:
[skipped]
+* [] 7.222456 d= 0.001997 [184 + 3.667] [ 3] IN : 4.5
+* [] 7.222459 d= 0.03 [184 + 7.000] [ 3] DATA0: 00
00
+*
+* It is known that missed IN in isochronous mode makes some
+* perepherial broken. For instance, pwc-driven or uvc-driven
+* web cameras.
+* In order to workaround this issue we postpone calling
+* urb->callback() after setting MUSB_RXCSR_H_REQPKT for the
+* next urb if there is the next urb pending in queue.
+*/
+ if (is_in && qh->type == USB_ENDPOINT_XFER_ISOC
+ && !list_empty(&qh->hep->urb_list)) {
+ postponed_giveback = 1;
+ } else {
+ qh->is_ready = 0;
+ __musb_giveback(musb, urb, status);
+
Re: musb: isoc pkt loss with pwc
0b a9 aa 8e 52 a5 2b 6c fa 50 ca a4 76
a0 54 b4 9b 47 ad 1d 22 b5 12 1c 95 4d a2 84 43 b9 0d a2 74 15 45 05
41 49 b2 28 94 66 d1 a8 46 a0 94 6a a4 6c da 1e ba 94 4a b5 01 55 6d
8a aa 1c ab d2 96 55 c5 36 41 d4 87 1a 5b 3c Unexpected ERR CRC
[] 7.222456 d= 0.001997 [184 + 3.667] [ 3] IN : 4.5
[] 7.222459 d= 0.03 [184 + 7.000] [ 3] DATA0: 00 00
[] 7.223456 d= 0.000997 [185.0 + 3.667] [ 3] IN : 4.5
[] 7.223459 d= 0.03 [185.0 + 7.000] [ 3] DATA0: 00 00
[] 7.224456 d= 0.000997 [186 + 3.583] [ 3] IN : 4.5
[] 7.224459 d= 0.03 [186 + 6.917] [ 3] DATA0: 00 00
[] 7.225456 d= 0.000997 [187.0 + 3.667] [ 3] IN : 4.5
[] 7.225459 d= 0.03 [187.0 + 7.000] [ 3] DATA0: 00 00
Here, I believe that IN request is missed at 7.221 and this leads to
the issues with missed data.
2016-08-28 13:13 GMT+03:00 Matwey V. Kornilov :
> Hello Bin,
>
> I would like to start new thread on my issue. Let me recall where the issue
> is:
> There is 100% frame lost in pwc webcam driver due to lots of
> zero-length packages coming from musb driver.
> The issue is present in all kernels (including 4.8) starting from the commit:
>
> f551e13529833e052f75ec628a8af7b034af20f9 ("Revert "usb: musb:
> musb_host: Enable HCD_BH flag to handle urb return in bottom half"")
>
> The issue is here both when DMA enabled and DMA disabled.
>
> Attached here is a plot. The vertical axis designates the value of
> rx_count variable from function musb_host_packet_rx(). One may see
> that there are only two possibilities: 0 bytes and 956 bytes.
> The horizontal axis is the last three digits of the timestamp when
> musb_host_packet_rx() invoked. I.e for [ 38.115379] it is 379. Given
> that my webcam is USB 1.1 and base time is 1 ms, then all frames
> should be grouped close to some single value. (Repeating package
> receive event every 1 ms won't change last tree digits considerably)
> One may see that it is not true, in practice there are two groups. And
> receive time strongly correlates with the package size. Packages
> received near round ms are 956 bytes long, packages received near 400
> us are 0 bytes long.
>
> I don't know how exactly SOF and IN are synchronized in musb, could
> someone give a hint? But from what I see the time difference between
> subsequent IN package requests is sometimes more than 1 ms due to
> heavy urb->complete() callback. After such events only zero length
> packages are received. Surprisingly, that `synchronization' is
> recovered sometimes in the middle of URB like the following:
>
> [ 163.207363] musb int
> [ 163.207380] rx_count 0
> [ 163.207393] req pkt c9c76200 // Expected musb int at 163.208393
> [ 163.207403] int end
> // No interrupt at 163.208393
> [ 163.209001] musb int
> [ 163.209017] rx_count 956
> [ 163.209108] req pkt c9c76200
> [ 163.209118] int end
>
> And then the series of 956 bytes long packages are received until URB
> giveback will occasionally break it again.
> Do I understand correctly, that SOF is generated every 1 ms by
> hardware and should be followed by IN immediately?
> If so, it is not clear to me how they should be aligned when the time
> difference between to subsequent INs is greater than 1ms.
>
> --
> With best regards,
> Matwey V. Kornilov.
> Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia
> 119991, Moscow, Universitetsky pr-k 13, +7 (495) 9392382
--
With best regards,
Matwey V. Kornilov.
Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia
119234, Moscow, Universitetsky pr-k 13, +7 (495) 9392382
--
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: musb: isoc pkt loss with pwc
2016-11-01 23:33 GMT+03:00 Bin Liu : > On Sat, Oct 15, 2016 at 10:25:42PM +0300, Matwey V. Kornilov wrote: > > [snip] > >> >>> > Which means without this commit your camera has been working without >> >>> > issues, and this is a regression with this commit, right? >> >>> > >> >>> >> >>> Right >> >> >> >> Okay, thanks for confirming. >> >> >> >> But we cannot just simply add this flag, as it breaks many other use >> >> cases. I will continue work on this to find a solution which works on >> >> all use cases. >> >> >> > >> > Ok, thank you. >> > >> >> Excuse me. Any news? > > Not solved yet. I used uvc class to exam the issue. uvc_video driver > takes longer time to execute urb complete() on my platform. Using HCD_BH > flag doesn't help, because urb->complete() was running with irq disabled > because of the local_irq. Removing the local_irq as in [1] causes the > system to lockup - uart and network stop responsing, so hard to debug > for now. > > Right now, I added a workqueue in musb_host to handle urb->complete() > with local_irq removed. It seems working fine in my test, but it is > still a long way find the proper fix for upstream. I didn't have much > time on this issue. > > Once I have a proper solution, I will post it to the mailing list. > Maybe I could help somehow? > [1] http://marc.info/?l=linux-usb&m=147560701431267&w=2 > > Regards, > -Bin. > -- With best regards, Matwey V. Kornilov. Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia 119991, Moscow, Universitetsky pr-k 13, +7 (495) 9392382 -- 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: musb: isoc pkt loss with pwc
2016-09-12 22:38 GMT+03:00 Matwey V. Kornilov :
> 2016-09-12 21:57 GMT+03:00 Bin Liu :
>> Hi,
>>
>> On Mon, Sep 12, 2016 at 11:52:46AM +0300, Matwey V. Kornilov wrote:
>>> 2016-09-12 6:28 GMT+03:00 Bin Liu :
>>> > Hi,
>>> >
>>> > On Tue, Aug 30, 2016 at 11:44:33PM +0300, Matwey V. Kornilov wrote:
>>> >> 2016-08-30 21:30 GMT+03:00 Bin Liu :
>>> >> > Hi,
>>> >> >
>>> >> > On Sun, Aug 28, 2016 at 01:13:55PM +0300, Matwey V. Kornilov wrote:
>>> >> >> Hello Bin,
>>> >> >>
>>> >> >> I would like to start new thread on my issue. Let me recall where the
>>> >> >> issue is:
>>> >> >> There is 100% frame lost in pwc webcam driver due to lots of
>>> >> >> zero-length packages coming from musb driver.
>>> >> >
>>> >> > What is the video resolution and fps?
>>> >>
>>> >> 640x480 YUV420 10 frames per second.
>>> >> pwc uses proprietary compression during device-host transmission, but
>>> >> I don't know how effective it is.
>>> >
>>> > The data rate for VGA YUV420 @10fps is 640x480*1.5*10 = 4.6MB/s, which
>>> > is much higher than full-speed 12Mbps. So the video data on the bus is
>>> > compressed, not YUV420, I believe.
>>> >
>>> >>
>>> >> >
>>> >> >> The issue is present in all kernels (including 4.8) starting from the
>>> >> >> commit:
>>> >> >>
>>> >> >> f551e13529833e052f75ec628a8af7b034af20f9 ("Revert "usb: musb:
>>> >> >> musb_host: Enable HCD_BH flag to handle urb return in bottom half"")
>>> >> >
>>> >> > What is the behavior without this commit?
>>> >>
>>> >> Without this commit all frames are being received correctly. Single
>>> >
>>> > Which means without this commit your camera has been working without
>>> > issues, and this is a regression with this commit, right?
>>> >
>>>
>>> Right
>>
>> Okay, thanks for confirming.
>>
>> But we cannot just simply add this flag, as it breaks many other use
>> cases. I will continue work on this to find a solution which works on
>> all use cases.
>>
>
> Ok, thank you.
>
Excuse me. Any news?
>> Regards,
>> -Bin.
>>
>
>
>
> --
> With best regards,
> Matwey V. Kornilov.
> Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia
> 119991, Moscow, Universitetsky pr-k 13, +7 (495) 9392382
--
With best regards,
Matwey V. Kornilov.
Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia
119991, Moscow, Universitetsky pr-k 13, +7 (495) 9392382
--
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: musb: isoc pkt loss with pwc
2016-09-12 21:57 GMT+03:00 Bin Liu :
> Hi,
>
> On Mon, Sep 12, 2016 at 11:52:46AM +0300, Matwey V. Kornilov wrote:
>> 2016-09-12 6:28 GMT+03:00 Bin Liu :
>> > Hi,
>> >
>> > On Tue, Aug 30, 2016 at 11:44:33PM +0300, Matwey V. Kornilov wrote:
>> >> 2016-08-30 21:30 GMT+03:00 Bin Liu :
>> >> > Hi,
>> >> >
>> >> > On Sun, Aug 28, 2016 at 01:13:55PM +0300, Matwey V. Kornilov wrote:
>> >> >> Hello Bin,
>> >> >>
>> >> >> I would like to start new thread on my issue. Let me recall where the
>> >> >> issue is:
>> >> >> There is 100% frame lost in pwc webcam driver due to lots of
>> >> >> zero-length packages coming from musb driver.
>> >> >
>> >> > What is the video resolution and fps?
>> >>
>> >> 640x480 YUV420 10 frames per second.
>> >> pwc uses proprietary compression during device-host transmission, but
>> >> I don't know how effective it is.
>> >
>> > The data rate for VGA YUV420 @10fps is 640x480*1.5*10 = 4.6MB/s, which
>> > is much higher than full-speed 12Mbps. So the video data on the bus is
>> > compressed, not YUV420, I believe.
>> >
>> >>
>> >> >
>> >> >> The issue is present in all kernels (including 4.8) starting from the
>> >> >> commit:
>> >> >>
>> >> >> f551e13529833e052f75ec628a8af7b034af20f9 ("Revert "usb: musb:
>> >> >> musb_host: Enable HCD_BH flag to handle urb return in bottom half"")
>> >> >
>> >> > What is the behavior without this commit?
>> >>
>> >> Without this commit all frames are being received correctly. Single
>> >
>> > Which means without this commit your camera has been working without
>> > issues, and this is a regression with this commit, right?
>> >
>>
>> Right
>
> Okay, thanks for confirming.
>
> But we cannot just simply add this flag, as it breaks many other use
> cases. I will continue work on this to find a solution which works on
> all use cases.
>
Ok, thank you.
> Regards,
> -Bin.
>
--
With best regards,
Matwey V. Kornilov.
Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia
119991, Moscow, Universitetsky pr-k 13, +7 (495) 9392382
--
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: musb: isoc pkt loss with pwc
2016-09-12 6:28 GMT+03:00 Bin Liu :
> Hi,
>
> On Tue, Aug 30, 2016 at 11:44:33PM +0300, Matwey V. Kornilov wrote:
>> 2016-08-30 21:30 GMT+03:00 Bin Liu :
>> > Hi,
>> >
>> > On Sun, Aug 28, 2016 at 01:13:55PM +0300, Matwey V. Kornilov wrote:
>> >> Hello Bin,
>> >>
>> >> I would like to start new thread on my issue. Let me recall where the
>> >> issue is:
>> >> There is 100% frame lost in pwc webcam driver due to lots of
>> >> zero-length packages coming from musb driver.
>> >
>> > What is the video resolution and fps?
>>
>> 640x480 YUV420 10 frames per second.
>> pwc uses proprietary compression during device-host transmission, but
>> I don't know how effective it is.
>
> The data rate for VGA YUV420 @10fps is 640x480*1.5*10 = 4.6MB/s, which
> is much higher than full-speed 12Mbps. So the video data on the bus is
> compressed, not YUV420, I believe.
>
>>
>> >
>> >> The issue is present in all kernels (including 4.8) starting from the
>> >> commit:
>> >>
>> >> f551e13529833e052f75ec628a8af7b034af20f9 ("Revert "usb: musb:
>> >> musb_host: Enable HCD_BH flag to handle urb return in bottom half"")
>> >
>> > What is the behavior without this commit?
>>
>> Without this commit all frames are being received correctly. Single
>
> Which means without this commit your camera has been working without
> issues, and this is a regression with this commit, right?
>
Right
>> one issue is a number of zero byte package at the beginning of iso
>> stream (probably during camera internal sync, I have to check how the
>> stream is started on x86 later). But they are never repeated after
>> this.
>
> I think this zero byte packet is normal. I don't know much about pwc,
> but with uvc cameras, the beginning of the stream is similar, with many
> 12-bytes packets. 12 byte is typical uvc header length, so 12-byte
> packet means zero data payload.
>
>>
>> >>
>> >> The issue is here both when DMA enabled and DMA disabled.
>> >>
>> >> Attached here is a plot. The vertical axis designates the value of
>> >> rx_count variable from function musb_host_packet_rx(). One may see
>> >> that there are only two possibilities: 0 bytes and 956 bytes.
>> >> The horizontal axis is the last three digits of the timestamp when
>> >> musb_host_packet_rx() invoked. I.e for [ 38.115379] it is 379. Given
>> >> that my webcam is USB 1.1 and base time is 1 ms, then all frames
>> >> should be grouped close to some single value. (Repeating package
>> >> receive event every 1 ms won't change last tree digits considerably)
>> >> One may see that it is not true, in practice there are two groups. And
>> >> receive time strongly correlates with the package size. Packages
>> >> received near round ms are 956 bytes long, packages received near 400
>> >> us are 0 bytes long.
>> >
>> > When the host IN packet passed the deadline, the device drops the video
>> > data, so device only sends 0 byte packet (or 12 bytes which is only the
>> > uvc header without data payload).
>>
>> Doesn't it mean that free part of the frame, i.e (1 msec - (t_IN -
>> t_SOF)) is not enough to transmit 956 bytes in device firmware
>> opinion?
>>
>> >
>> >>
>> >> I don't know how exactly SOF and IN are synchronized in musb, could
>> >> someone give a hint? But from what I see the time difference between
>> >> subsequent IN package requests is sometimes more than 1 ms due to
>> >> heavy urb->complete() callback. After such events only zero length
>> >
>> > Why musb delayed the IN packets, it needs to be investigated. I will
>> > start to look at this webcam issue with musb soon, after I cleaned up
>> > the musb patches queued recently. I will update once I have progress in
>> > my investigation.
>>
>> The last package in URB has different code path.
>> IN after the last package of URB is not requested in musb_host_packet_rx().
>> Instead, IN request is performed in the end of musb_advance_schedule()
>> by musb_start_urb().
>
> I am seeing the samilar issue with my Logitech pro9000 camera, and I
> have been looking at it whenever I got some time.
>
> I believe the IN after the last packet is coming from a new URB, that is
> why it is performed by musb_start_urb().
>
>> musb_advance_schedule()
Re: musb: isoc pkt loss with pwc
2016-08-30 21:30 GMT+03:00 Bin Liu :
> Hi,
>
> On Sun, Aug 28, 2016 at 01:13:55PM +0300, Matwey V. Kornilov wrote:
>> Hello Bin,
>>
>> I would like to start new thread on my issue. Let me recall where the issue
>> is:
>> There is 100% frame lost in pwc webcam driver due to lots of
>> zero-length packages coming from musb driver.
>
> What is the video resolution and fps?
640x480 YUV420 10 frames per second.
pwc uses proprietary compression during device-host transmission, but
I don't know how effective it is.
>
>> The issue is present in all kernels (including 4.8) starting from the commit:
>>
>> f551e13529833e052f75ec628a8af7b034af20f9 ("Revert "usb: musb:
>> musb_host: Enable HCD_BH flag to handle urb return in bottom half"")
>
> What is the behavior without this commit?
Without this commit all frames are being received correctly. Single
one issue is a number of zero byte package at the beginning of iso
stream (probably during camera internal sync, I have to check how the
stream is started on x86 later). But they are never repeated after
this.
>>
>> The issue is here both when DMA enabled and DMA disabled.
>>
>> Attached here is a plot. The vertical axis designates the value of
>> rx_count variable from function musb_host_packet_rx(). One may see
>> that there are only two possibilities: 0 bytes and 956 bytes.
>> The horizontal axis is the last three digits of the timestamp when
>> musb_host_packet_rx() invoked. I.e for [ 38.115379] it is 379. Given
>> that my webcam is USB 1.1 and base time is 1 ms, then all frames
>> should be grouped close to some single value. (Repeating package
>> receive event every 1 ms won't change last tree digits considerably)
>> One may see that it is not true, in practice there are two groups. And
>> receive time strongly correlates with the package size. Packages
>> received near round ms are 956 bytes long, packages received near 400
>> us are 0 bytes long.
>
> When the host IN packet passed the deadline, the device drops the video
> data, so device only sends 0 byte packet (or 12 bytes which is only the
> uvc header without data payload).
Doesn't it mean that free part of the frame, i.e (1 msec - (t_IN -
t_SOF)) is not enough to transmit 956 bytes in device firmware
opinion?
>
>>
>> I don't know how exactly SOF and IN are synchronized in musb, could
>> someone give a hint? But from what I see the time difference between
>> subsequent IN package requests is sometimes more than 1 ms due to
>> heavy urb->complete() callback. After such events only zero length
>
> Why musb delayed the IN packets, it needs to be investigated. I will
> start to look at this webcam issue with musb soon, after I cleaned up
> the musb patches queued recently. I will update once I have progress in
> my investigation.
The last package in URB has different code path.
IN after the last package of URB is not requested in musb_host_packet_rx().
Instead, IN request is performed in the end of musb_advance_schedule()
by musb_start_urb().
musb_advance_schedule() has the following code:
qh->is_ready = 0;
musb_giveback(musb, urb, status);
qh->is_ready = ready;
Which can be executed pretty long if urb->complete() handler is not
postphoned by HCD_BH.
In my case, it takes about 300 us for pwc urb->complete() to run.
Probably, the logic should be modified here, to run giveback on
current URB after the start of next URB.
>
>> packages are received. Surprisingly, that `synchronization' is
>> recovered sometimes in the middle of URB like the following:
>>
>> [ 163.207363] musb int
>> [ 163.207380] rx_count 0
>> [ 163.207393] req pkt c9c76200 // Expected musb int at 163.208393
>> [ 163.207403] int end
>> // No interrupt at 163.208393
>> [ 163.209001] musb int
>> [ 163.209017] rx_count 956
>> [ 163.209108] req pkt c9c76200
>> [ 163.209118] int end
>
> It looks like you used plain printk for these debug logs, which normally
> is not a good idea for this type of performance debugging. printk
> changes timing especially if the log is printed via uart console.
>
I think next time I will use tracepoints or something like that. Thank
you for pointing.
>> And then the series of 956 bytes long packages are received until URB
>> giveback will occasionally break it again.
>> Do I understand correctly, that SOF is generated every 1 ms by
>> hardware and should be followed by IN immediately?
>
> My understanding is that is does not have to be 'immediately', for
> example, in a few ns, it should be okay as long as the interval of IN
> packets is fixed, but I fo
musb: isoc pkt loss with pwc
Hello Bin,
I would like to start new thread on my issue. Let me recall where the issue is:
There is 100% frame lost in pwc webcam driver due to lots of
zero-length packages coming from musb driver.
The issue is present in all kernels (including 4.8) starting from the commit:
f551e13529833e052f75ec628a8af7b034af20f9 ("Revert "usb: musb:
musb_host: Enable HCD_BH flag to handle urb return in bottom half"")
The issue is here both when DMA enabled and DMA disabled.
Attached here is a plot. The vertical axis designates the value of
rx_count variable from function musb_host_packet_rx(). One may see
that there are only two possibilities: 0 bytes and 956 bytes.
The horizontal axis is the last three digits of the timestamp when
musb_host_packet_rx() invoked. I.e for [ 38.115379] it is 379. Given
that my webcam is USB 1.1 and base time is 1 ms, then all frames
should be grouped close to some single value. (Repeating package
receive event every 1 ms won't change last tree digits considerably)
One may see that it is not true, in practice there are two groups. And
receive time strongly correlates with the package size. Packages
received near round ms are 956 bytes long, packages received near 400
us are 0 bytes long.
I don't know how exactly SOF and IN are synchronized in musb, could
someone give a hint? But from what I see the time difference between
subsequent IN package requests is sometimes more than 1 ms due to
heavy urb->complete() callback. After such events only zero length
packages are received. Surprisingly, that `synchronization' is
recovered sometimes in the middle of URB like the following:
[ 163.207363] musb int
[ 163.207380] rx_count 0
[ 163.207393] req pkt c9c76200 // Expected musb int at 163.208393
[ 163.207403] int end
// No interrupt at 163.208393
[ 163.209001] musb int
[ 163.209017] rx_count 956
[ 163.209108] req pkt c9c76200
[ 163.209118] int end
And then the series of 956 bytes long packages are received until URB
giveback will occasionally break it again.
Do I understand correctly, that SOF is generated every 1 ms by
hardware and should be followed by IN immediately?
If so, it is not clear to me how they should be aligned when the time
difference between to subsequent INs is greater than 1ms.
--
With best regards,
Matwey V. Kornilov.
Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia
119991, Moscow, Universitetsky pr-k 13, +7 (495) 9392382
Rplots.pdf
Description: Adobe PDF document
Re: pwc over musb: 100% frame drop (lost) on high resolution stream
2016-08-22 11:32 GMT+03:00 Matwey V. Kornilov : > 2016-08-22 1:00 GMT+03:00 Alan Stern : >> On Sun, 21 Aug 2016, Matwey V. Kornilov wrote: >> >>> In both cases (with or without HCD_BH), usb_hcd_giveback_urb is called >>> every 0.01 sec. It is not clear why behavior is so different. >> >> What behavior are you asking about? The difference between HCD_BH set >> and not set? >> > > The difference between HCD_BH set and not set is that when it is not > set then usb_hcd_giveback_urb() receive zero-length URBs. And this > breaks my pwc webcam. And the question is how to fix it. > As far as I can see, usb_hcd_giveback_urb is being called with the > same rate in both cases, so zero-length URBs are probably supposed to > be data-carrying. > I can't understand what makes the difference. What I found to this moment is the following: 1) isoc transfer works in two empirical modes or regimes. I called them 'normal' one and 'broken'. 1a) In the 'normal' mode, every package is 956 bytes long and c->desc->pd2 (see cppi41_irq) is 149a 1b) In the 'broken' mode, every package is 0 bytes long and c->desc->pd2 (see cppi41_irq) is 1408009a 2) In each mode cppi41_irq is invoked every 1 ms. 2a) When the time lag between two subsequent calls of cppi41_irq is greater (up to 2 ms) or less (0.3 ms) than 1 ms then the mode is switched. It can happen inside single URB without calling complete(). So, the data are flowing in large bulks of either empty or full packages. 3) When HCD_BH is not set, then this two regimes are being flipped constantly breaking internal pwc logic. When HCD_BH is set, then first dozens packages are empty, then there is a pause between cppi41_irq and the rest packages are fine. >> Alan Stern >> > > > > -- > With best regards, > Matwey V. Kornilov. > Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia > 119991, Moscow, Universitetsky pr-k 13, +7 (495) 9392382 -- With best regards, Matwey V. Kornilov. Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia 119991, Moscow, Universitetsky pr-k 13, +7 (495) 9392382 -- 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: pwc over musb: 100% frame drop (lost) on high resolution stream
2016-08-22 1:00 GMT+03:00 Alan Stern : > On Sun, 21 Aug 2016, Matwey V. Kornilov wrote: > >> In both cases (with or without HCD_BH), usb_hcd_giveback_urb is called >> every 0.01 sec. It is not clear why behavior is so different. > > What behavior are you asking about? The difference between HCD_BH set > and not set? > The difference between HCD_BH set and not set is that when it is not set then usb_hcd_giveback_urb() receive zero-length URBs. And this breaks my pwc webcam. And the question is how to fix it. As far as I can see, usb_hcd_giveback_urb is being called with the same rate in both cases, so zero-length URBs are probably supposed to be data-carrying. > Alan Stern > -- With best regards, Matwey V. Kornilov. Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia 119991, Moscow, Universitetsky pr-k 13, +7 (495) 9392382 -- 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: pwc over musb: 100% frame drop (lost) on high resolution stream
In both cases (with or without HCD_BH), usb_hcd_giveback_urb is called
every 0.01 sec. It is not clear why behavior is so different.
2016-08-21 17:02 GMT+03:00 Matwey V. Kornilov :
> I've just measured that
>
> it takes 150 us in average for pwc_isoc_handler to run
> 350 us - __usb_hcd_giveback_urb
>
> So, it takes either 50 us (with HCD_BH) or 400 us (without) for
> usb_hcd_giveback_urb to run.
>
>
> 2016-08-20 21:09 GMT+03:00 Matwey V. Kornilov :
>> I've just checked 4.8-rc2 - same behaviour.
>>
>> 2016-08-18 16:31 GMT+03:00 Matwey V. Kornilov :
>>> Any ideas?
>>>
>>> 2016-08-04 23:08 GMT+03:00 Matwey V. Kornilov :
>>>> When DMA is not used, I see the same behavior: lots of zero-length
>>>> packages received.
>>>>
>>>> Can It be related to some kind of USB overflow due to long input data
>>>> processing with disabled IRQ?
>>>> When HCD_BC is used then part of processing is postponed and this can
>>>> explain greater throughput due to better latency.
>>>>
>>>> 2016-08-04 22:58 GMT+03:00 Matwey V. Kornilov :
>>>>> I've just found that in such cases, when DMA actual length is zero,
>>>>> both cppi41_channel->prog_len and txstate.residue equal 960 at
>>>>> musb_cppi41 line 225:
>>>>>
>>>>> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/usb/musb/musb_cppi41.c#n225
>>>>>
>>>>> 2016-08-04 22:08 GMT+03:00 Matwey V. Kornilov :
>>>>>> I've just found that dma->actual_len equals to zero in most cases at
>>>>>> musb_host.c line 1946.
>>>>>> And this produces zero-length packages.
>>>>>>
>>>>>> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/usb/musb/musb_host.c#n1946
>>>>>>
>>>>>> Any ideas why?
>>>>>>
>>>>>> 2016-08-04 19:57 GMT+03:00 Matwey V. Kornilov :
>>>>>>> I've just found that many packages in URBs have zero actual_length (It
>>>>>>> is a question why).
>>>>>>> Then the following end of frame criteria leads to `frame underflow'
>>>>>>> message:
>>>>>>>
>>>>>>> if (flen < pdev->vlast_packet_size) {
>>>>>>> /* Shorter packet... end of frame */
>>>>>>> if (pdev->vsync == 2)
>>>>>>> pwc_frame_complete(pdev);
>>>>>>> if (pdev->fill_buf == NULL)
>>>>>>> pdev->fill_buf =
>>>>>>> pwc_get_next_fill_buf(pdev);
>>>>>>> if (pdev->fill_buf) {
>>>>>>> pdev->fill_buf->filled = 0;
>>>>>>> pdev->vsync = 1;
>>>>>>> }
>>>>>>> }
>>>>>>>
>>>>>>> 2016-08-01 21:16 GMT+03:00 Matwey V. Kornilov :
>>>>>>>> pwc module output with trace=511 is the following:
>>>>>>>>
>>>>>>>> [ 24.793109] usbcore: registered new interface driver Philips webcam
>>>>>>>> [ 29.276979] pwc: Unsupported pixel format
>>>>>>>> [ 29.277055] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
>>>>>>>> bytesperline=640, sizeimage=460800, pixelformat=YU12
>>>>>>>> [ 29.277090] pwc: Trying to set format to: width=640 height=480
>>>>>>>> fps=15 format=YU12
>>>>>>>> [ 29.277123] pwc: set_video_mode(640x480 @ 30, pixfmt 32315559).
>>>>>>>> [ 29.277145] pwc: decode_size = 5.
>>>>>>>> [ 29.277180] pwc: frame_size=63120, vframes=15, vsize=5,
>>>>>>>> vbandlength=526
>>>>>>>> [ 29.277204] pwc: Set resolution to 640x480
>>>>>>>> [ 29.277225] pwc: pwc_set_video_mode(), return=0
>>>>>>>> [ 29.277256] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
>>>>>>>> bytesperline=640, sizeimage=460800, pixelformat=YU12
>>>>>>>> [ 29.277306] pwc: ioctl(VIDIOC_G_FMT) return size 640x480
>>>>>>>>
Re: pwc over musb: 100% frame drop (lost) on high resolution stream
I've just measured that
it takes 150 us in average for pwc_isoc_handler to run
350 us - __usb_hcd_giveback_urb
So, it takes either 50 us (with HCD_BH) or 400 us (without) for
usb_hcd_giveback_urb to run.
2016-08-20 21:09 GMT+03:00 Matwey V. Kornilov :
> I've just checked 4.8-rc2 - same behaviour.
>
> 2016-08-18 16:31 GMT+03:00 Matwey V. Kornilov :
>> Any ideas?
>>
>> 2016-08-04 23:08 GMT+03:00 Matwey V. Kornilov :
>>> When DMA is not used, I see the same behavior: lots of zero-length
>>> packages received.
>>>
>>> Can It be related to some kind of USB overflow due to long input data
>>> processing with disabled IRQ?
>>> When HCD_BC is used then part of processing is postponed and this can
>>> explain greater throughput due to better latency.
>>>
>>> 2016-08-04 22:58 GMT+03:00 Matwey V. Kornilov :
>>>> I've just found that in such cases, when DMA actual length is zero,
>>>> both cppi41_channel->prog_len and txstate.residue equal 960 at
>>>> musb_cppi41 line 225:
>>>>
>>>> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/usb/musb/musb_cppi41.c#n225
>>>>
>>>> 2016-08-04 22:08 GMT+03:00 Matwey V. Kornilov :
>>>>> I've just found that dma->actual_len equals to zero in most cases at
>>>>> musb_host.c line 1946.
>>>>> And this produces zero-length packages.
>>>>>
>>>>> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/usb/musb/musb_host.c#n1946
>>>>>
>>>>> Any ideas why?
>>>>>
>>>>> 2016-08-04 19:57 GMT+03:00 Matwey V. Kornilov :
>>>>>> I've just found that many packages in URBs have zero actual_length (It
>>>>>> is a question why).
>>>>>> Then the following end of frame criteria leads to `frame underflow'
>>>>>> message:
>>>>>>
>>>>>> if (flen < pdev->vlast_packet_size) {
>>>>>> /* Shorter packet... end of frame */
>>>>>> if (pdev->vsync == 2)
>>>>>> pwc_frame_complete(pdev);
>>>>>> if (pdev->fill_buf == NULL)
>>>>>> pdev->fill_buf =
>>>>>> pwc_get_next_fill_buf(pdev);
>>>>>> if (pdev->fill_buf) {
>>>>>> pdev->fill_buf->filled = 0;
>>>>>> pdev->vsync = 1;
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> 2016-08-01 21:16 GMT+03:00 Matwey V. Kornilov :
>>>>>>> pwc module output with trace=511 is the following:
>>>>>>>
>>>>>>> [ 24.793109] usbcore: registered new interface driver Philips webcam
>>>>>>> [ 29.276979] pwc: Unsupported pixel format
>>>>>>> [ 29.277055] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
>>>>>>> bytesperline=640, sizeimage=460800, pixelformat=YU12
>>>>>>> [ 29.277090] pwc: Trying to set format to: width=640 height=480
>>>>>>> fps=15 format=YU12
>>>>>>> [ 29.277123] pwc: set_video_mode(640x480 @ 30, pixfmt 32315559).
>>>>>>> [ 29.277145] pwc: decode_size = 5.
>>>>>>> [ 29.277180] pwc: frame_size=63120, vframes=15, vsize=5,
>>>>>>> vbandlength=526
>>>>>>> [ 29.277204] pwc: Set resolution to 640x480
>>>>>>> [ 29.277225] pwc: pwc_set_video_mode(), return=0
>>>>>>> [ 29.277256] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
>>>>>>> bytesperline=640, sizeimage=460800, pixelformat=YU12
>>>>>>> [ 29.277306] pwc: ioctl(VIDIOC_G_FMT) return size 640x480
>>>>>>> [ 29.277337] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
>>>>>>> bytesperline=640, sizeimage=460800, pixelformat=YU12
>>>>>>> [ 29.277449] pwc: set_video_mode(640x480 @ 10, pixfmt 32315559).
>>>>>>> [ 29.277475] pwc: decode_size = 5.
>>>>>>> [ 29.278726] pwc: frame_size=94560, vframes=10, vsize=5,
>>>>>>> vbandlength=788
>>>>>>> [ 29.278750] pwc: Set resolution t
Re: pwc over musb: 100% frame drop (lost) on high resolution stream
I've just checked 4.8-rc2 - same behaviour.
2016-08-18 16:31 GMT+03:00 Matwey V. Kornilov :
> Any ideas?
>
> 2016-08-04 23:08 GMT+03:00 Matwey V. Kornilov :
>> When DMA is not used, I see the same behavior: lots of zero-length
>> packages received.
>>
>> Can It be related to some kind of USB overflow due to long input data
>> processing with disabled IRQ?
>> When HCD_BC is used then part of processing is postponed and this can
>> explain greater throughput due to better latency.
>>
>> 2016-08-04 22:58 GMT+03:00 Matwey V. Kornilov :
>>> I've just found that in such cases, when DMA actual length is zero,
>>> both cppi41_channel->prog_len and txstate.residue equal 960 at
>>> musb_cppi41 line 225:
>>>
>>> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/usb/musb/musb_cppi41.c#n225
>>>
>>> 2016-08-04 22:08 GMT+03:00 Matwey V. Kornilov :
>>>> I've just found that dma->actual_len equals to zero in most cases at
>>>> musb_host.c line 1946.
>>>> And this produces zero-length packages.
>>>>
>>>> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/usb/musb/musb_host.c#n1946
>>>>
>>>> Any ideas why?
>>>>
>>>> 2016-08-04 19:57 GMT+03:00 Matwey V. Kornilov :
>>>>> I've just found that many packages in URBs have zero actual_length (It
>>>>> is a question why).
>>>>> Then the following end of frame criteria leads to `frame underflow'
>>>>> message:
>>>>>
>>>>> if (flen < pdev->vlast_packet_size) {
>>>>> /* Shorter packet... end of frame */
>>>>> if (pdev->vsync == 2)
>>>>> pwc_frame_complete(pdev);
>>>>> if (pdev->fill_buf == NULL)
>>>>> pdev->fill_buf =
>>>>> pwc_get_next_fill_buf(pdev);
>>>>> if (pdev->fill_buf) {
>>>>> pdev->fill_buf->filled = 0;
>>>>> pdev->vsync = 1;
>>>>> }
>>>>> }
>>>>>
>>>>> 2016-08-01 21:16 GMT+03:00 Matwey V. Kornilov :
>>>>>> pwc module output with trace=511 is the following:
>>>>>>
>>>>>> [ 24.793109] usbcore: registered new interface driver Philips webcam
>>>>>> [ 29.276979] pwc: Unsupported pixel format
>>>>>> [ 29.277055] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
>>>>>> bytesperline=640, sizeimage=460800, pixelformat=YU12
>>>>>> [ 29.277090] pwc: Trying to set format to: width=640 height=480
>>>>>> fps=15 format=YU12
>>>>>> [ 29.277123] pwc: set_video_mode(640x480 @ 30, pixfmt 32315559).
>>>>>> [ 29.277145] pwc: decode_size = 5.
>>>>>> [ 29.277180] pwc: frame_size=63120, vframes=15, vsize=5,
>>>>>> vbandlength=526
>>>>>> [ 29.277204] pwc: Set resolution to 640x480
>>>>>> [ 29.277225] pwc: pwc_set_video_mode(), return=0
>>>>>> [ 29.277256] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
>>>>>> bytesperline=640, sizeimage=460800, pixelformat=YU12
>>>>>> [ 29.277306] pwc: ioctl(VIDIOC_G_FMT) return size 640x480
>>>>>> [ 29.277337] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
>>>>>> bytesperline=640, sizeimage=460800, pixelformat=YU12
>>>>>> [ 29.277449] pwc: set_video_mode(640x480 @ 10, pixfmt 32315559).
>>>>>> [ 29.277475] pwc: decode_size = 5.
>>>>>> [ 29.278726] pwc: frame_size=94560, vframes=10, vsize=5,
>>>>>> vbandlength=788
>>>>>> [ 29.278750] pwc: Set resolution to 640x480
>>>>>> [ 29.300374] pwc: set_video_mode(640x480 @ 10, pixfmt 32315559).
>>>>>> [ 29.300420] pwc: decode_size = 5.
>>>>>> [ 29.441759] pwc: frame_size=94560, vframes=10, vsize=5,
>>>>>> vbandlength=788
>>>>>> [ 29.441792] pwc: Set resolution to 640x480
>>>>>> [ 29.441824] pwc: Setting alternate interface 9
>>>>>> [ 29.455061] pwc: Allocated URB at 0xc9b83600
>>>>>> [ 29.455850] pwc: Allocated
Re: pwc over musb: 100% frame drop (lost) on high resolution stream
Any ideas?
2016-08-04 23:08 GMT+03:00 Matwey V. Kornilov :
> When DMA is not used, I see the same behavior: lots of zero-length
> packages received.
>
> Can It be related to some kind of USB overflow due to long input data
> processing with disabled IRQ?
> When HCD_BC is used then part of processing is postponed and this can
> explain greater throughput due to better latency.
>
> 2016-08-04 22:58 GMT+03:00 Matwey V. Kornilov :
>> I've just found that in such cases, when DMA actual length is zero,
>> both cppi41_channel->prog_len and txstate.residue equal 960 at
>> musb_cppi41 line 225:
>>
>> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/usb/musb/musb_cppi41.c#n225
>>
>> 2016-08-04 22:08 GMT+03:00 Matwey V. Kornilov :
>>> I've just found that dma->actual_len equals to zero in most cases at
>>> musb_host.c line 1946.
>>> And this produces zero-length packages.
>>>
>>> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/usb/musb/musb_host.c#n1946
>>>
>>> Any ideas why?
>>>
>>> 2016-08-04 19:57 GMT+03:00 Matwey V. Kornilov :
>>>> I've just found that many packages in URBs have zero actual_length (It
>>>> is a question why).
>>>> Then the following end of frame criteria leads to `frame underflow'
>>>> message:
>>>>
>>>> if (flen < pdev->vlast_packet_size) {
>>>> /* Shorter packet... end of frame */
>>>> if (pdev->vsync == 2)
>>>> pwc_frame_complete(pdev);
>>>> if (pdev->fill_buf == NULL)
>>>> pdev->fill_buf =
>>>> pwc_get_next_fill_buf(pdev);
>>>> if (pdev->fill_buf) {
>>>> pdev->fill_buf->filled = 0;
>>>> pdev->vsync = 1;
>>>> }
>>>> }
>>>>
>>>> 2016-08-01 21:16 GMT+03:00 Matwey V. Kornilov :
>>>>> pwc module output with trace=511 is the following:
>>>>>
>>>>> [ 24.793109] usbcore: registered new interface driver Philips webcam
>>>>> [ 29.276979] pwc: Unsupported pixel format
>>>>> [ 29.277055] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
>>>>> bytesperline=640, sizeimage=460800, pixelformat=YU12
>>>>> [ 29.277090] pwc: Trying to set format to: width=640 height=480
>>>>> fps=15 format=YU12
>>>>> [ 29.277123] pwc: set_video_mode(640x480 @ 30, pixfmt 32315559).
>>>>> [ 29.277145] pwc: decode_size = 5.
>>>>> [ 29.277180] pwc: frame_size=63120, vframes=15, vsize=5, vbandlength=526
>>>>> [ 29.277204] pwc: Set resolution to 640x480
>>>>> [ 29.277225] pwc: pwc_set_video_mode(), return=0
>>>>> [ 29.277256] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
>>>>> bytesperline=640, sizeimage=460800, pixelformat=YU12
>>>>> [ 29.277306] pwc: ioctl(VIDIOC_G_FMT) return size 640x480
>>>>> [ 29.277337] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
>>>>> bytesperline=640, sizeimage=460800, pixelformat=YU12
>>>>> [ 29.277449] pwc: set_video_mode(640x480 @ 10, pixfmt 32315559).
>>>>> [ 29.277475] pwc: decode_size = 5.
>>>>> [ 29.278726] pwc: frame_size=94560, vframes=10, vsize=5, vbandlength=788
>>>>> [ 29.278750] pwc: Set resolution to 640x480
>>>>> [ 29.300374] pwc: set_video_mode(640x480 @ 10, pixfmt 32315559).
>>>>> [ 29.300420] pwc: decode_size = 5.
>>>>> [ 29.441759] pwc: frame_size=94560, vframes=10, vsize=5, vbandlength=788
>>>>> [ 29.441792] pwc: Set resolution to 640x480
>>>>> [ 29.441824] pwc: Setting alternate interface 9
>>>>> [ 29.455061] pwc: Allocated URB at 0xc9b83600
>>>>> [ 29.455850] pwc: Allocated URB at 0xc9b83400
>>>>> [ 29.456040] pwc: Allocated URB at 0xc9b83200
>>>>> [ 29.456271] pwc: URB 0xc9b83600 submitted.
>>>>> [ 29.456310] pwc: URB 0xc9b83400 submitted.
>>>>> [ 29.456341] pwc: URB 0xc9b83200 submitted.
>>>>> [ 29.456362] pwc: << pwc_isoc_init()
>>>>> [ 30.078550] pwc: Frame buffer underflow (20076 bytes); discarded.
>>>>> [ 30.170543] p
Re: pwc over musb: 100% frame drop (lost) on high resolution stream
When DMA is not used, I see the same behavior: lots of zero-length
packages received.
Can It be related to some kind of USB overflow due to long input data
processing with disabled IRQ?
When HCD_BC is used then part of processing is postponed and this can
explain greater throughput due to better latency.
2016-08-04 22:58 GMT+03:00 Matwey V. Kornilov :
> I've just found that in such cases, when DMA actual length is zero,
> both cppi41_channel->prog_len and txstate.residue equal 960 at
> musb_cppi41 line 225:
>
> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/usb/musb/musb_cppi41.c#n225
>
> 2016-08-04 22:08 GMT+03:00 Matwey V. Kornilov :
>> I've just found that dma->actual_len equals to zero in most cases at
>> musb_host.c line 1946.
>> And this produces zero-length packages.
>>
>> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/usb/musb/musb_host.c#n1946
>>
>> Any ideas why?
>>
>> 2016-08-04 19:57 GMT+03:00 Matwey V. Kornilov :
>>> I've just found that many packages in URBs have zero actual_length (It
>>> is a question why).
>>> Then the following end of frame criteria leads to `frame underflow' message:
>>>
>>> if (flen < pdev->vlast_packet_size) {
>>> /* Shorter packet... end of frame */
>>> if (pdev->vsync == 2)
>>> pwc_frame_complete(pdev);
>>> if (pdev->fill_buf == NULL)
>>> pdev->fill_buf =
>>> pwc_get_next_fill_buf(pdev);
>>> if (pdev->fill_buf) {
>>> pdev->fill_buf->filled = 0;
>>> pdev->vsync = 1;
>>> }
>>> }
>>>
>>> 2016-08-01 21:16 GMT+03:00 Matwey V. Kornilov :
>>>> pwc module output with trace=511 is the following:
>>>>
>>>> [ 24.793109] usbcore: registered new interface driver Philips webcam
>>>> [ 29.276979] pwc: Unsupported pixel format
>>>> [ 29.277055] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
>>>> bytesperline=640, sizeimage=460800, pixelformat=YU12
>>>> [ 29.277090] pwc: Trying to set format to: width=640 height=480
>>>> fps=15 format=YU12
>>>> [ 29.277123] pwc: set_video_mode(640x480 @ 30, pixfmt 32315559).
>>>> [ 29.277145] pwc: decode_size = 5.
>>>> [ 29.277180] pwc: frame_size=63120, vframes=15, vsize=5, vbandlength=526
>>>> [ 29.277204] pwc: Set resolution to 640x480
>>>> [ 29.277225] pwc: pwc_set_video_mode(), return=0
>>>> [ 29.277256] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
>>>> bytesperline=640, sizeimage=460800, pixelformat=YU12
>>>> [ 29.277306] pwc: ioctl(VIDIOC_G_FMT) return size 640x480
>>>> [ 29.277337] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
>>>> bytesperline=640, sizeimage=460800, pixelformat=YU12
>>>> [ 29.277449] pwc: set_video_mode(640x480 @ 10, pixfmt 32315559).
>>>> [ 29.277475] pwc: decode_size = 5.
>>>> [ 29.278726] pwc: frame_size=94560, vframes=10, vsize=5, vbandlength=788
>>>> [ 29.278750] pwc: Set resolution to 640x480
>>>> [ 29.300374] pwc: set_video_mode(640x480 @ 10, pixfmt 32315559).
>>>> [ 29.300420] pwc: decode_size = 5.
>>>> [ 29.441759] pwc: frame_size=94560, vframes=10, vsize=5, vbandlength=788
>>>> [ 29.441792] pwc: Set resolution to 640x480
>>>> [ 29.441824] pwc: Setting alternate interface 9
>>>> [ 29.455061] pwc: Allocated URB at 0xc9b83600
>>>> [ 29.455850] pwc: Allocated URB at 0xc9b83400
>>>> [ 29.456040] pwc: Allocated URB at 0xc9b83200
>>>> [ 29.456271] pwc: URB 0xc9b83600 submitted.
>>>> [ 29.456310] pwc: URB 0xc9b83400 submitted.
>>>> [ 29.456341] pwc: URB 0xc9b83200 submitted.
>>>> [ 29.456362] pwc: << pwc_isoc_init()
>>>> [ 30.078550] pwc: Frame buffer underflow (20076 bytes); discarded.
>>>> [ 30.170543] pwc: Frame buffer underflow (12428 bytes); discarded.
>>>> [ 30.272538] pwc: Frame buffer underflow (14340 bytes); discarded.
>>>> [ 30.374541] pwc: Frame buffer underflow (16252 bytes); discarded.
>>>> [ 30.476535] pwc: Frame buffer underflow (18164 bytes); discarded.
>>>> [ 30.578532] pwc: Frame buffer underflow (20076 bytes); discarded.
&
Re: pwc over musb: 100% frame drop (lost) on high resolution stream
I've just found that in such cases, when DMA actual length is zero,
both cppi41_channel->prog_len and txstate.residue equal 960 at
musb_cppi41 line 225:
http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/usb/musb/musb_cppi41.c#n225
2016-08-04 22:08 GMT+03:00 Matwey V. Kornilov :
> I've just found that dma->actual_len equals to zero in most cases at
> musb_host.c line 1946.
> And this produces zero-length packages.
>
> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/usb/musb/musb_host.c#n1946
>
> Any ideas why?
>
> 2016-08-04 19:57 GMT+03:00 Matwey V. Kornilov :
>> I've just found that many packages in URBs have zero actual_length (It
>> is a question why).
>> Then the following end of frame criteria leads to `frame underflow' message:
>>
>> if (flen < pdev->vlast_packet_size) {
>> /* Shorter packet... end of frame */
>> if (pdev->vsync == 2)
>> pwc_frame_complete(pdev);
>> if (pdev->fill_buf == NULL)
>> pdev->fill_buf = pwc_get_next_fill_buf(pdev);
>> if (pdev->fill_buf) {
>> pdev->fill_buf->filled = 0;
>> pdev->vsync = 1;
>> }
>> }
>>
>> 2016-08-01 21:16 GMT+03:00 Matwey V. Kornilov :
>>> pwc module output with trace=511 is the following:
>>>
>>> [ 24.793109] usbcore: registered new interface driver Philips webcam
>>> [ 29.276979] pwc: Unsupported pixel format
>>> [ 29.277055] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
>>> bytesperline=640, sizeimage=460800, pixelformat=YU12
>>> [ 29.277090] pwc: Trying to set format to: width=640 height=480
>>> fps=15 format=YU12
>>> [ 29.277123] pwc: set_video_mode(640x480 @ 30, pixfmt 32315559).
>>> [ 29.277145] pwc: decode_size = 5.
>>> [ 29.277180] pwc: frame_size=63120, vframes=15, vsize=5, vbandlength=526
>>> [ 29.277204] pwc: Set resolution to 640x480
>>> [ 29.277225] pwc: pwc_set_video_mode(), return=0
>>> [ 29.277256] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
>>> bytesperline=640, sizeimage=460800, pixelformat=YU12
>>> [ 29.277306] pwc: ioctl(VIDIOC_G_FMT) return size 640x480
>>> [ 29.277337] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
>>> bytesperline=640, sizeimage=460800, pixelformat=YU12
>>> [ 29.277449] pwc: set_video_mode(640x480 @ 10, pixfmt 32315559).
>>> [ 29.277475] pwc: decode_size = 5.
>>> [ 29.278726] pwc: frame_size=94560, vframes=10, vsize=5, vbandlength=788
>>> [ 29.278750] pwc: Set resolution to 640x480
>>> [ 29.300374] pwc: set_video_mode(640x480 @ 10, pixfmt 32315559).
>>> [ 29.300420] pwc: decode_size = 5.
>>> [ 29.441759] pwc: frame_size=94560, vframes=10, vsize=5, vbandlength=788
>>> [ 29.441792] pwc: Set resolution to 640x480
>>> [ 29.441824] pwc: Setting alternate interface 9
>>> [ 29.455061] pwc: Allocated URB at 0xc9b83600
>>> [ 29.455850] pwc: Allocated URB at 0xc9b83400
>>> [ 29.456040] pwc: Allocated URB at 0xc9b83200
>>> [ 29.456271] pwc: URB 0xc9b83600 submitted.
>>> [ 29.456310] pwc: URB 0xc9b83400 submitted.
>>> [ 29.456341] pwc: URB 0xc9b83200 submitted.
>>> [ 29.456362] pwc: << pwc_isoc_init()
>>> [ 30.078550] pwc: Frame buffer underflow (20076 bytes); discarded.
>>> [ 30.170543] pwc: Frame buffer underflow (12428 bytes); discarded.
>>> [ 30.272538] pwc: Frame buffer underflow (14340 bytes); discarded.
>>> [ 30.374541] pwc: Frame buffer underflow (16252 bytes); discarded.
>>> [ 30.476535] pwc: Frame buffer underflow (18164 bytes); discarded.
>>> [ 30.578532] pwc: Frame buffer underflow (20076 bytes); discarded.
>>> [ 30.670538] pwc: Frame buffer underflow (12428 bytes); discarded.
>>> [ 30.772544] pwc: Frame buffer underflow (14340 bytes); discarded.
>>> [ 30.874547] pwc: Frame buffer underflow (16252 bytes); discarded.
>>> [ 30.976552] pwc: Frame buffer underflow (18164 bytes); discarded.
>>> [ 31.078536] pwc: Frame buffer underflow (20076 bytes); discarded.
>>> [ 31.170533] pwc: Frame buffer underflow (12428 bytes); discarded.
>>> [ 31.272549] pwc: Frame buffer underflow (14340 bytes); discarded.
>>> [ 31.374545] pwc: Frame buffer underflow (16252 bytes); discarded.
>>> [
Re: pwc over musb: 100% frame drop (lost) on high resolution stream
I've just found that dma->actual_len equals to zero in most cases at
musb_host.c line 1946.
And this produces zero-length packages.
http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/usb/musb/musb_host.c#n1946
Any ideas why?
2016-08-04 19:57 GMT+03:00 Matwey V. Kornilov :
> I've just found that many packages in URBs have zero actual_length (It
> is a question why).
> Then the following end of frame criteria leads to `frame underflow' message:
>
> if (flen < pdev->vlast_packet_size) {
> /* Shorter packet... end of frame */
> if (pdev->vsync == 2)
> pwc_frame_complete(pdev);
> if (pdev->fill_buf == NULL)
> pdev->fill_buf = pwc_get_next_fill_buf(pdev);
> if (pdev->fill_buf) {
> pdev->fill_buf->filled = 0;
> pdev->vsync = 1;
> }
> }
>
> 2016-08-01 21:16 GMT+03:00 Matwey V. Kornilov :
>> pwc module output with trace=511 is the following:
>>
>> [ 24.793109] usbcore: registered new interface driver Philips webcam
>> [ 29.276979] pwc: Unsupported pixel format
>> [ 29.277055] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
>> bytesperline=640, sizeimage=460800, pixelformat=YU12
>> [ 29.277090] pwc: Trying to set format to: width=640 height=480
>> fps=15 format=YU12
>> [ 29.277123] pwc: set_video_mode(640x480 @ 30, pixfmt 32315559).
>> [ 29.277145] pwc: decode_size = 5.
>> [ 29.277180] pwc: frame_size=63120, vframes=15, vsize=5, vbandlength=526
>> [ 29.277204] pwc: Set resolution to 640x480
>> [ 29.277225] pwc: pwc_set_video_mode(), return=0
>> [ 29.277256] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
>> bytesperline=640, sizeimage=460800, pixelformat=YU12
>> [ 29.277306] pwc: ioctl(VIDIOC_G_FMT) return size 640x480
>> [ 29.277337] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
>> bytesperline=640, sizeimage=460800, pixelformat=YU12
>> [ 29.277449] pwc: set_video_mode(640x480 @ 10, pixfmt 32315559).
>> [ 29.277475] pwc: decode_size = 5.
>> [ 29.278726] pwc: frame_size=94560, vframes=10, vsize=5, vbandlength=788
>> [ 29.278750] pwc: Set resolution to 640x480
>> [ 29.300374] pwc: set_video_mode(640x480 @ 10, pixfmt 32315559).
>> [ 29.300420] pwc: decode_size = 5.
>> [ 29.441759] pwc: frame_size=94560, vframes=10, vsize=5, vbandlength=788
>> [ 29.441792] pwc: Set resolution to 640x480
>> [ 29.441824] pwc: Setting alternate interface 9
>> [ 29.455061] pwc: Allocated URB at 0xc9b83600
>> [ 29.455850] pwc: Allocated URB at 0xc9b83400
>> [ 29.456040] pwc: Allocated URB at 0xc9b83200
>> [ 29.456271] pwc: URB 0xc9b83600 submitted.
>> [ 29.456310] pwc: URB 0xc9b83400 submitted.
>> [ 29.456341] pwc: URB 0xc9b83200 submitted.
>> [ 29.456362] pwc: << pwc_isoc_init()
>> [ 30.078550] pwc: Frame buffer underflow (20076 bytes); discarded.
>> [ 30.170543] pwc: Frame buffer underflow (12428 bytes); discarded.
>> [ 30.272538] pwc: Frame buffer underflow (14340 bytes); discarded.
>> [ 30.374541] pwc: Frame buffer underflow (16252 bytes); discarded.
>> [ 30.476535] pwc: Frame buffer underflow (18164 bytes); discarded.
>> [ 30.578532] pwc: Frame buffer underflow (20076 bytes); discarded.
>> [ 30.670538] pwc: Frame buffer underflow (12428 bytes); discarded.
>> [ 30.772544] pwc: Frame buffer underflow (14340 bytes); discarded.
>> [ 30.874547] pwc: Frame buffer underflow (16252 bytes); discarded.
>> [ 30.976552] pwc: Frame buffer underflow (18164 bytes); discarded.
>> [ 31.078536] pwc: Frame buffer underflow (20076 bytes); discarded.
>> [ 31.170533] pwc: Frame buffer underflow (12428 bytes); discarded.
>> [ 31.272549] pwc: Frame buffer underflow (14340 bytes); discarded.
>> [ 31.374545] pwc: Frame buffer underflow (16252 bytes); discarded.
>> [ 31.476537] pwc: Frame buffer underflow (18164 bytes); discarded.
>> [ 31.578536] pwc: Frame buffer underflow (20076 bytes); discarded.
>> [ 31.660895] pwc: Frame buffer underflow (11472 bytes); discarded.
>> [ 31.772554] pwc: Frame buffer underflow (14340 bytes); discarded.
>> [ 31.874548] pwc: Frame buffer underflow (16252 bytes); discarded.
>> [ 31.976533] pwc: Frame buffer underflow (18164 bytes); discarded.
>>
>>
>> 2016-07-31 23:31 GMT+03:00 Matwey V. Kornilov :
>>> Hello,
>>>
>>> I've also just found that the same c
Re: pwc over musb: 100% frame drop (lost) on high resolution stream
I've just found that many packages in URBs have zero actual_length (It
is a question why).
Then the following end of frame criteria leads to `frame underflow' message:
if (flen < pdev->vlast_packet_size) {
/* Shorter packet... end of frame */
if (pdev->vsync == 2)
pwc_frame_complete(pdev);
if (pdev->fill_buf == NULL)
pdev->fill_buf = pwc_get_next_fill_buf(pdev);
if (pdev->fill_buf) {
pdev->fill_buf->filled = 0;
pdev->vsync = 1;
}
}
2016-08-01 21:16 GMT+03:00 Matwey V. Kornilov :
> pwc module output with trace=511 is the following:
>
> [ 24.793109] usbcore: registered new interface driver Philips webcam
> [ 29.276979] pwc: Unsupported pixel format
> [ 29.277055] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
> bytesperline=640, sizeimage=460800, pixelformat=YU12
> [ 29.277090] pwc: Trying to set format to: width=640 height=480
> fps=15 format=YU12
> [ 29.277123] pwc: set_video_mode(640x480 @ 30, pixfmt 32315559).
> [ 29.277145] pwc: decode_size = 5.
> [ 29.277180] pwc: frame_size=63120, vframes=15, vsize=5, vbandlength=526
> [ 29.277204] pwc: Set resolution to 640x480
> [ 29.277225] pwc: pwc_set_video_mode(), return=0
> [ 29.277256] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
> bytesperline=640, sizeimage=460800, pixelformat=YU12
> [ 29.277306] pwc: ioctl(VIDIOC_G_FMT) return size 640x480
> [ 29.277337] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
> bytesperline=640, sizeimage=460800, pixelformat=YU12
> [ 29.277449] pwc: set_video_mode(640x480 @ 10, pixfmt 32315559).
> [ 29.277475] pwc: decode_size = 5.
> [ 29.278726] pwc: frame_size=94560, vframes=10, vsize=5, vbandlength=788
> [ 29.278750] pwc: Set resolution to 640x480
> [ 29.300374] pwc: set_video_mode(640x480 @ 10, pixfmt 32315559).
> [ 29.300420] pwc: decode_size = 5.
> [ 29.441759] pwc: frame_size=94560, vframes=10, vsize=5, vbandlength=788
> [ 29.441792] pwc: Set resolution to 640x480
> [ 29.441824] pwc: Setting alternate interface 9
> [ 29.455061] pwc: Allocated URB at 0xc9b83600
> [ 29.455850] pwc: Allocated URB at 0xc9b83400
> [ 29.456040] pwc: Allocated URB at 0xc9b83200
> [ 29.456271] pwc: URB 0xc9b83600 submitted.
> [ 29.456310] pwc: URB 0xc9b83400 submitted.
> [ 29.456341] pwc: URB 0xc9b83200 submitted.
> [ 29.456362] pwc: << pwc_isoc_init()
> [ 30.078550] pwc: Frame buffer underflow (20076 bytes); discarded.
> [ 30.170543] pwc: Frame buffer underflow (12428 bytes); discarded.
> [ 30.272538] pwc: Frame buffer underflow (14340 bytes); discarded.
> [ 30.374541] pwc: Frame buffer underflow (16252 bytes); discarded.
> [ 30.476535] pwc: Frame buffer underflow (18164 bytes); discarded.
> [ 30.578532] pwc: Frame buffer underflow (20076 bytes); discarded.
> [ 30.670538] pwc: Frame buffer underflow (12428 bytes); discarded.
> [ 30.772544] pwc: Frame buffer underflow (14340 bytes); discarded.
> [ 30.874547] pwc: Frame buffer underflow (16252 bytes); discarded.
> [ 30.976552] pwc: Frame buffer underflow (18164 bytes); discarded.
> [ 31.078536] pwc: Frame buffer underflow (20076 bytes); discarded.
> [ 31.170533] pwc: Frame buffer underflow (12428 bytes); discarded.
> [ 31.272549] pwc: Frame buffer underflow (14340 bytes); discarded.
> [ 31.374545] pwc: Frame buffer underflow (16252 bytes); discarded.
> [ 31.476537] pwc: Frame buffer underflow (18164 bytes); discarded.
> [ 31.578536] pwc: Frame buffer underflow (20076 bytes); discarded.
> [ 31.660895] pwc: Frame buffer underflow (11472 bytes); discarded.
> [ 31.772554] pwc: Frame buffer underflow (14340 bytes); discarded.
> [ 31.874548] pwc: Frame buffer underflow (16252 bytes); discarded.
> [ 31.976533] pwc: Frame buffer underflow (18164 bytes); discarded.
>
>
> 2016-07-31 23:31 GMT+03:00 Matwey V. Kornilov :
>> Hello,
>>
>> I've also just found that the same commit breaks cpufreq on BeagleBone Black
>> :)
>>
>> So, probably without HCD_BH flag musb works correctly only at 1Ghz CPU
>> frequency, which is unlisted and being set to 720Mhz by cpufreq driver
>> (as it did whet there was cpufreq driver).
>>
>> 2016-07-29 21:01 GMT+03:00 Matwey V. Kornilov :
>>> Hello,
>>>
>>> I've found that the following commit fixes the issue:
>>>
>>> commit 7694ca6e1d6f01122f05039b81f70f64b1ec4063
>>> Author: Viresh Kumar
>>> Date: Fri Apr 22 16:58:42 2016 +0530
>>>
>>
Re: pwc over musb: 100% frame drop (lost) on high resolution stream
2016-08-01 20:06 GMT+03:00 Viresh Kumar : > On 01-08-16, 20:01, Matwey V. Kornilov wrote: >> With this patch, there is no cpufreq directory here. >> >> Without this patch, the output is the following: >> >> nohostname:~ # uname -a >> Linux nohostname 4.6.4-3.gecd9058-default #1 SMP PREEMPT Fri Jul 15 >> 08:08:50 UTC 2016 (ecd9058) armv7l armv7l armv7l GNU/Linux >> nohostname:~ # cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver >> cpufreq-dt > > I hope that the below patch fixes it for you? > Yes, it is. Thank you. > [PATCH] cpufreq: am33xx: Use generic platdev driver > > -- > viresh > -- With best regards, Matwey V. Kornilov. Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia 119991, Moscow, Universitetsky pr-k 13, +7 (495) 9392382 -- 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: pwc over musb: 100% frame drop (lost) on high resolution stream
pwc module output with trace=511 is the following: [ 24.793109] usbcore: registered new interface driver Philips webcam [ 29.276979] pwc: Unsupported pixel format [ 29.277055] pwc: pwc_vidioc_fill_fmt() width=640, height=480, bytesperline=640, sizeimage=460800, pixelformat=YU12 [ 29.277090] pwc: Trying to set format to: width=640 height=480 fps=15 format=YU12 [ 29.277123] pwc: set_video_mode(640x480 @ 30, pixfmt 32315559). [ 29.277145] pwc: decode_size = 5. [ 29.277180] pwc: frame_size=63120, vframes=15, vsize=5, vbandlength=526 [ 29.277204] pwc: Set resolution to 640x480 [ 29.277225] pwc: pwc_set_video_mode(), return=0 [ 29.277256] pwc: pwc_vidioc_fill_fmt() width=640, height=480, bytesperline=640, sizeimage=460800, pixelformat=YU12 [ 29.277306] pwc: ioctl(VIDIOC_G_FMT) return size 640x480 [ 29.277337] pwc: pwc_vidioc_fill_fmt() width=640, height=480, bytesperline=640, sizeimage=460800, pixelformat=YU12 [ 29.277449] pwc: set_video_mode(640x480 @ 10, pixfmt 32315559). [ 29.277475] pwc: decode_size = 5. [ 29.278726] pwc: frame_size=94560, vframes=10, vsize=5, vbandlength=788 [ 29.278750] pwc: Set resolution to 640x480 [ 29.300374] pwc: set_video_mode(640x480 @ 10, pixfmt 32315559). [ 29.300420] pwc: decode_size = 5. [ 29.441759] pwc: frame_size=94560, vframes=10, vsize=5, vbandlength=788 [ 29.441792] pwc: Set resolution to 640x480 [ 29.441824] pwc: Setting alternate interface 9 [ 29.455061] pwc: Allocated URB at 0xc9b83600 [ 29.455850] pwc: Allocated URB at 0xc9b83400 [ 29.456040] pwc: Allocated URB at 0xc9b83200 [ 29.456271] pwc: URB 0xc9b83600 submitted. [ 29.456310] pwc: URB 0xc9b83400 submitted. [ 29.456341] pwc: URB 0xc9b83200 submitted. [ 29.456362] pwc: << pwc_isoc_init() [ 30.078550] pwc: Frame buffer underflow (20076 bytes); discarded. [ 30.170543] pwc: Frame buffer underflow (12428 bytes); discarded. [ 30.272538] pwc: Frame buffer underflow (14340 bytes); discarded. [ 30.374541] pwc: Frame buffer underflow (16252 bytes); discarded. [ 30.476535] pwc: Frame buffer underflow (18164 bytes); discarded. [ 30.578532] pwc: Frame buffer underflow (20076 bytes); discarded. [ 30.670538] pwc: Frame buffer underflow (12428 bytes); discarded. [ 30.772544] pwc: Frame buffer underflow (14340 bytes); discarded. [ 30.874547] pwc: Frame buffer underflow (16252 bytes); discarded. [ 30.976552] pwc: Frame buffer underflow (18164 bytes); discarded. [ 31.078536] pwc: Frame buffer underflow (20076 bytes); discarded. [ 31.170533] pwc: Frame buffer underflow (12428 bytes); discarded. [ 31.272549] pwc: Frame buffer underflow (14340 bytes); discarded. [ 31.374545] pwc: Frame buffer underflow (16252 bytes); discarded. [ 31.476537] pwc: Frame buffer underflow (18164 bytes); discarded. [ 31.578536] pwc: Frame buffer underflow (20076 bytes); discarded. [ 31.660895] pwc: Frame buffer underflow (11472 bytes); discarded. [ 31.772554] pwc: Frame buffer underflow (14340 bytes); discarded. [ 31.874548] pwc: Frame buffer underflow (16252 bytes); discarded. [ 31.976533] pwc: Frame buffer underflow (18164 bytes); discarded. 2016-07-31 23:31 GMT+03:00 Matwey V. Kornilov : > Hello, > > I've also just found that the same commit breaks cpufreq on BeagleBone Black > :) > > So, probably without HCD_BH flag musb works correctly only at 1Ghz CPU > frequency, which is unlisted and being set to 720Mhz by cpufreq driver > (as it did whet there was cpufreq driver). > > 2016-07-29 21:01 GMT+03:00 Matwey V. Kornilov : >> Hello, >> >> I've found that the following commit fixes the issue: >> >> commit 7694ca6e1d6f01122f05039b81f70f64b1ec4063 >> Author: Viresh Kumar >> Date: Fri Apr 22 16:58:42 2016 +0530 >> >> cpufreq: omap: Use generic platdev driver >> >> The cpufreq-dt-platdev driver supports creation of cpufreq-dt platform >> device now, reuse that and remove similar code from platform code. >> >> >> 2016-07-28 19:16 GMT+03:00 Matwey V. Kornilov : >>> Hello, >>> >>> I've just bisected commit, which fixed the issue in v4.7 >>> >>> commit 9fa64d6424adabf0e3a546ae24d01a62a927b342 >>> Merge: f55532a febce40 >>> Author: Rafael J. Wysocki >>> Date: Sat Apr 2 01:07:17 2016 +0200 >>> >>> Merge back intel_pstate fixes for v4.6. >>> >>> * pm-cpufreq: >>> intel_pstate: Avoid extra invocation of intel_pstate_sample() >>> intel_pstate: Do not set utilization update hook too early >>> >>> Unfortunately, intel_pstate branch doesn't have >>> f551e13529833e052f75ec628a8af7b034af20f9 applied. >>> I'll try to bisect this branch with the patch manually applied. >>> >>> 2016-07-27 20:34 GMT+03:00 Matwey V. K
Re: pwc over musb: 100% frame drop (lost) on high resolution stream
2016-08-01 19:50 GMT+03:00 Viresh Kumar :
> On 31-07-16, 23:31, Matwey V. Kornilov wrote:
>> Hello,
>>
>> I've also just found that the same commit breaks cpufreq on BeagleBone Black
>> :)
>>
>> So, probably without HCD_BH flag musb works correctly only at 1Ghz CPU
>> frequency, which is unlisted and being set to 720Mhz by cpufreq driver
>> (as it did whet there was cpufreq driver).
>>
>> 2016-07-29 21:01 GMT+03:00 Matwey V. Kornilov :
>> > Hello,
>> >
>> > I've found that the following commit fixes the issue:
>> >
>> > commit 7694ca6e1d6f01122f05039b81f70f64b1ec4063
>> > Author: Viresh Kumar
>> > Date: Fri Apr 22 16:58:42 2016 +0530
>> >
>> > cpufreq: omap: Use generic platdev driver
>> >
>> > The cpufreq-dt-platdev driver supports creation of cpufreq-dt platform
>> > device now, reuse that and remove similar code from platform code.
>
> Sorry for this commit and the man hours wasted to get to this :(
>
> I am trying to figure out why things break though, as this patch shouldn't
> have
> had any functional impacts. So, some of the assumptions I had are surely
> incorrect..
Actually, nothing to sorry about.
I suppose, that with this patch my BeagleBone run at 1Ghz after boot,
because usually cpufreq limits it to 720Mhz saying
[ 14.255646] cpu cpu0: dev_pm_opp_set_rate: failed to find current
OPP for freq 10 (-34)
And actually musb is still broken after f551e13529833e052f75ec628a8af7
(" Revert "usb: musb: musb_host")
>
> The defconfig linked in the original thread [1] has this:
>
> CONFIG_CPUFREQ_DT=m
>
> So, the cpufreq-dt module needs to get inserted to make it work.
>
It has been inserted automatically by alias `platform:cpufreq-dt'
Issue here that 4.7 stopped to provide `platfrom:cpufreq-dt' on BeagleBone.
Have you received my patch fixing it yet?
> Can someone provide the output of:
>
> cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
>
> with and without this patch ?
With this patch, there is no cpufreq directory here.
Without this patch, the output is the following:
nohostname:~ # uname -a
Linux nohostname 4.6.4-3.gecd9058-default #1 SMP PREEMPT Fri Jul 15
08:08:50 UTC 2016 (ecd9058) armv7l armv7l armv7l GNU/Linux
nohostname:~ # cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
cpufreq-dt
>
> It looks like we wanted to select "omap-cpufreq" for beaglebone and selected
> "cpufreq-dt" by mistake.
No, I am not sure, cpufreq-dt worked well until v4.7 where it is disappeared.
>
> [Note]: I am not subscribed to USB lists and so please include me for any
> emails
> you want my response on.
>
> --
> viresh
>
> [1] http://www.spinics.net/lists/linux-usb/msg143956.html
>
> --
> viresh
>
--
With best regards,
Matwey V. Kornilov.
Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia
119991, Moscow, Universitetsky pr-k 13, +7 (495) 9392382
--
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: pwc over musb: 100% frame drop (lost) on high resolution stream
Hello, I've also just found that the same commit breaks cpufreq on BeagleBone Black :) So, probably without HCD_BH flag musb works correctly only at 1Ghz CPU frequency, which is unlisted and being set to 720Mhz by cpufreq driver (as it did whet there was cpufreq driver). 2016-07-29 21:01 GMT+03:00 Matwey V. Kornilov : > Hello, > > I've found that the following commit fixes the issue: > > commit 7694ca6e1d6f01122f05039b81f70f64b1ec4063 > Author: Viresh Kumar > Date: Fri Apr 22 16:58:42 2016 +0530 > > cpufreq: omap: Use generic platdev driver > > The cpufreq-dt-platdev driver supports creation of cpufreq-dt platform > device now, reuse that and remove similar code from platform code. > > > 2016-07-28 19:16 GMT+03:00 Matwey V. Kornilov : >> Hello, >> >> I've just bisected commit, which fixed the issue in v4.7 >> >> commit 9fa64d6424adabf0e3a546ae24d01a62a927b342 >> Merge: f55532a febce40 >> Author: Rafael J. Wysocki >> Date: Sat Apr 2 01:07:17 2016 +0200 >> >> Merge back intel_pstate fixes for v4.6. >> >> * pm-cpufreq: >> intel_pstate: Avoid extra invocation of intel_pstate_sample() >> intel_pstate: Do not set utilization update hook too early >> >> Unfortunately, intel_pstate branch doesn't have >> f551e13529833e052f75ec628a8af7b034af20f9 applied. >> I'll try to bisect this branch with the patch manually applied. >> >> 2016-07-27 20:34 GMT+03:00 Matwey V. Kornilov : >>> Hello, >>> >>> I've just biseced commit, which introduced this issue >>> >>> commit f551e13529833e052f75ec628a8af7b034af20f9 >>> Author: Bin Liu >>> Date: Mon Apr 25 15:53:30 2016 -0500 >>> >>> Revert "usb: musb: musb_host: Enable HCD_BH flag to handle urb >>> return in bottom half" >>> >>> I have not checked yet, if it was intentionnaly fixed. >>> >>> 2016-07-23 22:24 GMT+03:00 Matwey V. Kornilov : >>>> 2016-07-20 21:56 GMT+03:00 Matwey V. Kornilov : >>>>> 2016-07-20 18:06 GMT+03:00 Bin Liu : >>>>>> Hi, >>>>>> >>>>>> On Wed, Jul 20, 2016 at 05:44:56PM +0300, Matwey V. Kornilov wrote: >>>>>>> 2016-07-20 17:13 GMT+03:00 Bin Liu : >>>>>>> > Hi, >>>>>>> > >>>>>>> > On Wed, Jul 20, 2016 at 09:09:42AM +0300, Matwey V. Kornilov wrote: >>>>>>> >> 2016-07-20 0:34 GMT+03:00 Bin Liu : >>>>>>> >> > Hi, >>>>>>> >> > >>>>>>> >> > On Wed, Jul 20, 2016 at 12:25:44AM +0300, Matwey V. Kornilov wrote: >>>>>>> >> >> 2016-07-19 23:56 GMT+03:00 Bin Liu : >>>>>>> >> >> > Hi, >>>>>>> >> >> > >>>>>>> >> >> > On Tue, Jul 19, 2016 at 11:21:17PM +0300, mat...@sai.msu.ru >>>>>>> >> >> > wrote: >>>>>>> >> >> >> Hello, >>>>>>> >> >> >> >>>>>>> >> >> >> I have Philips SPC 900 camera (0471:0329) connected to my >>>>>>> >> >> >> AM335x based BeagleBoneBlack SBC. >>>>>>> >> >> >> I am sure that both of them are fine and work properly. >>>>>>> >> >> >> I am running Linux 4.6.4 (my kernel config is available at >>>>>>> >> >> >> https://clck.ru/A2kQs ) and I've just discovered, that there >>>>>>> >> >> >> is an issue with frame transfer when high resolution formats >>>>>>> >> >> >> are used. >>>>>>> >> >> >> >>>>>>> >> >> >> The issue is the following. I use simple v4l2 example tool >>>>>>> >> >> >> (taken from API docs), which source code is available at >>>>>>> >> >> >> http://pastebin.com/grcNXxfe >>>>>>> >> >> >> >>>>>>> >> >> >> When I use (see line 488) 640x480 frames >>>>>>> >> >> >> >>>>>>> >> >> >> fmt.fmt.pix.width = 640; >>>>>>> >> >> >> fmt.fmt.pix.height = 480; >>>
Re: pwc over musb: 100% frame drop (lost) on high resolution stream
Hello, I've found that the following commit fixes the issue: commit 7694ca6e1d6f01122f05039b81f70f64b1ec4063 Author: Viresh Kumar Date: Fri Apr 22 16:58:42 2016 +0530 cpufreq: omap: Use generic platdev driver The cpufreq-dt-platdev driver supports creation of cpufreq-dt platform device now, reuse that and remove similar code from platform code. 2016-07-28 19:16 GMT+03:00 Matwey V. Kornilov : > Hello, > > I've just bisected commit, which fixed the issue in v4.7 > > commit 9fa64d6424adabf0e3a546ae24d01a62a927b342 > Merge: f55532a febce40 > Author: Rafael J. Wysocki > Date: Sat Apr 2 01:07:17 2016 +0200 > > Merge back intel_pstate fixes for v4.6. > > * pm-cpufreq: > intel_pstate: Avoid extra invocation of intel_pstate_sample() > intel_pstate: Do not set utilization update hook too early > > Unfortunately, intel_pstate branch doesn't have > f551e13529833e052f75ec628a8af7b034af20f9 applied. > I'll try to bisect this branch with the patch manually applied. > > 2016-07-27 20:34 GMT+03:00 Matwey V. Kornilov : >> Hello, >> >> I've just biseced commit, which introduced this issue >> >> commit f551e13529833e052f75ec628a8af7b034af20f9 >> Author: Bin Liu >> Date: Mon Apr 25 15:53:30 2016 -0500 >> >> Revert "usb: musb: musb_host: Enable HCD_BH flag to handle urb >> return in bottom half" >> >> I have not checked yet, if it was intentionnaly fixed. >> >> 2016-07-23 22:24 GMT+03:00 Matwey V. Kornilov : >>> 2016-07-20 21:56 GMT+03:00 Matwey V. Kornilov : >>>> 2016-07-20 18:06 GMT+03:00 Bin Liu : >>>>> Hi, >>>>> >>>>> On Wed, Jul 20, 2016 at 05:44:56PM +0300, Matwey V. Kornilov wrote: >>>>>> 2016-07-20 17:13 GMT+03:00 Bin Liu : >>>>>> > Hi, >>>>>> > >>>>>> > On Wed, Jul 20, 2016 at 09:09:42AM +0300, Matwey V. Kornilov wrote: >>>>>> >> 2016-07-20 0:34 GMT+03:00 Bin Liu : >>>>>> >> > Hi, >>>>>> >> > >>>>>> >> > On Wed, Jul 20, 2016 at 12:25:44AM +0300, Matwey V. Kornilov wrote: >>>>>> >> >> 2016-07-19 23:56 GMT+03:00 Bin Liu : >>>>>> >> >> > Hi, >>>>>> >> >> > >>>>>> >> >> > On Tue, Jul 19, 2016 at 11:21:17PM +0300, mat...@sai.msu.ru >>>>>> >> >> > wrote: >>>>>> >> >> >> Hello, >>>>>> >> >> >> >>>>>> >> >> >> I have Philips SPC 900 camera (0471:0329) connected to my >>>>>> >> >> >> AM335x based BeagleBoneBlack SBC. >>>>>> >> >> >> I am sure that both of them are fine and work properly. >>>>>> >> >> >> I am running Linux 4.6.4 (my kernel config is available at >>>>>> >> >> >> https://clck.ru/A2kQs ) and I've just discovered, that there is >>>>>> >> >> >> an issue with frame transfer when high resolution formats are >>>>>> >> >> >> used. >>>>>> >> >> >> >>>>>> >> >> >> The issue is the following. I use simple v4l2 example tool >>>>>> >> >> >> (taken from API docs), which source code is available at >>>>>> >> >> >> http://pastebin.com/grcNXxfe >>>>>> >> >> >> >>>>>> >> >> >> When I use (see line 488) 640x480 frames >>>>>> >> >> >> >>>>>> >> >> >> fmt.fmt.pix.width = 640; >>>>>> >> >> >> fmt.fmt.pix.height = 480; >>>>>> >> >> >> >>>>>> >> >> >> then I get "select timeout" and don't get any frames. >>>>>> >> >> >> >>>>>> >> >> >> When I use 320x240 frames >>>>>> >> >> >> >>>>>> >> >> >> fmt.fmt.pix.width = 320; >>>>>> >> >> >> fmt.fmt.pix.height = 240; >>>>>> >> >> >> >>>>>> >> >> >> then about 60% frames are missed. An example ou
Re: pwc over musb: 100% frame drop (lost) on high resolution stream
Hello, I've just bisected commit, which fixed the issue in v4.7 commit 9fa64d6424adabf0e3a546ae24d01a62a927b342 Merge: f55532a febce40 Author: Rafael J. Wysocki Date: Sat Apr 2 01:07:17 2016 +0200 Merge back intel_pstate fixes for v4.6. * pm-cpufreq: intel_pstate: Avoid extra invocation of intel_pstate_sample() intel_pstate: Do not set utilization update hook too early Unfortunately, intel_pstate branch doesn't have f551e13529833e052f75ec628a8af7b034af20f9 applied. I'll try to bisect this branch with the patch manually applied. 2016-07-27 20:34 GMT+03:00 Matwey V. Kornilov : > Hello, > > I've just biseced commit, which introduced this issue > > commit f551e13529833e052f75ec628a8af7b034af20f9 > Author: Bin Liu > Date: Mon Apr 25 15:53:30 2016 -0500 > > Revert "usb: musb: musb_host: Enable HCD_BH flag to handle urb > return in bottom half" > > I have not checked yet, if it was intentionnaly fixed. > > 2016-07-23 22:24 GMT+03:00 Matwey V. Kornilov : >> 2016-07-20 21:56 GMT+03:00 Matwey V. Kornilov : >>> 2016-07-20 18:06 GMT+03:00 Bin Liu : >>>> Hi, >>>> >>>> On Wed, Jul 20, 2016 at 05:44:56PM +0300, Matwey V. Kornilov wrote: >>>>> 2016-07-20 17:13 GMT+03:00 Bin Liu : >>>>> > Hi, >>>>> > >>>>> > On Wed, Jul 20, 2016 at 09:09:42AM +0300, Matwey V. Kornilov wrote: >>>>> >> 2016-07-20 0:34 GMT+03:00 Bin Liu : >>>>> >> > Hi, >>>>> >> > >>>>> >> > On Wed, Jul 20, 2016 at 12:25:44AM +0300, Matwey V. Kornilov wrote: >>>>> >> >> 2016-07-19 23:56 GMT+03:00 Bin Liu : >>>>> >> >> > Hi, >>>>> >> >> > >>>>> >> >> > On Tue, Jul 19, 2016 at 11:21:17PM +0300, mat...@sai.msu.ru wrote: >>>>> >> >> >> Hello, >>>>> >> >> >> >>>>> >> >> >> I have Philips SPC 900 camera (0471:0329) connected to my AM335x >>>>> >> >> >> based BeagleBoneBlack SBC. >>>>> >> >> >> I am sure that both of them are fine and work properly. >>>>> >> >> >> I am running Linux 4.6.4 (my kernel config is available at >>>>> >> >> >> https://clck.ru/A2kQs ) and I've just discovered, that there is >>>>> >> >> >> an issue with frame transfer when high resolution formats are >>>>> >> >> >> used. >>>>> >> >> >> >>>>> >> >> >> The issue is the following. I use simple v4l2 example tool >>>>> >> >> >> (taken from API docs), which source code is available at >>>>> >> >> >> http://pastebin.com/grcNXxfe >>>>> >> >> >> >>>>> >> >> >> When I use (see line 488) 640x480 frames >>>>> >> >> >> >>>>> >> >> >> fmt.fmt.pix.width = 640; >>>>> >> >> >> fmt.fmt.pix.height = 480; >>>>> >> >> >> >>>>> >> >> >> then I get "select timeout" and don't get any frames. >>>>> >> >> >> >>>>> >> >> >> When I use 320x240 frames >>>>> >> >> >> >>>>> >> >> >> fmt.fmt.pix.width = 320; >>>>> >> >> >> fmt.fmt.pix.height = 240; >>>>> >> >> >> >>>>> >> >> >> then about 60% frames are missed. An example outpout of ./a.out >>>>> >> >> >> -f is available at https://yadi.sk/d/aRka8xWPtSc4y >>>>> >> >> >> It looks like there are pauses between bulks of frames (frame >>>>> >> >> >> counter and timestamp as returned from v4l2 API): >>>>> >> >> >> >>>>> >> >> >> 3 3705.142553 >>>>> >> >> >> 8 3705.342533 >>>>> >> >> >> 13 3705.542517 >>>>> >> >> >> 110 3708.776208 >>>>> >> >> >> 115 3708.976190 >>>>> >> >> >> 120 3709.176169 >>>>> >
Re: pwc over musb: 100% frame drop (lost) on high resolution stream
Hello, I've just biseced commit, which introduced this issue commit f551e13529833e052f75ec628a8af7b034af20f9 Author: Bin Liu Date: Mon Apr 25 15:53:30 2016 -0500 Revert "usb: musb: musb_host: Enable HCD_BH flag to handle urb return in bottom half" I have not checked yet, if it was intentionnaly fixed. 2016-07-23 22:24 GMT+03:00 Matwey V. Kornilov : > 2016-07-20 21:56 GMT+03:00 Matwey V. Kornilov : >> 2016-07-20 18:06 GMT+03:00 Bin Liu : >>> Hi, >>> >>> On Wed, Jul 20, 2016 at 05:44:56PM +0300, Matwey V. Kornilov wrote: >>>> 2016-07-20 17:13 GMT+03:00 Bin Liu : >>>> > Hi, >>>> > >>>> > On Wed, Jul 20, 2016 at 09:09:42AM +0300, Matwey V. Kornilov wrote: >>>> >> 2016-07-20 0:34 GMT+03:00 Bin Liu : >>>> >> > Hi, >>>> >> > >>>> >> > On Wed, Jul 20, 2016 at 12:25:44AM +0300, Matwey V. Kornilov wrote: >>>> >> >> 2016-07-19 23:56 GMT+03:00 Bin Liu : >>>> >> >> > Hi, >>>> >> >> > >>>> >> >> > On Tue, Jul 19, 2016 at 11:21:17PM +0300, mat...@sai.msu.ru wrote: >>>> >> >> >> Hello, >>>> >> >> >> >>>> >> >> >> I have Philips SPC 900 camera (0471:0329) connected to my AM335x >>>> >> >> >> based BeagleBoneBlack SBC. >>>> >> >> >> I am sure that both of them are fine and work properly. >>>> >> >> >> I am running Linux 4.6.4 (my kernel config is available at >>>> >> >> >> https://clck.ru/A2kQs ) and I've just discovered, that there is >>>> >> >> >> an issue with frame transfer when high resolution formats are >>>> >> >> >> used. >>>> >> >> >> >>>> >> >> >> The issue is the following. I use simple v4l2 example tool (taken >>>> >> >> >> from API docs), which source code is available at >>>> >> >> >> http://pastebin.com/grcNXxfe >>>> >> >> >> >>>> >> >> >> When I use (see line 488) 640x480 frames >>>> >> >> >> >>>> >> >> >> fmt.fmt.pix.width = 640; >>>> >> >> >> fmt.fmt.pix.height = 480; >>>> >> >> >> >>>> >> >> >> then I get "select timeout" and don't get any frames. >>>> >> >> >> >>>> >> >> >> When I use 320x240 frames >>>> >> >> >> >>>> >> >> >> fmt.fmt.pix.width = 320; >>>> >> >> >> fmt.fmt.pix.height = 240; >>>> >> >> >> >>>> >> >> >> then about 60% frames are missed. An example outpout of ./a.out >>>> >> >> >> -f is available at https://yadi.sk/d/aRka8xWPtSc4y >>>> >> >> >> It looks like there are pauses between bulks of frames (frame >>>> >> >> >> counter and timestamp as returned from v4l2 API): >>>> >> >> >> >>>> >> >> >> 3 3705.142553 >>>> >> >> >> 8 3705.342533 >>>> >> >> >> 13 3705.542517 >>>> >> >> >> 110 3708.776208 >>>> >> >> >> 115 3708.976190 >>>> >> >> >> 120 3709.176169 >>>> >> >> >> 125 3709.376152 >>>> >> >> >> 130 3709.576144 >>>> >> >> >> 226 3712.807848 >>>> >> >> >> >>>> >> >> >> When I use tiny 160x120 frames >>>> >> >> >> >>>> >> >> >> fmt.fmt.pix.width = 160; >>>> >> >> >> fmt.fmt.pix.height = 120; >>>> >> >> >> >>>> >> >> >> then more frames are received. See output example at >>>> >> >> >> https://yadi.sk/d/DedBmH6ftSc9t >>>> >> >> >> That is why I thought that everything was fine in May when used >>>> >> >> >> tiny xawtv window to check kernel OOPS presence (see &
Re: pwc over musb: 100% frame drop (lost) on high resolution stream
2016-07-20 21:56 GMT+03:00 Matwey V. Kornilov : > 2016-07-20 18:06 GMT+03:00 Bin Liu : >> Hi, >> >> On Wed, Jul 20, 2016 at 05:44:56PM +0300, Matwey V. Kornilov wrote: >>> 2016-07-20 17:13 GMT+03:00 Bin Liu : >>> > Hi, >>> > >>> > On Wed, Jul 20, 2016 at 09:09:42AM +0300, Matwey V. Kornilov wrote: >>> >> 2016-07-20 0:34 GMT+03:00 Bin Liu : >>> >> > Hi, >>> >> > >>> >> > On Wed, Jul 20, 2016 at 12:25:44AM +0300, Matwey V. Kornilov wrote: >>> >> >> 2016-07-19 23:56 GMT+03:00 Bin Liu : >>> >> >> > Hi, >>> >> >> > >>> >> >> > On Tue, Jul 19, 2016 at 11:21:17PM +0300, mat...@sai.msu.ru wrote: >>> >> >> >> Hello, >>> >> >> >> >>> >> >> >> I have Philips SPC 900 camera (0471:0329) connected to my AM335x >>> >> >> >> based BeagleBoneBlack SBC. >>> >> >> >> I am sure that both of them are fine and work properly. >>> >> >> >> I am running Linux 4.6.4 (my kernel config is available at >>> >> >> >> https://clck.ru/A2kQs ) and I've just discovered, that there is an >>> >> >> >> issue with frame transfer when high resolution formats are used. >>> >> >> >> >>> >> >> >> The issue is the following. I use simple v4l2 example tool (taken >>> >> >> >> from API docs), which source code is available at >>> >> >> >> http://pastebin.com/grcNXxfe >>> >> >> >> >>> >> >> >> When I use (see line 488) 640x480 frames >>> >> >> >> >>> >> >> >> fmt.fmt.pix.width = 640; >>> >> >> >> fmt.fmt.pix.height = 480; >>> >> >> >> >>> >> >> >> then I get "select timeout" and don't get any frames. >>> >> >> >> >>> >> >> >> When I use 320x240 frames >>> >> >> >> >>> >> >> >> fmt.fmt.pix.width = 320; >>> >> >> >> fmt.fmt.pix.height = 240; >>> >> >> >> >>> >> >> >> then about 60% frames are missed. An example outpout of ./a.out -f >>> >> >> >> is available at https://yadi.sk/d/aRka8xWPtSc4y >>> >> >> >> It looks like there are pauses between bulks of frames (frame >>> >> >> >> counter and timestamp as returned from v4l2 API): >>> >> >> >> >>> >> >> >> 3 3705.142553 >>> >> >> >> 8 3705.342533 >>> >> >> >> 13 3705.542517 >>> >> >> >> 110 3708.776208 >>> >> >> >> 115 3708.976190 >>> >> >> >> 120 3709.176169 >>> >> >> >> 125 3709.376152 >>> >> >> >> 130 3709.576144 >>> >> >> >> 226 3712.807848 >>> >> >> >> >>> >> >> >> When I use tiny 160x120 frames >>> >> >> >> >>> >> >> >> fmt.fmt.pix.width = 160; >>> >> >> >> fmt.fmt.pix.height = 120; >>> >> >> >> >>> >> >> >> then more frames are received. See output example at >>> >> >> >> https://yadi.sk/d/DedBmH6ftSc9t >>> >> >> >> That is why I thought that everything was fine in May when used >>> >> >> >> tiny xawtv window to check kernel OOPS presence (see >>> >> >> >> http://www.spinics.net/lists/linux-usb/msg141188.html for >>> >> >> >> reference) >>> >> >> >> >>> >> >> >> Even more. When I introduce USB hub between the host and the >>> >> >> >> webcam, I can not receive even any 320x240 frames. >>> >> >> >> >>> >> >> >> I've managed to use ftrace to see what is going on when no frames >>> >> >> >> are received. >>> >> >> >> I've found that pwc_isoc_handler is called frequently as
Re: pwc over musb: 100% frame drop (lost) on high resolution stream
2016-07-20 18:06 GMT+03:00 Bin Liu :
> Hi,
>
> On Wed, Jul 20, 2016 at 05:44:56PM +0300, Matwey V. Kornilov wrote:
>> 2016-07-20 17:13 GMT+03:00 Bin Liu :
>> > Hi,
>> >
>> > On Wed, Jul 20, 2016 at 09:09:42AM +0300, Matwey V. Kornilov wrote:
>> >> 2016-07-20 0:34 GMT+03:00 Bin Liu :
>> >> > Hi,
>> >> >
>> >> > On Wed, Jul 20, 2016 at 12:25:44AM +0300, Matwey V. Kornilov wrote:
>> >> >> 2016-07-19 23:56 GMT+03:00 Bin Liu :
>> >> >> > Hi,
>> >> >> >
>> >> >> > On Tue, Jul 19, 2016 at 11:21:17PM +0300, mat...@sai.msu.ru wrote:
>> >> >> >> Hello,
>> >> >> >>
>> >> >> >> I have Philips SPC 900 camera (0471:0329) connected to my AM335x
>> >> >> >> based BeagleBoneBlack SBC.
>> >> >> >> I am sure that both of them are fine and work properly.
>> >> >> >> I am running Linux 4.6.4 (my kernel config is available at
>> >> >> >> https://clck.ru/A2kQs ) and I've just discovered, that there is an
>> >> >> >> issue with frame transfer when high resolution formats are used.
>> >> >> >>
>> >> >> >> The issue is the following. I use simple v4l2 example tool (taken
>> >> >> >> from API docs), which source code is available at
>> >> >> >> http://pastebin.com/grcNXxfe
>> >> >> >>
>> >> >> >> When I use (see line 488) 640x480 frames
>> >> >> >>
>> >> >> >> fmt.fmt.pix.width = 640;
>> >> >> >> fmt.fmt.pix.height = 480;
>> >> >> >>
>> >> >> >> then I get "select timeout" and don't get any frames.
>> >> >> >>
>> >> >> >> When I use 320x240 frames
>> >> >> >>
>> >> >> >> fmt.fmt.pix.width = 320;
>> >> >> >> fmt.fmt.pix.height = 240;
>> >> >> >>
>> >> >> >> then about 60% frames are missed. An example outpout of ./a.out -f
>> >> >> >> is available at https://yadi.sk/d/aRka8xWPtSc4y
>> >> >> >> It looks like there are pauses between bulks of frames (frame
>> >> >> >> counter and timestamp as returned from v4l2 API):
>> >> >> >>
>> >> >> >> 3 3705.142553
>> >> >> >> 8 3705.342533
>> >> >> >> 13 3705.542517
>> >> >> >> 110 3708.776208
>> >> >> >> 115 3708.976190
>> >> >> >> 120 3709.176169
>> >> >> >> 125 3709.376152
>> >> >> >> 130 3709.576144
>> >> >> >> 226 3712.807848
>> >> >> >>
>> >> >> >> When I use tiny 160x120 frames
>> >> >> >>
>> >> >> >> fmt.fmt.pix.width = 160;
>> >> >> >> fmt.fmt.pix.height = 120;
>> >> >> >>
>> >> >> >> then more frames are received. See output example at
>> >> >> >> https://yadi.sk/d/DedBmH6ftSc9t
>> >> >> >> That is why I thought that everything was fine in May when used
>> >> >> >> tiny xawtv window to check kernel OOPS presence (see
>> >> >> >> http://www.spinics.net/lists/linux-usb/msg141188.html for reference)
>> >> >> >>
>> >> >> >> Even more. When I introduce USB hub between the host and the
>> >> >> >> webcam, I can not receive even any 320x240 frames.
>> >> >> >>
>> >> >> >> I've managed to use ftrace to see what is going on when no frames
>> >> >> >> are received.
>> >> >> >> I've found that pwc_isoc_handler is called frequently as the
>> >> >> >> following:
>> >> >> >>
>> >> >> >> 0) | pwc_isoc_handler [pwc]() {
>> >> >> >> 0) |usb_submit_urb [usbcore]() {
>> >> >> >> 0) | usb_submit_urb.part.3 [usbcore]() {
>> >> >>
Re: pwc over musb: 100% frame drop (lost) on high resolution stream
2016-07-20 17:13 GMT+03:00 Bin Liu :
> Hi,
>
> On Wed, Jul 20, 2016 at 09:09:42AM +0300, Matwey V. Kornilov wrote:
>> 2016-07-20 0:34 GMT+03:00 Bin Liu :
>> > Hi,
>> >
>> > On Wed, Jul 20, 2016 at 12:25:44AM +0300, Matwey V. Kornilov wrote:
>> >> 2016-07-19 23:56 GMT+03:00 Bin Liu :
>> >> > Hi,
>> >> >
>> >> > On Tue, Jul 19, 2016 at 11:21:17PM +0300, mat...@sai.msu.ru wrote:
>> >> >> Hello,
>> >> >>
>> >> >> I have Philips SPC 900 camera (0471:0329) connected to my AM335x based
>> >> >> BeagleBoneBlack SBC.
>> >> >> I am sure that both of them are fine and work properly.
>> >> >> I am running Linux 4.6.4 (my kernel config is available at
>> >> >> https://clck.ru/A2kQs ) and I've just discovered, that there is an
>> >> >> issue with frame transfer when high resolution formats are used.
>> >> >>
>> >> >> The issue is the following. I use simple v4l2 example tool (taken from
>> >> >> API docs), which source code is available at
>> >> >> http://pastebin.com/grcNXxfe
>> >> >>
>> >> >> When I use (see line 488) 640x480 frames
>> >> >>
>> >> >> fmt.fmt.pix.width = 640;
>> >> >> fmt.fmt.pix.height = 480;
>> >> >>
>> >> >> then I get "select timeout" and don't get any frames.
>> >> >>
>> >> >> When I use 320x240 frames
>> >> >>
>> >> >> fmt.fmt.pix.width = 320;
>> >> >> fmt.fmt.pix.height = 240;
>> >> >>
>> >> >> then about 60% frames are missed. An example outpout of ./a.out -f is
>> >> >> available at https://yadi.sk/d/aRka8xWPtSc4y
>> >> >> It looks like there are pauses between bulks of frames (frame counter
>> >> >> and timestamp as returned from v4l2 API):
>> >> >>
>> >> >> 3 3705.142553
>> >> >> 8 3705.342533
>> >> >> 13 3705.542517
>> >> >> 110 3708.776208
>> >> >> 115 3708.976190
>> >> >> 120 3709.176169
>> >> >> 125 3709.376152
>> >> >> 130 3709.576144
>> >> >> 226 3712.807848
>> >> >>
>> >> >> When I use tiny 160x120 frames
>> >> >>
>> >> >> fmt.fmt.pix.width = 160;
>> >> >> fmt.fmt.pix.height = 120;
>> >> >>
>> >> >> then more frames are received. See output example at
>> >> >> https://yadi.sk/d/DedBmH6ftSc9t
>> >> >> That is why I thought that everything was fine in May when used tiny
>> >> >> xawtv window to check kernel OOPS presence (see
>> >> >> http://www.spinics.net/lists/linux-usb/msg141188.html for reference)
>> >> >>
>> >> >> Even more. When I introduce USB hub between the host and the webcam, I
>> >> >> can not receive even any 320x240 frames.
>> >> >>
>> >> >> I've managed to use ftrace to see what is going on when no frames are
>> >> >> received.
>> >> >> I've found that pwc_isoc_handler is called frequently as the following:
>> >> >>
>> >> >> 0) | pwc_isoc_handler [pwc]() {
>> >> >> 0) |usb_submit_urb [usbcore]() {
>> >> >> 0) | usb_submit_urb.part.3 [usbcore]() {
>> >> >> 0) |usb_hcd_submit_urb [usbcore]() {
>> >> >> 0) 0.834 us| usb_get_urb [usbcore]();
>> >> >> 0) | musb_map_urb_for_dma [musb_hdrc]() {
>> >> >> 0) 0.792 us|usb_hcd_map_urb_for_dma [usbcore]();
>> >> >> 0) 5.750 us| }
>> >> >> 0) | musb_urb_enqueue [musb_hdrc]() {
>> >> >> 0) 0.750 us|_raw_spin_lock_irqsave();
>> >> >> 0) |usb_hcd_link_urb_to_ep [usbcore]() {
>> >> >> 0) 0.792 us| _raw_spin_lock();
>> >> >> 0) 0.791 us| _raw_spin_unlock();
>
Re: pwc over musb: 100% frame drop (lost) on high resolution stream
2016-07-20 9:09 GMT+03:00 Matwey V. Kornilov :
> 2016-07-20 0:34 GMT+03:00 Bin Liu :
>> Hi,
>>
>> On Wed, Jul 20, 2016 at 12:25:44AM +0300, Matwey V. Kornilov wrote:
>>> 2016-07-19 23:56 GMT+03:00 Bin Liu :
>>> > Hi,
>>> >
>>> > On Tue, Jul 19, 2016 at 11:21:17PM +0300, mat...@sai.msu.ru wrote:
>>> >> Hello,
>>> >>
>>> >> I have Philips SPC 900 camera (0471:0329) connected to my AM335x based
>>> >> BeagleBoneBlack SBC.
>>> >> I am sure that both of them are fine and work properly.
>>> >> I am running Linux 4.6.4 (my kernel config is available at
>>> >> https://clck.ru/A2kQs ) and I've just discovered, that there is an issue
>>> >> with frame transfer when high resolution formats are used.
>>> >>
>>> >> The issue is the following. I use simple v4l2 example tool (taken from
>>> >> API docs), which source code is available at http://pastebin.com/grcNXxfe
>>> >>
>>> >> When I use (see line 488) 640x480 frames
>>> >>
>>> >> fmt.fmt.pix.width = 640;
>>> >> fmt.fmt.pix.height = 480;
>>> >>
>>> >> then I get "select timeout" and don't get any frames.
>>> >>
>>> >> When I use 320x240 frames
>>> >>
>>> >> fmt.fmt.pix.width = 320;
>>> >> fmt.fmt.pix.height = 240;
>>> >>
>>> >> then about 60% frames are missed. An example outpout of ./a.out -f is
>>> >> available at https://yadi.sk/d/aRka8xWPtSc4y
>>> >> It looks like there are pauses between bulks of frames (frame counter
>>> >> and timestamp as returned from v4l2 API):
>>> >>
>>> >> 3 3705.142553
>>> >> 8 3705.342533
>>> >> 13 3705.542517
>>> >> 110 3708.776208
>>> >> 115 3708.976190
>>> >> 120 3709.176169
>>> >> 125 3709.376152
>>> >> 130 3709.576144
>>> >> 226 3712.807848
>>> >>
>>> >> When I use tiny 160x120 frames
>>> >>
>>> >> fmt.fmt.pix.width = 160;
>>> >> fmt.fmt.pix.height = 120;
>>> >>
>>> >> then more frames are received. See output example at
>>> >> https://yadi.sk/d/DedBmH6ftSc9t
>>> >> That is why I thought that everything was fine in May when used tiny
>>> >> xawtv window to check kernel OOPS presence (see
>>> >> http://www.spinics.net/lists/linux-usb/msg141188.html for reference)
>>> >>
>>> >> Even more. When I introduce USB hub between the host and the webcam, I
>>> >> can not receive even any 320x240 frames.
>>> >>
>>> >> I've managed to use ftrace to see what is going on when no frames are
>>> >> received.
>>> >> I've found that pwc_isoc_handler is called frequently as the following:
>>> >>
>>> >> 0) | pwc_isoc_handler [pwc]() {
>>> >> 0) |usb_submit_urb [usbcore]() {
>>> >> 0) | usb_submit_urb.part.3 [usbcore]() {
>>> >> 0) |usb_hcd_submit_urb [usbcore]() {
>>> >> 0) 0.834 us| usb_get_urb [usbcore]();
>>> >> 0) | musb_map_urb_for_dma [musb_hdrc]() {
>>> >> 0) 0.792 us|usb_hcd_map_urb_for_dma [usbcore]();
>>> >> 0) 5.750 us| }
>>> >> 0) | musb_urb_enqueue [musb_hdrc]() {
>>> >> 0) 0.750 us|_raw_spin_lock_irqsave();
>>> >> 0) |usb_hcd_link_urb_to_ep [usbcore]() {
>>> >> 0) 0.792 us| _raw_spin_lock();
>>> >> 0) 0.791 us| _raw_spin_unlock();
>>> >> 0) + 10.500 us |}
>>> >> 0) 0.791 us|_raw_spin_unlock_irqrestore();
>>> >> 0) + 25.375 us | }
>>> >> 0) + 45.208 us |}
>>> >> 0) + 51.042 us | }
>>> >> 0) + 56.084 us |}
>>> >> 0) + 61.292 us | }
>>> >>
>>> >> However, pwc_isoc_handler never calls vb2_buffer_done() that is why I
Re: pwc over musb: 100% frame drop (lost) on high resolution stream
2016-07-20 0:34 GMT+03:00 Bin Liu :
> Hi,
>
> On Wed, Jul 20, 2016 at 12:25:44AM +0300, Matwey V. Kornilov wrote:
>> 2016-07-19 23:56 GMT+03:00 Bin Liu :
>> > Hi,
>> >
>> > On Tue, Jul 19, 2016 at 11:21:17PM +0300, mat...@sai.msu.ru wrote:
>> >> Hello,
>> >>
>> >> I have Philips SPC 900 camera (0471:0329) connected to my AM335x based
>> >> BeagleBoneBlack SBC.
>> >> I am sure that both of them are fine and work properly.
>> >> I am running Linux 4.6.4 (my kernel config is available at
>> >> https://clck.ru/A2kQs ) and I've just discovered, that there is an issue
>> >> with frame transfer when high resolution formats are used.
>> >>
>> >> The issue is the following. I use simple v4l2 example tool (taken from
>> >> API docs), which source code is available at http://pastebin.com/grcNXxfe
>> >>
>> >> When I use (see line 488) 640x480 frames
>> >>
>> >> fmt.fmt.pix.width = 640;
>> >> fmt.fmt.pix.height = 480;
>> >>
>> >> then I get "select timeout" and don't get any frames.
>> >>
>> >> When I use 320x240 frames
>> >>
>> >> fmt.fmt.pix.width = 320;
>> >> fmt.fmt.pix.height = 240;
>> >>
>> >> then about 60% frames are missed. An example outpout of ./a.out -f is
>> >> available at https://yadi.sk/d/aRka8xWPtSc4y
>> >> It looks like there are pauses between bulks of frames (frame counter and
>> >> timestamp as returned from v4l2 API):
>> >>
>> >> 3 3705.142553
>> >> 8 3705.342533
>> >> 13 3705.542517
>> >> 110 3708.776208
>> >> 115 3708.976190
>> >> 120 3709.176169
>> >> 125 3709.376152
>> >> 130 3709.576144
>> >> 226 3712.807848
>> >>
>> >> When I use tiny 160x120 frames
>> >>
>> >> fmt.fmt.pix.width = 160;
>> >> fmt.fmt.pix.height = 120;
>> >>
>> >> then more frames are received. See output example at
>> >> https://yadi.sk/d/DedBmH6ftSc9t
>> >> That is why I thought that everything was fine in May when used tiny
>> >> xawtv window to check kernel OOPS presence (see
>> >> http://www.spinics.net/lists/linux-usb/msg141188.html for reference)
>> >>
>> >> Even more. When I introduce USB hub between the host and the webcam, I
>> >> can not receive even any 320x240 frames.
>> >>
>> >> I've managed to use ftrace to see what is going on when no frames are
>> >> received.
>> >> I've found that pwc_isoc_handler is called frequently as the following:
>> >>
>> >> 0) | pwc_isoc_handler [pwc]() {
>> >> 0) |usb_submit_urb [usbcore]() {
>> >> 0) | usb_submit_urb.part.3 [usbcore]() {
>> >> 0) |usb_hcd_submit_urb [usbcore]() {
>> >> 0) 0.834 us| usb_get_urb [usbcore]();
>> >> 0) | musb_map_urb_for_dma [musb_hdrc]() {
>> >> 0) 0.792 us|usb_hcd_map_urb_for_dma [usbcore]();
>> >> 0) 5.750 us| }
>> >> 0) | musb_urb_enqueue [musb_hdrc]() {
>> >> 0) 0.750 us|_raw_spin_lock_irqsave();
>> >> 0) |usb_hcd_link_urb_to_ep [usbcore]() {
>> >> 0) 0.792 us| _raw_spin_lock();
>> >> 0) 0.791 us| _raw_spin_unlock();
>> >> 0) + 10.500 us |}
>> >> 0) 0.791 us|_raw_spin_unlock_irqrestore();
>> >> 0) + 25.375 us | }
>> >> 0) + 45.208 us |}
>> >> 0) + 51.042 us | }
>> >> 0) + 56.084 us |}
>> >> 0) + 61.292 us | }
>> >>
>> >> However, pwc_isoc_handler never calls vb2_buffer_done() that is why I get
>> >> "select timeout" in userspace.
>> >> Unfortunately, my kernel is not compiled with CONFIG_USB_PWC_DEBUG=y but
>> >> I can recompile it, if you think that it could provide more information.
>> >> I am also ready to perform additional tests (use usbmon maybe?).
>> >>
>> >> How could this issue be re
Re: pwc over musb: 100% frame drop (lost) on high resolution stream
2016-07-19 23:56 GMT+03:00 Bin Liu :
> Hi,
>
> On Tue, Jul 19, 2016 at 11:21:17PM +0300, mat...@sai.msu.ru wrote:
>> Hello,
>>
>> I have Philips SPC 900 camera (0471:0329) connected to my AM335x based
>> BeagleBoneBlack SBC.
>> I am sure that both of them are fine and work properly.
>> I am running Linux 4.6.4 (my kernel config is available at
>> https://clck.ru/A2kQs ) and I've just discovered, that there is an issue
>> with frame transfer when high resolution formats are used.
>>
>> The issue is the following. I use simple v4l2 example tool (taken from API
>> docs), which source code is available at http://pastebin.com/grcNXxfe
>>
>> When I use (see line 488) 640x480 frames
>>
>> fmt.fmt.pix.width = 640;
>> fmt.fmt.pix.height = 480;
>>
>> then I get "select timeout" and don't get any frames.
>>
>> When I use 320x240 frames
>>
>> fmt.fmt.pix.width = 320;
>> fmt.fmt.pix.height = 240;
>>
>> then about 60% frames are missed. An example outpout of ./a.out -f is
>> available at https://yadi.sk/d/aRka8xWPtSc4y
>> It looks like there are pauses between bulks of frames (frame counter and
>> timestamp as returned from v4l2 API):
>>
>> 3 3705.142553
>> 8 3705.342533
>> 13 3705.542517
>> 110 3708.776208
>> 115 3708.976190
>> 120 3709.176169
>> 125 3709.376152
>> 130 3709.576144
>> 226 3712.807848
>>
>> When I use tiny 160x120 frames
>>
>> fmt.fmt.pix.width = 160;
>> fmt.fmt.pix.height = 120;
>>
>> then more frames are received. See output example at
>> https://yadi.sk/d/DedBmH6ftSc9t
>> That is why I thought that everything was fine in May when used tiny xawtv
>> window to check kernel OOPS presence (see
>> http://www.spinics.net/lists/linux-usb/msg141188.html for reference)
>>
>> Even more. When I introduce USB hub between the host and the webcam, I can
>> not receive even any 320x240 frames.
>>
>> I've managed to use ftrace to see what is going on when no frames are
>> received.
>> I've found that pwc_isoc_handler is called frequently as the following:
>>
>> 0) | pwc_isoc_handler [pwc]() {
>> 0) |usb_submit_urb [usbcore]() {
>> 0) | usb_submit_urb.part.3 [usbcore]() {
>> 0) |usb_hcd_submit_urb [usbcore]() {
>> 0) 0.834 us| usb_get_urb [usbcore]();
>> 0) | musb_map_urb_for_dma [musb_hdrc]() {
>> 0) 0.792 us|usb_hcd_map_urb_for_dma [usbcore]();
>> 0) 5.750 us| }
>> 0) | musb_urb_enqueue [musb_hdrc]() {
>> 0) 0.750 us|_raw_spin_lock_irqsave();
>> 0) |usb_hcd_link_urb_to_ep [usbcore]() {
>> 0) 0.792 us| _raw_spin_lock();
>> 0) 0.791 us| _raw_spin_unlock();
>> 0) + 10.500 us |}
>> 0) 0.791 us|_raw_spin_unlock_irqrestore();
>> 0) + 25.375 us | }
>> 0) + 45.208 us |}
>> 0) + 51.042 us | }
>> 0) + 56.084 us |}
>> 0) + 61.292 us | }
>>
>> However, pwc_isoc_handler never calls vb2_buffer_done() that is why I get
>> "select timeout" in userspace.
>> Unfortunately, my kernel is not compiled with CONFIG_USB_PWC_DEBUG=y but I
>> can recompile it, if you think that it could provide more information. I am
>> also ready to perform additional tests (use usbmon maybe?).
>>
>> How could this issue be resolved?
>>
>> Thank you.
>
> Do you have CPPI DMA enabled? If so I think you might hit on a known
> issue in CPPI Isoch transfer, in which the MUSB controller only sends IN
> tokens in every other SOF, so only half of the bus bandwidth is
> utilized, which causes video frame drops in higher resolution.
>
Yes, I do use DMA:
CONFIG_USB_TI_CPPI41_DMA=y
> To confirm this, use a bus analyzer to capture a bus trace, you would
> see no IN tokens in every other SOF while transfering Isoch packets.
>
I am sorry, I am new to USB debugging. Do you mean I need to use
usbmon or some external hardware device?
> Regards,
> -Bin.
>
--
With best regards,
Matwey V. Kornilov.
Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia
119991, Moscow, Universitetsky pr-k 13, +7 (495) 9392382
--
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
pwc over musb: 100% frame drop (lost) on high resolution stream
Hello,
I have Philips SPC 900 camera (0471:0329) connected to my AM335x based
BeagleBoneBlack SBC.
I am sure that both of them are fine and work properly.
I am running Linux 4.6.4 (my kernel config is available at
https://clck.ru/A2kQs ) and I've just discovered, that there is an issue with
frame transfer when high resolution formats are used.
The issue is the following. I use simple v4l2 example tool (taken from API
docs), which source code is available at http://pastebin.com/grcNXxfe
When I use (see line 488) 640x480 frames
fmt.fmt.pix.width = 640;
fmt.fmt.pix.height = 480;
then I get "select timeout" and don't get any frames.
When I use 320x240 frames
fmt.fmt.pix.width = 320;
fmt.fmt.pix.height = 240;
then about 60% frames are missed. An example outpout of ./a.out -f is available
at https://yadi.sk/d/aRka8xWPtSc4y
It looks like there are pauses between bulks of frames (frame counter and
timestamp as returned from v4l2 API):
3 3705.142553
8 3705.342533
13 3705.542517
110 3708.776208
115 3708.976190
120 3709.176169
125 3709.376152
130 3709.576144
226 3712.807848
When I use tiny 160x120 frames
fmt.fmt.pix.width = 160;
fmt.fmt.pix.height = 120;
then more frames are received. See output example at
https://yadi.sk/d/DedBmH6ftSc9t
That is why I thought that everything was fine in May when used tiny xawtv
window to check kernel OOPS presence (see
http://www.spinics.net/lists/linux-usb/msg141188.html for reference)
Even more. When I introduce USB hub between the host and the webcam, I can not
receive even any 320x240 frames.
I've managed to use ftrace to see what is going on when no frames are received.
I've found that pwc_isoc_handler is called frequently as the following:
0) | pwc_isoc_handler [pwc]() {
0) |usb_submit_urb [usbcore]() {
0) | usb_submit_urb.part.3 [usbcore]() {
0) |usb_hcd_submit_urb [usbcore]() {
0) 0.834 us| usb_get_urb [usbcore]();
0) | musb_map_urb_for_dma [musb_hdrc]() {
0) 0.792 us|usb_hcd_map_urb_for_dma [usbcore]();
0) 5.750 us| }
0) | musb_urb_enqueue [musb_hdrc]() {
0) 0.750 us|_raw_spin_lock_irqsave();
0) |usb_hcd_link_urb_to_ep [usbcore]() {
0) 0.792 us| _raw_spin_lock();
0) 0.791 us| _raw_spin_unlock();
0) + 10.500 us |}
0) 0.791 us|_raw_spin_unlock_irqrestore();
0) + 25.375 us | }
0) + 45.208 us |}
0) + 51.042 us | }
0) + 56.084 us |}
0) + 61.292 us | }
However, pwc_isoc_handler never calls vb2_buffer_done() that is why I get
"select timeout" in userspace.
Unfortunately, my kernel is not compiled with CONFIG_USB_PWC_DEBUG=y but I can
recompile it, if you think that it could provide more information. I am also
ready to perform additional tests (use usbmon maybe?).
How could this issue be resolved?
Thank you.
--
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: [OOPS] cppi41_dma_channel_program: Unable to handle kernel NULL pointer dereference
2016-05-23 16:36 GMT+03:00 Bin Liu : > Hi, > > On Sat, May 21, 2016 at 10:04:48PM +0300, Matwey V. Kornilov wrote: >> 2016-05-21 20:50 GMT+03:00 Matwey V. Kornilov : >> > 2016-05-21 6:13 GMT+03:00 Bin Liu : >> >> Hi, >> >> >> >> On Fri, May 20, 2016 at 4:20 PM, Matwey V. Kornilov >> >> wrote: >> >>> 2016-05-21 0:12 GMT+03:00 Bin Liu : >> >>>> Hi, >> >>>> >> >>>> On Sat, May 21, 2016 at 12:05:06AM +0300, Matwey V. Kornilov wrote: >> >>>>> By the way, is it ok that function musb_rx_dma_iso_cppi41 uses >> >>>>> hw_ep->tx_channel? I would suppose that it should use rx_channel >> >>>>> instead. >> >>>> >> >>>> I just got here, and am wondering the same. But the question is why just >> >>>> your case hit the problem. I will try to look at it more next week. >> >>>> >> >>>> I had an impression the linux-usb@ has a discussion before about >> >>>> rx/tx-channel messing up, will have to look it up. >> >>>> >> >>> >> >>> Thank you. >> >>> If you need additional info, I can use kgdb with this issue. >> >> >> >> After reviewed the code, it must be hw_ep->rx_channel instead. It is >> >> likely a >> >> bug caused by commit 069a3fd (usb: musb: Remove ifdefs for musb_host_rx >> >> in musb_host.c part1). Please test with the following patch. >> >> >> > >> > I've just tested this patch. Indeed, it helps to avoid kernel panic. >> > Now, I can interact with my webcam and watch video-stream in xawtv. >> > It would be great if the patch could become a part of 4.6.x stable tree. >> > >> >> Hm, the following string appeared one time during my testing: >> >> [ 867.017179] musb_host_rx 1925: RX14 dma busy, csr 2020 > > This seems to be a different issue. Does your webcam still functional > after the log shows up? > I've just checked. Yes, it does. I can still obtain relevant snapshots from the webcam. > Regards, > -Bin. > -- With best regards, Matwey V. Kornilov. Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia 119991, Moscow, Universitetsky pr-k 13, +7 (495) 9392382 -- 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: [OOPS] cppi41_dma_channel_program: Unable to handle kernel NULL pointer dereference
2016-05-23 16:36 GMT+03:00 Bin Liu : > Hi, > > On Sat, May 21, 2016 at 10:04:48PM +0300, Matwey V. Kornilov wrote: >> 2016-05-21 20:50 GMT+03:00 Matwey V. Kornilov : >> > 2016-05-21 6:13 GMT+03:00 Bin Liu : >> >> Hi, >> >> >> >> On Fri, May 20, 2016 at 4:20 PM, Matwey V. Kornilov >> >> wrote: >> >>> 2016-05-21 0:12 GMT+03:00 Bin Liu : >> >>>> Hi, >> >>>> >> >>>> On Sat, May 21, 2016 at 12:05:06AM +0300, Matwey V. Kornilov wrote: >> >>>>> By the way, is it ok that function musb_rx_dma_iso_cppi41 uses >> >>>>> hw_ep->tx_channel? I would suppose that it should use rx_channel >> >>>>> instead. >> >>>> >> >>>> I just got here, and am wondering the same. But the question is why just >> >>>> your case hit the problem. I will try to look at it more next week. >> >>>> >> >>>> I had an impression the linux-usb@ has a discussion before about >> >>>> rx/tx-channel messing up, will have to look it up. >> >>>> >> >>> >> >>> Thank you. >> >>> If you need additional info, I can use kgdb with this issue. >> >> >> >> After reviewed the code, it must be hw_ep->rx_channel instead. It is >> >> likely a >> >> bug caused by commit 069a3fd (usb: musb: Remove ifdefs for musb_host_rx >> >> in musb_host.c part1). Please test with the following patch. >> >> >> > >> > I've just tested this patch. Indeed, it helps to avoid kernel panic. >> > Now, I can interact with my webcam and watch video-stream in xawtv. >> > It would be great if the patch could become a part of 4.6.x stable tree. >> > >> >> Hm, the following string appeared one time during my testing: >> >> [ 867.017179] musb_host_rx 1925: RX14 dma busy, csr 2020 > > This seems to be a different issue. Does your webcam still functional > after the log shows up? It seems so, but I am not sure completely, unfortunately this message has stochastic origin. So, I will try to reproduce it again and then report additional info. > > Regards, > -Bin. > -- With best regards, Matwey V. Kornilov. Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia 119991, Moscow, Universitetsky pr-k 13, +7 (495) 9392382 -- 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: [OOPS] cppi41_dma_channel_program: Unable to handle kernel NULL pointer dereference
2016-05-23 16:35 GMT+03:00 Bin Liu : > Hi, > > On Sat, May 21, 2016 at 08:50:32PM +0300, Matwey V. Kornilov wrote: >> 2016-05-21 6:13 GMT+03:00 Bin Liu : >> > Hi, >> > >> > On Fri, May 20, 2016 at 4:20 PM, Matwey V. Kornilov >> > wrote: >> >> 2016-05-21 0:12 GMT+03:00 Bin Liu : >> >>> Hi, >> >>> >> >>> On Sat, May 21, 2016 at 12:05:06AM +0300, Matwey V. Kornilov wrote: >> >>>> By the way, is it ok that function musb_rx_dma_iso_cppi41 uses >> >>>> hw_ep->tx_channel? I would suppose that it should use rx_channel >> >>>> instead. >> >>> >> >>> I just got here, and am wondering the same. But the question is why just >> >>> your case hit the problem. I will try to look at it more next week. >> >>> >> >>> I had an impression the linux-usb@ has a discussion before about >> >>> rx/tx-channel messing up, will have to look it up. >> >>> >> >> >> >> Thank you. >> >> If you need additional info, I can use kgdb with this issue. >> > >> > After reviewed the code, it must be hw_ep->rx_channel instead. It is >> > likely a >> > bug caused by commit 069a3fd (usb: musb: Remove ifdefs for musb_host_rx >> > in musb_host.c part1). Please test with the following patch. >> > >> >> I've just tested this patch. Indeed, it helps to avoid kernel panic. > > Thanks for testing it. > >> Now, I can interact with my webcam and watch video-stream in xawtv. >> It would be great if the patch could become a part of 4.6.x stable tree. > > Sure. > > Would you mind to add your Reported-by in the patch? Sure, please add Reported-by: Matwey V. Kornilov > > Regards, > -Bin. > -- With best regards, Matwey V. Kornilov. Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia 119991, Moscow, Universitetsky pr-k 13, +7 (495) 9392382 -- 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: [OOPS] cppi41_dma_channel_program: Unable to handle kernel NULL pointer dereference
2016-05-21 20:50 GMT+03:00 Matwey V. Kornilov :
> 2016-05-21 6:13 GMT+03:00 Bin Liu :
>> Hi,
>>
>> On Fri, May 20, 2016 at 4:20 PM, Matwey V. Kornilov
>> wrote:
>>> 2016-05-21 0:12 GMT+03:00 Bin Liu :
>>>> Hi,
>>>>
>>>> On Sat, May 21, 2016 at 12:05:06AM +0300, Matwey V. Kornilov wrote:
>>>>> By the way, is it ok that function musb_rx_dma_iso_cppi41 uses
>>>>> hw_ep->tx_channel? I would suppose that it should use rx_channel
>>>>> instead.
>>>>
>>>> I just got here, and am wondering the same. But the question is why just
>>>> your case hit the problem. I will try to look at it more next week.
>>>>
>>>> I had an impression the linux-usb@ has a discussion before about
>>>> rx/tx-channel messing up, will have to look it up.
>>>>
>>>
>>> Thank you.
>>> If you need additional info, I can use kgdb with this issue.
>>
>> After reviewed the code, it must be hw_ep->rx_channel instead. It is likely a
>> bug caused by commit 069a3fd (usb: musb: Remove ifdefs for musb_host_rx
>> in musb_host.c part1). Please test with the following patch.
>>
>
> I've just tested this patch. Indeed, it helps to avoid kernel panic.
> Now, I can interact with my webcam and watch video-stream in xawtv.
> It would be great if the patch could become a part of 4.6.x stable tree.
>
Hm, the following string appeared one time during my testing:
[ 867.017179] musb_host_rx 1925: RX14 dma busy, csr 2020
>> Regards,
>> -Bin.
>>
>> -8<-
>> diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
>> index 2f8ad7f..9b2553c 100644
>> --- a/drivers/usb/musb/musb_host.c
>> +++ b/drivers/usb/musb/musb_host.c
>> @@ -1551,7 +1551,7 @@ static int musb_rx_dma_iso_cppi41(struct
>> dma_controller *dma,
>> struct urb *urb,
>> size_t len)
>> {
>> - struct dma_channel *channel = hw_ep->tx_channel;
>> + struct dma_channel *channel = hw_ep->rx_channel;
>> void __iomem *epio = hw_ep->regs;
>> dma_addr_t *buf;
>> u32 length, res;
>>
>
>
>
> --
> With best regards,
> Matwey V. Kornilov.
> Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia
> 119991, Moscow, Universitetsky pr-k 13, +7 (495) 9392382
--
With best regards,
Matwey V. Kornilov.
Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia
119991, Moscow, Universitetsky pr-k 13, +7 (495) 9392382
--
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: [OOPS] cppi41_dma_channel_program: Unable to handle kernel NULL pointer dereference
2016-05-21 6:13 GMT+03:00 Bin Liu :
> Hi,
>
> On Fri, May 20, 2016 at 4:20 PM, Matwey V. Kornilov wrote:
>> 2016-05-21 0:12 GMT+03:00 Bin Liu :
>>> Hi,
>>>
>>> On Sat, May 21, 2016 at 12:05:06AM +0300, Matwey V. Kornilov wrote:
>>>> By the way, is it ok that function musb_rx_dma_iso_cppi41 uses
>>>> hw_ep->tx_channel? I would suppose that it should use rx_channel
>>>> instead.
>>>
>>> I just got here, and am wondering the same. But the question is why just
>>> your case hit the problem. I will try to look at it more next week.
>>>
>>> I had an impression the linux-usb@ has a discussion before about
>>> rx/tx-channel messing up, will have to look it up.
>>>
>>
>> Thank you.
>> If you need additional info, I can use kgdb with this issue.
>
> After reviewed the code, it must be hw_ep->rx_channel instead. It is likely a
> bug caused by commit 069a3fd (usb: musb: Remove ifdefs for musb_host_rx
> in musb_host.c part1). Please test with the following patch.
>
I've just tested this patch. Indeed, it helps to avoid kernel panic.
Now, I can interact with my webcam and watch video-stream in xawtv.
It would be great if the patch could become a part of 4.6.x stable tree.
> Regards,
> -Bin.
>
> -8<-
> diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
> index 2f8ad7f..9b2553c 100644
> --- a/drivers/usb/musb/musb_host.c
> +++ b/drivers/usb/musb/musb_host.c
> @@ -1551,7 +1551,7 @@ static int musb_rx_dma_iso_cppi41(struct
> dma_controller *dma,
> struct urb *urb,
> size_t len)
> {
> - struct dma_channel *channel = hw_ep->tx_channel;
> + struct dma_channel *channel = hw_ep->rx_channel;
> void __iomem *epio = hw_ep->regs;
> dma_addr_t *buf;
> u32 length, res;
>
--
With best regards,
Matwey V. Kornilov.
Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia
119991, Moscow, Universitetsky pr-k 13, +7 (495) 9392382
--
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: [OOPS] cppi41_dma_channel_program: Unable to handle kernel NULL pointer dereference
2016-05-21 0:12 GMT+03:00 Bin Liu : > Hi, > > On Sat, May 21, 2016 at 12:05:06AM +0300, Matwey V. Kornilov wrote: >> By the way, is it ok that function musb_rx_dma_iso_cppi41 uses >> hw_ep->tx_channel? I would suppose that it should use rx_channel >> instead. > > I just got here, and am wondering the same. But the question is why just > your case hit the problem. I will try to look at it more next week. > > I had an impression the linux-usb@ has a discussion before about > rx/tx-channel messing up, will have to look it up. > Thank you. If you need additional info, I can use kgdb with this issue. > Regards, > -Bin. > -- With best regards, Matwey V. Kornilov. Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia 119991, Moscow, Universitetsky pr-k 13, +7 (495) 9392382 -- 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: [OOPS] cppi41_dma_channel_program: Unable to handle kernel NULL pointer dereference
By the way, is it ok that function musb_rx_dma_iso_cppi41 uses
hw_ep->tx_channel? I would suppose that it should use rx_channel
instead.
2016-05-20 23:58 GMT+03:00 Matwey V. Kornilov :
> (gdb) frame 3
> #3 musb_host_rx (musb=0xdb3e0010, epnum=) at
> ../drivers/usb/musb/musb_host.c:1969
> 1969done =
> musb_rx_dma_inventra_cppi41(c, hw_ep, qh, urb, xfer_len);
> (gdb) info locals
> hw_ep = 0xdb3e0f48
> c =
> epio =
> qh = 0xd9cb2000
> xfer_len =
> mbase =
> iso_err =
> done =
> status =
> dma =
> __func__ = address 0x3e8)>
> (gdb) print hw_ep
> $21 = (struct musb_hw_ep *) 0xdb3e0f48
> (gdb) print *hw_ep
> $22 = {musb = 0xdb3e0010, fifo = 0xe0bf6c58, regs = 0xe0bf6c10, epnum
> = 14 '\016', is_shared_fifo = true, tx_double_buffered = false,
> rx_double_buffered = false, max_packet_sz_tx = 1024,
> max_packet_sz_rx = 1024, tx_channel = 0x0, rx_channel = 0xd914c3bc,
> in_qh = 0xd9cb2000, out_qh = 0xd9cb2000, rx_reinit = 0 '\000',
> tx_reinit = 1 '\001', ep_in = {end_point = {driver_data = 0x0,
> name = 0x0, ops = 0x0, ep_list = {next = 0x0, prev = 0x0}, caps
> = {type_control = 0, type_iso = 0, type_bulk = 0, type_int = 0,
> dir_in = 0, dir_out = 0}, claimed = false, enabled = false,
> maxpacket = 0, maxpacket_limit = 0, max_streams = 0, mult = 0,
> maxburst = 0, address = 0 '\000', desc = 0x0, comp_desc = 0x0},
> name = '\000' , hw_ep = 0x0, musb = 0x0,
> current_epnum = 0 '\000', type = 0 '\000', is_in = 0 '\000',
> packet_sz = 0, desc = 0x0, dma = 0x0, req_list = {next = 0x0,
> prev = 0x0}, wedged = 0 '\000', busy = 0 '\000', hb_mult = 0
> '\000'}, ep_out = {end_point = {driver_data = 0x0, name = 0x0,
> ops = 0x0, ep_list = {next = 0x0, prev = 0x0}, caps =
> {type_control = 0, type_iso = 0, type_bulk = 0, type_int = 0, dir_in =
> 0,
> dir_out = 0}, claimed = false, enabled = false, maxpacket = 0,
> maxpacket_limit = 0, max_streams = 0, mult = 0, maxburst = 0,
> address = 0 '\000', desc = 0x0, comp_desc = 0x0}, name = '\000'
> , hw_ep = 0x0, musb = 0x0,
> current_epnum = 0 '\000', type = 0 '\000', is_in = 0 '\000',
> packet_sz = 0, desc = 0x0, dma = 0x0, req_list = {next = 0x0,
> prev = 0x0}, wedged = 0 '\000', busy = 0 '\000', hb_mult = 0 '\000'}}
>
> 2016-05-20 23:55 GMT+03:00 Matwey V. Kornilov :
>> I used kgdb. Is it ok?
>> channel appeared to be 0x0:
>>
>> (gdb) continue
>> Continuing.
>> [Switching to Thread 315]
>>
>> Breakpoint 1, cppi41_dma_channel_program (channel=0x0, packet_sz=960,
>> mode=0 '\000', dma_addr=2609136576, len=960)
>> at ../drivers/usb/musb/musb_cppi41.c:481
>> 481 {
>> (gdb) bt
>> #0 cppi41_dma_channel_program (channel=0x0, packet_sz=960, mode=0
>> '\000', dma_addr=2609136576, len=960)
>> at ../drivers/usb/musb/musb_cppi41.c:481
>> #1 0xbf251570 in musb_rx_dma_iso_cppi41 (len=,
>> urb=, qh=, hw_ep=,
>> dma=) at ../drivers/usb/musb/musb_host.c:1569
>> #2 musb_rx_dma_inventra_cppi41 (len=, urb=> out>, qh=, hw_ep=,
>> dma=) at ../drivers/usb/musb/musb_host.c:1652
>> #3 musb_host_rx (musb=0xdb3e0010, epnum=) at
>> ../drivers/usb/musb/musb_host.c:1969
>> #4 0xbf249fb4 in musb_dma_completion (musb=,
>> epnum=, transmit=)
>> at ../drivers/usb/musb/musb_core.c:1693
>> #5 0xbf258b10 in cppi41_trans_done (cppi41_channel=0xd914c3bc) at
>> ../drivers/usb/musb/musb_cppi41.c:148
>> #6 0xbf258c1c in cppi41_dma_callback (private_data=)
>> at ../drivers/usb/musb/musb_cppi41.c:286
>> #7 0xbf229f38 in ?? ()
>> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
>>
>>
>> 2016-05-20 23:10 GMT+03:00 Bin Liu :
>>> Hi,
>>>
>>> On Fri, May 20, 2016 at 04:32:06PM +0300, Matwey V. Kornilov wrote:
>>>> 2016-05-20 16:19 GMT+03:00 :
>>>> > Hello,
>>>> >
>>>> > I am running 4.6-rc3 on BealgeBone Black and when I try to interract
>>>> > with pwc webcam attached to usb port the following kernel panic
>>>> > happening.
>>>>
>>>> Please note, that the same is happening with 4.6.0 release.
>>>
>>> Please apply the following patch and reproduce the oops, I'd like to
>>> check if the oops is caused by NULL of hw_ep->in_qh.
>>>
>>> Regards,
>>> -Bin.
Re: [OOPS] cppi41_dma_channel_program: Unable to handle kernel NULL pointer dereference
(gdb) frame 3
#3 musb_host_rx (musb=0xdb3e0010, epnum=) at
../drivers/usb/musb/musb_host.c:1969
1969done =
musb_rx_dma_inventra_cppi41(c, hw_ep, qh, urb, xfer_len);
(gdb) info locals
hw_ep = 0xdb3e0f48
c =
epio =
qh = 0xd9cb2000
xfer_len =
mbase =
iso_err =
done =
status =
dma =
__func__ =
(gdb) print hw_ep
$21 = (struct musb_hw_ep *) 0xdb3e0f48
(gdb) print *hw_ep
$22 = {musb = 0xdb3e0010, fifo = 0xe0bf6c58, regs = 0xe0bf6c10, epnum
= 14 '\016', is_shared_fifo = true, tx_double_buffered = false,
rx_double_buffered = false, max_packet_sz_tx = 1024,
max_packet_sz_rx = 1024, tx_channel = 0x0, rx_channel = 0xd914c3bc,
in_qh = 0xd9cb2000, out_qh = 0xd9cb2000, rx_reinit = 0 '\000',
tx_reinit = 1 '\001', ep_in = {end_point = {driver_data = 0x0,
name = 0x0, ops = 0x0, ep_list = {next = 0x0, prev = 0x0}, caps
= {type_control = 0, type_iso = 0, type_bulk = 0, type_int = 0,
dir_in = 0, dir_out = 0}, claimed = false, enabled = false,
maxpacket = 0, maxpacket_limit = 0, max_streams = 0, mult = 0,
maxburst = 0, address = 0 '\000', desc = 0x0, comp_desc = 0x0},
name = '\000' , hw_ep = 0x0, musb = 0x0,
current_epnum = 0 '\000', type = 0 '\000', is_in = 0 '\000',
packet_sz = 0, desc = 0x0, dma = 0x0, req_list = {next = 0x0,
prev = 0x0}, wedged = 0 '\000', busy = 0 '\000', hb_mult = 0
'\000'}, ep_out = {end_point = {driver_data = 0x0, name = 0x0,
ops = 0x0, ep_list = {next = 0x0, prev = 0x0}, caps =
{type_control = 0, type_iso = 0, type_bulk = 0, type_int = 0, dir_in =
0,
dir_out = 0}, claimed = false, enabled = false, maxpacket = 0,
maxpacket_limit = 0, max_streams = 0, mult = 0, maxburst = 0,
address = 0 '\000', desc = 0x0, comp_desc = 0x0}, name = '\000'
, hw_ep = 0x0, musb = 0x0,
current_epnum = 0 '\000', type = 0 '\000', is_in = 0 '\000',
packet_sz = 0, desc = 0x0, dma = 0x0, req_list = {next = 0x0,
prev = 0x0}, wedged = 0 '\000', busy = 0 '\000', hb_mult = 0 '\000'}}
2016-05-20 23:55 GMT+03:00 Matwey V. Kornilov :
> I used kgdb. Is it ok?
> channel appeared to be 0x0:
>
> (gdb) continue
> Continuing.
> [Switching to Thread 315]
>
> Breakpoint 1, cppi41_dma_channel_program (channel=0x0, packet_sz=960,
> mode=0 '\000', dma_addr=2609136576, len=960)
> at ../drivers/usb/musb/musb_cppi41.c:481
> 481 {
> (gdb) bt
> #0 cppi41_dma_channel_program (channel=0x0, packet_sz=960, mode=0
> '\000', dma_addr=2609136576, len=960)
> at ../drivers/usb/musb/musb_cppi41.c:481
> #1 0xbf251570 in musb_rx_dma_iso_cppi41 (len=,
> urb=, qh=, hw_ep=,
> dma=) at ../drivers/usb/musb/musb_host.c:1569
> #2 musb_rx_dma_inventra_cppi41 (len=, urb= out>, qh=, hw_ep=,
> dma=) at ../drivers/usb/musb/musb_host.c:1652
> #3 musb_host_rx (musb=0xdb3e0010, epnum=) at
> ../drivers/usb/musb/musb_host.c:1969
> #4 0xbf249fb4 in musb_dma_completion (musb=,
> epnum=, transmit=)
> at ../drivers/usb/musb/musb_core.c:1693
> #5 0xbf258b10 in cppi41_trans_done (cppi41_channel=0xd914c3bc) at
> ../drivers/usb/musb/musb_cppi41.c:148
> #6 0xbf258c1c in cppi41_dma_callback (private_data=)
> at ../drivers/usb/musb/musb_cppi41.c:286
> #7 0xbf229f38 in ?? ()
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
>
>
> 2016-05-20 23:10 GMT+03:00 Bin Liu :
>> Hi,
>>
>> On Fri, May 20, 2016 at 04:32:06PM +0300, Matwey V. Kornilov wrote:
>>> 2016-05-20 16:19 GMT+03:00 :
>>> > Hello,
>>> >
>>> > I am running 4.6-rc3 on BealgeBone Black and when I try to interract
>>> > with pwc webcam attached to usb port the following kernel panic
>>> > happening.
>>>
>>> Please note, that the same is happening with 4.6.0 release.
>>
>> Please apply the following patch and reproduce the oops, I'd like to
>> check if the oops is caused by NULL of hw_ep->in_qh.
>>
>> Regards,
>> -Bin.
>>
>> ---8<---
>> diff --git a/drivers/usb/musb/musb_cppi41.c b/drivers/usb/musb/musb_cppi41.c
>> index e499b86..3492c6e 100644
>> --- a/drivers/usb/musb/musb_cppi41.c
>> +++ b/drivers/usb/musb/musb_cppi41.c
>> @@ -489,8 +489,11 @@ static int cppi41_dma_channel_program(struct
>> dma_channel *channel,
>> if (is_host_active(cppi41_channel->controller->musb)) {
>> if (cppi41_channel->is_tx)
>> hb_mult = cppi41_channel->hw_ep->out_qh->hb_mult;
>> - else
>> + else {
>> + if (!cppi41_channel->hw_ep-&
Re: [OOPS] cppi41_dma_channel_program: Unable to handle kernel NULL pointer dereference
I used kgdb. Is it ok?
channel appeared to be 0x0:
(gdb) continue
Continuing.
[Switching to Thread 315]
Breakpoint 1, cppi41_dma_channel_program (channel=0x0, packet_sz=960,
mode=0 '\000', dma_addr=2609136576, len=960)
at ../drivers/usb/musb/musb_cppi41.c:481
481 {
(gdb) bt
#0 cppi41_dma_channel_program (channel=0x0, packet_sz=960, mode=0
'\000', dma_addr=2609136576, len=960)
at ../drivers/usb/musb/musb_cppi41.c:481
#1 0xbf251570 in musb_rx_dma_iso_cppi41 (len=,
urb=, qh=, hw_ep=,
dma=) at ../drivers/usb/musb/musb_host.c:1569
#2 musb_rx_dma_inventra_cppi41 (len=, urb=, qh=, hw_ep=,
dma=) at ../drivers/usb/musb/musb_host.c:1652
#3 musb_host_rx (musb=0xdb3e0010, epnum=) at
../drivers/usb/musb/musb_host.c:1969
#4 0xbf249fb4 in musb_dma_completion (musb=,
epnum=, transmit=)
at ../drivers/usb/musb/musb_core.c:1693
#5 0xbf258b10 in cppi41_trans_done (cppi41_channel=0xd914c3bc) at
../drivers/usb/musb/musb_cppi41.c:148
#6 0xbf258c1c in cppi41_dma_callback (private_data=)
at ../drivers/usb/musb/musb_cppi41.c:286
#7 0xbf229f38 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
2016-05-20 23:10 GMT+03:00 Bin Liu :
> Hi,
>
> On Fri, May 20, 2016 at 04:32:06PM +0300, Matwey V. Kornilov wrote:
>> 2016-05-20 16:19 GMT+03:00 :
>> > Hello,
>> >
>> > I am running 4.6-rc3 on BealgeBone Black and when I try to interract
>> > with pwc webcam attached to usb port the following kernel panic
>> > happening.
>>
>> Please note, that the same is happening with 4.6.0 release.
>
> Please apply the following patch and reproduce the oops, I'd like to
> check if the oops is caused by NULL of hw_ep->in_qh.
>
> Regards,
> -Bin.
>
> ---8<---
> diff --git a/drivers/usb/musb/musb_cppi41.c b/drivers/usb/musb/musb_cppi41.c
> index e499b86..3492c6e 100644
> --- a/drivers/usb/musb/musb_cppi41.c
> +++ b/drivers/usb/musb/musb_cppi41.c
> @@ -489,8 +489,11 @@ static int cppi41_dma_channel_program(struct dma_channel
> *channel,
> if (is_host_active(cppi41_channel->controller->musb)) {
> if (cppi41_channel->is_tx)
> hb_mult = cppi41_channel->hw_ep->out_qh->hb_mult;
> - else
> + else {
> + if (!cppi41_channel->hw_ep->in_qh)
> + dev_err(NULL, "->in_qh is NULL\n");
> hb_mult = cppi41_channel->hw_ep->in_qh->hb_mult;
> + }
> }
>
> channel->status = MUSB_DMA_STATUS_BUSY;
>
--
With best regards,
Matwey V. Kornilov.
Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia
119991, Moscow, Universitetsky pr-k 13, +7 (495) 9392382
--
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: [OOPS] cppi41_dma_channel_program: Unable to handle kernel NULL pointer dereference
5acc c03acc04 c1501f6c c1501f60 > c03acc04 c0315524 > [ 4588.116466] 1f60: c1501f94 c1501f70 c03acf24 c03acbe0 0002 c162ad8b > c143d988 c1501f70 > [ 4588.124685] 1f80: c0c35e64 c1503500 c1501fac c1501f98 c0c33f18 c03acc24 > c163f040 0001 > [ 4588.132904] 1fa0: c1501ff4 c1501fb0 c1300db8 c0c33e90 > c1300714 > [ 4588.141122] 1fc0: c13b4a28 c163f5d4 c1503588 c13b4a24 > c150973c 80204059 > [ 4588.149340] 1fe0: 413fc082 c1501ff8 8020807c c13009c0 > > [ 4588.157705] [] (cppi41_dma_channel_program [musb_hdrc]) from > [] (musb_host_rx+0xc54/0xdd4 [musb_hdrc]) > [ 4588.168901] [] (musb_host_rx [musb_hdrc]) from [] > (musb_dma_completion+0x98/0x9c [musb_hdrc]) > [ 4588.179310] [] (musb_dma_completion [musb_hdrc]) from > [] (cppi41_trans_done+0x18c/0x1d8 [musb_hdrc]) > [ 4588.190329] [] (cppi41_trans_done [musb_hdrc]) from [] > (cppi41_dma_callback+0xc0/0x288 [musb_hdrc]) > [ 4588.201224] [] (cppi41_dma_callback [musb_hdrc]) from > [] (cppi41_irq+0xfc/0x198 [cppi41]) > [ 4588.211214] [] (cppi41_irq [cppi41]) from [] > (handle_irq_event_percpu+0xc4/0x2bc) > [ 4588.220486] [] (handle_irq_event_percpu) from [] > (handle_irq_event+0x48/0x70) > [ 4588.229410] [] (handle_irq_event) from [] > (handle_level_irq+0xbc/0x150) > [ 4588.237807] [] (handle_level_irq) from [] > (generic_handle_irq+0x34/0x48) > [ 4588.246290] [] (generic_handle_irq) from [] > (__handle_domain_irq+0x6c/0xc8) > [ 4588.255038] [] (__handle_domain_irq) from [] > (omap_intc_handle_irq+0x44/0xa8) > [ 4588.263965] [] (omap_intc_handle_irq) from [] > (__irq_svc+0x40/0x74) > [ 4588.272006] Exception stack(0xc1501f00 to 0xc1501f48) > [ 4588.277085] 1f00: 0001 c032c5c0 c150 c1503614 > c15035ac > [ 4588.285304] 1f20: c162b9a0 c150361c c1501f5c c1501f60 c1501f50 > c0315560 c0315568 > [ 4588.293518] 1f40: 600e0013 > [ 4588.297035] [] (__irq_svc) from [] > (arch_cpu_idle+0x50/0x54) > [ 4588.304485] [] (arch_cpu_idle) from [] > (default_idle_call+0x30/0x44) > [ 4588.312623] [] (default_idle_call) from [] > (cpu_startup_entry+0x30c/0x370) > [ 4588.321292] [] (cpu_startup_entry) from [] > (rest_init+0x94/0x98) > [ 4588.329082] [] (rest_init) from [] > (start_kernel+0x404/0x410) > [ 4588.336606] Code: e52de004 e8bd4000 e1a06001 e1a0a003 (e5904000) > [ 4588.349648] ---[ end trace 603f1cfffd4f1ec2 ]--- > [ 4588.354298] Kernel panic - not syncing: Fatal exception in interrupt > [ 4588.360689] Rebooting in 90 seconds.. -- With best regards, Matwey V. Kornilov. Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia 119991, Moscow, Universitetsky pr-k 13, +7 (495) 9392382 -- 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
[OOPS] cppi41_dma_channel_program: Unable to handle kernel NULL pointer dereference
Hello, I am running 4.6-rc3 on BealgeBone Black and when I try to interract with pwc webcam attached to usb port the following kernel panic happening. Please also find used kernel config here: http://kernel.opensuse.org/cgit/kernel-source/plain/config/armv7hl/default?id=43f1ed415e2227af11856fc120821c791d51494d [ 4587.746169] Unable to handle kernel NULL pointer dereference at virtual address [ 4587.754333] pgd = c0204000 [ 4587.757055] [] *pgd= [ 4587.760667] Internal error: Oops: 17 [#1] PREEMPT SMP ARM [ 4587.766095] Modules linked in: af_packet bridge stp llc nls_iso8859_1 nls_cp437 vfat fat snd_usb_audio snd_usbmidi_lib snd_hwdep snd_rawmidi snd_seq_device snd_pcm snd_timer snd soundcore pwc videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_core videodev media smsc musb_dsps musb_hdrc udc_core davinci_mdio phy_am335x usbcore phy_am335x_control phy_generic cppi41 usb_common wkup_m3_rproc remoteproc virtio_ring virtio pps_gpio ti_cpsw pps_core cpsw_ale cpsw_common omap_aes davinci_cpdma omap_sham crypto_engine omap_rng omap_mailbox musb_am335x omap_wdt at24 nvmem_core leds_gpio cpufreq_dt mmc_block tps65217_regulator omap_hsmmc omap_dma mmc_core tps65217 sg [ 4587.825879] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.6.0-rc3-2.gcfd5095-default #1 [ 4587.833745] Hardware name: Generic AM33XX (Flattened Device Tree) [ 4587.839867] task: c15081c0 ti: c150 task.ti: c150 [ 4587.845453] PC is at cppi41_dma_channel_program+0x20/0x2f0 [musb_hdrc] [ 4587.852063] LR is at musb_host_rx+0xc54/0xdd4 [musb_hdrc] [ 4587.857490] pc : []lr : []psr: 000e0193 [ 4587.857490] sp : c1501c48 ip : c1501cb8 fp : c1501cb4 [ 4587.869021] r10: 9b8443c0 r9 : d92baf48 r8 : e0c72c10 [ 4587.874270] r7 : r6 : 03c0 r5 : d9c8e900 r4 : d92ba010 [ 4587.880827] r3 : 9b8443c0 r2 : r1 : 03c0 r0 : [ 4587.887385] Flags: nzcv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel [ 4587.894815] Control: 10c5387d Table: 9b4fc019 DAC: 0055 [ 4587.900587] Process swapper/0 (pid: 0, stack limit = 0xc1500220) [ 4587.906621] Stack: (0xc1501c48 to 0xc1502000) [ 4587.911002] 1c40: 0001 c1501ca4 c1501c60 df926740 c1501c68 [ 4587.919221] 1c60: c03efed0 c0344ec8 8065dcc6 c153c490 df926740 df926740 2193 [ 4587.927440] 1c80: df926740 c1504920 d92ba010 d9c8e900 03c0 e0c72c10 [ 4587.935659] 1ca0: d92baf48 bf2a55cc c1501d2c c1501cb8 bf297570 bf29f1fc 03c0 df926740 [ 4587.943877] 1cc0: c1501cf4 c1501cd0 c038ffac c038fef0 9b8443c0 0c40 d92ba308 [ 4587.952096] 1ce0: d9dcc000 bf2a55c4 db50f800 000e bf2a4838 e0c72c10 db50f814 [ 4587.960315] 1d00: c1501d44 d9dcc3bc d92baf48 d92baf48 d92ba010 d92ba010 e0c72c10 [ 4587.968533] 1d20: c1501d3c c1501d30 bf28ffb4 bf296928 c1501d94 c1501d40 bf29eb10 bf28ff28 [ 4587.976751] 1d40: c0392284 c0391db8 c1501d8c c1501d58 c03abc14 c0392274 c03e77e8 [ 4587.984970] 1d60: c03c73f0 db4f9bf0 db4f9bec d9dcc3bc d92baf48 bf2a5348 d92ba010 [ 4587.993188] 1d80: 200e0193 c1501de4 c1501d98 bf29ec1c bf29e990 c1501dc4 c1501da8 [ 4588.001406] 1da0: c03ac91c c0c39b04 d9c8e900 0002 0002 03c0 c03e4a18 [ 4588.009625] 1dc0: db30ac10 0001 0080 0004 00a0 c1501e1c c1501de8 [ 4588.017843] 1de0: bf16ff38 bf29eb68 c150d8c0 c03e4a18 c1501e3c d9d4fd80 db40b2a0 db40b250 [ 4588.026062] 1e00: 0001 00b8 c1500020 c1501e6c c1501e20 c03c7260 bf16fe48 [ 4588.034281] 1e20: 042c c162b1a4 c162b1c0 db40b240 c15035ac [ 4588.042499] 1e40: c1501e7c db40b240 db40b2a0 db40b250 0001 db02e000 c150361c [ 4588.050718] 1e60: c1501e8c c1501e70 c03c74a0 c03c71a8 db40b240 db40b2a0 db40b250 0001 [ 4588.058936] 1e80: c1501eac c1501e90 c03cabf0 c03c7464 c143b77c 0001 [ 4588.067154] 1ea0: c1501ebc c1501eb0 c03c676c c03cab40 c1501ee4 c1501ec0 c03c6abc c03c6744 [ 4588.075373] 1ec0: c16f981c 600e0013 c1501f34 c162b9a0 c150361c c1501efc c1501ee8 [ 4588.083592] 1ee0: c0301770 c03c6a5c c0315568 600e0013 c1501f5c c1501f00 c0c3a280 c0301738 [ 4588.091810] 1f00: 0001 c032c5c0 c150 c1503614 c15035ac [ 4588.100029] 1f20: c162b9a0 c150361c c1501f5c c1501f60 c1501f50 c0315560 c0315568 [ 4588.108247] 1f40: 600e0013 c03d5acc c03acc04 c1501f6c c1501f60 c03acc04 c0315524 [ 4588.116466] 1f60: c1501f94 c1501f70 c03acf24 c03acbe0 0002 c162ad8b c143d988 c1501f70 [ 4588.124685] 1f80: c0c35e64 c1503500 c1501fac c1501f98 c0c33f18 c03acc24 c163f040 0001 [ 4588.132904] 1fa0: c1501ff4 c1501fb0 c1300db8 c0c33e90 c1300714 [ 4588.141122] 1fc0: c13b4a28 c163f5d4 c1503588 c13b4a24 c150973c 80204059 [ 4588.149340] 1fe0: 413fc082 c1501ff8 8020807c c13009c0 [ 4588.157705
ftdi_sio: ftdi_set_termios
Dear Bill and all, I am facing an issue with ftdi_sio module and FTDI FT232-based devices. Now I am trying to understand where the origin is. By indirect evidences, I think that there is a small time gap between return of tcsetattr(fd_, TCSANOW, &new_termios) and actual settings application in the hardware. From the kernel sources I see that tcsetattr returns after ftdi_set_termios complete, which uses sync usb_control_msg calls. Unfortunately, I've not found data-sheet for FT232 describing USB protocol, so I would like to ask whether it is guaranteed that new settings are applied in hardware before ftdi_set_termios returns? -- With best regards, Matwey V. Kornilov http://blog.matwey.name xmpp://0x2...@jabber.ru -- 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: OOPS: musb_am335x: __device_attach
05.02.2015 19:30, Matwey V. Kornilov пишет: > > The issue is still there for 3.19.0-rc7 > > -- > 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 > I think that I've found the problem in spear13xx_pcie_driver, now I am rebuilding the kernel and will try again. -- 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: OOPS: musb_am335x: __device_attach
The issue is still there for 3.19.0-rc7 -- 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: OOPS: musb_am335x: __device_attach
Hi, I was able to use some gdb to touch the issue: (gdb) monitor lsmod Module Size modstruct Used by musb_am335x 1431 0xbf0002781 (Loading) 0xbf00 [ ] (gdb) bt #0 0x73256020 in ?? () #1 0xc07a68f8 in driver_match_device (dev=, drv=) at ../drivers/base/base.h:117 #2 __device_attach (drv=0xc0ed5708 , data=0xdb624210) at ../drivers/base/dd.c:409 #3 0xc07a4920 in bus_for_each_drv (bus=, start=, data=0xda0, fn=0xc07a68c8 <__device_attach>) at ../drivers/base/bus.c:463 #4 0xc07a64ac in device_attach (dev=0xdb624210) at ../drivers/base/dd.c:447 #5 0xc07a599c in bus_probe_device (dev=0xdb624210) at ../drivers/base/bus.c:558 #6 0xc07a3a60 in device_add (dev=) at ../drivers/base/core.c:1058 #7 0xc08b6c0c in of_device_add (ofdev=) at ../drivers/of/device.c:66 #8 0xc08b75dc in of_platform_device_create_pdata (np=, bus_id=0x0 <__vectors_start>, platform_data=0x0 <__vectors_start>, parent=) at ../drivers/of/platform.c:241 #9 0xc08b7718 in of_platform_bus_create (bus=0xdfa46780, matches=0x0 <__vectors_start>, lookup=0x0 <__vectors_start>, parent=0xdb183410, strict=true) at ../drivers/of/platform.c:414 #10 0xc08b7b6c in of_platform_populate (root=0xdb624210, matches=0xc0ed5708 , lookup=0xda0, parent=0xc07a68c8 <__device_attach>) at ../drivers/of/platform.c:501 #11 0xbf30 in am335x_child_probe (pdev=0xdb183400) at ../drivers/usb/musb/musb_am335x.c:12 #12 0xc07a8578 in platform_drv_probe (_dev=0xdb183410) at ../drivers/base/platform.c:512 #13 0xc07a6670 in really_probe (drv=, dev=) at ../drivers/base/dd.c:302 #14 driver_probe_device (drv=0xbf000234, dev=0xdb183410) at ../drivers/base/dd.c:399 #15 0xc07a69a8 in __driver_attach (dev=0xdb183410, data=0xbf000234) at ../drivers/base/dd.c:477 #16 0xc07a4870 in bus_for_each_dev (bus=, start=, data=0xda0, fn=0xc07a852c ) at ../drivers/base/bus.c:313 #17 0xc07a6044 in driver_attach (drv=) at ../drivers/base/dd.c:496 #18 0xc07a5c78 in bus_add_driver (drv=0xbf000234) at ../drivers/base/bus.c:694 #19 0xc07a7174 in driver_register (drv=0xbf000234) at ../drivers/base/driver.c:167 #20 0xc0209c34 in do_one_initcall (fn=0xbf002000) at ../init/main.c:801 #21 0xc02e0494 in do_init_module (mod=) at ../kernel/module.c:3142 #22 load_module (info=0xdb6adf54, uargs=, flags=) at ../kernel/module.c:3461 #23 0xc02e0a44 in SYSC_finit_module (flags=, uargs=, fd=) at ../kernel/module.c:3537 #24 SyS_finit_module (fd=7, uargs=-1226138708, flags=0) at ../kernel/module.c:3518 #25 0xc021a680 in ?? () Here some strange stuff. And I have no idea what is spear13xx_pcie_driver. (gdb) frame 11 #11 0xbf30 in am335x_child_probe (pdev=0xdb183400) at ../drivers/usb/musb/musb_am335x.c:12 12 ../drivers/usb/musb/musb_am335x.c: Нет такого файла или каталога. (gdb) print pdev->dev.of_node $8 = (struct device_node *) 0xdfa46574 (gdb) print &pdev->dev $9 = (struct device *) 0xdb183410 (gdb) frame 10 #10 0xc08b7b6c in of_platform_populate (root=0xdb624210, matches=0xc0ed5708 , lookup=0xda0, parent=0xc07a68c8 <__device_attach>) at ../drivers/of/platform.c:501 501 ../drivers/of/platform.c: Нет такого файла или каталога. (gdb) print root $10 = (struct device_node *) 0xdb624210 (gdb) print parent $11 = (struct device *) 0xc07a68c8 <__device_attach> Something wrong has happened between 10 and 11 frames. -- 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
OOPS: musb_am335x: __device_attach
Hi, I am facing the following issue, when running 3.19-rc6 on my beaglebone black: [9.638571] Unable to handle kernel paging request at virtual address 69646b89 [9.646309] pgd = db6dc000 [9.649168] [69646b89] *pgd= [9.652929] Internal error: Oops: 5 [#1] SMP ARM [9.657769] Modules linked in: musb_am335x(+) [9.662351] CPU: 0 PID: 220 Comm: systemd-udevd Not tainted 3.19.0-rc6-3.ga7bdd86-default #1 [9.671196] Hardware name: Generic AM33XX (Flattened Device Tree) [9.677583] task: db6af300 ti: db6d8000 task.ti: db6d8000 [9.683257] PC is at __device_attach+0x18/0x4c [9.687918] LR is at bus_for_each_drv+0x60/0x94 [9.692668] pc : []lr : []psr: 60010013 [9.692668] sp : db6d9c70 ip : c0ed5708 fp : [9.704704] r10: r9 : r8 : c112b96c [9.710180] r7 : db183410 r6 : c07a68c8 r5 : db608a10 r4 : c0ed5708 [9.717023] r3 : 69646b6d r2 : 0da0 r1 : db608a10 r0 : c0ed5708 [9.723867] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [9.731347] Control: 10c5387d Table: 9b6dc019 DAC: 0015 [9.737371] Process systemd-udevd (pid: 220, stack limit = 0xdb6d8248) [9.744213] Stack: (0xdb6d9c70 to 0xdb6da000) [9.748781] 9c60: c07a68c8 db608a10 c07a4920 [9.757358] 9c80: db08bd70 db49b238 db608a10 db608a44 c1011b68 c07a64ac db608a18 db608a10 [9.765934] 9ca0: c1011b68 c07a599c db608a18 db608a10 c07a3a60 [9.774511] 9cc0: 60010013 dfa46780 db608a00 db608a10 dfa467cc [9.783088] 9ce0: db183410 c08b75dc dfa46780 0001 c08b7718 [9.791665] 9d00: 8000 db764640 c04f4c98 db03bdc0 22f3 db184088 c07a8560 [9.800241] 9d20: c11155d0 c0400180 db578088 dfa46780 dfa46574 db183410 [9.808819] 9d40: 0001 bf000278 c08b7b6c 0001 db57ef88 c0d2ab48 db183410 [9.817395] 9d60: db183400 bf000234 bf000234 0003 bf30 bf00 db183410 [9.825972] 9d80: fdfb c07a8578 c07a852c db183410 c112b990 c105bde0 c07a6670 [9.834549] 9da0: c07a8740 db183410 bf000234 db183410 bf000234 db183444 bf002000 [9.843125] 9dc0: c07a69a8 bf000234 c07a6914 c07a4870 db08bd5c db1734b4 [9.851703] 9de0: bf000234 db727a00 c1011b68 c07a5c78 bf000208 c04f5980 bf000234 bf000234 [9.860281] 9e00: c0f49a20 db330b80 db6d9e90 c07a7174 c0f49a20 c0f49a20 c0209c34 [9.868857] 9e20: dfe35b78 c0cd2e64 db194c80 dfe35b78 0008 dfa59000 [9.877434] 9e40: db6d9f18 c034ac1c 0007 dfe35b78 c848 c0379774 c02e0458 [9.886010] 9e60: 0002 db330b00 e083b000 bf000284 bf000284 db330b00 db6d9f54 db6d9e90 [9.894587] 9e80: db6d9f18 bf000278 c02e0494 8000 7fff c02dd32c db57d340 [9.903164] 9ea0: db57d340 e083b000 c0f455a4 bf000278 c1055360 0035 [9.911741] 9ec0: db6d9ee4 b6f50bac db6d9f5c db6d9f88 28ae 0002 81a4 [9.920317] 9ee0: 0001 [9.928894] 9f00: [9.937469] 9f20: 0007 b6f50bac 017b c021a848 db6d8000 1000 [9.946046] 9f40: 00d12058 c02e0a44 0002 db6d9f5c e083b000 13d8 e083be00 [9.954622] 9f60: e083b72f e083bba8 040c 04fc 001b [9.963200] 9f80: 001c 0014 0011 000d 00044640 [9.971776] 9fa0: c021a680 00044640 0007 b6f50bac [9.980352] 9fc0: 00044640 017b 0002 00d12058 [9.988929] 9fe0: bec55da8 bec55d98 b6f47114 b6e713b0 60010010 0007 975b1a3e 975b2a3e [9.997521] [] (__device_attach) from [] (bus_for_each_drv+0x60/0x94) [ 10.006102] [] (bus_for_each_drv) from [] (device_attach+0x7c/0x90) [ 10.014498] [] (device_attach) from [] (bus_probe_device+0x8c/0xb0) [ 10.022895] [] (bus_probe_device) from [] (device_add+0x3ac/0x568) [ 10.031209] [] (device_add) from [] (of_platform_device_create_pdata+0x7c/0xb0) [ 10.040702] [] (of_platform_device_create_pdata) from [] (of_platform_bus_create+0xf4/0x3bc) [ 10.051377] [] (of_platform_bus_create) from [] (of_platform_populate+0x64/0xb4) [ 10.060965] [] (of_platform_populate) from [] (am335x_child_probe+0x30/0x4c [musb_am335x]) [ 10.071466] [] (am335x_child_probe [musb_am335x]) from [] (platform_drv_probe+0x4c/0xac) [ 10.081777] [] (platform_drv_probe) from [] (driver_probe_device+0x154/0x3ac) [ 10.091084] [] (driver_probe_device) from [] (__driver_attach+0x94/0x98) [ 10.099936] [] (__driver_attach) from [] (bus_for_each_dev+0x68/0x9c) [ 10.108515] [] (bus_for_each_dev) from []
Re: [PATCH] usb: serial: Perform verification for FTDI FT232R devices
On 23.10.2014 12:52, russ.d...@gmail.com wrote: From: Russ Dill This patch provides the FTDI genuine product verification steps as contained within the new 2.12.00 official release. It ensures that counterfeiters don't exploit engineering investment made by FTDI. Counterfeit ICs are destroying innovation in the industry. FTDI recommends that to guarantee genuine FTDI products please purchase either from FTDI directly or an authorised distributor. This is definitely not targeting end users - if you're unsure if ICs are genuine then please don't use the drivers. Signed-off-by: Russ Dill By the way, have you tested it? -- 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: am335x musb_hdrc broken(?)
2014-09-17 19:46 GMT+04:00 Felipe Balbi : > On Wed, Sep 17, 2014 at 07:35:14PM +0400, Matwey V. Kornilov wrote: >> 2014-09-17 19:25 GMT+04:00 Felipe Balbi : >> > On Wed, Sep 17, 2014 at 10:46:57AM +0400, Matwey V. Kornilov wrote: >> >> 2014-09-16 22:39 GMT+04:00 Felipe Balbi : >> >> > Hi, >> >> > >> >> > (man, talk about trimming... leave some context ;-) >> >> > >> >> > On Tue, Sep 16, 2014 at 10:06:33PM +0400, Matwey V. Kornilov wrote: >> >> >> Ok. What is about musb_io.h? What does it mean "TUSB6010 doesn't allow >> >> >> 8-bit access; 16-bit access is the minimum."? >> >> > >> >> > it means that readb() won't work. >> >> > >> >> >> I think __raw_readb is kind of return *(u8_t*)(addr), but this is CPU >> >> >> stuff as far as I understand. >> >> > >> >> > tusb6010 is a discrete device connected through GPMC (general purpose >> >> > memory controller). Basically, this tells you that tusb6010 cannot >> >> > understand 8-bit accesses through gpmc. >> >> > >> >> >> >> So, I checked the stuff in musb_io.h and it doesn't work properly for >> >> my BBB. I don't know why. With this tusb6010-custom >> >> musb_readb/musb_writeb functions I am not able to mount USB flash >> >> drive (the device is being reset constantly, at the same time the >> >> webcam works fine). With __raw functions, it is fine. >> >> >> >> Do you have an idea how this could be refactored? >> > >> > can't think of a solution off the top of my head. >> >> Using musb->ops->readb everywhere will add too much overhead probably. > > correct :-) > > -- > balbi Could you please fix the Kconfig to prevent broken configurations until this fixed? -- With best regards, Matwey V. Kornilov http://blog.matwey.name xmpp://0x2...@jabber.ru -- 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: am335x musb_hdrc broken(?)
2014-09-17 19:25 GMT+04:00 Felipe Balbi : > On Wed, Sep 17, 2014 at 10:46:57AM +0400, Matwey V. Kornilov wrote: >> 2014-09-16 22:39 GMT+04:00 Felipe Balbi : >> > Hi, >> > >> > (man, talk about trimming... leave some context ;-) >> > >> > On Tue, Sep 16, 2014 at 10:06:33PM +0400, Matwey V. Kornilov wrote: >> >> Ok. What is about musb_io.h? What does it mean "TUSB6010 doesn't allow >> >> 8-bit access; 16-bit access is the minimum."? >> > >> > it means that readb() won't work. >> > >> >> I think __raw_readb is kind of return *(u8_t*)(addr), but this is CPU >> >> stuff as far as I understand. >> > >> > tusb6010 is a discrete device connected through GPMC (general purpose >> > memory controller). Basically, this tells you that tusb6010 cannot >> > understand 8-bit accesses through gpmc. >> > >> >> So, I checked the stuff in musb_io.h and it doesn't work properly for >> my BBB. I don't know why. With this tusb6010-custom >> musb_readb/musb_writeb functions I am not able to mount USB flash >> drive (the device is being reset constantly, at the same time the >> webcam works fine). With __raw functions, it is fine. >> >> Do you have an idea how this could be refactored? > > can't think of a solution off the top of my head. Using musb->ops->readb everywhere will add too much overhead probably. -- With best regards, Matwey V. Kornilov http://blog.matwey.name xmpp://0x2...@jabber.ru -- 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: am335x musb_hdrc broken(?)
2014-09-16 22:39 GMT+04:00 Felipe Balbi : > Hi, > > (man, talk about trimming... leave some context ;-) > > On Tue, Sep 16, 2014 at 10:06:33PM +0400, Matwey V. Kornilov wrote: >> Ok. What is about musb_io.h? What does it mean "TUSB6010 doesn't allow >> 8-bit access; 16-bit access is the minimum."? > > it means that readb() won't work. > >> I think __raw_readb is kind of return *(u8_t*)(addr), but this is CPU >> stuff as far as I understand. > > tusb6010 is a discrete device connected through GPMC (general purpose > memory controller). Basically, this tells you that tusb6010 cannot > understand 8-bit accesses through gpmc. > So, I checked the stuff in musb_io.h and it doesn't work properly for my BBB. I don't know why. With this tusb6010-custom musb_readb/musb_writeb functions I am not able to mount USB flash drive (the device is being reset constantly, at the same time the webcam works fine). With __raw functions, it is fine. Do you have an idea how this could be refactored? -- With best regards, Matwey V. Kornilov http://blog.matwey.name xmpp://0x2...@jabber.ru -- 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: am335x musb_hdrc broken(?)
Ok. What is about musb_io.h? What does it mean "TUSB6010 doesn't allow 8-bit access; 16-bit access is the minimum."? I think __raw_readb is kind of return *(u8_t*)(addr), but this is CPU stuff as far as I understand. -- With best regards, Matwey V. Kornilov http://blog.matwey.name xmpp://0x2...@jabber.ru -- 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: am335x musb_hdrc broken(?)
2014-09-16 21:25 GMT+04:00 Felipe Balbi : > we could, perhaps, pass a flag to change those offsets, but not a new > callback, I'm trying to get rid of some of them :-) We could have a tool musb_is_tusb(musb) (like dev_is_pci(dev)) instead of just a flag. But it is also a leakage in abstraction. I see also that void* private is required both by struct musb_hw_ep and struct musb. -- With best regards, Matwey V. Kornilov http://blog.matwey.name xmpp://0x2...@jabber.ru -- 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: am335x musb_hdrc broken(?)
2014-09-16 20:51 GMT+04:00 Felipe Balbi : > this can't be applied as it would break tusb6010. Sure. MUSB_FIFO_OFFSET is used only in musb_core_init to set endpoints. Can not understand whether endpoint setup can be moved to musb_platform_init. Or yet another callback to musb_platform_ops has to be introduced? -- With best regards, Matwey V. Kornilov http://blog.matwey.name xmpp://0x2...@jabber.ru -- 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: am335x musb_hdrc broken(?)
2014-09-10 23:50 GMT+04:00 Felipe Balbi : > hmmm, protocol error. Hi, I've found the root of the problem. CONFIG_USB_MUSB_TUSB6010=m affects the code inside musb_hdrc inspite of tusb6010 not loaded at all. When I disable CONFIG_USB_MUSB_TUSB6010 in my configuration, everything works fine. After the following modification, usb seems to be semi-working with CONFIG_USB_MUSB_TUSB6010=m. diff --git a/drivers/usb/musb/musb_regs.h b/drivers/usb/musb/musb_regs.h index 03f2655..a146b9a 100644 --- a/drivers/usb/musb/musb_regs.h +++ b/drivers/usb/musb/musb_regs.h @@ -234,12 +234,7 @@ #define MUSB_TESTMODE 0x0F/* 8 bit */ /* Get offset for a given FIFO from musb->mregs */ -#if defined(CONFIG_USB_MUSB_TUSB6010) || \ - defined(CONFIG_USB_MUSB_TUSB6010_MODULE) -#define MUSB_FIFO_OFFSET(epnum)(0x200 + ((epnum) * 0x20)) -#else #define MUSB_FIFO_OFFSET(epnum)(0x20 + ((epnum) * 4)) -#endif I am still testing, and suspect that musb_readb/musb_writeb stuff in musb_io.h is also the subject. The question is how to fix all this in correct way. -- With best regards, Matwey V. Kornilov http://blog.matwey.name xmpp://0x2...@jabber.ru -- 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: am335x musb_hdrc broken(?)
2014-09-11 0:32 GMT+04:00 Alan Stern : > If all else fails, git bisect might pinpoint the cause of the problem. > > Alan Stern > I would have need config bisect. -- With best regards, Matwey V. Kornilov http://blog.matwey.name xmpp://0x2...@jabber.ru -- 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: am335x musb_hdrc broken(?)
2014-09-10 19:53 GMT+04:00 Felipe Balbi : > you probably need a USB sniffer. usbmon (Documentation/usb/usbmon.txt) > will help to some extent, but some details can only be seen with a hw > sniffer. Hi To this moment I've found the following. Angstrom 3.8 works as expected, 3.16 also works until it wants GET_DESCRIPTOR. 3.8: dcbdd1c0 1596835984 S Ci:1:000:0 s 80 06 0100 0040 64 < dcbdd1c0 1596836075 C Ci:1:000:0 0 18 = 12010002 0040 fe132341 00010102 0301 3.16: dd063d00 3246071559 S Ci:2:000:0 s 80 06 0100 0040 64 < dd063d00 3246071607 C Ci:2:000:0 -71 0 I don't know why the ports enumeration is different, maybe this is due converting to dts. In the second case, usb_control_msg failed. And this error code comes from musb_h_ep0_irq function [ 2439.167419] musb-hdrc musb-hdrc.1.auto: qh de1a8d80 urb de3b7880 dev0 ep0out, hw_ep 0, de3a0500/8 [ 2439.176735] musb-hdrc musb-hdrc.1.auto: --> hw0 urb de3b7880 spd3 dev0 ep0out h_addr00 h_port00 bytes 8 [ 2439.186595] musb-hdrc musb-hdrc.1.auto: TX ep0 fifo e0dc4e00 count 8 buf de3a0500 [ 2439.19] musb-hdrc musb-hdrc.1.auto: Start TX0 pio [ 2439.199774] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb tx0001 rx [ 2439.206901] musb-hdrc musb-hdrc.1.auto: <== csr0 0010, qh de1a8d80, count 0, urb de3b7880, stage 1 [ 2439.216298] musb-hdrc musb-hdrc.1.auto: no response, csr0 0010 [ 2439.222414] musb-hdrc musb-hdrc.1.auto: aborting [ 2439.227458] musb-hdrc musb-hdrc.1.auto: complete de3b7880 usb_api_blocking_completion+0x0/0x1c [usbcore] (-71), dev0 ep0in, 0/64 This is similar to http://www.spinics.net/lists/linux-omap/msg106299.html (no explanation is given) However, I don't yet have an idea what is csr0 register for, and what is going on. :) -- With best regards, Matwey V. Kornilov http://blog.matwey.name xmpp://0x2...@jabber.ru -- 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: am335x musb_hdrc broken(?)
2014-09-10 17:52 GMT+04:00 Felipe Balbi : > Hi, > > On Wed, Sep 10, 2014 at 11:06:05AM +0400, Matwey V. Kornilov wrote: >> 2014-09-09 22:20 GMT+04:00 Felipe Balbi : >> > oh, so it's not really a BBB. I have never seen an EMBEST RevB3. Do you >> > have access to that board's accessory and/or a real BBB to check ? >> >> They claim it is just A5A. So, I've booted into Angstrom with kernel >> 3.8.6 (which is preinstalled on eMMC), and USB works perfectly. >> I can read my files on usb-drive, I can grab frames from my webcam and so on. >> Thereby, the issue is somewhere in my kernel (or config). However, could you provide me some hints how to debug it? -- With best regards, Matwey V. Kornilov http://blog.matwey.name xmpp://0x2...@jabber.ru -- 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: am335x musb_hdrc broken(?)
2014-09-09 22:20 GMT+04:00 Felipe Balbi : > oh, so it's not really a BBB. I have never seen an EMBEST RevB3. Do you > have access to that board's accessory and/or a real BBB to check ? They claim it is just A5A. So, I've booted into Angstrom with kernel 3.8.6 (which is preinstalled on eMMC), and USB works perfectly. I can read my files on usb-drive, I can grab frames from my webcam and so on. Thereby, the issue is somewhere in my kernel (or config). > Hmm, if your device draws more than 100mA, 4.7V is on the borderline. I > just checked my BBB and it's sourcing 5.046V when I attach a device > which draws 25 ~ 45 mA. Angstrom gives me the same 4.7V On the power input jack, there is 4.8V. I found no voltage regulators for 5V line on the board, so I think I just need to find other power supply. -- With best regards, Matwey V. Kornilov http://blog.matwey.name xmpp://0x2...@jabber.ru -- 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: am335x musb_hdrc broken(?)
2014-09-09 21:49 GMT+04:00 Felipe Balbi : > Hi, > > On Tue, Sep 09, 2014 at 09:16:50PM +0400, Matwey V. Kornilov wrote: >> I am still running 3.16.1 no BeagleBone Black and after I sorted out >> the configuration nothing oopses, but there is another problem. >> I can't attach any device (including but not limited to USB-hub with >> external power) to host USB (both when use_dma=1 or use_dma=0 is set) > > you're still doing something funny. I tested this yesterday and it works > on my BBB. What revision do you have ? Can you share full boot logs ? > From power on to failure. I have EMBEST Replica "RevB3". Please, find dmesg output here: http://susepaste.org/88577793 I've also measured voltage on USB (between GND and +) when the device is plugged in, it is 4.7V (not sure what does it mean). -- With best regards, Matwey V. Kornilov http://blog.matwey.name xmpp://0x2...@jabber.ru -- 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: OOPS: musb_hdrc
2014-09-09 20:09 GMT+04:00 Felipe Balbi : > On Tue, Sep 09, 2014 at 07:52:59PM +0400, Matwey V. Kornilov wrote: >> 2014-09-09 19:11 GMT+04:00 Felipe Balbi : >> > the proper way would be to move everything to dma_engine. OMAP already >> > has support for DMA engine and both CPPI and Ux500 are already using >> > that. >> >> If so, ux500_dma.c and musb_cppi41.c should be almost identically >> wrapping dmaengine, but they aren't. > > heh, the difference is mostly because ux500 supports scatter-gather > while cppi41 doesn't. That can be handled generically. The other > differences are due to silicon errata, and that should be hidden inside > DMA engine driver itself, not in MUSB. > That is, If I understand correctly, one may start from the other side. Firstly create musb_dmaengine.c using generic dmaengine API (not relying on hardware model) and providing private API and then drop one by one existing DMA implementations from musb. Eventually, only musb_dmaengine.c will be kept suitable for all kinds of drivers. -- With best regards, Matwey V. Kornilov http://blog.matwey.name xmpp://0x2...@jabber.ru -- 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: OOPS: musb_hdrc
2014-09-09 19:11 GMT+04:00 Felipe Balbi : > the proper way would be to move everything to dma_engine. OMAP already > has support for DMA engine and both CPPI and Ux500 are already using > that. If so, ux500_dma.c and musb_cppi41.c should be almost identically wrapping dmaengine, but they aren't. -- With best regards, Matwey V. Kornilov http://blog.matwey.name xmpp://0x2...@jabber.ru -- 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: OOPS: musb_hdrc
2014-09-09 18:45 GMT+04:00 Felipe Balbi : > On Tue, Sep 09, 2014 at 01:28:55PM +0400, Matwey V. Kornilov wrote: >> Hi George, >> >> Why dma_controller_create can not be set in struct musb_platform_ops? >> Then each module would be able to set dma_controller_create it wants, >> and musb_init_controller would use musb->ops->dma_controller_create >> instead of just dma_controller_create. > > patches are welcome :-) > Will the following approach be acceptable? 1. musbhsdma.o cppi_dma.o tusb6010_omap.o ux500_dma.o musb_cppi41.o became independent modules (tristate), each module exports two symbols: PREFIX_dma_controller_create and ..._destroy. 2. add two callbacks to musb_platform_ops, when pointers are NULL then no DMA is used 3. every module uses appropriate &PREFIX_dma_controller_create in its PREFIX_ops structure 4. musb_core uses wrappers which calls musb->ops->dma_controller_create and destroy In this case every DMA mode can be reused more by several drivers if necessarily. -- With best regards, Matwey V. Kornilov http://blog.matwey.name xmpp://0x2...@jabber.ru -- 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: OOPS: musb_hdrc
Hi George, Why dma_controller_create can not be set in struct musb_platform_ops? Then each module would be able to set dma_controller_create it wants, and musb_init_controller would use musb->ops->dma_controller_create instead of just dma_controller_create. 2014-09-09 13:15 GMT+04:00 Matwey V. Kornilov : > Hi George, > > Many thanks for the hint. Am I right that we can not have multiple > MUSB DMA modes within the same kernel? It is a pity. -- With best regards, Matwey V. Kornilov http://blog.matwey.name xmpp://0x2207@jabb -- 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: OOPS: musb_hdrc
Hi George, Many thanks for the hint. Am I right that we can not have multiple MUSB DMA modes within the same kernel? It is a pity. 2014-09-09 12:40 GMT+04:00 George Cherian : > Hi Matwey, > > > On 09/09/2014 01:58 PM, Matwey V. Kornilov wrote: >> >> Hi, >> >>>> Can you add a few printks around drivers/usb/musb/musb_cppi41.c to >>>> further narrow down where the problem is ? I ran v3.17-rc1 on my >>>> beaglebone black (a while back) and didn't have any issues. >> >> Now I am rebuilding the kernel to see where the problem is. >> >>> Are you sure you're running v3.16.1 vanilla ? I just tested on my end >>> and it's working fine. Please provide full boot logs including u-boot >>> all the way to the error scenario. >> >> I am sure that I am running 3.16.1 opensuse, where no patches >> affecting musb applied. Full log is quite big, please find it at >> http://susepaste.org/31032538 >> >>> attached you can find my logs (couldn't paste it anywhere as my test >>> case for mass storage devices outputs quite a bit of data) >> >> Could you please share your kernel config? My config is attached. > > Please set CONFIG_USB_TI_CPPI41_DMA=y and re-run your tests. > > -George -- With best regards, Matwey V. Kornilov http://blog.matwey.name xmpp://0x2...@jabber.ru -- 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
OOPS: musb_hdrc
Hi, Running 3.16.1 on beaglebone black, I have the following issue with musb_hdrc on boot: [ 11.151063] Unable to handle kernel paging request at virtual address e09bb05c [ 11.158774] pgd = de5d8000 [ 11.161613] [e09bb05c] *pgd=9e02d811, *pte=, *ppte= [ 11.168247] Internal error: Oops: 807 [#1] SMP ARM [ 11.173269] Modules linked in: musb_dsps(+) musb_hdrc udc_core davinci_mdio(+) mmc_block phy_am335x usbcore phy_am335x_control phy_generic usb_common ti_cpsw davinci_cpdma omap_hsmmc mmc_core musb_am335x [ 11.192315] CPU: 0 PID: 205 Comm: systemd-udevd Not tainted 3.16.1-2.g2ab6585-default #1 [ 11.200799] task: de58a080 ti: de5cc000 task.ti: de5cc000 [ 11.206541] PC is at dma_controller_create+0x18/0x120 [musb_hdrc] [ 11.212943] LR is at musb_probe+0x528/0x664 [musb_hdrc] [ 11.218420] pc : []lr : []psr: a013 [ 11.218420] sp : de5cdbf8 ip : de5ee8d8 fp : 0010 [ 11.230454] r10: r9 : 0003 r8 : de5ee810 [ 11.235930] r7 : 0023 r6 : de5ee800 r5 : de71aec0 r4 : de2ec010 [ 11.242771] r3 : e09ba800 r2 : 7fff r1 : e09b8c00 r0 : de2ec010 [ 11.249615] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 11.257096] Control: 10c5387d Table: 9e5d8019 DAC: 0015 [ 11.263118] Process systemd-udevd (pid: 205, stack limit = 0xde5cc250) [ 11.269959] Stack: (0xde5cdbf8 to 0xde5ce000) [ 11.274527] dbe0: de2ec010 de71aec0 [ 11.283102] dc00: de5ee800 0023 de5ee810 0003 bf125fec c0b21088 de71b5d8 [ 11.291678] dc20: 0001 de71b0d8 0010 de5ee810 bf134a84 c0ddfbc8 bf134a84 [ 11.300254] dc40: 0010 de5ee800 bf146760 c065a1bc c065a19c de5ee810 c0eaee3c c0658318 [ 11.308830] dc60: 1304 c065a2c8 bf134a84 de5ee810 c0658570 de5f1210 [ 11.317405] dc80: c06565d4 de0bff70 de79c7b8 de5ee810 de5ee844 c0d9c810 c0658154 [ 11.325981] dca0: de5ee818 de5ee810 c0d9c810 c0657648 de5ee818 de5ee810 c06557b4 [ 11.334558] dcc0: 8000 c0de8840 c0d35e54 de7f6f40 de5f1200 0002 de5ee800 de5ee810 [ 11.343134] dce0: de5f1200 de7f3790 dfadf0a0 c0659edc 0001 de5f1210 [ 11.351710] dd00: de5f1200 bf145ef4 bf146870 01f4 de01c901 25f0 0007 de71b6fa [ 11.360286] dd20: c0e97a00 de71af10 de71b628 bf146760 47401c00 47401fff c8005480 0200 [ 11.368861] dd40: 0023 0023 c80054a8 0400 [ 11.377436] dd60: 0010 de5f1210 bf14679c c0ddfbc8 bf14679c [ 11.386011] dd80: 0010 bf146870 c065a1bc c065a19c de5f1210 c0eaee3c c0658318 [ 11.394587] dda0: c065a2a8 de5f1210 bf14679c de5f1210 bf14679c de5f1244 bf149000 [ 11.403164] ddc0: de5cc020 c0658650 bf14679c c06585bc c0656524 de0bff5c de5924b4 [ 11.411739] dde0: bf14679c de79ce00 c0d9c810 c0657924 bf146664 c04df5e8 bf14679c bf14679c [ 11.420315] de00: c0cf1aa0 de7ed340 de5cdf18 c0658e14 c0cf1aa0 c0cf1aa0 c0209ab4 [ 11.428891] de20: c0ad03e8 c0ad03d4 c034195c c0cf1984 dfebf820 0008 [ 11.437467] de40: dfaf1000 c034338c 0007 dfebf820 c0e93d08 c036d8e0 [ 11.446043] de60: bf146870 0005 de7ed340 c036f26c 0005 de5cdf54 bf14687c [ 11.454618] de80: de5cdf18 de5cc018 bf146870 c02df0d8 8000 7fff [ 11.463194] dea0: c02dc1f4 c0390948 e09a6000 de5cdf18 c0ced560 b6e7fc80 [ 11.471770] dec0: e09a8880 00ae de5cdf5c de5cdf88 1c7e 0002 de5c81a4 [ 11.480344] dee0: 0001 [ 11.488919] df00: [ 11.497496] df20: de5cc000 000b b6e7fc80 017b c021b008 de5cc000 1000 [ 11.506071] df40: 009fadb0 c02df738 0002 de5cdf5c e09a6000 4b2e e09a8880 [ 11.514647] df60: e09a8707 e09a9928 1a04 1fb4 bf1467e0 0006 0023 [ 11.523223] df80: 0024 001b 0016 0012 0001 0001 [ 11.531798] dfa0: c021ae20 0001 0001 000b b6e7fc80 b6f1d370 [ 11.540374] dfc0: 0001 0001 017b 0002 009fadb0 [ 11.548949] dfe0: beeb12d8 beeb12c8 b6e76530 b6da66a0 60010010 000b [ 11.557582] [] (dma_controller_create [musb_hdrc]) from [] (musb_probe+0x528/0x664 [musb_hdrc]) [ 11.568554] [] (musb_probe [musb_hdrc]) from [] (platform_drv_probe+0x20/0x50) [ 11.577969] [] (platform_drv_probe) from [] (driver_probe_device+0x154/0x3ac) [ 11.587278] [] (driver_probe_device) from [] (bus_for_each_drv+0x60/0x94) [ 11.596221] [] (bus_for_each_drv) from [] (device_attach+0x7c/0x90) [ 11.604617] [] (device_attach) from [] (bus_probe_device+0x8c/0xb0) [ 11.613013] [] (bus_probe_device) from [] (device_add+0x45c/0x578) [ 11.621317] [] (devic
[PATCH 1/2] Add tusb_revision to struct musb to store the revision.
From 0bd8c14855eeb049f49685f36386750a999078a3 Mon Sep 17 00:00:00 2001
From: "Matwey V. Kornilov"
Date: Fri, 9 May 2014 15:52:00 +0400
Subject: [PATCH 1/2] Add tusb_revision to struct musb to store the revision.
Add field to store tusb6010 revision value. Read the revision at
the startup and store to the variable.
Signed-off-by: Matwey V. Kornilov
---
drivers/usb/musb/musb_core.h | 1 +
drivers/usb/musb/tusb6010.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 7083e82..d7dea2f 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -337,6 +337,7 @@ struct musb {
dma_addr_t async;
dma_addr_t sync;
void __iomem*sync_va;
+ u8 tusb_revision;
#endif
/* passed down from chip/board specific irq handlers */
diff --git a/drivers/usb/musb/tusb6010.c b/drivers/usb/musb/tusb6010.c
index 4e9fb1d..81fa8fd 100644
--- a/drivers/usb/musb/tusb6010.c
+++ b/drivers/usb/musb/tusb6010.c
@@ -1011,6 +1011,7 @@ static int tusb_musb_start(struct musb *musb)
goto err;
}
+ musb->tusb_revision = tusb_get_revision(musb);
ret = tusb_print_revision(musb);
if (ret < 2) {
printk(KERN_ERR "tusb: Unsupported TUSB6010 revision %i\n",
--
1.8.1.4
--
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/2] Use musb->tusb_revision instead of tusb_get_revision call.
From e24375ea6aefe2ad1ee72b8facab91abd1be190a Mon Sep 17 00:00:00 2001
From: "Matwey V. Kornilov"
Date: Fri, 9 May 2014 16:10:16 +0400
Subject: [PATCH 2/2] Use musb->tusb_revision instead of tusb_get_revision call.
The value of the revision is stored in musb->tusb_revision,
so don't re-read it every time.
Exporting tusb_get_revision is not needed anymore,
so the dependency loop between tusb6010 and tusb6010_omap is resolved.
Signed-off-by: Matwey V. Kornilov
---
drivers/usb/musb/tusb6010.c | 19 ---
drivers/usb/musb/tusb6010.h | 2 --
drivers/usb/musb/tusb6010_omap.c | 2 +-
3 files changed, 9 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/musb/tusb6010.c b/drivers/usb/musb/tusb6010.c
index 81fa8fd..d49415c 100644
--- a/drivers/usb/musb/tusb6010.c
+++ b/drivers/usb/musb/tusb6010.c
@@ -42,7 +42,7 @@ static void tusb_musb_set_vbus(struct musb *musb, int is_on);
* Checks the revision. We need to use the DMA register as 3.0 does not
* have correct versions for TUSB_PRCM_REV or TUSB_INT_CTRL_REV.
*/
-u8 tusb_get_revision(struct musb *musb)
+static u8 tusb_get_revision(struct musb *musb)
{
void __iomem*tbase = musb->ctrl_base;
u32 die_id;
@@ -58,14 +58,13 @@ u8 tusb_get_revision(struct musb *musb)
return rev;
}
-EXPORT_SYMBOL_GPL(tusb_get_revision);
-static int tusb_print_revision(struct musb *musb)
+static void tusb_print_revision(struct musb *musb)
{
void __iomem*tbase = musb->ctrl_base;
u8 rev;
- rev = tusb_get_revision(musb);
+ rev = musb->tusb_revision;
pr_info("tusb: %s%i.%i %s%i.%i %s%i.%i %s%i.%i %s%i %s%i.%i\n",
"prcm",
@@ -84,8 +83,6 @@ static int tusb_print_revision(struct musb *musb)
TUSB_DIDR1_HI_CHIP_REV(musb_readl(tbase, TUSB_DIDR1_HI)),
"rev",
TUSB_REV_MAJOR(rev), TUSB_REV_MINOR(rev));
-
- return tusb_get_revision(musb);
}
#define WBUS_QUIRK_MASK(TUSB_PHY_OTG_CTRL_TESTM2 |
TUSB_PHY_OTG_CTRL_TESTM1 \
@@ -349,7 +346,7 @@ static void tusb_allow_idle(struct musb *musb, u32
wakeup_enables)
u32 reg;
if ((wakeup_enables & TUSB_PRCM_WBUS)
- && (tusb_get_revision(musb) == TUSB_REV_30))
+ && (musb->tusb_revision == TUSB_REV_30))
tusb_wbus_quirk(musb, 1);
tusb_set_clock_source(musb, 0);
@@ -797,7 +794,7 @@ static irqreturn_t tusb_musb_interrupt(int irq, void *__hci)
u32 reg;
u32 i;
- if (tusb_get_revision(musb) == TUSB_REV_30)
+ if (musb->tusb_revision == TUSB_REV_30)
tusb_wbus_quirk(musb, 0);
/* there are issues re-locking the PLL on wakeup ... */
@@ -1012,10 +1009,10 @@ static int tusb_musb_start(struct musb *musb)
}
musb->tusb_revision = tusb_get_revision(musb);
- ret = tusb_print_revision(musb);
- if (ret < 2) {
+ tusb_print_revision(musb);
+ if (musb->tusb_revision < 2) {
printk(KERN_ERR "tusb: Unsupported TUSB6010 revision %i\n",
- ret);
+ musb->tusb_revision);
goto err;
}
diff --git a/drivers/usb/musb/tusb6010.h b/drivers/usb/musb/tusb6010.h
index 35c933a..3d40c63 100644
--- a/drivers/usb/musb/tusb6010.h
+++ b/drivers/usb/musb/tusb6010.h
@@ -12,8 +12,6 @@
#ifndef __TUSB6010_H__
#define __TUSB6010_H__
-extern u8 tusb_get_revision(struct musb *musb);
-
#ifdef CONFIG_USB_TUSB6010
#define musb_in_tusb() 1
#else
diff --git a/drivers/usb/musb/tusb6010_omap.c b/drivers/usb/musb/tusb6010_omap.c
index e33b6b2..3ce152c 100644
--- a/drivers/usb/musb/tusb6010_omap.c
+++ b/drivers/usb/musb/tusb6010_omap.c
@@ -677,7 +677,7 @@ struct dma_controller *dma_controller_create(struct musb
*musb, void __iomem *ba
tusb_dma->controller.channel_program = tusb_omap_dma_program;
tusb_dma->controller.channel_abort = tusb_omap_dma_abort;
- if (tusb_get_revision(musb) >= TUSB_REV_30)
+ if (musb->tusb_revision >= TUSB_REV_30)
tusb_dma->multichannel = 1;
for (i = 0; i < MAX_DMAREQ; i++) {
--
1.8.1.4
--
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/2] Fix dependency loop in tusb6010
From: "Matwey V. Kornilov" Subject: [PATCH 0/2] Fix dependency loop in tusb6010 With the following configure options, musb_hdrc and tusb6010 make dependency loop: CONFIG_USB_MUSB_HDRC=m CONFIG_USB_MUSB_TUSB6010=m CONFIG_USB_TUSB_OMAP_DMA=y tusb6010.ko provides function `tusb_get_revision` which is used by tusb6010_omap.o which is a part of musb_hdrc.ko In its turn, tusb6010.ko uses much of functions provided by musb_hdrc.ko The following patches are to solve the issue. Signed-off-by: Matwey V. Kornilov -- 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: musb_hdrc and tusb6010 loop
01.05.2014 23:51, Felipe Balbi пишет: I don't think you need that. Have tusb_get_revision() run only one during tusb6010 probe/init function and cache the returned value inside musb->revision or something like that, then remove all other calls to tusb_get_revision() and have tusb6010_omap.c check revision using if (musb->revision >= TUSB_REV30) and your problem is solved. Do you think that it is possible to add another tusb6010-specific field to struct musb, which seems to be general interface? -- 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: musb_hdrc and tusb6010 loop
01.05.2014 23:40, Felipe Balbi пишет: Hi, On Thu, May 01, 2014 at 11:13:19PM +0400, Matwey V. Kornilov wrote: Hi, With the following configure options, musb_hdrc and tusb6010 make dependency loop: CONFIG_USB_MUSB_HDRC=m CONFIG_USB_MUSB_TUSB6010=m CONFIG_USB_TUSB_OMAP_DMA=y tusb6010.ko provides function `tusb_get_revision` which is used by tusb6010_omap.o which is a part of musb_hdrc.ko In its turn, tusb6010.ko uses much of functions provided by musb_hdrc.ko What could be a solution to this? don't let tusb6010_omap use any symbols from tusb6010.ko. the _omap variant is just an adapter for the private DMA API (should be moved to dmaengine, actually) and as such, it shouldn't know details about tusb6010 (which doesn't exactly depend on the underlying DMA). This is possible when `tusb_get_revision` is static inline function. Then we would have to copies of `tusb_get_revision`: in tusb6010.ko, and in musb_hdrc.ko (tusb6010_omap.o) -- 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
musb_hdrc and tusb6010 loop
Hi, With the following configure options, musb_hdrc and tusb6010 make dependency loop: CONFIG_USB_MUSB_HDRC=m CONFIG_USB_MUSB_TUSB6010=m CONFIG_USB_TUSB_OMAP_DMA=y tusb6010.ko provides function `tusb_get_revision` which is used by tusb6010_omap.o which is a part of musb_hdrc.ko In its turn, tusb6010.ko uses much of functions provided by musb_hdrc.ko What could be a solution to this? -- 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: cp210x new Vendor/Device IDs
From: Matwey V. Kornilov
This patch adds support for the Lake Shore Cryotronics devices to
the CP210x driver.
Signed-off-by: Matwey V. Kornilov
---
These lines are ported from cp210x driver distributed by Lake Shore web site:
http://www.lakeshore.com/Documents/Lake%20Shore%20cp210x-3.0.0.tar.gz
and licensed under the terms of GPLv2.
Moreover, I've tested this changes with Lake Shore 335 in my labs.
This patch is based on linux/kernel/git/gregkh/usb.git tree.
p.s Sorry for 80-column overflow, but I don't know how to format this comments
more concinnous.
diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
index edc0f0d..67088ce 100644
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -150,6 +150,25 @@ static const struct usb_device_id id_table[] = {
{ USB_DEVICE(0x1BE3, 0x07A6) }, /* WAGO 750-923 USB Service Cable */
{ USB_DEVICE(0x1E29, 0x0102) }, /* Festo CPX-USB */
{ USB_DEVICE(0x1E29, 0x0501) }, /* Festo CMSP */
+ { USB_DEVICE(0x1FB9, 0x0100) }, /* Lake Shore Model 121 Current Source
*/
+ { USB_DEVICE(0x1FB9, 0x0200) }, /* Lake Shore Model 218A Temperature
Monitor */
+ { USB_DEVICE(0x1FB9, 0x0201) }, /* Lake Shore Model 219 Temperature
Monitor */
+ { USB_DEVICE(0x1FB9, 0x0202) }, /* Lake Shore Model 233 Temperature
Transmitter */
+ { USB_DEVICE(0x1FB9, 0x0203) }, /* Lake Shore Model 235 Temperature
Transmitter */
+ { USB_DEVICE(0x1FB9, 0x0300) }, /* Lake Shore Model 335 Temperature
Controller */
+ { USB_DEVICE(0x1FB9, 0x0301) }, /* Lake Shore Model 336 Temperature
Controller */
+ { USB_DEVICE(0x1FB9, 0x0302) }, /* Lake Shore Model 350 Temperature
Controller */
+ { USB_DEVICE(0x1FB9, 0x0303) }, /* Lake Shore Model 371 AC Bridge */
+ { USB_DEVICE(0x1FB9, 0x0400) }, /* Lake Shore Model 411 Handheld
Gaussmeter */
+ { USB_DEVICE(0x1FB9, 0x0401) }, /* Lake Shore Model 425 Gaussmeter */
+ { USB_DEVICE(0x1FB9, 0x0402) }, /* Lake Shore Model 455A Gaussmeter */
+ { USB_DEVICE(0x1FB9, 0x0403) }, /* Lake Shore Model 475A Gaussmeter */
+ { USB_DEVICE(0x1FB9, 0x0404) }, /* Lake Shore Model 465 Three Axis
Gaussmeter */
+ { USB_DEVICE(0x1FB9, 0x0600) }, /* Lake Shore Model 625A
Superconducting MPS */
+ { USB_DEVICE(0x1FB9, 0x0601) }, /* Lake Shore Model 642A Magnet Power
Supply */
+ { USB_DEVICE(0x1FB9, 0x0602) }, /* Lake Shore Model 648 Magnet Power
Supply */
+ { USB_DEVICE(0x1FB9, 0x0700) }, /* Lake Shore Model 737 VSM Controller
*/
+ { USB_DEVICE(0x1FB9, 0x0701) }, /* Lake Shore Model 776 Hall Matrix */
{ USB_DEVICE(0x3195, 0xF190) }, /* Link Instruments MSO-19 */
{ USB_DEVICE(0x3195, 0xF280) }, /* Link Instruments MSO-28 */
{ USB_DEVICE(0x3195, 0xF281) }, /* Link Instruments MSO-28 */
--
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
