Re: ram initialization on mcp2518fd

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 20.06.2022 15:36:35, Rasmus Villemoes wrote:
> >>> What does it read on your board? But still that transfer should work.

[...]

> So the problem was that I was using native chip select, i.e. my pinmux
> setting was
> 
> MX8MP_IOMUXC_ECSPI1_SS0__ECSPI1_SS0	0x00000144

HW chip selects are broken in the spi-imx driver/hardware, at least how
to the Linux SPI stack uses them.

> and that means the controller only asserts the CS line for the duration
> of one burst; so when the spi message contains two transfers, it
> obviously breaks as the device saw the release of CS after the two
> command/address bytes as the end of the transaction [then, from the
> device's POV another begins, but there MOSI is all 0, so that may get
> interpreted as a reset command, or perhaps it's ignored because it's not
> precisely 16 0 bits - I wonder how the hardware designers thought
> all-zeros was a good idea for a reset command].
> 
> Switching to gpio, i.e.
> 
> MX8MP_IOMUXC_ECSPI1_SS0__GPIO5_IO09	0x00000144
> 
> means CS is held low for the whole message, and I now read the expected
> contents.

\o/

> It's probably not anything to do with the mcp2518fd driver and this is
> straying somewhat from the original problem, but I see that CS is held
> low for a very long time after the last byte has been shifted in/out, on
> the order of 0.5ms. https://ibb.co/n1Hq3YR shows the first write to OSC,
> and zooming out shows https://ibb.co/12Z1YkM (or just looking at the
> mouse-over info in the first one).
> 
> Similarly, there's a rather large gap between the two spi_transfers in
> the case of the reading of dev_id (but, per the above, with CS correctly
> held throughout): https://ibb.co/pyG1y96 .
> 
> I'm not sure if this is to be expected.

It's the IRQ latency from transfer complete until the CS is deasserted
in software. In kernel v5.19 you will find some patches the improve the
imx-spi driver to use polling for short transfers, which greatly reduces
the latency you've measured.

regards,
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: PGP signature


[Index of Archives]     [Automotive Discussions]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]     [CAN Bus]

  Powered by Linux