| Message ID | 20250216123953.1252523-4-inochiama@gmail.com (mailing list archive) |
|---|---|
| State | Changes Requested |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | riscv: sophgo: Add ethernet support for SG2044 | expand |
On Sun, Feb 16, 2025 at 08:39:51PM +0800, Inochi Amaoto wrote: > +static void sophgo_dwmac_fix_mac_speed(void *priv, unsigned int speed, unsigned int mode) > +{ > + struct sophgo_dwmac *dwmac = priv; > + long rate; > + int ret; > + > + rate = rgmii_clock(speed); > + if (rate < 0) { > + dev_err(dwmac->dev, "invalid speed %u\n", speed); > + return; > + } > + > + ret = clk_set_rate(dwmac->clk_tx, rate); > + if (ret) > + dev_err(dwmac->dev, "failed to set tx rate %ld: %pe\n", > + rate, ERR_PTR(ret)); > +} There are a bunch of other platform support in stmmac that are doing the same: dwmac-s32.c is virtually identical dwmac-imx.c does the same, although has some pre-conditions dwmac-dwc-qos-eth.c is virually identical but the two steps are split across a bunch of register writes dwmac-starfive.c looks the same dwmac-rk.c also dwmac-intel-plat.c also So, I wonder whether either this should be a helper, or whether core code should be doing this. Maybe something to look at as a part of this patch submission? We really need to stop writing the same code in different ways and think more about how to reuse the code that's already present!
On Sun, Feb 16, 2025 at 03:47:18PM +0000, Russell King (Oracle) wrote: > On Sun, Feb 16, 2025 at 08:39:51PM +0800, Inochi Amaoto wrote: > > +static void sophgo_dwmac_fix_mac_speed(void *priv, unsigned int speed, unsigned int mode) > > +{ > > + struct sophgo_dwmac *dwmac = priv; > > + long rate; > > + int ret; > > + > > + rate = rgmii_clock(speed); > > + if (rate < 0) { > > + dev_err(dwmac->dev, "invalid speed %u\n", speed); > > + return; > > + } > > + > > + ret = clk_set_rate(dwmac->clk_tx, rate); > > + if (ret) > > + dev_err(dwmac->dev, "failed to set tx rate %ld: %pe\n", > > + rate, ERR_PTR(ret)); > > +} > > There are a bunch of other platform support in stmmac that are doing > the same: > > dwmac-s32.c is virtually identical > dwmac-imx.c does the same, although has some pre-conditions > dwmac-dwc-qos-eth.c is virually identical but the two steps are split > across a bunch of register writes > dwmac-starfive.c looks the same > dwmac-rk.c also > dwmac-intel-plat.c also > > So, I wonder whether either this should be a helper, or whether core > code should be doing this. Maybe something to look at as a part of > this patch submission? Inochi, please could you look at the datasheet for this IP. Is the transmit clock a part of the IP? Can we expect all devices integrating this IP to have such a clock? That would be a good indicator the clock handling should be moved into the core. Andrew
On Sun, Feb 16, 2025 at 06:07:05PM +0100, Andrew Lunn wrote: > On Sun, Feb 16, 2025 at 03:47:18PM +0000, Russell King (Oracle) wrote: > > On Sun, Feb 16, 2025 at 08:39:51PM +0800, Inochi Amaoto wrote: > > > +static void sophgo_dwmac_fix_mac_speed(void *priv, unsigned int speed, unsigned int mode) > > > +{ > > > + struct sophgo_dwmac *dwmac = priv; > > > + long rate; > > > + int ret; > > > + > > > + rate = rgmii_clock(speed); > > > + if (rate < 0) { > > > + dev_err(dwmac->dev, "invalid speed %u\n", speed); > > > + return; > > > + } > > > + > > > + ret = clk_set_rate(dwmac->clk_tx, rate); > > > + if (ret) > > > + dev_err(dwmac->dev, "failed to set tx rate %ld: %pe\n", > > > + rate, ERR_PTR(ret)); > > > +} > > > > There are a bunch of other platform support in stmmac that are doing > > the same: > > > > dwmac-s32.c is virtually identical > > dwmac-imx.c does the same, although has some pre-conditions > > dwmac-dwc-qos-eth.c is virually identical but the two steps are split > > across a bunch of register writes > > dwmac-starfive.c looks the same > > dwmac-rk.c also > > dwmac-intel-plat.c also > > > > So, I wonder whether either this should be a helper, or whether core > > code should be doing this. Maybe something to look at as a part of > > this patch submission? > > Inochi, please could you look at the datasheet for this IP. Is the > transmit clock a part of the IP? I checked the ip databook and found it is part of the RGMII clock. Also, I found RGMII also contains a rx clock following this quirk. > Can we expect all devices integrating this IP to have such a clock? > That would be a good indicator the clock handling should be moved > into the core. > I am not sure all whether devices has this clock, but it appears in the databook. So I think it is possible to move this in the core so any platform with these clock can reuse it. Regards, Inochi
> I am not sure all whether devices has this clock, but it appears in > the databook. So I think it is possible to move this in the core so > any platform with these clock can reuse it. Great The next problem will be, has everybody called it the same thing in DT. Since there has been a lot of cut/paste, maybe they have, by accident. Thanks Andrew
On Mon, Feb 17, 2025 at 02:25:33PM +0100, Andrew Lunn wrote: > > I am not sure all whether devices has this clock, but it appears in > > the databook. So I think it is possible to move this in the core so > > any platform with these clock can reuse it. > > Great > > The next problem will be, has everybody called it the same thing in > DT. Since there has been a lot of cut/paste, maybe they have, by > accident. Tegra186: "tx" imx: "tx" intel: "tx_clk" rk: "clk_mac_speed" s32: "tx" starfive: "tx" sti: "sti-ethclk" so 50% have settled on "tx" and the rest are doing their own thing, and that horse has already bolted. I have some ideas on sorting this out, and I'm working on some patches today.
On Mon, Feb 17, 2025 at 02:10:50PM +0000, Russell King (Oracle) wrote: > On Mon, Feb 17, 2025 at 02:25:33PM +0100, Andrew Lunn wrote: > > > I am not sure all whether devices has this clock, but it appears in > > > the databook. So I think it is possible to move this in the core so > > > any platform with these clock can reuse it. > > > > Great > > > > The next problem will be, has everybody called it the same thing in > > DT. Since there has been a lot of cut/paste, maybe they have, by > > accident. > > Tegra186: "tx" > imx: "tx" > intel: "tx_clk" > rk: "clk_mac_speed" > s32: "tx" > starfive: "tx" > sti: "sti-ethclk" > The dwc-qos-eth also use clock name "tx", but set the clock with extra calibration logic. > so 50% have settled on "tx" and the rest are doing their own thing, and > that horse has already bolted. > The "rx" clock in s32 also uses the same logic. I think the core also needs to take it, as this rx clock is also mentioned in the databook. > I have some ideas on sorting this out, and I'm working on some patches > today. Great, Could you cc me when you submit them? So I can take it and change my series. Regards, Inochi
On Tue, Feb 18, 2025 at 06:50:24AM +0800, Inochi Amaoto wrote: > On Mon, Feb 17, 2025 at 02:10:50PM +0000, Russell King (Oracle) wrote: > > On Mon, Feb 17, 2025 at 02:25:33PM +0100, Andrew Lunn wrote: > > > > I am not sure all whether devices has this clock, but it appears in > > > > the databook. So I think it is possible to move this in the core so > > > > any platform with these clock can reuse it. > > > > > > Great > > > > > > The next problem will be, has everybody called it the same thing in > > > DT. Since there has been a lot of cut/paste, maybe they have, by > > > accident. > > > > Tegra186: "tx" > > imx: "tx" > > intel: "tx_clk" > > rk: "clk_mac_speed" > > s32: "tx" > > starfive: "tx" > > sti: "sti-ethclk" > > > > The dwc-qos-eth also use clock name "tx", but set the clock with > extra calibration logic. Yep, that's what I meant by "Tegra186" above. > > so 50% have settled on "tx" and the rest are doing their own thing, and > > that horse has already bolted. > > > > The "rx" clock in s32 also uses the same logic. I think the core also > needs to take it, as this rx clock is also mentioned in the databook. The "rx" clock on s32 seems to only be set to 125MHz, and the driver seems to be limited to RGMII. This seems weird as the receive clock is supposed to be supplied by the PHY, and is recovered from the media (and thus will be 2.5, 25 or 125MHz as determined by the PHY.) So, I'm not sure that the s32 "rx" clock is really the clk_rx_i clock supplied to the DWMAC core. Certainly on stm32mp151, it states that ETH_RX_CLK in RGMII mode will be 2.5, 25 or 125MHz provided by the PHY, and the clock tree indicates that ETH_RX_CLK in RGMII mode will be routed directly to the clk_rx_i input on the DWMAC(4) core. > > I have some ideas on sorting this out, and I'm working on some patches > > today. > > Great, Could you cc me when you submit them? So I can take it and > change my series. Will do - I'm almost at that point, I have three other cleanup patches I will be sending before hand, so I'll send those out and then this series as RFC. The only platform drivers I've left with a call to rgmii_clock() are sti, imx (for imx93 only as that does extra fiddling after setting the clock and I'm not sure if there's an ordering dependency there) and the rk platforms. Five platforms converted, three not, and hopefully your platform can also use the helper as well!
On Mon, Feb 17, 2025 at 11:21:28PM +0000, Russell King (Oracle) wrote: > On Tue, Feb 18, 2025 at 06:50:24AM +0800, Inochi Amaoto wrote: > > On Mon, Feb 17, 2025 at 02:10:50PM +0000, Russell King (Oracle) wrote: > > > On Mon, Feb 17, 2025 at 02:25:33PM +0100, Andrew Lunn wrote: > > > > > I am not sure all whether devices has this clock, but it appears in > > > > > the databook. So I think it is possible to move this in the core so > > > > > any platform with these clock can reuse it. > > > > > > > > Great > > > > > > > > The next problem will be, has everybody called it the same thing in > > > > DT. Since there has been a lot of cut/paste, maybe they have, by > > > > accident. > > > > > > Tegra186: "tx" > > > imx: "tx" > > > intel: "tx_clk" > > > rk: "clk_mac_speed" > > > s32: "tx" > > > starfive: "tx" > > > sti: "sti-ethclk" > > > > > > > The dwc-qos-eth also use clock name "tx", but set the clock with > > extra calibration logic. > > Yep, that's what I meant by "Tegra186" above. > > > > so 50% have settled on "tx" and the rest are doing their own thing, and > > > that horse has already bolted. > > > > > > > The "rx" clock in s32 also uses the same logic. I think the core also > > needs to take it, as this rx clock is also mentioned in the databook. > > The "rx" clock on s32 seems to only be set to 125MHz, and the driver > seems to be limited to RGMII. > > This seems weird as the receive clock is supposed to be supplied by the > PHY, and is recovered from the media (and thus will be 2.5, 25 or > 125MHz as determined by the PHY.) So, I'm not sure that the s32 "rx" > clock is really the clk_rx_i clock supplied to the DWMAC core. > > Certainly on stm32mp151, it states that ETH_RX_CLK in RGMII mode will > be 2.5, 25 or 125MHz provided by the PHY, and the clock tree indicates > that ETH_RX_CLK in RGMII mode will be routed directly to the clk_rx_i > input on the DWMAC(4) core. > RGMII is not the problem. The databook says the RGMII clock (rx/tx) follows this set rate logic. For other things, I agree with you. A fixed "rx" clock does reach the limit of what I know. And the databook told nothing about it. As we can not determine the rx clock of s32 and it may be set for the phy, it will be better to not move it into the core. > > > I have some ideas on sorting this out, and I'm working on some patches > > > today. > > > > Great, Could you cc me when you submit them? So I can take it and > > change my series. > > Will do - I'm almost at that point, I have three other cleanup patches > I will be sending before hand, so I'll send those out and then this > series as RFC. > > The only platform drivers I've left with a call to rgmii_clock() are > sti, imx (for imx93 only as that does extra fiddling after setting the > clock and I'm not sure if there's an ordering dependency there) and > the rk platforms. > > Five platforms converted, three not, and hopefully your platform can > also use the helper as well! > I think my platform can fit. Thanks for your effort. Regards, Inochi
On Tue, Feb 18, 2025 at 09:01:59AM +0800, Inochi Amaoto wrote: > On Mon, Feb 17, 2025 at 11:21:28PM +0000, Russell King (Oracle) wrote: > > On Tue, Feb 18, 2025 at 06:50:24AM +0800, Inochi Amaoto wrote: > > > On Mon, Feb 17, 2025 at 02:10:50PM +0000, Russell King (Oracle) wrote: > > > > On Mon, Feb 17, 2025 at 02:25:33PM +0100, Andrew Lunn wrote: > > > > > > I am not sure all whether devices has this clock, but it appears in > > > > > > the databook. So I think it is possible to move this in the core so > > > > > > any platform with these clock can reuse it. > > > > > > > > > > Great > > > > > > > > > > The next problem will be, has everybody called it the same thing in > > > > > DT. Since there has been a lot of cut/paste, maybe they have, by > > > > > accident. > > > > > > > > Tegra186: "tx" > > > > imx: "tx" > > > > intel: "tx_clk" > > > > rk: "clk_mac_speed" > > > > s32: "tx" > > > > starfive: "tx" > > > > sti: "sti-ethclk" > > > > > > > > > > The dwc-qos-eth also use clock name "tx", but set the clock with > > > extra calibration logic. > > > > Yep, that's what I meant by "Tegra186" above. > > > > > > so 50% have settled on "tx" and the rest are doing their own thing, and > > > > that horse has already bolted. > > > > > > > > > > The "rx" clock in s32 also uses the same logic. I think the core also > > > needs to take it, as this rx clock is also mentioned in the databook. > > > > The "rx" clock on s32 seems to only be set to 125MHz, and the driver > > seems to be limited to RGMII. > > > > This seems weird as the receive clock is supposed to be supplied by the > > PHY, and is recovered from the media (and thus will be 2.5, 25 or > > 125MHz as determined by the PHY.) So, I'm not sure that the s32 "rx" > > clock is really the clk_rx_i clock supplied to the DWMAC core. > > > > Certainly on stm32mp151, it states that ETH_RX_CLK in RGMII mode will > > be 2.5, 25 or 125MHz provided by the PHY, and the clock tree indicates > > that ETH_RX_CLK in RGMII mode will be routed directly to the clk_rx_i > > input on the DWMAC(4) core. > > > > RGMII is not the problem. The databook says the RGMII clock (rx/tx) > follows this set rate logic. Sorry, I find this ambiguous. "This" doesn't tell me whether you are referring to either what s32 does (setting the "rx" clock to 125MHz only) or what RGMII spec says about RX_CLK (which is that it comes from the PHY and is 2.5/25/125MHz) which stm32mp151 agrees with and feeds the PHY's RX_CLK to the clk_rx_i inputs on the DWMAC in RGMII, GMII and MII modes. clk_rx_i comes through a bunch of muxes on stm32mp151. When the clock tree is configured for RMII mode, the rate on clk_rx_i depends on the MAC speed (10/100Mbps). This suggests as far as the core is concerned, the clock supplied as clk_rx_i isn't a fixed rate clock but depends on the speed just like the transmit clock. > For other things, I agree with you. A fixed "rx" clock does reach the > limit of what I know. And the databook told nothing about it. As we > can not determine the rx clock of s32 and it may be set for the phy, > it will be better to not move it into the core. I'm intending to leave s32's rx clock alone for this reason as it does not match what I expect. Maybe on s32 there is a bunch of dividers which are selected by the mac_speed_o signals from the core to divide the 125MHz clock down to 25 or 2.5MHz for 100 and 10Mbps respectively. As I don't know, it's safer that I leave it alone as that means the "rx" clock used there is not clk_rx_i.
On Tue, Feb 18, 2025 at 10:40:14AM +0000, Russell King (Oracle) wrote: > On Tue, Feb 18, 2025 at 09:01:59AM +0800, Inochi Amaoto wrote: > > On Mon, Feb 17, 2025 at 11:21:28PM +0000, Russell King (Oracle) wrote: > > > On Tue, Feb 18, 2025 at 06:50:24AM +0800, Inochi Amaoto wrote: > > > > On Mon, Feb 17, 2025 at 02:10:50PM +0000, Russell King (Oracle) wrote: > > > > > On Mon, Feb 17, 2025 at 02:25:33PM +0100, Andrew Lunn wrote: > > > > > > > I am not sure all whether devices has this clock, but it appears in > > > > > > > the databook. So I think it is possible to move this in the core so > > > > > > > any platform with these clock can reuse it. > > > > > > > > > > > > Great > > > > > > > > > > > > The next problem will be, has everybody called it the same thing in > > > > > > DT. Since there has been a lot of cut/paste, maybe they have, by > > > > > > accident. > > > > > > > > > > Tegra186: "tx" > > > > > imx: "tx" > > > > > intel: "tx_clk" > > > > > rk: "clk_mac_speed" > > > > > s32: "tx" > > > > > starfive: "tx" > > > > > sti: "sti-ethclk" > > > > > > > > > > > > > The dwc-qos-eth also use clock name "tx", but set the clock with > > > > extra calibration logic. > > > > > > Yep, that's what I meant by "Tegra186" above. > > > > > > > > so 50% have settled on "tx" and the rest are doing their own thing, and > > > > > that horse has already bolted. > > > > > > > > > > > > > The "rx" clock in s32 also uses the same logic. I think the core also > > > > needs to take it, as this rx clock is also mentioned in the databook. > > > > > > The "rx" clock on s32 seems to only be set to 125MHz, and the driver > > > seems to be limited to RGMII. > > > > > > This seems weird as the receive clock is supposed to be supplied by the > > > PHY, and is recovered from the media (and thus will be 2.5, 25 or > > > 125MHz as determined by the PHY.) So, I'm not sure that the s32 "rx" > > > clock is really the clk_rx_i clock supplied to the DWMAC core. > > > > > > Certainly on stm32mp151, it states that ETH_RX_CLK in RGMII mode will > > > be 2.5, 25 or 125MHz provided by the PHY, and the clock tree indicates > > > that ETH_RX_CLK in RGMII mode will be routed directly to the clk_rx_i > > > input on the DWMAC(4) core. > > > > > > > RGMII is not the problem. The databook says the RGMII clock (rx/tx) > > follows this set rate logic. > > Sorry, I find this ambiguous. "This" doesn't tell me whether you are > referring to either what s32 does (setting the "rx" clock to 125MHz > only) or what RGMII spec says about RX_CLK (which is that it comes from > the PHY and is 2.5/25/125MHz) which stm32mp151 agrees with and feeds > the PHY's RX_CLK to the clk_rx_i inputs on the DWMAC in RGMII, GMII > and MII modes. > What I said follows the second, the clock is set at 2.5/25/125MHz with speed at 10/100/1000Mbps. The only thing I can refer to is the ip databook. > clk_rx_i comes through a bunch of muxes on stm32mp151. When the clock > tree is configured for RMII mode, the rate on clk_rx_i depends on the > MAC speed (10/100Mbps). > OK, I have no problem and find some descriptions related to this in the databook. > This suggests as far as the core is concerned, the clock supplied as > clk_rx_i isn't a fixed rate clock but depends on the speed just like > the transmit clock. > This is what I want to say. clk_rx_i is not fixed but the s32 uses it as a fixed one (This is the thing I felt weird). In fact, Non-fixed clk_rx_i is why I suggested adding the rx clock to the core at first. Since the drive may not use rx clock as the databook says, it is good to leave it alone. At last, it seems like that I need to improve my statement. I am sorry for it. > > For other things, I agree with you. A fixed "rx" clock does reach the > > limit of what I know. And the databook told nothing about it. As we > > can not determine the rx clock of s32 and it may be set for the phy, > > it will be better to not move it into the core. > > I'm intending to leave s32's rx clock alone for this reason as it does > not match what I expect. Maybe on s32 there is a bunch of dividers > which are selected by the mac_speed_o signals from the core to divide > the 125MHz clock down to 25 or 2.5MHz for 100 and 10Mbps respectively. > As I don't know, it's safer that I leave it alone as that means the > "rx" clock used there is not clk_rx_i. > Thanks for your explanation. This is OK for me. Regards, Inochi
On Tue, Feb 18, 2025 at 07:34:47PM +0800, Inochi Amaoto wrote: > On Tue, Feb 18, 2025 at 10:40:14AM +0000, Russell King (Oracle) wrote: > > On Tue, Feb 18, 2025 at 09:01:59AM +0800, Inochi Amaoto wrote: > > > On Mon, Feb 17, 2025 at 11:21:28PM +0000, Russell King (Oracle) wrote: > > > > On Tue, Feb 18, 2025 at 06:50:24AM +0800, Inochi Amaoto wrote: > > > > > On Mon, Feb 17, 2025 at 02:10:50PM +0000, Russell King (Oracle) wrote: > > > > > > On Mon, Feb 17, 2025 at 02:25:33PM +0100, Andrew Lunn wrote: > > > > > > > > I am not sure all whether devices has this clock, but it appears in > > > > > > > > the databook. So I think it is possible to move this in the core so > > > > > > > > any platform with these clock can reuse it. > > > > > > > > > > > > > > Great > > > > > > > > > > > > > > The next problem will be, has everybody called it the same thing in > > > > > > > DT. Since there has been a lot of cut/paste, maybe they have, by > > > > > > > accident. > > > > > > > > > > > > Tegra186: "tx" > > > > > > imx: "tx" > > > > > > intel: "tx_clk" > > > > > > rk: "clk_mac_speed" > > > > > > s32: "tx" > > > > > > starfive: "tx" > > > > > > sti: "sti-ethclk" > > > > > > > > > > > > > > > > The dwc-qos-eth also use clock name "tx", but set the clock with > > > > > extra calibration logic. > > > > > > > > Yep, that's what I meant by "Tegra186" above. > > > > > > > > > > so 50% have settled on "tx" and the rest are doing their own thing, and > > > > > > that horse has already bolted. > > > > > > > > > > > > > > > > The "rx" clock in s32 also uses the same logic. I think the core also > > > > > needs to take it, as this rx clock is also mentioned in the databook. > > > > > > > > The "rx" clock on s32 seems to only be set to 125MHz, and the driver > > > > seems to be limited to RGMII. > > > > > > > > This seems weird as the receive clock is supposed to be supplied by the > > > > PHY, and is recovered from the media (and thus will be 2.5, 25 or > > > > 125MHz as determined by the PHY.) So, I'm not sure that the s32 "rx" > > > > clock is really the clk_rx_i clock supplied to the DWMAC core. > > > > > > > > Certainly on stm32mp151, it states that ETH_RX_CLK in RGMII mode will > > > > be 2.5, 25 or 125MHz provided by the PHY, and the clock tree indicates > > > > that ETH_RX_CLK in RGMII mode will be routed directly to the clk_rx_i > > > > input on the DWMAC(4) core. > > > > > > > > > > RGMII is not the problem. The databook says the RGMII clock (rx/tx) > > > follows this set rate logic. > > > > Sorry, I find this ambiguous. "This" doesn't tell me whether you are > > referring to either what s32 does (setting the "rx" clock to 125MHz > > only) or what RGMII spec says about RX_CLK (which is that it comes from > > the PHY and is 2.5/25/125MHz) which stm32mp151 agrees with and feeds > > the PHY's RX_CLK to the clk_rx_i inputs on the DWMAC in RGMII, GMII > > and MII modes. > > > > What I said follows the second, the clock is set at 2.5/25/125MHz > with speed at 10/100/1000Mbps. The only thing I can refer to is the > ip databook. > > > clk_rx_i comes through a bunch of muxes on stm32mp151. When the clock > > tree is configured for RMII mode, the rate on clk_rx_i depends on the > > MAC speed (10/100Mbps). > > > > OK, I have no problem and find some descriptions related to this in > the databook. > > > This suggests as far as the core is concerned, the clock supplied as > > clk_rx_i isn't a fixed rate clock but depends on the speed just like > > the transmit clock. > > > > This is what I want to say. clk_rx_i is not fixed but the > s32 uses it as a fixed one (This is the thing I felt weird). > > In fact, Non-fixed clk_rx_i is why I suggested adding the rx > clock to the core at first. Since the drive may not use rx > clock as the databook says, it is good to leave it alone. Please ignore my wrong point, I mistake the direction of the rx clock. It is not provided by the mac, but the phy. Regards, Inochi
diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig b/drivers/net/ethernet/stmicro/stmmac/Kconfig index 4cc85a36a1ab..b6ff51e1ebce 100644 --- a/drivers/net/ethernet/stmicro/stmmac/Kconfig +++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig @@ -181,6 +181,17 @@ config DWMAC_SOCFPGA for the stmmac device driver. This driver is used for arria5 and cyclone5 FPGA SoCs. +config DWMAC_SOPHGO + tristate "Sophgo dwmac support" + depends on OF && (ARCH_SOPHGO || COMPILE_TEST) + default m if ARCH_SOPHGO + help + Support for ethernet controllers on Sophgo RISC-V SoCs + + This selects the Sophgo SoC specific glue layer support + for the stmmac device driver. This driver is used for the + ethernet controllers on various Sophgo SoCs. + config DWMAC_STARFIVE tristate "StarFive dwmac support" depends on OF && (ARCH_STARFIVE || COMPILE_TEST) diff --git a/drivers/net/ethernet/stmicro/stmmac/Makefile b/drivers/net/ethernet/stmicro/stmmac/Makefile index b26f0e79c2b3..594883fb4164 100644 --- a/drivers/net/ethernet/stmicro/stmmac/Makefile +++ b/drivers/net/ethernet/stmicro/stmmac/Makefile @@ -24,6 +24,7 @@ obj-$(CONFIG_DWMAC_ROCKCHIP) += dwmac-rk.o obj-$(CONFIG_DWMAC_RZN1) += dwmac-rzn1.o obj-$(CONFIG_DWMAC_S32) += dwmac-s32.o obj-$(CONFIG_DWMAC_SOCFPGA) += dwmac-altr-socfpga.o +obj-$(CONFIG_DWMAC_SOPHGO) += dwmac-sophgo.o obj-$(CONFIG_DWMAC_STARFIVE) += dwmac-starfive.o obj-$(CONFIG_DWMAC_STI) += dwmac-sti.o obj-$(CONFIG_DWMAC_STM32) += dwmac-stm32.o diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sophgo.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-sophgo.c new file mode 100644 index 000000000000..93ea280da6bd --- /dev/null +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sophgo.c @@ -0,0 +1,107 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Sophgo DWMAC platform driver + * + * Copyright (C) 2024 Inochi Amaoto <inochiama@gmail.com> + */ + +#include <linux/clk.h> +#include <linux/module.h> +#include <linux/mod_devicetable.h> +#include <linux/phy.h> +#include <linux/platform_device.h> + +#include "stmmac_platform.h" + +struct sophgo_dwmac { + struct device *dev; + struct clk *clk_tx; +}; + +static void sophgo_dwmac_fix_mac_speed(void *priv, unsigned int speed, unsigned int mode) +{ + struct sophgo_dwmac *dwmac = priv; + long rate; + int ret; + + rate = rgmii_clock(speed); + if (rate < 0) { + dev_err(dwmac->dev, "invalid speed %u\n", speed); + return; + } + + ret = clk_set_rate(dwmac->clk_tx, rate); + if (ret) + dev_err(dwmac->dev, "failed to set tx rate %ld: %pe\n", + rate, ERR_PTR(ret)); +} + +static int sophgo_sg2044_dwmac_init(struct platform_device *pdev, + struct plat_stmmacenet_data *plat_dat, + struct stmmac_resources *stmmac_res) +{ + struct sophgo_dwmac *dwmac; + + dwmac = devm_kzalloc(&pdev->dev, sizeof(*dwmac), GFP_KERNEL); + if (!dwmac) + return -ENOMEM; + + dwmac->clk_tx = devm_clk_get_enabled(&pdev->dev, "tx"); + if (IS_ERR(dwmac->clk_tx)) + return dev_err_probe(&pdev->dev, PTR_ERR(dwmac->clk_tx), + "failed to get tx clock\n"); + + dwmac->dev = &pdev->dev; + plat_dat->bsp_priv = dwmac; + plat_dat->flags |= STMMAC_FLAG_SPH_DISABLE; + plat_dat->fix_mac_speed = sophgo_dwmac_fix_mac_speed; + plat_dat->multicast_filter_bins = 0; + plat_dat->unicast_filter_entries = 1; + + return 0; +} + +static int sophgo_dwmac_probe(struct platform_device *pdev) +{ + struct plat_stmmacenet_data *plat_dat; + struct stmmac_resources stmmac_res; + struct device *dev = &pdev->dev; + int ret; + + ret = stmmac_get_platform_resources(pdev, &stmmac_res); + if (ret) + return dev_err_probe(dev, ret, + "failed to get platform resources\n"); + + plat_dat = devm_stmmac_probe_config_dt(pdev, stmmac_res.mac); + if (IS_ERR(plat_dat)) + return dev_err_probe(dev, PTR_ERR(plat_dat), + "failed to parse DT parameters\n"); + + ret = sophgo_sg2044_dwmac_init(pdev, plat_dat, &stmmac_res); + if (ret) + return ret; + + return stmmac_dvr_probe(dev, plat_dat, &stmmac_res); +} + +static const struct of_device_id sophgo_dwmac_match[] = { + { .compatible = "sophgo,sg2044-dwmac" }, + { /* sentinel */ } +}; +MODULE_DEVICE_TABLE(of, sophgo_dwmac_match); + +static struct platform_driver sophgo_dwmac_driver = { + .probe = sophgo_dwmac_probe, + .remove = stmmac_pltfr_remove, + .driver = { + .name = "sophgo-dwmac", + .pm = &stmmac_pltfr_pm_ops, + .of_match_table = sophgo_dwmac_match, + }, +}; +module_platform_driver(sophgo_dwmac_driver); + +MODULE_AUTHOR("Inochi Amaoto <inochiama@gmail.com>"); +MODULE_DESCRIPTION("Sophgo DWMAC platform driver"); +MODULE_LICENSE("GPL");
Adds Sophgo dwmac driver support on the Sophgo SG2044 SoC. Signed-off-by: Inochi Amaoto <inochiama@gmail.com> --- drivers/net/ethernet/stmicro/stmmac/Kconfig | 11 ++ drivers/net/ethernet/stmicro/stmmac/Makefile | 1 + .../ethernet/stmicro/stmmac/dwmac-sophgo.c | 107 ++++++++++++++++++ 3 files changed, 119 insertions(+) create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-sophgo.c