[PATCH 2/2] spi: bcm2835: Allow platform to set realtime priority

[Lukas Wunner]

On Thu, Mar 23, 2017 at 02:48:01PM +0100, Linus Walleij wrote:
> On Thu, Mar 23, 2017 at 2:43 PM, Lukas Wunner <lukas at wunner.de> wrote:
> > On Thu, Mar 23, 2017 at 12:21:18PM +0000, Mark Brown wrote:
> >> > Also, if you question setting the RT priority in the devicetree, why
> >> > was that functionality allowed for pl022 in the first place?
> >>
> >> This was being done via platform data not via device tree, unlike
> >> platform data device tree should provide a long term stable OS neutral
> >> ABI.
> >
> > No, specifying it via the device tree was subsequently added with
> > commit 39a6ac11df65 ("spi/pl022: Devicetree support w/o platform data"),
> > sorry for not mentioning this in the commit message.
> 
> This was in 2012 when we were walking around like zombies in
> devicetreeland and walking into the wall and breaking things to the
> left and right, just trying to comply with the recent decision to move
> all of ARM development over to using device tree.
> 
> If the property would be allowed today it would at *least* be prefixed
> with "linux,*" so "linux,realtime-priority".
> 
> Even though linux-specific DT properties are generally frowned upon
> they do have their place sometimes.
> 
> If this DT property was suggested today it would get a very different
> treatment than in 2012. We are older and wiser now. Mistakes were
> made, also by me.

Thanks a lot Linus for providing the historic background, which was
unbeknown to me.

I'm still wondering though:  If the master thread is supposed to be
run at a realtime priority *always*, 100%, all the time, what is the
best way to achieve this?  Setting it with chrt from an initscript
seems clumsy to me.  It's racy as the spi driver module needs to be
loaded, whenever the driver module is removed and re-inserted, the
priority needs to be updated again, there's always the difficulty of
uniquely identifying the right thread, and so on.  Setting this from
the device tree is much more elegant so I intend to keep the commits
at least on our own branch.

Thanks,

Lukas