ChanServ changed the topic of #linux-msm to:
marvin24 has joined #linux-msm
marvin24_ has quit [Ping timeout: 480 seconds]
<calebccff> bryanodonoghue: KieranBingham[m]: so I've been diving down the C-PHY pipeline (haha), I've added the proper CSIPHY init tables to camss (cross referenced with register dump from downstream), hardcoded all the clock rates (also checked against downstream) and I still can't get anything out of this sensor... neither with the old imx519 driver or with the CCS driver (which seems to
<calebccff> have some issues calculating the clock rates anyway)
<calebccff> I pushed what I've got to this branch : https://gitlab.com/sdm845-mainline/linux/-/commits/sdm845/6.8-camera/
<calebccff> unless there's some other thing im missing on the camss side of things it must be an issue with the sensor, as far as I can tell there isn't any other special magic needed for CPHY beyond the hacks I've already done
<KieranBingham[m]> So many variables to tie in correctly! ... Does the CAMSS/CPHY have any stats that can tell if any data hits the wire?
<KieranBingham[m]> And can you clarify why you believe CCS doesn't calculate the clock rates correctly please? - That may be similar to what Umang saw ... but it would be good to hear more there.
<KieranBingham[m]> calebccff: https://docs.google.com/spreadsheets/d/1Cq4HI5O-VGg45jzR-sCtq7Bga5sXouhLeTDQAdw0hUA/edit?usp=sharing is the clock domain calculator I threw together while working on this with Umang.
<KieranBingham[m]> calebccff: Also - you won't be able to use the Arducam driver for C-PHY.
<KieranBingham[m]> (unmodified)
<KieranBingham[m]> There will almost certainly be a bit in the device to configure the IMX519 for C-PHY/D-PHY. We could /really/ do with the datasheet for that.
<KieranBingham[m]> I can dig around some other Sony datasheets to see if they do it in a common way, or we can see if CCS driver already handles this - but the concept of 'lanes' changes... so all of that needs rework if we know it's C-PHY
<KieranBingham[m]> aha ... looks like you've been experimenting around the lane reconfiguration already
junari has joined #linux-msm
deathmist has quit [Remote host closed the connection]
deathmist has joined #linux-msm
<travmurav[m]> Kieran Bingham: oh, this calculator sounds like something I lacked 2 years ago when I was trying to bring up a seemingly ccs compliant samsung s5k5e2 sensor. I think I had no idea /how much/ compliant it is and I never could figure out what link freq to pick so it doesn't fail configuring the plls in the sensor. Extra complication for that was that on msm8916 due to an errata we need xclk=23.88 instead of 24MHz...
<travmurav[m]> Kieran Bingham: seems like I even still have a log snippet from back then: https://gist.github.com/TravMurav/a178032c5dc5eac7bcf873e1e50d0c0c ; Do I understand correctly that the idea for the spreadsheet is that I need to "solve" link_freq by picking the divider values within the limits I see reported by the sensor?
<KieranBingham[m]> travmurav: it's really just following the calculations on the model to be able to visualise the results. It's nothing clever to do the solving automatically, but that's what the CCS driver does. Of course you can change the dividers and multipliers to solve yourself. Maybe some more spreadsheet macros could make a solver.
<KieranBingham[m]> CCS sensors have registers that tell you the limits. So you can read those (printed by the CCS driver) and work from there.
<travmurav[m]> yeah I think back then I got the logs and the driver was happy to dump the limits but I could never figure out which link freq to pick that it would actually be able to solve for
<KieranBingham[m]> Ultimately the VT domain needs to be fast enough to process all the pixels and the op domain needs to be faster to clock them all out. OP domain is the connection to the link frequency but then you have to account for bpp and lanes
<KieranBingham[m]> I should definitely pull all this into some slides sometime for elce
<travmurav[m]> hm, looking at my log, all op_* stuff is 0x0, does it mean the sensor won't play with me? :D
<KieranBingham[m]> No there can be configurations with a single clock domain
<KieranBingham[m]> So it can still work.
<travmurav[m]> I see
<KieranBingham[m]> Do you know if the sensor has a fixed input clock crystal?
<travmurav[m]> xclk? the 24MHz source?
<travmurav[m]> I think no and it's fed from the soc at 23.88 due to errata
<KieranBingham[m]> Yes that's it.
<KieranBingham[m]> Are there any clock rates that it can produce more consistently?
<KieranBingham[m]> Well ... Is it already working or do you still need to bring this sensor up?
<travmurav[m]> afaiu the errata says the clock jitters at 24.0 so one has to use 23.88
<travmurav[m]> no, never go the sensor to work
<KieranBingham[m]> Does 12mhz work without jitter?
<KieranBingham[m]> The benefit of CCS is we don't have to use 24
<KieranBingham[m]> I'm not sure what limits there are though.
<travmurav[m]> I think it should, and I should be able to set it to I think
<travmurav[m]> (I guess ideally I could try to measure it with the osciloscope to see what jitter does the errata refer to even)
<KieranBingham[m]> Well if you want to try again, hopefully we can help you bring it up
<KieranBingham[m]> What device is it in?
<travmurav[m]> it's "Longcheer L8150" design (per upstream dts) aka Wileyfox Swift or one of Google One gen2 devices
<travmurav[m]> *android one, how that project was called...
<KieranBingham[m]> I still don't have a device that's working with the CCS driver, so I'm keen to find one so we can add the support to libcamera
<KieranBingham[m]> In a perfect world then we'll be able to support lots more cameras without extra drivers, or easier bring up
<travmurav[m]> the phone has two samsung cameras: s5k3m2 13mp (didn't ever talk to me) and s5k5e2 5mp (did talk but never probed properly so far)
<travmurav[m]> the s5k5e2 sensors reports it's model ids as all 0x0 so not sure if it's properly compliant but otherwise ccs driver seems to have read it's capabilities resolution etc properly
<travmurav[m]> KieranBingham[m]: But yeah, I think now I have something new to try with looking at the spreadsheet so I think I'm going to take another stab at getting the sensor up :D
<KieranBingham[m]> It's just something I threw together while working through so let me know if it needs anything to be clearer
<travmurav[m]> Kieran Bingham: hm so I was trying to quickly come up with some values considering what I see in the old logs, and I just noticed that min_vt_sys_clk_freq_mhz=6MHz (0x40c00000) and max_=2.75MHz (0x40300000) Oh well...
<KieranBingham[m]> I think I'd have to look through more to understand
<travmurav[m]> Seems like I also have an old snippet where I tried to dump what downstream userspace blobs did to init the camera, which seem to not really do much with the clocks even... https://paste.debian.net/hidden/c14676e3/
roxell_ has quit []
roxell has joined #linux-msm
strongtz[m] has joined #linux-msm
<strongtz[m]> <konradybcio> "strongtz: could you please share..." <- konradybcio: feature_code: 2 soc_id: 603
<strongtz[m]> btw I do have a question on the qcm8550 patches on the mailing list
<strongtz[m]> different reserved memory regions were introduced in that patch, but on my device (qcs8550) I just used the original sm8550 memory layout
nick1343[m] has joined #linux-msm
mort_ has quit [Ping timeout: 480 seconds]
mort_ has joined #linux-msm
f_ is now known as funderscore
funderscore is now known as f_
pundir_ is now known as pundir
junari has quit [Quit: Leaving]
<calebccff> KieranBingham[m]: yeah i hacked up the imx519 driver, including using the correct init sequences for 3 lane C-PHY mode
<calebccff> possibly the sensor configuration is wrong, i should probably dump the registers and decode the clock tree if possible..? although I get the feeling that some of the registers don't actually match the CCS standard
<calebccff> KieranBingham[m] do you know what the LINK_FREQUENCY CCS register is? is it meant to be the same as the link-frequency DT property (i tried this as it seems to be about right)
<calebccff> the CCS driver does some weird maths for it though
<calebccff> this is all made so much worse by the whacky maths of C-PHY mode... 16 bits per lane, but the CSID clock has to be 1
<calebccff> 1.5 time faster* for weird reasons
<KieranBingham[m]> Yeah I don't know if CCS has been used for cphy yet so we can't be sure of the calcs until we check. This is the first device I've come across actually using cphy
<KieranBingham[m]> Cphy has some clever data clocking and indeed it's something like 1.5 bits per clock
<KieranBingham[m]> Do you have the correct reg settings for imx519 for cphy?
<KieranBingham[m]> The spreadsheet I linked earlier has a tab for the clock tree we decoded for imx519 from the Arducam settings
<KieranBingham[m]> Two clock domains. Follows as you can read in the CCS datasheet
<calebccff> KieranBingham[m] the reg settings im using are from downstream for this device, they're definitely for CPHY (also see in my branch I decoded a bunch of the registers and you can see for example CCS_R_CSI_SIGNALING_MODE is set to CPHY)
<calebccff> i'll take a look at that spreadsheet
<KieranBingham[m]> Perfect it's something like signalling mode I wanted to hear
<calebccff> KieranBingham[m]: also the fact that it's configuring it for 3 lanes now makes a whole lot more sense, that should have been the giveaway a year ago lol
<KieranBingham[m]> Does the CCS driver reference CSI signalling mode yet?
<KieranBingham[m]> If you have a downstream reg set I would definitely decode all the registers against CCS
<KieranBingham[m]> Otherwise it will just be a blob. It will be more insightful once broken down. I'd start by converting the table to CCI with the CCS register defines if possible.
<calebccff> lots of non-CCS registers though
<calebccff> KieranBingham[m]: reviewing some old logs I took capturing all the i2c writes to the sensor, I have no idea what's going on here... https://gitlab.com/sdm845-mainline/camera-porting/-/blob/main/dmesg-cam.log?ref_type=heads#L1600
<calebccff> i just repeated this and got the same result, it's definitely writing a whole bunch of data to the sensor starting at address 0, it must be some kind of special vendor thing
<KieranBingham[m]> Really wish we could get hold of the real datasheet
<calebccff> yeah
<calebccff> although im not certain this is for the same sensor
<calebccff> there are two on the back, the second one is an imx376k (noo idea what the K means)
<calebccff> dump i just took, note that "cam_cci_core_cfg: 1357 cmd 0" means CCI_INIT, it happens at the start, then the imx519 init sequence we're familiar with, then it happens again before the absurd writes, so it could be that they're for a different sensor
<calebccff> oh it could even be one of the actuators
<JIaxyga[m]> Can groups of pins for lpi-pinctrl be found ONLY in the datasheet?
<JIaxyga[m]> konradybcio: Maybe you know something about this?
<JIaxyga[m]> JIaxyga[m]: And btw did you return to wcd937x from last time?
f_ is now known as funderscore
funderscore is now known as f_
<KieranBingham[m]> calebccff: did that short datasheet you found detail the register ranges? If so what groups match the dumps you have?
<calebccff> KieranBingham[m]: no, no register data. Poked deeper and I'm confident that the data in the imx519 driver at the link I sent you before matches what Android does
<KieranBingham[m]> I thought there was a table of the offsets that's all that might have said 0x0000, x2000, 0x3000 with descriptions of the range at least. Maybe I'm remembering a different datasheet
<calebccff> KieranBingham[m]: ah, there's this https://0x0.st/HRi1.png
<calebccff> this datasheet at least has a loooooot of info about the clock tree
<KieranBingham[m]> That's it. That's what I was thinking of. Are there writes to 0x1000 and 0x2000 space? I think I saw earlier numbers in ranges beyond 0x5000 as welll in your list.
<calebccff> yes, there are lots of write which look standard, i decoded them all
<calebccff> really want to avoid having to calculate the clock tree... but I guess i don't see what else could be missing here, especially on the 6mq
<bryanodonoghue> calebccff can you detect the sensor on the CCI bus ?
<bryanodonoghue> also you can/should cherry-pick the debugfs stuff here
<bryanodonoghue> I'll get around to upstreaming this soonish
<bryanodonoghue> but what you want to do is
<bryanodonoghue> 1. Ensure you find a sensor
<bryanodonoghue> 2. Stream on
<bryanodonoghue> 3. cat debugfs entries - which are only visible during runtime
<bryanodonoghue> I might make these persist with a snapshot so that prior state can be seen when not running
<bryanodonoghue> point is - are you seeing error counters increment on the CSID side ?
<bryanodonoghue> but the commit log for the sensors says 2 or 4 lane mode
DavidHeidelberg_ has quit [Remote host closed the connection]
DavidHeidelberg has joined #linux-msm