[alsa-devel] [RFC PATCH 2/4] ALSA: core: add .notify callback for pcm ops

[Takashi Iwai]

On Wed, 08 Jul 2015 19:10:32 +0200,
Pierre-Louis Bossart wrote:
> 
> 
> >> This is only enabled when the NO_REWIND hardware flag is used,
> >> so that the low-level driver/hardware to opportunistically pre-fetch
> >> data.
> >>
> >> FIXME: should we rely on .ack for this?
> >> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart at linux.intel.com>
> >
> > Hmm, OK, so the forward is allowed but with workarounds...
> > But then why rewind won't work in a similar way?  DSP might be able to
> > cancel some of inflight data.
> 
> Nope, this is explicitly not supported, so unfortunately if we want to 
> optimize for power and let hardware fetch data when it's most 
> appropriate rewinds need to be disabled.
> 
> > In other words, I see no reason to strict notify callback only for
> > no_rewinds.  This is an optional ops in anyway.
> 
> It's fine to remove the check. I added this based on internal review 
> comments but I agree with your point.

OK, then let's treat the NO_REWIND and new ops individually.

> > Also, I find the name "notify" a bit too ambiguous.  In this case,
> > it's notifying the applptr change.  So, a name related with the
> > function would be more understandable.
> 
> The first open I had was to know if we could use .ack for this? if a 
> different callback is needed, we can use 'appl_ptr_update' instead of 
> 'notify'

As there are no many users of ack callback, I don't mind to reuse it.
But then we need to extend the function to receive a new argument
indicating the type of ack, right?


thanks,

Takashi