arm64: dts: qcom: qcm6490-fairphone-fp5: limit DP link-frequency - #34
arm64: dts: qcom: qcm6490-fairphone-fp5: limit DP link-frequency#34panpanpanpaan wants to merge 1 commit into
Conversation
The DP link training fails if higher than this and it doesn't seem to be able to fallback, pinning it to this rate seems to be safe and fix some more complex docks
0909dff to
a7af1c2
Compare
|
In either case please add Signed-off-by: https://docs.kernel.org/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin And can you please give details to what dock you're testing with? It works fine for the devices I have. |
|
I see this patch upstream, seems quite related: https://lore.kernel.org/linux-arm-msm/20260827-x13s-dpaudio-v1-1-da73414c6ab5@oldschoolsolutions.biz/ |
|
I checked the Qualcomm docs and QCM6490 supports 8.1/5.4/2.7/1.62 Gbps per lane And I'm not sure what the current upstream status is but at some point with a patch set from the mailing lists I tried 4-lane DP, which is Max resolution supported should be 3840x2160@60Hz with 24 bpp with two lanes (& USB3.0 active). Or 4096x2160@60Hz with 30 bpp with two lanes (no USB3.0 active) edit: actually small correction, the max link rate is set to HBR2 (5.40 Gbit/s) by default, so it should be able to fall back to lower ones I guess, or however the mechanism is supposed to work. That change I linked explicitly sets the maximum link freq higher, so there should not be much more other change to it. msm_dp_link->max_dp_link_rate = msm_dp_link_link_frequencies(of_node);
if (!msm_dp_link->max_dp_link_rate)
msm_dp_link->max_dp_link_rate = DP_LINK_RATE_HBR2; |
Decompiling the firmware pinned the txq_hw_fill trap: it is a deliberate assert (0x3e5bf0), not a NULL deref. txq_hw_fill lays an A-MPDU's per-MPDU hardware descriptors into 2112-byte "alfrag" pool buffers and panics when the placement needs more alfrag chunks than it pre-budgeted (ceil(D/2112), D = 96*A + 15*(N-A)) - but only when the alfrag pool is starved (pktpool_avail + rsvpool_avail <= 5). The estimate undercounts the real per-MPDU descriptor size, so a large aggregate under pool pressure overruns; the captured panic was at MPDU sc7280-mainline#34 (34*~64 = 2176 > 2112), verified via lr=0x3e5de5 and the sb/r6/r8 register triple. The host cannot resize the firmware's alfrag pool, but it can bound the aggregate. Cap the block-ack window and per-A-MPDU MPDU count to 16 so the descriptor placement always fits one 2112-byte chunk with margin and can never overrun the budget, whatever the pool state. Supersedes the ba_wsize=64 setting, which still allowed the overrun. Assisted-by: Claude:claude-opus-4-8
2 participants
The DP link training fails if higher than this and it doesn't seem to be able to fallback, pinning it to this rate seems to be safe and fix some more complex docks