[alsa-devel] How to select input from muxer in front of SSI on i.MX6
Hi,
I am now working on making my audio path working completely. And I get some difficulties to write a DT for my needs. I join a picture which is not the reality but a simplified version of the board.
I have a FPGA between my codecs and my i.MX6. This FPGA is responsible of lots of things, and in particular of muxing signals. I can program it in order to get the audio signal I want on the SSI I want (so sgtl5000 can ben on SSI1 or SSI2 or both). This path is not a single codec, but a multiple codec one. So I can have on SSI1 LineIn from sgtl5000 or audio from hdmi (adv7611).
I don't know how to write it in DT, regarding audmux for instance, and the sound{} node... And I don't know how to drive all these peripherals (from arecord, I wish I have hw:0,0 is LineIn, hw:0;1 is HDMI, etc.).
Any help would be appreciated :). Thanks, JM
CCed Mark and Liam.
On Fri, Sep 19, 2014 at 05:18:08PM +0200, Jean-Michel Hautbois wrote:
Hi,
I am now working on making my audio path working completely. And I get some difficulties to write a DT for my needs. I join a picture which is not the reality but a simplified version of the board.
I have a FPGA between my codecs and my i.MX6. This FPGA is responsible of lots of things, and in particular of muxing signals. I can program it in order to get the audio signal I want on the SSI I want (so sgtl5000 can ben on SSI1 or SSI2 or both). This path is not a single codec, but a multiple codec one. So I can have on SSI1 LineIn from sgtl5000 or audio from hdmi (adv7611).
I don't know how to write it in DT, regarding audmux for instance, and the sound{} node... And I don't know how to drive all these peripherals (from arecord, I wish I have hw:0,0 is LineIn, hw:0;1 is HDMI, etc.).
This looks like a DPCM (Documentation/sound/alsa/soc/DPCM.txt) to me.
I'm not sure how to write a DT for DPCM either. But it seems that you might need a specific machine driver (guessing).
I saw Morimoto-san plans to add DPCM into Simple Card, but not sure when they will finish it. Otherwise, you may use Simple Card while following their defined DT formats.
Nicolin
Hi,
2014-09-19 19:52 GMT+02:00 Nicolin Chen nicoleotsuka@gmail.com:
CCed Mark and Liam.
On Fri, Sep 19, 2014 at 05:18:08PM +0200, Jean-Michel Hautbois wrote:
Hi,
I am now working on making my audio path working completely. And I get some difficulties to write a DT for my needs. I join a picture which is not the reality but a simplified version of the board.
I have a FPGA between my codecs and my i.MX6. This FPGA is responsible of lots of things, and in particular of muxing signals. I can program it in order to get the audio signal I want on the SSI I want (so sgtl5000 can ben on SSI1 or SSI2 or both). This path is not a single codec, but a multiple codec one. So I can have on SSI1 LineIn from sgtl5000 or audio from hdmi (adv7611).
I don't know how to write it in DT, regarding audmux for instance, and the sound{} node... And I don't know how to drive all these peripherals (from arecord, I wish I have hw:0,0 is LineIn, hw:0;1 is HDMI, etc.).
This looks like a DPCM (Documentation/sound/alsa/soc/DPCM.txt) to me.
I'm not sure how to write a DT for DPCM either. But it seems that you might need a specific machine driver (guessing).
I saw Morimoto-san plans to add DPCM into Simple Card, but not sure when they will finish it. Otherwise, you may use Simple Card while following their defined DT formats.
Thanks, that's interesting. It looks like a DPCM, but in the other order (from FE to BE). I probably need a new driver, you are right. But I still don't know how/what I should declare in the DT...
Thanks, JM
On Fri, Sep 19, 2014 at 10:52:06AM -0700, Nicolin Chen wrote:
This looks like a DPCM (Documentation/sound/alsa/soc/DPCM.txt) to me.
I'm not sure how to write a DT for DPCM either. But it seems that you might need a specific machine driver (guessing).
I saw Morimoto-san plans to add DPCM into Simple Card, but not sure when they will finish it. Otherwise, you may use Simple Card while following their defined DT formats.
Depending on what the system looks like it's not at all clear that there should be any visibility at all of DPCM in the DT - it's a detail of how Linux is implemented at the end of the day.
Le 23 sept. 2014 03:51, "Mark Brown" broonie@kernel.org a écrit :
On Fri, Sep 19, 2014 at 10:52:06AM -0700, Nicolin Chen wrote:
This looks like a DPCM (Documentation/sound/alsa/soc/DPCM.txt) to me.
I'm not sure how to write a DT for DPCM either. But it seems that you might need a specific machine driver (guessing).
I saw Morimoto-san plans to add DPCM into Simple Card, but not sure when they will finish it. Otherwise, you may use Simple Card while following their defined DT formats.
Depending on what the system looks like it's not at all clear that there should be any visibility at all of DPCM in the DT - it's a detail of how Linux is implemented at the end of the day.
So this should definitely be implemented directly in a specific driver for my FPGA which is a DPCM right ?
Thanks, JM
On Tue, Sep 23, 2014 at 08:11:27AM +0200, Jean-Michel Hautbois wrote:
Le 23 sept. 2014 03:51, "Mark Brown" broonie@kernel.org a écrit :
Depending on what the system looks like it's not at all clear that there should be any visibility at all of DPCM in the DT - it's a detail of how Linux is implemented at the end of the day.
So this should definitely be implemented directly in a specific driver for my FPGA which is a DPCM right ?
No, that's really not what DPCM is all about... if this is a physically separate device that's not got direct memory access it's probably more appropriate to represent as a CODEC. I was CCed in part way so don't entirely know.
Hi Mark,
2014-09-24 10:21 GMT+02:00 Mark Brown broonie@kernel.org:
On Tue, Sep 23, 2014 at 08:11:27AM +0200, Jean-Michel Hautbois wrote:
Le 23 sept. 2014 03:51, "Mark Brown" broonie@kernel.org a écrit :
Depending on what the system looks like it's not at all clear that there should be any visibility at all of DPCM in the DT - it's a detail of how Linux is implemented at the end of the day.
So this should definitely be implemented directly in a specific driver for my FPGA which is a DPCM right ?
No, that's really not what DPCM is all about... if this is a physically separate device that's not got direct memory access it's probably more appropriate to represent as a CODEC. I was CCed in part way so don't entirely know.
OK, sorry for my late answer, but I was on a lot of things at the same time :/. Well, here is a tentative to explain what I want to do : http://paste.kde.org/pwijzty2p The objective is to develop the "Mux I²S" part, as this is in fact a FPGA with I²C registers which tell which input should go on which output.
I am reading Alsa docs, in order to fully understand what should be done, but it seems that this is nothing more than a simple codec with no effect on audio parameters... It should be visible in alsa mixer though, in order to drive the inputs from user space easily.
I hope this is clearer... Thanks ! JM
On Wed, Oct 08, 2014 at 05:24:49PM +0200, Jean-Michel Hautbois wrote:
2014-09-24 10:21 GMT+02:00 Mark Brown broonie@kernel.org:
No, that's really not what DPCM is all about... if this is a physically separate device that's not got direct memory access it's probably more appropriate to represent as a CODEC. I was CCed in part way so don't entirely know.
OK, sorry for my late answer, but I was on a lot of things at the same time :/. Well, here is a tentative to explain what I want to do : http://paste.kde.org/pwijzty2p The objective is to develop the "Mux I²S" part, as this is in fact a FPGA with I²C registers which tell which input should go on which output.
OK, this probably does fit best with DPCM at this point of view as it is such a simple straight through connection. At least it's probably the lowest impedence way of doing things right now, it's not really what we want to do longer term though.
I am reading Alsa docs, in order to fully understand what should be done, but it seems that this is nothing more than a simple codec with no effect on audio parameters... It should be visible in alsa mixer though, in order to drive the inputs from user space easily.
Even a dumb CODEC at least has the effect of limitng the configurations that can be used.
participants (3)
-
Jean-Michel Hautbois -
Mark Brown -
Nicolin Chen