All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Walle <michael@walle.cc>
To: Martin Schiller <ms@dev.tdt.de>
Cc: tharvey@gateworks.com, andrew@lunn.ch, davem@davemloft.net,
	f.fainelli@gmail.com, hauke@hauke-m.de, hkallweit1@gmail.com,
	kuba@kernel.org, linux-kernel@vger.kernel.org,
	linux@armlinux.org.uk, martin.blumenstingl@googlemail.com,
	netdev@vger.kernel.org
Subject: Re: [PATCH net-next v6] net: phy: intel-xway: Add RGMII internal delay configuration
Date: Fri, 24 Feb 2023 09:04:49 +0100	[thread overview]
Message-ID: <df9a0b6e59d27d5898a9021915ca333a@walle.cc> (raw)
In-Reply-To: <8aa26f417c99761cdf1b6b7082fdec14@dev.tdt.de>

Hi Martin,

Am 2023-02-24 07:25, schrieb Martin Schiller:
> On 2023-02-22 17:04, Michael Walle wrote:
>> Hi Tim, Hi Martin,
>> 
>>> I've got some boards with the GPY111 phy on them and I'm finding that
>>> modifying XWAY_MDIO_MIICTRL to change the skew has no effect unless I
>>> do a soft reset (BCMR_RESET) first. I don't see anything in the
>>> datasheet which specifies this to be the case so I'm interested it
>>> what you have found. Are you sure adjusting the skews like this
>>> without a soft (or hard pin based) reset actually works?
>> 
>> I do have the same PHY and I'm puzzled with the delay settings. Do
>> you have an EEPROM attached to the PHY? According to my datasheet,
>> that seems to make a difference. Apparently, only if there is an
>> EEPROM, you can change the value (the value is then also written to
>> the EEPROM according the datasheet).
>> If you don't have one, the values will get overwritten by the
>> external strappings on a soft reset. Therefore, it seems they cannot
>> be set. (FWIW there is also a sticky bit, but that doesn't seem to
>> help in this case).
>> 
>> -michael
> 
> Yes, you are right. The datasheet says: "In no-EEPROM mode, writing to
> this register has no impact on operation of the device".
> 
> But changing this settings without an EEPROM indeed has an impact.
> 
> We don't use an EEPROM and without tuning this values some boards are
> unable to communicate on the ethernet port(s).

Thanks for confirming! Could you share your PHYID1/PHYID2 register and
firmware version (FWV, 0x1E) contents?

In our case, any changes in MIICTRL are lost after a soft reset.

> I varied these values during operation in the uboot and was able to 
> test
> the limits very nicely.

So I guess, the value you write into MIICTRL are retained on a soft 
reset.
I.e.

mii write <phyad> 0x17 0xffff
mii write <phyad> 0x00 0x8000
mii read <phyad> 0x17

will still return 0xffff?

> 
> I wouldn't have introduced this feature if it hasn't got any impact.

Sure, I'm just trying to figure out the differences ;)

Thanks,
Michael

  reply	other threads:[~2023-02-24  8:04 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-19  8:27 [PATCH net-next v6] net: phy: intel-xway: Add RGMII internal delay configuration Martin Schiller
2021-07-19 20:56 ` Andrew Lunn
2021-07-20 11:50   ` Martin Schiller
2022-01-10 23:12 ` Tim Harvey
2022-01-11  7:44   ` Martin Schiller
2022-01-11 13:34     ` Andrew Lunn
2022-01-11 19:12     ` Tim Harvey
2022-01-12 11:07       ` Martin Schiller
2022-01-12 13:14         ` Andrew Lunn
2022-01-12 18:24           ` Tim Harvey
2022-01-12 13:46       ` Russell King (Oracle)
2022-01-12 18:25         ` Tim Harvey
2022-01-13  6:32           ` Martin Schiller
2022-02-01 20:28             ` Tim Harvey
2022-02-01 20:49               ` Andrew Lunn
2023-02-22 16:04   ` Michael Walle
2023-02-24  6:25     ` Martin Schiller
2023-02-24  8:04       ` Michael Walle [this message]
2023-02-24  8:48         ` Martin Schiller
2023-03-02 15:03           ` Michael Walle

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=df9a0b6e59d27d5898a9021915ca333a@walle.cc \
    --to=michael@walle.cc \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=hauke@hauke-m.de \
    --cc=hkallweit1@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=martin.blumenstingl@googlemail.com \
    --cc=ms@dev.tdt.de \
    --cc=netdev@vger.kernel.org \
    --cc=tharvey@gateworks.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.