[PATCH 1/2] dt-bindings: Document STM32 I2S bindings

Olivier MOYSAN olivier.moysan at st.com
Thu Apr 27 08:57:51 PDT 2017


Hello Mark,

On 04/26/2017 06:15 PM, Mark Brown wrote:
> On Thu, Apr 13, 2017 at 08:01:34AM +0000, Olivier MOYSAN wrote:
>
>> 1) 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.
>
>> 2) 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.
>
>> 3) 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?
>

Ok. I will implement a single bidirectional DAI in v2.

Best regards
Olivier



More information about the linux-arm-kernel mailing list