Re: [PATCH 1/2] spi: dt-bindings: introduce linux,use-rt-queue flag

[Matthias Schiffer <matthias.schiffer@xxxxxxxxxxxxxxx>]

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@xxxxxxxxxx> 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.

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...

Best regards,
Matthias


(ps. Sorry about our bouncing linux@ address. Should be fixed now.)

-- 
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/