alsa-devel.alsa-project.org archive mirror
 help / color / mirror / Atom feed
From: Peter Ujfalusi <peter.ujfalusi@ti.com>
To: Rick Mann <rmann@latencyzero.com>
Cc: Alsa-devel <alsa-devel@alsa-project.org>
Subject: Re: mcasp: stream has more channels (2) than are enabled in mcasp (0)
Date: Tue, 19 Apr 2016 14:17:36 +0300	[thread overview]
Message-ID: <571613D0.9060102@ti.com> (raw)
In-Reply-To: <65C7800B-EB96-4407-9174-488B368A890B@latencyzero.com>

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

  reply	other threads:[~2016-04-19 11:17 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-04  8:59 mcasp: stream has more channels (2) than are enabled in mcasp (0) Rick Mann
2016-04-18 15:36 ` Peter Ujfalusi
2016-04-19  0:25   ` Rick Mann
2016-04-19  0:48     ` Rick Mann
2016-04-19  7:00     ` Peter Ujfalusi
2016-04-19  7:18       ` Rick Mann
2016-04-19  7:36         ` Peter Ujfalusi
2016-04-19  8:05           ` Rick Mann
2016-04-19  8:37             ` Peter Ujfalusi
2016-04-19  9:04               ` Rick Mann
2016-04-19  9:22                 ` Peter Ujfalusi
2016-04-19  9:32                   ` Rick Mann
2016-04-19 11:17                     ` Peter Ujfalusi [this message]
2016-06-03 13:22           ` ASoC: TLV320AIC3x changing suspend delay time Timur Karaldin
2016-06-03 14:38             ` Timur Karaldin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=571613D0.9060102@ti.com \
    --to=peter.ujfalusi@ti.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=rmann@latencyzero.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).