ChanServ changed the topic of #linux-msm to:
irungentoo has quit [Quit: ZNC 1.8.2+deb2+b1 -]
irungentoo has joined #linux-msm
irungentoo has quit [Remote host closed the connection]
irungentoo has joined #linux-msm
irungentoo has quit [Remote host closed the connection]
irungentoo has joined #linux-msm
marvin24 has joined #linux-msm
marvin24_ has quit [Ping timeout: 480 seconds]
<aka_[m]> bhsharma: i have send yday few patches but will resend today because I somehow dropped few things from cpufreq/spi nodes
pevik_ has joined #linux-msm
<krzk> aka_[m]: different timezone... but I am onw
<aka_[m]> krzk: can you take a look on sm6115 dts patches?
<aka_[m]> I have to resend anyway atleast spi(lacking DMA on spi0) and cpufreq(somehow dropped freq domain props from cpu nodes)
<aka_[m]> Rob asked about some changes to 14nm phy. Should supply be changed from required to optional
<aka_[m]> Or some kind of "if:"
linusw has joined #linux-msm
<krzk> DTS? What do you need me exactly for DTS? I am not usually reviewing DTS.
<krzk> aka_[m]: but if you need something specific to check, tell me what exactly and where
<aka_[m]> krzk: ah, dt-bindings only?
<aka_[m]> There are two patches tho
<aka_[m]> Sex
<aka_[m]> *sec
<aka_[m]> Xd
<krzk> yeah, but you just sent them yesterday evening...
<aka_[m]> Ok so if you aren't reviewing dts then fine, I guess dt-bindings are OK, maybe Rob will have a look
<aka_[m]> So I have Konrad for dts review and not sure who else
<aka_[m]> Thanks for reply.
<bhsharma> aka_[m]: I will have a look at your patches and provide a Reviewed and Tested-by if everything looks fine
<bhsharma> aka_[m]: So Konradybcio and myself (specifically for sm6115) can help review your patches going ahead as well
<bhsharma> krzk is our dt-binding guru, so he can help you review those..
<aka_[m]> bhsharma: testing patches might be tricky tho
<aka_[m]> Cpufreq is broken on next, display require phy patch from Loic and smmu compatible is only for next
<bhsharma> Ok, I will start some tests tomorrow and ping you here if you find any obvious issues (other than the known issues).
<bhsharma> I find*
<aka_[m]> Probably I will make today testing tree on top of 6.1 RC so you can try it
<aka_[m]> Not sure in which are you going to test.
<bhsharma> Ok, I will try it on my qcom supplied sm6115 board
pespin has joined #linux-msm
<aka_[m]> krzk: so how should i name commit about changing node name from mdss to display-controller?:
<aka_[m]> Rename mdss node example into display-controller
<aka_[m]> ?
<krzk> aka_[m]: yeah, or rename mdss node name in example
<aka_[m]> ok imma take some action now.
<aka_[m]> I also have some question about cpufreq.
<aka_[m]> konradybcio said that new devices have also device-specific compatible
<aka_[m]> is that required now?
<aka_[m]> or only for EPSS (v2) IP
<aka_[m]> back in time i thought you add device specific compat only if these are required for handling some specific scenario in code
<aka_[m]> and now i see dummy compatibles getting into dt-bindings but being dropped from .c
<bamse> aka_[m]: running make dtbs_check will tell you ;)
<aka_[m]> it tells me more than i need to know
<bamse> yeah, i share that's nice to see though that the noise is coming down
<bamse> generally, the binding requires a platform-specific compatible, followed by a generic one, and the driver only acts on the generic one
<aka_[m]> some bindings also need changes, but im not really that able to even understand how they work to even change them
<bamse> the result is that adding a new platform means only ammending the dt binding, the driver can be ignored
<aka_[m]> well, imma run dt-bindings check then
<bamse> there's dt_binding_check to check that the yamls are good, and then there's dtbs_check to see that your .dts is good
<bamse> and i believe you can do "make CHEKC_DTBS=1 qcom/your.dtb" to get only what you care about
<aka_[m]> had "pleasure" to use both yet while dt_bindings_check can point to specific yaml folder, im not sure if dtb can
<konradybcio> this will only work after you ran make dtbs_check and generated the binary-from-yaml that schema will check against
<konradybcio> if your bindings changed, you need to rerun make dtbs_check
<aka_[m]> konradybcio:
<aka_[m]> that appears to require changes to yaml to add list into v1
<konradybcio> if only dtb changed, you dont hav eto
<bamse> konradybcio: ahh, but is there a way to run just that first step?
<konradybcio> bamse that's still being debated on the mailing lists I believe
<bamse> konradybcio: i often run dt-validate -s Documentation/devicetree/bindings/processed-schema.json arch/arm64/.../foo.dtb
<konradybcio> Marijn: could know..
<bamse> konradybcio: but that has the same problem, that i need to run make dtbs_check for a while before hand
<konradybcio> aka: enum:\n-qcom,sm6115...\nconst:qcom,cpufreq-hw
<aka_[m]> so redo v2 node
<aka_[m]> won't that break other v1 users?
<konradybcio> well, you could fix up all v1 users while at it
<aka_[m]> damn, you know i want to get this in, not everyone else, i don't understand single dime in these yamls
<aka_[m]> you are developer here, not me >_>
<mort_> where do I start when the only symptom I have is "the microphone doesn't pick up anything"
<mort_> I assume something's wrong with either my devicetree or some driver, I know the hardware is good and the mic works on an older kernel version
<aka_[m]> mort_: do you see mic being available?
<aka_[m]> audio is quite hard to understand
<aka_[m]> tho
<Marijn[m]> konradybcio: bamse yes I reported this on the lists. CHECK_DTBS=1 doesn't (re)build the schema if it's outdated. lumag's VALIDATE_DT=1 did that though...
<mort_> yes, 'arecord -l' shows a WCD-Capture device
<aka_[m]> with audio maybe minecrell[m] would be able to help
<aka_[m]> he did like most of q6dsp based stuff for 8916
<mort_> oh great, this is an 8916
<mort_> running `arecord -f cd recording.wav`, it creates a wav file with a wav header and then all 0s
<mort_> no errors tho
<mort_> not even in dmesg
<mort_> so we know: it's not something the kernel *knows* is wrong or it would've errored or not showed me the device, it's not a low gain or something because that would still register as something other than 0 bytes
<mort_> looking at alsamixer, with the f4 capture view, nothing is at 0
<krzk> aka_[m]: to your first question - specific device compatibles are usually recommended, especially when you deal with SoCs without documentation...
<aka_[m]> <krzk> "aka_: to your first question..." <- recommended vs required
<aka_[m]> You know there is a difference.
<aka_[m]> About documentation part as you know "it depends" xD
<aka_[m]> sadly i have no docs on almost anything.
<aka_[m]> Even things like TRMs are not so specific to be able to predict IP
<krzk> aka_[m]: the generic rule says recommended, because generic covers all possible cases, not only SoC related. But for SoC sub-blocks, I am more and more convinced they should be actually required. We did not follow this always in the past - neither for Qualcomm nor for other chipsets.
<krzk> Therefore it is anyway a bit different when we talk about new devices (completely new) or something existing, just now extended.
<aka_[m]> uh but SoC compatibles are fine if we don't know exact IP right?
<aka_[m]> There is IPA situation where sc7180/sm6115/sm6125 uses same IP , on DS qcom have IP_VX compatibles, on mainline i see SoC one
<aka_[m]> however code is sorted via IP_VX.c
<aka_[m]> so if 3 socs uses exact same IP why do we have to use SoC specific
<krzk> SoC compatibles are almost always expected - see exactly that rule of document I linked. Skipping SoC model is like a wildcard, so not accepted.
<aka_[m]> so i have to re-add all cpufreq users now then specify these compats in their dts
<krzk> aka_[m]: version-based compatibles are also accepted if there is a clear mapping between SoCs and versions, but if the mapping is 1-1 then version does not m ake sense anymore
<aka_[m]> from 9 dts patches its gonna grow to atleast 15 xD
<aka_[m]> ok, if thats required i will do it
<krzk> aka_[m]: again, it's a bit different between some old bindings and new ones - it is not always "I have to".
<krzk> aka_[m]: eh, I think we might be discussing about different things. I am giving you generic advices, generic rules.
<aka_[m]> this means im supposed to follow that if i add new driver with new compatible, or if i add new compatible to already existing driver
<krzk> aka_[m]: but mayb you expect some specific answer to specific patch... it does not work like that. I gave you just generic rules.
<krzk> Send a patch/mail and discuss the specific patch if you want to have specific answer.
<aka_[m]> i just need to know if i have to rework cpufreq v1 "list" to include compatible for sm6115 or i can use just generic
<aka_[m]> v2 got device specifc compatibles because it was just added for some specific socs
<krzk> aka_[m]: yeah, I think for v1 you should do the same.
<krzk> I mean, add a sm6115 specific compatible.
<aka_[m]> im not sure if its good idea to wire it into this 6115 series
<aka_[m]> or it doesn't matter much?
<aka_[m]> as all of these will go via same tree(maybe?)
<krzk> depends how many of binding patches you have. If just one from cpufreq, then put it there.
<krzk> If more, then you can send them separately and provide links in your DTS patch.
<krzk> It also depends on maintainers, because some prefer to take entire patchsets, not individual patches, so for such maintainers you should split DTS and bindings...
<krzk> Ehhh, it's getting a bit complicated :/
<aka_[m]> yes
<aka_[m]> and thats pain
<aka_[m]> like first i have to get compatible for tsens via some tree
<aka_[m]> then send dts
<aka_[m]> to other
<aka_[m]> and at some point one might think:Why i don't even have to deal with that.
<aka_[m]> or i will just do it without then if it gets merged send entire series dedicated to v1 cpufreqs
<aka_[m]> or just prepare series and then link first one as dependency
<mort_> hmm if I'm reading this datasheet correctly this hardware is using the apq8016's uart0_tx pin as a dmic clock and the uart0_rx pin as dmic data.. that feels like a non-standard configuration where I might have messed up the devicetree
<mort_> i
<mort_> when you use gpio names like "gpio0" or "gpio1" in the 'pins' field of a pinmux and pinconf, how does linux know what gpio controller those gpios are relative to?
<konradybcio> check what node you're adding them under
<aka_[m]> uh
<aka_[m]> arent you creating pinctrl nodes under one specific pinctrl device
<aka_[m]> like on qcom platform you have like 3 places where you can find pin controllers
<aka_[m]> main tlmm controller, LPI island and PM peripheral
<aka_[m]> konradybcio: im bit lost
<aka_[m]> somehow now next has sm6115 compatible for iommu
<aka_[m]> it wasnt there on 1711
<aka_[m]> still it wouldnt hurt to have this commit in dts right
<konradybcio> check with bindings on next
<aka_[m]> uh
<aka_[m]> its fucked
<aka_[m]> phun
<aka_[m]> i had 17 tree without commits
<aka_[m]> current one says they were merged on 14
<aka_[m]> well
<aka_[m]> maybe iommu tree was not pulled into next
<aka_[m]> konradybcio: So if sm6115 was added at the end to later "next" should i reword this commit regarding smmu?
<aka_[m]> uh
<aka_[m]> well
<aka_[m]> commit title sounds fine
<aka_[m]> but description is like it will fail
<aka_[m]> it did when 6115 binding was not there
<aka_[m]> but now it should not fail
<konradybcio> i think you answered your question
<aka_[m]> not really
<aka_[m]> im not sure if should leave it as it is
<aka_[m]> or change
<konradybcio> change because your commit msg is misleading as it stands now
<aka_[m]> like "add fallback to generic qcom smmu-500 compatible"
<aka_[m]> and thats all
<aka_[m]> it was failing on older tree because sm6115 smmu was part of dt-bindings but not yet in .c
<aka_[m]> or
<aka_[m]> SMMU on SM6115 implements qcom-mmu500 implementation add generic compatible fallback
<konradybcio> do the new bindings require both specific and fallback qcom compatible be present?
<aka_[m]> who knows
<aka_[m]> lets see docs maybe
<aka_[m]> i seen it on sm8550 tho
<aka_[m]> wait
<aka_[m]> on sm8550 there is only smmu-500
<aka_[m]> but they havent send 8550 compat
<konradybcio> now check if Dmitry hasn't fixed this dt in next then
<aka_[m]> sm8550 is not yet in next
<konradybcio> i meant 6115
<aka_[m]> no changes
<aka_[m]> there
<aka_[m]> since it was added
<konradybcio> so yes add your patch and reword it
<aka_[m]> so now i have to drop reviewed by?
<konradybcio> so yes
<konradybcio> well i don't know what you're gonna write there
<aka_[m]> i have no idea either
<aka_[m]> like
<aka_[m]> "provide generic fallback for mmu"
<konradybcio> to make it compliant with bindings
<konradybcio> enough
<aka_[m]> konradybcio: uh
<aka_[m]> have you tested latest rc
<aka_[m]> i still get phys deferred
<aka_[m]> on 6.1_rc7
<aka_[m]> try devlink hack?
<aka_[m]> konradybcio: so
<aka_[m]> with qfprom enabled i atleast get usb
<aka_[m]> dsi dying time to check debug
<aka_[m]> dsi deferred
<aka_[m]> clocks looks quite dead
<aka_[m]> uh
<aka_[m]> konradybcio: so on bengal i still need to pass clock to RPMCC
<aka_[m]> so statistics look okish
<aka_[m]> however i fucked something too as i don't see stuff on display
<aka_[m]> like idk, im missing PHY settings for qcm2290 which are part of next
<aka_[m]> yes xD
<aka_[m]> really, we need better debug msgs
<aka_[m]> somehow i didnt get cpufreq probing
<aka_[m]> wonder why
<aka_[m]> lets check
pevik_ has quit [Ping timeout: 480 seconds]
<aka_[m]> disabled in device dts because wasnt working on next
<aka_[m]> should be ok.
<aka_[m]> konradybcio: i see ath probing but it probably doesnt working
<aka_[m]> nmcli has no wifi
<konradybcio> it needs modem
<konradybcio> <aka_[m]> "konradybcio: so on bengal i..." <- expected
<aka_[m]> but it will be pain to pass it from device dts
<aka_[m]> due to how fake clocks were defined
<aka_[m]> or wait
<aka_[m]> lets see
<aka_[m]> uh, should be fine
<aka_[m]> just remember to add rate to device dts
<konradybcio> yes
<aka_[m]> bhsharma: bit lame tree but it boots for me on 6.1
<aka_[m]> konradybcio: i haven't expected to be able to finish building bootable tree today.
<konradybcio> why was it disabled in the first place
<aka_[m]> dying on next
<aka_[m]> ok, dropped your rb from smmu and regenerating
<konradybcio> which next?
<konradybcio> 20221129 boots for me
<aka_[m]> had issue on 17 one
<aka_[m]> 29 only clonned for dtses
<aka_[m]> uh
<aka_[m]> wtf, now when i try to do dtb check it says nothing to be done for that
<Marijn[m]> <Marijn[m]> ""; <- ^
<aka_[m]> konradybcio: well
<aka_[m]> downstream doesnt say anything about voting MX on dsi_ctrl
<aka_[m]> but thats what i had first in my dts
<aka_[m]> and later switched it to CX
<aka_[m]> it vote in phy
pespin has quit [Remote host closed the connection]
Caterpillar has quit [Ping timeout: 480 seconds]
Caterpillar has joined #linux-msm