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

[Konrad Dybcio]

On 6/19/26 2:50 PM, Icenowy Zheng wrote:
> 在 2026-06-19五的 14:27 +0200，Konrad Dybcio写道：
>> On 6/18/26 12:34 PM, Icenowy Zheng wrote:
>>> 在 2026-06-18四的 11:05 +0200，Konrad Dybcio写道：
>>>> On 6/18/26 11:04 AM, Konrad Dybcio wrote:
>>>>> 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@xxxxxxxxxxx> 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?
>>>>
>>>> i.e. now, is requesting these channels through (wrongfully)
>>>> enabling
>>>> the devices in DT the only remaining concern?
>>>
>>> Yes, I think so; although I think few devices will use GPI on these
>>> devices (usually only one or two SPI controllers according to the
>>> DSDTs).
>>
>> IIRC there's a configuration table that lets OEMs decide which ones
>> should fall under the secure umbrella (although most never seem to
>> change the defaults).
> 
> Ah then what's the default value?
> 
> Radxa Dragon Q8B seems to have GPII0-5 enabled for all GPI controllers

This matches what I can find in the default config

Konrad