Received-SPF: pass (google.com: domain of linux-kernel+bounces-91690-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Message-ID: <cbbeec8c-45c7-0f62-8947-90511fdc1f25@samsung.com>
Date: Tue, 5 Mar 2024 14:08:19 +0900
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
	Thunderbird/102.11.0
Subject: Re: [PATCH] spi: dt-bindings: samsung: make dma properties not
 required
To: Tudor Ambarus <tudor.ambarus@linaro.org>, Rob Herring <robh@kernel.org>,
	Sam Protsenko <semen.protsenko@linaro.org>
Cc: Mark Brown <broonie@kernel.org>, Krzysztof Kozlowski
	<krzysztof.kozlowski+dt@linaro.org>, andi.shyti@kernel.org,
	conor+dt@kernel.org, linux-spi@vger.kernel.org,
	linux-samsung-soc@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, andre.draszik@linaro.org,
	peter.griffin@linaro.org, willmcvicker@google.com, kernel-team@android.com
Content-Language: en-US
From: Jaewon Kim <jaewon02.kim@samsung.com>
In-Reply-To: <0852a6bc-315c-49e2-84fe-7dadca71df3d@linaro.org>
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset="utf-8"
CMS-TYPE: 102P
DLP-Filter: Pass
References: <20240301115546.2266676-1-tudor.ambarus@linaro.org>
	<CAPLW+4=6oYcs0NPXo4ffLiCvtNQ-tY1s_isaxTX8dcPkV56xMw@mail.gmail.com>
	<cb426fb0-2f27-4c9b-89f5-7139354ea425@sirena.org.uk>
	<f06328e4-b283-4302-b9c1-6473aa3cfa25@linaro.org>
	<CAPLW+4kjXK=EWx__h0bX0rJMrL33E=t4YDzSOfObmvtG9aS+jg@mail.gmail.com>
	<20240304165635.GA739022-robh@kernel.org>
	<CGME20240304181554epcas2p19ce81f9801d4704862e76f785980213e@epcas2p1.samsung.com>
	<0852a6bc-315c-49e2-84fe-7dadca71df3d@linaro.org>

Hello all,


On 24. 3. 5. 03:15, Tudor Ambarus wrote:
> Hi, Rob,
>
> On 3/4/24 16:56, Rob Herring wrote:
>> On Sat, Mar 02, 2024 at 10:23:16AM -0600, Sam Protsenko wrote:
>>> On Sat, Mar 2, 2024 at 3:36 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>>>>
>>>>
>>>> On 01.03.2024 22:42, Mark Brown wrote:
>>>>> On Fri, Mar 01, 2024 at 01:28:35PM -0600, Sam Protsenko wrote:
>>>>>> On Fri, Mar 1, 2024 at 5:55 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>>>>>>> Since the addition of the driver in 2009, the driver selects between DMA
>>>>>>> and polling mode depending on the transfer length - DMA mode for
>>>>>>> transfers bigger than the FIFO depth, polling mode otherwise. All
>>>>>>> versions of the IP support polling mode, make the dma properties not
>>>>>>> required.
>>>>>> AFAIU, the device tree has nothing to do with drivers, it's about
>>>>>> hardware description. Does making DMA properties not required here
>>>> correct
>>>>
>>>>>> mean that there are some HW out there which doesn't integrate DMA in
>>>> no, to me it means that the IP can work without DMA, only in PIO mode,
>>>> regardless if DMA is integrated or not. Not required means that the
>>>> property is not mandatory, which is what I'm trying to achieve here.
>>>>
>>>>>> SPI blocks? Even if this change is ok (I'm not sure), the
>>>>>> argumentation doesn't look sound to me.
>>>> switching to PIO mode in the driver for sizes smaller than FIFO depths
>>>> in the driver guarantees that all existing compatibles support PIO mode.
>>>>
>>>> Are you saying that if there is a physical line between an IP and DMA
>>>> controller, then the DMA properties must always be specified in dt? I
>>>> thought they can be marked as optional in this case, and that's what I
>>>> did with this patch.
>>>>
>>> No, I would wait for maintainers to clarify on that bit. Change itself
>>> can be ok. But the commit message shouldn't mention the driver,
>>> because the driver uses (depends on) device tree, not vice versa. The
>>> device tree can be used in other projects as well (like U-Boot and
>>> OP-TEE), so it should be designed to be universal and not depend on
>>> kernel drivers. The commit message should be based on particular HW
>>> layout features and how the patch makes the bindings describe that HW
>>> better. It shouldn't rely on driver implementations.
>> If the controller is DMA capable then it should have dma properties. The
> should have as in required/mandatory?
>
>> compatible should be enough to tell if it is a case of 'can only work
> yes, I agree
>
>> with DMA'. Otherwise, it is going to be up to a specific user. Even
>> within Linux, you may have a serial port that doesn't use DMA for the
>> console, but uses it for the tty or serdev.
>>
>> Of course, if a new device is added without DMA properties and they
>> are added later on, then they are going to be optional even though the
>> DMA support is always there. I can't fully understand everyone's h/w.
>>
> The SPI controller that I'm working with has a dedicated channel to the
> DMA controller. It can work without DMA too, just by polling registers
> or by interrupts.
>
> I can't get the DMA controller to work correctly yet, and since the SPI
> controller can work without DMA, I thought that I can mark the DMA
> properties as optional, add the SPI node in dt without DMA, and add the
> DMA properties later on, after I have the DMA controller working
> correctly. Is this approach wrong?
>
> Thanks,
> ta
>
>

I agree with this patch.

I don`t think DMA property needs to be "required" because it can operate 
well without DMA property.


Last year, I put a patch that makes dma property optional.

  - d1a7718ee8db (spi: s3c64xx: change polling mode to optional)

- https://lore.kernel.org/r/20230502062813.112434-2-jaewon02.kim@samsung.com


In the past, there was SoC without DMA, so it was a quirk that used 
polling mode.

Now, I want to change this to be optional to support cases where DMA is 
not available according to OS environment(Virtual Machine).


Thanks

Jaewon Kim