On Wed, 11 May 2016 00:33:27 +0200,
Takashi Sakamoto wrote:
>
> In current implementation, packet processing is done in both of software
> IRQ contexts of IR/IT contexts and process contexts.
>
> This is usual interrupt handling of IR/IT context for 1394 OHCI.
> (in hardware IRQ context)
> irq_handler() (drivers/firewire/ohci.c)
> ->tasklet_schedule()
> (in software IRQ context)
> handle_it_packet() or handle_ir_packet_per_buffer() (drivers/firewire/ohci.c)
> ->flush_iso_completions()
> ->struct fw_iso_context.callback.sc()
> = out_stream_callback() or in_stream_callback()
>
> However, we have another chance for packet processing. It's done in PCM
> frame handling via ALSA PCM interfaces.
> (in process context)
> ioctl(i.e. SNDRV_PCM_IOCTL_HWSYNC)
> ->snd_pcm_hwsync() (sound/core/pcm_native.c)
> ->snd_pcm_update_hw_ptr() (sound/core/pcm_lib.c)
> ->snd_pcm_update_hw_ptr0()
> ->struct snd_pcm_ops.pointer()
> = amdtp_stream_pcm_pointer()
> ->fw_iso_context_flush_completions() (drivers/firewire/core-iso.c)
> ->struct fw_card_driver.flush_iso_completions()
> = ohci_flush_iso_completions() (drivers/firewire/ohci.c)
> ->flush_iso_completions()
> ->struct fw_iso_context.callback.sc()
> = out_stream_callback() or in_stream_callback()
>
> This design is for a better granularity of PCM pointer. When ioctl(2) is
> executed with some commands for ALSA PCM interface, queued packets are
> handled at first. Then, the latest number of handled PCM frames is
> reported. The number can represent PCM frames transferred in most near
> isochronous cycle.
>
> Current tracepoints include no information to distinguish running contexts.
> When tracing the interval of software IRQ context, this is not good.
>
> This commit adds more information for current context. Additionally, the
> index of packet processed in one context is added in a case that packet
> processing is executed in continuous context of the same kind,
>
> As a result, the output includes 11 fields with additional two fields
> to commit 0c95c1d6197f ("ALSA: firewire-lib: add tracepoints to dump a part
> of isochronous packet data"):
> 17131.9186: out_packet: 07 7494 ffc0 ffc1 00 000700c0 9001a496 058 45 1 13
> 17131.9186: out_packet: 07 7495 ffc0 ffc1 00 000700c8 9001ba00 058 46 1 14
> 17131.9186: out_packet: 07 7496 ffc0 ffc1 00 000700d0 9001ffff 002 47 1 15
> 17131.9189: out_packet: 07 7497 ffc0 ffc1 00 000700d0 9001d36a 058 00 0 00
> 17131.9189: out_packet: 07 7498 ffc0 ffc1 00 000700d8 9001e8d4 058 01 0 01
> 17131.9189: out_packet: 07 7499 ffc0 ffc1 00 000700e0 9001023e 058 02 0 00
> 17131.9206: in_packet: 07 7447 ffc1 ffc0 01 3f070072 9001783d 058 32 1 00
> 17131.9206: in_packet: 07 7448 ffc1 ffc0 01 3f070072 90ffffff 002 33 1 01
> 17131.9206: in_packet: 07 7449 ffc1 ffc0 01 3f07007a 900191a8 058 34 1 02
> (Here, some common fields are omitted so that a line is within 80
> characters.)
>
> The legend is:
> - The second of cycle scheduled for the packet
> - The count of cycle scheduled for the packet
> - The ID of node as source (hex)
> - The ID of node as destination (hex)
> - The value of isochronous channel
> - The first quadlet of CIP header (hex)
> - The second quadlet of CIP header (hex)
> - The number of included quadlets
> - The index of packet in a buffer maintained by this module
> - 0 in process context, 1 in IRQ context
> - The index of packet processed in the context
>
> Signed-off-by: Takashi Sakamoto <o-takashi@xxxxxxxxxxxxx>
Applied, thanks.
Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
