RE: spi-pl022 on lpc32xx

[Luke Morrison <lmorrison@xxxxxxxxxx>]

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.