Message-ID: <sqsslcr7fsgqi7fvjpy5xnarhlm76atvatczkzwpn37e7gnsu6@tuy7an7t4gdg>
Date: Wed, 11 Dec 2024 15:46:13 +0100
From: Jörg Sommer <joerg@...so.de>
To: Christian Eggers <ceggers@...i.de>, linux-spi@...r.kernel.org
Cc: Andrew Lunn <andrew@...n.ch>, netdev@...r.kernel.org
Subject: Re: KSZ8795 not detected at start to boot from NFS

Hi Christian, hi SPI people,

we are debating the SPI mode setting for the microchip ksz8795 and ksz9477
and possibly others. Since the commit
8c4599f49841dd663402ec52325dc2233add1d32 the SPI mode gets fixed to mode 3
in the code. But at least my ksz8795 works also with mode 0 and shows better
initialization behaviour with mode 0.

The big question is: can both chips work with both modes? Should this
setting stay in code or moved to the device tree?

https://ww1.microchip.com/downloads/en/DeviceDoc/KSZ9563R-Data-Sheet-DS00002419D.pdf
https://ww1.microchip.com/downloads/aemDocuments/documents/UNG/ProductDocuments/DataSheets/KSZ8795CLX-Data-Sheet-DS00002112.pdf

Christian Eggers schrieb am Mi 11. Dez, 14:04 (+0100):
> On Wednesday, 11 December 2024, 13:23:38 CET, Jörg Sommer wrote:
> > Christian Eggers schrieb am Mi 11. Dez, 11:18 (+0100):
> 
> > I think for 8795 these are optional. At me, it works with 0 and 3.
> Hmm, I understood that setting SPI mode to 3 (by my patch) is the
> root of your problem? If you revert my patch and set spi-cpol + spi-cpha
> in you device tree, the result should be more or less the same.

Yes, that's right. When I set spi-cpol + spi-cpha in the DT (or with your
patch) I get the message “ksz8795-switch spi0.1: invalid family id: 0”.
Without it, I don't get this message and the switch works fine.

> If you think that your problem is related to the reset timing,

Not really. My impression is more that “the first read after mode switch
always fails.”

From my other mail:

[    1.712545] ksz8795-switch spi0.1: Switching SPI mode from 0 to spi-cpha,spi-cpol
[    1.851109] ksz8795-switch spi0.1: invalid family id: 0

a gap of 140ms.

With two reads immediately after the spi_setup:

[    1.569835] ksz8795-switch spi0.1: Switching SPI mode from 0 to spi-cpha,spi-cpol
[    1.570641] ksz8795-switch spi0.1: ksz8795_spi_probe:84: ksz_read16(REG_CHIP_ID0, 0) = 0
[    1.571420] ksz8795-switch spi0.1: ksz8795_spi_probe:90: ksz_read16(REG_CHIP_ID0, 34705) = 0
[    1.701375] ksz8795-switch spi0.1: Switching SPI mode from 3 to spi-cpha,spi-cpol
[    1.702191] ksz8795-switch spi0.1: ksz8795_spi_probe:84: ksz_read16(REG_CHIP_ID0, 34705) = 0
[    1.702928] ksz8795-switch spi0.1: ksz8795_spi_probe:90: ksz_read16(REG_CHIP_ID0, 34705) = 0

Maybe the chip needs this read to detect the SPI mode. And if this first
read is the chip detection the initialization fails.

> > > On Thursday, 19 November 2020 07:48:01 -0600, Rob Hering wrote:
> > > > On Wed, Nov 18, 2020 at 09:30:02PM +0100, Christian Eggers wrote:
> > > ...
> > > > > +        ksz9477: switch@0 {
> > > > > +            compatible = "microchip,ksz9477";
> > > > > +            reg = <0>;
> > > > > +            reset-gpios = <&gpio5 0 GPIO_ACTIVE_LOW>;
> > > > > +
> > > > > +            spi-max-frequency = <44000000>;
> > > > > +            spi-cpha;
> > > > > +            spi-cpol;
> > > > 
> > > > Are these 2 optional or required? Being optional is rare as most
> > > > devices support 1 mode, but not unheard of. In general, you shouldn't
> > > > need them as the driver should know how to configure the mode if the h/w
> > > > is fixed.
> > > ...
> > > 
> > > It seems that I considered the h/w as "fixed". The pre-existing device tree
> > > bindings and the diagrams on page 53 suggested that SPI mode 3 is the only
> > > valid option. Particularly the idle state of the "SCL" signal is high here:
> > > 
> > > https://ww1.microchip.com/downloads/en/DeviceDoc/KSZ9563R-Data-Sheet-DS00002419D.pdf
> > > 
> > > But the text description on page 52 says something different:
> > > > SCL is expected to stay low when SPI operation is idle. 
> > > 
> > > Especially the timing diagrams on page 206 look more like SPI mode 0.
> > > 
> > > So it is possible that my patch was wrong (due to inconsistent description
> > > on the data sheet / pre existing device tree binding). As I already mentioned,
> > > I did this only due to the DT conversion, I actually don't use SPI on such
> > > devices myself.
> > > 
> > > N.B. Which KSZ device do you actually use (I didn't find this in you previous
> > > mails)?
> > 
> > I'm using KSZ8795.
> 
> I should better read the subject line ...
> 
> Summary:
> - The timing diagrams of KSZ8795CLX and KSZ9563 implies that SPI mode 0 is correct
> - The functional descriptions in the datasheets look more like SPI mode 3, but this
>   is not authoritative.
> - Maybe that the KSZ devices can work with both modes.

Or maybe not all ksz8 behave the same? Should we revert the behaviour and
leave it up to the device tree to decide?


Jörg

-- 
Prof. in der Mathematikvorlesung zu einem vergessenen φ in der
Gleichung: „Klein‐φ macht auch Mist.“

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)

Powered by blists - more mailing lists