Posts
71
Following
26
Followers
22
A maintainer of Linux FireWire subsystem and ALSA firewire stack.
http://ieee1394.docs.kernel.org/
https://github.com/takaswie/linux-firewire-dkms/

Takashi Sakamoto (坂本 貴史)

I sent:

[GIT PULL] firewire updates for v6.12
https://lore.kernel.org/lkml/20240921031421.GA227826@workstation.local/

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.
0
0
2

Takashi Sakamoto (坂本 貴史)

Edited 2 months ago
Need sponsors:

* #1080372 RFS: libhinoko/1.0.3-1 [ITP] -- I/O library for IEEE 1394 isochronous communication
** https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1080372
** https://mentors.debian.net/package/libhinoko/
* #1081809 RFS: libhitaki/0.2.1-3 [ITP] -- Library to operate ALSA HwDep device for ALSA firewire stack
** https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1081809
** https://mentors.debian.net/package/libhitaki/
* #1081810 RFS: linux-firewire-utils/0.5.1-2 [ITP] -- Linux FireWire utilities
** https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1081810
** https://mentors.debian.net/package/linux-firewire-utils/
0
1
1

Takashi Sakamoto (坂本 貴史)

Phew.
0
0
0

Takashi Sakamoto (坂本 貴史)

Edited 3 months ago
I believe BH workqueue is not necessarily required for the purpose:

[RFT][PATCH 0/5] firewire: use sleepable workqueue to handle 1394 OHCI IT/IR context events
https://lore.kernel.org/lkml/20240901110642.154523-1-o-takashi@sakamocchi.jp/
0
0
0

Takashi Sakamoto (坂本 貴史)

Unexpectedly, I can easily replace tasklet with workqueue for 1394 OHCI IR/IT contexts in v6.11 kernel, at least for userspace application. Hm.
0
0
0

Takashi Sakamoto (坂本 貴史)

[PATCH] firewire: core: update fw_device outside of device_find_child()

https://lore.kernel.org/lkml/20240820132132.28839-1-o-takashi@sakamocchi.jp/

I believe it reasonable to separate updating from finding here.
0
0
0

Takashi Sakamoto (坂本 貴史)

Completed.
0
0
0

Takashi Sakamoto (坂本 貴史)

[PATCH 0/5] firewire: core: use XArray to maintain client resources

https://lore.kernel.org/lkml/20240812235210.28458-1-o-takashi@sakamocchi.jp/
0
0
0

Takashi Sakamoto (坂本 貴史)

As a first step.
0
0
0

Takashi Sakamoto (坂本 貴史)

[PATCH 0/2] firewire: core: use XArray to maintain firewire device nodes:

https://lore.kernel.org/lkml/20240812014251.165492-1-o-takashi@sakamocchi.jp/
0
0
1

Takashi Sakamoto (坂本 貴史)

I'm working to replace usage of IDR with XArray. I was a bit puzzled that DEFINE_XARRAY_ALLOC() and xa_init() are not equivalent. In my opinion, the naming scheme of XArray functions should be reconsidered. It easily confuse me.
0
0
0

Takashi Sakamoto (坂本 貴史)

Phew.

[PATCH 00/17] firewire: core/ohci: use guard macro for any type of lock primitives
https://lore.kernel.org/lkml/20240804130225.243496-1-o-takashi@sakamocchi.jp/T/#m3f70c1329301dc504d310a8f71c778061868772b
0
0
1

Takashi Sakamoto (坂本 貴史)

Oh, the usage of IDR should be replaced with XArray... Since when?
0
0
0

Takashi Sakamoto (坂本 貴史)

Edited 4 months ago
Phew
0
0
0

Takashi Sakamoto (坂本 貴史)

I'm surprised to see my protocol analyzer operational again.
0
0
0

Takashi Sakamoto (坂本 貴史)

Edited 4 months ago
Need some KUnit tests to check serializer/deserializer of data in payload of isochronous packet for various CIP format. However, the current implementation is tight-coupled to low-level hardware operations and procedures for complicated device-dependent protocols. Mmm.
0
0
0

Takashi Sakamoto (坂本 貴史)

Edited 4 months ago
Posted: [GIT PULL] firewire updates for v6.11
https://lore.kernel.org/linux-kernel/20240720084730.GA59546@workstation.local/T/#u

There are many line changes for FireWire subsystem, while there is no
functional change for practical use. The most of changes are for code
refactoring, some KUnit tests to added helper functions, and new
tracepoints events for both the core functions and 1394 OHCI driver.

The tracepoints events now cover the verbose logging enabled by debug
parameter of firewire-ohci kernel module. The parameter would be removed
in any future timing, thus it is now deprecated.
0
0
0

Takashi Sakamoto (坂本 貴史)

Hm. I'm investigating to replace the local implementation to maintain blocks in the allocated memory region mapped for DMA purpose with common dma_pool. However, it does not allows to pick up an arbitrary count of blocks at once for continuous memory region. It just connect returned block to the tail of local list, and has no mechanism to keep maintained blocks as continuous.
Typically, this kind of framework requires mechanism to suppress fragmentation, but it has nothing. I prefer its simplicity, but a bit inconvenient for my purpose...
0
0
0

Takashi Sakamoto (坂本 貴史)

Being straightforward is not necessarily more adequate than being simple.
0
0
0
Show older