>> Update on my SPI and DMA related problems with Beaglebone + ENC28J60:
>>
>> As I wrote in my previous mail, I could see that the data received by
>> the SPI driver was not same as what I could see using an oscilloscope.
>> The data I could see using the oscilloscope was 0x06 but the driver
>> returned 0x3C.
>>
>> Then I switched from spi0 to spi1, and to my surprise that port works!
>> However, as soon as there was substantial data available the driver and
>> kernel crashed with a DMA related error (included below).
>>
>> I disabled DMA by setting DMA_MIN_LEN to a very big number, and finally
>> I have a reliable network connection with ENC28J60!
>>
>> But I would prefer to use spi0, and I’m of course not happy with disabling
>> DMA.
>>
>> I’m using kernel 4.7.1 at commit 95f15f5ed6e68b479c73da842012108c567c6999.
>> There are no custom patches, except for a custom device tree.
>>
>> Any hints how to debug this further?
>
> Franklin recently reworked the mcspi dma part quite a bit. It looks
> like that work went into v4.8. Can you try the latest v4.8 rc to see if
> that helps. Here are the commits:
>
> 0ba1870f8865 (Franklin S Cooper Jr) 6 weeks ago spi: omap2-mcspi: Use the SPI framework to handle DMA mapping
> 2b32e987c48c (Franklin S Cooper Jr) 6 weeks ago spi: omap2-mcspi: Select SPI_SPLIT
Interesting. I will try that version. However, I have now tested with an older kernel. version 4.6.x, and there was no DMA related errors in that version! spi0 does still not work though.
> Cant think of a reason why spi1 works but not spi0. I would suspect the
> pinmux first. Did you double-check that?
I’ve been checking my pinmux settings for the whole week, but there may of course still be some error left. I got a bit worried after finding out that the clock output must be configured as an *input* or else nothing works!
Here’s the relevant parts of the current device tree (it’s a bit of a mess currently, but perhaps you can still see if there’s something fishy):
#include <dt-bindings/interrupt-controller/irq.h>
&am33xx_pinmux {
spi0_pins_default: spi0_pins_default {
pinctrl-single,pins = <
0x150 (PIN_INPUT_PULLDOWN | MUX_MODE0) /* spi0_sck */
0x154 (PIN_INPUT | MUX_MODE0) /* spi0_d0 */
0x158 (PIN_OUTPUT | MUX_MODE0) /* spi0_d1 */
0x15C (PIN_OUTPUT_PULLUP | MUX_MODE0) /* spi0_cs0 */
0x17C (PIN_OUTPUT_PULLUP | MUX_MODE7) /* Chip Select on GPIO0[13] (#505) */
> ;
};
spi1_pins_default: spi1_pins_default {
pinctrl-single,pins = <
0x190 0x33 /* mcasp0_aclkx.spi1_sclk, INPUT_PULLUP | MODE3 */
0x194 0x33 /* mcasp0_fsx.spi1_d0, INPUT_PULLUP | MODE3 */
0x198 0x13 /* mcasp0_axr0.spi1_d1, OUTPUT_PULLUP | MODE3 */
0x19c 0x13 /* mcasp0_ahclkr.spi1_cs0, OUTPUT_PULLUP | MODE3 */
> ;
};
enc28j60_pins_default: enc28j60_pins_default {
pinctrl-single,pins = <
0x98 ( PIN_INPUT_PULLUP | MUX_MODE7 ) /* !reset (U6) */
0x9c ( PIN_INPUT_PULLUP | MUX_MODE7 ) /* int (T6) */
> ;
};
};
&i2c2 {
/*
There is a pin conflict between ENC28J60 and I2C2 so we need to
disable I2C2 which is not used anyway: it's configured for an
eeprom cape. A better solution may be to move the conflicting
pin of ENC28J60 to another pin (int, reset or chip select)
*/
status = "disabled";
};
&spi0 {
status = "disabled";
};
&spi1 {
status = "okay";
/* Configure first chip select to use CS0 and second to use GPIO0[13] */
/* See #505 for details. */
/* num-cs = <2>;
cs-gpios = <0>, <&gpio0 13 0>; */
/* Oops, the default is to use d0 as input, d1 as output, but on the */
/* first revision of the BBGW cape we swapped these. */
/* ti,pindir-d0-out-d1-in = <1>; */
pinctrl-names = "default";
pinctrl-0 = <&spi1_pins_default>;
enc28j60@0 {
status = "okay";
compatible = "microchip,enc28j60";
spi-max-frequency = <1000000>;
reg = <0>; /* CS1 */
interrupt-parent = <&gpio2>;
interrupts = <5 IRQ_TYPE_EDGE_FALLING>;
pinctrl-names = "default";
pinctrl-0 = <&enc28j60_pins_default>;
};
};--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
