<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
<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