diff mbox series

[v3,2/4] net: stmmac: dwc-qos: Add FSD EQoS support

Message ID 20230814112539.70453-3-sriranjani.p@samsung.com
State New
Headers show
Series [v3,1/4] dt-bindings: net: Add FSD EQoS device tree bindings | expand

Commit Message

Sriranjani P Aug. 14, 2023, 11:25 a.m. UTC
The FSD SoC contains two instance of the Synopsys DWC ethernet QOS IP core.
The binding that it uses is slightly different from existing ones because
of the integration (clocks, resets).

For FSD SoC, a mux switch is needed between internal and external clocks.
By default after reset internal clock is used but for receiving packets
properly, external clock is needed. Mux switch to external clock happens
only when the external clock is present.

Signed-off-by: Chandrasekar R <rcsekar@samsung.com>
Signed-off-by: Suresh Siddha <ssiddha@tesla.com>
Signed-off-by: Swathi K S <swathi.ks@samsung.com>
Signed-off-by: Sriranjani P <sriranjani.p@samsung.com>
---
 .../stmicro/stmmac/dwmac-dwc-qos-eth.c        | 172 ++++++++++++++++++
 .../net/ethernet/stmicro/stmmac/stmmac_main.c |  28 ++-
 include/linux/stmmac.h                        |   1 +
 3 files changed, 199 insertions(+), 2 deletions(-)

Comments

Krzysztof Kozlowski Aug. 18, 2023, 9:27 a.m. UTC | #1
On 16/08/2023 08:38, Sriranjani P wrote:
> 
> 
>> -----Original Message-----
>> From: Krzysztof Kozlowski [mailto:krzysztof.kozlowski@linaro.org]
>> Sent: 15 August 2023 01:21
>> To: Sriranjani P <sriranjani.p@samsung.com>; davem@davemloft.net;
>> edumazet@google.com; kuba@kernel.org; pabeni@redhat.com;
>> robh+dt@kernel.org; krzysztof.kozlowski+dt@linaro.org;
>> conor+dt@kernel.org; richardcochran@gmail.com;
>> alexandre.torgue@foss.st.com; joabreu@synopsys.com;
>> mcoquelin.stm32@gmail.com; alim.akhtar@samsung.com; linux-
>> fsd@tesla.com; pankaj.dubey@samsung.com; swathi.ks@samsung.com;
>> ravi.patel@samsung.com
>> Cc: netdev@vger.kernel.org; devicetree@vger.kernel.org; linux-
>> kernel@vger.kernel.org; linux-samsung-soc@vger.kernel.org; linux-arm-
>> kernel@lists.infradead.org; Chandrasekar R <rcsekar@samsung.com>;
>> Suresh Siddha <ssiddha@tesla.com>
>> Subject: Re: [PATCH v3 2/4] net: stmmac: dwc-qos: Add FSD EQoS support
>>
>> On 14/08/2023 13:25, Sriranjani P wrote:
>>> The FSD SoC contains two instance of the Synopsys DWC ethernet QOS IP
>> core.
>>> The binding that it uses is slightly different from existing ones
>>> because of the integration (clocks, resets).
>>>
>>> For FSD SoC, a mux switch is needed between internal and external clocks.
>>> By default after reset internal clock is used but for receiving
>>> packets properly, external clock is needed. Mux switch to external
>>> clock happens only when the external clock is present.
>>>
>>> Signed-off-by: Chandrasekar R <rcsekar@samsung.com>
>>> Signed-off-by: Suresh Siddha <ssiddha@tesla.com>
>>> Signed-off-by: Swathi K S <swathi.ks@samsung.com>
>>> Signed-off-by: Sriranjani P <sriranjani.p@samsung.com>
>>> ---
>>
>>
>>> +static int dwc_eqos_setup_rxclock(struct platform_device *pdev, int
>>> +ins_num) {
>>> +	struct device_node *np = pdev->dev.of_node;
>>> +	struct regmap *syscon;
>>> +	unsigned int reg;
>>> +
>>> +	if (np && of_property_read_bool(np, "fsd-rx-clock-skew")) {
>>> +		syscon = syscon_regmap_lookup_by_phandle_args(np,
>>> +							      "fsd-rx-clock-
>> skew",
>>> +							      1, &reg);
>>> +		if (IS_ERR(syscon)) {
>>> +			dev_err(&pdev->dev,
>>> +				"couldn't get the rx-clock-skew syscon!\n");
>>> +			return PTR_ERR(syscon);
>>> +		}
>>> +
>>> +		regmap_write(syscon, reg, rx_clock_skew_val[ins_num]);
>>> +	}
>>> +
>>> +	return 0;
>>> +}
>>> +
>>> +static int fsd_eqos_clk_init(struct fsd_eqos_plat_data *plat,
>>> +			     struct plat_stmmacenet_data *data) {
>>> +	int ret = 0, i;
>>> +
>>> +	const struct fsd_eqos_variant *fsd_eqos_v_data =
>>> +						plat->fsd_eqos_inst_var;
>>> +
>>> +	plat->clks = devm_kcalloc(plat->dev, fsd_eqos_v_data->num_clks,
>>> +				  sizeof(*plat->clks), GFP_KERNEL);
>>> +	if (!plat->clks)
>>> +		return -ENOMEM;
>>> +
>>> +	for (i = 0; i < fsd_eqos_v_data->num_clks; i++)
>>> +		plat->clks[i].id = fsd_eqos_v_data->clk_list[i];
>>> +
>>> +	ret = devm_clk_bulk_get(plat->dev, fsd_eqos_v_data->num_clks,
>>> +				plat->clks);
>>
>> Instead of duplicating entire clock management with existing code, you
>> should extend/rework existing one.
>>
>> This code is unfortunately great example how not to stuff vendor code into
>> upstream project. :(
> 
> I will check again if I can extend existing one to support FSD platform specific requirement.
> 
>>
>>> +
>>> +	return ret;
>>> +}
>>> +
>>> +static int fsd_clks_endisable(void *priv, bool enabled) {
>>> +	int ret, num_clks;
>>> +	struct fsd_eqos_plat_data *plat = priv;
>>> +
>>> +	num_clks = plat->fsd_eqos_inst_var->num_clks;
>>> +
>>> +	if (enabled) {
>>> +		ret = clk_bulk_prepare_enable(num_clks, plat->clks);
>>> +		if (ret) {
>>> +			dev_err(plat->dev, "Clock enable failed, err = %d\n",
>> ret);
>>> +			return ret;
>>> +		}
>>> +	} else {
>>> +		clk_bulk_disable_unprepare(num_clks, plat->clks);
>>> +	}
>>> +
>>> +	return 0;
>>> +}
>>> +
>>> +static int fsd_eqos_probe(struct platform_device *pdev,
>>> +			  struct plat_stmmacenet_data *data,
>>> +			  struct stmmac_resources *res)
>>> +{
>>> +	struct fsd_eqos_plat_data *priv_plat;
>>> +	struct device_node *np = pdev->dev.of_node;
>>> +	int ret = 0;
>>> +
>>> +	priv_plat = devm_kzalloc(&pdev->dev, sizeof(*priv_plat),
>> GFP_KERNEL);
>>> +	if (!priv_plat) {
>>> +		ret = -ENOMEM;
>>
>> return -ENOMEM
> 
> Will fix this in v4.
> 
>>
>>> +		goto error;
>>> +	}
>>> +
>>> +	priv_plat->dev = &pdev->dev;
>>> +	data->bus_id = of_alias_get_id(np, "eth");
>>
>> No, you cannot do like this. Aliases are board specific and are based on
>> labeling on the board.
> 
> So if I understood this correctly, I need to move alias in the board specific DTS file 

This part: yes

> and I can use this, because we have to handle rx-clock-skew differently for the two instances in the FSD platform.

Not really. Do you expect it to work correctly if given EQoS instance
receives different alias, e.g. 5?

> Another approach we took in v1, by specifying the value to be programmed in rx-clock-skew property itself, but it seems it is not a preferred approach. 
> I can see that in drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c +436 common code is already using this API and getting alias id, so I can probably use the same rather getting same again here, but I have to specify alias in DTS file.

Getting alias ID is okay in general. It is used to provide user-visible
ID of the devices (see mmc). Using such alias to configure hardware is
abuse of the alias, because of the reasons I said - how is it supposed
to work if alias is 5 (this is perfectly valid alias)?

I suspect that all this is to substitute missing abstractions, like
clocks, phys or resets...

Best regards,
Krzysztof
Swathi K S June 6, 2024, 9:14 a.m. UTC | #2
> -----Original Message-----
> From: Krzysztof Kozlowski [mailto:krzysztof.kozlowski@linaro.org]
> Sent: 18 August 2023 14:57
> To: Sriranjani P <sriranjani.p@samsung.com>; davem@davemloft.net;
> edumazet@google.com; kuba@kernel.org; pabeni@redhat.com;
> robh+dt@kernel.org; krzysztof.kozlowski+dt@linaro.org;
> conor+dt@kernel.org; richardcochran@gmail.com;
> alexandre.torgue@foss.st.com; joabreu@synopsys.com;
> mcoquelin.stm32@gmail.com; alim.akhtar@samsung.com; linux-
> fsd@tesla.com; pankaj.dubey@samsung.com; swathi.ks@samsung.com;
> ravi.patel@samsung.com
> Cc: netdev@vger.kernel.org; devicetree@vger.kernel.org; linux-
> kernel@vger.kernel.org; linux-samsung-soc@vger.kernel.org; linux-arm-
> kernel@lists.infradead.org; 'Chandrasekar R' <rcsekar@samsung.com>;
> 'Suresh Siddha' <ssiddha@tesla.com>
> Subject: Re: [PATCH v3 2/4] net: stmmac: dwc-qos: Add FSD EQoS support
> 
> On 16/08/2023 08:38, Sriranjani P wrote:
> >
> >
> >> -----Original Message-----
> >> From: Krzysztof Kozlowski [mailto:krzysztof.kozlowski@linaro.org]
> >> Sent: 15 August 2023 01:21
> >> To: Sriranjani P <sriranjani.p@samsung.com>; davem@davemloft.net;
> >> edumazet@google.com; kuba@kernel.org; pabeni@redhat.com;
> >> robh+dt@kernel.org; krzysztof.kozlowski+dt@linaro.org;
> >> conor+dt@kernel.org; richardcochran@gmail.com;
> >> alexandre.torgue@foss.st.com; joabreu@synopsys.com;
> >> mcoquelin.stm32@gmail.com; alim.akhtar@samsung.com; linux-
> >> fsd@tesla.com; pankaj.dubey@samsung.com; swathi.ks@samsung.com;
> >> ravi.patel@samsung.com
> >> Cc: netdev@vger.kernel.org; devicetree@vger.kernel.org; linux-
> >> kernel@vger.kernel.org; linux-samsung-soc@vger.kernel.org; linux-arm-
> >> kernel@lists.infradead.org; Chandrasekar R <rcsekar@samsung.com>;
> >> Suresh Siddha <ssiddha@tesla.com>
> >> Subject: Re: [PATCH v3 2/4] net: stmmac: dwc-qos: Add FSD EQoS
> >> support
> >>
> >> On 14/08/2023 13:25, Sriranjani P wrote:
> >>> The FSD SoC contains two instance of the Synopsys DWC ethernet QOS
> >>> IP
> >> core.
> >>> The binding that it uses is slightly different from existing ones
> >>> because of the integration (clocks, resets).
> >>>
> >>> For FSD SoC, a mux switch is needed between internal and external
> clocks.
> >>> By default after reset internal clock is used but for receiving
> >>> packets properly, external clock is needed. Mux switch to external
> >>> clock happens only when the external clock is present.
> >>>
> >>> Signed-off-by: Chandrasekar R <rcsekar@samsung.com>
> >>> Signed-off-by: Suresh Siddha <ssiddha@tesla.com>
> >>> Signed-off-by: Swathi K S <swathi.ks@samsung.com>
> >>> Signed-off-by: Sriranjani P <sriranjani.p@samsung.com>
> >>> ---
> >>
> >>
> >>> +static int dwc_eqos_setup_rxclock(struct platform_device *pdev, int
> >>> +ins_num) {
> >>> +	struct device_node *np = pdev->dev.of_node;
> >>> +	struct regmap *syscon;
> >>> +	unsigned int reg;
> >>> +
> >>> +	if (np && of_property_read_bool(np, "fsd-rx-clock-skew")) {
> >>> +		syscon = syscon_regmap_lookup_by_phandle_args(np,
> >>> +							      "fsd-rx-clock-
> >> skew",
> >>> +							      1, &reg);
> >>> +		if (IS_ERR(syscon)) {
> >>> +			dev_err(&pdev->dev,
> >>> +				"couldn't get the rx-clock-skew syscon!\n");
> >>> +			return PTR_ERR(syscon);
> >>> +		}
> >>> +
> >>> +		regmap_write(syscon, reg, rx_clock_skew_val[ins_num]);
> >>> +	}
> >>> +
> >>> +	return 0;
> >>> +}
> >>> +
> >>> +static int fsd_eqos_clk_init(struct fsd_eqos_plat_data *plat,
> >>> +			     struct plat_stmmacenet_data *data) {
> >>> +	int ret = 0, i;
> >>> +
> >>> +	const struct fsd_eqos_variant *fsd_eqos_v_data =
> >>> +						plat->fsd_eqos_inst_var;
> >>> +
> >>> +	plat->clks = devm_kcalloc(plat->dev, fsd_eqos_v_data->num_clks,
> >>> +				  sizeof(*plat->clks), GFP_KERNEL);
> >>> +	if (!plat->clks)
> >>> +		return -ENOMEM;
> >>> +
> >>> +	for (i = 0; i < fsd_eqos_v_data->num_clks; i++)
> >>> +		plat->clks[i].id = fsd_eqos_v_data->clk_list[i];
> >>> +
> >>> +	ret = devm_clk_bulk_get(plat->dev, fsd_eqos_v_data->num_clks,
> >>> +				plat->clks);
> >>
> >> Instead of duplicating entire clock management with existing code,
> >> you should extend/rework existing one.
> >>
> >> This code is unfortunately great example how not to stuff vendor code
> >> into upstream project. :(
> >
> > I will check again if I can extend existing one to support FSD platform
> specific requirement.
> >
> >>
> >>> +
> >>> +	return ret;
> >>> +}
> >>> +
> >>> +static int fsd_clks_endisable(void *priv, bool enabled) {
> >>> +	int ret, num_clks;
> >>> +	struct fsd_eqos_plat_data *plat = priv;
> >>> +
> >>> +	num_clks = plat->fsd_eqos_inst_var->num_clks;
> >>> +
> >>> +	if (enabled) {
> >>> +		ret = clk_bulk_prepare_enable(num_clks, plat->clks);
> >>> +		if (ret) {
> >>> +			dev_err(plat->dev, "Clock enable failed, err = %d\n",
> >> ret);
> >>> +			return ret;
> >>> +		}
> >>> +	} else {
> >>> +		clk_bulk_disable_unprepare(num_clks, plat->clks);
> >>> +	}
> >>> +
> >>> +	return 0;
> >>> +}
> >>> +
> >>> +static int fsd_eqos_probe(struct platform_device *pdev,
> >>> +			  struct plat_stmmacenet_data *data,
> >>> +			  struct stmmac_resources *res)
> >>> +{
> >>> +	struct fsd_eqos_plat_data *priv_plat;
> >>> +	struct device_node *np = pdev->dev.of_node;
> >>> +	int ret = 0;
> >>> +
> >>> +	priv_plat = devm_kzalloc(&pdev->dev, sizeof(*priv_plat),
> >> GFP_KERNEL);
> >>> +	if (!priv_plat) {
> >>> +		ret = -ENOMEM;
> >>
> >> return -ENOMEM
> >
> > Will fix this in v4.
> >
> >>
> >>> +		goto error;
> >>> +	}
> >>> +
> >>> +	priv_plat->dev = &pdev->dev;
> >>> +	data->bus_id = of_alias_get_id(np, "eth");
> >>
> >> No, you cannot do like this. Aliases are board specific and are based
> >> on labeling on the board.
> >
> > So if I understood this correctly, I need to move alias in the board
> > specific DTS file
> 
> This part: yes
> 
> > and I can use this, because we have to handle rx-clock-skew differently for
> the two instances in the FSD platform.
> 
> Not really. Do you expect it to work correctly if given EQoS instance receives
> different alias, e.g. 5?
> 
> > Another approach we took in v1, by specifying the value to be programmed
> in rx-clock-skew property itself, but it seems it is not a preferred approach.
> > I can see that in drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> +436 common code is already using this API and getting alias id, so I can
> probably use the same rather getting same again here, but I have to specify
> alias in DTS file.
> 
> Getting alias ID is okay in general. It is used to provide user-visible ID of the
> devices (see mmc). Using such alias to configure hardware is abuse of the
> alias, because of the reasons I said - how is it supposed to work if alias is 5
> (this is perfectly valid alias)?
> 
> I suspect that all this is to substitute missing abstractions, like clocks, phys or
> resets...

Will avoid using the API to get alias id to configure the HW. Will share the new implementation in v4.

> 
> Best regards,
> Krzysztof


Regards,
Swathi
Swathi K S June 6, 2024, 9:16 a.m. UTC | #3
> -----Original Message-----
> From: Andrew Lunn [mailto:andrew@lunn.ch]
> Sent: 15 August 2023 02:17
> To: Sriranjani P <sriranjani.p@samsung.com>
> Cc: davem@davemloft.net; edumazet@google.com; kuba@kernel.org;
> pabeni@redhat.com; robh+dt@kernel.org;
> krzysztof.kozlowski+dt@linaro.org; conor+dt@kernel.org;
> richardcochran@gmail.com; alexandre.torgue@foss.st.com;
> joabreu@synopsys.com; mcoquelin.stm32@gmail.com;
> alim.akhtar@samsung.com; linux-fsd@tesla.com;
> pankaj.dubey@samsung.com; swathi.ks@samsung.com;
> ravi.patel@samsung.com; netdev@vger.kernel.org;
> devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; linux-samsung-
> soc@vger.kernel.org; linux-arm-kernel@lists.infradead.org; Chandrasekar R
> <rcsekar@samsung.com>; Suresh Siddha <ssiddha@tesla.com>
> Subject: Re: [PATCH v3 2/4] net: stmmac: dwc-qos: Add FSD EQoS support
> 
> > +static const int rx_clock_skew_val[] = {0x2, 0x0};
> 
> > +static int dwc_eqos_setup_rxclock(struct platform_device *pdev, int
> > +ins_num) {
> > +	struct device_node *np = pdev->dev.of_node;
> > +	struct regmap *syscon;
> > +	unsigned int reg;
> > +
> > +	if (np && of_property_read_bool(np, "fsd-rx-clock-skew")) {
> > +		syscon = syscon_regmap_lookup_by_phandle_args(np,
> > +							      "fsd-rx-clock-
> skew",
> > +							      1, &reg);
> > +		if (IS_ERR(syscon)) {
> > +			dev_err(&pdev->dev,
> > +				"couldn't get the rx-clock-skew syscon!\n");
> > +			return PTR_ERR(syscon);
> > +		}
> > +
> > +		regmap_write(syscon, reg, rx_clock_skew_val[ins_num]);
> 
> Please could you explain what this is doing.

As per customer requirement, we need to provide a delay of 2ns in FSYS in
both TX and RX path and no delay in peric block

> 
>        Andrew

Regards,
Swathi
Krzysztof Kozlowski June 6, 2024, 12:16 p.m. UTC | #4
On 06/06/2024 11:14, Swathi K S wrote:
> 
> 
>> -----Original Message-----
>> From: Krzysztof Kozlowski [mailto:krzysztof.kozlowski@linaro.org]
>> Sent: 18 August 2023 14:57
>> To: Sriranjani P <sriranjani.p@samsung.com>; davem@davemloft.net;
>> edumazet@google.com; kuba@kernel.org; pabeni@redhat.com;
>> robh+dt@kernel.org; krzysztof.kozlowski+dt@linaro.org;
>> conor+dt@kernel.org; richardcochran@gmail.com;
>> alexandre.torgue@foss.st.com; joabreu@synopsys.com;
>> mcoquelin.stm32@gmail.com; alim.akhtar@samsung.com; linux-
>> fsd@tesla.com; pankaj.dubey@samsung.com; swathi.ks@samsung.com;
>> ravi.patel@samsung.com
>> Cc: netdev@vger.kernel.org; devicetree@vger.kernel.org; linux-
>> kernel@vger.kernel.org; linux-samsung-soc@vger.kernel.org; linux-arm-
>> kernel@lists.infradead.org; 'Chandrasekar R' <rcsekar@samsung.com>;
>> 'Suresh Siddha' <ssiddha@tesla.com>
>> Subject: Re: [PATCH v3 2/4] net: stmmac: dwc-qos: Add FSD EQoS support
>>
>> On 16/08/2023 08:38, Sriranjani P wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: Krzysztof Kozlowski [mailto:krzysztof.kozlowski@linaro.org]
>>>> Sent: 15 August 2023 01:21
>>>> To: Sriranjani P <sriranjani.p@samsung.com>; davem@davemloft.net;
>>>> edumazet@google.com; kuba@kernel.org; pabeni@redhat.com;
>>>> robh+dt@kernel.org; krzysztof.kozlowski+dt@linaro.org;
>>>> conor+dt@kernel.org; richardcochran@gmail.com;
>>>> alexandre.torgue@foss.st.com; joabreu@synopsys.com;
>>>> mcoquelin.stm32@gmail.com; alim.akhtar@samsung.com; linux-
>>>> fsd@tesla.com; pankaj.dubey@samsung.com; swathi.ks@samsung.com;
>>>> ravi.patel@samsung.com
>>>> Cc: netdev@vger.kernel.org; devicetree@vger.kernel.org; linux-
>>>> kernel@vger.kernel.org; linux-samsung-soc@vger.kernel.org; linux-arm-
>>>> kernel@lists.infradead.org; Chandrasekar R <rcsekar@samsung.com>;
>>>> Suresh Siddha <ssiddha@tesla.com>
>>>> Subject: Re: [PATCH v3 2/4] net: stmmac: dwc-qos: Add FSD EQoS
>>>> support
>>>>
>>>> On 14/08/2023 13:25, Sriranjani P wrote:
>>>>> The FSD SoC contains two instance of the Synopsys DWC ethernet QOS
>>>>> IP
>>>> core.
>>>>> The binding that it uses is slightly different from existing ones
>>>>> because of the integration (clocks, resets).
>>>>>
>>>>> For FSD SoC, a mux switch is needed between internal and external
>> clocks.
>>>>> By default after reset internal clock is used but for receiving
>>>>> packets properly, external clock is needed. Mux switch to external
>>>>> clock happens only when the external clock is present.
>>>>>
>>>>> Signed-off-by: Chandrasekar R <rcsekar@samsung.com>
>>>>> Signed-off-by: Suresh Siddha <ssiddha@tesla.com>
>>>>> Signed-off-by: Swathi K S <swathi.ks@samsung.com>
>>>>> Signed-off-by: Sriranjani P <sriranjani.p@samsung.com>
>>>>> ---
>>>>
>>>>
>>>>> +static int dwc_eqos_setup_rxclock(struct platform_device *pdev, int
>>>>> +ins_num) {
>>>>> +	struct device_node *np = pdev->dev.of_node;
>>>>> +	struct regmap *syscon;
>>>>> +	unsigned int reg;
>>>>> +
>>>>> +	if (np && of_property_read_bool(np, "fsd-rx-clock-skew")) {
>>>>> +		syscon = syscon_regmap_lookup_by_phandle_args(np,
>>>>> +							      "fsd-rx-clock-
>>>> skew",
>>>>> +							      1, &reg);
>>>>> +		if (IS_ERR(syscon)) {
>>>>> +			dev_err(&pdev->dev,
>>>>> +				"couldn't get the rx-clock-skew syscon!\n");
>>>>> +			return PTR_ERR(syscon);
>>>>> +		}
>>>>> +
>>>>> +		regmap_write(syscon, reg, rx_clock_skew_val[ins_num]);
>>>>> +	}
>>>>> +
>>>>> +	return 0;
>>>>> +}
>>>>> +
>>>>> +static int fsd_eqos_clk_init(struct fsd_eqos_plat_data *plat,
>>>>> +			     struct plat_stmmacenet_data *data) {
>>>>> +	int ret = 0, i;
>>>>> +
>>>>> +	const struct fsd_eqos_variant *fsd_eqos_v_data =
>>>>> +						plat->fsd_eqos_inst_var;
>>>>> +
>>>>> +	plat->clks = devm_kcalloc(plat->dev, fsd_eqos_v_data->num_clks,
>>>>> +				  sizeof(*plat->clks), GFP_KERNEL);
>>>>> +	if (!plat->clks)
>>>>> +		return -ENOMEM;
>>>>> +
>>>>> +	for (i = 0; i < fsd_eqos_v_data->num_clks; i++)
>>>>> +		plat->clks[i].id = fsd_eqos_v_data->clk_list[i];
>>>>> +
>>>>> +	ret = devm_clk_bulk_get(plat->dev, fsd_eqos_v_data->num_clks,
>>>>> +				plat->clks);
>>>>
>>>> Instead of duplicating entire clock management with existing code,
>>>> you should extend/rework existing one.
>>>>
>>>> This code is unfortunately great example how not to stuff vendor code
>>>> into upstream project. :(
>>>
>>> I will check again if I can extend existing one to support FSD platform
>> specific requirement.
>>>
>>>>
>>>>> +
>>>>> +	return ret;
>>>>> +}
>>>>> +
>>>>> +static int fsd_clks_endisable(void *priv, bool enabled) {
>>>>> +	int ret, num_clks;
>>>>> +	struct fsd_eqos_plat_data *plat = priv;
>>>>> +
>>>>> +	num_clks = plat->fsd_eqos_inst_var->num_clks;
>>>>> +
>>>>> +	if (enabled) {
>>>>> +		ret = clk_bulk_prepare_enable(num_clks, plat->clks);
>>>>> +		if (ret) {
>>>>> +			dev_err(plat->dev, "Clock enable failed, err = %d\n",
>>>> ret);
>>>>> +			return ret;
>>>>> +		}
>>>>> +	} else {
>>>>> +		clk_bulk_disable_unprepare(num_clks, plat->clks);
>>>>> +	}
>>>>> +
>>>>> +	return 0;
>>>>> +}
>>>>> +
>>>>> +static int fsd_eqos_probe(struct platform_device *pdev,
>>>>> +			  struct plat_stmmacenet_data *data,
>>>>> +			  struct stmmac_resources *res)
>>>>> +{
>>>>> +	struct fsd_eqos_plat_data *priv_plat;
>>>>> +	struct device_node *np = pdev->dev.of_node;
>>>>> +	int ret = 0;
>>>>> +
>>>>> +	priv_plat = devm_kzalloc(&pdev->dev, sizeof(*priv_plat),
>>>> GFP_KERNEL);
>>>>> +	if (!priv_plat) {
>>>>> +		ret = -ENOMEM;
>>>>
>>>> return -ENOMEM
>>>
>>> Will fix this in v4.
>>>
>>>>
>>>>> +		goto error;
>>>>> +	}
>>>>> +
>>>>> +	priv_plat->dev = &pdev->dev;
>>>>> +	data->bus_id = of_alias_get_id(np, "eth");
>>>>
>>>> No, you cannot do like this. Aliases are board specific and are based
>>>> on labeling on the board.
>>>
>>> So if I understood this correctly, I need to move alias in the board
>>> specific DTS file
>>
>> This part: yes
>>
>>> and I can use this, because we have to handle rx-clock-skew differently for
>> the two instances in the FSD platform.
>>
>> Not really. Do you expect it to work correctly if given EQoS instance receives
>> different alias, e.g. 5?
>>
>>> Another approach we took in v1, by specifying the value to be programmed
>> in rx-clock-skew property itself, but it seems it is not a preferred approach.
>>> I can see that in drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
>> +436 common code is already using this API and getting alias id, so I can
>> probably use the same rather getting same again here, but I have to specify
>> alias in DTS file.
>>
>> Getting alias ID is okay in general. It is used to provide user-visible ID of the
>> devices (see mmc). Using such alias to configure hardware is abuse of the
>> alias, because of the reasons I said - how is it supposed to work if alias is 5
>> (this is perfectly valid alias)?
>>
>> I suspect that all this is to substitute missing abstractions, like clocks, phys or
>> resets...
> 
> Will avoid using the API to get alias id to configure the HW. Will share the new implementation in v4.

That was August 2023, almost year ago.

Whatever you plan, expect having same questions in the discussion
because we forgot everything said that year ago...

Best regards,
Krzysztof
diff mbox series

Patch

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c
index 61ebf36da13d..651a41e0dab9 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c
@@ -20,6 +20,7 @@ 
 #include <linux/platform_device.h>
 #include <linux/reset.h>
 #include <linux/stmmac.h>
+#include <linux/regmap.h>
 
 #include "stmmac_platform.h"
 #include "dwmac4.h"
@@ -37,6 +38,45 @@  struct tegra_eqos {
 	struct gpio_desc *reset;
 };
 
+enum fsd_rxmux_clk {
+	FSD_RXCLK_MUX = 7,
+	FSD_RXCLK_EXTERNAL,
+	FSD_RXCLK_INTERNAL
+};
+
+struct fsd_eqos_plat_data {
+	const struct fsd_eqos_variant *fsd_eqos_inst_var;
+	struct clk_bulk_data *clks;
+	struct device *dev;
+};
+
+struct fsd_eqos_variant {
+	const char * const *clk_list;
+	int num_clks;
+};
+
+static const char * const fsd_eqos_instance_0_clk[] = {
+	"ptp_ref", "master_bus", "slave_bus", "tx", "rx"
+};
+
+static const char * const fsd_eqos_instance_1_clk[] = {
+	"ptp_ref", "master_bus", "slave_bus", "tx", "rx", "master2_bus",
+	"slave2_bus", "eqos_rxclk_mux", "eqos_phyrxclk", "dout_peric_rgmii_clk"
+};
+
+static const int rx_clock_skew_val[] = {0x2, 0x0};
+
+static const struct fsd_eqos_variant fsd_eqos_clk_info[] = {
+	{
+		.clk_list = fsd_eqos_instance_0_clk,
+		.num_clks = ARRAY_SIZE(fsd_eqos_instance_0_clk)
+	},
+	{
+		.clk_list = fsd_eqos_instance_1_clk,
+		.num_clks = ARRAY_SIZE(fsd_eqos_instance_1_clk)
+	},
+};
+
 static int dwc_eth_dwmac_config_dt(struct platform_device *pdev,
 				   struct plat_stmmacenet_data *plat_dat)
 {
@@ -265,6 +305,132 @@  static int tegra_eqos_init(struct platform_device *pdev, void *priv)
 	return 0;
 }
 
+static int dwc_eqos_rxmux_setup(void *priv, bool external)
+{
+	struct fsd_eqos_plat_data *plat = priv;
+
+	/* doesn't support RX clock mux */
+	if (!plat->clks[FSD_RXCLK_MUX].clk)
+		return 0;
+
+	if (external)
+		return clk_set_parent(plat->clks[FSD_RXCLK_MUX].clk,
+				      plat->clks[FSD_RXCLK_EXTERNAL].clk);
+	else
+		return clk_set_parent(plat->clks[FSD_RXCLK_MUX].clk,
+				      plat->clks[FSD_RXCLK_INTERNAL].clk);
+}
+
+static int dwc_eqos_setup_rxclock(struct platform_device *pdev, int ins_num)
+{
+	struct device_node *np = pdev->dev.of_node;
+	struct regmap *syscon;
+	unsigned int reg;
+
+	if (np && of_property_read_bool(np, "fsd-rx-clock-skew")) {
+		syscon = syscon_regmap_lookup_by_phandle_args(np,
+							      "fsd-rx-clock-skew",
+							      1, &reg);
+		if (IS_ERR(syscon)) {
+			dev_err(&pdev->dev,
+				"couldn't get the rx-clock-skew syscon!\n");
+			return PTR_ERR(syscon);
+		}
+
+		regmap_write(syscon, reg, rx_clock_skew_val[ins_num]);
+	}
+
+	return 0;
+}
+
+static int fsd_eqos_clk_init(struct fsd_eqos_plat_data *plat,
+			     struct plat_stmmacenet_data *data)
+{
+	int ret = 0, i;
+
+	const struct fsd_eqos_variant *fsd_eqos_v_data =
+						plat->fsd_eqos_inst_var;
+
+	plat->clks = devm_kcalloc(plat->dev, fsd_eqos_v_data->num_clks,
+				  sizeof(*plat->clks), GFP_KERNEL);
+	if (!plat->clks)
+		return -ENOMEM;
+
+	for (i = 0; i < fsd_eqos_v_data->num_clks; i++)
+		plat->clks[i].id = fsd_eqos_v_data->clk_list[i];
+
+	ret = devm_clk_bulk_get(plat->dev, fsd_eqos_v_data->num_clks,
+				plat->clks);
+
+	return ret;
+}
+
+static int fsd_clks_endisable(void *priv, bool enabled)
+{
+	int ret, num_clks;
+	struct fsd_eqos_plat_data *plat = priv;
+
+	num_clks = plat->fsd_eqos_inst_var->num_clks;
+
+	if (enabled) {
+		ret = clk_bulk_prepare_enable(num_clks, plat->clks);
+		if (ret) {
+			dev_err(plat->dev, "Clock enable failed, err = %d\n", ret);
+			return ret;
+		}
+	} else {
+		clk_bulk_disable_unprepare(num_clks, plat->clks);
+	}
+
+	return 0;
+}
+
+static int fsd_eqos_probe(struct platform_device *pdev,
+			  struct plat_stmmacenet_data *data,
+			  struct stmmac_resources *res)
+{
+	struct fsd_eqos_plat_data *priv_plat;
+	struct device_node *np = pdev->dev.of_node;
+	int ret = 0;
+
+	priv_plat = devm_kzalloc(&pdev->dev, sizeof(*priv_plat), GFP_KERNEL);
+	if (!priv_plat) {
+		ret = -ENOMEM;
+		goto error;
+	}
+
+	priv_plat->dev = &pdev->dev;
+	data->bus_id = of_alias_get_id(np, "eth");
+
+	priv_plat->fsd_eqos_inst_var = &fsd_eqos_clk_info[data->bus_id];
+
+	ret = fsd_eqos_clk_init(priv_plat, data);
+
+	data->bsp_priv = priv_plat;
+	data->clks_config = fsd_clks_endisable;
+	data->rxmux_setup = dwc_eqos_rxmux_setup;
+
+	ret = fsd_clks_endisable(priv_plat, true);
+	if (ret)
+		goto error;
+
+	ret = dwc_eqos_setup_rxclock(pdev, data->bus_id);
+	if (ret) {
+		fsd_clks_endisable(priv_plat, false);
+		dev_err_probe(&pdev->dev, ret, "Unable to setup rxclock\n");
+	}
+
+error:
+	return ret;
+}
+
+static void fsd_eqos_remove(struct platform_device *pdev)
+{
+	struct fsd_eqos_plat_data *priv_plat = get_stmmac_bsp_priv(&pdev->dev);
+
+	fsd_clks_endisable(priv_plat, false);
+}
+
 static int tegra_eqos_probe(struct platform_device *pdev,
 			    struct plat_stmmacenet_data *data,
 			    struct stmmac_resources *res)
@@ -411,6 +577,11 @@  static const struct dwc_eth_dwmac_data tegra_eqos_data = {
 	.remove = tegra_eqos_remove,
 };
 
+static const struct dwc_eth_dwmac_data fsd_eqos_data = {
+	.probe = fsd_eqos_probe,
+	.remove = fsd_eqos_remove,
+};
+
 static int dwc_eth_dwmac_probe(struct platform_device *pdev)
 {
 	const struct dwc_eth_dwmac_data *data;
@@ -482,6 +653,7 @@  static void dwc_eth_dwmac_remove(struct platform_device *pdev)
 static const struct of_device_id dwc_eth_dwmac_match[] = {
 	{ .compatible = "snps,dwc-qos-ethernet-4.10", .data = &dwc_qos_data },
 	{ .compatible = "nvidia,tegra186-eqos", .data = &tegra_eqos_data },
+	{ .compatible = "tesla,dwc-qos-ethernet-4.21", .data = &fsd_eqos_data },
 	{ }
 };
 MODULE_DEVICE_TABLE(of, dwc_eth_dwmac_match);
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 733b5e900817..3c7d55786aaa 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -3883,6 +3883,12 @@  static int __stmmac_open(struct net_device *dev,
 	netif_tx_start_all_queues(priv->dev);
 	stmmac_enable_all_dma_irq(priv);
 
+	if (priv->plat->rxmux_setup) {
+		ret = priv->plat->rxmux_setup(priv->plat->bsp_priv, true);
+		if (ret)
+			netdev_err(priv->dev, "Rxmux setup failed\n");
+	}
+
 	return 0;
 
 irq_error:
@@ -3936,7 +3942,13 @@  static void stmmac_fpe_stop_wq(struct stmmac_priv *priv)
 static int stmmac_release(struct net_device *dev)
 {
 	struct stmmac_priv *priv = netdev_priv(dev);
-	u32 chan;
+	u32 chan, ret;
+
+	if (priv->plat->rxmux_setup) {
+		ret = priv->plat->rxmux_setup(priv->plat->bsp_priv, false);
+		if (ret)
+			netdev_err(priv->dev, "Rxmux setup failed\n");
+	}
 
 	if (device_may_wakeup(priv->device))
 		phylink_speed_down(priv->phylink, false);
@@ -7630,11 +7642,17 @@  int stmmac_suspend(struct device *dev)
 {
 	struct net_device *ndev = dev_get_drvdata(dev);
 	struct stmmac_priv *priv = netdev_priv(ndev);
-	u32 chan;
+	u32 chan, ret;
 
 	if (!ndev || !netif_running(ndev))
 		return 0;
 
+	if (priv->plat->rxmux_setup) {
+		ret = priv->plat->rxmux_setup(priv->plat->bsp_priv, false);
+		if (ret)
+			netdev_err(priv->dev, "Rxmux setup failed\n");
+	}
+
 	mutex_lock(&priv->lock);
 
 	netif_device_detach(ndev);
@@ -7799,6 +7817,12 @@  int stmmac_resume(struct device *dev)
 	mutex_unlock(&priv->lock);
 	rtnl_unlock();
 
+	if (priv->plat->rxmux_setup) {
+		ret = priv->plat->rxmux_setup(priv->plat->bsp_priv, true);
+		if (ret)
+			netdev_err(priv->dev, "Rxmux setup failed\n");
+	}
+
 	netif_device_attach(ndev);
 
 	return 0;
diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
index 784277d666eb..69150c8c8df7 100644
--- a/include/linux/stmmac.h
+++ b/include/linux/stmmac.h
@@ -264,6 +264,7 @@  struct plat_stmmacenet_data {
 	void (*ptp_clk_freq_config)(struct stmmac_priv *priv);
 	int (*init)(struct platform_device *pdev, void *priv);
 	void (*exit)(struct platform_device *pdev, void *priv);
+	int (*rxmux_setup)(void *priv, bool external);
 	struct mac_device_info *(*setup)(void *priv);
 	int (*clks_config)(void *priv, bool enabled);
 	int (*crosststamp)(ktime_t *device, struct system_counterval_t *system,