RE: spi-pl022 on lpc32xx

[Luke Morrison <lmorrison@xxxxxxxxxx>]

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