Am Dienstag 14 April 2009 16:47:19 schrieb Boris Borisov: > Josua Grawitter wrote: > > Am Montag 13 April 2009 19:47:24 schrieb Brian Johnson: > >> Bulk is sometimes useful for USB 1.1 were you have lower bandwidth > >> available. But yeah we shouldn't bother scanning the entire packet in > >> isoc mode as its not necessary at all. > >> > >> This patch has now been pushed out to the repo. > >> > >> 2009/4/12 Boris Borisov <[email protected]>: > >>> The bulk transfer and search in big stream is very hard task for > >>> processor. It is realy necesery to have bulk transfer? > >>> See my new proposal for patch. > >>> > >>> Brian Johnson wrote: > >>>> This code is necessary for bulk transfers since when using bulk mode > >>>> the header is not sent in a seperate packet by itself but is found > >>>> inside a larger bulk packet. however sicne when using isoc which is > >>>> the default the header is always a single 64 byte packet it should be > >>>> ok to run that scan only if you currently have bulk mode enabled. > >>>> > >>>> 2009/4/12 Boris Borisov <[email protected]>: > >>>>> Hello, > >>>>> The hunger function is detect start of frame, because is perform many > >>>>> comparation if received buffer is large than 64 bytes. > >>>>> See the patch > >>> > >>> snip > >>> > >>> > >>> > >>> diff --git a/sn9c20x-usb.c b/sn9c20x-usb.c > >>> index 4e7f1c7..ecec38d 100644 > >>> --- a/sn9c20x-usb.c > >>> +++ b/sn9c20x-usb.c > >>> @@ -501,12 +501,17 @@ int usb_sn9c20x_detect_frame(unsigned char *buf, > >>> unsigned int buf_length) else > >>> return -1; > >>> } > >>> - for (index = 0; index < buf_length - 63; index++) { > >>> - if (memcmp(buf + index, frame_header, 6) == 0) { > >>> - UDIA_DEBUG("Found Header at %d\n", index); > >>> - return index; > >>> - } > >>> - } > >>> + > >>> + if(bulk) > >>> + { > >>> + for (index = 0; index < buf_length - 63; index++) { > >>> + if (memcmp(buf + index, frame_header, 6) == 0) { > >>> + UDIA_DEBUG("Found Header at %d\n", index); > >>> + return index; > >>> + } > >>> + } > >>> + } > >>> + > >>> return -1; > >>> } > > > > Unfortunatly this didn't fix my problem either. > > > > I start to wonder if the problem is caused mplayer and not our driver. > > > > GWater > > > > BTW: Has anyone here experience with the linux HID-subsystem? > > This patch fix the processor load for isoc transfer. On my system from > 99% go to ~7% without libv4l (mean cat /dev/video0 > /dev/null) and ~50% > with libv4l. The jpeg format is loses bytes and picture is very poor > (flicker and lost synchronization). On all of my tests with mplayer and > bulk patch in isoc mode performance is ~70%. > > --~--~---------~--~----~------------~-------~--~----~ > Lets make microdia webcams plug'n play, (currently plug'n pray) > To post to this group, send email to [email protected] > Visit us online https://groups.google.com/group/microdia > -~----------~----~----~----~------~----~------~--~---
The lcok-ups must be caused by mplayer: VLC consumes ~30% of CPU under the same conditions. While the framerate is still low at 640x480 this doesn't bother the system - it only looks ugly. So we're fine. Are there anymore showstoppers for 2.6.31? Maybe one last call for testing? (BTW isn't the modern way to make send a git-pull request to the maintainer rather than sending patches?) GWater
signature.asc
Description: This is a digitally signed message part.
