• 0
Namio

Can I get Linux support for the SSM2603?

Question

Hello,

 

I am having trouble outputting sound on Linux using SSM2603.

The SSM2603 device driver loads normally.

It is also registered in ALSA sound card list.

 

However, "input / output error" is raised in "alsactl init". ("amixer" is also the same.)

It plays when I play wave file with "aplay" but it does not output to "R/LOUT pin" of SSM2603.

 

Regards,

Namio

 

 

1712796181_1.png.47e978a1fb2e94c6ff0499d1a2ea0351.png

Share this post


Link to post
Share on other sites

12 answers to this question

Recommended Posts

  • 1

Hi, @sbobrowicz,

Thank you for your reply.

 

I found the cause of the problem and solved it.

The ssm2603 driver was the cause.

 

I found the link below with Google search.

https://www.spinics.net/lists/alsa-devel/msg75416.html

image.png.74b71f87f79e8202b71e93dc74b1874f.png

 

If you have a problem like me, try applying the patch above.

(I am using Petalinux 2017.2 and Zybo-Z7-10. Linux version 4.9.0-xilinx)

 

Thanks,

Namio

 

Edited by Namio

Share this post


Link to post
Share on other sites
  • 0

Hi, @JColvin,

Thank you for your reply.

The link you provided has already been reviewed.

But let's take a closer look.

 

Please let me know if you find something else.

Thanks,

Namio

 

Edited by Namio

Share this post


Link to post
Share on other sites
  • 0

@Namio

I'm afraid the Zybo Z7-10 Petalinux Project doesn't include working audio support. It may be added in a future release.

I included drivers in the kernel config and device tree that worked with the SSM2603 in an earlier version of the kernel, but I ran into the same error you are reporting this time around. I left the drivers in and documented the broken audio as a known issue so that the it could be more easily debugged and resolved in a later release. Unfortunately, I'm expecting this issue to require a "deep dive" into the audio drivers, and I don't have time to address it immediately :(

I could help bounce some ideas around for debugging if you are interested in taking a crack at it.

A bare-metal example of using the SSM2603 is available here: https://reference.digilentinc.com/learn/programmable-logic/tutorials/zybo-z7-dma-audio-demo/start

Share this post


Link to post
Share on other sites
  • 0
On 6/9/2018 at 6:59 AM, sbobrowicz said:

I could help bounce some ideas around for debugging if you are interested in taking a crack at it.

The above mentioned patch fixes it up and it all seems to run ok.

 

 

Share this post


Link to post
Share on other sites
  • 0

Hi Guys,

 

Ok, I spoke too soon!

There is a bit of a problem where the Zybo audio device doesn't recover from an underrun, after recovery the play buffer is never drained and it hangs when full on write to the device.

I have checked that the issue is not a general alsa issue by setting up a gadget usb audio device to send over USB, this doesn't have the same issue.

Has anyone got any ideas of where to start looking?

Many thanks

Andy

Share this post


Link to post
Share on other sites
  • 0

Hi @AndyCap,

Unfortunately I don't have the time to look in to this but judging by what you said

Quote

I have checked that the issue is not a general alsa issue by setting up a gadget usb audio device to send over USB, this doesn't have the same issue. 

I would look in to the IP driver of the audio system <kernel>/sound/soc/adi/axi-i2s.c (as far as I remember), how the buffers are handled in regards to the DMA transfer. The issue might be that full and the empty flags are nor properly handled in the driver or in the HDL IP.

Sorry for not being able to help more.

-Ciprian

Share this post


Link to post
Share on other sites
  • 0

Hi @Ciprian,

 

I have had a poke around in the debugger and the issue is probably related to the DMA as you say.

 

I found that placing a breakpoint at:

static int pl330_terminate_all(struct dma_chan *chan)

"cured" the issue when the debugger was continued.

 

So I looked for updates to this function and there was a patch for the pl330 lock code, unfortunately this doesn't fix the problem.

Adding a 1000us delay before the lock in the code also "cures" the problem and everything then works for the under-run recovery.

I tried smaller delays but 1000us is needed to make things work, this is obviously not a solution to the issue and wondered if you may have any more pointers or ideas why this delay fixes the issue?

 

Cheers


Andy

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now