[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<SEZPR06MB69599F74D3C7D2B7705C9DA7964C2@SEZPR06MB6959.apcprd06.prod.outlook.com>
Date: Fri, 16 Feb 2024 21:33:17 +0800
From: Yang Xiwen <forbidden405@...look.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: Yisen Zhuang <yisen.zhuang@...wei.com>,
Salil Mehta <salil.mehta@...wei.com>, "David S. Miller"
<davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Conor Dooley <conor+dt@...nel.org>, Yang Xiwen <forbidden405@...mail.com>,
Heiner Kallweit <hkallweit1@...il.com>, Russell King
<linux@...linux.org.uk>, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH 4/6] dt-bindings: net: add hisilicon-femac
On 2/16/2024 9:11 PM, Andrew Lunn wrote:
>> + femac: ethernet@...0000 {
>> + compatible = "hisilicon,hi3798mv200-femac";
>> + reg = <0x9c30000 0x1000>, <0x9c31300 0x200>;
>> + ranges = <0x0 0x9c30000 0x10000>;
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>;
>> + clocks = <&crg HISTB_ETH0_MAC_CLK>,
>> + <&crg HISTB_ETH0_MACIF_CLK>,
>> + <&crg HISTB_ETH0_PHY_CLK>;
>> + clock-names = "mac", "macif", "phy";
>> + resets = <&crg 0xd0 3>, <&crg 0x388 4>;
>> + reset-names = "mac", "phy";
>> + phy-handle = <&fephy>;
>> + phy-connection-type = "mii";
>> + // To be filled by bootloader
>> + mac-address = [00 00 00 00 00 00];
>> + hisilicon,phy-reset-delays-us = <10000 10000 500000>;
>> + status = "okay";
>> +
>> + mdio: mdio@...0 {
>> + compatible = "hisilicon,hisi-femac-mdio";
> Is the MDIO bus master a device of its own? Is this compatible
> actually used anywhere?
>
> There are generally two different ways an MDIO bus master works. It is
> an individual device, with its own register space and it gets probed
> as an independent device. In this case, it needs a compatible to
> indicate what driver should be used.
>
> Or the MDIO bus master is embedded within a MAC driver. It shares the
> register space with the MAC driver. It is not a device which gets
> probed, and so it does not need a compatible. The MAC drivers
> compatible is sufficient.
I guess this is the main difference between the old "hi3516dv300-femac"
and the new "hi3798mv200-femac".
The old binding says there are individual clocks for MDIO bus and MAC
for hi3516. But according to my test, it's not true for hi3798mv200.
I've tried accessing MDIO address space and MAC controller address space
in u-boot with `md` and `mw` [1]. From the result, i guess the CLK_BUS
is the System Bus clock (AHB Bus clock), and the CLK_MAC is the clock
shared by both MDIO bus and MAC. The MAC has a internal clock divider to
divide the input clock(54MHz in common) to a configurable variable rate.
Due to the fact that MDIO bus address space is inside MAC address space
( MAC is at `f9c30000- f9c40000`, MDIO bus is at `f9c31100-f9c31120` ).
The only thing i can tell it's inside the SoC, but i can't say it's 100%
completely integrated to the MAC controller, though highly possible.
[1]: the result is summarized below, `md f9c31300` in u-boot is used to
poke the register values:
CLK_BUS | CLK_MAC | register values
Off | Off | All zero
Off | On | All zero
On | Off | System Hangs
On | On | All okay
>
> Andrew
--
Regards,
Yang Xiwen
Powered by blists - more mailing lists