<mort_>
the new kernel has gcc_camss_cci_clk and gcc_camss_cci_ahb_clk off while they're 19.2 and 80 MHz in 4.9
<konradybcio>
not very clear how you're accessing the camera if the CCI AHB is off :P
<mort_>
gcc_gfx_tcu_clk, gcc_sdcc1_apps_clk, gcc_sdcc1_ahb_clk, gcc_sdcc2_apps_clk, gcc_sdcc2_ahb_clk are also off in the new kernel, while gcc_usb2a_phy_sleep_clk is off in the old kernel but on in the new
<konradybcio>
sdcc clocks will only be active when there's ongoing access
<konradybcio>
you can dd something and run debugcc while that happens
<mort_>
gcc_blsp1_qup5_spi_apps_clk is half the clock frequency in the new kernel
<mort_>
but the camss stuff is certainly the most interesting
<mort_>
what does sddc stand for? Is the sd the same as in sdhci?
<konradybcio>
yes
<konradybcio>
hci means host controller interface, dc means dsomething controller, probably
<mort_>
that makes sense
<mort_>
now how the hell do I end up getting frames from the camera if the cci clock isn't going
<mort_>
as you asked
<konradybcio>
well you don't need the cci clock for getting the frames out, but having the i2c bus functional sounds useful for sensor configuration
<mort_>
maybe there's some additional logic in the new kernel to disable the clock except for when actually configuring the camera, while the old kernel would just keep the clock running needlessly when nothing's being configured?
<konradybcio>
sounds probable
<mort_>
is csi the interface which actually transfers the pixels?
<konradybcio>
y
<mort_>
and all the clocks with csi in their name are unchanged
<mort_>
time to check voltages I suppose, I don't have an oscilloscope with me but maybe I can figure something out with my multimeter
<konradybcio>
or SPMI reads
<mort_>
that sounds very relevant, what is it and how do I do it?
<mort_>
konradybcio: can you elaborate on the spmi thing?
<mort_>
is there a way to read it from userspace? If not I can just shove printks in the kernel but I'm not super familiar with most parts of the kernel
<mort_>
there's some spmi stuff in sysfs
<konradybcio>
i have no idea
pevik has quit [Quit: Lost terminal]
pevik has joined #linux-msm
<bryanodonoghue>
the cci clocks being off is not necessarily wrong
<bryanodonoghue>
that's just i2c to the sensor
<bryanodonoghue>
so - it need not be on unless you are doing i2c coms
<bryanodonoghue>
I'm just looking at your link speed
<bryanodonoghue>
its the same frequency on 4.9 as on 5.10
<bryanodonoghue>
mort_ can you check your datasheet and verify that 23.8 MHz is supported ?
<bryanodonoghue>
There's no real difference in the clocks
<bryanodonoghue>
I think you should look for differences in the sensor configuration
<bryanodonoghue>
Ideally just revert to the 4.9 sensor configuration state
<mort_>
the spec sheet says "input clock frequency: 6~27 MHz"
<bryanodonoghue>
yep that sounds right
<mort_>
I'll try to set the registers back to how they were with 4.9
<bryanodonoghue>
the CAMSS pins we are kind of fortuante with in that they are basically not muxed anywhere
<bryanodonoghue>
so... I'd be a bit skeptical that pin configuration was your root cause
<mort_>
my expectation when I started working on this tbh was a pinconf thing, I was expecting to just read through my dts diff and find some stupid issue
<bryanodonoghue>
you say you drop to 1 FPS when injecting EM
<mort_>
yeah
<mort_>
very suspiciously exactly 1
<bryanodonoghue>
do you have visible errors reported in Linux ?
<bryanodonoghue>
Not just the config but the logic too
<mort_>
oh yeah, good call
<mort_>
"With this commit the sensor is able to enter LP-11 mode during power up" -- what is LP-11 mode? Does LP mean some kind of low power
<konradybcio>
yes
<mort_>
well that's exactly what I want to avoid, I want it to use as much power as it needs to overcome the noise picked up by the giant antenna that's the camera cable
<mort_>
still compiling btw, I'm making a new image with yocto so it takes a while... I need to find a better workflow for kernel work
<mort_>
bryanodonoghue: !!! after reverting 092e8eb90a7dc7dd210cd4e2ea36075d0a7f96af EM noise doesn't affect it!
<bryanodonoghue>
sweet
<bryanodonoghue>
probably => we should do some extra work to fix in upstream
<mort_>
yeah
<mort_>
what do you think? Devicetree config option to decide LP or HS? Or make it runtime configurable
<konradybcio>
runtime sounds saner for a camera sensor