Getting ALSA drivers & command line tools operating with SGTL5000 configured like M28EVK

[jeff_poulsen]

Hi!

I am trying to add sound to an existing SBC based on an mx287. I've breadboarded an SGTL5000 onto the system and used the ltib options as described in i.MX28_Linux_BSP_RM. On booting the I get the following,

  sgtl5000-i2c 0-000a: SGTL5000 revision 17

  Registered DAI 'SGTL5000'

  No device for DAI mxs-saif

  Registered DAI 'mxs-saif'

  asoc: SGTL5000 <-> mxs-saif mapping ok

  ALSA device list:

    #0: mxs-evk (SGTL5000)

The command 'cat /proc/asound/cards' yields

0 [mxsevk       ]: SGTL5000 - mxs-evk

                    mxs-evk (SGTL5000)

The devices show as,                   

  crw-rw----    1 root     root     116,  24 Feb 27 16:04 /dev/pcmC0D0c

  crw-rw----    1 root     root     116,  16 Feb 27 16:04 /dev/pcmC0D0p

However the command 'aplay -l' yields,

  aplay: device_list:227: no soundcards found...

Linux version is - 2.6.35.3-571-gcca29a0-svn12552

Does anyone know what might be missing or where I could look next?

Cheers, Jeff.

[gianlucarenzi71]

Hello Jeff!

I am curious about what you define a "small hardware issue".

I am trying to get SGTL5000 working in my board for record (it fail) but when running on the EVK IMX28EVK it runs without any problem... The playback is working good indeed!

The pinmux are correctly set (they are 5 pins anyway), and I see the SAIF0_SDATA0 moving for playing and SAIF1_SDATA0 for recording... but the application side (arecord) fails after 10 seconds... The rootfilesystem and the kernel are the same in EVK and our board. The only thing (software) changed it is the pin muxing for UART and SDIO.... :-(

I am becoming crazy!!

My hardware-collegue is pushing me to find a solution because of the new design using MX6 and SGTL5000... :-(

[jeff_poulsen]

Hi All!

Final problem turned out to be a small hardware issue. When the software looks like it's working it probably is.

The reference manual for the EVK cost me a few hours while I checked out code issues in mxs-devb.c. There are structures in mxs-devb.c that are only used in imx-3stack-sgtl5000.c.

Cheers, Jeff.

[jeff_poulsen · Accepted solution]

Hi all.

I have had some success over the last few days.

It occurred to me that I could take a look through the file system for the EVK to see what might be different in the implementation. This was fruitful. The EVK uses UDEV for driver module rules, I have been using MDEV for the last 2 years on this project. UDEV as configured in the SDK has the required rules to finish the registration of the drivers with the ALSA command-line utilities. This is the answer to the forum question as I have raised it. I now have ALSA command line utilities working and accessing the drivers. Unfortunately this is not the end of the story. I can now see on the oscilloscope the data arriving at the SGTL500. I have tried several tests without any output other that the occasional switching thump in the headphones or line out. I have tied a Texas Ins chip with SAIF inputs across the SGTL500 and it is working well, producing the sounds correctly. I am assuming that the drivers are not setting all the registers correctly in the SGTL5000. I suspect it is a DAPM issue and the internal connections between the DAC and the headphone and line-out is not completed. I have a few options from here. One is the brute force method of capturing all the I2C traffic to the chip and seeing what registers are being set. Another is to follow through with the 2.5.35-1.1.0 revision and look for variations in the drivers. However, if my remaining problem(s) is fixed with the later release, it would suggest that the initial release of the EVK did not have the sound chip working. That doesn't seem right to me.

One issue that is curious; in the EVK reference manual in chapter 12, i.MX28_BSP_RM.pdf, relates that the source file imx-3stack-sgtl5000.c is part of the driver set. Also the manual shows a second PLAYBACK device in response to aplay -l, called imx3stack. Checking the Kconfig  dependencies with ltib, imx-3stack-sgtl5000.c is not available and in modules.builtin, for the EVK, it does not appear as a .ko. I can only assume for the moment that this is in error in the reference manual and relates to another EVK. I will in any case have a closer look at the code to see what services it was providing for possible clues.

Also, I noted that the EVK has the sound modules compiled into the kernel, not as separate modules.

Cheers, Jeff.

[jeff_poulsen]

Hi All!

Found the following online and thought it had a chance.

Check that the ALSA drivers are compiled as modules

Make sure you have installed ALSA as modules, and not compiled into the kernel. ALSA fails for all sorts of reasons when compiled into the kernel (this may no longer be true for kernels after v2.6.5*). Anything that mentions sound in the kernel config, even if it is not directly to do with ALSA, set its option to M if you can. If you compile your own kernel: when you configure the kernel, make sure you see M (for module) and not * (compiled into the kernel).

• Kernel v2.6.22.9 still doesn't like ALSA compiled into it, modules work.

So, I put the drivers in as modules in ltib and rebuilt. The following is the result.

root@eecm1 /$ modprobe snd-soc-mxs-devb

sgtl5000-i2c 0-000a: SGTL5000 revision 17

Registered DAI 'SGTL5000'

No device for DAI mxs-saif

Registered DAI 'mxs-saif'

asoc: SGTL5000 <-> mxs-saif mapping ok

root@eecm1 /$ aplay -l

aplay: device_list:227: no soundcards found...

root@eecm1 /$ cat /proc/asound/cards

0 [mxsevk         ]: SGTL5000 - mxs-evk

                      mxs-evk (SGTL5000)

This basically what I have with the drivers built into the kernel. So no improvement yet. I might be giving modprobe the wrong parameter. I'll keep checking.

Cheers, Jeff.

[MarekVasut]

I would suggest you to use mainline Linux on i.MX28 , 2.6.35 is ancient.