[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