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? 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