Firewire Maintainer Is Looking For Help Testing IEEE-1394 Devices On Linux 6.12
([Hardware] 3 Hours Ago
Firewire IEEE-1394)
- Reference: 0001493040
- News link: https://www.phoronix.com/news/Firewire-Linux-6.12
- Source link:
While not as exciting as some of the shiny new features for [1]Linux 6.12 like [2]real-time going mainline and [3]Lunar Lake and Battlemage graphics by default , the Firewire (IEEE-1394) subsystem has seen some significant alterations this cycle. With Firewire hardware increasingly rare, the maintainer is hoping to get this Linux 6.12 code better tested by the community.
Takashi Sakamoto continues maintaining the Firewire/IEEE-1394 code within the Linux kernel. He's the one [4]hoping to maintain Linux Firewire support through 2029 . With Linux 6.12 he's made a significant change to the processing context for isochronous packets. He added in the pull request, " Hopefully, many developers will test it before the official release. "
[5]
Takashi explains in [6]the pull request of Firewire changes for Linux 6.12:
"The batch of changes includes the followwing:
- Replacing tasklet with usual workqueue for isochronous context
- Replacing IDR with XArray
- Utilizing guard macro where possible
- Printing deprecation warning when enabling debug parameter of firewire-ohci module
Additionally, it includes a single patch for sound subsystem which the subsystem maintainer acked:
- Switching to nonatomic PCM operation
In FireWire subsystem, tasklet has been used as the bottom half of 1394 OHCi hardIRQ so long. In the recent kernel updates, BH workqueue has been available, and some developers have proposed replacing tasklet with BH workqueue. While it is fortunate that developers are still considering the legacy subsystem, a simple replacement is not necessarily suitable.
As a first step towards dropping tasklet, I've investigated the feasibility for 1394 OHCI isochronous context, and concluded that usual workqueue is available. In the context, the batch of packets is processed in the specific queue, thus the timing jitter caused by task scheduling is not so critical. Additionally, DMA transmission can be scheduled per-packet basis, therefore the context can be sleep between the operation of transmissions. Furthermore, in-kernel protocol implementation involves some CPU-bound tasks, which can sometimes consumes CPU time so long. These characteristics suggest that usual workqueue is suitable, through BH workqueues are not.
The replacement with usual workqueue allows unit drivers to process the content of packets in non-atomic context. It brings some reliefs to some drivers in sound subsystem that spin-lock is not mandatory anymore during isochronous packet processing."
Here's to hoping the Firewire code is in good shape for Linux 6.12.
[1] https://www.phoronix.com/search/Linux+6.12
[2] https://www.phoronix.com/news/Linux-6.12-Does-Real-Time
[3] https://www.phoronix.com/news/Linux-6.12-DRM-Graphics
[4] https://www.phoronix.com/news/Linux-Firewire-New-Maintainer
[5] https://www.phoronix.com/image-viewer.php?id=2024&image=linux_612_firewire_lrg
[6] https://lore.kernel.org/lkml/20240921031421.GA227826@workstation.local/
Takashi Sakamoto continues maintaining the Firewire/IEEE-1394 code within the Linux kernel. He's the one [4]hoping to maintain Linux Firewire support through 2029 . With Linux 6.12 he's made a significant change to the processing context for isochronous packets. He added in the pull request, " Hopefully, many developers will test it before the official release. "
[5]
Takashi explains in [6]the pull request of Firewire changes for Linux 6.12:
"The batch of changes includes the followwing:
- Replacing tasklet with usual workqueue for isochronous context
- Replacing IDR with XArray
- Utilizing guard macro where possible
- Printing deprecation warning when enabling debug parameter of firewire-ohci module
Additionally, it includes a single patch for sound subsystem which the subsystem maintainer acked:
- Switching to nonatomic PCM operation
In FireWire subsystem, tasklet has been used as the bottom half of 1394 OHCi hardIRQ so long. In the recent kernel updates, BH workqueue has been available, and some developers have proposed replacing tasklet with BH workqueue. While it is fortunate that developers are still considering the legacy subsystem, a simple replacement is not necessarily suitable.
As a first step towards dropping tasklet, I've investigated the feasibility for 1394 OHCI isochronous context, and concluded that usual workqueue is available. In the context, the batch of packets is processed in the specific queue, thus the timing jitter caused by task scheduling is not so critical. Additionally, DMA transmission can be scheduled per-packet basis, therefore the context can be sleep between the operation of transmissions. Furthermore, in-kernel protocol implementation involves some CPU-bound tasks, which can sometimes consumes CPU time so long. These characteristics suggest that usual workqueue is suitable, through BH workqueues are not.
The replacement with usual workqueue allows unit drivers to process the content of packets in non-atomic context. It brings some reliefs to some drivers in sound subsystem that spin-lock is not mandatory anymore during isochronous packet processing."
Here's to hoping the Firewire code is in good shape for Linux 6.12.
[1] https://www.phoronix.com/search/Linux+6.12
[2] https://www.phoronix.com/news/Linux-6.12-Does-Real-Time
[3] https://www.phoronix.com/news/Linux-6.12-DRM-Graphics
[4] https://www.phoronix.com/news/Linux-Firewire-New-Maintainer
[5] https://www.phoronix.com/image-viewer.php?id=2024&image=linux_612_firewire_lrg
[6] https://lore.kernel.org/lkml/20240921031421.GA227826@workstation.local/
jeisom