Message-ID: <6c6ffc8e-4c98-699e-ee63-d99880aea95f@linaro.org>
Date:   Wed, 7 Jun 2023 16:28:37 +0200
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     Matthias Schiffer <matthias.schiffer@...tq-group.com>,
        Mark Brown <broonie@...nel.org>,
        Linus Walleij <linus.walleij@...aro.org>
Cc:     Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Conor Dooley <conor+dt@...nel.org>, linux-spi@...r.kernel.org,
        devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-kernel@...r.kernel.org, linux@...tq-group.com
Subject: Re: [PATCH 1/2] spi: dt-bindings: introduce linux,use-rt-queue flag

On 07/06/2023 14:55, Matthias Schiffer wrote:
> On Tue, 2023-06-06 at 15:44 +0100, Mark Brown wrote:
>> * PGP Signed by an unknown key
>>
>> On Tue, Jun 06, 2023 at 04:37:08PM +0200, Linus Walleij wrote:
>>> On Fri, Jun 2, 2023 at 2:22 PM Mark Brown <broonie@...nel.org> wrote:
>>>> On Fri, Jun 02, 2023 at 01:52:00PM +0200, Matthias Schiffer wrote:
>>
>>>>> We have seen a number of downstream patches that allow enabling the
>>>>> realtime feature of the SPI subsystem to reduce latency. These were
>>>>> usually implemented for a specific SPI driver, even though the actual
>>>>> handling of the rt flag is happening in the generic SPI controller code.
>>
>>>>> Introduce a generic linux,use-rt-queue flag that can be used with any
>>>>> controller driver. The now redundant driver-specific pl022,rt flag is
>>>>> marked as deprecated.
>>
>>>> This is clearly OS specific tuning so out of scope for DT...
>>
>>> In a sense, but to be fair anything prefixed linux,* is out of scope for DT,
>>> Documentation/devicetree/bindings/input/matrix-keymap.yaml being
>>> the most obvious offender.
>>
>> That's at least a description of hardware though.  This is a performance
>> tuning thing, if it needs to be configured at all it should be
>> configured at runtime.  Some applications might see things work better,
>> some might see performance reduced and new versions might have different
>> performance characteristics and need different configuration.
> 
> 
> It is not clear to me what alternative options we currently have if we
> want a setting to be effective from the very beginning, before
> userspace is running. Of course adding a cmdline option would work, but
> that seems worse than having it in the DT in every possible way.
> 
> I can understand not wanting such tuning in Device Trees in the kernel
> repo - I agree that these default DTs should only describe the hardware
> and it makes sense to keep OS-specific tuning out of them.

It is not about the sense. It's the rule and the policy. If you want to
change the existing practice, don't do it via one patch that sneaks
something in, but change entire practice for entire DT.

> 
> Requiring such tuning for specific drivers or driver instances is
> however a common issue for embedded systems, which is why we are seeing
> (and occasionally writing) such patches - setting things up from
> userspace may happen too late, or may not be possible at all if a
> setting needs to be available during probe. And even when deferring
> things to userspace is possible, making things configurable at runtime
> always adds some complexity, even though it is often not a requirement
> at all for embedded systems.
> 
> Just doing this through the DT is very convenient and robust. The
> settings could be inserted into the default DT as an overlay applied
> during build or by the bootloader.
> 
> Any alternative solution we could come up with would likely add more
> complexity on the driver side, and be less convenient to use for
> developers. Overall, the rationale for not supporting such bindings in
> drivers seems much weaker to me than that for not having such settings
> in default DTs...

It's not a hardware property. Do not put software choices or policies
specific to only one OS into the DT. The DTS is used by different users,
including other operating systems, firmwares and bootloaders.

Your convenience is not justification for misusing the DT. That's the
same argument community is using since ages for every wish from someone
there wanting something "convenient for him". Same answer for all the
weird ABIs, weird new user-space interfaces, weird duplicated
subsystems, many different schedulers (yeah, because why improve
existing solution in the kernel...) etc. It's always easier for
contributor to solve only their one problem. No, we are less interested
in solving only your one specific problem if such solution breaks
existing rules and consensus.

I think Mark was here quite explicit, but since discussion is still going:

NAK for the linux,rt property.

Best regards,
Krzysztof

Powered by blists - more mailing lists