On 1/7/2024 6:03 AM, Sergey Ryazanov wrote:
On 06.01.2024 17:45, Andrew Lunn wrote:
I just realized that the UNIPHY block is a MII (probably SGMII)
controller.
Isn't it? And I expect that it responsible more then just for clock
enabling. It should also activate and perform a basic configuration
of MII
for actual data transmission. If so, then it should placed somewhere
under
drivers/net/phy or drivers/net/pcs.
Before we decide that, we need a description of what the UNIPHY
actually does, what registers it has, etc. Sometimes blocks like this
get split into a generic PHY, aka drivers/phy/ and a PCS driver. This
would be true if the UNIPHY is also used for USB SERDES, SATA SERDES
etc. The SERDES parts go into a generic PHY driver, and the SGMII on
to of the SERDES is placed is a PCS driver.
As far as I understand, UNIPHY only contains SGMII/PSGMII/whatever and a
simple clock controller. PCIe & USB phys are implemented in other
hardware blocks. See the lately merged USB support code for similar
IPQ5018 SoC. But I can only speak to what I found searching online and
checking the vendor's qca-ssdk "driver".
https://git.codelinaro.org/clo/qsdk/oss/lklm/qca-ssdk/-/tree/NHSS.QSDK.12.4.5.r3
I hope Luo can clarify with more confidence.
Yes, Sergey. UNIPHY includes the interface mode controller(SGMII/UXGMII
PSGMII etc.) and the clock controller that provides the clocks to the
PPE(packet process engine) ports, which is the dedicated UNIPHY(PCS) for
connecting external PHY(such as qca8084 PHY) and located in the PPE
hardware block. The UNIPHY of PPE can't be used for PCIE & USB.
The problem i have so far is that there is no usable description of
any of this hardware, and the developers trying to produce drivers for
this hardware don't actually seem to understand the Linux architecture
for things like this.
As far as I understand, we basically agree that clocks configuration
can be
implemented based on the clock API using a more specialized driver(s)
than
MDIO. The only obstacle is the PHY chip initialization issue explained
below.
Thank you for this compact yet detailed summary. Now it much more clear,
what this phy chip requires to be initialized.
Looks like you need to implement at least two drivers:
1. chip (package) level driver that is responsible for basic "package"
initialization;
2. phy driver to handle actual phy capabilities.
Nope. As i keep saying, please look at the work Christian is
doing. phylib already has the concept of a PHY package, e.g. look at
the MSCC driver, and how it uses devm_phy_package_join(). What is
missing is a DT binding which allows package properties to be
expressed in DT. And this is what Christian is adding.
Andrew, thank you so much for pointing me to that API and Christian's
work. I have checked the DT change proposal and it fits this QCA8084
case perfectly.
Am I right that all one has to do to solve this QCA8084 initialization
case is wrap phys in a ethernet-phy-package node and use
devm_phy_package_join() / phy_package_init_once() to do the basic
initialization? So simple?
I came to put my 2c in and learnt a couple of new tricks. What a nice
day :)
--
Sergey
