Netdev List
 help / color / mirror / Atom feed
From: Christian Eggers <ceggers@arri.de>
To: "Jörg Sommer" <joerg@jo-so.de>
Cc: Andrew Lunn <andrew@lunn.ch>, <netdev@vger.kernel.org>
Subject: Re: KSZ8795 not detected at start to boot from NFS
Date: Wed, 11 Dec 2024 14:04:37 +0100	[thread overview]
Message-ID: <2675613.fDdHjke4Dd@n9w6sw14> (raw)
In-Reply-To: <cxe42bethnzs7f46xxyvj6ok6ve7itssdxyh2vuftnfws4aa3z@2o4njdkw3r5i>

Hi Jörg,

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.

If you think that your problem is related to the reset timing, feel
free to increase the sleep time after asserting/deasserting the reset
line. Beside the hardware reset there's usually also a software reset.
But this type of reset normally doesn't affect consecutive register
accesses.

> I'm not an expert. So, please, double check this: the spec [1] says on
> page 53, table 4-3, register 11, bit 0 “Trigger on the rising edge of SPI
> clock (for higher speed SPI)”. According to [2] the rising edge is cpol=0
> and mode 0. So, “higher speed SPI” (I think this is the 25MHz) should use
> mode 0.
>
> [1] https://ww1.microchip.com/downloads/aemDocuments/documents/UNG/ProductDocuments/DataSheets/KSZ8795CLX-Data-Sheet-DS00002112.pdf
> [2] https://electronics.stackexchange.com/a/455564

I hate SPI because of its poorly written specifications! When I read the
corresponding sections of the KSZ9563 DS [3], I come to the conclusion that
the register bit you mentioned above affects the SPI *output* signal 
(SPIQ a.k.a MISO). This would also make more sense, as you usually
cannot change the behavior of the SPI input lines.

[3] https://ww1.microchip.com/downloads/en/DeviceDoc/KSZ9563R-Data-Sheet-DS00002419D.pdf

Page 68, on the bottom:
> *SPI Data Out Edge Select*
> 0 = SDO data is clocked by the falling edge of SCL
> 1 = SDO data is clocked by the rising edge of SCL

So the bit 0 is intended to adjust the phase of the SPIQ/SDO/MOSI output
signal, in order to avoid that this signal is switched at the same clock edge
where your uC samples the MISO input.

Also for the KSZ8795CLX there seems to be a mismatch regarding the SPI clock
polarity in the datasheet. Page 28 (functional description) implies CPOL=1
whilst page 123 (timing diagram) shows CPOL=0. I would trust the latter
in this case.

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


regards,
Christian




  reply	other threads:[~2024-12-11 13:04 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-07  7:53 KSZ8795 not detected at start to boot from NFS Jörg Sommer
2024-12-07 20:47 ` Andrew Lunn
2024-12-07 21:07   ` Jörg Sommer
2024-12-07 22:44     ` Christian Eggers
2024-12-08 16:44       ` Jörg Sommer
2024-12-10 16:43         ` Jörg Sommer
2024-12-10 17:41           ` Andrew Lunn
2024-12-10 21:21             ` Jörg Sommer
2024-12-11 10:18           ` Christian Eggers
2024-12-11 12:23             ` Jörg Sommer
2024-12-11 13:04               ` Christian Eggers [this message]
2024-12-11 14:46                 ` Jörg Sommer
2025-01-05 16:33                   ` Jörg Sommer
2025-01-05 17:08                     ` Andrew Lunn
2025-01-06 13:38                       ` Pieter Van Trappen
2025-01-07 22:14                         ` Jörg Sommer
2025-01-08  0:07                           ` Tristram.Ha
2024-12-11 13:24             ` Andrew Lunn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2675613.fDdHjke4Dd@n9w6sw14 \
    --to=ceggers@arri.de \
    --cc=andrew@lunn.ch \
    --cc=joerg@jo-so.de \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox