ChanServ changed the topic of #msm8937-mainline to: Boot Linux on your MSM8917/37/40 and QM215 mobile! | GitHub: https://github.com/msm89x7-mainline | Logs: https://oftc.irclog.whitequark.org/msm8937-mainline | Bridged to #msm8937-mainline:kde.org on Matrix
<semf[m]> <NekoCWD[m]> "MirrorHall on agassi" <- is the display good? might consider picking one myself <del>if im not broke for once</del>
<barni2000[m]> I am thinking about maybe with RXn mute we can avoid the pop noises
<barni2000[m]> no :(
<barni2000[m]> maybe if i put it in the boot sequence
<ValPackett[m]> what a coincidence, i also started looking into the camera (on nora)
<ValPackett[m]> who lives on i2c addr 50 and responds 027a to 0000? 0.o doesn't seem like any of the cameras suggested by the xml..
<barni2000[m]> eeprom
<barni2000[m]> getting cameras i2c address is tricky
<barni2000[m]> this is working but something was missing from the description last time when i have checked
<ValPackett[m]> hm i mean i2cdetect only detects the eeprom then
<ValPackett[m]> * eeprom then.. oh hm mclk
<barni2000[m]> yes mclk and regulators should be enabled
<barni2000[m]> after you should see the camera in i2cdetect
<barni2000[m]> an be aware of fixed-regulators they are typically GPIOs at downstream
<ValPackett[m]> yea i mean i screwed up the pinctrl for mclk setting it as gpio but fixing that didn't fix it yet
<barni2000[m]> in this example vana is a fixed regulator
<barni2000[m]> vaf is related to actuatotr not the sensor
<barni2000[m]> s/actuatotr/actuator/
<ValPackett[m]> no vana here
<barni2000[m]> all sensor have vio vdig vana
<ValPackett[m]> i mean no external regulator
<barni2000[m]> this is just an example how fixed regulators handled at downstream
<barni2000[m]> some times both are set
<barni2000[m]> if you have a gpio for a regulator that means always fixed regulator just sime times it is supplied by one of spmi regulator
<ValPackett[m]> all cameras here use pm8917_l{6,22,23}
<barni2000[m]> cam_vio-supply = <&pm8953_l6>;
<barni2000[m]> cam_vana-supply = <&pm8953_l22>;
<barni2000[m]> * ````
<barni2000[m]> cam_vio-supply = <&pm8953_l6>;
<barni2000[m]> cam_vana-supply = <&pm8953_l22>;
<ValPackett[m]> l23 is vdig
<barni2000[m]> so in my example vana is a fixed-regulator supplied by l22 as input
<ValPackett[m]> hm
<ValPackett[m]> no, gpio req here is only "CAMIF_MCLK[01]", "CAM_RESET[01]"
<barni2000[m]> ok in that case you are lucky
<barni2000[m]> 1 stuff is left using the propery voltahes
<barni2000[m]> s/voltahes/voltages/
<barni2000[m]> if one of the regulator allows lower value then min set it higher
<ValPackett[m]> `<1200000 0 2900000>` - avdd was already 2.9 min&max, dvdd was already 1.2 min&max
<ValPackett[m]> hm
<barni2000[m]> btw 0x10 0x2d and 0x36 (for omnivision) works most of the times
<ValPackett[m]> pinctrl cam_sensor_front_default has a comment /* VANA RESET */
<ValPackett[m]> though the rear one says just /* RESET */
<barni2000[m]> s5k4h8?
<ValPackett[m]> that's an option for the rear one (s5k4h8 or s5k3l8)
<ValPackett[m]> front is ov5675 or s5k4h7
<barni2000[m]> s5k3l8 is a back camera mostly
<barni2000[m]> sry i was miss understand :D
<barni2000[m]> there is s5k3l8 driver at msm8953
<ValPackett[m]> yeah i saw it
<ValPackett[m]> it queries chip id by reading register 0x0000 and the ids are like 0x2106 0x2187 0x30c8
<ValPackett[m]> i2cset -y 4 0x50 0x00 0x00; i2cget -y 4 0x50 0x00 w → 0x7a02 0.o
<ValPackett[m]> heh with mclk & reset for rear instead of front, still only the 0x50 is detected
<ValPackett[m]> * is detected. must be the eeprom fr
<ValPackett[m]> wait i might be stupid. i did not even have CONFIG_VIDEO_OV5675 on lolol
<ValPackett[m]> * wait i might be stupid. i did not even have CONFIG_VIDEO_OV5675 on lolol // err not like loading it helped..
<ValPackett[m]> oookay it was on 0x10
<ValPackett[m]> weirdddd, so mclk0 is actually also required for the front camera (mclk1) to show up
<ValPackett[m]> *