Marc:

The device tree is for mapping functions to hardware and controlling the 
pin-mux to get the signals in and out.
I think the hardware configuration used by the device tree compiler knows 
that it only has two SPI hardware peripherals, so it won't let you define 
any more.
You can define the required pins as GPIO, and write a driver that bit-bangs 
the SPI interface, but you will need to call it something different than 
regular SPI.
The device tree will understand the GPIO pins, but not much more.
It will run about an order of magnitude slower than the hardware 
peripheral, and have a lot of OS induced jitter.
This may or may not be a problem in your application.
You could also implement an additional SPI interface in each PRU that would 
work much more like a hardware peripheral.
But once again, the device tree will not recognize it a regular SPI 
interface, just some I/O pins that are assigned to the PRU.

--- Graham

==

On Tuesday, January 17, 2017 at 1:55:20 PM UTC-6, Marc M wrote:
>
>
> Hello,
> I have been trying to create some 'virtual' spi ports without success:
>
> I understand that the kernel supports gpio driven spi but I cannot seem to 
> add spi numbering greater than spi1 in my device tree.
> This I think is down to the definitions in the am33xx.dtsi file.
>
> Normally it is defined as a hardware reference:
> spi1: spi@481a0000 {
>
> But I don't have a hardware block/spi controller to address so was trying 
> to create a "virtual" spi controller.
>
> I thought that it should be possible to define an spi port that uses just 
> the gpio lines and the kernel driver bit-bangs the pins to create the 
> software controlled spi functionality.
>
> I have been trying to do this:
>
> /********************* PINMUX ************************/
> spi4_default: spi4_default {
> pinctrl-single,pins = <
> /* SPI 4 */
> 0x90 (PIN_OUTPUT_PULLUP | MUX_MODE7) /* gpmc_advn_ale.gpio_sclk */
> 0x9C (PIN_OUTPUT_PULLUP | MUX_MODE7) /* gpmc_be0n_cle.gpio_d1 */
> 0x3C (PIN_OUTPUT_PULLUP | MUX_MODE7)   /* spi CS0 */
> >;
> };
>
> spi4_sleep: spi4_sleep {
> pinctrl-single,pins = <
> /* SPI 4 reset value */
> 0x90 (PIN_INPUT_PULLDOWN | MUX_MODE7)
> 0x9C (PIN_INPUT_PULLDOWN | MUX_MODE7)
> 0x3C (PIN_INPUT_PULLDOWN | MUX_MODE7) /* spi CS0 */
> >;
> };
>
> /*******************************************************/
> spi4:spi4 {
> pinctrl-names = "default", "sleep";
> pinctrl-0 = <&spi4_default>;
> pinctrl-1 = <&spi4_sleep>; 
>
> compatible = "spi-gpio";
>         #address-cells = <0x1>;
>         ranges;
>
>         gpio-mosi = <&gpio2 2 0>;
>         gpio-sck = <&gpio1 15 0>;
>         cs-gpios = <&gpio2 5 1>;
>         num-chipselects = <1>;
>     status = "okay";
>
>         ioctrl@0 {
>         compatible = "fairchild,74hc595";
>         reg = <0>;
>         gpio-controller;
>         #gpio-cells = <2>;
>         registers-number = <4>;
>         spi-max-frequency = <100000>;
>         };
> };
>
>
> This is not being done as an overlay it is part of the main board device 
> tree for the kernel.
>
> I have also tried different combinations of declaring the device:
> spi4: spi4@0 {
> spi4: spi4 {
> spi4{
> &spi4{
>
> and none of them are successful :(
>
> Can anyone please cast some light on how this would be done ?
>
> Thank you in advance.
>
> Marc
>

-- 
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/a39c4d7b-b156-4072-8531-11d9317307fe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to