Re: spi-pl022 on lpc32xx

[Trevor Woerner <twoerner@xxxxxxxxx>]

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@xxxxxxxxx> 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