<!-- Some styling for better description lists --><style type='text/css'>dt { font-weight: bold;float: left;display:inline;margin-right: 1em} dd { display:block; margin-left: 2em}</style>

   ***: BrianG61UK has quit IRC (Read error: Connection reset by peer)
   <br> xecutercmd has joined #linux-media
   <br> xecutertool has quit IRC (Ping timeout: 480 seconds)
   <br> dcz_ has quit IRC (Quit: Konversation terminated!)
   <br> xecutertool has joined #linux-media
   <br> xecutercmd has quit IRC (Ping timeout: 480 seconds)
   <br> BrianG61UK has joined #linux-media
   <br> mvaittin has joined #linux-media
   <br> djrscally has joined #linux-media
   <br> dcz_ has joined #linux-media
   <br> tmerciai has joined #linux-media
   <br> GBenji has joined #linux-media
   <br> tmerciai has quit IRC (Ping timeout: 480 seconds)
   <br> ao2 has joined #linux-media
   <br> hansg has joined #linux-media
   hansg: sailus, hi, my "[PATCH v8 00/14] media: i2c: Add Omnivision OV02C10 sensor driver" got testing feedback quicker then I expected. As explained in the cover-letter I split out my cleanups as a series for future reference when upstreaming other Intel sensor drivers. Do you want to take a look at the incremental patches, or shall I post a squashed v9 which might be easier for you to review ?
   sailus: <u>hansg</u>: These are on top of earlier unmodified patch I guess?
   <br> Either is fine.
   hansg: I included the original unmodified v7 patch as patch 1/14 of the series. If either is fine I'll let you review the incremental patches before posting v9. This also makes me remember another reason for the incremental approach in some of the patches changes are made which could use a second pair of eyes which won't be obvious as changes in a squashed posting.
   <br> Especially patches 03/14 04/14 and 05/14 which are not just cleanups but also behavioral changes
   <br> p.s. / offtopic I like the new v4l2_link_freq_to_bitmap() helper, it really makes that part of check_hwcfg easier.
   sailus: That's nice to hear. We've tried to come up with helpers for common (and especially non-trivial) tasks like this one. Most drivers originally got that somewhat wrong, too.
   <br> <u>hansg</u>: Could you still send a squashed patch? I think the changes look good but it's harder to see everything that needed fixing in the original is fixed.
   hansg: sailus, sure one squashed v9 coming up
   sailus: Thanks!
   <br> What about the 0x12 GPIO handling, are those patches going (gone?) in or is there still work to do there?
   hansg: and yes many drivers including this ov02c10 got the link-frequency menu wrong. I had already rewritten it manually before seeing your remark about using the helper :)
   sailus: :-)
   hansg: p.s. please still do look at the 03/14 04/14 and 05/14 incremental patches those make subtle changes which you won't see in the squashed version and I think I got those right but an extra check would be good
   <br> About the handshake pin stuff, I believe we have agreed on modeling this as a vdd regulator with a 25 ms power-on delay on the regulator now, right?  That is pretty much where were at I've been with PTO + sick + a bit buried with work so I've not gotten around to implementing this plan yet.
   sailus: Is the horizontal blanking value written to the sensor somewhere?
   <br> I believe so.
   hansg: hts is written yes, but it is hidden in the register lists.
   sailus: It'd be nice to dig it out of there, but I guess the driver could work without that, too...
   <br> Now the values in the mode list are disconnected from sensor's registers which is not a good thing.
   hansg: So for single lane setup we write: {0x380c, 0x08}, {0x380d, 0xe8},  but for dual lane setup we write: {0x380c, 0x04}, {0x380d, 0x74},
   sailus: Btw. on the GPIO: the firmware indeed needs some time to boot and this delay is there for that. For some devices (Altek?) the delay is much longer so this needs to be taken into account. I'm not sure if these are out there though and it can be addressed separately anyway if needed.
   <br> It would have been nice to get some kind of an indication the firmware is up and running but it's just what it is. :-P
   hansg: about the hts, the different value for single/dual lane is weird, in dual lane the register value is less then the width of the mode.. This suggest that either the sensor somehow internally doubles the value in dual lane mode or the driver is wrong
   <br> I've asked one of the testers to look what FPS qcam reports. If the driver is wrong then I would expect the sensor to use 0 hblanking (as hts is too low) which should result in a much higher fps
   ***: tmerciai has joined #linux-media
   sailus: The driver may well be right there, especially if the mode is binned.
   <br> The pixel readout may work at same speed but the (total) lane speed is halved so you'll need more time go output the image. I guess it could also work at higher fps with lower vertical blanking on two lanes?
   hansg: The mode is not binned. It is the exact same mode at 1 lane and 2 lane, but the driver is writing half of the HTS value to the HTS register in dual lane mode. Note it seems that the laptops used by testers so far are actually using dual-lane mode, otherwise the mistake Heimer made with the lane check would have broken things.
   <br> Yes dual lane mode should be able to do higher fps at the cost of max exposure by lowering vblank. That is what "[PATCH v8 04/14] media: ov02c10: Fix vts_min" enables (theoretically, since I've no hw to test)
   sailus: This was Dell XPS 13 9340?
   <br> Based on Ingwar's e-mail that is.
   hansg: Ingwar has a Dell XPS 13 9340 and Heimir has a Dell XPS 9440, I believe all the Dell XPS 9x40 models use the same camera module.
   sailus: s/w/v/
   hansg: Ingvar just replied that he is getting exactly 30 fps, so apparently writing half the HTS value to the register in dual lane mode is correct.
   <br> Ugh just got an email that CI failed for v9 because of Makefile / Kconfig conflicts. I should have based this on media-committer/next. I'll try to remember to use that as base for v10.
   sailus: I'll review v9 soonish.
   hansg: Thank you.
   ***: alarumbe has quit IRC (Ping timeout: 480 seconds)
   <br> alarumbe has joined #linux-media
   <br> mvaittin has quit IRC (Ping timeout: 480 seconds)
   <br> ao2 has quit IRC (Quit: Leaving)
   <br> BrianG61UK has quit IRC (Read error: Connection reset by peer)
   <br> prabhakalad has joined #linux-media
   <br> chewitt has joined #linux-media
   <br> cyrinux has quit IRC ()
   <br> GBenji has left
   <br> prabhakalad has quit IRC (Quit: Konversation terminated!)
   <br> prabhakalad has joined #linux-media
   <br> mripard has quit IRC (Quit: WeeChat 4.5.1)
   <br> tmerciai has quit IRC (Ping timeout: 480 seconds)
   <br> hansg has quit IRC (Ping timeout: 480 seconds)
   <br> BrianG61UK has joined #linux-media
   <br> Ampera has quit IRC (Quit: Don't look at my quit message, steve30 has a better one anyways.)
   <br> Ampera has joined #linux-media
   <br> dcz_ has quit IRC (Read error: Connection reset by peer)
   <br> EcstasyGlommy[m] has joined #linux-media
   <br> djrscally has quit IRC (Ping timeout: 480 seconds)
   <br> danitool has joined #linux-media
   <br> xroumegue has quit IRC (Ping timeout: 480 seconds)
   <br> xroumegue has joined #linux-media