ChanServ changed the topic of #linux-msm to:
Danct12 has quit [Read error: Connection reset by peer]
Danct12 has joined #linux-msm
pespin has quit []
Daanct12 has joined #linux-msm
marvin24_ has joined #linux-msm
marvin24 has quit [Ping timeout: 480 seconds]
srinik has quit [Killed (NickServ (Too many failed password attempts.))]
srinik has joined #linux-msm
suihkulo1ki is now known as suihkulokki
agross_ has joined #linux-msm
hfink_ has joined #linux-msm
pundir_ has joined #linux-msm
ldts___ has joined #linux-msm
SanchayanMaity_ has joined #linux-msm
sboyd_ has joined #linux-msm
jbg_ has joined #linux-msm
qyousef_ has joined #linux-msm
elder_ has joined #linux-msm
jstultz_ has joined #linux-msm
mka_ has joined #linux-msm
sibis0 has joined #linux-msm
jhugo_ has joined #linux-msm
steev_ has joined #linux-msm
vkoul| has joined #linux-msm
vkoul has quit [resistance.oftc.net weber.oftc.net]
ndec has quit [resistance.oftc.net weber.oftc.net]
linusw has quit [resistance.oftc.net weber.oftc.net]
jbg has quit [resistance.oftc.net weber.oftc.net]
agross has quit [resistance.oftc.net weber.oftc.net]
pneuhardt has quit [resistance.oftc.net weber.oftc.net]
sboyd has quit [resistance.oftc.net weber.oftc.net]
hfink has quit [resistance.oftc.net weber.oftc.net]
steev has quit [resistance.oftc.net weber.oftc.net]
mka has quit [resistance.oftc.net weber.oftc.net]
elder has quit [resistance.oftc.net weber.oftc.net]
SanchayanMaity has quit [resistance.oftc.net weber.oftc.net]
pundir has quit [resistance.oftc.net weber.oftc.net]
norris has quit [resistance.oftc.net weber.oftc.net]
jhugo has quit [resistance.oftc.net weber.oftc.net]
ldts__ has quit [resistance.oftc.net weber.oftc.net]
kido has quit [resistance.oftc.net weber.oftc.net]
qyousef has quit [resistance.oftc.net weber.oftc.net]
jstultz has quit [resistance.oftc.net weber.oftc.net]
sibis has quit [resistance.oftc.net weber.oftc.net]
narmstrong has quit [resistance.oftc.net weber.oftc.net]
mka_ is now known as mka
elder_ is now known as elder
qyousef_ is now known as qyousef
agross_ is now known as agross
jbg_ is now known as jbg
steev_ is now known as steev
norris has joined #linux-msm
ndec has joined #linux-msm
pneuhardt has joined #linux-msm
narmstrong has joined #linux-msm
kido has joined #linux-msm
linusw has joined #linux-msm
<Daanct12> aka_[m]: a few days ago i said that lanik123's branch wouldn't be upstreamed, now i'm in the wrong
<Daanct12> very sorry if i offended anyone
<Daanct12> my assumption was based on what i saw from that branch a year ago
pundir_ is now known as pundir
norris has quit [Server closed connection]
norris has joined #linux-msm
<Daanct12> i got this error when loading usb
kido has quit [Server closed connection]
<Daanct12> Failed to create device link (0x180) on smd
kido has joined #linux-msm
<Daanct12> this is the good ol' ci-hdrc driver btw
linusw has quit [Server closed connection]
linusw has joined #linux-msm
narmstrong has quit [Server closed connection]
narmstrong has joined #linux-msm
ndec has quit [Server closed connection]
ndec has joined #linux-msm
sibis0 has quit []
sibis0 has joined #linux-msm
sibis0 is now known as sibis
sibis has quit []
sibis has joined #linux-msm
pneuhardt has quit [Server closed connection]
pneuhardt has joined #linux-msm
Daanct12 has quit [Quit: WeeChat 4.1.1]
<mal> bryanodonoghue: I tested your new power domain patchset and now the power domain errors are gone when doing rmmod, I did find a possible unrelated issue in the code, I will see if I can fix it, the issue is probably in interrupt cleanup
<aka_[m]> arent we like in non-merge window now?
<flamingradian[m]> what? 6.6 was released sunday
<aka_[m]> then we have 2 weeks window in which next will be frozen
<aka_[m]> and then after 2 weeks turn into 6.7_rc1
<flamingradian[m]> so merge window, not non-merge window?
<aka_[m]> ¯\_(ツ)_/¯
<aka_[m]> i haven't yet figured how it all works
<bryanodonoghue> Eh well if you tested and you are happy would appreciate a Tested-by mal
<bryanodonoghue> ;)
<aka_[m]> bryanodonoghue: have you guys figured way to handle CCI on 8939 yet?
<bryanodonoghue> CCI should just be 1:1 with 8916
<aka_[m]> separate driver/inside icc/something_else?
<bryanodonoghue> CCI or ICC ?
<aka_[m]> CCI
<aka_[m]> APCS_C0,APCS_C1,CCI
<bryanodonoghue> ah *that* cci
<aka_[m]> on 8996 they do cci inside cpu-clk
<aka_[m]> with clk-icc stuff
<bryanodonoghue> its been a while since I looked at CPR
<aka_[m]> will be same on 8953 but still 8939/8952/8976 is left with apcs-msm8916 driver and no "this_stuff"
<aka_[m]> cpr kinda bad, i guess i got it on 8976 but it required dumping multiple mem-acc paths
<aka_[m]> and freq was changed way too fast anyway
<bryanodonoghue> maybe the nicest way to fix upstream for non PSCI which includes CPR since you really need CPR for suspend/resume is the idea we discussed before
<bryanodonoghue> throwing something into arch/arm not arch/arm64
<bryanodonoghue> CPR + LPM seems like a whole topic that should be solved at once
<bryanodonoghue> but, there's been no movement - or sadly upstreaming of even the working CPR we have on 4.19
<mal> bryanodonoghue: sure, I will send tested-by, should I send just one for the whole series?
<bryanodonoghue> mal up to you
<mal> bryanodonoghue: btw, this is the error I get when probing camss after removal:
<mal> [ 57.101918] irq: type mismatch, failed to map hwirq-509 for interrupt-controller@17a00000!
<mal> [ 57.101937] qcom-camss ace0000.camss: error -ENXIO: IRQ csiphy0 not found
<mal> [ 57.101953] qcom-camss ace0000.camss: Failed to init csiphy0 sub-device: -6
<flamingradian[m]> had the same problem yesterday on stable, fixed by changing to IRQ_TYPE_EDGE_RISING
<mal> why does that only happen during second probe, not during first?
<bryanodonoghue> because this fails maybe type == irq_get_trigger_type(virq)
<mal> indeed changing the type to IRQ_TYPE_EDGE_RISING fixes the issue
<bryanodonoghue> root@linaro-gnome:~# rmmod venus_core
<bryanodonoghue> root@linaro-gnome:~# modprobe venus_enc venus_dec
<bryanodonoghue> [12167.739974] qcom-venus aa00000.video-codec: non legacy binding
<bryanodonoghue> [12167.871736] qcom-venus: probe of aa00000.video-codec failed with error -110
<bryanodonoghue> [12167.863387] qcom-venus aa00000.video-codec: failed to reset venus core
<bryanodonoghue> [12167.880540] venus_enc: unknown parameter 'venus_dec' ignored
<bryanodonoghue> I have to admit rmmod + modprobe is not something I do regularly
<mal> it's useful when testing some changes quickly
<bryanodonoghue> a bug is a bug
<vknecht[m]> do you also get crashes/problems when running v4l2-compliance ?
<mal> bryanodonoghue: do you have any opinion how to handle this properly https://github.com/mlehtima/linux/commit/b144611b43ac1ffc871bd834968c113a16650bf0
<mal> sc7280 has 3 normal and 2 lite CSIDs
<bryanodonoghue> mal I'm aware of someone adding struct resources->is_lite per VFE
<bryanodonoghue> so I've been holding off on adding that flag
<bryanodonoghue> has_pd != is_lite
<bryanodonoghue> since older SoCs don't have PDs but also are not "lite"
<bryanodonoghue> but yeah that MACRO is on the way out
<bryanodonoghue> # macro /
<mal> bryanodonoghue: should I wait for such a flag to be added or include it in my patchset?
<bryanodonoghue> mal if you want to submit code feel free
<bryanodonoghue> is_lite should be a parameter associated with struct resources {} and should result in said horriffic macro exiting reality
<bryanodonoghue> vknecht[m] I get an NV12 complaint with my current userspace on venus
jhugo_ is now known as jhugo
<mal> bryanodonoghue: I just noticed that there is that vfe_num and vfe_lite_num in struct camss_resources already, that could be used
<mal> unless there is possibility that the lite vfes are not the last ones
<mal> this would work for now "#define IS_LITE (csid->id >= csid->camss->res->vfe_num ? 1 : 0)"
<bryanodonoghue> ah that's the whole point of the pd-names series
<bryanodonoghue> no magic indexes
<bryanodonoghue> vfe_lite_num should go away
<mal> ok, I will then add the is_lite member to the vfe resources struct
<bryanodonoghue> vknecht[m] if you build v4l-utils then the NV12 failures go away
<bryanodonoghue> 3d6682746de535d1f7aa71b43a30af40d52a539c / README.md: drop qt5-default, add libsdl2-dev libbpf-dev llvm clang
<vknecht[m]> hmm, unless I'm utterly mistaken, I got those crashes/problems when running v4l2-compliance on camss video capture devices, not venus encoder/decoder... but will check again
<bryanodonoghue> vknecht[m] https://git.codelinaro.org/bryan.odonoghue/kernel/-/tree/b4/b4-camss-named-power-domains-v3+sm8250 on rb5 passes all compliance tests for me with above v4l-utils sha
<vknecht[m]> alright, will try with updated v4l2-utils
hfink_ has quit []
hfink has joined #linux-msm
<mal> bryanodonoghue: this is how I did the csid change https://github.com/mlehtima/linux/commit/bdb96686775c561104d30da3919c0e53afb103d9
<bryanodonoghue> So it would be nice to have an IS_LITE or is_lite() helper in csid.h which takes a struct vfe *
<bryanodonoghue> and then to use that helper wherever we currently differentiate around lite v non-lie
<bryanodonoghue> lite
<bryanodonoghue> I like the removal of vfe_total_num and vfe_lite_num
<bryanodonoghue> yep looks good otherwise
<bryanodonoghue> also you don't need the ternary operator
<bryanodonoghue> (csid->camss->res->vfe_res[csid->id].is_lite ? 1 : 0)
<bryanodonoghue> is_lite should default to false
<bryanodonoghue> and be a bool
<mal> ok, I'll look into that helper function
<bryanodonoghue> an inline or a macro - also consider sending the patch separate to your SoC enabling series
<bryanodonoghue> unless there's some need to gate one on the other
<mal> my patches requires this change because of the number of VFEs but not sure how soon I will send the sc7280 support patches anyway, trying to figure out if test pattern issues are generic or something in my changes, same issue of only top of the test pattern being correct happens also on one other platform
<bryanodonoghue> hmm IDT that is apparent on other platforms TBH
<vknecht[m]> I think the bottom-half issue is what I get too on msm8939 (in addition to garbled top half)
<mal> bottom-half is only zeros, top-half looks correct
<vknecht[m]> yeah, probably two distinct issues here
<mal> vknecht[m]: is that also using csid-gen2?
<vknecht[m]> you could try hooking a sensor, afaik the bottom-half problem doesn't affect sensor output (ie. I only stripes/garbage over the whole sensor output, but it's not cut in half)
<vknecht[m]> * I only get stripes/garbage over
<bryanodonoghue> real image > tpg
<vknecht[m]> nope, it's gen1
<bryanodonoghue> if you have a real image coming from a sensor..
<mal> I haven't yet managed to get the real sensor working, I have to fix the driver I'm writing for it first
<mal> although I did find some random driver for a bit older kernel (6.1) for one of the other camera sensors on the device, I didn't yet try to build it
<bryanodonoghue> what TPG command are you using lads ?
<vknecht[m]> <vknecht[m]> "IMG20231009185726.jpg" <- real image still looks like that :-/
<mal> I have used similar commands, I have also tested using v4l2-ctl for setting test pattern and capturing the image
jstultz_ has quit []
<bryanodonoghue> is what I use on db410c
jstultz has joined #linux-msm
<bryanodonoghue> rb3
<bryanodonoghue> yeah maybe try changing your pixel format
<bryanodonoghue> I haven't run yuv8 though tpg in a while/ever
<bryanodonoghue> might explain the disparity in our results
<mal> I wasn't able to get your commands to work, need to debug what is wrong a bit later today
<bryanodonoghue> probably the vfl subdev number
<bryanodonoghue> v4l
<mal> bryanodonoghue: the output file I now got using your commands seems to contain full data, is it just yuv that has problems
<mal> bryanodonoghue: about the is_lite helper, that is used from both vfe and csid side, can we assume csid->id == vfe->id? other it makes it a bit more difficult to use because vfe_device * is not available directly in the code where it used in csid code
marvin24 has joined #linux-msm
<mal> maybe it needs is_lite members in both the resource structs for vfe and csid
marvin24_ has quit [Ping timeout: 480 seconds]
<bryanodonoghue> just have an is_lite for csid and another is_lite for vfe
<bryanodonoghue> I will try running yuv8 on my test systems - assuming I reproduce the fault this => what you have is "good enough" on sc7280 and we should bugfix TPG in isolation
<bryanodonoghue> i.e. TPG works for me @ RBG as well as actual sensor data RX
<bryanodonoghue> so there's no point in gating new SoC additions for TPG yuv8
<mal> just mentioning that the csid one has a small issue which I will fix, one missing is_lite