On Mon, Oct 07, 2013 at 06:27:06PM +0100, Mark Brown wrote:
On Fri, Oct 04, 2013 at 12:53:17PM +0200, Markus Pargmann wrote:
In case of a start command, the calling function will call undo_start, calling this trigger function with the stop command. It will call stop for each function. But only the first function was started previously. The other functions may fail in the assumption that a stop command always comes after a start command.
As the API does not specify the behaviour of trigger functionpointers, I think this should be fixed in the function calling the trigger functionpointers.
This patch changes the behaviour. The trigger function calls all functionpointers independent of their returncodes. The first error-code is returned.
I'm not sure if this will resolve the problem robustly - if something is going to get confused about this it seems just as likely that the trigger that failed will get upset because it gets a _STOP after returning an error from _START. I think what I'd expect here is that the unwind on error would unwind only the triggers that it successfully ran. Equally well I'd be a bit surprised if a trigger function actually had a problem with extra _STOPs since they mostly just do register writes... did you see this from code inspection or were you resolving a practical problem in your system?
Yes this is a practical problem on mx28. mxs-saif enables/disables clocks when starting/stopping. I debugged a problem where the DMA engine returned an error on channel preparation and clk_disabled in mxs-saif was called twice.
To make proper error handling and only STOP functions that successfully started, we have to store the state of each function. The command error handling is done in pcm_native.c so we don't have any influence on that.
Another possibility is to explicitly allow multiple _STOPs. Then I could fix the driver to store the clock state. But I would prefer a generic solution.
Regards,
Markus