ChanServ changed the topic of #linux-msm to:
marvin24_ has joined #linux-msm
marvin24 has quit [Ping timeout: 480 seconds]
pevik has joined #linux-msm
jhovold has quit [Quit: WeeChat 3.7.1]
jhovold has joined #linux-msm
pespin has joined #linux-msm
<narmstrong> flto: no idea on production devices, we have a tweaked abl on the dev boards
<mort_> bryanodonoghue: how do you actually run debugcc? Is there docs anywhere?
<mort_> the output says "<platform>-debugcc [-b blk] <-a | -l | clk>" as its only output, but it does that regardless of what I give it
<konradybcio> i had a problem on at least one distro where i had to move it to /usr/bin and then run it with no prefixed
<konradybcio> prefixes*
<mort_> aha, setting PATH=`pwd`:$PATH and then running debugcc -p msm8936 instead of msm8936-debugcc seems to have worked
<mort_> should I grab anything other than the '-a' output ( before I go back to the 4.9 kernel and try it there?
<bryanodonoghue> mort_ you should run that when you are capturing data
<bryanodonoghue> all of your CSI clocks are off ;)
<mort_> aha
<mort_> fair :p
<bryanodonoghue> gcc_bimc_clk: 1065.999660MHz (1065999660Hz)
<bryanodonoghue> impressive
<bryanodonoghue> So there's your link
<bryanodonoghue> gcc_camss_mclk1_clk: 23.879924MHz (23879924Hz)
<bryanodonoghue> 23.8 != 22.4
<bryanodonoghue> but anyway
<bryanodonoghue> I'm not sure the utility will run on 4.9
<bryanodonoghue> i.e. are the right registers available to user-space
<mort_> we'll see
<konradybcio> it runs fine on a few recent platforms on android, so it prob should
<mort_> doesn't android use fairly recent kernels these days
<konradybcio> yes they do, ish
<bryanodonoghue> actually I think I ran this on a downstream 3.10
<bryanodonoghue> no..
<bryanodonoghue> 3.10 exports it via debugfs I think
<bryanodonoghue> well worst case you can printk()
<konradybcio> msm-3.10 has the msm clk framework which lets you call their measure() funcs
<mort_> debugcc worked just fine on 4.9
<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?
<konradybcio> drivers/regulator/qcom_spmi-regulator.c spmi_regulator_common_get_voltage
<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> probably supports up to 24 MHz
<mort_> I'll check
<DylanVanAssche> Recently, `memory-region` DTS property was added to the FastRPC DT bindings by abelvesa, but I cannot find any DTS using it or an example. According to the docs, it allows to allocate CMA memory for a DSP?,fastrpc.yaml#n30
<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 ?
<mort_> nothing from dmesg
<bryanodonoghue> and 15 FPS without EM on 5.10
<mort_> yeah
<mort_> and 15 FPS with or without EM on 4.9
<mort_> alright, building new kernel with this patch:
<mort_> uh 0x300e is the MIPI CONTROL 00 register, bits [7:5] controls lane mode, 010 is two lane mode
<mort_> I don't know what's default but it seems potentially relevant
<bryanodonoghue> probably two lane
<bryanodonoghue> I'm diffing a bit between 4.9 and 5.10 trying to understand if somehow the signal terminations @ the PHY would be different
<mort_> oh the new kernel sets 0x300e too, just with OV5645_IO_MIPI_CTRL00
<bryanodonoghue> If so, not done purposefully
<bryanodonoghue> I don't suppose you could run linux-next on this ?
<mort_> I probably can, with some work
<mort_> we're running upstream linux with a couple custom kernel patches
<bryanodonoghue> that would be interesting
<mort_> alright let's give it a shot
<bryanodonoghue> git revert 092e8eb90a7dc7dd210cd4e2ea36075d0a7f96af
<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
<mort_> yeah
pevik has quit [Ping timeout: 480 seconds]
pespin has quit []
flto has quit [Remote host closed the connection]
flto has joined #linux-msm
flto has quit [Remote host closed the connection]
flto has joined #linux-msm