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 behav
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
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?
Alan Stern
--
To unsubscri
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_ur
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 behaviou
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 overf
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 processi
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 l
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. Ko
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 */
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
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
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 a
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
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 i
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:
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
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 i
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 intent
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 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,
>>
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 +0
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,
>>
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 +0
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:
>>>
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 (047
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
> >> Beagl
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 runnin
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
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
fra
31 matches
Mail list logo
