TX/RX FIFO underrun shouldn't crash the RTOS when it occurs.
Also, since this can also happen under "normal" conditions
(i.e: DMA doesn't copy data fast enough from/to SAI's FIFOs)
the software should be able to recover from it.
As such:
1) Remove `z_irq_spurious()` call.
2) Clear error flag
3) De-escalate error message to warning message
Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
While running the following command:
aplay ... | arecord ...
multiple times, it was discovered that the SAI transmit
FIFO goes into underrun. This only happened in the
beginning, a few BCLK cycles after unmasking the transmit
data line. With the following flow:
1) Trigger start on RX
a) Do TX and RX software reset
b) Enable RX FIFO error interrupt
c) Enable RX DMA requests
d) Enable receive data line
e) Enable transmitter
f) Enable receiver
..... some time has passed .....
2) Trigger start on TX
a) Enable DMA requests
b) Enable transmit data line
and configuration in mind:
1) RX is SYNC with TX
2) TX is ASYNC
3) Each FSYNC edge is 32-bit wide
4) Each frame contains 2 32-bit words
this points to the following possibilites:
1) The transmitter is enabled so close to the
start of a new frame that even though the DMA requests
are asserted, the DMAC doesn't have enough time
to service them until the module goes into underrun
=> the timing is bad.
2) The transmitter is enabled somewhat close to
the start of a new frame such that the DMAC is not
fast enough to service the module until it goes into
underrun => DMAC is too slow AND the timing is bad.
Although the exact cause was not pinpointed, this patch
aims to fix the problem by writing a frame's worth of 0s
in the transmit FIFO. This way, even if we're dealing with
scenario 1) or 2), the DMAC has plenty of time to perform
the transfer (i.e: a frame), thus avoiding the underrun.
Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
Add support for performing pinctrl operations. For now,
the only supported operation is applying the pinctrl default
state. Pinctrl is left optional to allow for scenarios in which
this is not required (e.g: AMP system in which another
OS configures the pinctrl).
Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
Some SAI instances are mutliline, meaning they can have multiple
TX/RX data lines (channels). Depending on the board, the index
of the TX/RX data lines that are connected to the consumer
(e.g: the codec) may not always be 0. This commit fixes this
issue by adding support for passing the index of the used
TX/RX data lines through the DTS.
Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
Since a DMA cell now allows specifying a channel and a MUX value
there's no need to fetch these values from the HAL. This, in turn,
allows for more flexibility and reduces the coding effort for new
platforms that want to use the SAI driver.
Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
Currently, whenever performing TRIGGER_PAUSE operation, the
data line is not disabled. This works well if TX and RX don't
operate at the same time or they operate in ASYNC-ASYNC mode. This
is because sai_tx_rx_disable() will disable transmitter/receiver
all the time since there's no dependencies to take into consideration.
However, in the ASYNC-SYNC mode, sai_tx_rx_disable() may not disable
the current asynchronous side if the synchronous side is still enabled.
As a consequence, the asynchronous side will remain enabled, thus
leading to an underrun/overrun.
To fix this issue, sai_trigger_pause() should disable the data line
each time it's called. This way, even if sai_tx_rx_disable() doesn't
disable the current direction, the data line will be disabled, thus
stopping the consumption/production of frames.
Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
It might happens that DT(_INST)_PROP_OR is used with boolean properties.
For instance:
.single_wire = DT_INST_PROP_OR(index, single_wire, false), \
.tx_rx_swap = DT_INST_PROP_OR(index, tx_rx_swap, false), \
This is not required as boolean properties are generated with false
value when not present, so the _OR macro extension is superflous
and the above code can be replaced by:
.single_wire = DT_INST_PROP(index, single_wire), \
.tx_rx_swap = DT_INST_PROP(index, tx_rx_swap), \
Signed-off-by: Roman Studenikin <srv@meta.com>
ERRATA 051421 states that if the SAI is FSYNC/BCLK master,
one of the directions is SYNC with the other, and the
ASYNC direction has the BYP bit toggled, the SYNC direction's
BCLK won't be generated properly.
This commit fixes this issue by enabling BCI for the SYNC
direction. What this does is it makes the SYNC direction use
the BCLK from the ASYNC direction's pad, which, if the BYP
bit is toggled, will be the undivided MCLK. Without this fix,
the SYNC direction will use the ASYNC direction's BCLK obtained
by dividing the MCLK via the following formula: MCLK / ((DIV + 1) * 2).
This is wrong because the ASYNC direction will use an undivided
MCLK while the SYNC direction will use a divided MCLK.
Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
With the introduction of the "rx_sync_mode" and "tx_sync_mode"
properties, the user may choose which synchronization mode the
SAI should use. To support this, the code had to be changed a
bit such that the software reset and the disable operations
work on all synchronization modes.
What this commit does, is it changes the software reset and
disable sequences such that they work with any of the
supported synchronization modes. Also, the syncMode field
of sai_transceiver_t structure is set to the value passed
from the DTS during sai_config_set().
Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
In preparation for supporting all synchronization modes, this
commit introduces the rx_sync_mode/tx_sync_mode DTS properties.
Using these, the user will be able to specify which synchronization
mode the SAI should use.
At the moment, the driver does nothing with the values from
said properties but still checks if their values are sane
(i.e: it checks if the directions are both in SYNC mode which
is forbidden). By default, if "rx_sync_mode" or "tx_sync_mode"
is not specified, the direction will be set to ASYNC mode.
As such, below one may find a couple of valid examples
depicting this idea:
tx_sync_mode = <0>;
rx_sync_mode = <0>;
is the same as not specifying any of the properties,
tx_sync_mode = <1>;
rx_sync_mode = <0>;
is the same as:
tx_sync_mode = <1>;
Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
