Re: omap4-droid4: voice call support was Re: [PATCHv5, 5/5] ARM: dts: omap4-droid4: add soundcard

[Pavel Machek <pavel@ucw.cz>]

[-- Attachment #1.1: Type: text/plain, Size: 3817 bytes --]

Hi!

> > > My understanding is, that we only need to replace the audio-graph-card
> > > driver to something more complex. The VOICE DAI needs to be configured
> > > differently based on the use case:
> > > 
> > > call:
> > > 	* mode=i2s
> > > 	* freq=26000000
> > > 	* samprate=16000 or samprate=8000
> > 
> > Ok, lets ignore bluetooth for now. There is "normal" mode, and then
> > there's "call" mode, right? Where's "normal" mode configured?
> 
> mcbsp3_port: port {
> 	cpu_dai3: endpoint {
> 		dai-format = "dsp_a";
> 		frame-master = <&cpcap_audio_codec1>;
> 		bitclock-master = <&cpcap_audio_codec1>;
> 		remote-endpoint = <&cpcap_audio_codec1>;
> 	};
> };

Hmm. Can't tell mode and freq here easily. Does it default to i2s /
26000000?

> > Could we simply always configure the VOICE DAI in the call mode? Yes,
> > it would limit samplerates to 8 or 16k, but .. that's not too
> > important limitation for voice codec...?
> 
> I think we could configure "normal" mode to use the same settings
> as call mode. But ASoC will disable CPCAP, since there will be no
> active user without ASoC knowing about the modem.

Ok, but then we can just start playback/recording with the call, and
everything should work, no?

But Motorola code seems to do different magic according to modem type,
so things may not be as easy.

                if (pdata->voice_type == VOICE_TYPE_STE) {
                        /* STE_M570 */
                        ret = cpcap_audio_reg_write(codec, 2, 0xAE06);
                        if (rate == 16000)
				ret |= cpcap_audio_reg_write(codec, 1, 0x8720);
                        else
                                ret |= cpcap_audio_reg_write(codec, 1, 0x8120);
                } else if (pdata->voice_type == VOICE_TYPE_QC) {
                        /* MDM6600 */
                        ret = cpcap_audio_reg_write(codec, 2, 0xAE02);
                        if (rate == 16000) {
                                ret |= cpcap_audio_reg_write(codec, 1, 0x6720);
                        } else {
                                ret |= cpcap_audio_reg_write(codec, 1, 0x6120);
                        }


> > > "audio-graph-card" is not capable of doing this. I was planning to
> > > try "audio-graph-scu-card" in combination with adding codecs for the
> > > modem and BT to DT. If that does not work we need a Droid 4 specific
> > > soundcard driver.
> > > 
> > > Either way "audio-graph-card" is not the correct driver for D4. I
> > > added it nevertheless, since it gets audio working for now and there
> > > is no risk of DT breakage. Old *.dtb will continue to work with the
> > > "audio-graph-card" even after we switch to something else.
> > 
> > Well, you'll still cause regressions when you change the dts, as
> > people will have wrong .config for new dts.
> 
> That's correct, the .config needs to change. I think that's
> ok, because the only alternative is having no audio support
> at all until the soundcard driver is ready. This means, that
> you also need to change .config once its ready (in case you
> want to use it).

Ok, another problem seems to be that spaces in audio device name seem
to confuse the userland.

Aha, here:

user@devuan:~$ cat /proc/asound/cards
 0 [H58006000encode]: HDMI_58006000_e - HDMI 58006000.encoder
                       HDMI 58006000.encoder
 1 [Audio          ]: Droid_4_Audio - Droid 4 Audio
                       Droid 4 Audio
		       
See how the card is refered simply as "Audio"? Same thing then happens
in alsa "state" file:

state.Audio {
        control.1 {

.

Best regards,

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]