[PATCH 1/2] spi: dt-bindings: qcom,spi-geni-qcom: Add property to force GSI mode

[PATCH 1/2] spi: dt-bindings: qcom,spi-geni-qcom: Add property to force GSI mode

[Pengyu Luo]

Some devices (such as gaokun3) do not disable FIFO mode, causing the
driver to fallback to FIFO mode by default. However, these platforms
also support GSI mode, which is highly preferred for certain
peripherals like SPI touchscreens to improve performance.

Introduce the "qcom,force-gsi-mode" device property to hint and force
the controller into GSI mode during initialization.

Signed-off-by: Pengyu Luo <mitltlatltl@gmail.com>
---
 .../devicetree/bindings/spi/qcom,spi-geni-qcom.yaml          | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/spi/qcom,spi-geni-qcom.yaml b/Documentation/devicetree/bindings/spi/qcom,spi-geni-qcom.yaml
index edf399681d7a..80e394c1c715 100644
--- a/Documentation/devicetree/bindings/spi/qcom,spi-geni-qcom.yaml
+++ b/Documentation/devicetree/bindings/spi/qcom,spi-geni-qcom.yaml
@@ -45,6 +45,11 @@ properties:
       - const: tx
       - const: rx
 
+  qcom,force-gsi-mode:
+    $ref: /schemas/types.yaml#/definitions/flag
+    description:
+      Use DMA (GSI) mode, even if FIFO mode is not disabled.
+
   interconnects:
     minItems: 2
     maxItems: 3
-- 
2.54.0

[PATCH 2/2] spi: qcom-geni: Add property to force GSI mode

[Pengyu Luo]

Some devices (such as gaokun3) do not disable FIFO mode, causing the
driver to fallback to FIFO mode by default. However, these platforms
also support GSI mode, which is highly preferred for certain
peripherals like SPI touchscreens to improve performance.

Introduce the "qcom,force-gsi-mode" device property to hint and force
the controller into GSI mode during initialization.

Signed-off-by: Pengyu Luo <mitltlatltl@gmail.com>
---
 drivers/spi/spi-geni-qcom.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/spi/spi-geni-qcom.c b/drivers/spi/spi-geni-qcom.c
index 26e723cfea61..eece7312f780 100644
--- a/drivers/spi/spi-geni-qcom.c
+++ b/drivers/spi/spi-geni-qcom.c
@@ -102,6 +102,7 @@ struct spi_geni_master {
 	int irq;
 	bool cs_flag;
 	bool abort_failed;
+	bool force_gsi_mode;
 	struct dma_chan *tx;
 	struct dma_chan *rx;
 	int cur_xfer_mode;
@@ -655,6 +656,9 @@ static int spi_geni_init(struct spi_geni_master *mas)
 		mas->oversampling = 1;
 
 	fifo_disable = readl(se->base + GENI_IF_DISABLE_RO) & FIFO_IF_DISABLE;
+	if (mas->force_gsi_mode)
+		fifo_disable = 1;
+
 	switch (fifo_disable) {
 	case 1:
 		ret = spi_geni_grab_gpi_chan(mas);
@@ -1133,6 +1137,9 @@ static int spi_geni_probe(struct platform_device *pdev)
 	if (ret)
 		return ret;
 
+	if (device_property_read_bool(&pdev->dev, "qcom,force-gsi-mode"))
+		mas->force_gsi_mode = true;
+
 	ret = spi_geni_init(mas);
 	if (ret)
 		return ret;
-- 
2.54.0

Re: [PATCH 2/2] spi: qcom-geni: Add property to force GSI mode

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Forcing GSI mode via `qcom,force-gsi-mode` fails to update the hardware configuration registers (`SE_FIFO_IF_DISABLE` and `SE_DMA_IF_EN`), leaving the hardware and software in inconsistent states.
- [Medium] The new `qcom,force-gsi-mode` property is functionally redundant and bypasses the existing `qcom,enable-gsi-dma` property, muddying the device tree bindings.
--

commit 7902ba1d5ce1661e61400f2f7a40e6f1185b3264
Author: Pengyu Luo <mitltlatltl@gmail.com>

spi: qcom-geni: Add property to force GSI mode

This commit introduces a "qcom,force-gsi-mode" property to force the
controller into GSI mode during initialization for devices that do not
disable FIFO mode by default.

> diff --git a/drivers/spi/spi-geni-qcom.c b/drivers/spi/spi-geni-qcom.c
> index 26e723cfea61e..eece7312f7805 100644
> --- a/drivers/spi/spi-geni-qcom.c
> +++ b/drivers/spi/spi-geni-qcom.c
[ ... ]
> @@ -655,6 +656,9 @@ static int spi_geni_init(struct spi_geni_master *mas)
>  		mas->oversampling = 1;
>  
>  	fifo_disable = readl(se->base + GENI_IF_DISABLE_RO) & FIFO_IF_DISABLE;
> +	if (mas->force_gsi_mode)
> +		fifo_disable = 1;
> +

[Severity: High]
Does overriding this local variable actually configure the hardware for GSI DMA
mode?

Looking at the hardware initialization, geni_load_se_fw() is the only place
where SE_FIFO_IF_DISABLE and SE_DMA_IF_EN are written. By just overriding
fifo_disable here, the driver will attempt to use GENI_GPI_DMA mode while
the hardware's core FIFO interface might still be enabled and the DMA
interface disabled.

Could this lead to DMA failures, timeouts, or lockups since the software and
hardware states are inconsistent?

>  	switch (fifo_disable) {
>  	case 1:
>  		ret = spi_geni_grab_gpi_chan(mas);
[ ... ]
> @@ -1133,6 +1137,9 @@ static int spi_geni_probe(struct platform_device *pdev)
>  	if (ret)
>  		return ret;
>  
> +	if (device_property_read_bool(&pdev->dev, "qcom,force-gsi-mode"))
> +		mas->force_gsi_mode = true;
> +

[Severity: Medium]
Is this new property functionally redundant?

The subsystem already supports the qcom,enable-gsi-dma device tree property
to configure GSI DMA mode, which is parsed in geni_load_se_firmware().

Would introducing qcom,force-gsi-mode create overlapping bindings for the
same hardware configuration and pollute the device tree ABI?

It seems this new property might be introduced to work around an internal
software parsing order issue where geni_load_se_firmware() is skipped if the
firmware is already loaded.

>  	ret = spi_geni_init(mas);
>  	if (ret)
>  		return ret;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260614083424.464132-1-mitltlatltl@gmail.com?part=2

Re: [PATCH 2/2] spi: qcom-geni: Add property to force GSI mode

[Dmitry Baryshkov]

On Sun, Jun 14, 2026 at 04:34:24PM +0800, Pengyu Luo wrote:
> Some devices (such as gaokun3) do not disable FIFO mode, causing the
> driver to fallback to FIFO mode by default. However, these platforms
> also support GSI mode, which is highly preferred for certain
> peripherals like SPI touchscreens to improve performance.
> 
> Introduce the "qcom,force-gsi-mode" device property to hint and force
> the controller into GSI mode during initialization.

Ideally, this should be decided by the SPI controller based on the
requirements. Another option would be to prefer GSI for all transfers if
it is available, ignoring the FIFO even if it is not disabled.

> 
> Signed-off-by: Pengyu Luo <mitltlatltl@gmail.com>
> ---
>  drivers/spi/spi-geni-qcom.c | 7 +++++++
>  1 file changed, 7 insertions(+)
> 

-- 
With best wishes
Dmitry

Re: [PATCH 2/2] spi: qcom-geni: Add property to force GSI mode

[Pengyu Luo]

On Mon, Jun 15, 2026 at 5:18 AM Dmitry Baryshkov
<dmitry.baryshkov@oss.qualcomm.com> wrote:
>
> On Sun, Jun 14, 2026 at 04:34:24PM +0800, Pengyu Luo wrote:
> > Some devices (such as gaokun3) do not disable FIFO mode, causing the
> > driver to fallback to FIFO mode by default. However, these platforms
> > also support GSI mode, which is highly preferred for certain
> > peripherals like SPI touchscreens to improve performance.
> >
> > Introduce the "qcom,force-gsi-mode" device property to hint and force
> > the controller into GSI mode during initialization.
>
> Ideally, this should be decided by the SPI controller based on the
> requirements. Another option would be to prefer GSI for all transfers if
> it is available, ignoring the FIFO even if it is not disabled.
>

I have read reviews. Can we check if the compatible
"qcom,sm6350-gpi-dma" is in DT? If the gpi dma controller is
presented, then we enable GSI mode.

Best wishes,
Pengyu

> >
> > Signed-off-by: Pengyu Luo <mitltlatltl@gmail.com>
> > ---
> >  drivers/spi/spi-geni-qcom.c | 7 +++++++
> >  1 file changed, 7 insertions(+)
> >
>
> --
> With best wishes
> Dmitry

Re: [PATCH 2/2] spi: qcom-geni: Add property to force GSI mode

[Konrad Dybcio]

On 6/15/26 6:25 AM, Pengyu Luo wrote:
> On Mon, Jun 15, 2026 at 5:18 AM Dmitry Baryshkov
> <dmitry.baryshkov@oss.qualcomm.com> wrote:
>>
>> On Sun, Jun 14, 2026 at 04:34:24PM +0800, Pengyu Luo wrote:
>>> Some devices (such as gaokun3) do not disable FIFO mode, causing the
>>> driver to fallback to FIFO mode by default. However, these platforms
>>> also support GSI mode, which is highly preferred for certain
>>> peripherals like SPI touchscreens to improve performance.
>>>
>>> Introduce the "qcom,force-gsi-mode" device property to hint and force
>>> the controller into GSI mode during initialization.
>>
>> Ideally, this should be decided by the SPI controller based on the
>> requirements. Another option would be to prefer GSI for all transfers if
>> it is available, ignoring the FIFO even if it is not disabled.
>>
> 
> I have read reviews. Can we check if the compatible
> "qcom,sm6350-gpi-dma" is in DT? If the gpi dma controller is
> presented, then we enable GSI mode.


This hunk is very odd:

/*
 * in case of failure to get gpi dma channel, we can still do the
 * FIFO mode, so fallthrough
 */
dev_warn(mas->dev, "FIFO mode disabled, but couldn't get DMA, fall back to FIFO mode\n");

In my understanding, GSI DMA mode is always preferable. +Mukesh, do
you have any insights?

Konrad

Re: [PATCH 2/2] spi: qcom-geni: Add property to force GSI mode

[Mukesh Savaliya]

Hi Konrad, sorry for late response.

On 6/15/2026 5:12 PM, Konrad Dybcio wrote:
> On 6/15/26 6:25 AM, Pengyu Luo wrote:
>> On Mon, Jun 15, 2026 at 5:18 AM Dmitry Baryshkov
>> <dmitry.baryshkov@oss.qualcomm.com> wrote:
>>>
>>> On Sun, Jun 14, 2026 at 04:34:24PM +0800, Pengyu Luo wrote:
>>>> Some devices (such as gaokun3) do not disable FIFO mode, causing the
>>>> driver to fallback to FIFO mode by default. However, these platforms
>>>> also support GSI mode, which is highly preferred for certain
>>>> peripherals like SPI touchscreens to improve performance.
>>>>
>>>> Introduce the "qcom,force-gsi-mode" device property to hint and force
>>>> the controller into GSI mode during initialization.
>>>
>>> Ideally, this should be decided by the SPI controller based on the
>>> requirements. Another option would be to prefer GSI for all transfers if
>>> it is available, ignoring the FIFO even if it is not disabled.
>>>
>>
>> I have read reviews. Can we check if the compatible
>> "qcom,sm6350-gpi-dma" is in DT? If the gpi dma controller is
>> presented, then we enable GSI mode.
> 
> 
> This hunk is very odd:
> 
> /*
>   * in case of failure to get gpi dma channel, we can still do the
>   * FIFO mode, so fallthrough
>   */
> dev_warn(mas->dev, "FIFO mode disabled, but couldn't get DMA, fall back to FIFO mode\n");
> 
> In my understanding, GSI DMA mode is always preferable. +Mukesh, do
> you have any insights?
> 
GSI mode is preferable but if for some reason it fails, we try to 
continue with the FIFO mode. Just fallback mechanism.
> Konrad

Re: [PATCH 2/2] spi: qcom-geni: Add property to force GSI mode

[Konrad Dybcio]

On 6/25/26 11:06 AM, Mukesh Savaliya wrote:
> Hi Konrad, sorry for late response.
> 
> On 6/15/2026 5:12 PM, Konrad Dybcio wrote:
>> On 6/15/26 6:25 AM, Pengyu Luo wrote:
>>> On Mon, Jun 15, 2026 at 5:18 AM Dmitry Baryshkov
>>> <dmitry.baryshkov@oss.qualcomm.com> wrote:
>>>>
>>>> On Sun, Jun 14, 2026 at 04:34:24PM +0800, Pengyu Luo wrote:
>>>>> Some devices (such as gaokun3) do not disable FIFO mode, causing the
>>>>> driver to fallback to FIFO mode by default. However, these platforms
>>>>> also support GSI mode, which is highly preferred for certain
>>>>> peripherals like SPI touchscreens to improve performance.
>>>>>
>>>>> Introduce the "qcom,force-gsi-mode" device property to hint and force
>>>>> the controller into GSI mode during initialization.
>>>>
>>>> Ideally, this should be decided by the SPI controller based on the
>>>> requirements. Another option would be to prefer GSI for all transfers if
>>>> it is available, ignoring the FIFO even if it is not disabled.
>>>>
>>>
>>> I have read reviews. Can we check if the compatible
>>> "qcom,sm6350-gpi-dma" is in DT? If the gpi dma controller is
>>> presented, then we enable GSI mode.
>>
>>
>> This hunk is very odd:
>>
>> /*
>>   * in case of failure to get gpi dma channel, we can still do the
>>   * FIFO mode, so fallthrough
>>   */
>> dev_warn(mas->dev, "FIFO mode disabled, but couldn't get DMA, fall back to FIFO mode\n");
>>
>> In my understanding, GSI DMA mode is always preferable. +Mukesh, do
>> you have any insights?
>>
> GSI mode is preferable but if for some reason it fails, we try to continue with the FIFO mode. Just fallback mechanism.

So, would making GSI the default and FIFO the fallback option
sound good?

Konrad

Re: [PATCH 2/2] spi: qcom-geni: Add property to force GSI mode

[Pengyu Luo]

On Fri, Jun 26, 2026 at 11:34 PM Konrad Dybcio
<konrad.dybcio@oss.qualcomm.com> wrote:
>
> On 6/25/26 11:06 AM, Mukesh Savaliya wrote:
> > Hi Konrad, sorry for late response.
> >
> > On 6/15/2026 5:12 PM, Konrad Dybcio wrote:
> >> On 6/15/26 6:25 AM, Pengyu Luo wrote:
> >>> On Mon, Jun 15, 2026 at 5:18 AM Dmitry Baryshkov
> >>> <dmitry.baryshkov@oss.qualcomm.com> wrote:
> >>>>
> >>>> On Sun, Jun 14, 2026 at 04:34:24PM +0800, Pengyu Luo wrote:
> >>>>> Some devices (such as gaokun3) do not disable FIFO mode, causing the
> >>>>> driver to fallback to FIFO mode by default. However, these platforms
> >>>>> also support GSI mode, which is highly preferred for certain
> >>>>> peripherals like SPI touchscreens to improve performance.
> >>>>>
> >>>>> Introduce the "qcom,force-gsi-mode" device property to hint and force
> >>>>> the controller into GSI mode during initialization.
> >>>>
> >>>> Ideally, this should be decided by the SPI controller based on the
> >>>> requirements. Another option would be to prefer GSI for all transfers if
> >>>> it is available, ignoring the FIFO even if it is not disabled.
> >>>>
> >>>
> >>> I have read reviews. Can we check if the compatible
> >>> "qcom,sm6350-gpi-dma" is in DT? If the gpi dma controller is
> >>> presented, then we enable GSI mode.
> >>
> >>
> >> This hunk is very odd:
> >>
> >> /*
> >>   * in case of failure to get gpi dma channel, we can still do the
> >>   * FIFO mode, so fallthrough
> >>   */
> >> dev_warn(mas->dev, "FIFO mode disabled, but couldn't get DMA, fall back to FIFO mode\n");
> >>
> >> In my understanding, GSI DMA mode is always preferable. +Mukesh, do
> >> you have any insights?
> >>
> > GSI mode is preferable but if for some reason it fails, we try to continue with the FIFO mode. Just fallback mechanism.
>
> So, would making GSI the default and FIFO the fallback option
> sound good?
>

Yes, I have sent v2, please check here
https://lore.kernel.org/linux-arm-msm/20260616122605.668908-1-mitltlatltl@gmail.com

Best wishes,
Pengyu

> Konrad
>

Re: [PATCH 2/2] spi: qcom-geni: Add property to force GSI mode

[Mukesh Savaliya]

On 6/27/2026 10:52 AM, Pengyu Luo wrote:
[...]
>>>> This hunk is very odd:
>>>>
>>>> /*
>>>>    * in case of failure to get gpi dma channel, we can still do the
>>>>    * FIFO mode, so fallthrough
>>>>    */
>>>> dev_warn(mas->dev, "FIFO mode disabled, but couldn't get DMA, fall back to FIFO mode\n");
>>>>
>>>> In my understanding, GSI DMA mode is always preferable. +Mukesh, do
>>>> you have any insights?
>>>>
>>> GSI mode is preferable but if for some reason it fails, we try to continue with the FIFO mode. Just fallback mechanism.
>>
>> So, would making GSI the default and FIFO the fallback option
>> sound good?
>>
> 
> Yes, I have sent v2, please check here
> https://lore.kernel.org/linux-arm-msm/20260616122605.668908-1-mitltlatltl@gmail.com
> 
Just Reviewed and Commented on V2.
> Best wishes,
> Pengyu
> 
>> Konrad
>>

Re: [PATCH 2/2] spi: qcom-geni: Add property to force GSI mode

[Dmitry Baryshkov]

On Mon, Jun 15, 2026 at 12:25:32PM +0800, Pengyu Luo wrote:
> On Mon, Jun 15, 2026 at 5:18 AM Dmitry Baryshkov
> <dmitry.baryshkov@oss.qualcomm.com> wrote:
> >
> > On Sun, Jun 14, 2026 at 04:34:24PM +0800, Pengyu Luo wrote:
> > > Some devices (such as gaokun3) do not disable FIFO mode, causing the
> > > driver to fallback to FIFO mode by default. However, these platforms
> > > also support GSI mode, which is highly preferred for certain
> > > peripherals like SPI touchscreens to improve performance.
> > >
> > > Introduce the "qcom,force-gsi-mode" device property to hint and force
> > > the controller into GSI mode during initialization.
> >
> > Ideally, this should be decided by the SPI controller based on the
> > requirements. Another option would be to prefer GSI for all transfers if
> > it is available, ignoring the FIFO even if it is not disabled.
> >
> 
> I have read reviews. Can we check if the compatible
> "qcom,sm6350-gpi-dma" is in DT? If the gpi dma controller is
> presented, then we enable GSI mode.

Can we just check for the dmas property? If it is present and if we
could get DMA channels, then GSI DMA is available.

> 
> Best wishes,
> Pengyu
> 
> > >
> > > Signed-off-by: Pengyu Luo <mitltlatltl@gmail.com>
> > > ---
> > >  drivers/spi/spi-geni-qcom.c | 7 +++++++
> > >  1 file changed, 7 insertions(+)
> > >
> >
> > --
> > With best wishes
> > Dmitry

-- 
With best wishes
Dmitry

Re: [PATCH 2/2] spi: qcom-geni: Add property to force GSI mode

[Mukesh Savaliya]

Hi Pengyu,

On 6/15/2026 2:48 AM, Dmitry Baryshkov wrote:
> On Sun, Jun 14, 2026 at 04:34:24PM +0800, Pengyu Luo wrote:
>> Some devices (such as gaokun3) do not disable FIFO mode, causing the
>> driver to fallback to FIFO mode by default. However, these platforms
>> also support GSI mode, which is highly preferred for certain
>> peripherals like SPI touchscreens to improve performance.
>>
>> Introduce the "qcom,force-gsi-mode" device property to hint and force
>> the controller into GSI mode during initialization.
Why to force ? You can directly configure in GSI mode. Note there are 
some configuration done prior to Linux bootup too.
> 
> Ideally, this should be decided by the SPI controller based on the
> requirements. Another option would be to prefer GSI for all transfers if
> it is available, ignoring the FIFO even if it is not disabled.
> 
Yes, it should be decided in advance and configured accordingly for GSI 
vs non GSI mode. Because there would be limited set of GSI pipes, which 
will actually make must have GSI mode device run with FIFO mode.

Why don't you decide prior and configure for GSI mode ? We don't need to 
change the current logic of deciding FIFO vs GSI.
>>
>> Signed-off-by: Pengyu Luo <mitltlatltl@gmail.com>
>> ---
>>   drivers/spi/spi-geni-qcom.c | 7 +++++++
>>   1 file changed, 7 insertions(+)
>>
> 

Re: [PATCH 2/2] spi: qcom-geni: Add property to force GSI mode

[Pengyu Luo]

On Mon, Jun 29, 2026 at 1:36 PM Mukesh Savaliya
<mukesh.savaliya@oss.qualcomm.com> wrote:
>
> Hi Pengyu,
>
> On 6/15/2026 2:48 AM, Dmitry Baryshkov wrote:
> > On Sun, Jun 14, 2026 at 04:34:24PM +0800, Pengyu Luo wrote:
> >> Some devices (such as gaokun3) do not disable FIFO mode, causing the
> >> driver to fallback to FIFO mode by default. However, these platforms
> >> also support GSI mode, which is highly preferred for certain
> >> peripherals like SPI touchscreens to improve performance.
> >>
> >> Introduce the "qcom,force-gsi-mode" device property to hint and force
> >> the controller into GSI mode during initialization.
> Why to force ? You can directly configure in GSI mode. Note there are
> some configuration done prior to Linux bootup too.

Sorry, I don't get it. how? I know there may be a qupfw, but it is
impossible for a normal user like me to generate one with GSI
preferred.

Best wishes,
Pengyu

> >
> > Ideally, this should be decided by the SPI controller based on the
> > requirements. Another option would be to prefer GSI for all transfers if
> > it is available, ignoring the FIFO even if it is not disabled.
> >
> Yes, it should be decided in advance and configured accordingly for GSI
> vs non GSI mode. Because there would be limited set of GSI pipes, which
> will actually make must have GSI mode device run with FIFO mode.
>
> Why don't you decide prior and configure for GSI mode ? We don't need to
> change the current logic of deciding FIFO vs GSI.
> >>
> >> Signed-off-by: Pengyu Luo <mitltlatltl@gmail.com>
> >> ---
> >>   drivers/spi/spi-geni-qcom.c | 7 +++++++
> >>   1 file changed, 7 insertions(+)
> >>
> >
>

Re: [PATCH 2/2] spi: qcom-geni: Add property to force GSI mode

[Mukesh Savaliya]

On 6/29/2026 1:33 PM, Pengyu Luo wrote:
> On Mon, Jun 29, 2026 at 1:36 PM Mukesh Savaliya
> <mukesh.savaliya@oss.qualcomm.com> wrote:
>>
>> Hi Pengyu,
>>
>> On 6/15/2026 2:48 AM, Dmitry Baryshkov wrote:
>>> On Sun, Jun 14, 2026 at 04:34:24PM +0800, Pengyu Luo wrote:
>>>> Some devices (such as gaokun3) do not disable FIFO mode, causing the
>>>> driver to fallback to FIFO mode by default. However, these platforms
>>>> also support GSI mode, which is highly preferred for certain
>>>> peripherals like SPI touchscreens to improve performance.
>>>>
>>>> Introduce the "qcom,force-gsi-mode" device property to hint and force
>>>> the controller into GSI mode during initialization.
>> Why to force ? You can directly configure in GSI mode. Note there are
>> some configuration done prior to Linux bootup too.
> 
> Sorry, I don't get it. how? I know there may be a qupfw, but it is
> impossible for a normal user like me to generate one with GSI
> preferred.
> 
If firmware doesn't program in GSI, you can't have this working in GSI 
mode, its going to fail (and work with fallback). if it's programmed in 
GSI, anyway this will run in GSI mode. So why to add extra things 
without any usage ?

> Best wishes,
> Pengyu
> 
>>>
>>> Ideally, this should be decided by the SPI controller based on the
>>> requirements. Another option would be to prefer GSI for all transfers if
>>> it is available, ignoring the FIFO even if it is not disabled.
>>>
>> Yes, it should be decided in advance and configured accordingly for GSI
>> vs non GSI mode. Because there would be limited set of GSI pipes, which
>> will actually make must have GSI mode device run with FIFO mode.
>>
>> Why don't you decide prior and configure for GSI mode ? We don't need to
>> change the current logic of deciding FIFO vs GSI.
>>>>
>>>> Signed-off-by: Pengyu Luo <mitltlatltl@gmail.com>
>>>> ---
>>>>    drivers/spi/spi-geni-qcom.c | 7 +++++++
>>>>    1 file changed, 7 insertions(+)
>>>>
>>>
>>

Re: [PATCH 2/2] spi: qcom-geni: Add property to force GSI mode

[Pengyu Luo]

On Tue, Jun 30, 2026 at 5:52 PM Mukesh Savaliya
<mukesh.savaliya@oss.qualcomm.com> wrote:
>
>
>
> On 6/29/2026 1:33 PM, Pengyu Luo wrote:
> > On Mon, Jun 29, 2026 at 1:36 PM Mukesh Savaliya
> > <mukesh.savaliya@oss.qualcomm.com> wrote:
> >>
> >> Hi Pengyu,
> >>
> >> On 6/15/2026 2:48 AM, Dmitry Baryshkov wrote:
> >>> On Sun, Jun 14, 2026 at 04:34:24PM +0800, Pengyu Luo wrote:
> >>>> Some devices (such as gaokun3) do not disable FIFO mode, causing the
> >>>> driver to fallback to FIFO mode by default. However, these platforms
> >>>> also support GSI mode, which is highly preferred for certain
> >>>> peripherals like SPI touchscreens to improve performance.
> >>>>
> >>>> Introduce the "qcom,force-gsi-mode" device property to hint and force
> >>>> the controller into GSI mode during initialization.
> >> Why to force ? You can directly configure in GSI mode. Note there are
> >> some configuration done prior to Linux bootup too.
> >
> > Sorry, I don't get it. how? I know there may be a qupfw, but it is
> > impossible for a normal user like me to generate one with GSI
> > preferred.
> >
> If firmware doesn't program in GSI, you can't have this working in GSI
> mode, its going to fail (and work with fallback). if it's programmed in
> GSI, anyway this will run in GSI mode. So why to add extra things
> without any usage ?
>

What I can confirm is that fifo is not disabled on my device, and gsi
is definitely enabled (under windows, check the register
SE_GENI_DMA_MODE_EN), forcing the device to enable GSI mode on linux
works well.

Best wishes,
Pengyu

> > Best wishes,
> > Pengyu
> >
> >>>
> >>> Ideally, this should be decided by the SPI controller based on the
> >>> requirements. Another option would be to prefer GSI for all transfers if
> >>> it is available, ignoring the FIFO even if it is not disabled.
> >>>
> >> Yes, it should be decided in advance and configured accordingly for GSI
> >> vs non GSI mode. Because there would be limited set of GSI pipes, which
> >> will actually make must have GSI mode device run with FIFO mode.
> >>
> >> Why don't you decide prior and configure for GSI mode ? We don't need to
> >> change the current logic of deciding FIFO vs GSI.
> >>>>
> >>>> Signed-off-by: Pengyu Luo <mitltlatltl@gmail.com>
> >>>> ---
> >>>>    drivers/spi/spi-geni-qcom.c | 7 +++++++
> >>>>    1 file changed, 7 insertions(+)
> >>>>
> >>>
> >>
>

Re: [PATCH 2/2] spi: qcom-geni: Add property to force GSI mode

[Mukesh Savaliya]

On 6/30/2026 3:36 PM, Pengyu Luo wrote:
> On Tue, Jun 30, 2026 at 5:52 PM Mukesh Savaliya
> <mukesh.savaliya@oss.qualcomm.com> wrote:
>>
>>
>>
>> On 6/29/2026 1:33 PM, Pengyu Luo wrote:
>>> On Mon, Jun 29, 2026 at 1:36 PM Mukesh Savaliya
>>> <mukesh.savaliya@oss.qualcomm.com> wrote:
>>>>
>>>> Hi Pengyu,
>>>>
>>>> On 6/15/2026 2:48 AM, Dmitry Baryshkov wrote:
>>>>> On Sun, Jun 14, 2026 at 04:34:24PM +0800, Pengyu Luo wrote:
>>>>>> Some devices (such as gaokun3) do not disable FIFO mode, causing the
>>>>>> driver to fallback to FIFO mode by default. However, these platforms
>>>>>> also support GSI mode, which is highly preferred for certain
>>>>>> peripherals like SPI touchscreens to improve performance.
>>>>>>
>>>>>> Introduce the "qcom,force-gsi-mode" device property to hint and force
>>>>>> the controller into GSI mode during initialization.
>>>> Why to force ? You can directly configure in GSI mode. Note there are
>>>> some configuration done prior to Linux bootup too.
>>>
>>> Sorry, I don't get it. how? I know there may be a qupfw, but it is
>>> impossible for a normal user like me to generate one with GSI
>>> preferred.
>>>
>> If firmware doesn't program in GSI, you can't have this working in GSI
>> mode, its going to fail (and work with fallback). if it's programmed in
>> GSI, anyway this will run in GSI mode. So why to add extra things
>> without any usage ?
>>
> 
> What I can confirm is that fifo is not disabled on my device, and gsi
> is definitely enabled (under windows, check the register
> SE_GENI_DMA_MODE_EN), forcing the device to enable GSI mode on linux
> works well.
> 
Thanks  ! if GSI is already enabled, then why do you need forced gsi ?
My point here - SW should only decide mode based on register read, not 
enforce by DT flag. As such it's not a SOC exposed, can't be overridden 
by user.
>>>
>>>>>
>>>>> Ideally, this should be decided by the SPI controller based on the
>>>>> requirements. Another option would be to prefer GSI for all transfers if
>>>>> it is available, ignoring the FIFO even if it is not disabled.
>>>>>
>>>> Yes, it should be decided in advance and configured accordingly for GSI
>>>> vs non GSI mode. Because there would be limited set of GSI pipes, which
>>>> will actually make must have GSI mode device run with FIFO mode.
>>>>
>>>> Why don't you decide prior and configure for GSI mode ? We don't need to
>>>> change the current logic of deciding FIFO vs GSI.
>>>>>>
>>>>>> Signed-off-by: Pengyu Luo <mitltlatltl@gmail.com>
>>>>>> ---
>>>>>>     drivers/spi/spi-geni-qcom.c | 7 +++++++
>>>>>>     1 file changed, 7 insertions(+)
>>>>>>
>>>>>
>>>>
>>

Re: [PATCH 2/2] spi: qcom-geni: Add property to force GSI mode

[Pengyu Luo]

On Tue, Jun 30, 2026 at 8:28 PM Mukesh Savaliya
<mukesh.savaliya@oss.qualcomm.com> wrote:
>
>
>
> On 6/30/2026 3:36 PM, Pengyu Luo wrote:
> > On Tue, Jun 30, 2026 at 5:52 PM Mukesh Savaliya
> > <mukesh.savaliya@oss.qualcomm.com> wrote:
> >>
> >>
> >>
> >> On 6/29/2026 1:33 PM, Pengyu Luo wrote:
> >>> On Mon, Jun 29, 2026 at 1:36 PM Mukesh Savaliya
> >>> <mukesh.savaliya@oss.qualcomm.com> wrote:
> >>>>
> >>>> Hi Pengyu,
> >>>>
> >>>> On 6/15/2026 2:48 AM, Dmitry Baryshkov wrote:
> >>>>> On Sun, Jun 14, 2026 at 04:34:24PM +0800, Pengyu Luo wrote:
> >>>>>> Some devices (such as gaokun3) do not disable FIFO mode, causing the
> >>>>>> driver to fallback to FIFO mode by default. However, these platforms
> >>>>>> also support GSI mode, which is highly preferred for certain
> >>>>>> peripherals like SPI touchscreens to improve performance.
> >>>>>>
> >>>>>> Introduce the "qcom,force-gsi-mode" device property to hint and force
> >>>>>> the controller into GSI mode during initialization.
> >>>> Why to force ? You can directly configure in GSI mode. Note there are
> >>>> some configuration done prior to Linux bootup too.
> >>>
> >>> Sorry, I don't get it. how? I know there may be a qupfw, but it is
> >>> impossible for a normal user like me to generate one with GSI
> >>> preferred.
> >>>
> >> If firmware doesn't program in GSI, you can't have this working in GSI
> >> mode, its going to fail (and work with fallback). if it's programmed in
> >> GSI, anyway this will run in GSI mode. So why to add extra things
> >> without any usage ?
> >>
> >
> > What I can confirm is that fifo is not disabled on my device, and gsi
> > is definitely enabled (under windows, check the register
> > SE_GENI_DMA_MODE_EN), forcing the device to enable GSI mode on linux
> > works well.
> >
> Thanks  ! if GSI is already enabled, then why do you need forced gsi ?

I meant it is enabled on windows, not linux, and I think it is enabled
in the driver, geni_se_select_dma_mode() does it. On windows,
GENI_DMA_MODE_EN bit is set, but not on linux.

Yes, I have no doubt about below(as I drop DT part in V2), but the
GENI_IF_DISABLE_RO register only determines if fifo is disabled, if
not, why can't we use GSI?

> My point here - SW should only decide mode based on register read, not
> enforce by DT flag. As such it's not a SOC exposed, can't be overridden
> by user.

Best wishes,
Pengyu

> >>>
> >>>>>
> >>>>> Ideally, this should be decided by the SPI controller based on the
> >>>>> requirements. Another option would be to prefer GSI for all transfers if
> >>>>> it is available, ignoring the FIFO even if it is not disabled.
> >>>>>
> >>>> Yes, it should be decided in advance and configured accordingly for GSI
> >>>> vs non GSI mode. Because there would be limited set of GSI pipes, which
> >>>> will actually make must have GSI mode device run with FIFO mode.
> >>>>
> >>>> Why don't you decide prior and configure for GSI mode ? We don't need to
> >>>> change the current logic of deciding FIFO vs GSI.
> >>>>>>
> >>>>>> Signed-off-by: Pengyu Luo <mitltlatltl@gmail.com>
> >>>>>> ---
> >>>>>>     drivers/spi/spi-geni-qcom.c | 7 +++++++
> >>>>>>     1 file changed, 7 insertions(+)
> >>>>>>
> >>>>>
> >>>>
> >>
>

Re: [PATCH 2/2] spi: qcom-geni: Add property to force GSI mode

[Konrad Dybcio]

On 6/30/26 12:06 PM, Pengyu Luo wrote:
> On Tue, Jun 30, 2026 at 5:52 PM Mukesh Savaliya
> <mukesh.savaliya@oss.qualcomm.com> wrote:
>>
>>
>>
>> On 6/29/2026 1:33 PM, Pengyu Luo wrote:
>>> On Mon, Jun 29, 2026 at 1:36 PM Mukesh Savaliya
>>> <mukesh.savaliya@oss.qualcomm.com> wrote:
>>>>
>>>> Hi Pengyu,
>>>>
>>>> On 6/15/2026 2:48 AM, Dmitry Baryshkov wrote:
>>>>> On Sun, Jun 14, 2026 at 04:34:24PM +0800, Pengyu Luo wrote:
>>>>>> Some devices (such as gaokun3) do not disable FIFO mode, causing the
>>>>>> driver to fallback to FIFO mode by default. However, these platforms
>>>>>> also support GSI mode, which is highly preferred for certain
>>>>>> peripherals like SPI touchscreens to improve performance.
>>>>>>
>>>>>> Introduce the "qcom,force-gsi-mode" device property to hint and force
>>>>>> the controller into GSI mode during initialization.
>>>> Why to force ? You can directly configure in GSI mode. Note there are
>>>> some configuration done prior to Linux bootup too.
>>>
>>> Sorry, I don't get it. how? I know there may be a qupfw, but it is
>>> impossible for a normal user like me to generate one with GSI
>>> preferred.
>>>
>> If firmware doesn't program in GSI, you can't have this working in GSI
>> mode, its going to fail (and work with fallback). if it's programmed in
>> GSI, anyway this will run in GSI mode. So why to add extra things
>> without any usage ?
>>
> 
> What I can confirm is that fifo is not disabled on my device, and gsi
> is definitely enabled (under windows, check the register
> SE_GENI_DMA_MODE_EN), forcing the device to enable GSI mode on linux
> works well.

What's the value of se->base + SE_DMA_IF_EN (+0x2004) on this SE?

Konrad

Re: [PATCH 2/2] spi: qcom-geni: Add property to force GSI mode

[Konrad Dybcio]

On 7/2/26 2:39 PM, Konrad Dybcio wrote:
> On 6/30/26 12:06 PM, Pengyu Luo wrote:
>> On Tue, Jun 30, 2026 at 5:52 PM Mukesh Savaliya
>> <mukesh.savaliya@oss.qualcomm.com> wrote:
>>>
>>>
>>>
>>> On 6/29/2026 1:33 PM, Pengyu Luo wrote:
>>>> On Mon, Jun 29, 2026 at 1:36 PM Mukesh Savaliya
>>>> <mukesh.savaliya@oss.qualcomm.com> wrote:
>>>>>
>>>>> Hi Pengyu,
>>>>>
>>>>> On 6/15/2026 2:48 AM, Dmitry Baryshkov wrote:
>>>>>> On Sun, Jun 14, 2026 at 04:34:24PM +0800, Pengyu Luo wrote:
>>>>>>> Some devices (such as gaokun3) do not disable FIFO mode, causing the
>>>>>>> driver to fallback to FIFO mode by default. However, these platforms
>>>>>>> also support GSI mode, which is highly preferred for certain
>>>>>>> peripherals like SPI touchscreens to improve performance.
>>>>>>>
>>>>>>> Introduce the "qcom,force-gsi-mode" device property to hint and force
>>>>>>> the controller into GSI mode during initialization.
>>>>> Why to force ? You can directly configure in GSI mode. Note there are
>>>>> some configuration done prior to Linux bootup too.
>>>>
>>>> Sorry, I don't get it. how? I know there may be a qupfw, but it is
>>>> impossible for a normal user like me to generate one with GSI
>>>> preferred.
>>>>
>>> If firmware doesn't program in GSI, you can't have this working in GSI
>>> mode, its going to fail (and work with fallback). if it's programmed in
>>> GSI, anyway this will run in GSI mode. So why to add extra things
>>> without any usage ?
>>>
>>
>> What I can confirm is that fifo is not disabled on my device, and gsi
>> is definitely enabled (under windows, check the register
>> SE_GENI_DMA_MODE_EN), forcing the device to enable GSI mode on linux
>> works well.
> 
> What's the value of se->base + SE_DMA_IF_EN (+0x2004) on this SE?

I'm sorry, I read the first sentence only..

I think the enabling of DMA and the disabling of FIFO are technically
disjoint operations, but shouldn't be. The programming guide mentions that
FIFO_DISABLE=1 is set to prevent malicious software from snooping the data
from the RX FIFO while the SE is operated through the GSI.

Mukesh, would it make sense to make to rework the checks this way:

if (dma_enabled)
	prefer GSI, try SE DMA otherwise
else if (fifo_disabled)
	return error, misconfigured SE
else
	fifo mode

?

Konrad

Re: [PATCH 2/2] spi: qcom-geni: Add property to force GSI mode

[Mukesh Savaliya]

Hi Konrad,

On 7/2/2026 6:14 PM, Konrad Dybcio wrote:
> On 7/2/26 2:39 PM, Konrad Dybcio wrote:
>> On 6/30/26 12:06 PM, Pengyu Luo wrote:
>>> On Tue, Jun 30, 2026 at 5:52 PM Mukesh Savaliya
>>> <mukesh.savaliya@oss.qualcomm.com> wrote:
>>>>
>>>>
>>>>
>>>> On 6/29/2026 1:33 PM, Pengyu Luo wrote:
>>>>> On Mon, Jun 29, 2026 at 1:36 PM Mukesh Savaliya
>>>>> <mukesh.savaliya@oss.qualcomm.com> wrote:
>>>>>>
>>>>>> Hi Pengyu,
>>>>>>
>>>>>> On 6/15/2026 2:48 AM, Dmitry Baryshkov wrote:
>>>>>>> On Sun, Jun 14, 2026 at 04:34:24PM +0800, Pengyu Luo wrote:
>>>>>>>> Some devices (such as gaokun3) do not disable FIFO mode, causing the
>>>>>>>> driver to fallback to FIFO mode by default. However, these platforms
>>>>>>>> also support GSI mode, which is highly preferred for certain
>>>>>>>> peripherals like SPI touchscreens to improve performance.
>>>>>>>>
>>>>>>>> Introduce the "qcom,force-gsi-mode" device property to hint and force
>>>>>>>> the controller into GSI mode during initialization.
>>>>>> Why to force ? You can directly configure in GSI mode. Note there are
>>>>>> some configuration done prior to Linux bootup too.
>>>>>
>>>>> Sorry, I don't get it. how? I know there may be a qupfw, but it is
>>>>> impossible for a normal user like me to generate one with GSI
>>>>> preferred.
>>>>>
>>>> If firmware doesn't program in GSI, you can't have this working in GSI
>>>> mode, its going to fail (and work with fallback). if it's programmed in
>>>> GSI, anyway this will run in GSI mode. So why to add extra things
>>>> without any usage ?
>>>>
>>>
>>> What I can confirm is that fifo is not disabled on my device, and gsi
>>> is definitely enabled (under windows, check the register
>>> SE_GENI_DMA_MODE_EN), forcing the device to enable GSI mode on linux
>>> works well.
It may work, but it may fail too. We rather want to decide FIFO/DMA vs 
GSI based on fifo_disabled variable.
>>
>> What's the value of se->base + SE_DMA_IF_EN (+0x2004) on this SE?
> 
> I'm sorry, I read the first sentence only..
> 
> I think the enabling of DMA and the disabling of FIFO are technically
> disjoint operations, but shouldn't be. The programming guide mentions that
> FIFO_DISABLE=1 is set to prevent malicious software from snooping the data
> from the RX FIFO while the SE is operated through the GSI.
> 
> Mukesh, would it make sense to make to rework the checks this way:
> 
No, below actually completely makes things wrong.
Overall it's between GSI vs non GSI [i.e. FIFO/DMA]


fifo_disabled = 1 = GSI [Neither go for FIFO nor for DMA]

fifo_disabled = 0 = non GSI [Then Driver checks data transfer size, if 
<64 prefer FIFO else go for CPU DMA mode]

dma_enabled = 1 [fifo_disabled = 0] = FIFO OR DMA [Driver checks data 
size, if <64 prefer FIFO else go for CPU DMA mode]

let me know if there is still a confusion, we can discuss.

> if (dma_enabled)
> 	prefer GSI, try SE DMA otherwise
> else if (fifo_disabled)
> 	return error, misconfigured SE
> else
> 	fifo mode
> 
> ?
> 
> Konrad

Re: [PATCH 2/2] spi: qcom-geni: Add property to force GSI mode

[Konrad Dybcio]

On 6/30/26 11:52 AM, Mukesh Savaliya wrote:
> 
> 
> On 6/29/2026 1:33 PM, Pengyu Luo wrote:
>> On Mon, Jun 29, 2026 at 1:36 PM Mukesh Savaliya
>> <mukesh.savaliya@oss.qualcomm.com> wrote:
>>>
>>> Hi Pengyu,
>>>
>>> On 6/15/2026 2:48 AM, Dmitry Baryshkov wrote:
>>>> On Sun, Jun 14, 2026 at 04:34:24PM +0800, Pengyu Luo wrote:
>>>>> Some devices (such as gaokun3) do not disable FIFO mode, causing the
>>>>> driver to fallback to FIFO mode by default. However, these platforms
>>>>> also support GSI mode, which is highly preferred for certain
>>>>> peripherals like SPI touchscreens to improve performance.
>>>>>
>>>>> Introduce the "qcom,force-gsi-mode" device property to hint and force
>>>>> the controller into GSI mode during initialization.
>>> Why to force ? You can directly configure in GSI mode. Note there are
>>> some configuration done prior to Linux bootup too.
>>
>> Sorry, I don't get it. how? I know there may be a qupfw, but it is
>> impossible for a normal user like me to generate one with GSI
>> preferred.
>>
> If firmware doesn't program in GSI, you can't have this working in GSI mode, its going to fail (and work with fallback). if it's programmed in GSI, anyway this will run in GSI mode. So why to add extra things without any usage ?

My understanding is that GSI mode works, but the the FIFO_DISABLE bit
is set to zero, so FIFO mode is chosen.

So NHLOS would allow the use of this GPI instance (and not reserve the
GPI channels for this SE), but not set FIFO_DISABLE=1.

Konrad

Re: [PATCH 2/2] spi: qcom-geni: Add property to force GSI mode

[Mukesh Savaliya]

On 6/14/2026 2:04 PM, Pengyu Luo wrote:
> Some devices (such as gaokun3) do not disable FIFO mode, causing the
> driver to fallback to FIFO mode by default. However, these platforms
> also support GSI mode, which is highly preferred for certain
> peripherals like SPI touchscreens to improve performance.
> 
> Introduce the "qcom,force-gsi-mode" device property to hint and force
> the controller into GSI mode during initialization.
> 
> Signed-off-by: Pengyu Luo <mitltlatltl@gmail.com>
> ---
>   drivers/spi/spi-geni-qcom.c | 7 +++++++
>   1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/spi/spi-geni-qcom.c b/drivers/spi/spi-geni-qcom.c
> index 26e723cfea61..eece7312f780 100644
> --- a/drivers/spi/spi-geni-qcom.c
> +++ b/drivers/spi/spi-geni-qcom.c
> @@ -102,6 +102,7 @@ struct spi_geni_master {
>   	int irq;
>   	bool cs_flag;
>   	bool abort_failed;
> +	bool force_gsi_mode;
>   	struct dma_chan *tx;
>   	struct dma_chan *rx;
>   	int cur_xfer_mode;
> @@ -655,6 +656,9 @@ static int spi_geni_init(struct spi_geni_master *mas)
>   		mas->oversampling = 1;
>   
>   	fifo_disable = readl(se->base + GENI_IF_DISABLE_RO) & FIFO_IF_DISABLE;
> +	if (mas->force_gsi_mode)
> +		fifo_disable = 1;
> +
>   	switch (fifo_disable) {
>   	case 1:
>   		ret = spi_geni_grab_gpi_chan(mas);
> @@ -1133,6 +1137,9 @@ static int spi_geni_probe(struct platform_device *pdev)
>   	if (ret)
>   		return ret;
>   
> +	if (device_property_read_bool(&pdev->dev, "qcom,force-gsi-mode"))
> +		mas->force_gsi_mode = true;
> +
I don't think this is a HW bit, it's an internal selection based on FW 
programming. This is inherently decided by GENI_IF_DISABLE_RO, No 
exposure to the user/DT.
>   	ret = spi_geni_init(mas);
>   	if (ret)
>   		return ret;

Re: [PATCH 1/2] spi: dt-bindings: qcom,spi-geni-qcom: Add property to force GSI mode

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The `qcom,force-gsi-mode` property dictates driver software behavior instead of describing hardware configuration, violating Devicetree principles.
--

commit 0692b669eca2d4de46bd91bb83f4d52a4fe1f11d
Author: Pengyu Luo <mitltlatltl@gmail.com>

spi: dt-bindings: qcom,spi-geni-qcom: Add property to force GSI mode

This commit introduces a new devicetree property, "qcom,force-gsi-mode",
to the Qualcomm SPI Geni binding. The property is intended to instruct
the driver to prioritize DMA (GSI) mode over FIFO mode during initialization
on platforms where FIFO mode isn't explicitly disabled.

> diff --git a/Documentation/devicetree/bindings/spi/qcom,spi-geni-qcom.yaml b/Documentation/devicetree/bindings/spi/qcom,spi-geni-qcom.yaml
> index edf399681d7a9..80e394c1c7159 100644
> --- a/Documentation/devicetree/bindings/spi/qcom,spi-geni-qcom.yaml
> +++ b/Documentation/devicetree/bindings/spi/qcom,spi-geni-qcom.yaml
> @@ -45,6 +45,11 @@ properties:
>        - const: tx
>        - const: rx
>  
> +  qcom,force-gsi-mode:
> +    $ref: /schemas/types.yaml#/definitions/flag
> +    description:
> +      Use DMA (GSI) mode, even if FIFO mode is not disabled.

[Severity: Medium]
Does this property violate the principle that devicetree bindings should
describe hardware capabilities rather than software behavior?

The hardware's capability to use DMA is typically already described by standard
properties like dmas and dma-names. Since qcom,force-gsi-mode acts as a hint to
override the driver's default fallback logic, could the driver instead make
this decision internally?

For example, the driver could default to DMA when the resources are available,
or apply a quirk based on the board's compatible string, avoiding the need to
introduce an OS-specific policy flag into the devicetree.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260614083424.464132-1-mitltlatltl@gmail.com?part=1

Re: [PATCH 1/2] spi: dt-bindings: qcom,spi-geni-qcom: Add property to force GSI mode

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 724 bytes --]

On Sun, Jun 14, 2026 at 04:34:23PM +0800, Pengyu Luo wrote:
> Some devices (such as gaokun3) do not disable FIFO mode, causing the
> driver to fallback to FIFO mode by default. However, these platforms
> also support GSI mode, which is highly preferred for certain
> peripherals like SPI touchscreens to improve performance.
> 
> Introduce the "qcom,force-gsi-mode" device property to hint and force
> the controller into GSI mode during initialization.

This is an optimisation not a fundamental part of how these devices
operate.  The DT should describe whatever it is about these SoCs that
allows this mode, or this should be triggered based on the compatible
for the variant of the device that can do this.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH 1/2] spi: dt-bindings: qcom,spi-geni-qcom: Add property to force GSI mode

[Krzysztof Kozlowski]

On 14/06/2026 10:34, Pengyu Luo wrote:
> Some devices (such as gaokun3) do not disable FIFO mode, causing the
> driver to fallback to FIFO mode by default. However, these platforms
> also support GSI mode, which is highly preferred for certain
> peripherals like SPI touchscreens to improve performance.
> 
> Introduce the "qcom,force-gsi-mode" device property to hint and force
> the controller into GSI mode during initialization.

You described the desired Linux feature or behavior, not the actual
hardware. The bindings are about the latter, so instead you need to
rephrase the property and its description to match actual hardware
capabilities/features/configuration etc.

And even differently named property does not feel correct here - just
choose GSI in the driver...

Best regards,
Krzysztof