On 9/16/20 12:32 AM, Kirby Nankivell wrote:
> I was able to work my way through the initial issues, I was able to resolve the
> device tree interrupt setting.
> This fixed all of the initial issues that I was experiencing, with respect to
> the bring up of the device and the bringing of the link online.
>
> The final DTS fragment ended up like this (Allwinner H3 Base):
> mcp2518fd@1 {
> reg = <1>;
> compatible = "microchip,mcp2518fd";
> clocks = <&can0_osc_fixed>;
> pinctrl-names = "default";
> pinctrl-0 = <&can0_pin_irq>;
> spi-max-frequency = <8823529>;
> interrupts-extended = <&pio 1 1 IRQ_TYPE_LEVEL_LOW>; //PB1
> status = "okay";
> };
What about the spi0 node?
> The clock frequency was chosen on your prior advice: being less than 50% of the
> controller clock speed (10Mhz), and a factor of 600/2x as limited by the
> Allwinner SPI peripheral, in this case; 600 / (2*34).
In my H3 DT, I configure the SPI core to 600 MHz, not sure if the V3s supports that.
The driver will use the DT max frequency as an upper bound. If you use a recent
kernel (v5.7 or newer) or have included my patch:
spi: spi-sun6i: sun6i_spi_transfer_one():
fix setting of clock rate
the spi host driver will pick up a proper clock rate.
> [ 1.255123] CAN device driver interface
> [ 1.259309] spi_master spi0: will run message pump with realtime priority
> [ 1.304566] mcp25xxfd spi0.1 can0: MCP2518FD rev0.0 (-RX_INT -MAB_NO_WARN
> +CRC_REG +CRC_RX +CRC_TX +ECC -HD m:8.82MHz r:8.82MHz e:8.33MHz)
> successfully initialized.
"m:8.82MHz r:8.82MHz e:8.33MHz"
m = maximum as defined by DT
r = requested by driver
e = effective speed used by the host driver
> However that was short lived; I couldn't receive a single message (candump 500k)
> without getting a crc error:
>
> [ 48.469759] mcp25xxfd spi0.1 can0: CRC read error at address 0x001c
> (length=4, data=00 00 1a 3f, CRC=0x1e7c).
> [ 48.479730] mcp25xxfd spi0.1 can0: IRQ handler returned -74 (intf=0x3f1a0002).
Can you compile the mcp25xxfd-regmap.c with adding a:
#define DEBUG
prior to any of the #include statements. That should give some more debugging
output with enabled CRC mode. Please post that here.
> I used the advice previously posted and disabled the CRC mode quirks in the
> driver prior to build which got me some results (I was able to load-test once at
> around 15% bus utilisation at 500k), however now I am getting persistent errors
> after a few packets:
Without CRC, you'll not notice any errors on the SPI bus, better keep it enabled.
> [ 382.629705] mcp25xxfd spi0.1 can0: RX tail of chip (26) and ours (27)
> inconsistent.
> [ 382.637422] mcp25xxfd spi0.1 can0: IRQ handler mcp25xxfd_handle_rxif()
> returned -84.
> [ 382.645189] mcp25xxfd spi0.1 can0: IRQ handler returned -84 (intf=0x3e1a0002).
>
> It seems horribly inconsistent, sometimes high busload is ok, sometimes anything
> more than 250ms in-between single frames will fault the driver. The only
> solution is to ip link down and bring up again, however it is likely to occur
> again the next time the link is online and receiving traffic.I initially thought
> this was related to ECC, however disabling this mode did not improve things.
>
> Any thoughts here?
Can you remove the display from the SPI and test again.
Can you try to limit the spi speed via DT even more, e.g. to 5MHz?
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | https://www.pengutronix.de |
Vertretung West/Dortmund | Phone: +49-231-2826-924 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
Attachment:
signature.asc
Description: OpenPGP digital signature
