Message ID | 20220405072221.226217-1-o-takashi@sakamocchi.jp (mailing list archive) |
---|---|
Headers | show |
Series | firewire: assist unit driver to compute packet time stamp | expand |
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. Takashi
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
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@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. 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
On Thu, Apr 07, 2022 at 08:02:10AM +0200, Takashi Iwai wrote: > 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@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. > > 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. That's great. I think we can see few objections. In this weekend, I'll send two respined patchset. One is for bug fixes for your for-linus and living stables. Another is for your linux-next. Thanks for your kindness. Takashi Sakamoto