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:
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.dts... https://github.com/RobertCNelson/dtb-rebuilder/blob/4.4.x/src/arm/am33xx-es2... https://github.com/RobertCNelson/dtb-rebuilder/blob/4.4.x/src/arm/am335x-bon... https://github.com/RobertCNelson/dtb-rebuilder/blob/4.4.x/src/arm/am33xx-ove...
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...
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...
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?