ChanServ changed the topic of #linux-msm to:
<bryanodonoghue> I think you are missing vfe-17x in that change set
<mal> bryanodonoghue: there are no checks for lite in camss-vfe-170.c
<bryanodonoghue> hmm - so there's isn't
<bryanodonoghue> I think you are missing a few is_lite in your 845 and 8250 declarations
<bryanodonoghue> vfe_lite_num =2 => you need two is_lite = true in 8250.. and the same with csid
<mal> yes, I had fixed those locally already after I posted the links, I have two is_lite in both csid and vfe of 8250 and one in each in 845
<mal> also fixed some formatting issues
<bryanodonoghue> grand so
<mal> I also did test both normal and lite versions with test patterns, both seem to work
Daanct12 has joined #linux-msm
danylo has quit [Ping timeout: 480 seconds]
svarbanov has quit [Remote host closed the connection]
svarbanov has joined #linux-msm
marvin24_ has joined #linux-msm
marvin24 has quit [Ping timeout: 480 seconds]
jn has joined #linux-msm
jnn has quit [Ping timeout: 480 seconds]
pespin has joined #linux-msm
<vkoul|> HELP REGISTER
vkoul| is now known as vkoul
atipls_ has joined #linux-msm
atipls has quit [Ping timeout: 480 seconds]
danylo has joined #linux-msm
svarbanov_ has joined #linux-msm
svarbanov has quit [Ping timeout: 480 seconds]
mort_32 is now known as mort_
<f_> vkoul: ?
sibis2 has joined #linux-msm
bamse is now known as Guest5544
bamse has joined #linux-msm
Guest5544 has quit [Read error: Connection reset by peer]
sibis has quit [Ping timeout: 480 seconds]
Daanct12 has quit [Quit: WeeChat 4.1.1]
<mal> bryanodonoghue: wouldn't that sc8280xp camss require those patches I made? it has more than 2 full VFEs and CSIDs
<bryanodonoghue> early bird gets the worm !
<bryanodonoghue> I mean to say - whatever patches get posted first and merged first take priority
<bryanodonoghue> when your patches are ready - tested on multiple platforms if my SoC enablign stuff is not merged then happy to include your changes in mine
<bryanodonoghue> and vice versa
<mal> yes but is that series now partially broken because it doesn't handle the hardcode values in https://github.com/torvalds/linux/blob/master/drivers/media/platform/qcom/camss/camss-csid-gen2.c#L24
<mal> bryanodonoghue: you use gen2 csid but don't handle that issue with hardcoded maximum of 2 normal CSIDs, or do misunderstand something
<bryanodonoghue> yes - the magic index is breaking VFE lite determination
<mal> I will send the two patches separately from my changes so we can more easily fix that series
<bryanodonoghue> two ?
<mal> although first is not strictly needed for your case this time
<bryanodonoghue> hmm I might just pick up your two patches into my series directly
<bryanodonoghue> it'll have to be tested on db410c, sdm845 and sm8250 anyway
<mal> I think I will slightly modify those, the second part of comment in camss-csid.h change probably still belongs to the camss-csid-gen2.c
<mal> since it talks about gen2 specifically
<mal> bryanodonoghue: these are the final versions https://github.com/mlehtima/linux/commit/92901c8dc5cba3837fdfcd35257fc4a147ffd637 and https://github.com/mlehtima/linux/commit/492406f7010c24bfe223f659178002883b52e702 feel free to change those if needed and you can include those in your patchset
<bryanodonoghue> so the is_lite(vfe) check for PDs I think can be better represented as has_pd in my power-domain name series has_pd != is_lite
<bryanodonoghue> the change you've made there just shows that the named pd stuff could be done better
<mal> true, it does handle power domain things using that is_lite, I just replace those without thinking too much what happens after the check
<bryanodonoghue> swiched up has_pd in the named pd series
<bryanodonoghue> may as well stack your is_lite stuff in there too
<mal> bryanodonoghue: I found bug in my is_lite code
<mal> it seems in some cases it can cause a crash, debugging it now
<mal> bryanodonoghue: which one should camss_pm_domain_on and camss_pm_domain_off use, now those use vfe_is_lite but should those use some had_pd check?
<mal> *has_pd
<bryanodonoghue> should really be has_pd
<bryanodonoghue> since has_pd != is_lite
<bryanodonoghue> there's nothing to stop qcom floating a SoC with a VFE lite that is individually power collapse capable
<bryanodonoghue> actually - I'll take that into the power-domain fix series
<bryanodonoghue> .... since we are flagging has_pd inside the driver there's no dtb dependency either way
<mal> bryanodonoghue: actually using is_lite in configure_pd was the reason for the crash I see now
<mal> so probably using that latest code from you fixes that issue
<bryanodonoghue> there's no need to check for has_pd or is_lite in domain_on off since we check for genpd at the end of the named pd series
<bryanodonoghue> ah yeah ack
<mal> yes, the crash is gone now
<mal> bryanodonoghue: that latest changes in your branch seem good, I tested those on my device
sboyd_ has left #linux-msm [#linux-msm]
sboyd has joined #linux-msm
pespin has quit [Remote host closed the connection]
<mal> bryanodonoghue: I'm trying to test actual camera sensor (still wip driver so not sure if that is the problem) but I don't understand the clock-lanes and data-lanes setup used for other devices like this https://git.linuxtv.org/media_tree.git/tree/arch/arm64/boot/dts/qcom/qrb5165-rb5-vision-mezzanine.dts?h=master
<vknecht[m]> first step is to know whether the sensor has 2 or 4 lanes wired ; sometimes both options are possible
<vknecht[m]> https://wiki.postmarketos.org/wiki/Camera#Qualcomm has some explanations, but from what I experienced, downstream settings might be hidded in camera sensor userspace libs, so might have to build downstream with camera debug enabled
<vknecht[m]> if you can, check for csi_lane_assign and csi_lanei_mask
<vknecht[m]> s/csi_lanei_mask/csi_lane_mask/
<mal> should be 4 lanes, based on the schematics
<mal> vknecht[m]: any idea where that clock-lanes = <7>; in camss side comes from when the sensor has clock-lanes = <1>;
<bryanodonoghue> clock-lanes = <7> is a fixed mapping
<aka_[m]> bryanodonoghue: do you guys have anyone on qcs40X or its long dead?
<mal> ok, thanks
Newbyte has quit [Ping timeout: 480 seconds]
aka_[m] has quit [Ping timeout: 480 seconds]
z3ntu has quit [Ping timeout: 480 seconds]
flamingradian[m] has quit [Ping timeout: 480 seconds]
Tooniis[m] has quit [Ping timeout: 482 seconds]
DylanVanAssche has quit [Ping timeout: 480 seconds]
sergi1 has quit [Ping timeout: 480 seconds]
adomerle has quit [Ping timeout: 482 seconds]
felixwither[m] has quit [Ping timeout: 480 seconds]
konradybcio has quit [Ping timeout: 480 seconds]
go4godvin has quit [Ping timeout: 480 seconds]
enick_991 has quit [Ping timeout: 482 seconds]
alikateshethey[m] has quit [Ping timeout: 482 seconds]
Adrian[m]1 has quit [Ping timeout: 480 seconds]
minecrell[m] has quit [Ping timeout: 480 seconds]
FieryFlames[m] has quit [Ping timeout: 480 seconds]
Marijn[m] has quit [Ping timeout: 483 seconds]
strongtz[m] has quit [Ping timeout: 483 seconds]
Leandro[m]1 has quit [Ping timeout: 483 seconds]
AffeNull[m]1 has quit [Ping timeout: 480 seconds]
JIaxyga[m] has quit [Ping timeout: 480 seconds]
Degdag_Med[m] has quit [Ping timeout: 483 seconds]
travmurav[m] has quit [Ping timeout: 480 seconds]
xtex[m] has quit [Ping timeout: 480 seconds]
Nia[m] has quit [Ping timeout: 480 seconds]
nergzd723 has quit [Ping timeout: 480 seconds]
RayyanAnsari[m] has quit [Ping timeout: 480 seconds]
enick_966 has quit [Ping timeout: 480 seconds]
ajhalaney[m] has quit [Ping timeout: 480 seconds]
vknecht[m] has quit [Ping timeout: 483 seconds]
HappY[m] has quit [Ping timeout: 483 seconds]
aka_[m] has joined #linux-msm