[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <cnmv4ahgyblej7aoknhhb3xyvb67j7t24tug7uoxxtl5s4pjy3@wd3copbtdiec>
Date: Sun, 5 Jan 2025 17:33:38 +0100
From: Jörg Sommer <joerg@...so.de>
To: Christian Eggers <ceggers@...i.de>, Jakub Kicinski <kuba@...nel.org>,
Tristram Ha <tristram.ha@...rochip.com>, Pieter Van Trappen <pieter.van.trappen@...n.ch>,
Woojung Huh <Woojung.Huh@...rochip.com>
Cc: Andrew Lunn <andrew@...n.ch>, netdev@...r.kernel.org,
linux-spi@...r.kernel.org
Subject: Re: KSZ8795 not detected at start to boot from NFS
Hi everyone,
I've added you to the list of recipients, because you where somehow involved
in changes of the KSZ-SPI switch code.
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 (or all ksz) chips work with both modes?
Should this setting stay in code or moved to the device tree?
The specs are here, but I found no evidence about the supported/recommended
SPI modes:
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
The commit 8c4599f498 was a result of the conversion of device trees where
already the question about the SPI mode was raised:
https://lore.kernel.org/netdev/20201119134801.GB3149565@bogus/
> > + 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.
My observation is that the ksz8795 supports mode 0 and mode 3, but it seems
the first read with mode 3 always fails (read value for e.g. chip ID is 0)
which causes the initialization of the chip to fail. Removing the code in
ksz_spi.c:88,+5 or modifying it to use mode 0 gives me a working ksz chip
and I can happily mount the NFS root filesystem.
Can someone at microchip acknowledge that both SPI modes are supported by
the ksz8795 or all chips? Who would be able to test patches?
Thanks in advance.
Here is the last part of the discussion started at
https://lore.kernel.org/netdev/cxe42bethnzs7f46xxyvj6ok6ve7itssdxyh2vuftnfws4aa3z@2o4njdkw3r5i/T/
Jörg Sommer schrieb am Mi 11. Dez, 15:46 (+0100):
> 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?
--
Damit das Mögliche entsteht, muß immer wieder das Unmögliche versucht
werden. (Hermann Hesse)
Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)
Powered by blists - more mailing lists