Re: spi-pl022 on lpc32xx

[Linus Walleij <linus.walleij@xxxxxxxxxx>]

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.

> 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