<aka_[m]>
while setup is okish names are different so i was hitting out of index
pevik_ has quit [Quit: Reconnecting]
pevik_ has joined #linux-msm
pevik_ has quit []
pevik_ has joined #linux-msm
<Mis012[m]>
are those even the same clock?
lumag_ has joined #linux-msm
<aka_[m]>
well its just binding
<aka_[m]>
MMSS NOC
<aka_[m]>
sounds like multimedia subsystem network on a chip
<aka_[m]>
MMSNOC sounds more like multimedia system network on a chip
<Mis012[m]>
well, there's also the missing AHB part
<Mis012[m]>
but you have FLAT, so probaly take names from there? ;)
<lumag_>
DavidHeidelberg[m], Marijn[m] (and anybody else working on older, armv7 hardware). There is a question if you use (or would have used) meta-qcom for armv7 devices. I started pushing my ifc6410 fixes and ndec raised a question whether it would be worth adding generic armv7 device.
<DavidHeidelberg[m]>
lumag_: qcom_defconfig ? for apq8064 I use custom one based on qcom_
<lumag_>
DavidHeidelberg[m], qcom_defconfig, kernel builds, the rest of initramfs/rootfs/firmware/etc infrastructure
<lumag_>
e.g. for my work I use custom kernel builds, with the initramfs generated using meta-qcom
<DavidHeidelberg[m]>
oh, we don't. Userspace incl. initramfs comes from pmOS, but I might to try that
<lumag_>
DavidHeidelberg[m], no rush
sepkov[m] has joined #linux-msm
<sepkov[m]>
Hello guys. I'm trying to mainline Xiaomi Mi5s with msm8996 mainline kernel. I get succesful builds and bootups but booting time is very slow and dmesg is filled with ufshcd errors. Any tips?
<Tooniis[m]>
i tried it a while ago but it didnt seem to do anything for me so i didnt bother with it, and im quite sure i read something about msm8996 not having a reset line at least for the ufs host controller somewhere
<Tooniis[m]>
i had my own fair share of ufs issues while mainlining scorpio
<sepkov[m]>
This schematic is for mi 5s PLUS btw
<sepkov[m]>
Tooniis[m]: That's sad
<sepkov[m]>
Let me find 5s schematic
<Tooniis[m]>
its probably the same
<Tooniis[m]>
scorpio has that pin wired up as well
<Tooniis[m]>
that pin should be coming out of the ufs phy i believe
<Tooniis[m]>
it isnt a gpio
minecrell has quit [Quit: :( ]
<sepkov[m]>
What does <12> in schematic means?
<sepkov[m]>
Can I react somewhere with it?
minecrell has joined #linux-msm
<sepkov[m]>
s/react/reach/
<sepkov[m]>
BTW I would like to mention
<sepkov[m]>
While reading downstream kernel I see that ufs reset is happening via QCOM UFS Host controller vendor specific registers
<sepkov[m]>
Specific register is REG_UFS_CFG1 Which is 0xDC
<sepkov[m]>
Because without this line it's booting up
<lumag_>
sepkov[m], could you please post your dtsi parts related to ufs?
<sepkov[m]>
Well
<sepkov[m]>
None
<lumag_>
you don't have to change ufs/ufs phy in the msm8996.
<lumag_>
msm8996.dts
<sepkov[m]>
Yeah it's stock
<sepkov[m]>
I couldn't find anything to change
<lumag_>
sepkov[m], you have to add them in the board dtsi file. Three regulators for the ufs hc and three for the ufs phy
<sepkov[m]>
Those are already specified in imported dts file?
<bamse>
sboyd: so per your previous request, when i create an immutable branch i shouldn't use a tag for that? even when i share that immutable thing with another maintainer?
<lumag_>
Check other examples for your platform (see apq8096-db820c or msm8996-xiaomi-common.dtsi)
<sboyd>
bamse: when did I say don't make a tag?
<bamse>
sboyd: as a response to one of my clk pull requests, you objected to the fact that i had created a tag of some series that i merged into the qcom and clk trees
<sboyd>
bamse: I don't recall but I'm getting old
<sepkov[m]>
lumag_: I keep looking at them and none of them specified reset ping
<sboyd>
bamse: I do remember that you keep missing linux-clk@vger each time
<bamse>
sboyd: here it is "Next time can you merge branches with yourself instead of tags?"
<bamse>
sboyd: yes, that i do remember as well...
<sboyd>
bamse: ah right. There's not much point to record the tag merge to yourself
<bamse>
sboyd: okay, so you're saying when i do things between qcom-dts and qcom-clks i should just do a branch, otherwise it's fine to use a tag?
<sboyd>
bamse: yes
<lumag_>
sepkov[m], no
<bamse>
okay cool, thanks for clarifying :)
<sepkov[m]>
lumag_: When I add reset props device goes into boot loop
<sepkov[m]>
And I can't get any dmesg whatsoever
<bamse>
sboyd: and while i have you here, the caching of rcg parent updates...we need that on some more platforms now
<sboyd>
bamse: I'm sure
<bamse>
sboyd: so if you have a chance to take a look that would be appreciated
<bamse>
sboyd: thinking about it, don't you need that on sc7280? or it escaped the new fangled gdsc design?
<sboyd>
bamse: no prob! I'm out of my suspend hole
<lumag_>
sepkov[m], you don't need resets. you have to add regulators used on your board.
<sboyd>
bamse: probably it is needed on sc7280 as well
pevik_ has joined #linux-msm
<bamse>
sboyd: digging for suspend sounds dangerous...glad you guys are probing the grounds there ;)
<sboyd>
bamse: I recently discovered that RPMh XO resource doesn't block XO shutdown
<sboyd>
and then my mind exploded
<bamse>
so keeping xo enabled doesn't prevent xo from shutting down?
<sboyd>
bamse: apparently yes
<sepkov[m]>
lumag_: I'm repeating they are already exist on imported one but I'm adding okay
<bamse>
sboyd: but why then do we have all these drivers enabling xo?!
<sboyd>
bamse: exactly!
<bamse>
amazing
<sboyd>
bamse: I'm crafting a patch that blocks system suspend if XO is enabled to force the issue
<bamse>
i bet they just had too many clients holding it enabled, so they had to ignore it :)
<bamse>
can't fix that client code you know
<bamse>
different team...
<sboyd>
way too hard
<sboyd>
will take months of work
<bamse>
not worth it, when we instead can achieve an eternity of painful bugs
<sboyd>
I'm not sure why those pcie clk patches need weeks of review either
<bamse>
sboyd: the pipe_clk_src thing?
<sboyd>
bamse: yes
<bamse>
sboyd: picking up the clock patches as we speek...
<lumag_>
sepkov[m], do you use msm8996-xiaomi-common?
<sepkov[m]>
lumag_: Yes
<sboyd>
bamse: ok let me sit down and read this patch
<sepkov[m]>
And I've added the things you said it didn't fix
<lumag_>
sepkov[m], are they correct?
<bamse>
sboyd: seems though that per jhovold's feedback the last patch should be updated
<bamse>
lumag_: ^^
<sepkov[m]>
lumag_: That's a good point
<sepkov[m]>
vregs are correct
<sepkov[m]>
I comapred with android
<lumag_>
bamse, I'll take a look
<sepkov[m]>
s/comapred/compared/
<bamse>
lumag_: ahh sorry, i meant patch 4/5, not the last one
<lumag_>
sepkov[m], voltages values?
<sepkov[m]>
Yes totally same
<lumag_>
Also if you have original Android running, I'd compare clock rates
<sepkov[m]>
Where am I going to see them?
<sepkov[m]>
I have android dts
<sepkov[m]>
and they are same too
<sboyd>
bamse: minor nits but please resend!
<bamse>
sboyd: thanks
<z3ntu>
vkoul: Hi, I'm trying to get qcom,gpi-dma working on sm6350/"lagoon" and I'm wondering about the qcom,gpi-ee-offset property used in downstream that basically subtracts (on this SoC) 0x10000 from gpi_dev->ee_base , so from what I understand it's just accessing some different memory than when it's not set. What I also find curious is that sm8250 has qcom,gpi-ee-offset = <0x6000>; or 0x1000 downstream but this doesn't seem to be reflected in any
<z3ntu>
way in mainline. Do you know if I can just ignore this property?
<z3ntu>
<7>[ 78.659952] geni_i2c 988000.i2c: Using GPI DMA mode for I2C
<z3ntu>
but then my crappy touchscreen driver (which works with i2c-gpio though) still fails to transfer any data (and crashes at the end because crappy programming)
<z3ntu>
full dmesg, if it helps https://pastebin.com/raw/zevS7TgT (with #define DEBUG in i2c-qcom-geni.c). I don't understand what's going on there though
<Mis012[m]>
did you try `i2c-detect`
<Mis012[m]>
*?
<calebccff>
z3ntu: fyi pundir: is seeing similar GPI DMA failures on the poco F1 with 5.18
<z3ntu>
I'm also on 5.18. calebccff Did it work with 5.17?
<calebccff>
z3ntu: yeah im pretty sure it did
<Mis012[m]>
yay, bisection time \o/
<calebccff>
I'll ping Amit tomorrow and ask where he's at with that, he might have made some progress
<z3ntu>
indeed it looks better on 5.17.. e.g. `<7>[ 62.404850] geni_i2c 990000.i2c: len:1, slv-addr:0x30, RD/WR:1` and no errors with i2cdetect
<z3ntu>
of course with "i2c: qcom-geni: Add support for GPI DMA" cherry-picked from 5.18, otherwise GPI DMA won't get used
<z3ntu>
the touchscreen driver still isn't happy though and seems to fail to read any register :(
<calebccff>
z3ntu there's a global i2c WHOAMI register iirc, try that maybe?
<z3ntu>
I thought this gpi-dma mode would fix the touchscreens on geni i2c, no? Or is there something else missing still?
<calebccff>
if that doesn't work then probably stuck in reset or something
<z3ntu>
I mean with i2c-gpio the touchscreen works..