<lumag>
logicalerzor[m], I forgot that DEVTMPFS_MOUNT doesn't work with initramfs
<logicalerzor[m]>
lumag: This works now thanks! i2cdetect works now! :)
<logicalerzor[m]>
how did u figure out the DEVTMPFS_MOUNT was the problem? now sure how to search for configs that might solve my problem
<logicalerzor[m]>
s/now/not/
<logicalerzor[m]>
oh wait i was probably mounting incorectly. was doing this instead
<logicalerzor[m]>
~ # mount -t debugfs none /sys/kernel/debug
<lumag>
logicalerzor[m], ??
<lumag>
regarding devtmpfs - once you've posted the empty /dev/ it became more or less obvious. If the system was working properly, you'd have got at least ttyMSM0 and other usual stuff like zero, null, etc.
<logicalerzor[m]>
thanks lumag! i thought it was me mounting wrong because mount none /dev -t devtmpfs works whereas ‘mount -t debugfs none /sys/kernel/debug’ didnt
<konradybcio>
logicalerzor: make sure you have the i2c_dev module
<konradybcio>
oh you guys solved that issue :p
<konradybcio>
lumag: yes the gpu works on fp5
<lumag>
konradybcio, but with the default DT
<lumag>
I assume
<konradybcio>
i would assume so as well, i can dig the thing out of the drawer a bit later on
<lumag>
no worries
<lumag>
I think bamse solved the issue thanks to robclark's help
<marc|gonzalez>
lumag: thanks. I'm pretty disheartened. I was on vacation until Sept 3rd, if I had known the PR was going out, I would have pinged then...
<marc|gonzalez>
lumag: I appreciate your help along the way. I guess I'm relieved my work is done.
<lumag>
marc|gonzalez, it's sad that this is a kind of experience that you've got. I'm used to 'it gets in, great. it gets in next cycle, it's fine too'.
<lumag>
I'm used to think that way
<lumag>
And anyway, thanks for your work, as usual.
<konradybcio>
marc|gonzalez: sorry to hear you're done with this.. thank you for your contributions though, especially the iommu saga which nobody wanted to touch with a 10ft pole for 7 years..
<lumag>
Yep
<lumag>
And now it unblocked a lot of other stuff for that generation of platforms
<aka_[m]>
Great pros, now fix mesa pretty please.
<lumag>
:-D
<lumag>
aka_[m], I hope that Vladimir's patches will make 8996 / 8998 more stable
<konradybcio>
maybe one day even the imx300 driver will get merged..
<marc|gonzalez>
konradybcio: do you mean the audio dsp iommu hack?
<lumag>
marc|gonzalez, yes
<marc|gonzalez>
that was ugly as... something very ugly
<lumag>
But it got accepted!
<marc|gonzalez>
smirk
<lumag>
and so it unblocked the way for 660
<marc|gonzalez>
660 has the same issue? because similar FW I guess?
<phh>
yeah looks like iommu was the big blocker for all of Angelo's contributions?
<konradybcio>
yep and yep
<lumag>
which required this hack not only for lpass, but also for WiFi, GPU and most likely compute DSP
<marc|gonzalez>
but you see, even this acceptance has left me jaded
<marc|gonzalez>
because the compromise that was required is straight up gross
<marc|gonzalez>
I'm not used to programming that way
<marc|gonzalez>
I make art normally :p
<lumag>
it's a contemporary art :-P
<marc|gonzalez>
Yeah Picasso programming
<konradybcio>
that's linux kernel for you, one day you change 3 lines to be like Michelangelo, another day you're Picasso..
<lumag>
Don't frown upon Picasso!
<marc|gonzalez>
I have a system-wide kernel change in the works since about 2016. I think it'll just never get in. Maybe I can just go for the greatest number of patch versions?
<marc|gonzalez>
Maybe I'll just rage quit when I get to v42
<konradybcio>
that wouldn't even be a world record
<marc|gonzalez>
for real?
<konradybcio>
ofc
<marc|gonzalez>
I don't think I have the courage to read up on that
<marc|gonzalez>
But someome needs to be clobbered with a foam bat
<marc|gonzalez>
Either the author, or the maintainer, or both
<lumag>
Sometimes it takes a year to get the patch _reviewed_
<marc|gonzalez>
I KNOW. CAUSE IT HAPPENED TO ME :(
<marc|gonzalez>
I posted the most magnificent patch series (said in Trump's voice) to media. It was a work of art
<marc|gonzalez>
No one gave af
<marc|gonzalez>
Then 1.5 years later, Mauro said "oh I need to look at this"
<marc|gonzalez>
Dude, I gave up 1.3 years ago
<lumag>
:-(
<aklimov>
TJ[m]: if you look at sound/soc/qcom/qdsp6/q6asm-dai.c and define PLAYBACK_MAX_PERIOD_SIZE as 6144 and PLAYBACK_MAX_PERIOD_SIZE as 8
<aklimov>
TJ[m]: then does the DSP error go away?
<aklimov>
TJ[m]: you can also check max period size set to 7168
marc|gonzalez has quit [Quit: Leaving.]
<TJ[m]>
aklimov: you mean PLAYBACK_MIN_PERIOD_SIZE as 8?
<aklimov>
TJ[m]: sorry, yes, correct
<aklimov>
min period size as 8
<TJ[m]>
<aklimov> "TJ: then does the DSP error go..." <- Yes, no DSP error with 6144
<TJ[m]>
<aklimov> "TJ: you can also check max..." <- 7168 also work, thanks.
<aka_[m]>
aklimov: got anything?
<aklimov>
aka_[m]: nope :(
<aklimov>
aka_[m]: i can share rx macro and wcd regdumps from regmap debugfs
<aklimov>
aka_[m]: from downstream
<aka_[m]>
if you cannot get it there is even lower chance for me to get it
<aka_[m]>
s/you/You/
<aklimov>
TJ[m]: yeah, i think anything starting with 8k as max period size leads to that dsp mapping error
<aklimov>
TJ[m]: but i don't have any info apart from that
<aka_[m]>
what kind of error you had?
<aka_[m]>
aklimov: i wouldn't mind i guess
<aka_[m]>
no playback and playback enabled
<aka_[m]>
tho i remember your route had RX_2 in it and mine is just RX1
marc|gonzalez has joined #linux-msm
<marc|gonzalez>
lumag: trying to bring 17300000.remoteproc up ... No cookie so far. You merged a kernel-side PD-thingy-mapper? I have all the user-space bells & whistles to make WiFi work. Is there more magic required for adsp?
<marc|gonzalez>
It looks like the kernel impl fails ("PDR: service lookup for avs/audio failed: -6") as expected, then later the user-space impl fails as well ("probe with driver q6asm-dai failed with error -22")
<marc|gonzalez>
hmmm, apparently of_q6asm_parse_dai_data(dev, pdata) is not happy & returning EINVAL. Maybe something changed between 6.1 & 6.11