[alsa-devel] Kernel Device Tree entries for simple-audio-card
Rick Mann
rmann at latencyzero.com
Tue Sep 29 08:31:10 CEST 2015
> On Sep 28, 2015, at 23:27 , Caleb Crome <caleb at crome.org> wrote:
>
>
> On Mon, Sep 28, 2015 at 5:08 PM, Rick Mann <rmann at latencyzero.com> wrote:
>
> > On Sep 28, 2015, at 16:46 , Caleb Crome <caleb at crome.org> wrote:
> >
> > Hmm, the pinmux looks right, except that you have your TX set as an input. You should have this:
> >
> > mymcasp1_pins_default: mymcasp1_pins_default {
> > pinctrl-single,pins = <
> > 0x1ac ( PIN_OUTPUT | MUX_MODE0 ) /* (A14) mcasp0_ahclkx.mcasp0_ahclkx */
> > 0x190 ( PIN_INPUT | MUX_MODE0 ) /* (A13) mcasp0_aclkx.mcasp0_aclkx */
> > 0x194 ( PIN_INPUT | MUX_MODE0 ) /* (B13) mcasp0_fsx.mcasp0_fsx */
> > 0x198 ( PIN_INPUT | MUX_MODE0 ) /* (D12) mcasp0_axr0.mcasp0_axr0 */
> > 0x19c ( PIN_OUTPUT | MUX_MODE2 ) /* (C12) mcasp0_ahclkr.mcasp0_axr2 */
> > >;
> > };
>
> The DTBO for the Audio Cape didn't mark the TX as an output, but I surely can try that.
>
> That's because you didn't tell it to :-) There's checkbox you need to uncheck to make it Tx. It's an uncelar UI. You uncheck Rx to make it a Tx.
What I mean is, the Audio Cape's DTBO (.dts, really), has the modes on all but the WCLK as 0x20 (one is 0x22). That makes them all inputs. Only WCLK is 0x00. Even if it's for the BB White and not Black, that part wouldn't change.
> That won't get your clocking going unfortunately.
>
> Also, the DTBO I found for the audio cape is for the BeagleBone, not the BeagleBoneBlack, so that threw me for a while.
>
> also, I got things running using the audio cape and the davinci-evm.c device tree entry, not the simple-audio-card. I ended up putting a lot of printk's into the kernel so I could trace out how the whole thing worked.
>
> Your fundamental problem seems to be in getting the McASP's output clock going. Once that's going, then you can worry about getting the codec's PLL to output BCLK and WCLK.
>
> Look through the davinci-evm.c and see what it does that simple-audio-card doesn't. It's something to do with the MCLK for sure.
Could you send me your DTS?
>
> Once your MCLK is going, you can use i2cdump to look at the codec registers:
>
> sudo i2cdump -f -y 1 0x18
>
> or similar.
Yeah, that works.
--
Rick Mann
rmann at latencyzero.com
More information about the Alsa-devel
mailing list