devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 1/2] ASoC: fsl: fsl_ssi: add ac97 fixed mode support
@ 2020-10-05 11:16 Primoz Fiser
  2020-10-05 11:16 ` [PATCH 2/2] ASoC: dt-bindings: fsl: " Primoz Fiser
                   ` (2 more replies)
  0 siblings, 3 replies; 11+ messages in thread
From: Primoz Fiser @ 2020-10-05 11:16 UTC (permalink / raw)
  To: alsa-devel
  Cc: Timur Tabi, Nicolin Chen, Xiubo Li, Fabio Estevam, Shengjiu Wang,
	Liam Girdwood, Mark Brown, Jaroslav Kysela, Takashi Iwai,
	Rob Herring, devicetree

SSI supports "variable" and "fixed" mode of operation in AC'97 mode. Up
to now, driver always configured SSI port to operate in "variable" AC'97
mode which is known to be unreliable with some CODECs, see:
commit 01ca485171e3 ("ASoC: fsl_ssi: only enable proper channel slots in
AC'97 mode") for more information on issues related to spurious SLOTREQ
bits. But in summary, when SSI operates in AC'97 variable mode of
operation, CODECs can sometimes send SLOTREQ bits for non-existent audio
slots which then "stick" in SSI and completely break audio output.
Contrary when operating SSI in AC'97 fixed mode, described issues were
completely gone!

Thus add support for operating SSI in AC'97 Fixed Mode of operation
which provides better audio reliability when compared to AC'97 Variable
Mode with some CODECs.

Signed-off-by: Primoz Fiser <primoz.fiser@norik.com>
---
 sound/soc/fsl/fsl_ssi.c | 18 ++++++++++++++++--
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index 404be27c15fe..3b89785f6de8 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -243,6 +243,7 @@ struct fsl_ssi_soc_data {
  * @dma_maxburst: Max number of words to transfer in one go. So far,
  *                this is always the same as fifo_watermark.
  * @ac97_reg_lock: Mutex lock to serialize AC97 register access operations
+ * @ac97_fixed_mode: SSI in AC97 fixed mode of operation
  */
 struct fsl_ssi {
 	struct regmap *regs;
@@ -287,6 +288,7 @@ struct fsl_ssi {
 	u32 dma_maxburst;
 
 	struct mutex ac97_reg_lock;
+	bool ac97_fixed_mode;
 };
 
 /*
@@ -616,7 +618,12 @@ static void fsl_ssi_setup_ac97(struct fsl_ssi *ssi)
 	regmap_write(regs, REG_SSI_SRCCR, SSI_SxCCR_WL(17) | SSI_SxCCR_DC(13));
 
 	/* Enable AC97 mode and startup the SSI */
-	regmap_write(regs, REG_SSI_SACNT, SSI_SACNT_AC97EN | SSI_SACNT_FV);
+	if (ssi->ac97_fixed_mode) {
+		regmap_write(regs, REG_SSI_SACNT, SSI_SACNT_AC97EN);
+		regmap_write(regs, REG_SSI_SATAG, 0x9800);
+	} else
+		regmap_write(regs, REG_SSI_SACNT,
+				SSI_SACNT_AC97EN | SSI_SACNT_FV);
 
 	/* AC97 has to communicate with codec before starting a stream */
 	regmap_update_bits(regs, REG_SSI_SCR,
@@ -1092,8 +1099,10 @@ static int fsl_ssi_trigger(struct snd_pcm_substream *substream, int cmd,
 		 * send valid data to slots other than normal playback slots.
 		 *
 		 * To be safe, configure SACCST right before TX starts.
+		 *
+		 * Above applies only when SSI operates in AC97 Variable Mode.
 		 */
-		if (tx && fsl_ssi_is_ac97(ssi))
+		if (tx && fsl_ssi_is_ac97(ssi) && !ssi->ac97_fixed_mode)
 			fsl_ssi_tx_ac97_saccst_setup(ssi);
 		fsl_ssi_config_enable(ssi, tx);
 		break;
@@ -1437,6 +1446,11 @@ static int fsl_ssi_probe_from_dt(struct fsl_ssi *ssi)
 		ssi->synchronous = true;
 	}
 
+	/* Check AC97 mode of operation */
+	sprop = of_get_property(np, "fsl,ac97-mode", NULL);
+	if (sprop && !strcmp(sprop, "fixed"))
+		ssi->ac97_fixed_mode = true;
+
 	/* Select DMA or FIQ */
 	ssi->use_dma = !of_property_read_bool(np, "fsl,fiq-stream-filter");
 
-- 
2.25.1


^ permalink raw reply related	[flat|nested] 11+ messages in thread

* [PATCH 2/2] ASoC: dt-bindings: fsl: add ac97 fixed mode support
  2020-10-05 11:16 [PATCH 1/2] ASoC: fsl: fsl_ssi: add ac97 fixed mode support Primoz Fiser
@ 2020-10-05 11:16 ` Primoz Fiser
  2020-10-05 11:35   ` Fabio Estevam
  2020-10-05 11:34 ` [PATCH 1/2] ASoC: fsl: fsl_ssi: " Fabio Estevam
  2020-10-05 11:49 ` Mark Brown
  2 siblings, 1 reply; 11+ messages in thread
From: Primoz Fiser @ 2020-10-05 11:16 UTC (permalink / raw)
  To: alsa-devel
  Cc: Timur Tabi, Nicolin Chen, Xiubo Li, Fabio Estevam, Shengjiu Wang,
	Liam Girdwood, Mark Brown, Jaroslav Kysela, Takashi Iwai,
	Rob Herring, devicetree

Add devicetree bindings documentation for operating SSI in AC'97
variable/fixed mode of operation.

Signed-off-by: Primoz Fiser <primoz.fiser@norik.com>
---
 Documentation/devicetree/bindings/sound/fsl,ssi.txt | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/sound/fsl,ssi.txt b/Documentation/devicetree/bindings/sound/fsl,ssi.txt
index 7e15a85cecd2..abc5abe11fb9 100644
--- a/Documentation/devicetree/bindings/sound/fsl,ssi.txt
+++ b/Documentation/devicetree/bindings/sound/fsl,ssi.txt
@@ -43,6 +43,11 @@ Optional properties:
 - fsl,mode:         The operating mode for the AC97 interface only.
                     "ac97-slave" - AC97 mode, SSI is clock slave
                     "ac97-master" - AC97 mode, SSI is clock master
+- fsl,ac97-mode:    SSI AC97 mode of operation.
+                    "variable" - AC97 Variable Mode, SLOTREQ bits determine
+                    next receive/transmit frame
+                    "fixed" - AC97 Fixed Mode, SSI transmits in accordance with
+                    AC97 Frame Rate Divider bits
 - fsl,ssi-asynchronous:
                     If specified, the SSI is to be programmed in asynchronous
                     mode.  In this mode, pins SRCK, STCK, SRFS, and STFS must
-- 
2.25.1


^ permalink raw reply related	[flat|nested] 11+ messages in thread

* Re: [PATCH 1/2] ASoC: fsl: fsl_ssi: add ac97 fixed mode support
  2020-10-05 11:16 [PATCH 1/2] ASoC: fsl: fsl_ssi: add ac97 fixed mode support Primoz Fiser
  2020-10-05 11:16 ` [PATCH 2/2] ASoC: dt-bindings: fsl: " Primoz Fiser
@ 2020-10-05 11:34 ` Fabio Estevam
  2020-10-05 11:49 ` Mark Brown
  2 siblings, 0 replies; 11+ messages in thread
From: Fabio Estevam @ 2020-10-05 11:34 UTC (permalink / raw)
  To: Primoz Fiser
  Cc: Linux-ALSA, Timur Tabi, Nicolin Chen, Xiubo Li, Shengjiu Wang,
	Liam Girdwood, Mark Brown, Jaroslav Kysela, Takashi Iwai,
	Rob Herring,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS

Hi Primoz,

On Mon, Oct 5, 2020 at 8:16 AM Primoz Fiser <primoz.fiser@norik.com> wrote:
>
> SSI supports "variable" and "fixed" mode of operation in AC'97 mode. Up
> to now, driver always configured SSI port to operate in "variable" AC'97
> mode which is known to be unreliable with some CODECs, see:
> commit 01ca485171e3 ("ASoC: fsl_ssi: only enable proper channel slots in
> AC'97 mode") for more information on issues related to spurious SLOTREQ
> bits. But in summary, when SSI operates in AC'97 variable mode of
> operation, CODECs can sometimes send SLOTREQ bits for non-existent audio
> slots which then "stick" in SSI and completely break audio output.
> Contrary when operating SSI in AC'97 fixed mode, described issues were
> completely gone!
>
> Thus add support for operating SSI in AC'97 Fixed Mode of operation
> which provides better audio reliability when compared to AC'97 Variable
> Mode with some CODECs.
>
> Signed-off-by: Primoz Fiser <primoz.fiser@norik.com>
> ---
>  sound/soc/fsl/fsl_ssi.c | 18 ++++++++++++++++--
>  1 file changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
> index 404be27c15fe..3b89785f6de8 100644
> --- a/sound/soc/fsl/fsl_ssi.c
> +++ b/sound/soc/fsl/fsl_ssi.c
> @@ -243,6 +243,7 @@ struct fsl_ssi_soc_data {
>   * @dma_maxburst: Max number of words to transfer in one go. So far,
>   *                this is always the same as fifo_watermark.
>   * @ac97_reg_lock: Mutex lock to serialize AC97 register access operations
> + * @ac97_fixed_mode: SSI in AC97 fixed mode of operation
>   */
>  struct fsl_ssi {
>         struct regmap *regs;
> @@ -287,6 +288,7 @@ struct fsl_ssi {
>         u32 dma_maxburst;
>
>         struct mutex ac97_reg_lock;
> +       bool ac97_fixed_mode;
>  };
>
>  /*
> @@ -616,7 +618,12 @@ static void fsl_ssi_setup_ac97(struct fsl_ssi *ssi)
>         regmap_write(regs, REG_SSI_SRCCR, SSI_SxCCR_WL(17) | SSI_SxCCR_DC(13));
>
>         /* Enable AC97 mode and startup the SSI */
> -       regmap_write(regs, REG_SSI_SACNT, SSI_SACNT_AC97EN | SSI_SACNT_FV);
> +       if (ssi->ac97_fixed_mode) {
> +               regmap_write(regs, REG_SSI_SACNT, SSI_SACNT_AC97EN);
> +               regmap_write(regs, REG_SSI_SATAG, 0x9800);
> +       } else

Should be } else { because the previous if block used curly braces.

> +               regmap_write(regs, REG_SSI_SACNT,
> +                               SSI_SACNT_AC97EN | SSI_SACNT_FV);

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH 2/2] ASoC: dt-bindings: fsl: add ac97 fixed mode support
  2020-10-05 11:16 ` [PATCH 2/2] ASoC: dt-bindings: fsl: " Primoz Fiser
@ 2020-10-05 11:35   ` Fabio Estevam
  2020-10-06 21:52     ` Rob Herring
  0 siblings, 1 reply; 11+ messages in thread
From: Fabio Estevam @ 2020-10-05 11:35 UTC (permalink / raw)
  To: Primoz Fiser
  Cc: Linux-ALSA, Timur Tabi, Nicolin Chen, Xiubo Li, Shengjiu Wang,
	Liam Girdwood, Mark Brown, Jaroslav Kysela, Takashi Iwai,
	Rob Herring,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS

On Mon, Oct 5, 2020 at 8:16 AM Primoz Fiser <primoz.fiser@norik.com> wrote:
>
> Add devicetree bindings documentation for operating SSI in AC'97
> variable/fixed mode of operation.
>
> Signed-off-by: Primoz Fiser <primoz.fiser@norik.com>
> ---
>  Documentation/devicetree/bindings/sound/fsl,ssi.txt | 5 +++++
>  1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/sound/fsl,ssi.txt b/Documentation/devicetree/bindings/sound/fsl,ssi.txt
> index 7e15a85cecd2..abc5abe11fb9 100644
> --- a/Documentation/devicetree/bindings/sound/fsl,ssi.txt
> +++ b/Documentation/devicetree/bindings/sound/fsl,ssi.txt
> @@ -43,6 +43,11 @@ Optional properties:
>  - fsl,mode:         The operating mode for the AC97 interface only.
>                      "ac97-slave" - AC97 mode, SSI is clock slave
>                      "ac97-master" - AC97 mode, SSI is clock master
> +- fsl,ac97-mode:    SSI AC97 mode of operation.
> +                    "variable" - AC97 Variable Mode, SLOTREQ bits determine
> +                    next receive/transmit frame
> +                    "fixed" - AC97 Fixed Mode, SSI transmits in accordance with
> +                    AC97 Frame Rate Divider bits

It would be good to mention what is the default mode when such
property is absent.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH 1/2] ASoC: fsl: fsl_ssi: add ac97 fixed mode support
  2020-10-05 11:16 [PATCH 1/2] ASoC: fsl: fsl_ssi: add ac97 fixed mode support Primoz Fiser
  2020-10-05 11:16 ` [PATCH 2/2] ASoC: dt-bindings: fsl: " Primoz Fiser
  2020-10-05 11:34 ` [PATCH 1/2] ASoC: fsl: fsl_ssi: " Fabio Estevam
@ 2020-10-05 11:49 ` Mark Brown
  2020-10-05 12:59   ` Primoz Fiser
  2 siblings, 1 reply; 11+ messages in thread
From: Mark Brown @ 2020-10-05 11:49 UTC (permalink / raw)
  To: Primoz Fiser
  Cc: alsa-devel, Timur Tabi, Nicolin Chen, Xiubo Li, Fabio Estevam,
	Shengjiu Wang, Liam Girdwood, Jaroslav Kysela, Takashi Iwai,
	Rob Herring, devicetree

[-- Attachment #1: Type: text/plain, Size: 459 bytes --]

On Mon, Oct 05, 2020 at 01:16:43PM +0200, Primoz Fiser wrote:

> bits. But in summary, when SSI operates in AC'97 variable mode of
> operation, CODECs can sometimes send SLOTREQ bits for non-existent audio
> slots which then "stick" in SSI and completely break audio output.

If this is something that happens based on the CODEC shouldn't we be
doing this by quirking based on the CODEC the system has rather than
requiring people set a separate DT property?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH 1/2] ASoC: fsl: fsl_ssi: add ac97 fixed mode support
  2020-10-05 11:49 ` Mark Brown
@ 2020-10-05 12:59   ` Primoz Fiser
  2020-10-05 13:51     ` Maciej S. Szmigiero
  2020-10-05 22:03     ` Mark Brown
  0 siblings, 2 replies; 11+ messages in thread
From: Primoz Fiser @ 2020-10-05 12:59 UTC (permalink / raw)
  To: Mark Brown
  Cc: alsa-devel, Timur Tabi, Nicolin Chen, Xiubo Li, Fabio Estevam,
	Shengjiu Wang, Liam Girdwood, Jaroslav Kysela, Takashi Iwai,
	Rob Herring, devicetree, Maciej S. Szmigiero

Hi Mark,

On 5. 10. 20 13:49, Mark Brown wrote:
> On Mon, Oct 05, 2020 at 01:16:43PM +0200, Primoz Fiser wrote:
> 
>> bits. But in summary, when SSI operates in AC'97 variable mode of
>> operation, CODECs can sometimes send SLOTREQ bits for non-existent audio
>> slots which then "stick" in SSI and completely break audio output.
> 
> If this is something that happens based on the CODEC shouldn't we be
> doing this by quirking based on the CODEC the system has rather than
> requiring people set a separate DT property?
> 

To be totally honest, we are not 100% sure if this is only CODEC's fault 
or something else might be causing these issues.

For example, it could be some EMI/noise that causes SLOTREQ bits to flip 
spuriously. Or it could even be the buggy SSI itself (taking into 
account all the issues with channel slipping, slot filtering, AC'97 reg 
reading/writing, etc)?

We are just referencing commit 01ca485171e3 ("ASoC: fsl_ssi: only enable 
proper channel slots in AC'97 mode"), as we saw that UDOO board had the 
same problems. I added commit author to CC.

We were able to overcome those by programming SSI in AC'97 fixed mode 
which driver up to now completely ignored (it was using only AC'97 
variable mode).

Additionally, we are using WM9712 codec and UDOO board is using VT1613, 
right? So these issues might not be CODEC related at all.

BR,
Primoz





^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH 1/2] ASoC: fsl: fsl_ssi: add ac97 fixed mode support
  2020-10-05 12:59   ` Primoz Fiser
@ 2020-10-05 13:51     ` Maciej S. Szmigiero
  2020-10-07  7:01       ` Primoz Fiser
  2020-10-05 22:03     ` Mark Brown
  1 sibling, 1 reply; 11+ messages in thread
From: Maciej S. Szmigiero @ 2020-10-05 13:51 UTC (permalink / raw)
  To: Primoz Fiser, Mark Brown
  Cc: alsa-devel, Timur Tabi, Nicolin Chen, Xiubo Li, Fabio Estevam,
	Shengjiu Wang, Liam Girdwood, Jaroslav Kysela, Takashi Iwai,
	Rob Herring, devicetree

On 05.10.2020 14:59, Primoz Fiser wrote:
> Hi Mark,
> 
> On 5. 10. 20 13:49, Mark Brown wrote:
>> On Mon, Oct 05, 2020 at 01:16:43PM +0200, Primoz Fiser wrote:
>>
>>> bits. But in summary, when SSI operates in AC'97 variable mode of
>>> operation, CODECs can sometimes send SLOTREQ bits for non-existent audio
>>> slots which then "stick" in SSI and completely break audio output.
>>
>> If this is something that happens based on the CODEC shouldn't we be
>> doing this by quirking based on the CODEC the system has rather than
>> requiring people set a separate DT property?
>>
> 
> To be totally honest, we are not 100% sure if this is only CODEC's fault or something else might be causing these issues.
> 
> For example, it could be some EMI/noise that causes SLOTREQ bits to flip spuriously. Or it could even be the buggy SSI itself (taking into account all the issues with channel slipping, slot filtering, AC'97 reg reading/writing, etc)?
> 
> We are just referencing commit 01ca485171e3 ("ASoC: fsl_ssi: only enable proper channel slots in AC'97 mode"), as we saw that UDOO board had the same problems. I added commit author to CC.
> 
> We were able to overcome those by programming SSI in AC'97 fixed mode which driver up to now completely ignored (it was using only AC'97 variable mode).
> 
> Additionally, we are using WM9712 codec and UDOO board is using VT1613, right? So these issues might not be CODEC related at all.

I remember that the AC'97 mode in SSI was riddled with bugs to a level of
being barely usable.

Not only the channel slots would enable on their own, but the CODEC
registers got randomly trashed from time to time (I think a register
would get zeroed spontaneously).

This happened even if an external CODEC, different than the boards
VT1613, was connected.
So these were definitely SSI problems, not CODEC ones.

That's why probably pretty much every board other than UDOO uses SSI
in the I²S mode.

Maciej

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH 1/2] ASoC: fsl: fsl_ssi: add ac97 fixed mode support
  2020-10-05 12:59   ` Primoz Fiser
  2020-10-05 13:51     ` Maciej S. Szmigiero
@ 2020-10-05 22:03     ` Mark Brown
  1 sibling, 0 replies; 11+ messages in thread
From: Mark Brown @ 2020-10-05 22:03 UTC (permalink / raw)
  To: Primoz Fiser
  Cc: alsa-devel, Timur Tabi, Nicolin Chen, Xiubo Li, Fabio Estevam,
	Shengjiu Wang, Liam Girdwood, Jaroslav Kysela, Takashi Iwai,
	Rob Herring, devicetree, Maciej S. Szmigiero

[-- Attachment #1: Type: text/plain, Size: 808 bytes --]

On Mon, Oct 05, 2020 at 02:59:53PM +0200, Primoz Fiser wrote:
> On 5. 10. 20 13:49, Mark Brown wrote:

> > If this is something that happens based on the CODEC shouldn't we be
> > doing this by quirking based on the CODEC the system has rather than
> > requiring people set a separate DT property?

> To be totally honest, we are not 100% sure if this is only CODEC's fault or
> something else might be causing these issues.

OK, the description made it sound like it was an interop issue with the
CODEC but if there's concerns about there being board related issues
then a property is fine.

> Additionally, we are using WM9712 codec and UDOO board is using VT1613,
> right? So these issues might not be CODEC related at all.

ISTR people had got the WM9712 (or was it WM9713?) working with some
i.MX SoCs.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH 2/2] ASoC: dt-bindings: fsl: add ac97 fixed mode support
  2020-10-05 11:35   ` Fabio Estevam
@ 2020-10-06 21:52     ` Rob Herring
  2020-10-07  6:49       ` Primoz Fiser
  0 siblings, 1 reply; 11+ messages in thread
From: Rob Herring @ 2020-10-06 21:52 UTC (permalink / raw)
  To: Fabio Estevam
  Cc: Primoz Fiser, Linux-ALSA, Timur Tabi, Nicolin Chen, Xiubo Li,
	Shengjiu Wang, Liam Girdwood, Mark Brown, Jaroslav Kysela,
	Takashi Iwai,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS

On Mon, Oct 05, 2020 at 08:35:58AM -0300, Fabio Estevam wrote:
> On Mon, Oct 5, 2020 at 8:16 AM Primoz Fiser <primoz.fiser@norik.com> wrote:
> >
> > Add devicetree bindings documentation for operating SSI in AC'97
> > variable/fixed mode of operation.
> >
> > Signed-off-by: Primoz Fiser <primoz.fiser@norik.com>
> > ---
> >  Documentation/devicetree/bindings/sound/fsl,ssi.txt | 5 +++++
> >  1 file changed, 5 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/sound/fsl,ssi.txt b/Documentation/devicetree/bindings/sound/fsl,ssi.txt
> > index 7e15a85cecd2..abc5abe11fb9 100644
> > --- a/Documentation/devicetree/bindings/sound/fsl,ssi.txt
> > +++ b/Documentation/devicetree/bindings/sound/fsl,ssi.txt
> > @@ -43,6 +43,11 @@ Optional properties:
> >  - fsl,mode:         The operating mode for the AC97 interface only.
> >                      "ac97-slave" - AC97 mode, SSI is clock slave
> >                      "ac97-master" - AC97 mode, SSI is clock master
> > +- fsl,ac97-mode:    SSI AC97 mode of operation.
> > +                    "variable" - AC97 Variable Mode, SLOTREQ bits determine
> > +                    next receive/transmit frame
> > +                    "fixed" - AC97 Fixed Mode, SSI transmits in accordance with
> > +                    AC97 Frame Rate Divider bits
> 
> It would be good to mention what is the default mode when such
> property is absent.

Then perhaps it could be boolean?

Rob

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH 2/2] ASoC: dt-bindings: fsl: add ac97 fixed mode support
  2020-10-06 21:52     ` Rob Herring
@ 2020-10-07  6:49       ` Primoz Fiser
  0 siblings, 0 replies; 11+ messages in thread
From: Primoz Fiser @ 2020-10-07  6:49 UTC (permalink / raw)
  To: Rob Herring, Fabio Estevam
  Cc: Linux-ALSA, Timur Tabi, Nicolin Chen, Xiubo Li, Shengjiu Wang,
	Liam Girdwood, Mark Brown, Jaroslav Kysela, Takashi Iwai,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS

Hi,

> Then perhaps it could be boolean?

Indeed, I can make it boolean.

In that case I would rename property to "fsl,ac97-fixed-mode".

Should I do that for V2?

Please advise.

BR,
Primoz


On 6. 10. 20 23:52, Rob Herring wrote:
> On Mon, Oct 05, 2020 at 08:35:58AM -0300, Fabio Estevam wrote:
>> On Mon, Oct 5, 2020 at 8:16 AM Primoz Fiser <primoz.fiser@norik.com> wrote:
>>>
>>> Add devicetree bindings documentation for operating SSI in AC'97
>>> variable/fixed mode of operation.
>>>
>>> Signed-off-by: Primoz Fiser <primoz.fiser@norik.com>
>>> ---
>>>   Documentation/devicetree/bindings/sound/fsl,ssi.txt | 5 +++++
>>>   1 file changed, 5 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/sound/fsl,ssi.txt b/Documentation/devicetree/bindings/sound/fsl,ssi.txt
>>> index 7e15a85cecd2..abc5abe11fb9 100644
>>> --- a/Documentation/devicetree/bindings/sound/fsl,ssi.txt
>>> +++ b/Documentation/devicetree/bindings/sound/fsl,ssi.txt
>>> @@ -43,6 +43,11 @@ Optional properties:
>>>   - fsl,mode:         The operating mode for the AC97 interface only.
>>>                       "ac97-slave" - AC97 mode, SSI is clock slave
>>>                       "ac97-master" - AC97 mode, SSI is clock master
>>> +- fsl,ac97-mode:    SSI AC97 mode of operation.
>>> +                    "variable" - AC97 Variable Mode, SLOTREQ bits determine
>>> +                    next receive/transmit frame
>>> +                    "fixed" - AC97 Fixed Mode, SSI transmits in accordance with
>>> +                    AC97 Frame Rate Divider bits
>>
>> It would be good to mention what is the default mode when such
>> property is absent.
> 
> Then perhaps it could be boolean?
> 
> Rob
> 

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH 1/2] ASoC: fsl: fsl_ssi: add ac97 fixed mode support
  2020-10-05 13:51     ` Maciej S. Szmigiero
@ 2020-10-07  7:01       ` Primoz Fiser
  0 siblings, 0 replies; 11+ messages in thread
From: Primoz Fiser @ 2020-10-07  7:01 UTC (permalink / raw)
  To: Maciej S. Szmigiero, Mark Brown
  Cc: devicetree, alsa-devel, Timur Tabi, Xiubo Li, Fabio Estevam,
	Takashi Iwai, Liam Girdwood, Nicolin Chen, Rob Herring,
	Shengjiu Wang

Hi Maciej,

>> I remember that the AC'97 mode in SSI was riddled with bugs to a level of
>> being barely usable.

True.

After exhausting work we managed to get it stable enough to be ready for 
"production". One of improvements was the use of AC'97 fixed mode 
instead of variable mode. Other improvements to fsl_ssi by us might 
follow in the future, but at the moment I don't think those are ready 
for "mainline".

>> Not only the channel slots would enable on their own, but the CODEC
>> registers got randomly trashed from time to time (I think a register
>> would get zeroed spontaneously).

Yes, we also encountered those issues. For this we use special thread in 
a loop to check the state of AC'97 registers. We store known good values 
and check for discrepancies while audio is running. Once discrepancy is 
found, we immediately recover the register value with the previous good 
value. Downside of this approach is that audio might be down for a 
period of thread loop and that's why we keep it tight at 1 Hz.

BR,
Primoz


On 5. 10. 20 15:51, Maciej S. Szmigiero wrote:
> On 05.10.2020 14:59, Primoz Fiser wrote:
>> Hi Mark,
>>
>> On 5. 10. 20 13:49, Mark Brown wrote:
>>> On Mon, Oct 05, 2020 at 01:16:43PM +0200, Primoz Fiser wrote:
>>>
>>>> bits. But in summary, when SSI operates in AC'97 variable mode of
>>>> operation, CODECs can sometimes send SLOTREQ bits for non-existent audio
>>>> slots which then "stick" in SSI and completely break audio output.
>>>
>>> If this is something that happens based on the CODEC shouldn't we be
>>> doing this by quirking based on the CODEC the system has rather than
>>> requiring people set a separate DT property?
>>>
>>
>> To be totally honest, we are not 100% sure if this is only CODEC's fault or something else might be causing these issues.
>>
>> For example, it could be some EMI/noise that causes SLOTREQ bits to flip spuriously. Or it could even be the buggy SSI itself (taking into account all the issues with channel slipping, slot filtering, AC'97 reg reading/writing, etc)?
>>
>> We are just referencing commit 01ca485171e3 ("ASoC: fsl_ssi: only enable proper channel slots in AC'97 mode"), as we saw that UDOO board had the same problems. I added commit author to CC.
>>
>> We were able to overcome those by programming SSI in AC'97 fixed mode which driver up to now completely ignored (it was using only AC'97 variable mode).
>>
>> Additionally, we are using WM9712 codec and UDOO board is using VT1613, right? So these issues might not be CODEC related at all.
> 
> I remember that the AC'97 mode in SSI was riddled with bugs to a level of
> being barely usable.
> 
> Not only the channel slots would enable on their own, but the CODEC
> registers got randomly trashed from time to time (I think a register
> would get zeroed spontaneously).
> 
> This happened even if an external CODEC, different than the boards
> VT1613, was connected.
> So these were definitely SSI problems, not CODEC ones.
> 
> That's why probably pretty much every board other than UDOO uses SSI
> in the I²S mode.
> 
> Maciej
> 

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2020-10-07  7:01 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-10-05 11:16 [PATCH 1/2] ASoC: fsl: fsl_ssi: add ac97 fixed mode support Primoz Fiser
2020-10-05 11:16 ` [PATCH 2/2] ASoC: dt-bindings: fsl: " Primoz Fiser
2020-10-05 11:35   ` Fabio Estevam
2020-10-06 21:52     ` Rob Herring
2020-10-07  6:49       ` Primoz Fiser
2020-10-05 11:34 ` [PATCH 1/2] ASoC: fsl: fsl_ssi: " Fabio Estevam
2020-10-05 11:49 ` Mark Brown
2020-10-05 12:59   ` Primoz Fiser
2020-10-05 13:51     ` Maciej S. Szmigiero
2020-10-07  7:01       ` Primoz Fiser
2020-10-05 22:03     ` Mark Brown

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).