ChanServ changed the topic of #linux-msm to:
marvin24_ has joined #linux-msm
marvin24 has quit [Ping timeout: 480 seconds]
minecrell has quit [Read error: Connection timed out]
minecrell has joined #linux-msm
jhovold has quit [Quit: WeeChat 3.7.1]
jhovold has joined #linux-msm
<bryanodonoghue> mort_ how do you know your problem is emissions and not simply say software timings / race conditions ?
<mort_> bryanodonoghue: when there's no noise, I get a stable 15 FPS from my ov5645, when I activate an EM noise generator at 175MHz and position the antenna right it drops to 1 FPS
<bryanodonoghue> heh fair enough
<bryanodonoghue> does the frequency make a difference ?
<bryanodonoghue> why 175 MHz ?
<mort_> the frequency does make a difference yeah
<mort_> some make it worse than others, some don't affect it at all
<bryanodonoghue> interesting
<bryanodonoghue> what's the CSI bus frequency ?
<bryanodonoghue> is 175 a harmonic ?
<bryanodonoghue> If something were to change between kernel releases and pin-states were not it
<mort_> https://p.mort.coffee/M9f.auto here's the whole devicetree (canonicalized)
<bryanodonoghue> then bus frequencies might be plausible
<mort_> https://p.mort.coffee/pad.auto here's the 4.9 dts (canonicalized), and 4.9 is not affected by noise at all
<mort_> the fact that 4.9 is not affected is the reason I'm looking at software, rather than trying a hardware fix like more shielding
<bryanodonoghue> is the sensor upstream or downstream for you on 4.9 ?
<mort_> it's a pretty broad range which affects it, most things I try between like 155MHz and 265MHz has *some* effect, even though the magnitude differs within that range; so I don't think it can really be a harmonic thing
<mort_> https://github.com/varigit/DART-SD410-kernel/commit/b95f0f74ce5343a0327d031c7f0a34986f116217 this is the last change to ov5645.c which is not one of variscite's changes, so the ov5645 driver is upstream
<bryanodonoghue> how do you inject the noise ?
<mort_> there are some changes to the camss stuff though
<mort_> I have an antenna which I position in a particular way, then turn on a signal generator thing
<bryanodonoghue> I'd try reverting that commit
<mort_> that commit is from the variscite 4.9 kernel which works, I think it would be more interesting to see if there are changes after that to 5.10 which might've broken something
<mort_> huh, that commit is not part of the history of the file in the gregkh linux-5.10.y branch
<bryanodonoghue> IDK if you can rule out pin configuration
<bryanodonoghue> Seems to me clocks are a likely culpritt
<bryanodonoghue> espec considering you can elicit a splat at a particular EM freq input
<mort_> the file in 5.10 uses the same pixel_clock values as the 4.9 code so even though the commit doesn't seem like it's part of the history for the 5.10 branch those changes have been applied somehow
<mort_> I've read the devicetrees thoroughly and haven't been able to find any pinconf changes which seem relevant
<mort_> all the regulator stuff seems the same, the pinctrls seem the same
<bryanodonoghue> is the 4.9..5.10 ov5645 configuration the same ?
<bryanodonoghue> Typically there are a series of magic numbers that are thrown over the i2c to configure the sensor
<bryanodonoghue> Secret stuff like divide my PLL / 4
<mort_> the camera node is the same (except for the reg value, which is because the 4.9 kernel has a patch from variscite to support multiple cameras which messes with reg values)
<bryanodonoghue> Sorry I mean git diff 4.9..5.10 -- driver/i2c/media/ov5645.c
<mort_> aha
<bryanodonoghue> i.e. is your sensor config the same
<mort_> https://p.mort.coffee/1Yf.diff here's the diff between them, there are some differences
<mort_> especially the ov5645_global_init_setting stuff is a bit suspicious
<bryanodonoghue> -{ 0x3008, 0x02 },
<bryanodonoghue> -{ OV5645_IO_MIPI_CTRL00, 0x40 },
<bryanodonoghue> -{ OV5645_PAD_OUTPUT00, 0x70 }
<bryanodonoghue> -{ OV5645_MIPI_CTRL00, 0x24 },
<bryanodonoghue> +{ 0x3008, 0x02 }
<bryanodonoghue> what's that about ?
<mort_> that's what I'm calling suspicious.. I'll have a look at the ov5645 datasheet and see if they're listed there
<bryanodonoghue> and the link frequencies have gone away
<bryanodonoghue> -static const s64 link_freq[] = {
<bryanodonoghue> -224000000,
<bryanodonoghue> -336000000
<bryanodonoghue> -
<bryanodonoghue> -};
<bryanodonoghue> you need to set a link frequency in your dts
<mort_> hmmmm that's also a very solid clue
<bryanodonoghue> I'd suggest the lower one
<mort_> in 4.9 it seems to use the higher link freq for anything that's not sxga
<bryanodonoghue> heh
<bryanodonoghue> Higher so :)
<bryanodonoghue> that was my next guess
<mort_> I'll look at the commits and see if I find the one which changes this stuff, maybe it lists out a rationale and it should at the very least tell us which dts prop it's replaced with
<bryanodonoghue> 224000000 / 1000000 => 224 MHz which is inside the window of where you say you get an EM response
<bryanodonoghue> 155-265 MHz
<bryanodonoghue> If you set 336 MHz in 4.9
<bryanodonoghue> and 224 in 5.10
<bryanodonoghue> ?
<mort_> oh wait! I gave you a bad diff
<mort_> the diff is 5.10 -> 4.9 not 4.9 -> 5.10
<bryanodonoghue> might be a worthwhile test to `git checkout 4.9 -- drivers/i2c/media/ov5645.c` fix up the dts to satisfy the ~ small differences and try it out
<bryanodonoghue> to know if you should look at CAMSS or sensor
<bryanodonoghue> also suggest doing a printk() on the link frequency CAMSS is setting in 4.9 and 5.10
<bryanodonoghue> and forcing 5.10 to the same speed
<mort_> the issue with trying the old driver is that the devicetree stuff has changed quite a lot from 4.9 to 5.10
<mort_> I mean the internal kernel interfaces to deal with it
<mort_> anyways https://p.mort.coffee/e2N.diff is a diff which goes the right way
<mort_> I don't understand what the new link_freq mechanism replaced
<mort_> I'll try using the old driver anyways
<Marijn[m]> mort_: is there perhaps debugcc available for apq8016? You might use it to measure actual clock frequencies
<mort_> what exactly is debugcc?
<Marijn[m]> mort_: it is a userspace application that uses the hardware to measure/count clockticks
<Marijn[m]> You'd use it to count if a clock ia really emitting the frequency that you set it to, without external probe points