[alsa-devel] 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 at ti.com> wrote:
> 
> On 04/19/16 12:04, Rick Mann wrote:
>> 
>>> On Apr 19, 2016, at 01:37 , Peter Ujfalusi <peter.ujfalusi at 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 at latencyzero.com