Re: [RFT][PATCH 0/5] firewire: use sleepable workqueue to handle 1394 OHCI IT/IR context events

Allen Pais <[email protected]>
Newsgroups gmane.linux.sound,gmane.linux.kernel.firewire.devel,gmane.linux.kernel,gmane.linux.drivers.video-input-infrastructure,gmane.linux.network
Message-ID <[email protected]>

>This series of change is inspired by BH workqueue available in recent
>kernel.

>In Linux FireWire subsystem, tasklet softIRQ context has been utilized to
>operate 1394 OHCI Isochronous Transmit (IT) and Isochronous Receive (IR)
>contexts. The tasklet context is not preferable, as you know.

>I have already received a proposal[1][2] to replace the usage of tasklet
>with BH workqueue. However, the proposal includes bare replacement for 1394
>OHCI IT, IR, Asynchronous Transmit (AT), and Asynchronous Receive (AR)
>contexts with neither any care of actual usage for each context nor
>practical test reports. In theory, this kind of change should be done by
>step by step with enough amount of evaluation over software design to avoid
>any disorder.

>In this series of changes, the usage of tasklet for 1394 OHCI IT/IR
>contexts is just replaced, as a first step. In 1394 OHCI IR/IT events,
>software is expected to process the content of page dedicated to DMA
>transmission for each isochronous context. It means that the content can be
>processed concurrently per isochronous context. Additionally, the content
>of page is immutable as long as the software schedules the transmission
>again for the page. It means that the task to process the content can sleep
>or be preempted. Due to the characteristics, BH workqueue is _not_ used.

>At present, 1394 OHCI driver is responsible for the maintenance of tasklet
>context, while in this series of change the core function is responsible
>for the maintenance of workqueue and work items. This change is an attempt
>to let each implementation focus on own task.

>The change affects the following implementations of unit protocols which
>operate isochronous contexts:

>- firewire-net for IP over 1394 (RFC 2734/3146)
>- firedtv
>- drivers in ALSA firewire stack for IEC 61883-1/6
>- user space applications

>As long as reading their codes, the first two drivers look to require no
>change. While the drivers in ALSA firewire stack require change to switch
>the type of context in which callback is executed. The series of change
>includes a patch for them to adapt to work process context.

>Finally, these changes are tested by devices supported by ALSA firewire
>stack with/without no-period-wakeup runtime of PCM substream. I also tested
>examples in libhinoko[3] as samples of user space applications. Currently I
>face no issue.

>On the other hand, I have neither tested for firewire-net nor firedtv,
>since I have never used these functions. If someone has any experience to
>use them, I would request to test the change.

>[1] https://lore.kernel.org/lkml/[email protected]/
>[2] https://github.com/allenpais/for-6.9-bh-conversions/issues/1
>[3] https://git.kernel.org/pub/scm/libs/ieee1394/libhinoko.git/


>Regards

Thank you for doing this work. You will probably need to send out a v2
As most of you patches have single line comment instead of Block style
Commnents (/* ..*/). Please have it fixed.

- Allen

>Takashi Sakamoto (5):
> firewire: core: allocate workqueue to handle isochronous contexts in
>   card
> firewire: core: add local API for work items scheduled to workqueue
>   specific to isochronous contexts
> firewire: ohci: process IT/IR events in sleepable work process to
>   obsolete tasklet softIRQ
> firewire: core: non-atomic memory allocation for isochronous event to
>   user client
> ALSA: firewire: use nonatomic PCM operation
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.