Posts by daniel.neukomm

The problem is in the kernel. At least the behaviour has changed.

The codec makes a delay of 400ms in snd_pcm_prepare().

This is much too long, and delays and disturbs the audio output.

One solution is described at https://community.nxp.com/t5/i…l5000-latency/td-p/857730

My solution is the parameter no-standby from the device tree file

If no-standby is set, the codec is always powered up. And the 400ms delay disappears.

Index: arch/arm/boot/dts/picocoma7.dts

===================================================================

--- arch/arm/boot/dts/picocoma7.dts (revision 35)

+++ arch/arm/boot/dts/picocoma7.dts (working copy)

@@ -502,6 +502,7 @@

compatible = "fsl,sgtl5000";

reg = <0x0a>;

mono2both;

+ no-standby;

clocks = <&clks IMX6UL_CLK_SAI1>;

VDDA-supply = <&reg_sgtl5000_vdda>;

VDDIO-supply = <&reg_sgtl5000_vddio>;

The version is linux-4.9.88-picocoma7-B2019.11.1.

We did some changes. (added the second uart).

But I don't think that this might impact alsa.

And arecord works.

The software, that runs on the picocomA5 is an echoserver. That means it reads on port 7 udp and resends the data. The other side generates some well known data, sends this data to the picocomA5 and verifies the content. If successfull it prints out the time difference between sending and receiving. This is done in a loop from 10 to 65000 with an increment step of 16. That means the first udp packet has the size 10, the next one 26, etc. The bug ERR6358 could be observed 1 to 10 times for one complete loop. First failures might be around lengths of 2000 to 3000 Bytes. It is very important that there is absolutely no other ethernet traffic on picocoma5. However a tcpdump to a file is allowed. However in the tcpdump on picoA5 you would see, that the netdriver pretends, that it has sent the data. Only the tcpdump on the other side would show the reality. Our test system is an ubuntu system. We detected that in case of the error, the ubuntu send an unicast arp after 4 seconds of silence. This arp packet made the picocom to generate an answer, and then there was a flow of data again.

There's a bug in sgtl5000.c concerning PCM Playback Volume. The TLV entry is missign.
This patch addes the TLV entry.

After that the output of amixer works as expected.
amixer cget name="PCM Playback Volume"
numid=1,iface=MIXER,name='PCM Playback Volume'
; type=INTEGER,access=rw---R--,values=2,min=0,max=192,step=0
: values=180,180
| dBscale-min=-90.00dB,step=0.50dB,mute=0

Index: sound/soc/codecs/sgtl5000.c
===================================================================
--- sound/soc/codecs/sgtl5000.c (revision 99)
+++ sound/soc/codecs/sgtl5000.c (working copy)
@@ -707,6 +707,8 @@
return 0;
}

+static const DECLARE_TLV_DB_SCALE(pcm_playback_volume, -9000,50, 0);
+
static const DECLARE_TLV_DB_SCALE(capture_6db_attenuate, -600, 600, 0);

/* tlv for mic gain, 0db 20db 30db 40db */
@@ -734,6 +736,7 @@
.name = "PCM Playback Volume",
.access = SNDRV_CTL_ELEM_ACCESS_TLV_READ |
SNDRV_CTL_ELEM_ACCESS_READWRITE,
+ .tlv.p = pcm_playback_volume,
.info = dac_info_volsw,
.get = dac_get_volsw,
.put = dac_put_volsw,

NXP decribes in VYBRID_2N02G.pdf a bug in the ethernet controller of the processors imx6 and VF500. This bug in the errata sheet is ERR6358.
The effect is, that some of the ethernetpackets will not be send, or send with a big delay. In fact it is never the first packet, of a bunch of packets, that will be delayed.
In our case, the delay could be 4 seconds or more.
Newer versions of the ethernet driver fec.c have a correction for that problem.
I
This is the patch

Index: drivers/net/fec.c
===================================================================
--- drivers/net/fec.c (revision 94)
+++ drivers/net/fec.c (working copy)
@@ -469,7 +469,12 @@
if (netif_queue_stopped(ndev))
netif_wake_queue(ndev);
}
- }
+ }
+
+ /* ERR006358: Keep the transmitter going */
+ if (bdp != fep->cur_tx && readl(fep->hwp + FEC_X_DES_ACTIVE) == 0)
+ writel(0, fep->hwp + FEC_X_DES_ACTIVE);
+
fep->dirty_tx = bdp;
spin_unlock(&fep->hw_lock);
}

For me, the patch solves the problem.

The recent version linux-3.0.15-fsvybrid-V2.2 does not contain this patch. So I think it is a good idea to give this patch to all users of VF500-processors.
By the way.
All of the iMx6 have the same problem.
And some of the iMX6-derivates have some additional problems.