From: Peter Geis <hidden> Date: 2021-04-14 11:03:42
On Tue, Apr 13, 2021 at 7:37 PM Ezequiel Garcia [off-list ref] wrote:
On Tuesday, April 13, 2021 19:51 -03, Peter Geis [off-list ref] wrote:
quoted
On Tue, Apr 13, 2021 at 5:03 PM Ezequiel Garcia [off-list ref] wrote:
quoted
From: David Wu <redacted>
Add constants and callback functions for the dwmac present
on RK3566 and RK3568 SoCs. As can be seen, the base structure
is the same, only registers and the bits in them moved slightly.
RK3568 supports two MACs, and RK3566 support just one.
Tested this driver on the rk3566-quartz64.
It fails to fully probe the gmac with the following error:
[ 5.711127] rk_gmac-dwmac fe010000.ethernet: IRQ eth_lpi not found
[ 5.714147] rk_gmac-dwmac fe010000.ethernet: no regulator found
[ 5.714766] rk_gmac-dwmac fe010000.ethernet: clock input or output? (input).
[ 5.715474] rk_gmac-dwmac fe010000.ethernet: TX delay(0x4f).
[ 5.716058] rk_gmac-dwmac fe010000.ethernet: RX delay(0x25).
[ 5.716694] rk_gmac-dwmac fe010000.ethernet: integrated PHY? (no).
[ 5.718413] rk_gmac-dwmac fe010000.ethernet: clock input from PHY
[ 5.724140] rk_gmac-dwmac fe010000.ethernet: init for RGMII
[ 5.726802] rk_gmac-dwmac fe010000.ethernet: Version ID not available
[ 5.727525] rk_gmac-dwmac fe010000.ethernet: DWMAC1000
[ 5.728064] rk_gmac-dwmac fe010000.ethernet: DMA HW capability
register supported
[ 5.729026] rk_gmac-dwmac fe010000.ethernet: Normal descriptors
[ 5.729624] rk_gmac-dwmac fe010000.ethernet: Ring mode enabled
[ 5.731123] rk_gmac-dwmac fe010000.ethernet: Unbalanced pm_runtime_enable!
[ 5.873329] libphy: stmmac: probed
[ 5.905599] rk_gmac-dwmac fe010000.ethernet: Cannot register the MDIO bus
[ 5.906335] rk_gmac-dwmac fe010000.ethernet: stmmac_dvr_probe: MDIO
bus (id: 1) registration failed
[ 5.914338] rk_gmac-dwmac: probe of fe010000.ethernet failed with error -5
This is due to the lack of setting has_gmac4 = true.
You are probably missing a "snps,dwmac-4.20a" in your compatible string, i.e.:
compatible = "rockchip,rk3566-gmac", "snps,dwmac-4.20a";
Ah yes, I had disabled that because my variant took a different path.
Thanks!
This seems to be common practice, judging from arch/arm/boot/dts/stm32***.
Let me know how that goes!
Ezequiel
@@ -12,6 +12,8 @@ Required properties: "rockchip,rk3366-gmac": found on RK3366 SoCs "rockchip,rk3368-gmac": found on RK3368 SoCs "rockchip,rk3399-gmac": found on RK3399 SoCs+ "rockchip,rk3566-gmac": found on RK3566 SoCs+ "rockchip,rk3568-gmac": found on RK3568 SoCs "rockchip,rv1108-gmac": found on RV1108 SoCs - reg: addresses and length of the register sets for the device. - interrupts: Should contain the GMAC interrupts.
Since there are two GMACs on the rk3568, and either, or, or both may
be enabled in various configurations, we should only configure the
controller we are currently operating.
Perhaps we should have match data (such as reg = <0>, or against the
address) to identify the individual controllers.
Since there are two GMACs on the rk3568, and either, or, or both may
be enabled in various configurations, we should only configure the
controller we are currently operating.
Perhaps we should have match data (such as reg = <0>, or against the
address) to identify the individual controllers.
Since there are two GMACs on the rk3568, and either, or, or both may
be enabled in various configurations, we should only configure the
controller we are currently operating.
Perhaps we should have match data (such as reg = <0>, or against the
address) to identify the individual controllers.
I have to admit, I'm not a fan of hardcoding the registers in the kernel.
David Wu solved this in the downstream kernel by using bus_id,
which parses the devicetree "ethernet@0" node, i.e.:
plat->bus_id = of_alias_get_id(np, "ethernet");
I'm inclined for this solution. Maybe Jose can suggest how to approach it?
Thanks!
Ezequiel
On Wed, 2021-04-14 at 07:03 -0400, Peter Geis wrote:
On Tue, Apr 13, 2021 at 7:37 PM Ezequiel Garcia [off-list ref] wrote:
quoted
On Tuesday, April 13, 2021 19:51 -03, Peter Geis [off-list ref] wrote:
quoted
On Tue, Apr 13, 2021 at 5:03 PM Ezequiel Garcia [off-list ref] wrote:
quoted
From: David Wu <redacted>
Add constants and callback functions for the dwmac present
on RK3566 and RK3568 SoCs. As can be seen, the base structure
is the same, only registers and the bits in them moved slightly.
RK3568 supports two MACs, and RK3566 support just one.
Tested this driver on the rk3566-quartz64.
It fails to fully probe the gmac with the following error:
[ 5.711127] rk_gmac-dwmac fe010000.ethernet: IRQ eth_lpi not found
[ 5.714147] rk_gmac-dwmac fe010000.ethernet: no regulator found
[ 5.714766] rk_gmac-dwmac fe010000.ethernet: clock input or output? (input).
[ 5.715474] rk_gmac-dwmac fe010000.ethernet: TX delay(0x4f).
[ 5.716058] rk_gmac-dwmac fe010000.ethernet: RX delay(0x25).
[ 5.716694] rk_gmac-dwmac fe010000.ethernet: integrated PHY? (no).
[ 5.718413] rk_gmac-dwmac fe010000.ethernet: clock input from PHY
[ 5.724140] rk_gmac-dwmac fe010000.ethernet: init for RGMII
[ 5.726802] rk_gmac-dwmac fe010000.ethernet: Version ID not available
[ 5.727525] rk_gmac-dwmac fe010000.ethernet: DWMAC1000
[ 5.728064] rk_gmac-dwmac fe010000.ethernet: DMA HW capability
register supported
[ 5.729026] rk_gmac-dwmac fe010000.ethernet: Normal descriptors
[ 5.729624] rk_gmac-dwmac fe010000.ethernet: Ring mode enabled
[ 5.731123] rk_gmac-dwmac fe010000.ethernet: Unbalanced pm_runtime_enable!
[ 5.873329] libphy: stmmac: probed
[ 5.905599] rk_gmac-dwmac fe010000.ethernet: Cannot register the MDIO bus
[ 5.906335] rk_gmac-dwmac fe010000.ethernet: stmmac_dvr_probe: MDIO
bus (id: 1) registration failed
[ 5.914338] rk_gmac-dwmac: probe of fe010000.ethernet failed with error -5
This is due to the lack of setting has_gmac4 = true.
You are probably missing a "snps,dwmac-4.20a" in your compatible string, i.e.:
compatible = "rockchip,rk3566-gmac", "snps,dwmac-4.20a";
Ah yes, I had disabled that because my variant took a different path.
Thanks!
Since there are two GMACs on the rk3568, and either, or, or both may
be enabled in various configurations, we should only configure the
controller we are currently operating.
Perhaps we should have match data (such as reg = <0>, or against the
address) to identify the individual controllers.
I have to admit, I'm not a fan of hardcoding the registers in the kernel.
David Wu solved this in the downstream kernel by using bus_id,
which parses the devicetree "ethernet@0" node, i.e.:
plat->bus_id = of_alias_get_id(np, "ethernet");
What happens when one adds another ethernet controller (USB or PCIe) to
the board and wants to change the numbering order?
Or maybe only the second ethernet controller is routed on some board
and the submitter / vendor wants that one to be ethernet0, because
it's the only usable controller?
This seems even more fragile than hardcoding the registers.
Regards
ChenYu
Since there are two GMACs on the rk3568, and either, or, or both may
be enabled in various configurations, we should only configure the
controller we are currently operating.
Perhaps we should have match data (such as reg = <0>, or against the
address) to identify the individual controllers.
I have to admit, I'm not a fan of hardcoding the registers in the kernel.
David Wu solved this in the downstream kernel by using bus_id,
which parses the devicetree "ethernet@0" node, i.e.:
plat->bus_id = of_alias_get_id(np, "ethernet");
What happens when one adds another ethernet controller (USB or PCIe) to
the board and wants to change the numbering order?
Or maybe only the second ethernet controller is routed on some board
and the submitter / vendor wants that one to be ethernet0, because
it's the only usable controller?
Which matches a discussion I had with Arnd about the mmc numbering.
I.e. there the first mmc device is supposed to be mmc0 and so on,
without gaps - for probably the same reasons.
This seems even more fragile than hardcoding the registers.
Regards
ChenYu
Since there are two GMACs on the rk3568, and either, or, or both may
be enabled in various configurations, we should only configure the
controller we are currently operating.
Perhaps we should have match data (such as reg = <0>, or against the
address) to identify the individual controllers.
I have to admit, I'm not a fan of hardcoding the registers in the kernel.
David Wu solved this in the downstream kernel by using bus_id,
which parses the devicetree "ethernet@0" node, i.e.:
plat->bus_id = of_alias_get_id(np, "ethernet");
What happens when one adds another ethernet controller (USB or PCIe) to
the board and wants to change the numbering order?
Or maybe only the second ethernet controller is routed on some board
and the submitter / vendor wants that one to be ethernet0, because
it's the only usable controller?
Which matches a discussion I had with Arnd about the mmc numbering.
I.e. there the first mmc device is supposed to be mmc0 and so on,
without gaps - for probably the same reasons.
Well, given each controller has its own register space, maybe
just model it with a new reg cell or a DT property that is able
to directly encode the base address?
Looking at the vendor kernel, XPCS will have another set of registers,
separate for each MAC.
Thanks,
Ezequiel
quoted
This seems even more fragile than hardcoding the registers.
Regards
ChenYu