<jstultz>
bamse: sorry, have another db845c dts change regression.. :(
<jstultz>
bamse: i suspect folks dgaf (same happened on hikey960), so i'll try to figure out something in userland... but i'm back on my dts node breakage griping bs. :)
<bamse>
jstultz: sorry about that, i had completely forgotten that the node name is used in the udc naming :/
<jstultz>
bamse: not your fault, when i raised the issue earlier w/ the hikey960 they basically told me to change it in userland.. :P
<jstultz>
bamse: so i should have expected it to hit db845c, but I was under the impression db845c had it "right" from the beginning so it was just hikey960 that was dealing with the chagne
<jstultz>
but i didn't look closely
<bamse>
well, the firmware issue we had a couple of releases ago, there i wanted the change because it never really worked..here it's just a cosmetic thing
<jstultz>
bamse: i'm reaching out to folks on the android team w/ greg cc'ed to see what the best fix in userland might be
<bamse>
yeah, it was dwc3@ in accordance to the binding all along...but then they decided to "standardize" the dwc3->usb
<jstultz>
bamse: i get that having it consistent makes it easier for generic distros to find it...
<bamse>
we had to patch some stuff in the dwc3-qcom driver to get there even...
<jstultz>
but its still a pain and generic distros probably have to deal with older kernels too
<bamse>
well, the fact that udc names includes the mmio address means that it isn't generic anyways
<jstultz>
yea
<jstultz>
it all reminds me of the hda -> sda rename pain from back in the day
<bamse>
so to bind your usb gadget you need to know which magic name matches which port on the particular board you're on
<bamse>
hehe, yeah but for block devices we have uuid and partlabel, which have many other benefits as well
<bamse>
jstultz: but did the name change land ing v5.14-rc1 or v5.13?
<jstultz>
bamse: 5.14-rc1 for db845c
<jstultz>
bamse: the hikey960 one was back in dec
<bamse>
jstultz: right, the binding update came in 5.13...but i couldn't merge the qualcomm dts changes becuase we needed dwc3-qcom to be updated first
marvin24_ has joined #linux-msm
marvin24 has quit [Ping timeout: 480 seconds]
cmeerw has joined #linux-msm
quarkyalice__ has quit [Quit: Leaving]
quarkyalice has joined #linux-msm
cmeerw has quit [Ping timeout: 480 seconds]
pevik has joined #linux-msm
<konradybcio>
bamse I was meaning to use the mdm9607 device as a regular modem, adding some kind of a minimal userspace for it with required daemons to keep it... a modem..
<konradybcio>
the target user of it is the pinephone, so it has to expose some interface to mm/ofono via usb
svarbanov has joined #linux-msm
silver has joined #linux-msm
silver has quit []
svarbanov has quit [Ping timeout: 480 seconds]
svarbanov has joined #linux-msm
silver has joined #linux-msm
<bamse>
konradybcio: so you're able to replace the firmware in your mdm9607 in the pinephone?
<bamse>
konradybcio: or you're saying that you want android to speak with the mdm9607 in your pinephone?
<konradybcio>
i want linux to speak to it
<konradybcio>
nobody runs android on the pinephone
<bamse>
pcie?
<konradybcio>
but i guess we mean the same thing yes
<konradybcio>
no, usb
<konradybcio>
it's an quectel EG25
<bamse>
hmm, then libqmi and modemmanager should do the trick
<bamse>
possibly libmbim, depending on what quectel decided to expose
<konradybcio>
i don't think we can use the hacked-together blobbed to oblivion downstream userland with mainline
<konradybcio>
unless we can?
<bamse>
i don't think you need to
<minecrell>
bamse: it still sounds a bit like you're talking about the Linux on the PinePhone CPU, while konradybcio probably means the Linux on the MDM9607
<konradybcio>
yes, sorry if that wasn't clear
<bamse>
minecrell: i'm confused
<minecrell>
so you'd mainly need some USB gadget setup I guess
<bamse>
konradybcio: ohh, yeah no that wasn't clear to me :)
<bamse>
sorry
<konradybcio>
pinephone has an allwinner cpu and an external usb modem that has a mdm9607
<bamse>
okay, and you're replacing linux on the mdm9607, have data connectivity, but want to share that with the linux host?
<konradybcio>
yes, i want it to be presented as a generic usb modem to the phone
<konradybcio>
data and calls
<bamse>
i see, that makes sense
<minecrell>
bamse: Linaro seems to be doing work on the SDX55/SDX65 which should be in a similar situation (except PCI instead of USB)
<minecrell>
So I think konradybcio was curious what you're running there
<bamse>
right, we're approaching the same problem
<minecrell>
(That's how I understood the original question)
<konradybcio>
yes i should work on my communication skills
<bamse>
but we're still having problems establishing the data call...
<minecrell>
oh fun
<minecrell>
like directly on the Linux running in the modem?
<minecrell>
or already via PCI
<konradybcio>
on the 9607 i cannot power up the modem due to some scm call being not happy but i haven't touched it for a while and each degree celcius inside makes me 10x less productive heh
<bamse>
off-the-shelf sdx55 attached works fine
<konradybcio>
*off-the-shelf sdx55 not on 8250 :D
<bamse>
konradybcio: right, on 8250 we still have the esoc framework stuff to deal with
<bamse>
konradybcio: but the sdx55 in my lenovo flex 5g comes up nicely (and then stops responding after a few 100mb of traffic)
<konradybcio>
[sadly] don't have any qc laptops so can
<konradybcio>
can't relate*
<bamse>
but as we're running our own software on the arm core in the sdx55, the start_network QMI message sent to the modem fails
<konradybcio>
but that does sound like an usual some-obscure-downstream-hack-is-missing situation
<bamse>
konradybcio: well it works there because of efforts to connect sdx55 to x86 machines
<bamse>
konradybcio: it certainly does, so we're trying to debug it...
<bamse>
well, mani_s is trying to debug it
<konradybcio>
maybe it's some dumb thing like an icc path that needs to be voted for higher bw
<minecrell>
bamse: Do you already send those QMI messages via PCI or from the modem directly? Like, do you already have some "PCI gadget" driver that forwards things? (not sure how it's called in the PCI world)
<bamse>
konradybcio: no it fails with an error code, so it's unhappy with something
<bamse>
minecrell: mani_s is working on "pcie endpoint" support, so that will allow us to talk to some app in linux running on the sdx55 - to make it setup the data call
<minecrell>
I see
<bamse>
i.e. once we have the pcie endpoint and the data call in place, i think we're pretty much at the same place as konradybcio is
<minecrell>
bamse: So you suspect the "start_network QMI" problem is related to the PCI endpoint driver?
<mani_s>
minecrell, no, that's something to do with ipa/3gpp config
<bamse>
minecrell: no we'e developing that on the thundercomm t55 board, which is a standalone sdx55
<konradybcio>
right, ipa can be an unseen blocker too
<konradybcio>
that was the case on msm8998
<konradybcio>
after adding ipa support, all the network stuff automagically started working
<bamse>
konradybcio: ipa seems to initalize just fine, but the start_network fails with "something (specific) is wrong"...and apparently there's various things that can cause that response
<minecrell>
ah
<bamse>
and it seems to fall inbetween the data guys and ipa guys at qualcomm...so mani_s is still working on it :/
<minecrell>
I think Qualcomm is intentionally adding some obstacles there so one definitely gets frustrated trying to make the modem work :P
<konradybcio>
qualcomm doing things to prevent people from tinkering with their devices? are you crazy man?
<bamse>
minecrell: yes, the DPM open port is required, and it's in there
<bamse>
and not having it results in a different failure
<bamse>
well at least on sdm845...
cmeerw has joined #linux-msm
<mani_s>
minecrell, yeah I did use them
<minecrell>
Well, looks like Qualcomm had nice new ideas then :/
<mani_s>
but as bamse said it fails at start network interface time
<mani_s>
and I'm not able to capture the modem logs properly for debugging
<konradybcio>
doesn't it store logs in like ipc_log?
<konradybcio>
or is it a thing of the past?
<minecrell>
konradybcio: Did you ever manage to get a useful log from the modem? :P
pevik has quit [Ping timeout: 480 seconds]
quarkyalice has quit [Ping timeout: 480 seconds]
<DavidHeidelberg[m]>
Hello guys, since 5.9 I'm getting `CPU: 0 PID: 34 at drivers/gpu/drm/drm_vblank.c:1194 drm_vblank_put+0x170/0x174
<DavidHeidelberg[m]>
` and also when display goes off, it won't get back (but that's happening since more earlier versions). Any ideas where to look first? It's ofc issue in MDP4 (since I assume MDP5 works just fine)
<DavidHeidelberg[m]>
line ```
<DavidHeidelberg[m]>
if (drm_WARN_ON(dev, atomic_read(&vblank->refcount) == 0))
<DavidHeidelberg[m]>
```
Danct12 has quit [Remote host closed the connection]
<DavidHeidelberg[m]>
robclark ^ the original code I removed should be based on your 2014 code, any ideas? Can I sent this to ML or should I handle it differently?
<robclark>
I don't think that is what you want.. unless there is somewhere else that is enabling vblank
<DavidHeidelberg[m]>
the drm_WARN_ON is triggered by mdp4_complete_commit and none of other drivers do something similar
<robclark>
mdp5 does something similar from `mdp5_crtc_wait_for_commit_done()`.. but looks like it is complaining about unbalanced gets and puts
<robclark>
so the question is, how does that happen
<robclark>
hmm, ok, so that might not be required anymore, since msm_atomic.c is doing vblank get/puts
<robclark>
still, I wouldn't _expect_ to end up in a situation where the get/put mdp4 does is unbalanced
<DavidHeidelberg[m]>
robclark about unbalanced part - that's the vblank time out warning or the drm_WARN_ON ?
<robclark>
the drm_WARN_ON()
<robclark>
if vblanks get disabled when we need them to be enabled, that could cause timeouts waiting for a vblank that never comes, and other sorts of problems
<DavidHeidelberg[m]>
it's persistent since 5.9, at same time in boot process
<DavidHeidelberg[m]>
and the timeouts has been present for many kernels, I'll check
<DavidHeidelberg[m]>
vblank timeout showed up between 4.19 and 5.4
<robclark>
I wonder a bit about the earlier (seemingly) irq related splat.. check /proc/interrupts to see if we are getting *any* mdp irqs?
<robclark>
hmm, I think that is ok.. ` 40: 25272 0 0 0 GIC-0 107 Level msm`
svarbanov has quit [Ping timeout: 480 seconds]
<DavidHeidelberg[m]>
rebooted again with that patch, and no warnings or issue, it's 99.9% triggered by the code
<DavidHeidelberg[m]>
no sideeffects, just haven't tried Weston :)
silver has quit [Quit: One for all, all for One (2 Corinthians 5)]
<robclark>
it looks like it should probably be ok to drop the vblank get/put in mdp4, since it is done in msm_atomic.c these days.. but you should probably also just remove `mdp4_prepare_commit()`/`mdp4_complete_commit()` completely
<robclark>
still, I'm not seeing an obvious cause for unbalanced get/put
<DavidHeidelberg[m]>
<robclark "it looks like it should probably"> I tried, but got crash when driver loads I probably need to replace it with some default function?