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

[Icenowy Zheng <zhengxingda@iscas.ac.cn>]

在 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@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?
> > > 
> > > 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
[1].

Thanks,
Icenowy

[1]
https://github.com/strongtz/linux-radxa-qcom/commit/99878a41264ef4f2a77783676de36a80de7103ba

> 
> I don't think we need to care too much about the mask being ultra-
> correct,
> since as we've established only QUPs are "valid" consumers and we're
> not
> going to enable them globally by default, since there are conflicting
> pin
> assignments (i.e. there are many more QUPs than allocated GPIOs)
> 
> Konrad