With the dma conf being reallocated on each call to stmmac_open(), any
information in there is lost, unless we specifically handle it.
The STMMAC_TBS_EN bit is set when adding an etf qdisc, and the etf qdisc
therefore would stop working when link was set down and then back up.
Fixes: ba39b344e924 ("net: ethernet: stmicro: stmmac: generate stmmac dma conf before open")
Cc: [email protected]
Signed-off-by: Esben Haabendal <[email protected]>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index a0e46369ae15..691bf3ef5e30 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -3932,6 +3932,9 @@ static int __stmmac_open(struct net_device *dev,
priv->rx_copybreak = STMMAC_RX_COPYBREAK;
buf_sz = dma_conf->dma_buf_sz;
+ for (int i = 0; i < MTL_MAX_TX_QUEUES; i++)
+ if (priv->dma_conf.tx_queue[i].tbs & STMMAC_TBS_EN)
+ dma_conf->tx_queue[i].tbs = priv->dma_conf.tx_queue[i].tbs;
memcpy(&priv->dma_conf, dma_conf, sizeof(*dma_conf));
stmmac_reset_queues_param(priv);
--
2.43.0
Time Based Scheduling can be enabled per TX queue, if supported by the
controller.
Signed-off-by: Esben Haabendal <[email protected]>
---
Documentation/devicetree/bindings/net/snps,dwmac.yaml | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
index 5c2769dc689a..301e9150ecc3 100644
--- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
@@ -399,6 +399,12 @@ properties:
type: boolean
description: TX checksum offload is unsupported by the TX queue.
+ snps,time-based-scheduling:
+ type: boolean
+ description:
+ Time Based Scheduling will be enabled for TX queue.
+ This is typically not supported for TX queue 0.
+
allOf:
- if:
required:
--
2.43.0
This allows enabling TBS for TX queues by adding the
snps,time-based-scheduling property. You should check for support for this
on your particular controller before enabling. Typically, TX queue 0 does
not support TBS.
Signed-off-by: Esben Haabendal <[email protected]>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 70eadc83ca68..f0bb49b0f41c 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -278,6 +278,8 @@ static int stmmac_mtl_setup(struct platform_device *pdev,
plat->tx_queues_cfg[queue].coe_unsupported =
of_property_read_bool(q_node, "snps,coe-unsupported");
+ plat->tx_queues_cfg[queue].tbs_en =
+ of_property_read_bool(q_node, "snps,time-based-scheduling");
queue++;
}
--
2.43.0
On Wed, Jan 24, 2024 at 03:33:06PM +0100, Esben Haabendal wrote:
> Time Based Scheduling can be enabled per TX queue, if supported by the
> controller.
If time based scheduling is not supported by the controller, then the
property should not be present! The presence of a property like this
should mean that the feature is supported, using it is up to the
operating system.
That said, why is this a property that should be in DT? If support is
per controller is it not sufficient to use the compatible to determine
if this is supported?
Thanks,
Conor.
>
> Signed-off-by: Esben Haabendal <[email protected]>
> ---
> Documentation/devicetree/bindings/net/snps,dwmac.yaml | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> index 5c2769dc689a..301e9150ecc3 100644
> --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> @@ -399,6 +399,12 @@ properties:
> type: boolean
> description: TX checksum offload is unsupported by the TX queue.
>
> + snps,time-based-scheduling:
> + type: boolean
> + description:
> + Time Based Scheduling will be enabled for TX queue.
> + This is typically not supported for TX queue 0.
> +
> allOf:
> - if:
> required:
> --
> 2.43.0
>
On 25/01/2024 10:10, [email protected] wrote:
> Conor Dooley <[email protected]> writes:
>
>> On Wed, Jan 24, 2024 at 03:33:06PM +0100, Esben Haabendal wrote:
>>> Time Based Scheduling can be enabled per TX queue, if supported by the
>>> controller.
>>
>> If time based scheduling is not supported by the controller, then the
>> property should not be present! The presence of a property like this
>> should mean that the feature is supported, using it is up to the
>> operating system.
>>
>> That said, why is this a property that should be in DT?
>
> It is added to the tx-queues-config object of snps,dwmac bindings. This
> entire object is about configuration of the ethernet controller, which
> is also what the purpose of the snps,time-based-scheduling.
> So yes, it is not specifically about describing what the hardware is
> capable of, but how the hardware is configured. It is a continuation of
> the current driver design.
>
>> If support is per controller is it not sufficient to use the
>> compatible to determine if this is supported?
>
> Are you suggesting to include the mapping from all supported compatible
> controllers to which TX queues supports TBS in the driver code? What
> would the benefit of that compared to describing it explicitly in the
> binding?
The benefit is complying with DT bindings rules, saying that bindings
describe hardware pieces, not drivers.
> And for the purpose of the above question, I am talking about it as if
> the binding was describing the hardware capability and not the
> configuration.
"if"? You wrote it is for driver design...
Best regards,
Krzysztof
Conor Dooley <[email protected]> writes:
> On Wed, Jan 24, 2024 at 03:33:06PM +0100, Esben Haabendal wrote:
>> Time Based Scheduling can be enabled per TX queue, if supported by the
>> controller.
>
> If time based scheduling is not supported by the controller, then the
> property should not be present! The presence of a property like this
> should mean that the feature is supported, using it is up to the
> operating system.
>
> That said, why is this a property that should be in DT?
It is added to the tx-queues-config object of snps,dwmac bindings. This
entire object is about configuration of the ethernet controller, which
is also what the purpose of the snps,time-based-scheduling.
So yes, it is not specifically about describing what the hardware is
capable of, but how the hardware is configured. It is a continuation of
the current driver design.
> If support is per controller is it not sufficient to use the
> compatible to determine if this is supported?
Are you suggesting to include the mapping from all supported compatible
controllers to which TX queues supports TBS in the driver code? What
would the benefit of that compared to describing it explicitly in the
binding?
And for the purpose of the above question, I am talking about it as if
the binding was describing the hardware capability and not the
configuration.
/Esben
>> Signed-off-by: Esben Haabendal <[email protected]>
>> ---
>> Documentation/devicetree/bindings/net/snps,dwmac.yaml | 6 ++++++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
>> index 5c2769dc689a..301e9150ecc3 100644
>> --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
>> +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
>> @@ -399,6 +399,12 @@ properties:
>> type: boolean
>> description: TX checksum offload is unsupported by the TX queue.
>>
>> + snps,time-based-scheduling:
>> + type: boolean
>> + description:
>> + Time Based Scheduling will be enabled for TX queue.
>> + This is typically not supported for TX queue 0.
>> +
>> allOf:
>> - if:
>> required:
>> --
>> 2.43.0
>>
Hi,
On Wed Jan 24 2024, Esben Haabendal wrote:
> This allows enabling TBS for TX queues by adding the
> snps,time-based-scheduling property. You should check for support for this
> on your particular controller before enabling. Typically, TX queue 0 does
> not support TBS.
More a general question: Do i see that correctly that Launch Time does
not work for OF platforms (such as an imx93) at the moment, because the
tbs_en property is not configured? Or why are these patches necessary?
Thanks,
Kurt
Krzysztof Kozlowski <[email protected]> writes:
> On 25/01/2024 10:10, [email protected] wrote:
>> Conor Dooley <[email protected]> writes:
>>
>>> On Wed, Jan 24, 2024 at 03:33:06PM +0100, Esben Haabendal wrote:
>>>> Time Based Scheduling can be enabled per TX queue, if supported by the
>>>> controller.
>>>
>>> If time based scheduling is not supported by the controller, then the
>>> property should not be present! The presence of a property like this
>>> should mean that the feature is supported, using it is up to the
>>> operating system.
>>>
>>> That said, why is this a property that should be in DT?
>>
>> It is added to the tx-queues-config object of snps,dwmac bindings. This
>> entire object is about configuration of the ethernet controller, which
>> is also what the purpose of the snps,time-based-scheduling.
>> So yes, it is not specifically about describing what the hardware is
>> capable of, but how the hardware is configured. It is a continuation of
>> the current driver design.
>>
>>> If support is per controller is it not sufficient to use the
>>> compatible to determine if this is supported?
>>
>> Are you suggesting to include the mapping from all supported compatible
>> controllers to which TX queues supports TBS in the driver code? What
>> would the benefit of that compared to describing it explicitly in the
>> binding?
>
> The benefit is complying with DT bindings rules, saying that bindings
> describe hardware pieces, not drivers.
Understood.
>> And for the purpose of the above question, I am talking about it as if
>> the binding was describing the hardware capability and not the
>> configuration.
>
> "if"? You wrote it is for driver design...
If you look at the current driver, all the devicetree bindings under
rx-queues-config and tx-queues-config are violating the DT binding
rules.
Cleaning up that requires quite some work and I guess will break
backwards compatibility to some extend.
But that is another story.
I will respin the patch according to Conor's suggestion.
/Esben
Kurt Kanzenbach <[email protected]> writes:
> Hi,
>
> On Wed Jan 24 2024, Esben Haabendal wrote:
>> This allows enabling TBS for TX queues by adding the
>> snps,time-based-scheduling property. You should check for support for this
>> on your particular controller before enabling. Typically, TX queue 0 does
>> not support TBS.
>
> More a general question: Do i see that correctly that Launch Time does
> not work for OF platforms (such as an imx93) at the moment, because the
> tbs_en property is not configured? Or why are these patches necessary?
Correct. You cannot use etf qdisc with "offload" on for OF platforms,
including imx93.
Doing that will end with "return -EINVAL" in tc_setup_etf().
I am working with imx98mp, but there should not be any difference for
imx93.
/Esben
On Thu, Jan 25, 2024 at 12:55:12PM +0100, [email protected] wrote:
> Krzysztof Kozlowski <[email protected]> writes:
>
> > On 25/01/2024 10:10, [email protected] wrote:
> >> Conor Dooley <[email protected]> writes:
> >>
> >>> On Wed, Jan 24, 2024 at 03:33:06PM +0100, Esben Haabendal wrote:
> >>>> Time Based Scheduling can be enabled per TX queue, if supported by the
> >>>> controller.
> >>>
> >>> If time based scheduling is not supported by the controller, then the
> >>> property should not be present! The presence of a property like this
> >>> should mean that the feature is supported, using it is up to the
> >>> operating system.
> >>>
> >>> That said, why is this a property that should be in DT?
> >>
> >> It is added to the tx-queues-config object of snps,dwmac bindings. This
> >> entire object is about configuration of the ethernet controller, which
> >> is also what the purpose of the snps,time-based-scheduling.
> >> So yes, it is not specifically about describing what the hardware is
> >> capable of, but how the hardware is configured. It is a continuation of
> >> the current driver design.
> >>
> >>> If support is per controller is it not sufficient to use the
> >>> compatible to determine if this is supported?
> >>
> >> Are you suggesting to include the mapping from all supported compatible
> >> controllers to which TX queues supports TBS in the driver code? What
> >> would the benefit of that compared to describing it explicitly in the
> >> binding?
> >
> > The benefit is complying with DT bindings rules, saying that bindings
> > describe hardware pieces, not drivers.
>
> Understood.
>
> >> And for the purpose of the above question, I am talking about it as if
> >> the binding was describing the hardware capability and not the
> >> configuration.
> >
> > "if"? You wrote it is for driver design...
>
> If you look at the current driver, all the devicetree bindings under
> rx-queues-config and tx-queues-config are violating the DT binding
> rules.
> Cleaning up that requires quite some work and I guess will break
> backwards compatibility to some extend.
Let bygones be bygones. If something undesirable got in previously,
breaking backwards compatibility there is not justified IMO.
On Wed, Jan 24, 2024 at 03:33:06PM +0100, Esben Haabendal wrote:
> Time Based Scheduling can be enabled per TX queue, if supported by the
> controller.
>
> Signed-off-by: Esben Haabendal <[email protected]>
> ---
> Documentation/devicetree/bindings/net/snps,dwmac.yaml | 6 ++++++
> 1 file changed, 6 insertions(+)
This is not v1 which you are aware. Where's the justification or do I
need to ask the same questions again? Here's the last discussion[1].
I'm still not clear on why this is needed. Seems like the combination of
TBS and TSO capabilities provides enough information. If TSO is enabled
for a queue, then don't enable TBS.
This binding is already such a mess of properties, I'm inclined to say
"what's one more", but it's death by 1000 cuts. Part of the problem is
this binding is for not 1 IP block, but something that's evolved over
at least 15 years.
The question on configuration properties really comes down to who would
configure things and when. If it's one time for the life of given h/w,
then DT makes sense. If every user wants/needs to tweak the setting,
then definitely shouldn't be in DT. Somewhere in the middle? Judgement
call.
> diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> index 5c2769dc689a..301e9150ecc3 100644
> --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> @@ -399,6 +399,12 @@ properties:
> type: boolean
> description: TX checksum offload is unsupported by the TX queue.
>
> + snps,time-based-scheduling:
> + type: boolean
> + description:
> + Time Based Scheduling will be enabled for TX queue.
> + This is typically not supported for TX queue 0.
Make the property name clear it is an enable, not a capability.
> +
[1] https://lore.kernel.org/all/[email protected]/
Rob Herring <[email protected]> writes:
> On Wed, Jan 24, 2024 at 03:33:06PM +0100, Esben Haabendal wrote:
>> Time Based Scheduling can be enabled per TX queue, if supported by the
>> controller.
>>
>> Signed-off-by: Esben Haabendal <[email protected]>
>> ---
>> Documentation/devicetree/bindings/net/snps,dwmac.yaml | 6 ++++++
>> 1 file changed, 6 insertions(+)
>
> This is not v1 which you are aware. Where's the justification or do I
> need to ask the same questions again? Here's the last discussion[1].
Yes, I am aware. I must admit I only spotted the last discussion you are
referring to after submitting my version of it. Sorry about that.
> I'm still not clear on why this is needed. Seems like the combination
> of TBS and TSO capabilities provides enough information. If TSO is
> enabled for a queue, then don't enable TBS.
> This binding is already such a mess of properties, I'm inclined to say
> "what's one more", but it's death by 1000 cuts. Part of the problem is
> this binding is for not 1 IP block, but something that's evolved over
> at least 15 years.
It definitely is a mess. A lot of these properties are not the type of
properties that I think would be accepted today, as there is a lot of
configuration like properties there.
> The question on configuration properties really comes down to who
> would configure things and when. If it's one time for the life of
> given h/w, then DT makes sense. If every user wants/needs to tweak the
> setting, then definitely shouldn't be in DT. Somewhere in the middle?
> Judgement call.
Some of the existsing configuration properties in there is something
that users will need to tweak, such as the selection of queue scheduling
and priority algorithms.
The TBS vs TSO is probably somewhere in the middle. It might just be
that choosing TSO for TX queue 0, and TBS for the remaining ones are
something that everybody can agree on. But I am not really sure about
that.
I think we should drop this binding.
I have found another simple solution for i.MX, which does not involve
new bindings.
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=3b12ec8f618e
Improving on that, I think we should make switching between TSO and TBS
a run-time configurable thing, instead of creating binding for it.
But I am unsure if that is really worth it.
/Esben
>
>> diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
>> index 5c2769dc689a..301e9150ecc3 100644
>> --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
>> +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
>> @@ -399,6 +399,12 @@ properties:
>> type: boolean
>> description: TX checksum offload is unsupported by the TX queue.
>>
>> + snps,time-based-scheduling:
>> + type: boolean
>> + description:
>> + Time Based Scheduling will be enabled for TX queue.
>> + This is typically not supported for TX queue 0.
>
> Make the property name clear it is an enable, not a capability.
>
>> +
>
> [1] https://lore.kernel.org/all/[email protected]/