Re: [PATCH] net: dsa: mt7530: disable LEDs before reset
flat view
From: Justin Swartz <hidden>
Date: 2024-03-12 16:35:57
Also in:
linux-mediatek, lkml, netdev
Possibly related (same subject, not in this thread)
- 2024-03-12 · Re: [PATCH] net: dsa: mt7530: disable LEDs before reset · Justin Swartz <hidden>
- 2024-03-12 · Re: [PATCH] net: dsa: mt7530: disable LEDs before reset · Paolo Abeni <pabeni@redhat.com>
- 2024-03-12 · Re: [PATCH] net: dsa: mt7530: disable LEDs before reset · Andrew Lunn <andrew@lunn.ch>
- 2024-03-12 · Re: [PATCH] net: dsa: mt7530: disable LEDs before reset · Justin Swartz <hidden>
- 2024-03-11 · Re: [PATCH] net: dsa: mt7530: disable LEDs before reset · Daniel Golle <daniel@makrotopia.org>
On 2024-03-12 17:25, Justin Swartz wrote:
On 2024-03-12 16:06, Arınç ÜNAL wrote:quoted
On 12.03.2024 15:01, Justin Swartz wrote:quoted
Arınç On 2024-03-12 04:41, Arınç ÜNAL wrote:quoted
Wouldn't it be a better idea to increase the delay between reset_control_assert() and reset_control_deassert(), and gpiod_set_value_cansleep(priv->reset, 0) and gpiod_set_value_cansleep(priv->reset, 1) instead of disabling the LED controller and delaying before reset?I've done some additional tests to see what the difference would be between increasing the reset hold period vs. disabling the LEDs then sleeping before reset. I wanted to know: When an active link is present on Port 3 at boot, what are the minimum, maximum and average periods between ESW_P3_LED_0 going low and the signal inversion that seems to co-incide with reset_control_deassert() for each approach? I created two patches: WITH INCREASED RESET DELAY As I submitted a patch that added an intended 1000 - 1100 usec delay before reset, I thought it would be fair to increase the reset hold period by the same value. ---%------ a/drivers/net/dsa/mt7530.c +++ b/drivers/net/dsa/mt7530.c@@ -2243,11 +2243,11 @@ mt7530_setup(struct dsa_switch *ds) */ if (priv->mcm) { reset_control_assert(priv->rstc); - usleep_range(1000, 1100); + usleep_range(2000, 2200); reset_control_deassert(priv->rstc); } else { gpiod_set_value_cansleep(priv->reset, 0); - usleep_range(1000, 1100); + usleep_range(2000, 2200); gpiod_set_value_cansleep(priv->reset, 1); } ---%---DISABLE LEDS BEFORE RESET Reset hold period unchanged from the intended 1000 - 1100 usec. ---%------ a/drivers/net/dsa/mt7530.c +++ b/drivers/net/dsa/mt7530.c@@ -2238,6 +2238,12 @@ mt7530_setup(struct dsa_switch *ds) } } + /* Disable LEDs before reset to prevent the MT7530 sampling a + * potentially incorrect HT_XTAL_FSEL value. + */ + mt7530_write(priv, MT7530_LED_EN, 0); + usleep_range(1000, 1100); + /* Reset whole chip through gpio pin or memory-mapped registers for * different type of hardware */ ---%---I ran 20 tests per patch, applied exclusively. 40 tests in total. <-- ESW_P3_LED_0 Low Period before Reset Deassertion --> TEST WITH INCREASED RESET DELAY DISABLE LEDS BEFORE RESET # (usec) (usec) ------------------------------------------------------------------- 1 182 4790 2 370 3470 3 240 4635 4 1475 4850 5 70 4775 6 2730 4575 7 3180 4565 8 265 5650 9 270 4690 10 1525 4450 11 3210 4735 12 120 4690 13 185 4625 14 305 7020 15 2975 4720 16 245 4675 17 350 4740 18 80 17920 19 150 17665 20 100 4620 Min 70 3470 Max 3210 17920 Mean 270 4720-1s/ Mean/Median/quoted
quoted
Avg 923.421 6161.579 Every test resulted in a 40MHz HT_XTAL_FSEL, but after seeing 70 usec and 80 usec periods I wondered how many more tests it may take before an 25MHz HT_XTAL_FSEL appears. I was also surprised by the 17920 usec and 17665 usec periods listed under the DISABLED LEDS BEFORE RESET column. Nothing unusual seemed to be happening, at least as far as the kernel message output was concerned. What do you make of these results?What I see is setting ESW_P3_LED_0 low via reset assertion is much more efficient than doing so by setting the LED controller off. So I'd prefer increasing the delay between assertion and reassertion. For example, the Realtek DSA subdriver has a much more generous delay. 25ms after reset assertion [1]. Looking at your results, 2000 - 2200 usec delay still seems too close, so let's agree on an amount that will ensure that boards in any circumstances will have these pins back to the bootstrapping configuration before reset deassertion. What about 5000 - 5100 usec?TEST ESW_P3_LED_0 LOW PERIOD # (usec) ---------------------------------- 1 5410 2 5440 3 4375 4 5490 5 5475 6 4335 7 4370 8 5435 9 4205 10 4335 11 3750 12 3170 13 4395 14 4375 15 3515 16 4335 17 4220 18 4175 19 4175 20 4350 Min 3170 Max 5490 Median 4342.500 Avg 4466.500 Looks reasonable to me.
I had messed up the Median/Average calculation with the data
I had pasted earlier after copying and pasting formulas without
double checking how they had been affected.
So here's the table again, now with the 5000 - 5100 usec test
run tacked on for easier comparison:
2000 usec 5000 usec
- 2200 usec DISABLE LEDS - 5100 usec
TEST RESET HOLD BEFORE RESET RESET HOLD
# (usec) (usec) (usec)
--------------------------------------------------------
1 182 4790 5410
2 370 3470 5440
3 240 4635 4375
4 1475 4850 5490
5 70 4775 5475
6 2730 4575 4335
7 3180 4565 4370
8 265 5650 5435
9 270 4690 4205
10 1525 4450 4335
11 3210 4735 3750
12 120 4690 3170
13 185 4625 4395
14 305 7020 4375
15 2975 4720 3515
16 245 4675 4335
17 350 4740 4220
18 80 17920 4175
19 150 17665 4175
20 100 4620 4350
Min 70 3470 3170
Max 3210 17920 5490
Median 267.500 4705 4342.500
Avg 901.350 6093 4466.500
_______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel