Re: spi-pl022 on lpc32xx

[Trevor Woerner <twoerner@xxxxxxxxx>]

On Tue 2022-03-29 @ 06:06:01 PM, Linus Walleij wrote:
> On Mon, Mar 28, 2022 at 9:01 PM Trevor Woerner <twoerner@xxxxxxxxx> 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