[alsa-devel] dummy codec + simple card combination
Hi,
I'm trying to add audio support for gta04 (for gsm + bt and fm audio). All audio sources are clock masters so basically connection is dummy codecs -> cpu dai (mcbsp ports).
For implementing such thing I can see 2 options: 1. simple card driver which can easily describe cpu dai interface but dummy codec cannot because there are no DT bindings (there was sever attempts to add DT bindings for dummy-codec but AFAIK none was accepted)
This turns it to only solution to create gta04 soundcard which will get from DT cpu dai links and use in card driver dummy codecs directly.
Is my assumption correct? I would like to get some feedback before wasting my time with implementing something which cannot be pushed mainline. Thanks for all suggestions.
BR,
marek
Hi,
I posted same question on alsa-devel ML this week but I forgot to add sound omap + asoc maintainers (sorry about that)
I'm trying to add audio support for gta04 (for gsm + bt and fm audio). All audio sources are clock masters so basically connection is dummy codecs -> cpu dai (mcbsp ports).
For implementing such thing I can see 2 options: 1. simple card driver which can easily describe cpu dai interface but dummy codec cannot because there are no DT bindings (there was sever attempts to add DT bindings for dummy-codec but AFAIK none was accepted)
This turns it to only solution to create gta04 soundcard which will get from DT cpu dai links and use in card driver dummy codecs directly.
Is my assumption correct? I would like to get some feedback before wasting my time with implementing something which cannot be pushed mainline. Thanks for all suggestions.
BR,
marek
-- as simple and primitive as possible ------------------------------------------------- Marek Belisko - OPEN-NANDRA Freelance Developer
Ruska Nova Ves 219 | Presov, 08005 Slovak Republic Tel: +421 915 052 184 skype: marekwhite twitter: #opennandra web: http://open-nandra.com
Hi,
On 03/12/2015 08:33 PM, Belisko Marek wrote:
Hi,
I posted same question on alsa-devel ML this week but I forgot to add sound omap + asoc maintainers (sorry about that)
I'm trying to add audio support for gta04 (for gsm + bt and fm audio). All audio sources are clock masters so basically connection is dummy codecs -> cpu dai (mcbsp ports).
The FM seams to be slave device (Si4705/Si4721) on the I2S bus. But in any of the cases (FM, GSM and BT) how do you configure the DAI formats of the 'codecs'? Si47xx has support for I2S, L_JUST and DSP mode for example. What about the sample formats and rates? I think there should be a driver for at least the FM. For BT there is a bt-sco codec driver but w/o DT support.
For implementing such thing I can see 2 options:
- simple card driver which can easily describe cpu dai interface but
dummy codec cannot because there are no DT bindings (there was sever attempts to add DT bindings for dummy-codec but AFAIK none was accepted)
Yes, the dummy-codec is Linux/ASoC concept and should not be described in DT. However I think there should be a way to describing passive DAIs. Slave devices only listening, or masters streaming the data. But, I think even if you have such a device you do have some control, at least to enable/disable them...
This turns it to only solution to create gta04 soundcard which will get from DT cpu dai links and use in card driver dummy codecs directly.
I would look up the driver for the FM and write the codec driver for it, probably the same can be done for the GSM and add bindings for the bt-sco so all of this can work with simple-card. Or write a custom machine driver and get it done ;)
Is my assumption correct? I would like to get some feedback before wasting my time with implementing something which cannot be pushed mainline. Thanks for all suggestions.
BR,
marek
-- as simple and primitive as possible
Marek Belisko - OPEN-NANDRA Freelance Developer
Ruska Nova Ves 219 | Presov, 08005 Slovak Republic Tel: +421 915 052 184 skype: marekwhite twitter: #opennandra web: http://open-nandra.com
Hi,
Am 13.03.2015 um 10:28 schrieb Peter Ujfalusi peter.ujfalusi@ti.com:
Hi,
On 03/12/2015 08:33 PM, Belisko Marek wrote:
Hi,
I posted same question on alsa-devel ML this week but I forgot to add sound omap + asoc maintainers (sorry about that)
I'm trying to add audio support for gta04 (for gsm + bt and fm audio). All audio sources are clock masters so basically connection is dummy codecs -> cpu dai (mcbsp ports).
The FM seams to be slave device (Si4705/Si4721) on the I2S bus. But in any of the cases (FM, GSM and BT) how do you configure the DAI formats of the 'codecs'? Si47xx has support for I2S, L_JUST and DSP mode for example. What about the sample formats and rates?
That was previously (before DT) set up in some board specific paches into the audio systems and partially in the board-file.
I think there should be a driver for at least the FM.
We control it through its i2c interface and a user space tool which can set up the Si4721.
For BT there is a bt-sco codec driver but w/o DT support.
For implementing such thing I can see 2 options:
- simple card driver which can easily describe cpu dai interface but
dummy codec cannot because there are no DT bindings (there was sever attempts to add DT bindings for dummy-codec but AFAIK none was accepted)
Yes, the dummy-codec is Linux/ASoC concept and should not be described in DT. However I think there should be a way to describing passive DAIs. Slave devices only listening, or masters streaming the data. But, I think even if you have such a device you do have some control, at least to enable/disable them...
This turns it to only solution to create gta04 soundcard which will get from DT cpu dai links and use in card driver dummy codecs directly.
I would look up the driver for the FM and write the codec driver for it, probably the same can be done for the GSM and add bindings for the bt-sco so all of this can work with simple-card.
For GSM there is some special logic for tri-stating a DAI because the audio channel is wired to the twl4030 *and* a McBSP. This is for either routing the voice directly to the twl or through the CPU (and some filters, answering machine, sound scrambling etc.). This needs tri-state support of the McBSP DX line.
Or write a custom machine driver and get it done ;)
If you would find time (which is beyond what we can realistically expect) to look into the non-DT 3.12 kernel where everything works, it would be here:
http://git.goldelico.com/?p=gta04-kernel.git;a=tree;f=sound/soc/omap;hb=HEAD
Basically we want to rebuild this using DT and use as much standard pieces as possible. So that we only need to upstream what is missing for full gta04 support.
Is my assumption correct? I would like to get some feedback before wasting my time with implementing something which cannot be pushed mainline. Thanks for all suggestions.
BR,
marek
-- as simple and primitive as possible
Marek Belisko - OPEN-NANDRA Freelance Developer
Ruska Nova Ves 219 | Presov, 08005 Slovak Republic Tel: +421 915 052 184 skype: marekwhite twitter: #opennandra web: http://open-nandra.com
-- Péter
BR, Nikolaus
On 03/13/2015 11:54 AM, Dr. H. Nikolaus Schaller wrote:
For GSM there is some special logic for tri-stating a DAI because the audio channel is wired to the twl4030 *and* a McBSP. This is for either routing the voice directly to the twl or through the CPU (and some filters, answering machine, sound scrambling etc.). This needs tri-state support of the McBSP DX line.
Or write a custom machine driver and get it done ;)
If you would find time (which is beyond what we can realistically expect) to look into the non-DT 3.12 kernel where everything works, it would be here:
http://git.goldelico.com/?p=gta04-kernel.git;a=tree;f=sound/soc/omap;hb=HEAD
Basically we want to rebuild this using DT and use as much standard pieces as possible. So that we only need to upstream what is missing for full gta04 support.
I see. You have had written dummy codecs for the GSM, BT, the FM had an actual working driver.
Hrm. There is one thing which would make sense for these audio devices: Since you do not have control over them in terms of formats, rates and protocol - they use fixed interfaces.
I think it would make sense to have binding for something like: compatible = "fixed-codec" or something like that, implying that it's configuration can not be changed. In it's bindings you would have the supported properties of the interface, like rate, channels, sample width, protocol on the bus (I2S, DSP, etc) and to indicate if it is bus master or slave.
You could use this 'fixed-codec' to describe the DAIs and use simple-card to connect them with the CPU.
I think this will fill in some gaps and it is actually going to describe the HW you have as well, so it is not Linux specific.
Is my assumption correct? I would like to get some feedback before wasting my time with implementing something which cannot be pushed mainline. Thanks for all suggestions.
BR,
marek
-- as simple and primitive as possible
Marek Belisko - OPEN-NANDRA Freelance Developer
Ruska Nova Ves 219 | Presov, 08005 Slovak Republic Tel: +421 915 052 184 skype: marekwhite twitter: #opennandra web: http://open-nandra.com
-- Péter
BR, Nikolaus
On Tue, Mar 17, 2015 at 3:07 PM, Peter Ujfalusi peter.ujfalusi@ti.com wrote:
On 03/13/2015 11:54 AM, Dr. H. Nikolaus Schaller wrote:
For GSM there is some special logic for tri-stating a DAI because the audio channel is wired to the twl4030 *and* a McBSP. This is for either routing the voice directly to the twl or through the CPU (and some filters, answering machine, sound scrambling etc.). This needs tri-state support of the McBSP DX line.
Or write a custom machine driver and get it done ;)
If you would find time (which is beyond what we can realistically expect) to look into the non-DT 3.12 kernel where everything works, it would be here:
http://git.goldelico.com/?p=gta04-kernel.git;a=tree;f=sound/soc/omap;hb=HEAD
Basically we want to rebuild this using DT and use as much standard pieces as possible. So that we only need to upstream what is missing for full gta04 support.
I see. You have had written dummy codecs for the GSM, BT, the FM had an actual working driver.
Hrm. There is one thing which would make sense for these audio devices: Since you do not have control over them in terms of formats, rates and protocol - they use fixed interfaces.
I think it would make sense to have binding for something like: compatible = "fixed-codec" or something like that, implying that it's configuration can not be changed.
fixed-codec sounds good.
In it's bindings you would have the supported properties of the interface, like rate, channels, sample width, protocol on the bus (I2S, DSP, etc) and to indicate if it is bus master or slave.
Instead of adding many properties to DT and parsing them cannot we just hard code them (rate, channels, width) in fixed-codec driver (similar as is done for dummy-codec in soc-utils). I'm not sure but how to use protocol on the bus and master/slave in codec driver(must be used in glue card driver). This fixed-codec driver could also cover e.g. spdif_receiver and spdif_transmitter codecs which are also only dummy.
You could use this 'fixed-codec' to describe the DAIs and use simple-card to connect them with the CPU.
I think this will fill in some gaps and it is actually going to describe the HW you have as well, so it is not Linux specific.
BR,
marek
Is my assumption correct? I would like to get some feedback before wasting my time with implementing something which cannot be pushed mainline. Thanks for all suggestions.
BR,
marek
-- as simple and primitive as possible
Marek Belisko - OPEN-NANDRA Freelance Developer
Ruska Nova Ves 219 | Presov, 08005 Slovak Republic Tel: +421 915 052 184 skype: marekwhite twitter: #opennandra web: http://open-nandra.com
-- Péter
BR, Nikolaus
-- Péter
On Wed, 1 Apr 2015 23:08:30 +0200 Belisko Marek marek.belisko@gmail.com wrote:
This fixed-codec driver could also cover e.g. spdif_receiver and spdif_transmitter codecs which are also only dummy.
The S/PDIF CODECs are not really dummy. Their presence indicates that there is a S/PDIF connector and to which audio device it is connected.
BTW, I already proposed a generic DT CODEC, but it was not accepted: http://lists.infradead.org/pipermail/linux-arm-kernel/2013-September/199241....
On Thu, Apr 2, 2015 at 7:11 AM, Jean-Francois Moine moinejf@free.fr wrote:
On Wed, 1 Apr 2015 23:08:30 +0200 Belisko Marek marek.belisko@gmail.com wrote:
This fixed-codec driver could also cover e.g. spdif_receiver and spdif_transmitter codecs which are also only dummy.
The S/PDIF CODECs are not really dummy. Their presence indicates that there is a S/PDIF connector and to which audio device it is connected.
BTW, I already proposed a generic DT CODEC, but it was not accepted: http://lists.infradead.org/pipermail/linux-arm-kernel/2013-September/199241....
Thanks for link. For what kind of device do you wrote simple codec? We would use it for GSM and BT (we could use bt-sco driver) which produce PCM samples (rate is determined by mclk and bclk). If your proposal wasn't accepted then I think the best would be for our purpose to write dummy codecs for both interfaces and not generic simple codec.
-- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/
BR,
marek
On Thu, 2 Apr 2015 22:24:45 +0200 Belisko Marek marek.belisko@gmail.com wrote:
For what kind of device do you wrote simple codec? We would use it for GSM and BT
At this time, I wanted to use DPCM, and a dummy codec was needed. The simple codec could also have been used to replace empty codecs as s/pdif and hdmi.
(we could use bt-sco driver) which produce PCM samples (rate is determined by mclk and bclk). If your proposal wasn't accepted then I think the best would be for our purpose to write dummy codecs for both interfaces and not generic simple codec.
The generic simple codec was just a dummy codec. Which difference do you see?
On Fri, Apr 3, 2015 at 10:45 AM, Jean-Francois Moine moinejf@free.fr wrote:
On Thu, 2 Apr 2015 22:24:45 +0200 Belisko Marek marek.belisko@gmail.com wrote:
For what kind of device do you wrote simple codec? We would use it for GSM and BT
At this time, I wanted to use DPCM, and a dummy codec was needed. The simple codec could also have been used to replace empty codecs as s/pdif and hdmi.
(we could use bt-sco driver) which produce PCM samples (rate is determined by mclk and bclk). If your proposal wasn't accepted then I think the best would be for our purpose to write dummy codecs for both interfaces and not generic simple codec.
The generic simple codec was just a dummy codec. Which difference do you see?
dummy codec cannot be described in DT. There was an attempts to add it but it was rejected. So I see only possibilities: 1: - use dummy codec for gsm path - use bt-sco for bluetoooth path - describe it in DT via simple card
2: create new card machine driver and use dummy codecs for gsm and bt
-- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/
BR,
marek
participants (4)
-
Belisko Marek -
Dr. H. Nikolaus Schaller -
Jean-Francois Moine -
Peter Ujfalusi