spi-pl022 on lpc32xx

spi-pl022 on lpc32xx

[Trevor Woerner]

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?

Best regards,
 	Trevor

Re: spi-pl022 on lpc32xx

[Alexandre Belloni]

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!

-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: spi-pl022 on lpc32xx

[Trevor Woerner]

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

Re: spi-pl022 on lpc32xx

[Linus Walleij]

On Mon, Mar 28, 2022 at 9:01 PM Trevor Woerner <twoerner@gmail.com> wrote:

> 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'm using it in with the Cypress CY8CTMA340 touchscreen in
arch/arm/boot/dts/ste-href-tvk1281618-r3.dtsi
like this:

              spi@80111000 {
                        compatible = "arm,pl022", "arm,primecell";
                        reg = <0x80111000 0x1000>;
                        interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
                        #address-cells = <1>;
                        #size-cells = <0>;

                        /* Same clock wired to kernel and pclk */
                        clocks = <&prcc_pclk 2 1>, <&prcc_pclk 2 1>;
                        clock-names = "sspclk", "apb_pclk";
                        dmas = <&dma 33 0 0x2>, /* Logical - DevToMem */
                               <&dma 33 0 0x0>; /* Logical - MemToDev */
                        dma-names = "rx", "tx";
                        power-domains = <&pm_domains DOMAIN_VAPE>;
                        num-cs = <1>;
                        cs-gpios = <&gpio6 24 GPIO_ACTIVE_LOW>;
                        pinctrl-names = "default";
                        pinctrl-0 = <&spi2_default_mode>;

                        touchscreen@0 {
                                compatible = "cypress,cy8ctma340";
                                /*
                                 * Actually the max frequency is 6
MHz, but over 2 MHz the
                                 * data rate needs to be restricted to
max 2Mbps which the
                                 * SPI framework cannot handle.
                                 */
                                spi-max-frequency = <2000000>;
                                reg = <0>;
                                interrupt-parent = <&gpio2>;
                                interrupts = <20 IRQ_TYPE_EDGE_FALLING>;
                                vcpin-supply = <&ab8500_ldo_aux1_reg>;
                                vdd-supply = <&db8500_vsmps2_reg>;
                                reset-gpios = <&gpio4 15 GPIO_ACTIVE_LOW>;
                                touchscreen-size-x = <480>;
                                touchscreen-size-y = <854>;
                                active-interval-ms = <0>;
                                touch-timeout-ms = <255>;
                                lowpower-interval-ms = <10>;
                                bootloader-key = /bits/ 8 <0x00 0x01
0x02 0x03 0x04 0x05 0x06 0x07>;
                                pinctrl-names = "default";
                                pinctrl-0 = <&cyttsp_tvk_mode>;
                        };
                };

It works just fine with DMA and all.

> 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";

The main definition of the SSP is elsewhere in the node with ssp0:, so I
have no idea how this is configured really.

>                 num-cs = <1>;
>                 cs-gpios = <&gpio 3 4 1>;

Use #include <dt-bindings/gpio/gpio.h> and GPIO_ACTIVE_LOW
for the flag so it gets readable.

>                 m25p16@0 {
>                         compatible = "jedec,spi-nor";
>                         reg = <0>;
>                         spi-max-frequency = <500000>;
>
>                         pl022,interface = <0>;
>                         pl022,com-mode = <1>;

com-mode 1 (polling) really? Why? Are interrupts broken
on your silicon?

I made zero default on both in
commit 413c601e8fd0e4adab67e0775dd84e63be6d803e
"spi: pl022: User more sensible defaults"

So the first one can be omitted.

> 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.

These things should be fine. It's tested on quite a lot of systems.

Yours,
Linus Walleij

Re: spi-pl022 on lpc32xx

[Trevor Woerner]

On Tue 2022-03-29 @ 06:06:01 PM, Linus Walleij wrote:
> On Mon, Mar 28, 2022 at 9:01 PM Trevor Woerner <twoerner@gmail.com> wrote:
> 
> > 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'm using it in with the Cypress CY8CTMA340 touchscreen in
> arch/arm/boot/dts/ste-href-tvk1281618-r3.dtsi
> like this:
> 
>               spi@80111000 {
>                         compatible = "arm,pl022", "arm,primecell";
>                         reg = <0x80111000 0x1000>;
>                         interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
>                         #address-cells = <1>;
>                         #size-cells = <0>;
> 
>                         /* Same clock wired to kernel and pclk */
>                         clocks = <&prcc_pclk 2 1>, <&prcc_pclk 2 1>;
>                         clock-names = "sspclk", "apb_pclk";
>                         dmas = <&dma 33 0 0x2>, /* Logical - DevToMem */
>                                <&dma 33 0 0x0>; /* Logical - MemToDev */
>                         dma-names = "rx", "tx";
>                         power-domains = <&pm_domains DOMAIN_VAPE>;
>                         num-cs = <1>;
>                         cs-gpios = <&gpio6 24 GPIO_ACTIVE_LOW>;
>                         pinctrl-names = "default";
>                         pinctrl-0 = <&spi2_default_mode>;
> 
>                         touchscreen@0 {
>                                 compatible = "cypress,cy8ctma340";
>                                 /*
>                                  * Actually the max frequency is 6
> MHz, but over 2 MHz the
>                                  * data rate needs to be restricted to
> max 2Mbps which the
>                                  * SPI framework cannot handle.
>                                  */
>                                 spi-max-frequency = <2000000>;
>                                 reg = <0>;
>                                 interrupt-parent = <&gpio2>;
>                                 interrupts = <20 IRQ_TYPE_EDGE_FALLING>;
>                                 vcpin-supply = <&ab8500_ldo_aux1_reg>;
>                                 vdd-supply = <&db8500_vsmps2_reg>;
>                                 reset-gpios = <&gpio4 15 GPIO_ACTIVE_LOW>;
>                                 touchscreen-size-x = <480>;
>                                 touchscreen-size-y = <854>;
>                                 active-interval-ms = <0>;
>                                 touch-timeout-ms = <255>;
>                                 lowpower-interval-ms = <10>;
>                                 bootloader-key = /bits/ 8 <0x00 0x01
> 0x02 0x03 0x04 0x05 0x06 0x07>;
>                                 pinctrl-names = "default";
>                                 pinctrl-0 = <&cyttsp_tvk_mode>;
>                         };
>                 };
> 
> It works just fine with DMA and all.

Okay, thanks for the reply! It's good to know this driver is being used.

> > 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";
> 
> The main definition of the SSP is elsewhere in the node with ssp0:, so I
> have no idea how this is configured really.

I'm not sure what you mean here. lpc32xx.dtsi defines the ssp0 node and
disables it. On the lpc32xx one must choose between spi and ssp since this SoC
has controllers for both. However the Linux kernel only has a driver for ssp
(i.e. the spi-pl022 driver).

> >                 num-cs = <1>;
> >                 cs-gpios = <&gpio 3 4 1>;
> 
> Use #include <dt-bindings/gpio/gpio.h> and GPIO_ACTIVE_LOW
> for the flag so it gets readable.

Awesome, thanks!

> >                 m25p16@0 {
> >                         compatible = "jedec,spi-nor";
> >                         reg = <0>;
> >                         spi-max-frequency = <500000>;
> >
> >                         pl022,interface = <0>;
> >                         pl022,com-mode = <1>;
> 
> com-mode 1 (polling) really? Why? Are interrupts broken
> on your silicon?

Right now I'm getting nothing back from the spi-nor. I see the SPI subsystem
sending out the 0x9f, I see the pl022 driver writing it to the data register,
I've added some code to the pl022 driver to print out the status register, and
the "receive FIFO not empty flag" (RNE) never goes up. In polling mode it'll
eventually time out and I'll get to a prompt (to reflash and reboot). In
interrupt mode I'd have to yank the power, boot to a different image, flash
from there, and reboot. So polling mode make the build/flash/reboot cycle
faster :-)

> I made zero default on both in
> commit 413c601e8fd0e4adab67e0775dd84e63be6d803e
> "spi: pl022: User more sensible defaults"
> 
> So the first one can be omitted.
> 
> > 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.
> 
> These things should be fine. It's tested on quite a lot of systems.

Thanks, good to know.

Best regards,
	Trevor

Re: spi-pl022 on lpc32xx

[Linus Walleij]

On Tue, Mar 29, 2022 at 8:31 PM Trevor Woerner <twoerner@gmail.com> wrote:

> > >         &ssp0 {
> > >                 status = "okay";
> >
> > The main definition of the SSP is elsewhere in the node with ssp0:, so I
> > have no idea how this is configured really.
>
> I'm not sure what you mean here. lpc32xx.dtsi defines the ssp0 node and
> disables it.

Yeah that is what I'm asking about. So now that I look at that:

                        ssp0: spi@20084000 {
                                compatible = "arm,pl022", "arm,primecell";
                                reg = <0x20084000 0x1000>;
                                interrupts = <20 IRQ_TYPE_LEVEL_HIGH>;
                                clocks = <&clk LPC32XX_CLK_SSP0>;
                                clock-names = "apb_pclk";
                                #address-cells = <1>;
                                #size-cells = <0>;
                                status = "disabled";
                        };

Just apb_pclk? You need sspclk as well. If the same clock is used for
both then add the same clock with the name "sspclk" *before* the
apb_pclk, so:

clocks = <&clk LPC32XX_CLK_SSP0>, <&clk LPC32XX_CLK_SSP0>;
clock-names = "sspclk", "apb_pclk";

NOTE: I don't know if this is what the SoC is actually routing to the SSP.
Consult the LPC32xx docs to figure out which clock is actually connected
to the SSPCLK input of the PL022.

> > >                 m25p16@0 {
> > >                         compatible = "jedec,spi-nor";
> > >                         reg = <0>;
> > >                         spi-max-frequency = <500000>;
> > >
> > >                         pl022,interface = <0>;
> > >                         pl022,com-mode = <1>;
> >
> > com-mode 1 (polling) really? Why? Are interrupts broken
> > on your silicon?
>
> Right now I'm getting nothing back from the spi-nor. I see the SPI subsystem
> sending out the 0x9f, I see the pl022 driver writing it to the data register,
> I've added some code to the pl022 driver to print out the status register, and
> the "receive FIFO not empty flag" (RNE) never goes up. In polling mode it'll
> eventually time out and I'll get to a prompt (to reflash and reboot). In
> interrupt mode I'd have to yank the power, boot to a different image, flash
> from there, and reboot. So polling mode make the build/flash/reboot cycle
> faster :-)

I'd bet on the clock (which is obviously wrong) and if you have a pin
controller then inspect the pin multiplexing too. You have
drivers/pinctrl/pinctrl-lpc18xx.c
but there is no driver for lpc32xx? So how is pin multiplexing
actually set up on this platform?

How are these two SPI and SSP controllers actually sharing these
pins without any configuration anywhere? It just gives me the feel
that an lpc32xx pin control driver is missing.

On LPC18xx it looks like this:

               pinctrl: pinctrl@40086000 {
                        compatible = "nxp,lpc1850-scu";
                        reg = <0x40086000 0x1000>;
                        clocks = <&ccu1 CLK_CPU_SCU>;
                };

SCU sounds like "system control unit" doesn't LPC32xx have one
of these? Where is that configured then?

Yours,
Linus Walleij

Re: spi-pl022 on lpc32xx

[Trevor Woerner]

Hi Linus,

Amazing! It's like you're looking over my shoulder (in a good way) :-)

On Tue 2022-03-29 @ 11:33:48 PM, Linus Walleij wrote:
> On Tue, Mar 29, 2022 at 8:31 PM Trevor Woerner <twoerner@gmail.com> wrote:
> 
> > > >         &ssp0 {
> > > >                 status = "okay";
> > >
> > > The main definition of the SSP is elsewhere in the node with ssp0:, so I
> > > have no idea how this is configured really.
> >
> > I'm not sure what you mean here. lpc32xx.dtsi defines the ssp0 node and
> > disables it.
> 
> Yeah that is what I'm asking about. So now that I look at that:
> 
>                         ssp0: spi@20084000 {
>                                 compatible = "arm,pl022", "arm,primecell";
>                                 reg = <0x20084000 0x1000>;
>                                 interrupts = <20 IRQ_TYPE_LEVEL_HIGH>;
>                                 clocks = <&clk LPC32XX_CLK_SSP0>;
>                                 clock-names = "apb_pclk";
>                                 #address-cells = <1>;
>                                 #size-cells = <0>;
>                                 status = "disabled";
>                         };
> 
> Just apb_pclk? You need sspclk as well. If the same clock is used for
> both then add the same clock with the name "sspclk" *before* the
> apb_pclk, so:
> 
> clocks = <&clk LPC32XX_CLK_SSP0>, <&clk LPC32XX_CLK_SSP0>;
> clock-names = "sspclk", "apb_pclk";
> 
> NOTE: I don't know if this is what the SoC is actually routing to the SSP.
> Consult the LPC32xx docs to figure out which clock is actually connected
> to the SSPCLK input of the PL022.

We're having that exact conversation here:
	http://lists.infradead.org/pipermail/linux-arm-kernel/2022-March/724702.html

On the lpc32xx this device is an APB peripheral meaning its configuration
registers are on the APB bus which are driven by PERIPH_CLK. *However*, the
clock source used to derive the SPI/SSP clock itself (i.e. not the clock used
to communicate with its registers) comes from the HCLK (which is the clock
usually used to drive AHB peripherals on this SoC).

My understanding is that "LPC32XX_CLK_SSP0 is aliased to HCLK, so that should
be fine. apb_pclk, however, is wrong (I believe), unless that dts stanza is
talking about the clock used to communicate with the controller itself.

> > > >                 m25p16@0 {
> > > >                         compatible = "jedec,spi-nor";
> > > >                         reg = <0>;
> > > >                         spi-max-frequency = <500000>;
> > > >
> > > >                         pl022,interface = <0>;
> > > >                         pl022,com-mode = <1>;
> > >
> > > com-mode 1 (polling) really? Why? Are interrupts broken
> > > on your silicon?
> >
> > Right now I'm getting nothing back from the spi-nor. I see the SPI subsystem
> > sending out the 0x9f, I see the pl022 driver writing it to the data register,
> > I've added some code to the pl022 driver to print out the status register, and
> > the "receive FIFO not empty flag" (RNE) never goes up. In polling mode it'll
> > eventually time out and I'll get to a prompt (to reflash and reboot). In
> > interrupt mode I'd have to yank the power, boot to a different image, flash
> > from there, and reboot. So polling mode make the build/flash/reboot cycle
> > faster :-)
> 
> I'd bet on the clock (which is obviously wrong) and if you have a pin
> controller then inspect the pin multiplexing too. You have
> drivers/pinctrl/pinctrl-lpc18xx.c
> but there is no driver for lpc32xx? So how is pin multiplexing
> actually set up on this platform?

I've been zeroing in on that exact same question myself.

In my particular case the first bootloader to run on my device is an old,
in-house, bootloader written 20 years ago. That bootloader configures and runs
SPI, but then never unconfigures it. My U-Boot doesn't do anything with
SPI, and Linux doesn't have an SPI driver. Therefore the first bootloader
configures SPI and then nothing turns it off again (as far as I can tell).

I noticed that the pinmuxing was wrong and I was going to ask the other people
using this device (Alexandre and Vladimir) if they could use something like
devmem2 to tell me what their register 0x40028108 contains. I believe theirs
should contain either 0x0000_1760 or 0x0000_1600 or 0x0000_0160 (depending on
which of ssp0 and/or ssp1 they have enabled). But mine is 0.

I was looking at various registers and wondering about pinmuxing. In fact I
was about to ask if anyone knew how it was being done on the lpc32xx, because
I couldn't find it (but assumed I wasn't looking for the right things).

> How are these two SPI and SSP controllers actually sharing these
> pins without any configuration anywhere? It just gives me the feel
> that an lpc32xx pin control driver is missing.

They can't. On the lpc32xx you can use either the SPI controller or the SSP
controller, but you can't have both enabled at the same time since they both
use the same external pins.

> On LPC18xx it looks like this:
> 
>                pinctrl: pinctrl@40086000 {
>                         compatible = "nxp,lpc1850-scu";
>                         reg = <0x40086000 0x1000>;
>                         clocks = <&ccu1 CLK_CPU_SCU>;
>                 };
> 
> SCU sounds like "system control unit" doesn't LPC32xx have one
> of these? Where is that configured then?

The lpc32xx doesn't have an SCU, but it does have a set of registers used to
set, clear, or show the current state of various pinmuxing arrangements.
Unfortunately some of the pinmuxing configurations are interspersed with
various controllers' control registers as well (e.g. uart, lcd, ethernet mac,
sd card).

This SoC can use some attention, and it has my attention :-) It's also a
32-bit ARM device which could use some more attention too (as I understand
it).

Best regards,
	Trevor

Re: spi-pl022 on lpc32xx

[Vladimir Zapolskiy]

Hi Linus, Trevor,

On 3/30/22 00:33, Linus Walleij wrote:
> On Tue, Mar 29, 2022 at 8:31 PM Trevor Woerner <twoerner@gmail.com> wrote:
> 
>>>>          &ssp0 {
>>>>                  status = "okay";
>>>
>>> The main definition of the SSP is elsewhere in the node with ssp0:, so I
>>> have no idea how this is configured really.
>>
>> I'm not sure what you mean here. lpc32xx.dtsi defines the ssp0 node and
>> disables it.
> 
> Yeah that is what I'm asking about. So now that I look at that:
> 
>                          ssp0: spi@20084000 {
>                                  compatible = "arm,pl022", "arm,primecell";
>                                  reg = <0x20084000 0x1000>;
>                                  interrupts = <20 IRQ_TYPE_LEVEL_HIGH>;
>                                  clocks = <&clk LPC32XX_CLK_SSP0>;
>                                  clock-names = "apb_pclk";
>                                  #address-cells = <1>;
>                                  #size-cells = <0>;
>                                  status = "disabled";
>                          };
> 
> Just apb_pclk? You need sspclk as well. If the same clock is used for
> both then add the same clock with the name "sspclk" *before* the
> apb_pclk, so:
> 
> clocks = <&clk LPC32XX_CLK_SSP0>, <&clk LPC32XX_CLK_SSP0>;
> clock-names = "sspclk", "apb_pclk";
> 
> NOTE: I don't know if this is what the SoC is actually routing to the SSP.
> Consult the LPC32xx docs to figure out which clock is actually connected
> to the SSPCLK input of the PL022.
> 
>>>>                  m25p16@0 {
>>>>                          compatible = "jedec,spi-nor";
>>>>                          reg = <0>;
>>>>                          spi-max-frequency = <500000>;
>>>>
>>>>                          pl022,interface = <0>;
>>>>                          pl022,com-mode = <1>;
>>>
>>> com-mode 1 (polling) really? Why? Are interrupts broken
>>> on your silicon?
>>
>> Right now I'm getting nothing back from the spi-nor. I see the SPI subsystem
>> sending out the 0x9f, I see the pl022 driver writing it to the data register,
>> I've added some code to the pl022 driver to print out the status register, and
>> the "receive FIFO not empty flag" (RNE) never goes up. In polling mode it'll
>> eventually time out and I'll get to a prompt (to reflash and reboot). In
>> interrupt mode I'd have to yank the power, boot to a different image, flash
>> from there, and reboot. So polling mode make the build/flash/reboot cycle
>> faster :-)
> 
> I'd bet on the clock (which is obviously wrong) and if you have a pin
> controller then inspect the pin multiplexing too. You have
> drivers/pinctrl/pinctrl-lpc18xx.c
> but there is no driver for lpc32xx? So how is pin multiplexing
> actually set up on this platform?

years ago you've asked the same question, and the answer is that there is no
pinctrl IP or controls on the SoC. This sounds weird, but that's how it goes.

There are just a few multiplexed pins, and a pin function selection is done
on basis of powering up a corresponding particular IP while keeping
conflicting ones disabled. Such implicit pin multiplexing is inconvenient,
but working, fortunately the SoC is simple to have such a model supported.

The newer LPC18xx/LPC43xx has a pin control IP, and it makes everything much
more transparent and comprehensible, but it's not transferable to LPC32xx.

> How are these two SPI and SSP controllers actually sharing these
> pins without any configuration anywhere? It just gives me the feel
> that an lpc32xx pin control driver is missing.
> 
> On LPC18xx it looks like this:
> 
>                 pinctrl: pinctrl@40086000 {
>                          compatible = "nxp,lpc1850-scu";
>                          reg = <0x40086000 0x1000>;
>                          clocks = <&ccu1 CLK_CPU_SCU>;
>                  };
> 
> SCU sounds like "system control unit" doesn't LPC32xx have one
> of these? Where is that configured then?
> 
> Yours,
> Linus Walleij

--
Best wishes,
Vladimir

Re: spi-pl022 on lpc32xx

[Vladimir Zapolskiy]

Hi Trevor,

On 3/28/22 22:01, 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 have a feeling that Sylvain Lemieux once reported that the PrimeCell SPI
driver worked for him, but here I might be wrong.

> 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>;
> 		};
> 	};
> 

FWIW on my board I do use both SSP0 and SSP1 at once, but I didn't rebase
the dts/kernel for a long time, so the examples might be outdated:

&ssp0 {
	num-cs = <1>;
	cs-gpios = <&gpio 3 5 GPIO_ACTIVE_HIGH>; /* SSEL0 */

	sc16is752@0 {
		compatible = "nxp,sc16is752";
		reg = <0>;
		spi-max-frequency = <4000000>;

		/* 18.432 MHz external oscillator */
		clocks = <&xtal_18432k>;

		/* Interrupt to GPI_07 */
		interrupt-parent = <&sic2>;
		interrupts = <15 IRQ_TYPE_EDGE_FALLING>;
	};
};

&ssp1 {
	num-cs = <1>;
	cs-gpios = <&gpio 3 4 GPIO_ACTIVE_HIGH>;

	s25fl216k@0 {
		compatible = "s25fl216k", "jedec,spi-nor";
		reg = <0>;
		spi-max-frequency = <150000>;
		spi-cpol;
		spi-cpha;
	};
};

Also SSP0 is enabled on PhyTec phy3250 board, there is an at25 eeprom on it,
I've just briefly checked the device tree node, and apparently it contains
some references/properties specific to the PL022 SPI driver.

> 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?
> 
> Best regards,
>   	Trevor

--
Best wishes,
Vladimir

Re: spi-pl022 on lpc32xx

[Trevor Woerner]

Hi Vladimir,

This is great: I've now heard from the driver's maintainer, and the 2 other
people (other than me) still using this SoC ;-)

On Tue 2022-03-29 @ 09:59:07 PM, Vladimir Zapolskiy wrote:
> FWIW on my board I do use both SSP0 and SSP1 at once, but I didn't rebase
> the dts/kernel for a long time, so the examples might be outdated:
> 
> &ssp0 {
> 	num-cs = <1>;
> 	cs-gpios = <&gpio 3 5 GPIO_ACTIVE_HIGH>; /* SSEL0 */
> 
> 	sc16is752@0 {
> 		compatible = "nxp,sc16is752";
> 		reg = <0>;
> 		spi-max-frequency = <4000000>;
> 
> 		/* 18.432 MHz external oscillator */
> 		clocks = <&xtal_18432k>;
> 
> 		/* Interrupt to GPI_07 */
> 		interrupt-parent = <&sic2>;
> 		interrupts = <15 IRQ_TYPE_EDGE_FALLING>;
> 	};
> };
> 
> &ssp1 {
> 	num-cs = <1>;
> 	cs-gpios = <&gpio 3 4 GPIO_ACTIVE_HIGH>;

The chip selects of most SPI devices are active low (and the s25fl216k is
no exception), so *technically* this should probably be GPIO_ACTIVE_LOW.
Regardless, the spi-pl022 driver ignores this parameter anyway:
	https://elixir.bootlin.com/linux/v5.17.1/source/drivers/spi/spi-pl022.c#L458

> 	s25fl216k@0 {
> 		compatible = "s25fl216k", "jedec,spi-nor";
> 		reg = <0>;
> 		spi-max-frequency = <150000>;
> 		spi-cpol;
> 		spi-cpha;
> 	};
> };
> 
> Also SSP0 is enabled on PhyTec phy3250 board, there is an at25 eeprom on it,
> I've just briefly checked the device tree node, and apparently it contains
> some references/properties specific to the PL022 SPI driver.

Thanks for the report. Both you and Alexander are using SSP on this SoC
successfully, and it looks like your configurations are pretty much what I'm
using.

That means it's not the driver, and it's probably not my dts. I'm getting the
feeling that I'm being messed up by my 1st stage bootloader which is
configuring SPI and then leaving it running. I noticed that my SPI_CTRL
register is still setup with the SPI clocks running. Simply disabling the SPI
clocks on startup, however, doesn't seem to fix things. So then I started
looking at the various pinmuxing registers and noticed that nothing is setup
for SSP. The pins that are muxed for SSP are all left in their default
configurations on my device (which means they're all setup for SPI since SPI
is the default and SSP is the alternate).

Any chance either your or Alexander know what register 0x4002_8108 contains?
Maybe you have devmem2 available? Maybe you have bootloaders that are setting
up the pinmuxing for SSP mode for you?

The docs talk about how to configure SPI, and how to configure SSP. But they
don't talk about how to turn one off and enable the other (or if that's even
possible). If it's not possible for this SoC to switch between the two, then
my only option would be to write an SPI driver.

Best regards,
	Trevor

RE: spi-pl022 on lpc32xx

[Luke Morrison]

Hello,

I'm with a team that's working on picking up this work where Trevor had to
leave it behind. We've worked around the issue up until now with a hack
using a userspace program that talks to the SPI peripheral registers through
/dev/mem. This won't be viable over the longer term, and we're revisiting
the task of getting the pl022 driver up and running.

On 3/30/22 10:56, Vladimir Zapolskiy wrote:
> years ago you've asked the same question, and the answer is that there is no
> pinctrl IP or controls on the SoC. This sounds weird, but that's how it goes.
>
> There are just a few multiplexed pins, and a pin function selection is done on
> basis of powering up a corresponding particular IP while keeping conflicting
> ones disabled. Such implicit pin multiplexing is inconvenient, but working,
> fortunately the SoC is simple to have such a model supported.
>
> The newer LPC18xx/LPC43xx has a pin control IP, and it makes everything
> much more transparent and comprehensible, but it's not transferable to
> LPC32xx.
>
I am really curious about that statement. The LPC32xx reference manual does
document a number of registers related to selecting which peripheral gets to
control which shared pins. It's described in chapter 33. Specifically, the
P_MUX_*, P0_MUX_*, P1_MUX_*, P2_MUX_*, and P3_MUX_* registers.

I note that these registers are defined in the kernel, but it doesn't appear
that any drivers are written to actually make use of them. I think this might
be part of the problem that Trevor was hitting when he was working on this.
Since neither the kernel nor U-Boot ever attempt to set the bits that would
need to be set in order to give the SCU control of these pins, and we know
that our stage1 bootloader was previously also leaving these bits cleared,
it's reasonable to conclude that the SCU wouldn't be able to access them.

We are working on a change that directly set the P*_MUX_* registers to
appropriate values for use by the SCU, but I think the more appropriate
approach would be to figure out a way to map these registers into a
proper pinmux driver.

> Best wishes,
> Vladimir

Regards,
Luke
This communication, including any attached documentation, is intended only for the person or entity to which it is addressed, and may contain confidential, personal, and/or privileged information. Any unauthorized disclosure, copying, or taking action on the contents is strictly prohibited. If you have received this message in error, please contact us immediately so we may correct our records. Please then delete or destroy the original transmission and any subsequent reply. Thank you.

RE: spi-pl022 on lpc32xx

[Luke Morrison]

On 11/1/23, Luke Morrison wrote:
> Hello,
> 
> I'm with a team that's working on picking up this work where Trevor had to
> leave it behind. We've worked around the issue up until now with a hack
> using a userspace program that talks to the SPI peripheral registers through
> /dev/mem. This won't be viable over the longer term, and we're revisiting the
> task of getting the pl022 driver up and running.
> 
> On 3/30/22 10:56, Vladimir Zapolskiy wrote:
> > years ago you've asked the same question, and the answer is that there
> > is no pinctrl IP or controls on the SoC. This sounds weird, but that's how it
> goes.
> >
> > There are just a few multiplexed pins, and a pin function selection is
> > done on basis of powering up a corresponding particular IP while
> > keeping conflicting ones disabled. Such implicit pin multiplexing is
> > inconvenient, but working, fortunately the SoC is simple to have such a
> model supported.
> >
> > The newer LPC18xx/LPC43xx has a pin control IP, and it makes
> > everything much more transparent and comprehensible, but it's not
> > transferable to LPC32xx.
> >
> I am really curious about that statement. The LPC32xx reference manual does
> document a number of registers related to selecting which peripheral gets to
> control which shared pins. It's described in chapter 33. Specifically, the
> P_MUX_*, P0_MUX_*, P1_MUX_*, P2_MUX_*, and P3_MUX_* registers.
> 
> I note that these registers are defined in the kernel, but it doesn't appear
> that any drivers are written to actually make use of them. I think this might
> be part of the problem that Trevor was hitting when he was working on this.
> Since neither the kernel nor U-Boot ever attempt to set the bits that would
> need to be set in order to give the SCU control of these pins, and we know
> that our stage1 bootloader was previously also leaving these bits cleared, it's
> reasonable to conclude that the SCU wouldn't be able to access them.
> 
> We are working on a change that directly set the P*_MUX_* registers to
> appropriate values for use by the SCU, but I think the more appropriate
> approach would be to figure out a way to map these registers into a proper
> pinmux driver.
> 
> > Best wishes,
> > Vladimir
> 
> Regards,
> Luke

I have a follow-up. We have experimentally confirmed that it is not
enough to shut off the SPI1 peripheral and power on the SSC0
peripheral; you also need to reconfigure the P*_MUX_* registers to
take away control of the clock and data pins from the SPI and give it
to the SSC. Trevor was on the verge of discovering that last year when
he reached out here, but other obligations stopped him from being
able to finish that work.

In general, it appears that some LPC32xx peripherals will unconditionally
take over control of pins simply by turning them on. Examples include
the LCD controller, motor controller, and SD card controller. But equally,
other peripherals which share pins will defer to pinmux registers instead.
I can see how that could add complication to a properly implemented
pinctrl driver.

Maybe that is a good enough reason to stick with configuring the pins
statically the way we need within the stage1 bootloader and let both
U-Boot and Linux pretend that none of these complexities exist?

Regards,
Luke