Re: [PATCH v3 0/3] firewire: assist unit driver to compute packet time stamp

[Takashi Sakamoto <o-takashi@sakamocchi.jp>]

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@sakamocchi.jp/
> > V1:
> >  * https://lore.kernel.org/lkml/20211202113457.24011-1-o-takashi@sakamocchi.jp/
> > 
> > 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.


Thanks

Takashi Sakamoto