On Thu, 07 Apr 2022 02:10:21 +0200, Takashi Sakamoto wrote: > > On Tue, Apr 05, 2022 at 06:23:35PM +0200, Takashi Iwai wrote: > > On Tue, 05 Apr 2022 09:22:18 +0200, > > Takashi Sakamoto wrote: > > > > > > Hi, > > > > > > Current implementation of Linux FireWire subsystem doesn't allow unit > > > driver to operate content of packet in IR context according to > > > time stamp. Additionally it doesn't allow unit driver to read current value > > > of CYCLE_TIME register in OHCI 1394 controller. It brings disadvantages to > > > drivers in Linux sound subsystem in regards of handling time for sampled > > > data such as PCM frames and MIDI messages. > > > > > > This rerolled patchset is first step to improve the situation. > > > > > > Changes in v3: > > > * Rebase v2 patchset to v5.18-rc1 > > > Changes in v2: > > > * Rebase v1 patchset to v5.16 release > > > * https://lore.kernel.org/lkml/20220212022131.199855-1-o-takashi@xxxxxxxxxxxxx/ > > > V1: > > > * https://lore.kernel.org/lkml/20211202113457.24011-1-o-takashi@xxxxxxxxxxxxx/ > > > > > > Hector Martin (1): > > > firewire: Add dummy read_csr/write_csr functions > > > > > > Takashi Sakamoto (2): > > > firewire: add kernel API to access CYCLE_TIME register > > > firewire: add kernel API to access packet structure in request > > > structure for AR context > > > > Thanks, applied all three patches now to for-next branch. > > Although thanks for your applying them into your tree, I apologize to > trouble you if you overlook that the included changes is just for Linux > FireWire subsystem. It's my fault to send them only to Linux sound > subsystem, but the changes are required to my work in sound drivers... > > If you are willing to include patches to Linux FireWire subsystem for > your pull-request to Linus, I can prepare respined patches for it since > I have the list of patches posted to LKML as bug fixes for Linux FireWire > subsystem. > > I need any help to solve current situation of Linux FireWire subsystem > that bug fixes and new changes are hardly merged. Of course, IEEE 1394 bus > is already outdated and legacy, but I know that some users still work > with it. If your path is available for it, it's the easiest and the most > convenient way for upstreaming, I think. Ah OK, it's fine for me in either way. I can keep up those changes in my tree, or go through others. I leave the decision Firewire subsystem people. Just let me know. thanks, Takashi
