Re: Useless dovetail hacks

[Jan Kiszka <jan.kiszka@siemens.com>]

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.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux