From mboxrd@z Thu Jan 1 00:00:00 1970 References: <55694df3-85a8-cca8-1801-d55a4e7f0e53@siemens.com> <87ft7os284.fsf@xenomai.org> <9c76bfeb-f114-0c29-f048-fb51679ad0de@siemens.com> <87k0wzdk3h.fsf@xenomai.org> <87pn6gcrw0.fsf@xenomai.org> <181a2c6b-0aa7-b189-237e-c8b8b3b39e9e@siemens.com> <74e7e1a2-8650-ae6d-99cb-1f403d86fc92@siemens.com> From: Philippe Gerum Subject: Re: Useless dovetail hacks In-reply-to: <74e7e1a2-8650-ae6d-99cb-1f403d86fc92@siemens.com> Date: Mon, 21 Sep 2020 09:23:50 +0200 Message-ID: <875z87d249.fsf@xenomai.org> MIME-Version: 1.0 Content-Type: text/plain List-Id: Discussions about the Xenomai project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: "Pirou, Florent" , "Hu, Mingliang" , "Wang, Rick Y" , xenomai@xenomai.org, evl@evlproject.org Jan Kiszka writes: > On 21.09.20 08:15, Jan Kiszka wrote: >> On 20.09.20 18:52, Philippe Gerum wrote: >>> >>> Philippe Gerum 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.