Here is the patch. The difference is that now soft-AE checks if we are already at maximal/minimal exposure and exits if that's the case. There are some hardcoded values for what I call maximal/minimal exposure that are working for me, and I hope they will not cause any problem, but I'll be grateful if someone from the developers inspect the changes as they are only 10 lines of code.
And I must note - soft-AE is still called - it's just exiting faster if there is nothing useful to do - as I have no idea who is the caller I may be missing some potential speedup. Regards Stefan 2009/3/28 Stefan Krastanov <[email protected]> > I made some test on the soft-AE and it seems it may be part of the problem. > > I edited it so it writes to dmesg every time it changes the exposure level. > Here are the results: > > for origin/HEAD: > normal use - 15 changes for 20 seconds > a bit more light than normal - 8 changes for 20 seconds > extreme luminosity(a lamp in front of the cam) - 137 changes for 20 > seconds > > with hue_sat.patch: > normal use - 11 times for 20 seconds > a bit more light than normal - 11 changes for 20 seconds > extreme luminosity(a lamp in front of the cam) - 450 changes for 20 > seconds > > Although the test are not quite scientific I believe it's clear that > soft-AE is not working well with extreme luminosities(and probably in > darkness we'll have the same problem) and that the hue-sat.patch is making > it a bit worser. > > I hour or two I'll send a patch to address the problem, sorry for the > inconvinience that I created. > > There was another problem with the hue-sat.patch - two times my laptop > hanged when inserting the usb cable from the camera and dmesg complained > about not being able to do something with register 1005 or something like > that. Exuse me for the inexact report but I needed to reboot and was unable > to save the dmesg nor to reproduce the problem > > Best regards > Stefan > > 2009/3/28 GWater <[email protected]> > > >> I just tested a bit more and it seems the performance problem is >> already in origin/masterHEAD~2 (http://repo.or.cz/w/microdia.git? >> a=commitdiff;h=9c5f82199c365e847906919af0f3b985fbc1696a<http://repo.or.cz/w/microdia.git?%0Aa=commitdiff;h=9c5f82199c365e847906919af0f3b985fbc1696a>). >> Although >> there was no lockup there was one very interesting thing: >> Framerate drops visibly when the camera input gets brighter. When the >> sensor adapts (via AEC or AGC) the framarate stabilizes. If that >> doesn't work the framerate stays low and mplayer gets upset. >> The only few reasons for a lockup under these circumstances are: The >> USB-subsystem deosn't like empty isochronous pipes. Or soft-AE has >> some side effect when it gets a very bright frame (BTW I don't use it >> - this is just the avgy calculation). OR fglrx is crappy (whoo - we >> didn't know that!). >> >> Anyway I propose the following: >> We investigate this issue further but in the meantime the saturation >> patch goes into the repo. It maybe put the cream on top of some >> performance problem but the real cause is most likely somewhere else. >> >> The question is: >> To be or not to submit for 2.6.30 now? Maybe staging? >> >> GWater >> >> On 28 Mrz., 11:14, GWater <[email protected]> wrote: >> > I tested and I finally got something to show you: >> > >> > $ dmesg >> > sn9c20x: SN9C20X USB 2.0 Webcam - 0C45:624E plugged- >> > in. >> > sn9c20x: Detected SOI968 >> > Sensor. >> > sn9c20x: Webcam device 0C45:624E is now controlling video device /dev/ >> > video0 >> > input: SN9C20X Webcam as /devices/pci0000:00/0000:00:02.1/usb1/1-4/ >> > input/ >> > input6 >> > sn9c20x: Hue Value: >> > 180 >> > sn9c20x: Hue vsettings.hue: >> > 0 >> > sn9c20x: Hue Value: >> > 180 >> > sn9c20x: Hue vsettings.hue: >> > 0 >> > sn9c20x: Using yuv420 output >> > format >> > usbcore: registered new interface driver >> > sn9c20x >> > sn9c20x: SN9C20x USB 2.0 Webcam Driver v2009.01 >> > loaded >> > sn9c20x: Hue Value: >> > 180 >> > sn9c20x: Hue vsettings.hue: >> > 0 >> > sn9c20x: Hue Value: >> > 180 >> > sn9c20x: Hue vsettings.hue: >> > 0 >> > BUG: soft lockup - CPU#0 stuck for 62s! [kondemand/ >> > 0:1568] >> > Modules linked in: sn9c20x fuse it87 hwmon_vid ipv6 >> > nf_conntrack_netbios_ns cpufreq_ondemand powernow_k8 freq_table >> > dm_multipath uinput ppdev radio_gemtek_pci snd_seq_dummy snd_hda_intel >> > snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss >> > snd_mixer_oss snd_pcm snd_timer snd_page_alloc snd_hwdep k8temp >> > radio_maxiradio snd hwmon firewire_ohci compat_ioctl32 firewire_core >> > videodev fglrx(P) pcspkr crc_itu_t pata_amd forcedeth v4l1_compat >> > soundcore parport_pc parport i2c_nforce2 i2c_core ata_generic >> > pata_acpi sata_nv [last unloaded: >> > scsi_wait_scan] >> > CPU >> > 0: >> > Modules linked in: sn9c20x fuse it87 hwmon_vid ipv6 >> > nf_conntrack_netbios_ns cpufreq_ondemand powernow_k8 freq_table >> > dm_multipath uinput ppdev radio_gemtek_pci snd_seq_dummy snd_hda_intel >> > snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss >> > snd_mixer_oss snd_pcm snd_timer snd_page_alloc snd_hwdep k8temp >> > radio_maxiradio snd hwmon firewire_ohci compat_ioctl32 firewire_core >> > videodev fglrx(P) pcspkr crc_itu_t pata_amd forcedeth v4l1_compat >> > soundcore parport_pc parport i2c_nforce2 i2c_core ata_generic >> > pata_acpi sata_nv [last unloaded: >> > scsi_wait_scan] >> > Pid: 1568, comm: kondemand/0 Tainted: P >> > 2.6.27.19-170.2.35.fc10.x86_64 >> > #1 >> > RIP: 0010:[<ffffffff8123c5d7>] [<ffffffff8123c5d7>] usb_hcd_irq >> > +0xa1/0xb3 >> > RSP: 0018:ffffffff8170ec98 EFLAGS: >> > 00000292 >> > RAX: ffff88003d13b920 RBX: ffffffff8170ecb8 RCX: >> > 00000000000006d0 >> > RDX: 00000000ffffffff RSI: 0000000000000000 RDI: >> > 0000000000000292 >> > RBP: ffffffff8170ec10 R08: ffff88001a9f2800 R09: >> > ffff8800178666a0 >> > R10: 0000000014c88000 R11: ffff880017867000 R12: >> > ffffffff81011408 >> > R13: ffffffff8170ec10 R14: 0000000000000001 R15: >> > ffff88003d13b800 >> > FS: 00007f062e769950(0000) GS:ffffffff81717000(0000) knlGS: >> > 00000000f7f2b710 >> > CS: 0010 DS: 0018 ES: 0018 CR0: >> > 000000008005003b >> > CR2: 00007f6a96197000 CR3: 000000001b8cc000 CR4: >> > 00000000000006e0 >> > DR0: 0000000000000000 DR1: 0000000000000000 DR2: >> > 0000000000000000 >> > DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: >> > 0000000000000400 >> > >> > Call Trace: >> > <IRQ> [<ffffffff81082b1f>] ? handle_IRQ_event+0x33/0x6f >> > [<ffffffff81083f12>] ? handle_fasteoi_irq+0xa5/0xeb >> > [<ffffffff810130ce>] ? do_IRQ+0xf7/0x169 >> > [<ffffffff81010963>] ? ret_from_intr+0x0/0x2e >> > [<ffffffff81333b70>] ? _spin_unlock_irqrestore+0x33/0x3e >> > [<ffffffff8103a6bf>] ? try_to_wake_up+0x271/0x283 >> > [<ffffffff81010a37>] ? restore_args+0x0/0x30 >> > [<ffffffff8104b388>] ? process_timeout+0x0/0xb >> > [<ffffffff8103a6fd>] ? wake_up_process+0x10/0x12 >> > [<ffffffff8104b391>] ? process_timeout+0x9/0xb >> > [<ffffffff8104b0c6>] ? run_timer_softirq+0x19c/0x222 >> > [<ffffffffa004830f>] ? nv_nic_irq_optimized+0xbd/0x277 [forcedeth] >> > [<ffffffff81046c82>] ? __do_softirq+0x7e/0x10c >> > [<ffffffff81011bfc>] ? call_softirq+0x1c/0x28 >> > [<ffffffff81012e02>] ? do_softirq+0x4d/0xb0 >> > [<ffffffff81046857>] ? irq_exit+0x4e/0x9d >> > [<ffffffff8101311e>] ? do_IRQ+0x147/0x169 >> > [<ffffffff81010963>] ? ret_from_intr+0x0/0x2e >> > <EOI> [<ffffffff81016fc3>] ? native_read_tsc+0xc/0x22 >> > [<ffffffff8116df60>] ? delay_tsc+0x26/0x58 >> > [<ffffffff8116dff6>] ? __const_udelay+0x47/0x49 >> > [<ffffffff8116e008>] ? __udelay+0x10/0x12 >> > [<ffffffffa03f65df>] ? decrease_vid_code_by_step+0x33/0x3b >> > [powernow_k8] >> > [<ffffffffa03f6b61>] ? powernowk8_target+0x47d/0x8b5 [powernow_k8] >> > [<ffffffff812857c3>] ? __cpufreq_driver_target+0x64/0x74 >> > [<ffffffffa03fe751>] ? do_dbs_timer+0x1cb/0x235 [cpufreq_ondemand] >> > [<ffffffffa03fe586>] ? do_dbs_timer+0x0/0x235 [cpufreq_ondemand] >> > [<ffffffff81051c85>] ? run_workqueue+0xa3/0x146 >> > [<ffffffff81051e1d>] ? worker_thread+0xf5/0x109 >> > [<ffffffff8105553d>] ? autoremove_wake_function+0x0/0x38 >> > [<ffffffff81051d28>] ? worker_thread+0x0/0x109 >> > [<ffffffff810551f7>] ? kthread+0x49/0x76 >> > [<ffffffff81011719>] ? child_rip+0xa/0x11 >> > [<ffffffff81010a37>] ? restore_args+0x0/0x30 >> > [<ffffffff810551ae>] ? kthread+0x0/0x76 >> > [<ffffffff8101170f>] ? child_rip+0x0/0x11 >> > >> > hda-intel: IRQ timing workaround is activated for card #0. Suggest a >> > bigger bdl_pos_adj. >> > sn9c20x: [E] Empty buffer queue. >> > sn9c20x: Hue Value: 180 >> > sn9c20x: Hue vsettings.hue: 0 >> > sn9c20x: Hue Value: 180 >> > sn9c20x: Hue vsettings.hue: 0 >> > >> > (So, yes the system still locks up. This time I didn't even attempt to >> > set saturation. I suspect mplayer is sending ioctl by itself.) >> > >> > GWater >> > >> > On 28 Mrz., 07:16, Boris Borisov <[email protected]> wrote: >> > >> > > 3 times OK from me >> > >> > > Brian Johnson wrote: >> > > > ah was not aware that some chips didn't like setting spme of the >> color >> > > > matrix independently. >> > >> > > > Updated version that adds the 21byte array into the sn9c20x_video >> > > > struct so we can still sett the whole thing at once. >> > >> > > > 2009/3/27 Boris Borisov <[email protected]>: >> > >> > > >> Freezing on my camera the version of my bridge maybe is lowest. No >> way for >> > > >> detection of version of bridge. All parameters (21 parameters from >> 10e1)must >> > > >> be set at once for prevent of similar problem during iso transfer >> (I don't >> > > >> know why perhaps some engine bug). That is the main problem. >> > > >> On other one more new camera (same model 6270) is working. >> > > >> I check with 3 different (as producer but same as model) cameras 2 >> is OK 1 >> > > >> is NOK camera engine is freezing. >> > >> > > >> Brian Johnson wrote: >> > >> > > >> Here is a somewhat updated version of this patch that does >> > > >> successfully break hue/sat, contrast and brightness up into >> separate >> > > >> functions and seems to work fine. Don't know if it will actually >> help >> > > >> with the freezing when settings lower satuation that Joshua was >> > > >> experiencing. It also fixes a few other minor issues like >> accidentally >> > > >> undoing a few previous commits, making RX, RY, etc static, and >> adding >> > > >> hue as a module param. >> > >> > > >> On Fri, Mar 27, 2009 at 1:50 PM, Brian Johnson <[email protected]> >> wrote: >> > >> > > >> I didn't look too much at why the global static array is not >> working, >> > > >> however you really do not want to use one here because it will >> cause >> > > >> problems the first time you try to have the driver handle two >> > > >> different sn9c20x webcams. It would probably be better to add it to >> > > >> maybe to the sn9c20x_video struct. Also not sure the array has to >> be >> > > >> pre initialized either since given the first time you set >> > > >> brightness,contrast,etc it will be filled out properly and we will >> do >> > > >> this when the camera is initialized. >> > >> > > >> 2009/3/27 Boris Borisov <[email protected]>: >> > >> > > >> I do some investigation of function set_optical_parameters as I >> transfer >> > > >> execution of instruction into user space and disassemble the >> program. >> > > >> For reference I use cycle execution of i486 worst case (is possible >> for >> > > >> some instruction to not get the correct cycles but as estimation is >> good >> > > >> start). >> > > >> Possible optimization: >> > > >> 1. Define __u8 optical_parameters[21] as global static - I try but >> > > >> always the values is not save on this global static array - What I >> do >> > > >> wrong ??? Pleas for some idea about __u8 optical_parameters[21] >> (see in >> > > >> patch what i want to do with this array ) ??? For first time global >> > > >> initialization of array is not work for me ??? >> > > >> If this array going into global space as static the functions can >> split >> > > >> into small parts for Brightness, Contrast, HUE-Saturation >> > >> > > >> 2. Possible optimization of calculation multiplying and dividing I >> can >> > > >> replace with logic operation and reanalyze execution time. >> > >> > > >> 3. As total execution calculation of RGB matrix parameters is not >> get >> > > >> too much microprocessor time (near to sn9c20x_set_gamma - too many >> > > >> multiplication and dividing ). Maybe other often call code get this >> time. >> > >> > > >> diff --git a/sn9c20x-bridge.c b/sn9c20x-bridge.c >> > > >> index f5d77b8..b4c3212 100644 >> > > >> --- a/sn9c20x-bridge.c >> > > >> +++ b/sn9c20x-bridge.c >> > > >> @@ -30,8 +30,312 @@ >> > > >> #include "sn9c20x.h" >> > > >> #include "sn9c20x-bridge.h" >> > >> > > >> + >> > > >> + >> > > >> +/** >> > > >> + * @var RX >> > > >> + * Coordinate X aray for eliptic HSV corrections, conditionaly >> Red pixel >> > > >> + */ >> > > >> +const int RX[] = {41, 44, 46, 48, 50, 52, 54, 56, >> > > >> + 58, 60, 62, 64, 66, 68, 70, 72, >> > > >> + 74, 76, 78, 80, 81, 83, 85, 87, >> > > >> + 88, 90, 92, 93, 95, 97, 98, 100, >> > > >> + 101, 102, 104, 105, 107, 108, 109, 110, >> > > >> + 112, 113, 114, 115, 116, 117, 118, 119, >> > > >> + 120, 121, 122, 123, 123, 124, 125, 125, >> > > >> + 126, 127, 127, 128, 128, 129, 129, 129, >> > > >> + 130, 130, 130, 130, 131, 131, 131, 131, >> > > >> + 131, 131, 131, 131, 130, 130, 130, 130, >> > > >> + 129, 129, 129, 128, 128, 127, 127, 126, >> > > >> + 125, 125, 124, 123, 122, 122, 121, 120, >> > > >> + 119, 118, 117, 116, 115, 114, 112, 111, >> > > >> + 110, 109, 107, 106, 105, 103, 102, 101, >> > > >> + 99, 98, 96, 94, 93, 91, 90, 88, >> > > >> + 86, 84, 83, 81, 79, 77, 75, 74, >> > > >> + 72, 70, 68, 66, 64, 62, 60, 58, >> > >> > ... >> > >> > Erfahren Sie mehr ยป >> >> >> > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
From 68f520e5c358b046b9d5a164e0904effdae0483e Mon Sep 17 00:00:00 2001 From: Stefan Krastanov <[email protected]> Date: Sat, 28 Mar 2009 14:53:22 +0100 Subject: [PATCH] subtle improvement in soft-AE speed Signed-off-by: Stefan Krastanov <[email protected]> --- sn9c20x-dev.c | 10 ++++++++++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/sn9c20x-dev.c b/sn9c20x-dev.c index b1eb4d3..ec0705a 100644 --- a/sn9c20x-dev.c +++ b/sn9c20x-dev.c @@ -295,8 +295,15 @@ int dev_sn9c20x_perform_soft_ae(struct usb_sn9c20x *dev) return -1; } + /*some hardcoded values are present + *like those for maximal/minimal exposure + *and exposure steps*/ + /* image too dark */ if (yavg < dev->camera.min_yavg) { + /*worst case - exposure is allready maximal*/ + if (dev->vsettings.exposure > 0xf5) + return 0; /*change exposure just a bit*/ new_exp = dev->vsettings.exposure+dev->camera.exposure_step; if (new_exp > 0xff) @@ -320,6 +327,9 @@ int dev_sn9c20x_perform_soft_ae(struct usb_sn9c20x *dev) } /*image too light*/ if (yavg > dev->camera.max_yavg) { + /*worst case - exposure is allready minimal*/ + if (dev->vsettings.exposure < 0x10) + return 0; /*change exposure just a bit*/ new_exp = dev->vsettings.exposure-dev->camera.exposure_step; if (new_exp > 0xff) -- 1.5.6.3
