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

From: Konrad Dybcio

Date: Fri Jun 26 2026 - 11:41:06 EST


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@xxxxxxxxxxxxxxxx> 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