* [PATCH] soc: amlogic: clk-measure: Optimize measurement accuracy
@ 2025-07-17 3:08 Chuan Liu via B4 Relay
2025-07-17 15:43 ` Martin Blumenstingl
0 siblings, 1 reply; 5+ messages in thread
From: Chuan Liu via B4 Relay @ 2025-07-17 3:08 UTC (permalink / raw)
To: Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl
Cc: linux-arm-kernel, linux-amlogic, linux-kernel, Chuan Liu
From: Chuan Liu <chuan.liu@amlogic.com>
The cycle count register has a 20-bit effective width, but the driver
only utilizes 16 bits. This reduces the sampling window when measuring
high-frequency clocks, resulting in (slightly) degraded measurement
accuracy.
The input clock signal path from gate (Controlled by MSR_RUN) to internal
sampling circuit in clk-measure has a propagation delay requirement: 24
clock cycles must elapse after mux selection before sampling.
The measurement circuit employs single-edge sampling for clock frequency
detection, resulting in a ±1 cycle count error within the measurement window.
+1 cycle: 3 rising edges captured in 2-cycle measurement window.
__ __ __
__↑ |__↑ |__↑ |__
^ ^
-1 cycle: 2 rising edges captured in 3-cycle measurement window.
__ __ __
__↑ |__↑ |__↑ |__↑
^ ^
Change-Id: If367c013fe2a8d0c8f5f06888bb8f30a1e46b927
Signed-off-by: Chuan Liu <chuan.liu@amlogic.com>
---
Improve measurement accuracy by increasing the bit width of the cycle
counter register and adding delay during measurement.
The 800μs delay between enabling the input clock gate and activating
sampling is determined by the minimum sampling frequency of 30kHz (the
lowest commonly used frequency in applications is 32.768kHz).
Here are the test comparisons based on C3:
Pre-optimization:
cat /sys/kernel/debug/meson-clk-msr/measure_summary
clock rate precision
---------------------------------------------
sys_clk 166664063 +/-5208Hz
axi_clk 499968750 +/-15625Hz
rtc_clk 23982813 +/-3125Hz
p20_usb2_ckout 479968750 +/-15625Hz
eth_mpll_test 499992188 +/-15625Hz
sys_pll 1919875000 +/-62500Hz
cpu_clk_div16 119998162 +/-3676Hz
ts_pll 0 +/-3125Hz
fclk_div2 999843750 +/-31250Hz
fclk_div2p5 799953125 +/-31250Hz
fclk_div3 666625000 +/-20833Hz
fclk_div4 499914063 +/-15625Hz
fclk_div5 399987500 +/-12500Hz
fclk_div7 285709821 +/-8928Hz
fclk_50m 49982813 +/-3125Hz
sys_oscin32k_i 26563 +/-3125Hz
Post-optimization:
cat /sys/kernel/debug/meson-clk-msr/measure_summary
clock rate precision
---------------------------------------------
sys_clk 166665625 +/-1562Hz
axi_clk 499996875 +/-1562Hz
rtc_clk 24000000 +/-1562Hz
p20_usb2_ckout 479996875 +/-1562Hz
eth_mpll_test 499996875 +/-1562Hz
sys_pll 1919987132 +/-1838Hz
cpu_clk_div16 119998438 +/-1562Hz
ts_pll 0 +/-1562Hz
fclk_div2 999993750 +/-1562Hz
fclk_div2p5 799995313 +/-1562Hz
fclk_div3 666656250 +/-1562Hz
fclk_div4 499996875 +/-1562Hz
fclk_div5 399993750 +/-1562Hz
fclk_div7 285712500 +/-1562Hz
fclk_50m 49998438 +/-1562Hz
sys_oscin32k_i 32813 +/-1562Hz
---
drivers/soc/amlogic/meson-clk-measure.c | 27 ++++++++++++++++++---------
1 file changed, 18 insertions(+), 9 deletions(-)
diff --git a/drivers/soc/amlogic/meson-clk-measure.c b/drivers/soc/amlogic/meson-clk-measure.c
index d862e30a244e..82acd8635bf8 100644
--- a/drivers/soc/amlogic/meson-clk-measure.c
+++ b/drivers/soc/amlogic/meson-clk-measure.c
@@ -22,7 +22,7 @@ static DEFINE_MUTEX(measure_lock);
#define MSR_CLK_SRC GENMASK(26, 20)
#define MSR_BUSY BIT(31)
-#define MSR_VAL_MASK GENMASK(15, 0)
+#define MSR_VAL_MASK GENMASK(19, 0)
#define DIV_MIN 32
#define DIV_STEP 32
@@ -805,14 +805,23 @@ static int meson_measure_id(struct meson_msr_id *clk_msr_id,
regmap_update_bits(priv->regmap, reg->freq_ctrl, MSR_DURATION,
FIELD_PREP(MSR_DURATION, duration - 1));
- /* Set ID */
- regmap_update_bits(priv->regmap, reg->freq_ctrl, MSR_CLK_SRC,
- FIELD_PREP(MSR_CLK_SRC, clk_msr_id->id));
+ /* Set the clock channel ID and enable the input clock gate. */
+ regmap_update_bits(priv->regmap, reg->freq_ctrl, MSR_CLK_SRC | MSR_RUN,
+ FIELD_PREP(MSR_CLK_SRC, clk_msr_id->id) | MSR_RUN);
- /* Enable & Start */
- regmap_update_bits(priv->regmap, reg->freq_ctrl,
- MSR_RUN | MSR_ENABLE,
- MSR_RUN | MSR_ENABLE);
+ /*
+ * HACK: The input clock signal path from gate (Controlled by MSR_RUN)
+ * to internal sampling circuit in clk-measure has a propagation delay
+ * requirement: 24 clock cycles must elapse after mux selection before
+ * sampling.
+ *
+ * For a 30kHz measurement clock, this translates to an 800μs delay:
+ * 800us = 24 / 30000Hz.
+ */
+ fsleep(800);
+
+ /* Enable the internal sampling circuit and start clock measurement. */
+ regmap_update_bits(priv->regmap, reg->freq_ctrl, MSR_ENABLE, MSR_ENABLE);
ret = regmap_read_poll_timeout(priv->regmap, reg->freq_ctrl,
val, !(val & MSR_BUSY), 10, 10000);
@@ -846,7 +855,7 @@ static int meson_measure_best_id(struct meson_msr_id *clk_msr_id,
do {
ret = meson_measure_id(clk_msr_id, duration);
if (ret >= 0)
- *precision = (2 * 1000000) / duration;
+ *precision = 1000000 / duration;
else
duration -= DIV_STEP;
} while (duration >= DIV_MIN && ret == -EINVAL);
---
base-commit: 87b480e04af45833deb5af1584694b0077805ea6
change-id: 20250523-optimize_clk-measure_accuracy-9e16ee346dd2
Best regards,
--
Chuan Liu <chuan.liu@amlogic.com>
_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH] soc: amlogic: clk-measure: Optimize measurement accuracy
2025-07-17 3:08 [PATCH] soc: amlogic: clk-measure: Optimize measurement accuracy Chuan Liu via B4 Relay
@ 2025-07-17 15:43 ` Martin Blumenstingl
2025-07-18 6:13 ` Chuan Liu
0 siblings, 1 reply; 5+ messages in thread
From: Martin Blumenstingl @ 2025-07-17 15:43 UTC (permalink / raw)
To: chuan.liu
Cc: Neil Armstrong, Kevin Hilman, Jerome Brunet, linux-arm-kernel,
linux-amlogic, linux-kernel
Hello,
thank you for this patch!
On Thu, Jul 17, 2025 at 5:08 AM Chuan Liu via B4 Relay
<devnull+chuan.liu.amlogic.com@kernel.org> wrote:
>
> From: Chuan Liu <chuan.liu@amlogic.com>
>
> The cycle count register has a 20-bit effective width, but the driver
> only utilizes 16 bits. This reduces the sampling window when measuring
> high-frequency clocks, resulting in (slightly) degraded measurement
> accuracy.
I checked the Meson8 downstream code [0] and it uses 0x000FFFFF to
mask the register value -> this means that old SoCs also have a 20-bit
wide width.
[...]
> Here are the test comparisons based on C3:
[...]
> Here are the test comparisons based on C3:
I have tested this patch with Meson8b based Odroid-C1:
pre-optimization:
# time cat /sys/kernel/debug/meson-clk-msr/measure_summary | grep -v " 0 "
clock rate precision
---------------------------------------------
clk81 159372396 +/-5208Hz
a9_clk_div16 24000000 +/-3125Hz
rtc_osc_clk_out 31250 +/-3125Hz
hdmi_ch0_tmds 146399038 +/-4807Hz
sar_adc 1140625 +/-3125Hz
sdhc_rx 94443750 +/-3125Hz
sdhc_sd 94443750 +/-3125Hz
pwm_d 849921875 +/-31250Hz
pwm_c 849921875 +/-31250Hz
real 0m0.102s
user 0m0.005s
sys 0m0.069s
post-optimization:
# time cat /sys/kernel/debug/meson-clk-msr/measure_summary | grep -v " 0 "
clock rate precision
---------------------------------------------
clk81 159373438 +/-1562Hz
a9_clk_div16 12000000 +/-1562Hz
rtc_osc_clk_out 32813 +/-1562Hz
hdmi_ch0_tmds 146398438 +/-1562Hz
sar_adc 1143750 +/-1562Hz
sdhc_rx 94443750 +/-1562Hz
sdhc_sd 94443750 +/-1562Hz
pwm_d 849992188 +/-1562Hz
pwm_c 849992188 +/-1562Hz
real 0m0.173s
user 0m0.008s
sys 0m0.109s
So there's also an improvement in accuracy. The only downside I'm
seeing is that it takes 75% extra time for the measurement. For me
this is irrelevant since we use this for debugging.
[...]
> + /*
> + * HACK: The input clock signal path from gate (Controlled by MSR_RUN)
> + * to internal sampling circuit in clk-measure has a propagation delay
> + * requirement: 24 clock cycles must elapse after mux selection before
> + * sampling.
> + *
> + * For a 30kHz measurement clock, this translates to an 800μs delay:
> + * 800us = 24 / 30000Hz.
> + */
> + fsleep(800);
What is needed to make this not a HACK anymore? Is there a register
that we can poll for the number of clock cycles that have passed?
Best regards,
Martin
_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] soc: amlogic: clk-measure: Optimize measurement accuracy
2025-07-17 15:43 ` Martin Blumenstingl
@ 2025-07-18 6:13 ` Chuan Liu
2025-07-21 20:16 ` Martin Blumenstingl
0 siblings, 1 reply; 5+ messages in thread
From: Chuan Liu @ 2025-07-18 6:13 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: Neil Armstrong, Kevin Hilman, Jerome Brunet, linux-arm-kernel,
linux-amlogic, linux-kernel
hi Marti:
On 7/17/2025 11:43 PM, Martin Blumenstingl wrote:
> [ EXTERNAL EMAIL ]
>
> Hello,
>
> thank you for this patch!
>
> On Thu, Jul 17, 2025 at 5:08 AM Chuan Liu via B4 Relay
> <devnull+chuan.liu.amlogic.com@kernel.org> wrote:
>> From: Chuan Liu <chuan.liu@amlogic.com>
>>
>> The cycle count register has a 20-bit effective width, but the driver
>> only utilizes 16 bits. This reduces the sampling window when measuring
>> high-frequency clocks, resulting in (slightly) degraded measurement
>> accuracy.
> I checked the Meson8 downstream code [0] and it uses 0x000FFFFF to
> mask the register value -> this means that old SoCs also have a 20-bit
> wide width.
>
> [...]
>> Here are the test comparisons based on C3:
> [...]
>> Here are the test comparisons based on C3:
> I have tested this patch with Meson8b based Odroid-C1:
> pre-optimization:
> # time cat /sys/kernel/debug/meson-clk-msr/measure_summary | grep -v " 0 "
> clock rate precision
> ---------------------------------------------
> clk81 159372396 +/-5208Hz
> a9_clk_div16 24000000 +/-3125Hz
> rtc_osc_clk_out 31250 +/-3125Hz
> hdmi_ch0_tmds 146399038 +/-4807Hz
> sar_adc 1140625 +/-3125Hz
> sdhc_rx 94443750 +/-3125Hz
> sdhc_sd 94443750 +/-3125Hz
> pwm_d 849921875 +/-31250Hz
> pwm_c 849921875 +/-31250Hz
>
> real 0m0.102s
> user 0m0.005s
> sys 0m0.069s
>
>
> post-optimization:
> # time cat /sys/kernel/debug/meson-clk-msr/measure_summary | grep -v " 0 "
> clock rate precision
> ---------------------------------------------
> clk81 159373438 +/-1562Hz
> a9_clk_div16 12000000 +/-1562Hz
> rtc_osc_clk_out 32813 +/-1562Hz
> hdmi_ch0_tmds 146398438 +/-1562Hz
> sar_adc 1143750 +/-1562Hz
> sdhc_rx 94443750 +/-1562Hz
> sdhc_sd 94443750 +/-1562Hz
> pwm_d 849992188 +/-1562Hz
> pwm_c 849992188 +/-1562Hz
>
> real 0m0.173s
> user 0m0.008s
> sys 0m0.109s
>
> So there's also an improvement in accuracy. The only downside I'm
> seeing is that it takes 75% extra time for the measurement. For me
> this is irrelevant since we use this for debugging.
>
> [...]
>> + /*
>> + * HACK: The input clock signal path from gate (Controlled by MSR_RUN)
>> + * to internal sampling circuit in clk-measure has a propagation delay
>> + * requirement: 24 clock cycles must elapse after mux selection before
>> + * sampling.
>> + *
>> + * For a 30kHz measurement clock, this translates to an 800μs delay:
>> + * 800us = 24 / 30000Hz.
>> + */
>> + fsleep(800);
> What is needed to make this not a HACK anymore? Is there a register
> that we can poll for the number of clock cycles that have passed?
The required delay duration is frequency-dependent on the measurement
clock source. The current 800μs delay is calculated based on a
minimum input clock frequency of 30kHz. At higher input frequencies,
this delay could be proportionally reduced. Applying a uniform 800μs
delay therefore appears overly conservative for general use cases.
The IP currently lacks a status register to detect whether the input
clock signal has successfully propagated to the internal measurement
circuitry.
The design of this IP has been maintained for many years. From a
hardware design perspective, there is room for optimization in this
signal propagation delay. Future IP updates may not require such a
long delay.
>
> Best regards,
> Martin
_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] soc: amlogic: clk-measure: Optimize measurement accuracy
2025-07-18 6:13 ` Chuan Liu
@ 2025-07-21 20:16 ` Martin Blumenstingl
2025-07-22 2:32 ` Chuan Liu
0 siblings, 1 reply; 5+ messages in thread
From: Martin Blumenstingl @ 2025-07-21 20:16 UTC (permalink / raw)
To: Chuan Liu
Cc: Neil Armstrong, Kevin Hilman, Jerome Brunet, linux-arm-kernel,
linux-amlogic, linux-kernel
On Fri, Jul 18, 2025 at 8:14 AM Chuan Liu <chuan.liu@amlogic.com> wrote:
>
> hi Marti:
>
>
> On 7/17/2025 11:43 PM, Martin Blumenstingl wrote:
> > [ EXTERNAL EMAIL ]
> >
> > Hello,
> >
> > thank you for this patch!
> >
> > On Thu, Jul 17, 2025 at 5:08 AM Chuan Liu via B4 Relay
> > <devnull+chuan.liu.amlogic.com@kernel.org> wrote:
> >> From: Chuan Liu <chuan.liu@amlogic.com>
> >>
> >> The cycle count register has a 20-bit effective width, but the driver
> >> only utilizes 16 bits. This reduces the sampling window when measuring
> >> high-frequency clocks, resulting in (slightly) degraded measurement
> >> accuracy.
> > I checked the Meson8 downstream code [0] and it uses 0x000FFFFF to
> > mask the register value -> this means that old SoCs also have a 20-bit
> > wide width.
> >
> > [...]
> >> Here are the test comparisons based on C3:
> > [...]
> >> Here are the test comparisons based on C3:
> > I have tested this patch with Meson8b based Odroid-C1:
> > pre-optimization:
> > # time cat /sys/kernel/debug/meson-clk-msr/measure_summary | grep -v " 0 "
> > clock rate precision
> > ---------------------------------------------
> > clk81 159372396 +/-5208Hz
> > a9_clk_div16 24000000 +/-3125Hz
> > rtc_osc_clk_out 31250 +/-3125Hz
> > hdmi_ch0_tmds 146399038 +/-4807Hz
> > sar_adc 1140625 +/-3125Hz
> > sdhc_rx 94443750 +/-3125Hz
> > sdhc_sd 94443750 +/-3125Hz
> > pwm_d 849921875 +/-31250Hz
> > pwm_c 849921875 +/-31250Hz
> >
> > real 0m0.102s
> > user 0m0.005s
> > sys 0m0.069s
> >
> >
> > post-optimization:
> > # time cat /sys/kernel/debug/meson-clk-msr/measure_summary | grep -v " 0 "
> > clock rate precision
> > ---------------------------------------------
> > clk81 159373438 +/-1562Hz
> > a9_clk_div16 12000000 +/-1562Hz
> > rtc_osc_clk_out 32813 +/-1562Hz
> > hdmi_ch0_tmds 146398438 +/-1562Hz
> > sar_adc 1143750 +/-1562Hz
> > sdhc_rx 94443750 +/-1562Hz
> > sdhc_sd 94443750 +/-1562Hz
> > pwm_d 849992188 +/-1562Hz
> > pwm_c 849992188 +/-1562Hz
> >
> > real 0m0.173s
> > user 0m0.008s
> > sys 0m0.109s
> >
> > So there's also an improvement in accuracy. The only downside I'm
> > seeing is that it takes 75% extra time for the measurement. For me
> > this is irrelevant since we use this for debugging.
> >
> > [...]
> >> + /*
> >> + * HACK: The input clock signal path from gate (Controlled by MSR_RUN)
> >> + * to internal sampling circuit in clk-measure has a propagation delay
> >> + * requirement: 24 clock cycles must elapse after mux selection before
> >> + * sampling.
> >> + *
> >> + * For a 30kHz measurement clock, this translates to an 800μs delay:
> >> + * 800us = 24 / 30000Hz.
> >> + */
> >> + fsleep(800);
> > What is needed to make this not a HACK anymore? Is there a register
> > that we can poll for the number of clock cycles that have passed?
>
>
> The required delay duration is frequency-dependent on the measurement
> clock source. The current 800μs delay is calculated based on a
> minimum input clock frequency of 30kHz. At higher input frequencies,
> this delay could be proportionally reduced. Applying a uniform 800μs
> delay therefore appears overly conservative for general use cases.
>
>
> The IP currently lacks a status register to detect whether the input
> clock signal has successfully propagated to the internal measurement
> circuitry.
>
>
> The design of this IP has been maintained for many years. From a
> hardware design perspective, there is room for optimization in this
> signal propagation delay. Future IP updates may not require such a
> long delay.
Thanks for the detailed description. To me this doesn't seem like a
"hack" then, it's just something that's needed to interface with the
hardware correctly.
My suggestion is to replace the word "HACK" with "NOTE".
What do you think?
Best regards,
Martin
_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] soc: amlogic: clk-measure: Optimize measurement accuracy
2025-07-21 20:16 ` Martin Blumenstingl
@ 2025-07-22 2:32 ` Chuan Liu
0 siblings, 0 replies; 5+ messages in thread
From: Chuan Liu @ 2025-07-22 2:32 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: Neil Armstrong, Kevin Hilman, Jerome Brunet, linux-arm-kernel,
linux-amlogic, linux-kernel
On 7/22/2025 4:16 AM, Martin Blumenstingl wrote:
> [ EXTERNAL EMAIL ]
>
> On Fri, Jul 18, 2025 at 8:14 AM Chuan Liu <chuan.liu@amlogic.com> wrote:
>> hi Marti:
>>
>>
>> On 7/17/2025 11:43 PM, Martin Blumenstingl wrote:
>>> [ EXTERNAL EMAIL ]
>>>
>>> Hello,
>>>
>>> thank you for this patch!
>>>
>>> On Thu, Jul 17, 2025 at 5:08 AM Chuan Liu via B4 Relay
>>> <devnull+chuan.liu.amlogic.com@kernel.org> wrote:
>>>> From: Chuan Liu <chuan.liu@amlogic.com>
>>>>
>>>> The cycle count register has a 20-bit effective width, but the driver
>>>> only utilizes 16 bits. This reduces the sampling window when measuring
>>>> high-frequency clocks, resulting in (slightly) degraded measurement
>>>> accuracy.
>>> I checked the Meson8 downstream code [0] and it uses 0x000FFFFF to
>>> mask the register value -> this means that old SoCs also have a 20-bit
>>> wide width.
>>>
>>> [...]
>>>> Here are the test comparisons based on C3:
>>> [...]
>>>> Here are the test comparisons based on C3:
>>> I have tested this patch with Meson8b based Odroid-C1:
>>> pre-optimization:
>>> # time cat /sys/kernel/debug/meson-clk-msr/measure_summary | grep -v " 0 "
>>> clock rate precision
>>> ---------------------------------------------
>>> clk81 159372396 +/-5208Hz
>>> a9_clk_div16 24000000 +/-3125Hz
>>> rtc_osc_clk_out 31250 +/-3125Hz
>>> hdmi_ch0_tmds 146399038 +/-4807Hz
>>> sar_adc 1140625 +/-3125Hz
>>> sdhc_rx 94443750 +/-3125Hz
>>> sdhc_sd 94443750 +/-3125Hz
>>> pwm_d 849921875 +/-31250Hz
>>> pwm_c 849921875 +/-31250Hz
>>>
>>> real 0m0.102s
>>> user 0m0.005s
>>> sys 0m0.069s
>>>
>>>
>>> post-optimization:
>>> # time cat /sys/kernel/debug/meson-clk-msr/measure_summary | grep -v " 0 "
>>> clock rate precision
>>> ---------------------------------------------
>>> clk81 159373438 +/-1562Hz
>>> a9_clk_div16 12000000 +/-1562Hz
>>> rtc_osc_clk_out 32813 +/-1562Hz
>>> hdmi_ch0_tmds 146398438 +/-1562Hz
>>> sar_adc 1143750 +/-1562Hz
>>> sdhc_rx 94443750 +/-1562Hz
>>> sdhc_sd 94443750 +/-1562Hz
>>> pwm_d 849992188 +/-1562Hz
>>> pwm_c 849992188 +/-1562Hz
>>>
>>> real 0m0.173s
>>> user 0m0.008s
>>> sys 0m0.109s
>>>
>>> So there's also an improvement in accuracy. The only downside I'm
>>> seeing is that it takes 75% extra time for the measurement. For me
>>> this is irrelevant since we use this for debugging.
>>>
>>> [...]
>>>> + /*
>>>> + * HACK: The input clock signal path from gate (Controlled by MSR_RUN)
>>>> + * to internal sampling circuit in clk-measure has a propagation delay
>>>> + * requirement: 24 clock cycles must elapse after mux selection before
>>>> + * sampling.
>>>> + *
>>>> + * For a 30kHz measurement clock, this translates to an 800μs delay:
>>>> + * 800us = 24 / 30000Hz.
>>>> + */
>>>> + fsleep(800);
>>> What is needed to make this not a HACK anymore? Is there a register
>>> that we can poll for the number of clock cycles that have passed?
>>
>> The required delay duration is frequency-dependent on the measurement
>> clock source. The current 800μs delay is calculated based on a
>> minimum input clock frequency of 30kHz. At higher input frequencies,
>> this delay could be proportionally reduced. Applying a uniform 800μs
>> delay therefore appears overly conservative for general use cases.
>>
>>
>> The IP currently lacks a status register to detect whether the input
>> clock signal has successfully propagated to the internal measurement
>> circuitry.
>>
>>
>> The design of this IP has been maintained for many years. From a
>> hardware design perspective, there is room for optimization in this
>> signal propagation delay. Future IP updates may not require such a
>> long delay.
> Thanks for the detailed description. To me this doesn't seem like a
> "hack" then, it's just something that's needed to interface with the
> hardware correctly.
> My suggestion is to replace the word "HACK" with "NOTE".
>
> What do you think?
OK, thanks for your suggestion. I'll replace it with “NOTE” in the next
version.
>
> Best regards,
> Martin
_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2025-07-22 2:36 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-07-17 3:08 [PATCH] soc: amlogic: clk-measure: Optimize measurement accuracy Chuan Liu via B4 Relay
2025-07-17 15:43 ` Martin Blumenstingl
2025-07-18 6:13 ` Chuan Liu
2025-07-21 20:16 ` Martin Blumenstingl
2025-07-22 2:32 ` Chuan Liu
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).