Hi,
I stumbled into an issues with the tegra-serial driver, which fails to
acquire a dma channel after the first shutdown() call on any of the
channels. The effect is, that once a ttyTHSx device was opened and then
closed none of the existang ttyTHSx devices can be opened anymore.
I tracked this down to some messing with the DMA_PRIVATE flag. The
tegra-serial driver makes use of dma_request_slave_channel_reason to
acquire a tx and a rx channel. Via of_dma_request_slave_channel the call
goes through tegra_dma_of_xlate which finally calls
dma_get_any_slave_channel. This again calls private_candidate to
actually select a channel and finally dma_chan_get to acquire the channel.
On shutdown the tegra-serial driver calls dma_release_channel for both
channels. Now this is where things break, because dma_release_channel
does decrease privatecnt and drops the DMA_PRIVATE flag once the
privatecnt reached zero. This happens immediately, so that the flag is
cleared and the next call to private_candidate will fail.
The comment before decreasing privatecnt suggests that it is assumed
that the channel which is release was acquired by __dma_request_channel,
which increases the privatecnt.
This allows two conclusion:
(a) dma_request_slave_channel and dma_request_slave_channel_reason shall
increase the privatecnt just like __dma_request_channel does.
(b) dma_release_channel must not be used for channels which have not
been acquired via __dma_request_channel.
I have implemented (a) in my tree and it works, but as I am copletely
new to dmaengine I am very unsure whether this is the right approach.
I'd be glad to have some feedback by someone with better insights to the
dmaengine and the whole DMA_PRIVATE construct than I have.
-Julian
--
To unsubscribe from this list: send the line "unsubscribe dmaengine" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
