mcasp: stream has more channels (2) than are enabled in mcasp (0)

mcasp: stream has more channels (2) than are enabled in mcasp (0)

[Rick Mann]

I've got a Beaglebone Green with a custom cape (CODEC and amp and some other stuff).

Kernel 4.4.6-bone-rt-r6. When I load the overlay that should set up my CODEC in the device tree, I get the following in the log.

[  367.172337] davinci-mcasp 48038000.mcasp: stream has more channels (2) than are enabled in mcasp (0)
[  367.172374] davinci-mcasp 48038000.mcasp: ASoC: can't set 48038000.mcasp hw params: -22

You can see a little more log context, along with the DTS, here:

	http://pastebin.com/UPB1xjPF

Can anyone tell me what this means? Thanks!

-- 
Rick Mann
rmann@latencyzero.com

Re: mcasp: stream has more channels (2) than are enabled in mcasp (0)

[Peter Ujfalusi]

On 04/04/2016 11:59 AM, Rick Mann wrote:
> I've got a Beaglebone Green with a custom cape (CODEC and amp and some
> other stuff).
> 
> Kernel 4.4.6-bone-rt-r6. When I load the overlay that should set up my
> CODEC in the device tree, I get the following in the log.
> 
> [  367.172337] davinci-mcasp 48038000.mcasp: stream has more channels (2)
> than are enabled in mcasp (0) [  367.172374] davinci-mcasp 48038000.mcasp:
> ASoC: can't set 48038000.mcasp hw params: -22
> 
> You can see a little more log context, along with the DTS, here:
> 
> http://pastebin.com/UPB1xjPF
> 
> Can anyone tell me what this means? Thanks!

The fragment mostly looks OK, but am335x have 4 serializers, not 16 and the
num-serializer is deprecated at least in upstream kernel.

Something goes wrong when the McASP is loaded for sure, some parameters did
not got updated via DT perhaps, or most likely the DT fragment is loaded after
the McASP is loaded.
Can you print out:
slots, max_active_serializers, active_serializers and channels in
mcasp_common_hw_param() function?
Also just in case, can you put a dev_err() print in davinci_mcasp_probe() to
see when the driver is loaded compared to the time when the fragment is loaded?

If McASP is built in, try to build it as module and load the audio modules
after the DT fragments are handled.

-- 
Péter

Re: mcasp: stream has more channels (2) than are enabled in mcasp (0)

[Rick Mann]

> On Apr 18, 2016, at 08:36 , Peter Ujfalusi <peter.ujfalusi@ti.com> wrote:
> 
> On 04/04/2016 11:59 AM, Rick Mann wrote:
>> I've got a Beaglebone Green with a custom cape (CODEC and amp and some
>> other stuff).
>> 
>> Kernel 4.4.6-bone-rt-r6. When I load the overlay that should set up my
>> CODEC in the device tree, I get the following in the log.
>> 
>> [  367.172337] davinci-mcasp 48038000.mcasp: stream has more channels (2)
>> than are enabled in mcasp (0) [  367.172374] davinci-mcasp 48038000.mcasp:
>> ASoC: can't set 48038000.mcasp hw params: -22
>> 
>> You can see a little more log context, along with the DTS, here:
>> 
>> http://pastebin.com/UPB1xjPF
>> 
>> Can anyone tell me what this means? Thanks!
> 
> The fragment mostly looks OK, but am335x have 4 serializers, not 16 and the
> num-serializer is deprecated at least in upstream kernel.
> 
> Something goes wrong when the McASP is loaded for sure, some parameters did
> not got updated via DT perhaps, or most likely the DT fragment is loaded after
> the McASP is loaded.
> Can you print out:
> slots, max_active_serializers, active_serializers and channels in
> mcasp_common_hw_param() function?
> Also just in case, can you put a dev_err() print in davinci_mcasp_probe() to
> see when the driver is loaded compared to the time when the fragment is loaded?
> 
> If McASP is built in, try to build it as module and load the audio modules
> after the DT fragments are handled.

Thanks for the suggestions, Peter, I really appreciate the help. Here's what I get:

[  256.743991] davinci-mcasp 48038000.mcasp: Slots: 2, max_active_serializers: 1, active_serializers: 0, channels: 2

I rebuilt the 4.4.7-bone-rt-r9 kernel using Robert C Nelson's bb-kernel repo scripts. I modified sound/soc/davinci/davinci-mcasp.c to print some diagnostics. Rebooted, then executed the following. Note that BB-BONE-AUDI-02.dts is <https://github.com/RobertCNelson/bb.org-overlays/blob/master/src/arm/BB-BONE-AUDI-02-00A0.dts>, and the base DTB is <http://pastebin.com/5vVEdAKt>:

$ sudo su
# echo BB-BONE-AUDI-02 > $SLOTS
# aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: B [AudioCape Rev B], device 0: davinci-mcasp.0-tlv320aic3x-hifi tlv320aic3x-hifi-0 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
# speaker-test 

speaker-test 1.0.28

Playback device is default
Stream parameters are 48000Hz, S16_LE, 1 channels
Using 16 octaves of pink noise
Rate set to 48000Hz (requested 48000Hz)
Buffer size range from 16 to 32768
Period size range from 8 to 16384
Using max buffer size 32768
Periods = 4
Unable to set hw params for playback: Invalid argument
Setting of hwparams failed: Invalid argument

speaker-test caused the following to be logged:

[  256.743991] davinci-mcasp 48038000.mcasp: Slots: 2, max_active_serializers: 1, active_serializers: 0, channels: 2
[  256.754343] davinci-mcasp 48038000.mcasp: ASoC: can't set 48038000.mcasp hw params: -22


Full logs:

	http://pastebin.com/HGhu9CPk




-- 
Rick Mann
rmann@latencyzero.com

Re: mcasp: stream has more channels (2) than are enabled in mcasp (0)

[Rick Mann]

I forgot to add: I also added the dev_err() call to output "davinci_mcasp_probe: enter". This happens twice, you can find it in the full log at the pastebin (http://pastebin.com/HGhu9CPk).

[    8.220175] davinci-mcasp 48038000.mcasp: davinci_mcasp_probe: enter
[    8.268496] davinci-mcasp 48038000.mcasp: invalid tdm slots: 0
[    8.323405] davinci-mcasp 4803c000.mcasp: davinci_mcasp_probe: enter
[    8.339936] davinci-mcasp 4803c000.mcasp: invalid tdm slots: 0

> On Apr 18, 2016, at 08:36 , Peter Ujfalusi <peter.ujfalusi@ti.com> wrote:
> 
> Something goes wrong when the McASP is loaded for sure, some parameters did
> not got updated via DT perhaps, or most likely the DT fragment is loaded after
> the McASP is loaded.

The DT fragment that sets up clk_mcasp0 happens early during boot (http://pastebin.com/5vVEdAKt). The fragment that sets up the tlv320aic3104, and the serializer, and the sound card happens when I load the overlay (https://github.com/RobertCNelson/bb.org-overlays/blob/master/src/arm/BB-BONE-AUDI-02-00A0.dts) after logging in. That's at around 33 seconds:

[   33.432680] bone_capemgr bone_capemgr: part_number 'BB-BONE-AUDI-02', version 'N/A'
[   33.432719] bone_capemgr bone_capemgr: slot #4: override
[   33.432736] bone_capemgr bone_capemgr: Using override eeprom data at slot 4
[   33.432752] bone_capemgr bone_capemgr: slot #4: 'Override Board Name,00A0,Override Manuf,BB-BONE-AUDI-02'
[   33.451729] bone_capemgr bone_capemgr: slot #4: dtbo 'BB-BONE-AUDI-02-00A0.dtbo' loaded; overlay id #0
[   33.462646] 2-0018 supply IOVDD not found, using dummy regulator
[   33.462722] 2-0018 supply DVDD not found, using dummy regulator
[   33.462779] 2-0018 supply AVDD not found, using dummy regulator
[   33.462822] 2-0018 supply DRVDD not found, using dummy regulator
[   33.484174] asoc-simple-card sound: tlv320aic3x-hifi <-> 48038000.mcasp mapping ok

> If McASP is built in, try to build it as module and load the audio modules
> after the DT fragments are handled.

I'm not sure how to do this. I do believe it's a module (when I modified the code and rebuilt, it rebuilt snd-soc-davinci-mcasp.ko, and I copied that over. It seems to load by default; not sure how to prevent that. If I move the clk_mcasp0 DT fragment out of the base DTB, things don't work correctly (I'm not sure why, but this is something I was told by Robert Nelson). I don't know if it's that initial fragment that causes the snd-soc-davinci-mcasp  module to load, or something else.

Thanks. Original reply follows:

----------------------------------

> On Apr 18, 2016, at 17:25 , Rick Mann <rmann@latencyzero.com> wrote:
> 
> 
>> On Apr 18, 2016, at 08:36 , Peter Ujfalusi <peter.ujfalusi@ti.com> wrote:
>> 
>> On 04/04/2016 11:59 AM, Rick Mann wrote:
>>> I've got a Beaglebone Green with a custom cape (CODEC and amp and some
>>> other stuff).
>>> 
>>> Kernel 4.4.6-bone-rt-r6. When I load the overlay that should set up my
>>> CODEC in the device tree, I get the following in the log.
>>> 
>>> [  367.172337] davinci-mcasp 48038000.mcasp: stream has more channels (2)
>>> than are enabled in mcasp (0) [  367.172374] davinci-mcasp 48038000.mcasp:
>>> ASoC: can't set 48038000.mcasp hw params: -22
>>> 
>>> You can see a little more log context, along with the DTS, here:
>>> 
>>> http://pastebin.com/UPB1xjPF
>>> 
>>> Can anyone tell me what this means? Thanks!
>> 
>> The fragment mostly looks OK, but am335x have 4 serializers, not 16 and the
>> num-serializer is deprecated at least in upstream kernel.
>> 
>> Something goes wrong when the McASP is loaded for sure, some parameters did
>> not got updated via DT perhaps, or most likely the DT fragment is loaded after
>> the McASP is loaded.
>> Can you print out:
>> slots, max_active_serializers, active_serializers and channels in
>> mcasp_common_hw_param() function?
>> Also just in case, can you put a dev_err() print in davinci_mcasp_probe() to
>> see when the driver is loaded compared to the time when the fragment is loaded?
>> 
>> If McASP is built in, try to build it as module and load the audio modules
>> after the DT fragments are handled.
> 
> Thanks for the suggestions, Peter, I really appreciate the help. Here's what I get:
> 
> [  256.743991] davinci-mcasp 48038000.mcasp: Slots: 2, max_active_serializers: 1, active_serializers: 0, channels: 2
> 
> I rebuilt the 4.4.7-bone-rt-r9 kernel using Robert C Nelson's bb-kernel repo scripts. I modified sound/soc/davinci/davinci-mcasp.c to print some diagnostics. Rebooted, then executed the following. Note that BB-BONE-AUDI-02.dts is <https://github.com/RobertCNelson/bb.org-overlays/blob/master/src/arm/BB-BONE-AUDI-02-00A0.dts>, and the base DTB is <http://pastebin.com/5vVEdAKt>:
> 
> $ sudo su
> # echo BB-BONE-AUDI-02 > $SLOTS
> # aplay -l
> **** List of PLAYBACK Hardware Devices ****
> card 0: B [AudioCape Rev B], device 0: davinci-mcasp.0-tlv320aic3x-hifi tlv320aic3x-hifi-0 []
>  Subdevices: 1/1
>  Subdevice #0: subdevice #0
> # speaker-test 
> 
> speaker-test 1.0.28
> 
> Playback device is default
> Stream parameters are 48000Hz, S16_LE, 1 channels
> Using 16 octaves of pink noise
> Rate set to 48000Hz (requested 48000Hz)
> Buffer size range from 16 to 32768
> Period size range from 8 to 16384
> Using max buffer size 32768
> Periods = 4
> Unable to set hw params for playback: Invalid argument
> Setting of hwparams failed: Invalid argument
> 
> speaker-test caused the following to be logged:
> 
> [  256.743991] davinci-mcasp 48038000.mcasp: Slots: 2, max_active_serializers: 1, active_serializers: 0, channels: 2
> [  256.754343] davinci-mcasp 48038000.mcasp: ASoC: can't set 48038000.mcasp hw params: -22
> 
> 
> Full logs:
> 
> 	http://pastebin.com/HGhu9CPk
> 
> 
> 
> 
> -- 
> Rick Mann
> rmann@latencyzero.com
> 
> 
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel


-- 
Rick Mann
rmann@latencyzero.com

Re: mcasp: stream has more channels (2) than are enabled in mcasp (0)

[Peter Ujfalusi]

On 04/19/16 03:25, Rick Mann wrote:
> Thanks for the suggestions, Peter, I really appreciate the help. Here's
> what I get:
> 
> [  256.743991] davinci-mcasp 48038000.mcasp: Slots: 2,
> max_active_serializers: 1, active_serializers: 0, channels: 2
> 
> I rebuilt the 4.4.7-bone-rt-r9 kernel using Robert C Nelson's bb-kernel
> repo scripts. I modified sound/soc/davinci/davinci-mcasp.c to print some
> diagnostics. Rebooted, then executed the following. Note that
> BB-BONE-AUDI-02.dts is
> <https://github.com/RobertCNelson/bb.org-overlays/blob/master/src/arm/BB-BONE-AUDI-02-00A0.dts>,
> and the base DTB is <http://pastebin.com/5vVEdAKt>:

Looks OK.

FWIW: I have the following patch on top of linux-next to get the BBW's
AudioCape RevA working:
https://github.com/omap-audio/linux-audio/commit/37d2421c321762360a6982b37107b617b0f74bee

> $ sudo su # echo BB-BONE-AUDI-02 > $SLOTS # aplay -l **** List of PLAYBACK
> Hardware Devices **** card 0: B [AudioCape Rev B], device 0:
> davinci-mcasp.0-tlv320aic3x-hifi tlv320aic3x-hifi-0 [] Subdevices: 1/1 
> Subdevice #0: subdevice #0 # speaker-test
> 
> speaker-test 1.0.28
> 
> Playback device is default Stream parameters are 48000Hz, S16_LE, 1
> channels Using 16 octaves of pink noise Rate set to 48000Hz (requested
> 48000Hz) Buffer size range from 16 to 32768 Period size range from 8 to
> 16384 Using max buffer size 32768 Periods = 4 Unable to set hw params for
> playback: Invalid argument Setting of hwparams failed: Invalid argument
> 
> speaker-test caused the following to be logged:
> 
> [  256.743991] davinci-mcasp 48038000.mcasp: Slots: 2,
> max_active_serializers: 1, active_serializers: 0, channels: 2

Now this is odd... Can you print also the mcasp->num_serializer here? If it is
0, then something really strange is going on.
We set this up in davinci_mcasp_set_pdata_from_of() when reading the
serial-dir array.

> [256.754343] davinci-mcasp 48038000.mcasp: ASoC: can't set 48038000.mcasp hw
> params: -22
> 
> 
> Full logs:
> 
> http://pastebin.com/HGhu9CPk
> 
> 
> 
> 


-- 
Péter

Re: mcasp: stream has more channels (2) than are enabled in mcasp (0)

[Rick Mann]

> On Apr 19, 2016, at 00:00 , Peter Ujfalusi <peter.ujfalusi@ti.com> wrote:
> 
> On 04/19/16 03:25, Rick Mann wrote:
>> Thanks for the suggestions, Peter, I really appreciate the help. Here's
>> what I get:
>> 
>> [  256.743991] davinci-mcasp 48038000.mcasp: Slots: 2,
>> max_active_serializers: 1, active_serializers: 0, channels: 2
>> 
>> I rebuilt the 4.4.7-bone-rt-r9 kernel using Robert C Nelson's bb-kernel
>> repo scripts. I modified sound/soc/davinci/davinci-mcasp.c to print some
>> diagnostics. Rebooted, then executed the following. Note that
>> BB-BONE-AUDI-02.dts is
>> <https://github.com/RobertCNelson/bb.org-overlays/blob/master/src/arm/BB-BONE-AUDI-02-00A0.dts>,
>> and the base DTB is <http://pastebin.com/5vVEdAKt>:
> 
> Looks OK.
> 
> FWIW: I have the following patch on top of linux-next to get the BBW's
> AudioCape RevA working:
> https://github.com/omap-audio/linux-audio/commit/37d2421c321762360a6982b37107b617b0f74bee

Interesting, I'll look at that when I start modifying the DTS again. I see that uses the '3106. My own cape has the '3104 on it, which is why I'm trying to get the AudioCape RevB working (my cape has additional GPIOs controlling regulators and resets that I'll have to accommodate).
> 
>> $ sudo su # echo BB-BONE-AUDI-02 > $SLOTS # aplay -l **** List of PLAYBACK
>> Hardware Devices **** card 0: B [AudioCape Rev B], device 0:
>> davinci-mcasp.0-tlv320aic3x-hifi tlv320aic3x-hifi-0 [] Subdevices: 1/1 
>> Subdevice #0: subdevice #0 # speaker-test
>> 
>> speaker-test 1.0.28
>> 
>> Playback device is default Stream parameters are 48000Hz, S16_LE, 1
>> channels Using 16 octaves of pink noise Rate set to 48000Hz (requested
>> 48000Hz) Buffer size range from 16 to 32768 Period size range from 8 to
>> 16384 Using max buffer size 32768 Periods = 4 Unable to set hw params for
>> playback: Invalid argument Setting of hwparams failed: Invalid argument
>> 
>> speaker-test caused the following to be logged:
>> 
>> [  256.743991] davinci-mcasp 48038000.mcasp: Slots: 2,
>> max_active_serializers: 1, active_serializers: 0, channels: 2
> 
> Now this is odd... Can you print also the mcasp->num_serializer here? If it is
> 0, then something really strange is going on.
> We set this up in davinci_mcasp_set_pdata_from_of() when reading the
> serial-dir array.

Yup, seems like it's 0:

[   67.876673] davinci-mcasp 48038000.mcasp: Slots: 2, max_active_serializers: 1, active_serializers: 0, channels: 2, mcasp->num_serializer: 0
[   67.889362] davinci-mcasp 48038000.mcasp: ASoC: can't set 48038000.mcasp hw params: -22


> 
>> [256.754343] davinci-mcasp 48038000.mcasp: ASoC: can't set 48038000.mcasp hw
>> params: -22
>> 
>> 
>> Full logs:
>> 
>> http://pastebin.com/HGhu9CPk
>> 
>> 
>> 
>> 
> 
> 
> -- 
> Péter


-- 
Rick Mann
rmann@latencyzero.com

Re: mcasp: stream has more channels (2) than are enabled in mcasp (0)

[Peter Ujfalusi]

On 04/19/16 10:18, Rick Mann wrote:
> 
>> On Apr 19, 2016, at 00:00 , Peter Ujfalusi <peter.ujfalusi@ti.com>
>> wrote:
>> 
>> On 04/19/16 03:25, Rick Mann wrote:
>>> Thanks for the suggestions, Peter, I really appreciate the help.
>>> Here's what I get:
>>> 
>>> [  256.743991] davinci-mcasp 48038000.mcasp: Slots: 2, 
>>> max_active_serializers: 1, active_serializers: 0, channels: 2
>>> 
>>> I rebuilt the 4.4.7-bone-rt-r9 kernel using Robert C Nelson's
>>> bb-kernel repo scripts. I modified sound/soc/davinci/davinci-mcasp.c to
>>> print some diagnostics. Rebooted, then executed the following. Note
>>> that BB-BONE-AUDI-02.dts is 
>>> <https://github.com/RobertCNelson/bb.org-overlays/blob/master/src/arm/BB-BONE-AUDI-02-00A0.dts>,
>>>
>>> 
and the base DTB is <http://pastebin.com/5vVEdAKt>:
>> 
>> Looks OK.
>> 
>> FWIW: I have the following patch on top of linux-next to get the BBW's 
>> AudioCape RevA working: 
>> https://github.com/omap-audio/linux-audio/commit/37d2421c321762360a6982b37107b617b0f74bee
>
>> 
> Interesting, I'll look at that when I start modifying the DTS again. I see
> that uses the '3106. My own cape has the '3104 on it, which is why I'm
> trying to get the AudioCape RevB working (my cape has additional GPIOs
> controlling regulators and resets that I'll have to accommodate).
>> 
>>> $ sudo su # echo BB-BONE-AUDI-02 > $SLOTS # aplay -l **** List of
>>> PLAYBACK Hardware Devices **** card 0: B [AudioCape Rev B], device 0: 
>>> davinci-mcasp.0-tlv320aic3x-hifi tlv320aic3x-hifi-0 [] Subdevices: 1/1
>>>  Subdevice #0: subdevice #0 # speaker-test
>>> 
>>> speaker-test 1.0.28
>>> 
>>> Playback device is default Stream parameters are 48000Hz, S16_LE, 1 
>>> channels Using 16 octaves of pink noise Rate set to 48000Hz (requested 
>>> 48000Hz) Buffer size range from 16 to 32768 Period size range from 8
>>> to 16384 Using max buffer size 32768 Periods = 4 Unable to set hw
>>> params for playback: Invalid argument Setting of hwparams failed:
>>> Invalid argument
>>> 
>>> speaker-test caused the following to be logged:
>>> 
>>> [  256.743991] davinci-mcasp 48038000.mcasp: Slots: 2, 
>>> max_active_serializers: 1, active_serializers: 0, channels: 2
>> 
>> Now this is odd... Can you print also the mcasp->num_serializer here? If
>> it is 0, then something really strange is going on. We set this up in
>> davinci_mcasp_set_pdata_from_of() when reading the serial-dir array.
> 
> Yup, seems like it's 0:
> 
> [   67.876673] davinci-mcasp 48038000.mcasp: Slots: 2,
> max_active_serializers: 1, active_serializers: 0, channels: 2,
> mcasp->num_serializer: 0 [   67.889362] davinci-mcasp 48038000.mcasp: ASoC:
> can't set 48038000.mcasp hw params: -22

How can it be?
can you take a look of the davinci_mcasp_set_pdata_from_of() function where
the serial-dir is set up? Do we get the of_serial_dir32? What is the size of
the array we got (val)?

BTW: can you check your mail client to wrap the lines around 78 characters?

-- 
Péter

Re: mcasp: stream has more channels (2) than are enabled in mcasp (0)

[Rick Mann]

> On Apr 19, 2016, at 00:36 , Peter Ujfalusi <peter.ujfalusi@ti.com> wrote:
> 
> On 04/19/16 10:18, Rick Mann wrote:
>> 
>>> On Apr 19, 2016, at 00:00 , Peter Ujfalusi <peter.ujfalusi@ti.com>
>>> wrote:
>>> 
>>> On 04/19/16 03:25, Rick Mann wrote:
>>>> Thanks for the suggestions, Peter, I really appreciate the help.
>>>> Here's what I get:
>>>> 
>>>> [  256.743991] davinci-mcasp 48038000.mcasp: Slots: 2, 
>>>> max_active_serializers: 1, active_serializers: 0, channels: 2
>>>> 
>>>> I rebuilt the 4.4.7-bone-rt-r9 kernel using Robert C Nelson's
>>>> bb-kernel repo scripts. I modified sound/soc/davinci/davinci-mcasp.c to
>>>> print some diagnostics. Rebooted, then executed the following. Note
>>>> that BB-BONE-AUDI-02.dts is 
>>>> <https://github.com/RobertCNelson/bb.org-overlays/blob/master/src/arm/BB-BONE-AUDI-02-00A0.dts>,
>>>> 
>>>> 
> and the base DTB is <http://pastebin.com/5vVEdAKt>:
>>> 
>>> Looks OK.
>>> 
>>> FWIW: I have the following patch on top of linux-next to get the BBW's 
>>> AudioCape RevA working: 
>>> https://github.com/omap-audio/linux-audio/commit/37d2421c321762360a6982b37107b617b0f74bee
>> 
>>> 
>> Interesting, I'll look at that when I start modifying the DTS again. I see
>> that uses the '3106. My own cape has the '3104 on it, which is why I'm
>> trying to get the AudioCape RevB working (my cape has additional GPIOs
>> controlling regulators and resets that I'll have to accommodate).
>>> 
>>>> $ sudo su # echo BB-BONE-AUDI-02 > $SLOTS # aplay -l **** List of
>>>> PLAYBACK Hardware Devices **** card 0: B [AudioCape Rev B], device 0: 
>>>> davinci-mcasp.0-tlv320aic3x-hifi tlv320aic3x-hifi-0 [] Subdevices: 1/1
>>>> Subdevice #0: subdevice #0 # speaker-test
>>>> 
>>>> speaker-test 1.0.28
>>>> 
>>>> Playback device is default Stream parameters are 48000Hz, S16_LE, 1 
>>>> channels Using 16 octaves of pink noise Rate set to 48000Hz (requested 
>>>> 48000Hz) Buffer size range from 16 to 32768 Period size range from 8
>>>> to 16384 Using max buffer size 32768 Periods = 4 Unable to set hw
>>>> params for playback: Invalid argument Setting of hwparams failed:
>>>> Invalid argument
>>>> 
>>>> speaker-test caused the following to be logged:
>>>> 
>>>> [  256.743991] davinci-mcasp 48038000.mcasp: Slots: 2, 
>>>> max_active_serializers: 1, active_serializers: 0, channels: 2
>>> 
>>> Now this is odd... Can you print also the mcasp->num_serializer here? If
>>> it is 0, then something really strange is going on. We set this up in
>>> davinci_mcasp_set_pdata_from_of() when reading the serial-dir array.
>> 
>> Yup, seems like it's 0:
>> 
>> [   67.876673] davinci-mcasp 48038000.mcasp: Slots: 2,
>> max_active_serializers: 1, active_serializers: 0, channels: 2,
>> mcasp->num_serializer: 0 [   67.889362] davinci-mcasp 48038000.mcasp: ASoC:
>> can't set 48038000.mcasp hw params: -22
> 
> How can it be?
> can you take a look of the davinci_mcasp_set_pdata_from_of() function where
> the serial-dir is set up? Do we get the of_serial_dir32? What is the size of
> the array we got (val)?

It seems to be 0:

[    8.411990] davinci-mcasp 48038000.mcasp: davinci_mcasp_probe: enter
[    8.453167] davinci-mcasp 48038000.mcasp: serial-dir: 0
[    8.501317] davinci-mcasp 48038000.mcasp: invalid tdm slots: 0
[    8.554405] davinci-mcasp 4803c000.mcasp: davinci_mcasp_probe: enter
[    8.562924] davinci-mcasp 4803c000.mcasp: serial-dir: 0
[    8.635250] davinci-mcasp 4803c000.mcasp: invalid tdm slots: 0

> BTW: can you check your mail client to wrap the lines around 78 characters?

I'm sorry, it seems to be an issue with OS X Mail. There are no settings to
control this, despite the fact that I have it set to send "plain-text" email.
I will try to insert hard carriage returns to shorten my typed text.

https://discussions.apple.com/thread/3040166?tstart=0


-- 
Rick Mann
rmann@latencyzero.com

Re: mcasp: stream has more channels (2) than are enabled in mcasp (0)

[Peter Ujfalusi]

On 04/19/16 11:05, Rick Mann wrote:
>>> Yup, seems like it's 0:
>>>
>>> [   67.876673] davinci-mcasp 48038000.mcasp: Slots: 2,
>>> max_active_serializers: 1, active_serializers: 0, channels: 2,
>>> mcasp->num_serializer: 0 [   67.889362] davinci-mcasp 48038000.mcasp: ASoC:
>>> can't set 48038000.mcasp hw params: -22
>>
>> How can it be?
>> can you take a look of the davinci_mcasp_set_pdata_from_of() function where
>> the serial-dir is set up? Do we get the of_serial_dir32? What is the size of
>> the array we got (val)?
> 
> It seems to be 0:
> 
> [    8.411990] davinci-mcasp 48038000.mcasp: davinci_mcasp_probe: enter
> [    8.453167] davinci-mcasp 48038000.mcasp: serial-dir: 0
> [    8.501317] davinci-mcasp 48038000.mcasp: invalid tdm slots: 0
> [    8.554405] davinci-mcasp 4803c000.mcasp: davinci_mcasp_probe: enter
> [    8.562924] davinci-mcasp 4803c000.mcasp: serial-dir: 0
> [    8.635250] davinci-mcasp 4803c000.mcasp: invalid tdm slots: 0

Hrm, it seems that we can not read any of the parameters set by the DT
fragment for mcasp0, my guess is that the tx-num-evt and rx-num-evt is not
there either.

from the full log: the mcasp is loaded earlier than you have patched the DT
with the audio overlay.

[    8.220175] davinci-mcasp 48038000.mcasp: davinci_mcasp_probe: enter
[    8.268496] davinci-mcasp 48038000.mcasp: invalid tdm slots: 0
[    8.323405] davinci-mcasp 4803c000.mcasp: davinci_mcasp_probe: enter
[    8.339936] davinci-mcasp 4803c000.mcasp: invalid tdm slots: 0
...
[   33.432680] bone_capemgr bone_capemgr: part_number 'BB-BONE-AUDI-02',
version 'N/A'
[   33.432719] bone_capemgr bone_capemgr: slot #4: override
[   33.432736] bone_capemgr bone_capemgr: Using override eeprom data at slot 4
[   33.432752] bone_capemgr bone_capemgr: slot #4: 'Override Board
Name,00A0,Override Manuf,BB-BONE-AUDI-02'
[   33.451729] bone_capemgr bone_capemgr: slot #4: dtbo
'BB-BONE-AUDI-02-00A0.dtbo' loaded; overlay id #0
[   33.462646] 2-0018 supply IOVDD not found, using dummy regulator
[   33.462722] 2-0018 supply DVDD not found, using dummy regulator
[   33.462779] 2-0018 supply AVDD not found, using dummy regulator
[   33.462822] 2-0018 supply DRVDD not found, using dummy regulator
[   33.484174] asoc-simple-card sound: tlv320aic3x-hifi <-> 48038000.mcasp
mapping ok
[   50.062097] davinci-mcasp 48038000.mcasp: Slots: 2, max_active_serializers:
1, active_serializers: 0, channels: 2
[   50.072596] davinci-mcasp 48038000.mcasp: stream has more channels (2) than
are enabled in mcasp (0)
[   50.072613] davinci-mcasp 48038000.mcasp: ASoC: can't set 48038000.mcasp hw
params: -22

You can try to remove the mcasp module, do the DT fragment magic, reload the
mcasp driver if it is not loaded automatically.
But if you want to get it working properly you need to find the dts(i) file
which set the mcasp0 and mcasp1 nodes to status = "okay";
In upstream we do not do this, so it must come from the bone changes.

>> BTW: can you check your mail client to wrap the lines around 78 characters?
> 
> I'm sorry, it seems to be an issue with OS X Mail. There are no settings to
> control this, despite the fact that I have it set to send "plain-text" email.
> I will try to insert hard carriage returns to shorten my typed text.
> 
> https://discussions.apple.com/thread/3040166?tstart=0


-- 
Péter

Re: mcasp: stream has more channels (2) than are enabled in mcasp (0)

[Rick Mann]

> On Apr 19, 2016, at 01:37 , Peter Ujfalusi <peter.ujfalusi@ti.com> wrote:
> 
> On 04/19/16 11:05, Rick Mann wrote:
>>>> Yup, seems like it's 0:
>>>> 
>>>> [   67.876673] davinci-mcasp 48038000.mcasp: Slots: 2,
>>>> max_active_serializers: 1, active_serializers: 0, channels: 2,
>>>> mcasp->num_serializer: 0 [   67.889362] davinci-mcasp 48038000.mcasp: ASoC:
>>>> can't set 48038000.mcasp hw params: -22
>>> 
>>> How can it be?
>>> can you take a look of the davinci_mcasp_set_pdata_from_of() function where
>>> the serial-dir is set up? Do we get the of_serial_dir32? What is the size of
>>> the array we got (val)?
>> 
>> It seems to be 0:
>> 
>> [    8.411990] davinci-mcasp 48038000.mcasp: davinci_mcasp_probe: enter
>> [    8.453167] davinci-mcasp 48038000.mcasp: serial-dir: 0
>> [    8.501317] davinci-mcasp 48038000.mcasp: invalid tdm slots: 0
>> [    8.554405] davinci-mcasp 4803c000.mcasp: davinci_mcasp_probe: enter
>> [    8.562924] davinci-mcasp 4803c000.mcasp: serial-dir: 0
>> [    8.635250] davinci-mcasp 4803c000.mcasp: invalid tdm slots: 0
> 
> Hrm, it seems that we can not read any of the parameters set by the DT
> fragment for mcasp0, my guess is that the tx-num-evt and rx-num-evt is not
> there either.
> 
> from the full log: the mcasp is loaded earlier than you have patched the DT
> with the audio overlay.
> 
> [    8.220175] davinci-mcasp 48038000.mcasp: davinci_mcasp_probe: enter
> [    8.268496] davinci-mcasp 48038000.mcasp: invalid tdm slots: 0
> [    8.323405] davinci-mcasp 4803c000.mcasp: davinci_mcasp_probe: enter
> [    8.339936] davinci-mcasp 4803c000.mcasp: invalid tdm slots: 0
> ...
> [   33.432680] bone_capemgr bone_capemgr: part_number 'BB-BONE-AUDI-02',
> version 'N/A'
> [   33.432719] bone_capemgr bone_capemgr: slot #4: override
> [   33.432736] bone_capemgr bone_capemgr: Using override eeprom data at slot 4
> [   33.432752] bone_capemgr bone_capemgr: slot #4: 'Override Board
> Name,00A0,Override Manuf,BB-BONE-AUDI-02'
> [   33.451729] bone_capemgr bone_capemgr: slot #4: dtbo
> 'BB-BONE-AUDI-02-00A0.dtbo' loaded; overlay id #0
> [   33.462646] 2-0018 supply IOVDD not found, using dummy regulator
> [   33.462722] 2-0018 supply DVDD not found, using dummy regulator
> [   33.462779] 2-0018 supply AVDD not found, using dummy regulator
> [   33.462822] 2-0018 supply DRVDD not found, using dummy regulator
> [   33.484174] asoc-simple-card sound: tlv320aic3x-hifi <-> 48038000.mcasp
> mapping ok
> [   50.062097] davinci-mcasp 48038000.mcasp: Slots: 2, max_active_serializers:
> 1, active_serializers: 0, channels: 2
> [   50.072596] davinci-mcasp 48038000.mcasp: stream has more channels (2) than
> are enabled in mcasp (0)
> [   50.072613] davinci-mcasp 48038000.mcasp: ASoC: can't set 48038000.mcasp hw
> params: -22
> 
> You can try to remove the mcasp module, do the DT fragment magic, reload the
> mcasp driver if it is not loaded automatically.

I don't quite understand how to do what you're suggesting here.

> But if you want to get it working properly you need to find the dts(i) file
> which set the mcasp0 and mcasp1 nodes to status = "okay";
> In upstream we do not do this, so it must come from the bone changes.

The DTB (prior to the BB-BONE-AUDI-02 overlay) starts with this file:

	http://pastebin.com/5vVEdAKt

That file first includes the following files in this order, before adding
its own entries (sorry about the line length):

https://github.com/RobertCNelson/dtb-rebuilder/blob/4.4.x/src/arm/am33xx.dtsi
https://github.com/RobertCNelson/dtb-rebuilder/blob/4.4.x/src/arm/am33xx-es2.dtsi
https://github.com/RobertCNelson/dtb-rebuilder/blob/4.4.x/src/arm/am335x-bone-common.dtsi
https://github.com/RobertCNelson/dtb-rebuilder/blob/4.4.x/src/arm/am33xx-overlay-edma-fix.dtsi

The last of these files sets spi0, spi1, mcasp0, mcasp1 to "okay".

If I understand what you're saying, this is causing the driver to load
before other things have been set in the DT, and they should be moved
to later, perhaps in the overlay? In fact, the overlay (which gets loaded
after login) does also set the mcasp0 to "okay" (I think):

https://github.com/RobertCNelson/bb.org-overlays/blob/master/src/arm/BB-BONE-AUDI-02-00A0.dts#L72

I rebuilt the .dtb by commenting out the enabling of the macasp0/1 in
that .dtsi, and now it seems to work! davinci_mcasp_probe is entered
when I apply the overlay, and I get this logged:

[   35.868324] davinci-mcasp 48038000.mcasp: davinci_mcasp_probe: enter
[   35.874741] davinci-mcasp 48038000.mcasp: serial-dir: 64
[   43.469254] davinci-mcasp 48038000.mcasp: Slots: 2,
	max_active_serializers: 1, active_serializers: 1,
	channels: 2, mcasp->num_serializer: 16
[   78.846314] davinci-mcasp 48038000.mcasp: Slots: 2,
	max_active_serializers: 1, active_serializers: 1,
	channels: 2, mcasp->num_serializer: 16

By default, speaker-test only outputs to the left channel, and I get
noise out that channel. If I invoke speaker-test -c 2, it claims to
cycle between Front Left and Front Right, but there is only silence
out the Front Right. This is probably due to issues in asound.state,
right (I'd sure love some help getting that straightened out)?

In any case, thank you. This seems to have advanced things considerably.
I really appreciate your help and your patience.


-- 
Rick Mann
rmann@latencyzero.com

Re: mcasp: stream has more channels (2) than are enabled in mcasp (0)

[Peter Ujfalusi]

On 04/19/16 12:04, Rick Mann wrote:
> 
>> On Apr 19, 2016, at 01:37 , Peter Ujfalusi <peter.ujfalusi@ti.com> wrote:
>>
>> On 04/19/16 11:05, Rick Mann wrote:
>>>>> Yup, seems like it's 0:
>>>>>
>>>>> [   67.876673] davinci-mcasp 48038000.mcasp: Slots: 2,
>>>>> max_active_serializers: 1, active_serializers: 0, channels: 2,
>>>>> mcasp->num_serializer: 0 [   67.889362] davinci-mcasp 48038000.mcasp: ASoC:
>>>>> can't set 48038000.mcasp hw params: -22
>>>>
>>>> How can it be?
>>>> can you take a look of the davinci_mcasp_set_pdata_from_of() function where
>>>> the serial-dir is set up? Do we get the of_serial_dir32? What is the size of
>>>> the array we got (val)?
>>>
>>> It seems to be 0:
>>>
>>> [    8.411990] davinci-mcasp 48038000.mcasp: davinci_mcasp_probe: enter
>>> [    8.453167] davinci-mcasp 48038000.mcasp: serial-dir: 0
>>> [    8.501317] davinci-mcasp 48038000.mcasp: invalid tdm slots: 0
>>> [    8.554405] davinci-mcasp 4803c000.mcasp: davinci_mcasp_probe: enter
>>> [    8.562924] davinci-mcasp 4803c000.mcasp: serial-dir: 0
>>> [    8.635250] davinci-mcasp 4803c000.mcasp: invalid tdm slots: 0
>>
>> Hrm, it seems that we can not read any of the parameters set by the DT
>> fragment for mcasp0, my guess is that the tx-num-evt and rx-num-evt is not
>> there either.
>>
>> from the full log: the mcasp is loaded earlier than you have patched the DT
>> with the audio overlay.
>>
>> [    8.220175] davinci-mcasp 48038000.mcasp: davinci_mcasp_probe: enter
>> [    8.268496] davinci-mcasp 48038000.mcasp: invalid tdm slots: 0
>> [    8.323405] davinci-mcasp 4803c000.mcasp: davinci_mcasp_probe: enter
>> [    8.339936] davinci-mcasp 4803c000.mcasp: invalid tdm slots: 0
>> ...
>> [   33.432680] bone_capemgr bone_capemgr: part_number 'BB-BONE-AUDI-02',
>> version 'N/A'
>> [   33.432719] bone_capemgr bone_capemgr: slot #4: override
>> [   33.432736] bone_capemgr bone_capemgr: Using override eeprom data at slot 4
>> [   33.432752] bone_capemgr bone_capemgr: slot #4: 'Override Board
>> Name,00A0,Override Manuf,BB-BONE-AUDI-02'
>> [   33.451729] bone_capemgr bone_capemgr: slot #4: dtbo
>> 'BB-BONE-AUDI-02-00A0.dtbo' loaded; overlay id #0
>> [   33.462646] 2-0018 supply IOVDD not found, using dummy regulator
>> [   33.462722] 2-0018 supply DVDD not found, using dummy regulator
>> [   33.462779] 2-0018 supply AVDD not found, using dummy regulator
>> [   33.462822] 2-0018 supply DRVDD not found, using dummy regulator
>> [   33.484174] asoc-simple-card sound: tlv320aic3x-hifi <-> 48038000.mcasp
>> mapping ok
>> [   50.062097] davinci-mcasp 48038000.mcasp: Slots: 2, max_active_serializers:
>> 1, active_serializers: 0, channels: 2
>> [   50.072596] davinci-mcasp 48038000.mcasp: stream has more channels (2) than
>> are enabled in mcasp (0)
>> [   50.072613] davinci-mcasp 48038000.mcasp: ASoC: can't set 48038000.mcasp hw
>> params: -22
>>
>> You can try to remove the mcasp module, do the DT fragment magic, reload the
>> mcasp driver if it is not loaded automatically.
> 
> I don't quite understand how to do what you're suggesting here.

rmmod snd-soc-davinci-mcasp
...
DT patching
...
modprobe snd-soc-davinci-mcasp


>> But if you want to get it working properly you need to find the dts(i) file
>> which set the mcasp0 and mcasp1 nodes to status = "okay";
>> In upstream we do not do this, so it must come from the bone changes.
> 
> The DTB (prior to the BB-BONE-AUDI-02 overlay) starts with this file:
> 
> 	http://pastebin.com/5vVEdAKt
> 
> That file first includes the following files in this order, before adding
> its own entries (sorry about the line length):
> 
> https://github.com/RobertCNelson/dtb-rebuilder/blob/4.4.x/src/arm/am33xx.dtsi
> https://github.com/RobertCNelson/dtb-rebuilder/blob/4.4.x/src/arm/am33xx-es2.dtsi
> https://github.com/RobertCNelson/dtb-rebuilder/blob/4.4.x/src/arm/am335x-bone-common.dtsi
> https://github.com/RobertCNelson/dtb-rebuilder/blob/4.4.x/src/arm/am33xx-overlay-edma-fix.dtsi
> 
> The last of these files sets spi0, spi1, mcasp0, mcasp1 to "okay".

Interesting, why an include file called am33xx-overlay-edma-fix.dtsi would
enable spi and mcasp??? What it is fixing regarding to eDMA?

> If I understand what you're saying, this is causing the driver to load
> before other things have been set in the DT, and they should be moved
> to later, perhaps in the overlay? In fact, the overlay (which gets loaded
> after login) does also set the mcasp0 to "okay" (I think):

Yes, since the DT blob you are booting with have mcasp0/1 enabled, the driver
will load using the boot DTB. You later patch the DTB, but the driver is
already loaded so it will have no effect to the driver.

> https://github.com/RobertCNelson/bb.org-overlays/blob/master/src/arm/BB-BONE-AUDI-02-00A0.dts#L72
> 
> I rebuilt the .dtb by commenting out the enabling of the macasp0/1 in
> that .dtsi, and now it seems to work! davinci_mcasp_probe is entered
> when I apply the overlay, and I get this logged:
> 
> [   35.868324] davinci-mcasp 48038000.mcasp: davinci_mcasp_probe: enter
> [   35.874741] davinci-mcasp 48038000.mcasp: serial-dir: 64
> [   43.469254] davinci-mcasp 48038000.mcasp: Slots: 2,
> 	max_active_serializers: 1, active_serializers: 1,
> 	channels: 2, mcasp->num_serializer: 16
> [   78.846314] davinci-mcasp 48038000.mcasp: Slots: 2,
> 	max_active_serializers: 1, active_serializers: 1,
> 	channels: 2, mcasp->num_serializer: 16

Great!

> By default, speaker-test only outputs to the left channel, and I get
> noise out that channel. If I invoke speaker-test -c 2, it claims to
> cycle between Front Left and Front Right, but there is only silence
> out the Front Right. This is probably due to issues in asound.state,
> right (I'd sure love some help getting that straightened out)?

I'll try to take a look at the speaker-test, it should work fine AFAIK.

> In any case, thank you. This seems to have advanced things considerably.
> I really appreciate your help and your patience.

No problem, I'm glad that I we sorted out.

-- 
Péter

Re: mcasp: stream has more channels (2) than are enabled in mcasp (0)

[Rick Mann]

> On Apr 19, 2016, at 02:22 , Peter Ujfalusi <peter.ujfalusi@ti.com> wrote:
> 
> On 04/19/16 12:04, Rick Mann wrote:
>> 
>>> On Apr 19, 2016, at 01:37 , Peter Ujfalusi <peter.ujfalusi@ti.com> wrote:
>>> 
>>> You can try to remove the mcasp module, do the DT fragment magic, reload the
>>> mcasp driver if it is not loaded automatically.
>> 
>> I don't quite understand how to do what you're suggesting here.
> 
> rmmod snd-soc-davinci-mcasp
> ...
> DT patching
> ...
> modprobe snd-soc-davinci-mcasp

Ah, straightforward enough. Thanks.

>>> But if you want to get it working properly you need to find the dts(i) file
>>> which set the mcasp0 and mcasp1 nodes to status = "okay";
>>> In upstream we do not do this, so it must come from the bone changes.
>> 
>> The DTB (prior to the BB-BONE-AUDI-02 overlay) starts with this file:
>> 
>> 	http://pastebin.com/5vVEdAKt
>> 
>> That file first includes the following files in this order, before adding
>> its own entries (sorry about the line length):
>> 
>> https://github.com/RobertCNelson/dtb-rebuilder/blob/4.4.x/src/arm/am33xx.dtsi
>> https://github.com/RobertCNelson/dtb-rebuilder/blob/4.4.x/src/arm/am33xx-es2.dtsi
>> https://github.com/RobertCNelson/dtb-rebuilder/blob/4.4.x/src/arm/am335x-bone-common.dtsi
>> https://github.com/RobertCNelson/dtb-rebuilder/blob/4.4.x/src/arm/am33xx-overlay-edma-fix.dtsi
>> 
>> The last of these files sets spi0, spi1, mcasp0, mcasp1 to "okay".
> 
> Interesting, why an include file called am33xx-overlay-edma-fix.dtsi would
> enable spi and mcasp??? What it is fixing regarding to eDMA?

I wish I knew. I've often wished they'd put a block of text
at the start of each of these files explaining their existence.

> 
>> If I understand what you're saying, this is causing the driver to load
>> before other things have been set in the DT, and they should be moved
>> to later, perhaps in the overlay? In fact, the overlay (which gets loaded
>> after login) does also set the mcasp0 to "okay" (I think):
> 
> Yes, since the DT blob you are booting with have mcasp0/1 enabled, the driver
> will load using the boot DTB. You later patch the DTB, but the driver is
> already loaded so it will have no effect to the driver.

Okay, that makes sense.

Should I be able to make a single, combined DTB that's loaded
at boot, and have it work, not worrying about where in the DTB the mcasp0/1
are enabled? Or do I still want the status="okay" to appear no earlier than
the specific mcasp configuration?

> 
>> https://github.com/RobertCNelson/bb.org-overlays/blob/master/src/arm/BB-BONE-AUDI-02-00A0.dts#L72
>> 
>> I rebuilt the .dtb by commenting out the enabling of the macasp0/1 in
>> that .dtsi, and now it seems to work! davinci_mcasp_probe is entered
>> when I apply the overlay, and I get this logged:
>> 
>> [   35.868324] davinci-mcasp 48038000.mcasp: davinci_mcasp_probe: enter
>> [   35.874741] davinci-mcasp 48038000.mcasp: serial-dir: 64
>> [   43.469254] davinci-mcasp 48038000.mcasp: Slots: 2,
>> 	max_active_serializers: 1, active_serializers: 1,
>> 	channels: 2, mcasp->num_serializer: 16
>> [   78.846314] davinci-mcasp 48038000.mcasp: Slots: 2,
>> 	max_active_serializers: 1, active_serializers: 1,
>> 	channels: 2, mcasp->num_serializer: 16
> 
> Great!

Should I change the DT to use only four serializers? I noticed that
a) your DTS doesn't specify the number of serializers explicitly,
and b) has the active/inactive ones set differently from mine:

https://github.com/RobertCNelson/bb.org-overlays/blob/master/src/arm/BB-BONE-AUDI-02-00A0.dts#L75

> 
>> By default, speaker-test only outputs to the left channel, and I get
>> noise out that channel. If I invoke speaker-test -c 2, it claims to
>> cycle between Front Left and Front Right, but there is only silence
>> out the Front Right. This is probably due to issues in asound.state,
>> right (I'd sure love some help getting that straightened out)?
> 
> I'll try to take a look at the speaker-test, it should work fine AFAIK.

Yeah, I don't think the problem is in speaker-test, per se. I think it's
in the ALSA configuration, or perhaps the routing entries in the DTB?

-- 
Rick Mann
rmann@latencyzero.com

Re: mcasp: stream has more channels (2) than are enabled in mcasp (0)

[Peter Ujfalusi]

On 04/19/16 12:32, Rick Mann wrote:
>> Interesting, why an include file called am33xx-overlay-edma-fix.dtsi would
>> enable spi and mcasp??? What it is fixing regarding to eDMA?
> 
> I wish I knew. I've often wished they'd put a block of text
> at the start of each of these files explaining their existence.

The commit message is not much talkative either :(

>>> If I understand what you're saying, this is causing the driver to load
>>> before other things have been set in the DT, and they should be moved
>>> to later, perhaps in the overlay? In fact, the overlay (which gets loaded
>>> after login) does also set the mcasp0 to "okay" (I think):
>>
>> Yes, since the DT blob you are booting with have mcasp0/1 enabled, the driver
>> will load using the boot DTB. You later patch the DTB, but the driver is
>> already loaded so it will have no effect to the driver.
> 
> Okay, that makes sense.
> 
> Should I be able to make a single, combined DTB that's loaded
> at boot, and have it work, not worrying about where in the DTB the mcasp0/1
> are enabled? Or do I still want the status="okay" to appear no earlier than
> the specific mcasp configuration?

You can make a static DTS file and not to use the DT overlay support - I'm
doing this with linux-next.

The important thing is to only enable the mcasp node when you add the needed
setup to it. You can have it in the overlay, but enable only in one place.

>>
>>> https://github.com/RobertCNelson/bb.org-overlays/blob/master/src/arm/BB-BONE-AUDI-02-00A0.dts#L72
>>>
>>> I rebuilt the .dtb by commenting out the enabling of the macasp0/1 in
>>> that .dtsi, and now it seems to work! davinci_mcasp_probe is entered
>>> when I apply the overlay, and I get this logged:
>>>
>>> [   35.868324] davinci-mcasp 48038000.mcasp: davinci_mcasp_probe: enter
>>> [   35.874741] davinci-mcasp 48038000.mcasp: serial-dir: 64
>>> [   43.469254] davinci-mcasp 48038000.mcasp: Slots: 2,
>>> 	max_active_serializers: 1, active_serializers: 1,
>>> 	channels: 2, mcasp->num_serializer: 16
>>> [   78.846314] davinci-mcasp 48038000.mcasp: Slots: 2,
>>> 	max_active_serializers: 1, active_serializers: 1,
>>> 	channels: 2, mcasp->num_serializer: 16
>>
>> Great!
> 
> Should I change the DT to use only four serializers? I noticed that
> a) your DTS doesn't specify the number of serializers explicitly,
> and b) has the active/inactive ones set differently from mine:
> 
> https://github.com/RobertCNelson/bb.org-overlays/blob/master/src/arm/BB-BONE-AUDI-02-00A0.dts#L75
> 
>>
>>> By default, speaker-test only outputs to the left channel, and I get
>>> noise out that channel. If I invoke speaker-test -c 2, it claims to
>>> cycle between Front Left and Front Right, but there is only silence
>>> out the Front Right. This is probably due to issues in asound.state,
>>> right (I'd sure love some help getting that straightened out)?
>>
>> I'll try to take a look at the speaker-test, it should work fine AFAIK.
> 
> Yeah, I don't think the problem is in speaker-test, per se. I think it's
> in the ALSA configuration, or perhaps the routing entries in the DTB?

speaker-test will output noise by default.
speaker-test -c2 -t wav # will play samples to each channel

I have spent an hour to figure out why the channels are swapped for me using
the AudioCapeA1... The jack connector is wired up wrongly Left -> Right, Right
-> Left. Aaargh.

Take a look at the alsamixer or start with no asound.state, the after reset
configuration should be fine for the codec to output stereo on the headphone.

-- 
Péter

ASoC: TLV320AIC3x changing suspend delay time

[Timur Karaldin]

Hi!

Could you help me to control delay time for suspend and power down codec. Because of 
HW problem for my board I need to warm reset codec each time I'm doing close/open 
ALSA device. Because of suspend delay the codec's driver didn't power off chip until 
SW waits at least about 5 seconds between close and open. Thank you for any help.

Best regards,
Timur Karaldin

Re: ASoC: TLV320AIC3x changing suspend delay time

[Timur Karaldin]

Have found pmdown_time sysfs parameter, issue is solved, thanks

03.06.2016 16:22, Timur Karaldin пишет:
> Hi!
>
> Could you help me to control delay time for suspend and power down codec. Because of
> HW problem for my board I need to warm reset codec each time I'm doing close/open
> ALSA device. Because of suspend delay the codec's driver didn't power off chip until
> SW waits at least about 5 seconds between close and open. Thank you for any help.
>
> Best regards,
> Timur Karaldin
>
>
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel


-- 
С уважением,
Руководитель проектов
Морские комплексы и системы плюс
Каралдин Т.М.
________________________________________________________
Best regards,
Projects director
Marine complexes and systems plus
Timur Karaldin
__
+7(911)9766791
+7(812)3253802 +7(812)3253804 +7(812)3253806
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel