| Message ID | 20231215074005.26976-15-quic_luoj@quicinc.com |
|---|---|
| State | New |
| Headers | show |
| Series | add qca8084 ethernet phy driver | expand |
On 12/17/2023 12:09 AM, Russell King (Oracle) wrote: > On Sat, Dec 16, 2023 at 10:41:28PM +0800, Jie Luo wrote: >> >> >> On 12/16/2023 9:51 PM, Russell King (Oracle) wrote: >>> On Sat, Dec 16, 2023 at 11:21:53AM +0100, Andrew Lunn wrote: >>>>> The following is the chip package, the chip can work on the switch mode >>>>> like the existed upstream code qca8k, where PHY1-PHY4 is connected with >>>>> MAC1-MAC4 directly; >>>> >>>> Ah, that is new information, and has a big effect on the design. >>> >>> This QCA8084 that's being proposed in these patches is not a PHY in >>> itself, but is a SoC. I came across this: >>> >>> https://www.rt-rk.com/android-tv-solution-tv-in-smartphone-pantsstb-based-on-qualcomm-soc-design/ >> >> The chip mentioned in the link you mentioned is SoC, which is not the >> chip that the qca8084 driver work for. > > So there's two chips called QCA8084 both produced by Qualcomm? I find > that hard to believe. > The SoC mentioned in the link you provided is the APQ8084 that is introduced in the link below: https://www.qualcomm.com/products/mobile/snapdragon/smartphones/snapdragon-8-series-mobile-platforms/snapdragon-processors-805 https://hwbot.org/hardware/processor/snapdragon_805_apq8084_pro__(8084_fusion_4.5)_2700mhz/ The driver here is for qca8084, which has the different prefix, and qca8084 is the Ethernet CHIP like qca8081, but qca8084 is multiple ports(quad-phy).
On 12/17/2023 1:30 AM, Andrew Lunn wrote: >> The following is the chip package, the chip can work on the switch mode >> like the existed upstream code qca8k, where PHY1-PHY4 is connected with >> MAC1-MAC4 directly; The chip can also work on the PHY mode, where PHY1- >> PHY4 is connected with PCS1 by 10g-qxgmii; Either switch mode or PHY mode, >> the PHY4 is optionally connected with PCS0 by SGMII, PCS0 and PCS1 >> are connected with the SoC(IPQ platform) PCSes. > > I don't really understand. Are you saying the hardware is actually : > > > +----------------------------------------------+ > | PCS1 PCS0 | > | | > | MAC0 MAC5 | > | | | | > | +-----+--------------+-------------+ | > | | | | > | | Switch | | > | | | | > | +-+---------+---------+---------+--+ | > | | | | | | > | MAC1 MAC2 MAC3 MAC4 | > | | > | PHY1 PHY2 PHY3 PHY4 | > +----------------------------------------------+ > Actually there are two CHIP types, ,let me explain to be more clear. 1. The diagram you describe is actually the switch work mode, which has the different chip name called qca8386, the DSA driver and PHY driver are used, since the general PHY driver can't work for the PHY here. +----------------------------------------------+ | +-----+ | | GCC | | +-----+ PCS1 PCS0 | | | | MAC0 MAC5 | | | | | | +-----+--------------+-------------+ | | | | | | | Switch | | | | | | | +-+---------+---------+---------+--+ | | | | | | | | MAC1 MAC2 MAC3 MAC4 | | | | PHY1 PHY2 PHY3 PHY4 | +----------------------------------------------+ 2. The pure PHY chip called by qca8084 works on the PHY mode 10-qxgmii on quad-phy, or the sgmii mode can be configured on PHY4 optionally. The qca8084 is below, there is no MAC involved on qca8084. +----------------------------------------------+ | PCS1 PCS0 | | | | +-----+ | | GCC | | +-----+ | | | PHY1 PHY2 PHY3 PHY4 | +----------------------------------------------+ On qca8386, the same qca8084 PHY is used, but the qca8084 PHY is connected with internal MAC directly same as qca8337(qca8k dsa driver). On both Ethernet chips qca8386 and qca8084, GCC block is same and with the same clock controller driver that provides the clocks and resets used by the qca8084 PHY driver and qca8386 DSA driver(leverage the existed DSA driver qca8k.c). > When in PHY mode, the switch is hard coded to map the 4 PCS1 channels > straight to MAC1-MAC4 and all switch functionality is disabled. But > then in switch mode, the switch can be controlled as a DSA switch? The > 10G PCS1 is then a single 10G port, not 4x 2.5G? For the qca8084 PHY chip, there is no MAC involved, the PHY is connected with the PCS with 10g-qxgmii, PHY4 is optional connected with sgmii. For the qca8386 switch chip, it is controlled as DSA, the PCS is connected with the SOC(such as IPQ5332) PCS. > > Is there a product brief for this PHY? That might help us understand > this hardware? > Sorry, i also searched it on the internet and Qualcomm website, there is no Doc found, the CHIP is developed recently 1-2 year before, the Doc is not updated to the website. > Andrew
On 12/17/2023 3:08 AM, Russell King (Oracle) wrote: > On Sat, Dec 16, 2023 at 06:30:00PM +0100, Andrew Lunn wrote: >>> The following is the chip package, the chip can work on the switch mode >>> like the existed upstream code qca8k, where PHY1-PHY4 is connected with >>> MAC1-MAC4 directly; The chip can also work on the PHY mode, where PHY1- >>> PHY4 is connected with PCS1 by 10g-qxgmii; Either switch mode or PHY mode, >>> the PHY4 is optionally connected with PCS0 by SGMII, PCS0 and PCS1 >>> are connected with the SoC(IPQ platform) PCSes. >> >> I don't really understand. Are you saying the hardware is actually : >> >> >> +----------------------------------------------+ >> | PCS1 PCS0 | >> | | >> | MAC0 MAC5 | >> | | | | >> | +-----+--------------+-------------+ | >> | | | | >> | | Switch | | >> | | | | >> | +-+---------+---------+---------+--+ | >> | | | | | | >> | MAC1 MAC2 MAC3 MAC4 | >> | | >> | PHY1 PHY2 PHY3 PHY4 | >> +----------------------------------------------+ >> >> When in PHY mode, the switch is hard coded to map the 4 PCS1 channels >> straight to MAC1-MAC4 and all switch functionality is disabled. But >> then in switch mode, the switch can be controlled as a DSA switch? The >> 10G PCS1 is then a single 10G port, not 4x 2.5G? >> >> Is there a product brief for this PHY? That might help us understand >> this hardware? > > Not even digikey give any clues what "QCA8084" is - they list it as > "unclassified" and give no documentation and no photo. Basically it > seems to be a super secret device. > Sorry for the confusion here, maybe the chip is developed recently, which leads to the Doc or introduction is not released in time.
On 12/17/2023 1:17 AM, Andrew Lunn wrote: >> Yes, Russell, i will add an example in the DT doc in the next patch set. >> The following is the device node used for the current qca8084 PHY >> code design. > > If you look at Christians work, this would be expressed differently: > >> mdio: mdio@90000 { >> ethernet-phy-package@1 { >> >> compatible = "qca,qca8084-package"; >> >> qcom,phy-work-mode = <2>; >> clocks = <&qca8k_nsscc NSS_CC_APB_BRIDGE_CLK>, >> <&qca8k_nsscc NSS_CC_AHB_CLK>, >> <&qca8k_nsscc NSS_CC_SEC_CTRL_AHB_CLK>, >> <&qca8k_nsscc NSS_CC_TLMM_CLK>, >> <&qca8k_nsscc NSS_CC_TLMM_AHB_CLK>, >> <&qca8k_nsscc NSS_CC_CNOC_AHB_CLK>, >> <&qca8k_nsscc NSS_CC_MDIO_AHB_CLK>, >> <&qca8k_nsscc NSS_CC_MDIO_MASTER_AHB_CLK>, >> <&qca8k_nsscc NSS_CC_SRDS0_SYS_CLK>, >> <&qca8k_nsscc NSS_CC_SRDS1_SYS_CLK>; >> clock-names = "apb_bridge", >> "ahb", >> "sec_ctrl_ahb", >> "tlmm", >> "tlmm_ahb", >> "cnoc_ahb", >> "mdio_ahb", >> "mdio_master_ahb", >> "srds0_sys", >> "srds1_sys"; >> resets = <&qca8k_nsscc NSS_CC_SRDS0_SYS_ARES>, >> <&qca8k_nsscc NSS_CC_SRDS1_SYS_ARES>, >> <&qca8k_nsscc NSS_CC_DSP_ARES>; >> reset-names = "srds0_sys", >> "srds1_sys"; >> > > All the properties above are common to the package as a whole. > > Then follow the four individual PHYs, and the properties which are > specific to each one. Thanks Andrew for the proposal. For the pure PHY chip qca8084, there is no driver to parse the package level device tree node for common clocks and resets. For the common clocks and resets above, whether we can add a qca8084 common device tree node as the child node of MDIO bus node, and then parse these common properties in the PHY probe function? since the DSA driver is not enabled for the pure PHY chip. > >> >> ethernet-phy@0 { >> compatible = "ethernet-phy-id004d.d180"; >> reg = <0>; >> clocks = <qca8k_nsscc NSS_CC_GEPHY0_SYS_CLK>, >> clock-names = <"gephy_sys">; >> resets = <&qca8k_nsscc NSS_CC_GEPHY0_SYS_ARES>, >> <&qca8k_nsscc NSS_CC_GEPHY0_ARES>; >> reset-names = "gephy_sys", "gephy_soft"; >> }; >> >> >> ethernet-phy@1 { >> compatible = "ethernet-phy-id004d.d180"; >> reg = <1>; >> clocks = <qca8k_nsscc NSS_CC_GEPHY1_SYS_CLK>, >> clock-names = <"gephy_sys">; >> resets = <&qca8k_nsscc NSS_CC_GEPHY1_SYS_ARES>, >> <&qca8k_nsscc NSS_CC_GEPHY1_ARES>; >> reset-names = "gephy_sys", "gephy_soft"; >> >> }; >> >> ethernet-phy@2 { >> compatible = "ethernet-phy-id004d.d180"; >> reg = <2>; >> clocks = <qca8k_nsscc NSS_CC_GEPHY2_SYS_CLK>, >> clock-names = <"gephy_sys">; >> resets = <&qca8k_nsscc NSS_CC_GEPHY2_SYS_ARES>, >> <&qca8k_nsscc NSS_CC_GEPHY2_ARES>; >> reset-names = "gephy_sys", "gephy_soft"; >> >> }; >> >> ethernet-phy@3 { >> compatible = "ethernet-phy-id004d.d180"; >> reg = <3>; >> clocks = <qca8k_nsscc NSS_CC_GEPHY3_SYS_CLK>, >> clock-names = <"gephy_sys">; >> reset-names = "gephy_sys", "gephy_soft"; >> }; >> }; > > Andrew
On 12/17/2023 12:01 AM, Christian Marangi wrote: > On Sat, Dec 16, 2023 at 10:41:28PM +0800, Jie Luo wrote: >> >> >> On 12/16/2023 9:51 PM, Russell King (Oracle) wrote: >>> On Sat, Dec 16, 2023 at 11:21:53AM +0100, Andrew Lunn wrote: >>>>> The following is the chip package, the chip can work on the switch mode >>>>> like the existed upstream code qca8k, where PHY1-PHY4 is connected with >>>>> MAC1-MAC4 directly; >>>> >>>> Ah, that is new information, and has a big effect on the design. >>> >>> This QCA8084 that's being proposed in these patches is not a PHY in >>> itself, but is a SoC. I came across this: >>> >>> https://www.rt-rk.com/android-tv-solution-tv-in-smartphone-pantsstb-based-on-qualcomm-soc-design/ >> >> The chip mentioned in the link you mentioned is SoC, which is not the >> chip that the qca8084 driver work for. >> >> qca8084/qca8386 is just the Ethernet CHIP, not SoC, for the switch mode >> qca8386, which is most like qca8337 the dsa drive qca8k.c is already in >> upstream. > > Hi, > sorry for stepping in. I guess here there is a massive confusion with > naming and using qca8k. > > Since it seems the same name is used for PHY and for Switch stuff, I > would add PHY and MAC prefix when referring to qca8064. Hi Christian, Welcome to join the discussion. Sorry for the confusion, since the switch and PHY are the different chips, the switch chip is named as qca8386, the pure PHY chip is named as qca8084, the pure PHY chip qca8084 is connected with the SoC by PCS working on 10g-qxgmii, the switch chip qca8386 is connected with SoC by PCS working on sgmii. > > With the previous message I was a bit confused by the use of qca8k and > didn't know you were actually referring to the DSA driver. > Interesting... this is for the upcoming WiFi 7 platoform right? (ipq9574) For qca8386, it is the switch chip and leverages the qca8k DSA driver, it is connected on the ipq5332 platform currently. But for qca8084, it is the pure PHY chip, which works on 10g-qxgmii for quad-phy, which is connected on the ipq9574. > > All these discussion comes for the problem of using this PHY as an > integrated PHY in the qca8386 switch and trying to select the mode in > the PHY driver. Yes, for qca8386, the PHY is integrated to switch, since same PHY needs to work with qca8386 and qca8084, so the work mode needs to be configured to distinguish the different work mode as the patch <[PATCH v8 13/14] net: phy: at803x: configure qca8084 work mode>. > > Considering you would use the same logic of the current DSA qca8k driver > with the integrated PHY, the problem doesn't apply or a different > implementation should be used (and actually handled later when the > actual DSA code will come) qca8386 has some differences from qca8337(qca8k dsa driver), qca8337 integrated PHY can work by the general PHY, but the PHY in qca8386 needs the extra PHY driver, and the GCC clocks introduced. > > I would expect in the integrated mode, the switch to handle the PHY (as > it's done by qca8337) with the PHY defined in the switch node and qca8k > handling the PHY registration. With the following implementation flags > can be passed and PHY can be configured to integrated mode. (or virtual > PHY ID can be used for such scope with dedicated functions in the PHY > driver) > Since there is the pure PHY chip qca8084 using the same PHY, which does not enable the DSA driver. So the PHY driver should be standalone, and the common clocks and resets is better to put in the PHY driver, since these are the common configs for the qca8386 and qca8084. > With this in mind the entire integrated problem can put on hold and > dropped to be later reimplemented when it's time. (assuming that all the > prereq are already here and the very same implementation of qca8k will > be used) For the qca8386, it is true very same implementation of qca8k, besides the 2.5G capability and GCC clock involved. > > Anyway, I'm more or less the maintainer of the qca8k.c DSA driver and I > would be more than happy to help you guys internally or externally on > pushing and make this proceed further. (again assuming this is ipq9574 > stuff, it would be good to finally have proper DSA driver instead of > leaving the thing unusable as it's the current situation with ipq8074) Yes, the pure PHY chip qca8084 is connected on ipq9574 platform, and the switch chip qca8386 is connected on ipq5332 platform. Many thanks Christian again, will add you when pushing the qca8386 DSA patches for upstream review. > >> >> i qca8084 chip package includes 4 PHYs, 2 PCSs and the common chip level >> modules such as GCC and security control modules, all these modules are >> located in the qca8084 chip package, since qca8084 works on PHY mode, so >> the MACs are not used. >> >> qca8084 is connected with the SoC CHIP such as IPQ platform by PCS1 >> working on 10g-qxgmii mode and the fourth PHY can also optionally >> be connected with the IPQ SoC PCS by sgmii mode, there is no more >> interface on qca8084 to connect the external chips. >> >>> It's sounding like what we have here is some PHY IP that is integrated >>> into a larger SoC, and the larger SoC needs to be configured so the >>> PHY IP can work correctly. >> >> qca8084 is not a SoC, it is the Ethernet chip, in this qca8084 package, >> there are GCC that is driving the PHY working on the various link speed. >> that is the reason we need to do these package level common clocks and >> resets initialization before probing PHY correctly. >> >>> >>> Given that this package of four PHYs seems to be rather unique, I think >>> we need Jie Luo to provide sufficient information so we can understand: >>> >>> 1) this package of four PHYs itself >> >> Yes, this chip package for all 4 PHYs itself, also including the PCSes >> and common package level modules such as GCC. >> >>> 2) how this package is integrated into the SoC >> >> the qca8084 is connected with SoC by PCSes. >> >>> >>> Specifically, what resets and clocks are controlled from within the >>> package's register space, which are external to the package >>> register space (and thus are provided by other IPs in the SoC). >> >> All clocks and resets mentioned for qca8084 drive including package >> level and PCS & PHY clocks and resets from the qca8084 internal GCC >> modules register space, >> >>> >>> As I've said previously, the lack of DT example doesn't help to further >>> our understanding. The lack of details of what the package encompases >>> also doesn't help us understand the hardware. >> >> Indeed, i will add the qca8084 DT example in the next patch set. >> BTW, i also replied your earlier comments by providing the DTS defined >> for the current qca8084 drive code. >> >> hope you can have a better understanding with the provided DTS code in >> earlier reply of this email thread. >>> >>> Unless we can gain that understanding, I feel that Jie Luo's patches >>> are effectively unreviewable and can't be accepted into mainline. >>> >
> Thanks Andrew for the proposal. > For the pure PHY chip qca8084, there is no driver to parse the package > level device tree node for common clocks and resets. So you still have not look at the work Christian is doing. You must work together with Christian. This driver is not going to be accepted unless you do. > > > ethernet-phy@0 { > > > compatible = "ethernet-phy-id004d.d180"; > > > reg = <0>; > > > clocks = <qca8k_nsscc NSS_CC_GEPHY0_SYS_CLK>, > > > clock-names = <"gephy_sys">; > > > resets = <&qca8k_nsscc NSS_CC_GEPHY0_SYS_ARES>, > > > <&qca8k_nsscc NSS_CC_GEPHY0_ARES>; > > > reset-names = "gephy_sys", "gephy_soft"; Which of these properties exist for the Pure PHY device? Which exist for the integrated switch? And by that, i mean which are actual pins on the PHY device? We need the device tree binding to list which properties are required for each use case. Andrew
On 1/2/2024 6:08 PM, Christian Marangi wrote: > On Tue, Jan 02, 2024 at 09:57:48AM +0000, Russell King (Oracle) wrote: >> On Mon, Dec 18, 2023 at 11:01:03AM +0800, Jie Luo wrote: >>> >>> >>> On 12/17/2023 12:09 AM, Russell King (Oracle) wrote: >>>> On Sat, Dec 16, 2023 at 10:41:28PM +0800, Jie Luo wrote: >>>>> >>>>> >>>>> On 12/16/2023 9:51 PM, Russell King (Oracle) wrote: >>>>>> On Sat, Dec 16, 2023 at 11:21:53AM +0100, Andrew Lunn wrote: >>>>>>>> The following is the chip package, the chip can work on the switch mode >>>>>>>> like the existed upstream code qca8k, where PHY1-PHY4 is connected with >>>>>>>> MAC1-MAC4 directly; >>>>>>> >>>>>>> Ah, that is new information, and has a big effect on the design. >>>>>> >>>>>> This QCA8084 that's being proposed in these patches is not a PHY in >>>>>> itself, but is a SoC. I came across this: >>>>>> >>>>>> https://www.rt-rk.com/android-tv-solution-tv-in-smartphone-pantsstb-based-on-qualcomm-soc-design/ >>>>> >>>>> The chip mentioned in the link you mentioned is SoC, which is not the >>>>> chip that the qca8084 driver work for. >>>> >>>> So there's two chips called QCA8084 both produced by Qualcomm? I find >>>> that hard to believe. >>>> >>> >>> The SoC mentioned in the link you provided is the APQ8084 that is introduced >>> in the link below: >>> https://www.qualcomm.com/products/mobile/snapdragon/smartphones/snapdragon-8-series-mobile-platforms/snapdragon-processors-805 >> >> So the one mentioned in the rt-rk article and a load of CVEs is _not_ >> QCA8084 but is APQ8084. Sounds like a lot of people are getting stuff >> wrong - which is hardly surprising as there are people that seem to >> _enjoy_ getting the technical details wrong. I haven't worked out if >> it's intentional malace, or they're just fundamentally lazy individuals >> who just like to screw with other people. >> >> Sigh. >> > > Hoping to give some clarification with the naming. > - APQ8084 ("Application" SoC for 8084 family) > - IPQ8084 ("Internet" SoC version of APQ8084) > - QCA8084 (Integrated PHYs in the IPQ8084 SoC) > > I guess? > > Considering QCA8084 is only in in IPQ8084 SoC, the confusion with > referring to it is in the fact that it's all the same thing, and > everything related to APQ is also related to IPQ since they are the same > SoC with minor difference (different DSP, presence of NSS cores) > > I can totally see sencente like "The IPQ8084 PHYs..." referencing the > QCA8084 PHY. > > (Just to put how the naming is confusing there are PMIC with the > same exact naming) > There should be NO IPQ8084. Yes, APQ8084 is the application SoC. QCA8084 is the pure PHY chip which has quad-phy. The prefix QCA is the Ethernet device, like qca8081(PHY chip), qca8386( switch chip) and qca8084(PHY chip). The prefix IPQ is the internet processor SoC, like ipq5332.
On 1/3/2024 10:22 PM, Andrew Lunn wrote: >> Yes, APQ8084 is the application SoC. >> QCA8084 is the pure PHY chip which has quad-phy. > > I think everybody agrees these are terrible names, being so close > together but being very different devices. > > You have the issues of not giving clear explanations of your > hardware. This is resulting in a lot of wasted tome for everybody. S > please make your explanations very clear. I personally would avoid > using APQ8084 or QCA8084 on there own. Always say the application SoC > APQ8084, or the PHY chip QCA8084, or the switch embedded within the > application processor APQ8084, or the PHYs embedded within the > Application processor etc. This is particularly important when talking > about clocks and resets, since the PHYs embedded within the > application processor are likely to have different clocks and reset > controllers to the PHY chip QCA8084. > > Andrew Let me explain it more. APQ8084 is the Snapdragon SoC(for smart phone or other applicaiton) according to the link below. https://www.qualcomm.com/products/mobile/snapdragon/smartphones/snapdragon-8-series-mobile-platforms/snapdragon-processors-805. which has nothing to do with QCA8084 or IPQ SoC we are discussing here. let's remove out the APQ SoC from the discussion here. 1. For IPQ SoC series, there are only ipq4019, ipq5018, ipq6018, ipq8074 documented in the current dt-bindings doc qcom,ipq4019-mdio.yaml and ipq9574, ipq5332 that are being added by the MDIO patch, and one more ipq8064 whose MDIO driver is mdio-ipq8064.c, on more others. 2. For qca8084(pure PHY chip), which is the quad-phy chip, which is just like qca8081 PHY(single port PHY), each port can be linked to maximum speed 2.5G. For qca8386(switch chip), which includes the same PHY CHIP as qca8084 (4 physical ports and two CPU ports), qca8386 switch can work with the current qca8k.c DSA driver with the supplement patches. Both qca8084 and qca8386 includes same network clock controller(let's call it NSSCC, since this clock controller is located in the Ethernet chip qca8084 and qca8386), they have the same clock initial configuration sequence to initialize the Ethernet chip. The Ethernet chip qca8084 and qca8386 are only connected with IPQ SoC, Currently qca8084 is connected with IPQ SoC by 10G-QXGMII mode. the 4 PHYs of qca8386 are connected with the internal MAC of qca8386 by GMII, the maximum speed is also 2.5G. The port4 of qca8084 or qca8386 is optionally be able to connected with IPQ SoC by sgmii.
> 1. For IPQ SoC series, there are only ipq4019, ipq5018, ipq6018, > ipq8074 documented in the current dt-bindings doc qcom,ipq4019-mdio.yaml > and ipq9574, ipq5332 that are being added by the MDIO patch, and one > more ipq8064 whose MDIO driver is mdio-ipq8064.c, on more others. > > 2. For qca8084(pure PHY chip), which is the quad-phy chip, which is just > like qca8081 PHY(single port PHY), each port can be linked to maximum > speed 2.5G. > > For qca8386(switch chip), which includes the same PHY CHIP as qca8084 > (4 physical ports and two CPU ports), qca8386 switch can work with > the current qca8k.c DSA driver with the supplement patches. Is the qca8386 purely a switch plus integrated PHYs? There is no CPU on it? What is the management path? MDIO? > > Both qca8084 and qca8386 includes same network clock controller(let's > call it NSSCC, since this clock controller is located in the > Ethernet chip qca8084 and qca8386), they have the same clock initial > configuration sequence to initialize the Ethernet chip. You said For "qca8084(pure PHY chip)". Here you just called it an Ethernet chip? To me, and Ethernet chip is a MAC, Intel e1000e etc. Do you now see how your explanations are confusing. Is it s pure PHY, or is it an Ethernet chip? O.K. Since we are getting nowhere at the moment, lets take just the pure PHY chip, and ignore the rest for the moment. For any pure PHY, there is generally one clock input, which might be a crystal, or an actual clock. If you look at other DT bindings for PHYs, it is only listed if the clock is expected to come from somewhere else, like a SoC, and it needs to be turned on before the PHY will work. And generally, a pure PHY has one defined clock frequency input. If that is true, there is no need to specify the clock. If multiple clock input frequencies are supported, then you do need to specify the clock, so its possible to work out what frequency it is using. How that clock input is then used internally in the PHY is not described in DT, but the driver can set any dividers, PLLs needed etc. So, for the pure PHY chip, what is the pinout? Is there one clock input? Or 4 clock inputs, one per PHY in the quad package? Typically, where does this/these clocks come from? Is the frequency fixed by the design, or are a number of input frequencies supported? > The Ethernet chip qca8084 and qca8386 are only connected with IPQ SoC, > Currently qca8084 is connected with IPQ SoC by 10G-QXGMII mode. > the 4 PHYs of qca8386 are connected with the internal MAC of qca8386 > by GMII, the maximum speed is also 2.5G. > The port4 of qca8084 or qca8386 is optionally be able to connected > with IPQ SoC by sgmii. To some extent, this does not matter. The DT binding and the driver should not care what the pure PHY is connected to. It has standardised ports, so in theory it could be connected to any vendors MAC. Please be very careful with your wording. Because computers instructions should be unambiguous, it does what it is told, we also expect computer scientists to be unambiguous. Wording is very important. Andrew
On 1/4/2024 9:57 PM, Andrew Lunn wrote: >> 1. For IPQ SoC series, there are only ipq4019, ipq5018, ipq6018, >> ipq8074 documented in the current dt-bindings doc qcom,ipq4019-mdio.yaml >> and ipq9574, ipq5332 that are being added by the MDIO patch, and one >> more ipq8064 whose MDIO driver is mdio-ipq8064.c, on more others. >> >> 2. For qca8084(pure PHY chip), which is the quad-phy chip, which is just >> like qca8081 PHY(single port PHY), each port can be linked to maximum >> speed 2.5G. >> >> For qca8386(switch chip), which includes the same PHY CHIP as qca8084 >> (4 physical ports and two CPU ports), qca8386 switch can work with >> the current qca8k.c DSA driver with the supplement patches. > > Is the qca8386 purely a switch plus integrated PHYs? There is no CPU > on it? What is the management path? MDIO? Yes, qca8386 is a pure switch plus integrated PHYs(same PHY type as qca8084), there is no CPU on qca8386, the management path is MDIO. the access of switch register is by the multiple MDIO operations. > >> >> Both qca8084 and qca8386 includes same network clock controller(let's >> call it NSSCC, since this clock controller is located in the >> Ethernet chip qca8084 and qca8386), they have the same clock initial >> configuration sequence to initialize the Ethernet chip. > > You said For "qca8084(pure PHY chip)". Here you just called it an > Ethernet chip? To me, and Ethernet chip is a MAC, Intel e1000e etc. > Do you now see how your explanations are confusing. Is it s pure PHY, > or is it an Ethernet chip? My bad, sorry for this confusion. qca8084 is a pure PHY, there is no MAC in qca8084. > > O.K. Since we are getting nowhere at the moment, lets take just the > pure PHY chip, and ignore the rest for the moment. > > For any pure PHY, there is generally one clock input, which might be a > crystal, or an actual clock. If you look at other DT bindings for > PHYs, it is only listed if the clock is expected to come from > somewhere else, like a SoC, and it needs to be turned on before the > PHY will work. And generally, a pure PHY has one defined clock > frequency input. If that is true, there is no need to specify the > clock. If multiple clock input frequencies are supported, then you do > need to specify the clock, so its possible to work out what frequency > it is using. How that clock input is then used internally in the PHY > is not described in DT, but the driver can set any dividers, PLLs > needed etc. Yes, Andrew, there is only one clock input to qca8084(same as qca8386), this input clock rate is 50MHZ, which is from the output clock of CMN PLL block that is configured by the MDIO bus driver patch under review. In qca8084(same as qca8386), there is a clock controller, let's call it as NSSCC, the logic of NSSCC is same as qualcomm GCC(located in SoC), the NSSCC provides the clocks to the quad PHYs, the initial clocks for quad PHYs need to be configured before PHY to work. These clocks and resets are provided by the NSSCC provider driver, i need to define these clocks and resets in DT to use it. > > So, for the pure PHY chip, what is the pinout? Is there one clock > input? Or 4 clock inputs, one per PHY in the quad package? Typically, > where does this/these clocks come from? Is the frequency fixed by the > design, or are a number of input frequencies supported? There is one 50M clock input for qca8084(same as qca8386), the input clock is generated from the CMN PLL block that is configured by MDIO driver patch of mdio-ipq4019.c. The frequency of input clock is fixed to 50MHZ. > >> The Ethernet chip qca8084 and qca8386 are only connected with IPQ SoC, >> Currently qca8084 is connected with IPQ SoC by 10G-QXGMII mode. >> the 4 PHYs of qca8386 are connected with the internal MAC of qca8386 >> by GMII, the maximum speed is also 2.5G. >> The port4 of qca8084 or qca8386 is optionally be able to connected >> with IPQ SoC by sgmii. > > To some extent, this does not matter. The DT binding and the driver > should not care what the pure PHY is connected to. It has standardised > ports, so in theory it could be connected to any vendors MAC. Yes, it can be connected with any vendors MAC with the interface mode supported. > > Please be very careful with your wording. Because computers > instructions should be unambiguous, it does what it is told, we also > expect computer scientists to be unambiguous. Wording is very > important. > > Andrew Got it. Thanks Andrew for the comments and suggestions.
> > O.K. Since we are getting nowhere at the moment, lets take just the > > pure PHY chip, and ignore the rest for the moment. > > > > For any pure PHY, there is generally one clock input, which might be a > > crystal, or an actual clock. If you look at other DT bindings for > > PHYs, it is only listed if the clock is expected to come from > > somewhere else, like a SoC, and it needs to be turned on before the > > PHY will work. And generally, a pure PHY has one defined clock > > frequency input. If that is true, there is no need to specify the > > clock. If multiple clock input frequencies are supported, then you do > > need to specify the clock, so its possible to work out what frequency > > it is using. How that clock input is then used internally in the PHY > > is not described in DT, but the driver can set any dividers, PLLs > > needed etc. > > Yes, Andrew, there is only one clock input to qca8084(same as qca8386), > this input clock rate is 50MHZ, which is from the output clock of CMN > PLL block that is configured by the MDIO bus driver patch under review. Lets concentrate on the pure PHY. All it sees is a clock. It does not care where it come from. All you need in the device tree for the pure PHY is a clock consumer. There is one clock input, so its shared by all four instances in the pure PHY package. So you need to use Christians code which extends the PHY DT bindings to allow DT properties for a package of PHYs. What about resets. Is there one reset pin for the pure PHY package, or one per PHY? Go find Christians code, understand it, and propose a DT binding for the pure PHY. Include the clock provider and the reset provider. Forget about the MDIO controller, and the PHY integrated into the switch, etc. Baby steps... > In qca8084(same as qca8386), there is a clock controller, let's call it > as NSSCC, the logic of NSSCC is same as qualcomm GCC(located in SoC), > the NSSCC provides the clocks to the quad PHYs, the initial clocks for > quad PHYs need to be configured before PHY to work. You said above, there is one clock input to the qca8084. Here you use the word clocks, plural. Is there one clock, or multiple clocks? Andrew
On 1/5/2024 9:37 PM, Andrew Lunn wrote: >>> O.K. Since we are getting nowhere at the moment, lets take just the >>> pure PHY chip, and ignore the rest for the moment. >>> >>> For any pure PHY, there is generally one clock input, which might be a >>> crystal, or an actual clock. If you look at other DT bindings for >>> PHYs, it is only listed if the clock is expected to come from >>> somewhere else, like a SoC, and it needs to be turned on before the >>> PHY will work. And generally, a pure PHY has one defined clock >>> frequency input. If that is true, there is no need to specify the >>> clock. If multiple clock input frequencies are supported, then you do >>> need to specify the clock, so its possible to work out what frequency >>> it is using. How that clock input is then used internally in the PHY >>> is not described in DT, but the driver can set any dividers, PLLs >>> needed etc. >> >> Yes, Andrew, there is only one clock input to qca8084(same as qca8386), >> this input clock rate is 50MHZ, which is from the output clock of CMN >> PLL block that is configured by the MDIO bus driver patch under review. > > Lets concentrate on the pure PHY. All it sees is a clock. It does not > care where it come from. All you need in the device tree for the pure > PHY is a clock consumer. Yes. > > There is one clock input, so its shared by all four instances in the > pure PHY package. So you need to use Christians code which extends the > PHY DT bindings to allow DT properties for a package of PHYs. OK, will > > What about resets. Is there one reset pin for the pure PHY package, or > one per PHY? There is only one GPIO hardware reset PIN for the chip qca8084 including all 4 PHYs. > > Go find Christians code, understand it, and propose a DT binding for > the pure PHY. Include the clock provider and the reset > provider. Forget about the MDIO controller, and the PHY integrated > into the switch, etc. Baby steps... Thanks Andrew for pointing me the Christians code, i will keep the driver of qca8084 synced with Christian's code before pushing the next patch set. > >> In qca8084(same as qca8386), there is a clock controller, let's call it >> as NSSCC, the logic of NSSCC is same as qualcomm GCC(located in SoC), >> the NSSCC provides the clocks to the quad PHYs, the initial clocks for >> quad PHYs need to be configured before PHY to work. > > You said above, there is one clock input to the qca8084. Here you use > the word clocks, plural. Is there one clock, or multiple clocks? > > Andrew Yes, Andrew, it is multiple clocks. These multiple clocks are generated(PLL, divider) and used internally by qca8084 CHIP, these clocks are generated by the clock controller of qca8084, let's call the clock controller of qca8084 as NSSCC provider, which generates the clocks to the PHYs, this NSSCC is located in qca8084. The only one input clock of qca8084 is the clock source of the chip qca8084, which is fixed to 50MHZ. The NSSCC of qca8084 generates different clock rates for the different link speed of the PHY, which is the internal block of qca8084.
diff --git a/Documentation/devicetree/bindings/net/qca,ar803x.yaml b/Documentation/devicetree/bindings/net/qca,ar803x.yaml index 3acd09f0da86..febff039a44f 100644 --- a/Documentation/devicetree/bindings/net/qca,ar803x.yaml +++ b/Documentation/devicetree/bindings/net/qca,ar803x.yaml @@ -14,9 +14,6 @@ maintainers: description: | Bindings for Qualcomm Atheros AR803x PHYs -allOf: - - $ref: ethernet-phy.yaml# - properties: qca,clk-out-frequency: description: Clock output frequency in Hertz. @@ -85,6 +82,161 @@ properties: $ref: /schemas/regulator/regulator.yaml unevaluatedProperties: false + qcom,phy-addr-fixup: + $ref: /schemas/types.yaml#/definitions/uint32-array + description: + MDIO address for 4 PHY devices and 3 PCS devices + + qcom,phy-work-mode: + description: PHY device work mode. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3] + + clocks: + items: + - description: APB bridge clock + - description: AHB clock + - description: Security control clock + - description: TLMM clock + - description: TLMM AHB clock + - description: CNOC AHB clock + - description: MDIO AHB clock + - description: MDIO master AHB clock + - description: PCS0 system clock + - description: PCS1 system clock + - description: EPHY0 system clock + - description: EPHY1 system clock + - description: EPHY2 system clock + - description: EPHY3 system clock + description: PHY initial common clock configs + + clock-names: + items: + - const: apb_bridge + - const: ahb + - const: sec_ctrl_ahb + - const: tlmm + - const: tlmm_ahb + - const: cnoc_ahb + - const: mdio_ahb + - const: mdio_master_ahb + - const: srds0_sys + - const: srds1_sys + - const: gephy0_sys + - const: gephy1_sys + - const: gephy2_sys + - const: gephy3_sys + + resets: + items: + - description: PCS0 system reset + - description: PCS1 system reset + - description: EPHY0 system reset + - description: EPHY1 system reset + - description: EPHY2 system reset + - description: EPHY3 system reset + - description: EPHY0 software reset + - description: EPHY1 software reset + - description: EPHY2 software reset + - description: EPHY3 software reset + - description: Ethernet DSP reset + description: PHY initial common reset configs + + reset-names: + items: + - const: srds0_sys + - const: srds1_sys + - const: gephy0_sys + - const: gephy1_sys + - const: gephy2_sys + - const: gephy3_sys + - const: gephy0_soft + - const: gephy1_soft + - const: gephy2_soft + - const: gephy3_soft + - const: gephy_dsp + +allOf: + - $ref: ethernet-phy.yaml# + + - if: + properties: + compatible: + contains: + enum: + - ethernet-phy-id004d.d180 + then: + properties: + clocks: + items: + - description: APB bridge clock + - description: AHB clock + - description: Security control clock + - description: TLMM clock + - description: TLMM AHB clock + - description: CNOC AHB clock + - description: MDIO AHB clock + - description: MDIO master AHB clock + - description: PCS0 system clock + - description: PCS1 system clock + - description: EPHY0 system clock + - description: EPHY1 system clock + - description: EPHY2 system clock + - description: EPHY3 system clock + clock-names: + items: + - const: apb_bridge + - const: ahb + - const: sec_ctrl_ahb + - const: tlmm + - const: tlmm_ahb + - const: cnoc_ahb + - const: mdio_ahb + - const: mdio_master_ahb + - const: srds0_sys + - const: srds1_sys + - const: gephy0_sys + - const: gephy1_sys + - const: gephy2_sys + - const: gephy3_sys + resets: + items: + - description: PCS0 system reset + - description: PCS1 system reset + - description: EPHY0 system reset + - description: EPHY1 system reset + - description: EPHY2 system reset + - description: EPHY3 system reset + - description: EPHY0 software reset + - description: EPHY1 software reset + - description: EPHY2 software reset + - description: EPHY3 software reset + - description: Ethernet DSP reset + reset-names: + items: + - const: srds0_sys + - const: srds1_sys + - const: gephy0_sys + - const: gephy1_sys + - const: gephy2_sys + - const: gephy3_sys + - const: gephy0_soft + - const: gephy1_soft + - const: gephy2_soft + - const: gephy3_soft + - const: gephy_dsp + required: + - qcom,phy-addr-fixup + - qcom,phy-work-mode + - clocks + - clock-names + - resets + - reset-names + else: + properties: + qcom,phy-addr-fixup: false + qcom,phy-work-mode: false + unevaluatedProperties: false examples:
The following properties are added for qca8084 PHY. 1. add the compatible string "ethernet-phy-id004d.d180" since the PHY device is not accessible during MDIO bus register. 2. add property "qcom,phy-addr-fixup" for customizing MDIO address. 3. add property "qcom,phy-work-mode" for specifying qca8084 PHY work mode. 4. add the initial clocks and resets. Signed-off-by: Luo Jie <quic_luoj@quicinc.com> --- .../devicetree/bindings/net/qca,ar803x.yaml | 158 +++++++++++++++++- 1 file changed, 155 insertions(+), 3 deletions(-)