Re: spi-pl022 on lpc32xx

[Trevor Woerner <twoerner@xxxxxxxxx>]

Hi Alexandre,

On Mon 2022-03-28 @ 10:09:39 PM, Alexandre Belloni wrote:
> Hello,
> 
> On 28/03/2022 15:01:04-0400, Trevor Woerner wrote:
> > Hi,
> > 
> > I have a spi-nor chip (m25p16) connected to the SPI1 bus of an LPC32xx-based
> > machine that I can't get working.
> > 
> > The LPC32xx has both an SPI controller and an SSP controller, but only one can
> > be active at a time. The SSP is an ARM primecell component which is a "SPI on
> > steroids" device. The SSP can be run in several modes, one of which is "SPI"
> > mode.
> > 
> > The LPC32xx machine does not have a SPI driver in the kernel, but it does have
> > a driver for the SSP controller. Since there is no SPI driver, I'm using the
> > SSP driver in "SPI" mode, but not having much luck.
> > 
> > I can see the SPI subsystem sending the 0x9f command (READ ID), the spi-pl022
> > driver writes the command to the SSP data register, but the flag in the SSP
> > status register to say data has been received never goes up.
> > 
> > I'm wondering if anyone is successfully using the current spi-pl022 driver to
> > interact with an SPI device (preferably on a lpc32xx-based machine)?
> > 
> > I've spent the better part of the last week poking at this. I've tried many
> > combinations of device tree, but what I think should work is:
> > 
> > 	&ssp0 {
> > 		status = "okay";
> > 		num-cs = <1>;
> > 		cs-gpios = <&gpio 3 4 1>;
> > 
> > 		m25p16@0 {
> > 			compatible = "jedec,spi-nor";
> > 			reg = <0>;
> > 			spi-max-frequency = <500000>;
> > 
> > 			pl022,interface = <0>;
> > 			pl022,com-mode = <1>;
> > 		};
> > 	};
> > 
> > I've tried a couple other compatible strings ("micron,m25p16", "st,m25p16"),
> > I've tried a range of frequencies (from 0.5MHz to 33MHz). The 3 options for
> > interface are 0 (SPI), 1 (TI), or 2 (Microwire) and I've tried all of them. I
> > don't believe the DMA system works generically on the lpc32xx but I've tried
> > both interrupt <0> and polling <1> for the com-mode. I believe SPI1 and SSP0
> > are the same and SPI2 and SSP1 are the same (which is why I'm using SSP0
> > here).
> > 
> > The pl-022 driver is quite aggressive about shutting off the SSP and raising
> > the chip select after a message is sent, so I modified my driver to leave the
> > SSP enabled and keeping the (active-low) chip select low (in case those were
> > affecting the reply) but there's no change.
> > 
> > One thing that's curious is that the platform_info->bus_id is -1. This bus
> > number comes from the parent device (spi core). I wonder if this driver is not
> > registering itself correctly with the spi core?
> > 
> 
> On our side, we use ssp0 with spidev and ssp1 that way:
> 
> &ssp1 {
>         #address-cells = <1>;
>         #size-cells = <0>;
>         num-cs = <1>;
>         status = "okay";
>         ads8344: adc@0 {
>                 compatible = "ti,ads8344";
>                 /* mode spi */
>                 pl022,interface = <0>;
>                 reg = <0>;
>                 spi-max-frequency = <2000000>;
>                 #io-channel-cells = <1>;
>                 vref-supply = <&vcc_2_5>;
>         };
> };
> 
> We do ave a workaround to disable DMA because IIRC, it doesn't work
> alongside DMA for the NAND:
> 
> diff --git a/drivers/spi/spi-pl022.c b/drivers/spi/spi-pl022.c
> index d1776fea287e..989b4a980b35 100644
> --- a/drivers/spi/spi-pl022.c
> +++ b/drivers/spi/spi-pl022.c
> @@ -2106,7 +2106,7 @@ pl022_platform_data_dt_get(struct device *dev)
>                 return NULL;
>  
>         pd->bus_id = -1;
> -       pd->enable_dma = 1;
> +       pd->enable_dma = 0;
>         of_property_read_u32(np, "num-cs", &tmp);
>         pd->num_chipselect = tmp;
>         of_property_read_u32(np, "pl022,autosuspend-delay",
> 
> I hope that helps!

It is extremely helpful knowing that someone is currently using the SSP driver
and that it is working for them (i.e. it hasn't bitrotted to the point of not
working). I wonder what version of the kernel you're using?

I'm explicitly setting the pl022,com-mode of my setup to "polling" so the DMA
shouldn't be an issue. I added your patch anyway and am in the same position.

I made an interesting discovery: one of my bootloaders is enabling the SPI
controller, U-Boot doesn't touch it and neither does Linux. But when my Linux
system runs, the SPI system is running. I was hoping that was the source of my
problems, but turning off its clocks doesn't get SSP going for me. Maybe I
need to check more controllers, pinmuxing, and gpio direction registers.

Maybe it would be faster for me to try to get an SPI driver written? lol

Best regards,
	Trevor