As stated in the first post, I've tested it on 4.9 and 4.4, resulting in
same behaviour on both. I've fully disabled mcasp in my .dtsi:
&mcasp0 {
status = "disabled";
};
but it didn't work. This may be due to the board being BBGW not BBB/BBBW -
I've already encountered few other things that work differently and are
poorly documented.
Also, the aim was to do it via pure DTB without any plugin/overlay (dtbo).
As I've written already, I've just switched to SPI0.
Additionally, the 4.9.x kernel seems to have some other ongoing issues
(e.g. PRU RPROC not working in 4.9.32, bad wireless adapter MAC address in
slightly earlier versions and so on) so I've reverted to the most
up-to-date 4.4.x.
W dniu piątek, 23 czerwca 2017 19:08:41 UTC+2 użytkownik Gaurav S napisał:
>
> I had a similar issue with 4.9 kernel where I couldnt load SPI1 pins using
> BB-SPIDEV1. Apparently mcasp was also getting assigned the same pins,
> disabling audio in uEnv helps. Didnt really test it all the way, but I
> could see /dev/spidev* pins loaded and spidev module loaded. Hope this help,
>
> Gaurav
>
> On Friday, June 23, 2017 at 10:33:16 AM UTC-5, [email protected] wrote:
>>
>> Problem "solved" (worked around really) by switching to SPI0, changing
>> the pins around and rerouting most of our custom cape.
>> There are still some problems with the SPI bus but that's a separate
>> issue.
>>
>
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/beagleboard/b89dc6e7-bd41-495e-9b7b-c979ec28e4f2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
