From: Anson Huang <[email protected]>
This patch adds an optional property "clock-frequency" to pass
the system counter frequency value to kernel system counter
driver and indicate the driver to skip of_clk operations, this
is to support those platforms using platform driver model for
clock driver.
Signed-off-by: Anson Huang <[email protected]>
---
Documentation/devicetree/bindings/timer/nxp,sysctr-timer.txt | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/timer/nxp,sysctr-timer.txt b/Documentation/devicetree/bindings/timer/nxp,sysctr-timer.txt
index d576599..c9907a0 100644
--- a/Documentation/devicetree/bindings/timer/nxp,sysctr-timer.txt
+++ b/Documentation/devicetree/bindings/timer/nxp,sysctr-timer.txt
@@ -14,6 +14,11 @@ Required properties:
- clocks : Specifies the counter clock.
- clock-names: Specifies the clock's name of this module
+Optional properties:
+
+- clock-frequency : Specifies system counter clock frequency and indicates system
+ counter driver to skip clock operations.
+
Example:
system_counter: timer@306a0000 {
@@ -22,4 +27,5 @@ Example:
clocks = <&clk_8m>;
clock-names = "per";
interrupts = <GIC_SPI 47 IRQ_TYPE_LEVEL_HIGH>;
+ clock-frequency = <8333333>;
};
--
2.7.4
From: Anson Huang <[email protected]>
On some i.MX8M platforms, clock driver uses platform driver
model and it is NOT ready during timer initialization phase,
the clock operations will fail and system counter driver will
fail too. As all the i.MX8M platforms' system counter clock
are from OSC which is always enabled, so it is no need to enable
clock for system counter driver, the ONLY thing is to pass
clock frequence to driver.
This patch adds an option of skipping of_clk operation for
system counter driver, an optional property "clock-frequency"
is introduced to pass the frequency value to system counter
driver and indicate driver to skip of_clk operations.
Signed-off-by: Anson Huang <[email protected]>
---
drivers/clocksource/timer-imx-sysctr.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/clocksource/timer-imx-sysctr.c b/drivers/clocksource/timer-imx-sysctr.c
index fd7d680..8ff3d7e 100644
--- a/drivers/clocksource/timer-imx-sysctr.c
+++ b/drivers/clocksource/timer-imx-sysctr.c
@@ -129,6 +129,14 @@ static void __init sysctr_clockevent_init(void)
static int __init sysctr_timer_init(struct device_node *np)
{
int ret = 0;
+ u32 rate;
+
+ if (!of_property_read_u32(np, "clock-frequency",
+ &rate)) {
+ to_sysctr.of_clk.rate = rate;
+ to_sysctr.of_clk.period = DIV_ROUND_UP(rate, HZ);
+ to_sysctr.flags &= ~TIMER_OF_CLOCK;
+ }
ret = timer_of_init(np, &to_sysctr);
if (ret)
--
2.7.4
From: Anson Huang <[email protected]>
Add i.MX8MQ system counter node to enable timer-imx-sysctr
broadcast timer driver.
Signed-off-by: Anson Huang <[email protected]>
---
arch/arm64/boot/dts/freescale/imx8mq.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
index d09b808..9d99191 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
@@ -635,6 +635,14 @@
#pwm-cells = <2>;
status = "disabled";
};
+
+ system_counter: timer@306a0000 {
+ compatible = "nxp,sysctr-timer";
+ reg = <0x306a0000 0x30000>;
+ interrupts = <GIC_SPI 47 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>;
+ clock-frequency = <8333333>;
+ };
};
bus@30800000 { /* AIPS3 */
--
2.7.4
On 21.06.19 10:28, [email protected] wrote:
> From: Anson Huang <[email protected]>
>
> Add i.MX8MQ system counter node to enable timer-imx-sysctr
> broadcast timer driver.
with these changes and TIMER_IMX_SYS_CTR selected, I don't see cpuidle
working yet (which is what I want to achieve on imx8mq). Might there be
a system counter clock definition or anything else missing?
thanks,
martin
Anson,
On Fri, 21 Jun 2019, [email protected] wrote:
> Subject : [PATCH 1/3] clocksource/drivers/sysctr: Add an optional property
That subject line is not really informative. From Documentation:
The ``summary phrase`` in the email's Subject should concisely
describe the patch which that email contains.
That means that it should tell which property it adds so it's immediately
clear what this is about. Something like:
Subject: clocksource/drivers/sysctr: Add optional clock-frequency property
Hmm?
> From: Anson Huang <[email protected]>
>
> This patch adds an optional property "clock-frequency" to pass
Please read Documentation/process/submitting-patches.rst and search for
'This patch'
> the system counter frequency value to kernel system counter
> driver and indicate the driver to skip of_clk operations, this
> is to support those platforms using platform driver model for
> clock driver.
That sentence does not parse. Please structure your changelog in the
following order:
1) Context or problem
2) Detailed analysis (if applicable and necessary)
3) Short description of the solution (the rest is obvious from the patch
itself).
So something like this (assumed I decoded the above correctly):
Systems which use the system counter with the platform driver model
require the clock frequency to be supplied via device tree.
This is necessary as in the platform driver model the of_clk operations
do not work correctly because LENGHTY EXPLANATION WHY ...
Add the optinal clock-frequency to the device tree bindings of the NXP
system counter so the frequency can be handed in and the of_clk
operations can be skipped.
The important part is the missing LENGTHY EXPLANATION WHY. I can't fill
that in because you did not provide that information.
Thanks,
tglx
On 22.06.19 16:16, Martin Kepplinger wrote:
> On 21.06.19 10:28, [email protected] wrote:
>> From: Anson Huang <[email protected]>
>>
>> Add i.MX8MQ system counter node to enable timer-imx-sysctr
>> broadcast timer driver.
>
> with these changes and TIMER_IMX_SYS_CTR selected, I don't see cpuidle
> working yet (which is what I want to achieve on imx8mq). Might there be
> a system counter clock definition or anything else missing?
>
To be clear about what I tried running: Abel's wakeup-workaround (with
the corresponding ATF changes): https://lkml.org/lkml/2019/6/10/350 plus
your patches here (although you don't define a system counter clock,
like you do in your imx8mm patches).
In any case, I might try to enable cpuidle totally wrong still :) and
I'd be happy for hints and test your changes (no matter how fit they are
to be merged right now).
thanks,
martin
Hi, Martin
> -----Original Message-----
> From: Martin Kepplinger <[email protected]>
> Sent: Saturday, June 22, 2019 10:16 PM
> To: Anson Huang <[email protected]>; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; Abel Vesa
> <[email protected]>; [email protected]; [email protected];
> [email protected]; [email protected]; linux-
> [email protected]; [email protected]; linux-arm-
> [email protected]
> Cc: dl-linux-imx <[email protected]>
> Subject: Re: [PATCH 3/3] arm64: dts: imx8mq: Add system counter node
>
> On 21.06.19 10:28, [email protected] wrote:
> > From: Anson Huang <[email protected]>
> >
> > Add i.MX8MQ system counter node to enable timer-imx-sysctr broadcast
> > timer driver.
>
> with these changes and TIMER_IMX_SYS_CTR selected, I don't see cpuidle
> working yet (which is what I want to achieve on imx8mq). Might there be a
> system counter clock definition or anything else missing?
i.MX8MQ is different about system counter enablement, with this patch series,
no need to have system counter clock definition, this patch is just to enable the
system counter as broadcast timer, it is necessary for further support of cpu-idle,
to enable cpu-idle, another DT patch is needed to add idle node, but as far as I
know, Abel is working on the workaround of the i.MX8MQ cpu-idle, I don't know
if it is picked up or NOT, so I believe the cpu-idle will be enabled later for i.MX8MQ
by Abel.
Thanks,
Anson.
>
> thanks,
> martin
>
> -----Original Message-----
> From: Martin Kepplinger <[email protected]>
> Sent: Sunday, June 23, 2019 7:21 PM
> To: Anson Huang <[email protected]>; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; Abel Vesa
> <[email protected]>; [email protected]; [email protected];
> [email protected]; [email protected]; linux-
> [email protected]; [email protected]; linux-arm-
> [email protected]
> Cc: dl-linux-imx <[email protected]>
> Subject: Re: [PATCH 3/3] arm64: dts: imx8mq: Add system counter node
>
> On 22.06.19 16:16, Martin Kepplinger wrote:
> > On 21.06.19 10:28, [email protected] wrote:
> >> From: Anson Huang <[email protected]>
> >>
> >> Add i.MX8MQ system counter node to enable timer-imx-sysctr broadcast
> >> timer driver.
> >
> > with these changes and TIMER_IMX_SYS_CTR selected, I don't see cpuidle
> > working yet (which is what I want to achieve on imx8mq). Might there
> > be a system counter clock definition or anything else missing?
> >
>
> To be clear about what I tried running: Abel's wakeup-workaround (with the
> corresponding ATF changes):
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flkml.o
> rg%2Flkml%2F2019%2F6%2F10%2F350&data=02%7C01%7CAnson.Huan
> g%40nxp.com%7C445690743187422a2d2b08d6f7ccd665%7C686ea1d3bc2b4
> c6fa92cd99c5c301635%7C0%7C0%7C636968856477185012&sdata=k1Aj
> CJ5SGUYQE7VnzciihRTKgf1yi4bDaBqCCv9DzpU%3D&reserved=0 plus
> your patches here (although you don't define a system counter clock, like you
> do in your imx8mm patches).
>
> In any case, I might try to enable cpuidle totally wrong still :) and I'd be happy
> for hints and test your changes (no matter how fit they are to be merged
> right now).
Could be something else than this patch series, i.MX8MQ uses platform driver model
for clock driver, to enable system counter driver, something needs to be changed in
system counter driver, and no need to have system counter clock definition in i.MX8MQ
clock tree, while i.MX8MM uses OF_CLK as clock driver initialization, so we need system
counter clock definition.
My understanding is, even without this patch series, cpu-idle should be able to work, but
The last CPU could be always powered ON to ack as broadcast timer, if with system counter
enabled, all CPUs can be powered OFF when entering state #1 idle independently, as system
counter can be broadcast timer. Correct me if anything wrong, maybe latest upstream kernel
has something different about this part.
Thanks,
Anson.
>
> thanks,
> martin
Hi, Thomas
Thanks for the useful comment, I will resend the patch with improvement.
Anson.
> -----Original Message-----
> From: Thomas Gleixner <[email protected]>
> Sent: Sunday, June 23, 2019 6:47 PM
> To: Anson Huang <[email protected]>
> Cc: [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; Abel Vesa
> <[email protected]>; [email protected]; [email protected];
> [email protected]; [email protected]; linux-
> [email protected]; [email protected]; linux-arm-
> [email protected]; dl-linux-imx <[email protected]>
> Subject: Re: [PATCH 1/3] clocksource/drivers/sysctr: Add an optional
> property
>
> Anson,
>
> On Fri, 21 Jun 2019, [email protected] wrote:
>
> > Subject : [PATCH 1/3] clocksource/drivers/sysctr: Add an optional
> > property
>
> That subject line is not really informative. From Documentation:
>
> The ``summary phrase`` in the email's Subject should concisely
> describe the patch which that email contains.
>
> That means that it should tell which property it adds so it's immediately clear
> what this is about. Something like:
>
> Subject: clocksource/drivers/sysctr: Add optional clock-frequency property
>
> Hmm?
>
> > From: Anson Huang <[email protected]>
> >
> > This patch adds an optional property "clock-frequency" to pass
>
> Please read Documentation/process/submitting-patches.rst and search for
> 'This patch'
>
> > the system counter frequency value to kernel system counter driver and
> > indicate the driver to skip of_clk operations, this is to support
> > those platforms using platform driver model for clock driver.
>
> That sentence does not parse. Please structure your changelog in the
> following order:
>
> 1) Context or problem
>
> 2) Detailed analysis (if applicable and necessary)
>
> 3) Short description of the solution (the rest is obvious from the patch
> itself).
>
> So something like this (assumed I decoded the above correctly):
>
> Systems which use the system counter with the platform driver model
> require the clock frequency to be supplied via device tree.
>
> This is necessary as in the platform driver model the of_clk operations
> do not work correctly because LENGHTY EXPLANATION WHY ...
>
> Add the optinal clock-frequency to the device tree bindings of the NXP
> system counter so the frequency can be handed in and the of_clk
> operations can be skipped.
>
> The important part is the missing LENGTHY EXPLANATION WHY. I can't fill
> that in because you did not provide that information.
>
> Thanks,
>
> tglx
Anson,
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
A: No.
Q: Should I include quotations after my reply?
http://daringfireball.net/2007/07/on_top
On Sun, 23 Jun 2019, Anson Huang wrote:
> Hi, Thomas
> Thanks for the useful comment, I will resend the patch with improvement.
>
> Anson.
>
> > -----Original Message-----
> > From: Thomas Gleixner <[email protected]>
> > Sent: Sunday, June 23, 2019 6:47 PM
> > To: Anson Huang <[email protected]>
> > Cc: [email protected]; [email protected]; [email protected];
> > [email protected]; [email protected]; [email protected];
> > [email protected]; [email protected]; Abel Vesa
> > <[email protected]>; [email protected]; [email protected];
> > [email protected]; [email protected]; linux-
> > [email protected]; [email protected]; linux-arm-
> > [email protected]; dl-linux-imx <[email protected]>
> > Subject: Re: [PATCH 1/3] clocksource/drivers/sysctr: Add an optional
> > property
Also please fix your mailer to NOT copy the full mail header into the
reply. That's absolutely useless.
> >
> > Anson,
> >
> > On Fri, 21 Jun 2019, [email protected] wrote:
> >
> > > Subject : [PATCH 1/3] clocksource/drivers/sysctr: Add an optional
> > > property
And finally please trim your replies, so the uninteresting parts are gone.
Thanks,
tglx
Hi, Thomas
> Anson,
>
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing in e-mail?
>
> A: No.
> Q: Should I include quotations after my reply?
>
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdaringf
> ireball.net%2F2007%2F07%2Fon_top&data=02%7C01%7Canson.huang
> %40nxp.com%7C658d12e0d65a401034d208d6f7cecc86%7C686ea1d3bc2b4c6
> fa92cd99c5c301635%7C0%7C1%7C636968864908338236&sdata=%2F0%
> 2B9DIT2HVuVFgLvhW7QFFNAXrRqbcTi9%2BJcasgOv08%3D&reserved=0
>
Thanks for these info.
> On Sun, 23 Jun 2019, Anson Huang wrote:
>
> > Hi, Thomas
> > Thanks for the useful comment, I will resend the patch with
> improvement.
> >
> > Anson.
> >
> Also please fix your mailer to NOT copy the full mail header into the reply.
> That's absolutely useless.
Sure, thanks for reminder.
>
> > >
> > > Anson,
> > >
> > > On Fri, 21 Jun 2019, [email protected] wrote:
> > >
> > > > Subject : [PATCH 1/3] clocksource/drivers/sysctr: Add an optional
> > > > property
>
> And finally please trim your replies, so the uninteresting parts are gone.
>
OK.
Thanks,
Anson.
> Thanks,
>
> tglx