Re: [PATCH 2/6] dt-bindings: dma: qcom-gpi: Add QSPI protocol identifier

[Konrad Dybcio]

On 11/12/26 2:57 PM, Krzysztof Kozlowski wrote:
> On 12/11/2026 14:47, Jyothi Kumar Seerapu wrote:
>>
>>
>> On 11/11/2026 6:07 PM, Krzysztof Kozlowski wrote:
>>> On Mon, Nov 09, 2026 at 08:03:29PM +0530, Jyothi Kumar Seerapu wrote:
>>>>
>>>>
>>>> On 11/9/2026 7:12 PM, Krzysztof Kozlowski wrote:
>>>>> On Fri, Nov 06, 2026 at 08:31:20PM +0530, Jyothi Kumar Seerapu wrote:
>>>>>> Add QCOM_GPI_QSPI to identify QSPI (Quad SPI) channels in GPI DMA
>>>>>> specifiers. Its value, 9, matches the GENI serial engine firmware
>>>>>> protocol ID for QSPI.
>>>>>
>>>>> What is GENI serial engine firmware? How does the Linux rely on it that
>>>>> we add bindings for it?
>>>>
>>>> Hi Krzysztof,
>>>> GENI firmware runs on the serial engine’s programmable sequencers and
>>>> implements protocols such as SPI and QSPI. Linux configures the engine and
>>>> submits transfers to it.
>>>> The existing GPI DMA specifier includes a client protocol ID. Linux programs
>>>> this ID into the DMA channel and selects the corresponding descriptor
>>>> format. QCOM_GPI_QSPI adds the QSPI protocol encoding 9 to that interface.
>>>> I will clarify this in the commit description in V2.
>>>
>>> Does not really answer. I see no reason why GENI firmware needs ABI for
>>> Linux.
>>>
>> This extends the existing GPI DMA binding, not a GENI firmware ABI.
> 
> OK, so it is not ABI for the firmware. Period. Let's stop discussing this.

It is a firmware ABI, the various protocols each have their own magic
number and the firmware needs to know the right one. The GPI DMA driver
uses exactly that information and programs it into the core:

gpi_of_dma_xlate():
  gchan->protocol = args->args[2];

gpi_alloc_chan():
  gpi_write_reg(gpii, gpii->regs + GPII_n_CH_k_SCRATCH_0_OFFS(id, chid),
                GPII_n_CH_k_SCRATCH_0(pair_chid, chan->protocol, chan->seid));
							^^

It doesn't necessarily _have to_ be the DT ABI, but since it's
bijective, an identity mapping seems like the sanest choice. The
holes are a result of some of the other protocols not being
supported upstream (yet?).



But we already know this value in most cases (if the firmware is
present). Once upon a time I tried to de-multiplex the GENI nodes:

https://github.com/quic-kdybcio/linux/commits/topic/single_node_genise/

particularly:

https://github.com/quic-kdybcio/linux/commit/02e4671d8f9c3743a8e1a520cae75a455912eca7

which (for x1e80100.dtsi) only keeps a single node per QUP instance
(and not NUM_PROTOCOLS nodes for each one)

But I think for removing this completely we'd need to move this
information into a new property (qcom,protocol?) which would encode
exactly the same value to convey that to the fw loader.

FWIW I can pick up that work again if we agree on the bindings.

Konrad