On Thu, Apr 13, 2017 at 08:01:34AM +0000, Olivier MOYSAN wrote:
- 2 static dais NOT exclusive
- dai tx
- dai rx
The IP exhibits a mode register, where you select mode TX, RX or FD. There are 2 two options to manage this register. option 1: start first channel with mode RX or TX when second channel is started, mode has to be changed to FD. Transfers have to be stopped before changing configuration registers, so this leads to cuts in audio stream. option 2: start a first channel with mode FD. In this case, we may have unpredictable behavior for the stream which is not already started. probably underrun/overrun. So, this solution rises problem for full-duplex management.
- 3 static dais exclusive
- dai tx
- dai rx
- dai rx-tx (fd)
This is the current implementation. The choice of the dai is done at probe time. It is provided by DT through sound-dai parameter. When dai fd is selected, after starting first stream, we assume that second stream will be started. In this case we wait for second stream to be available before enabling IP and starting transfers.
- 1 dynamic dai
- dai rx or tx or fd (according to dma conf in IP node)
Here the driver exposes only a single dai constructed from dma configuration provided by IP DT node. This allows to get ride of sound-dai parameter.
None of these options reflect how normal I2S controllers present themselves in DT. To repeat, you should present a single bidirectional DAI for the single physical bidirectional I2S controller that your hardware has.
If it's not possible to figure out a way to make the controller support simultaneous playback and record with the two started independently then the driver should just return an error if userspace tries to start the second direction up. This will severely limit the utility of the driver as Linux generally treats playback and record independently but that's going to apply just as much with any of the options involving multiple DAIs or configuration in DT. You might be able to do something with feeding it dummy data I guess?