Hi Linus, Trevor,
On 3/30/22 00:33, 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.
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?
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.
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.
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?
Yours,
Linus Walleij
--
Best wishes,
Vladimir
