* Peter Ujfalusi <peter.ujfalusi@xxxxxx> [160908 03:49]:
> >
> > I managed to get time for this and it looks like that we only need to block
> > core OFF for audio. I don't know why C6 ("MPU OFF + CORE RET") with it's 3000
> > + 8500 exit latency not causing issues when we have less time from the DMA
> > request to empty FIFO...
Right, the wakeup event should be the fifo threshold and the dma trigger
line.. But there must some other thing we're not accounting for.
> > My findings so far:
> > w/o the QoS patch we will hit core OFF even if we are in element mode in McBSP:
> > # cat /sys/devices/platform/68000000.ocp/49022000.mcbsp/dma_op_mode
> > [element] threshold
> >
> > If I start the playback we will hit core OFF even if the we have DMA request
> > coming at every sample (every 0.02ms).
I think that's because we still have windows without pm qos where dma
is not active and we hit idle and there's nothing in hardware blocking
off mode.
> > We hit C6, but when the DMA request comes we have 16 words in the FIFO (8
> > samples, 0.16ms of audio). C6 should take 11.5ms to exit...
So maybe we have the C6 latency for 36xx wrong, and it's much faster than
for 34xx? I wonder what happens on the original beagleboard, not the
xm variant.. I don't have one though.
> > Based on my experiments the FIFO threshold does not matter as even if we
> > should not be able to leave from a C state in time, we do leave from the state :o
Yes that's a mystery :)
> > The patch generates the following warning when the playback is stopped:
...
> > [ 115.996002] [<c0155b74>] (__cancel_work_timer) from [<c0199ad8>]
> > (pm_qos_remove_request+0x28/0x1c8)
> > [ 116.005523] [<c0199ad8>] (pm_qos_remove_request) from [<c0684634>]
> > (omap_mcbsp_dai_trigger+0x70/0x8c)
> > [ 116.015197] [<c0684634>] (omap_mcbsp_dai_trigger) from [<c067baa8>]
> > (soc_pcm_trigger+0xd0/0x11c)
> > [ 116.024414] [<c067baa8>] (soc_pcm_trigger) from [<c0663be0>]
> > (snd_pcm_do_stop+0x50/0x54)
> > [ 116.032928] [<c0663be0>] (snd_pcm_do_stop) from [<c06639c4>]
> > (snd_pcm_action_single+0x38/0x80)
Hmm OK I wonder why have not seen that one, I've been just hitting ctrl-c
to stop the playback.
> > There is one more issue: if we have playback and capture running at the same
> > time and you stop one of them. It will remove the QoS and the remaining stream
> > might break.
>
> it is better to place the QoS in omap_mcbsp_request() and remove it in
> omap_mcbsp_free(). This way we retain the QoS for the time the McBSP is in
> active use.
OK makes sense.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
