Re: [PATCH 0/6] arm64: dts: qcom: sc8280xp: set GPI DMA channels according to DSDT

[Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>]

On 6/9/26 5:54 PM, Icenowy Zheng wrote:
> 在 2026-06-09二的 14:23 +0200，Konrad Dybcio写道：
>> On 6/7/26 10:49 AM, Icenowy Zheng wrote:
>>> 在 2026-06-06六的 21:51 +0800，Pengyu Luo写道：
>>>> On Sat, Jun 6, 2026 at 9:21 PM Icenowy Zheng
>>>> <zhengxingda@iscas.ac.cn> wrote:
>>>>>
>>>>> 在 2026-06-06六的 17:46 +0800，Pengyu Luo写道：
>>>>>> On 2026-06-06 17:28:35+08:00, Icenowy Zheng wrote:
>>>>>>> 在 2026-06-06六的 17:22 +0800，Pengyu Luo写道：
>>>>>>>
>>>>>>>> On 2026-06-02 21:21:27+08:00, Icenowy Zheng wrote:
>>>>>>>>
>>>>>>>> The magnetic keyboard (USB HID) can't be connected
>>>>>>>> somehow,
>>>>>>>> others
>>>>>>>> are
>>>>>>>> fine, such as the spi touchscreen (not upstream yet),
>>>>>>>> which
>>>>>>>> utilizes
>>>>>>>> DMA definitely. My config is here
>>>>>>>> https://pastebin.com/SdjuyJYk
>>>>>>>
>>>>>>> Is this a defconfig?
>>>>>>>
>>>>>>
>>>>>> Yes.
>>>>>>
>>>>>>> BTW it seems that CONFIG_ASYNC_TX_DMA needs to be selected
>>>>>>> too
>>>>>>> for
>>>>>>> exhibiting the problem (because there should be "public"
>>>>>>> GPI
>>>>>>> DMA
>>>>>>> consumers to trigger the stuck/reset).
>>>>>>>
>>>>>>
>>>>>> Is this still necessary? I checked the fedora discussion and
>>>>>> your
>>>>>> GPI
>>>>>> DMA fix. And GPI DMA is only for the QUP-supported
>>>>>> peripherals as
>>>>>> the
>>>>>> binding mentioned, devicetree/bindings/dma/qcom,gpi.yaml
>>>>>
>>>>> The devicetree without this fix seems to be still incorrect,
>>>>> because
>>>>> with the device tree fix even if the GPI DMA driver misbehaves
>>>>> the
>>>>> system won't be stuck (although it will iterate all GPI
>>>>> channels
>>>>> and
>>>>> then fail to function at all).
>>>>>
>>>>
>>>> Back to the start. You said some GPI interfaces aren't available
>>>> to
>>>> HLOS, your mask is 0xb(0b1011), so I use 0x4(0b100) did a quick
>>>> test,
>>>> and spi6 consumed it, no stuck or reset. Could you give me a
>>>> unavailable channel?
>>>
>>> I think channel 0b10000 of gpi_dma2 could be an example?
>>>
>>> It seems that 4 channels are tried on gpi_dma2 before hang on my
>>> gaokun3, but as gaokun3 has no known serial access, it's possible
>>> that
>>> 0b100000 or 0b1000 is problematic.
>>>
>>> (The reason gpi_dma2 is checked first is because it's the GPI DMA
>>> controller with the smallest address)
>>>
>>> BTW I just took the values from Windows DSDT, which is quite
>>> conservative.
>>
>> So, with DMA_PRIVATE set, is this series made redundant?
> 
> I assume technically the trustzone is still protecting some channels,
> although the system stuck issue is fixed.
> 
> This series should still be relevant, although not so emergent.

So now we're down to the case of the TZ reserving some of the GPI
channels (presumably for locked down/TZ-driven QUPs) crashing the
device on access, is that right?

Konrad