Re: Useless dovetail hacks

[Philippe Gerum <rpm@xenomai.org>]

Jan Kiszka <jan.kiszka@siemens.com> writes:

> On 21.09.20 08:15, Jan Kiszka wrote:
>> On 20.09.20 18:52, Philippe Gerum wrote:
>>>
>>> Philippe Gerum <rpm@xenomai.org> writes:
>>>>
>>>> SPI, DMA, and GPIOs are a no brainer for this and are already available
>>>> in such form, serial and network need more analysis because their
>>>> execution contexts are either more clumsy/complex. I also got the PCM
>>>> portion of the Alsa stack enabled with a complete I/O path over the
>>>> real-time context, from the user (ioctl) request to send/recv frames to
>>>> some i2s device, via DMA transactions controlled by the PCM core. As
>>>> weird as it may seem, it is actually not that intrusive, and works quite
>>>> well, including at insane acquisition rates for feeding an audio
>>>> pipeline. There is still some work ahead to fix rough edges, but the
>>>> fundamentals look sane.
>>>>
>>>
>>> I pushed more code to illustrate what I have been talking about. The
>>> eight topmost patches of the following branch implement a dual-kernel
>>> aware variant of the Alsa PCM core:
>>>
>>> https://git.evlproject.org/linux-evl.git/log/?h=wip/audio
>>>
>>> This is a quick forward port (compile-tested only so far) to v5.8 of the
>>> original working implementation based on v5.4. A very limited set of
>>> i.MX audio hardware (sai, wm8904) was enabled for demo purpose so far.
>>>
>>> To exploit this in some app, one would need to issue the ioctl request
>>> (SNDRV_PCM_IOCTL_PREPARE_OOB), telling the real-time capable PCM core to
>>> switch a capture/playback (sub)stream to out-of-band mode
>>> (i.e. interrupts, DMA and scheduling controlled end-to-end by the
>>> real-time core, EVL in this case). I plan to hack this into tinyalsa,
>>> which should be just fine for running simply audio pipelines, calling
>>> pcm_readi()/pcm_writei() basically.
>>>
>> That problem was never about straightforward lock conversion. It was 
>> always about architectural conversions. That may only change with
>> the mainline drivers if PREEMPT-RT triggers more rework and more RT
>> friendly architectures.
>
> To make it clearer: A conversion toward hard spinlocks may work
> smoothing in one kernel but can have interesting effects in another
> one because upstream code between the locks changed, and you need to
> look into what it now pulls in into your critical oob section. So,
> while the conversion is mechanically easy, the maintenance may not be
> that simple.
>
>> And, again, I do not want tones of driver conversions complicate the 
>> porting to new kernel versions. That is what will happen if
>> spreading this pattern significantly. I.e., you will also need
>> maintainers and deprecation policies for these enabling driver
>> patches as they will quickly bitrot, just differently.
>> 
>
> Like
> https://git.evlproject.org/linux-evl.git/commit/?h=wip/audio&id=54c909b2758430fceda776e7faffd39e9b284fcc 
> - not an easy one to maintain in this form on the long run, I'm sure.

Nope, you should not actually. Despite a massive code churn which has
been going on in Alsa, that patch was fairly straightforward to
port. There should be no fundamental design change to bring into a
mainline driver in order to cope with out-of-band activity. This is
where our assessment of the general issue of maintaining oob drivers
differs for the most part.

-- 
Philippe.