On Thu, Aug 24, 2023 at 06:09:52PM -0400, Sean Anderson wrote:

On 8/21/23 19:59, Vladimir Oltean wrote:

quoted

On Mon, Aug 21, 2023 at 07:39:15PM -0400, Sean Anderson wrote:

quoted

Well, I think we should take the opportunity to think about the hardware
which exists and how we plan to model it. IMO grouping lanes into a
single phy simplifies both the phy driver and the mac driver.

Ok, but ungrouped for backplane and grouped for !backplane? For the KR
link modes, parallel link training, with separate consumers per lanes in
a group, will be needed per lane.

Hm, this is the sort of thing I hadn't considered since separate link
training isn't necessary for lynx 10g. But couldn't this be done by
adding a "lane" parameter to phy_configure_opts_xgkr?

Although, I am not sure how the driver is supposed to figure out what
coefficients to use. c73 implies that the training frame should be sent
on each lane. So I expected that there would be four copies of the
link coefficient registers. However, when reading the LX2160ARM, I only
saw one set of registers (e.g. 26.6.3.3). So is link training done
serially? I didn't see anything like a "lane select" field.

--Sean

There is one AN/LT block replicated for each lane, even for multi-lane
backplane protocols. The primary (first) AN/LT block handles C73 autoneg
+ C73 link training on that lane, and the secondary AN/LT blocks handle
just link training on their respective lanes.

In other words, each AN/LT block needs to interact with just its lane
(SerDes PHY). A "lane" parameter could be added to phy_configure_opts_xgkr
to work around the "grouped lanes" design, but it would complicate the
consumer implementation, since the AN/LT block does not otherwise need
to know what is the index of the SerDes lane it is attached to (so it
would need something like an extra device tree property).

C72 link training is independent on each lane, has independent AN/LT
block MDIO registers, independent SerDes lane registers, and independent
training frame exchanges. There is no "lane select" field.

You can see the "LX2160A lanes A, B, C, D with SerDes 1 protocol 19:
dpmac2 uses 40GBase-KR4" example in my backplane dt-bindings patch,
which shows how on dpmac2's internal MDIO bus, there are AN/LT devices
at MDIO addresses 7, 6, 5 and 4, one for each lane.

I know that Lynx 10G doesn't do multi-lane backplane, but I wouldn't
want Lynx 10G and Lynx 28G to have different designs when it comes to
their handling of multi-lane. A single design that works for both would
be great.