Re: [PATCH] ARC: AXS10x: Add temporary quirk to reset ethernet IP
On 09/06/2017 11:21 AM, Eugeniy Paltsev wrote: DW ethernet controller on AXS10x hangs sometimes after SW reset, so add temporary quirk to reset DW ethernet controller IP core. This quirk can be removed after axs10x reset driver (see http://patchwork.ozlabs.org/patch/800273/) or simple reset driver (see https://patchwork.kernel.org/patch/9903375/) will be available in upstream. Signed-off-by: Eugeniy Paltsev Added to for-next ! Thx, --- arch/arc/plat-axs10x/axs10x.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/arc/plat-axs10x/axs10x.c b/arch/arc/plat-axs10x/axs10x.c index f1ac679..cf14ebc 100644 --- a/arch/arc/plat-axs10x/axs10x.c +++ b/arch/arc/plat-axs10x/axs10x.c @@ -111,6 +111,13 @@ static void __init axs10x_early_init(void) axs10x_enable_gpio_intc_wire(); + /* +* Reset ethernet IP core. +* TODO: get rid of this quirk after axs10x reset driver (or simple +* reset driver) will be available in upstream. +*/ + iowrite32((1 << 5), (void __iomem *) CREG_MB_SW_RESET); + scnprintf(mb, 32, "MainBoard v%d", mb_rev); axs10x_print_board_ver(CREG_MB_VER, mb); } ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: Setting CPU clock frequency on early boot
On Wed, Sep 6, 2017 at 11:22 AM, Alexey Brodkin
wrote:
> Hi Rob,
>
> On Wed, 2017-09-06 at 10:25 -0500, Rob Herring wrote:
>> On Wed, Sep 6, 2017 at 8:51 AM, Alexey Brodkin
>> wrote:
>> >
>> > Hi Vineet, Rob,
>> >
>> > On Tue, 2017-09-05 at 16:40 -0700, Vineet Gupta wrote:
>> > >
>> > > On 09/05/2017 03:04 PM, Rob Herring wrote:
>> > > >
>> > > >
>> > > > On Tue, Sep 5, 2017 at 10:37 AM, Alexey Brodkin
>> > > > wrote:
>
> [snip]
>
>> > Yeah, that's an interesting question. We may indeed move more smarts to
>> > the clock driver
>> > but:
>> > 1. We'll have duplicate code in different clock drivers. Even today that
>> > kind of clock
>> > setup is applicable to AXS10x and HSDK platforms (and they use
>> > different clock drivers).
>>
>> No, you could provide a common, shared function to call. Then each
>> platform can opt-in. If you can make something that applies to every
>> single platform now or in the future, then I'd put it in arch. If you
>> have plans to decouple the timer and cpu clocks, then sounds like you
>> can't.
>
> Right so we'll implement a function which is called by a platform if required.
> That way we escape copy-pasting while keeping enough flexibility for current
> and future platforms.
>
>> IMO, if it's not part of the defined CPU architecture, then don't put
>> it in arch/. That's how we end up with multiple copies of the same
>> thing done arbitrarily different ways because few people look across
>> architectures.
>
> So do you propose to have the function [that reads "clock-frequency" from say
> CPU node and passes its value to CPU's parent clock driver] in generic
> [i.e. architecture agnostic] code somewhere in "init/main.c"?
No, just like you said above and have the platform's clock driver
initialize frequencies.
I haven't seen anyone else want such a thing as generally the
bootloader should initialize things to something reasonable.
>> > 2. Print out of CPU frequency which is used during boot process for us is
>> > important as well
>> > especially during bring-up of new HW.
>> >
>> > 3. If there's no dedicated "clock-frequency" parameter in CPU node we
>> > won't
>> > change anything so that non-affected platforms will live as they used
>> > to.
>> >
>> > That said IMHO proposed implementation is what we want to kep for now.
>> >
>> > >
>> > > Also note that this code is using a new / adhoc DT binding cpu-freq in
>> > > cou node to
>> > > do the override - is that acceptable ?
>>
>> No, I meant to point that out.
>
> Sorry, but for me it's not clear what did you mean here.
> Care to elaborate a bit more?
I noticed the same thing and meant to highlight that in my first
reply. Use clock-frequency, don't invent something new.
>> > I think we'll switch to more common "clock-frequency" in the next respin.
>> > Indeed "cpu-freq" might be a bit misleading.
>>
>> Ideally, you'd use the clock binding eventually.
>
> Again I'm probably missing something :)
"clock-frequency" property and the clock bindings (i.e. clocks =
<&phandle>) are generally mutually exclusive at least within clock
consumer side. There's the assigned-clocks binding which provides the
ability to set both parent clocks and frequency.
> I meant we will have both clock phandle and "clock-frequency" at the same
> time.
> Something like this:
> >8---
> cpus {
> #address-cells = <1>;
> #size-cells = <0>;
>
> cpu@0 {
> device_type = "cpu";
> compatible = "snps,archs38";
> reg = <0>;
> clocks = <&core_clk>;
> clock-frequency = <1>; <-- That's where we
> want to set desired value
> };
> ...
> }
>
> core_clk: core-clk@80 {
> compatible = "snps,axs10x-arc-pll-clock";
> reg = <0x80 0x10>, <0x100 0x10>;
> #clock-cells = <0>;
> clocks = <&input_clk>;
> };
> >8---
>
> Or alternatively we may move "clock-frequency" right to the clock's node and
> have
> it like that:
> >8---
> core_clk: core-clk@80 {
> compatible = "snps,axs10x-arc-pll-clock";
> reg = <0x80 0x10>, <0x100 0x10>;
>
> #clock-cells = <0>;
> clocks = <&input_clk>;
> clock-frequency = <1>; <-- That's where we want to
> set desired value
I think this is how it should be done if you use clock-frequency prop.
This is inline with how fixed-clock binding is done.
Rob
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH] ARC: AXS10x: Add temporary quirk to reset ethernet IP
DW ethernet controller on AXS10x hangs sometimes after SW reset, so add temporary quirk to reset DW ethernet controller IP core. This quirk can be removed after axs10x reset driver (see http://patchwork.ozlabs.org/patch/800273/) or simple reset driver (see https://patchwork.kernel.org/patch/9903375/) will be available in upstream. Signed-off-by: Eugeniy Paltsev --- arch/arc/plat-axs10x/axs10x.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/arc/plat-axs10x/axs10x.c b/arch/arc/plat-axs10x/axs10x.c index f1ac679..cf14ebc 100644 --- a/arch/arc/plat-axs10x/axs10x.c +++ b/arch/arc/plat-axs10x/axs10x.c @@ -111,6 +111,13 @@ static void __init axs10x_early_init(void) axs10x_enable_gpio_intc_wire(); + /* +* Reset ethernet IP core. +* TODO: get rid of this quirk after axs10x reset driver (or simple +* reset driver) will be available in upstream. +*/ + iowrite32((1 << 5), (void __iomem *) CREG_MB_SW_RESET); + scnprintf(mb, 32, "MainBoard v%d", mb_rev); axs10x_print_board_ver(CREG_MB_VER, mb); } -- 2.9.3 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2 2/2] console: don't select first registered console if stdout-path used
Hi Eugeniy,
On Wednesday, 6 September 2017 10:57:18 PDT Eugeniy Paltsev wrote:
> > > We retain previous behavior for tty0 console (if "stdout-path" used)
> > > as a special case:
> > > tty0 will be registered even if it was specified neither
> > > in "bootargs" nor in "stdout-path".
> > > We had to retain this behavior because a lot of ARM boards (and some
> > > powerpc) rely on it.
> >
> > My main concern is the exception for "tty". Yes, it was regiression
> > reported in the commit c6c7d83b9c9e6a8b3e ("Revert "console: don't
> > prefer first registered if DT specifies stdout-path""). But is this
> > the only possible regression?
> >
> > All this is about the fallback code that tries to enable all
> > consoles until a real one with tty binding (newcon->device)
> > is enabled.
> >
> > v1 version of you patch disabled this fallback code when a console
> > was defined by stdout-path in the device tree. This emulates
> > defining the console by console= parameter on the command line.
> >
> > It might make sense until some complains that a console is not
> > longer automatically enabled while it was before. But wait.
> > Someone already complained about "tty0". We can solve this
> > by adding an exception for "tty0". And if anyone else complains
> > about another console, we might need more exceptions.
> >
> > We might endup with so many exceptions that the fallback code
> > will be always used. But then we are back in the square
> > and have the original behavior before your patch.
>
> Yes, I understand your concerns.
>
> But I also have another concern: If we decide to left current behavior
> untouched (like after reverting patch 05fd007e4629)
> more and more boards and devices will use current broken stdout-path
> behavior in any form and in the results we will get the situation when we
> can't fix stdout-path behavior at all - because every change will break
> something somewhere.
> (05fd007e4629 patch do absolutely the same as v1 version of my patch)
>
> > This is why I would like to know more info about your problem.
> > We need to decide if it is more important than a regression.
> > Or if it can be fixed another way.
After the troubles with commit 05fd007e4629 ("console: don't prefer first
registered if DT specifies stdout-path") I took an alternate approach: rather
than preventing the first console being registered, I instead prevent the
bootconsole from being unregistered until we see the stdout-path console
probed.
For my systems, where there are 3 consoles involved, this is how it goes:
- The 8250 earlycon is our boot console.
- tty0 (from CONFIG_VT) comes along & gets registered fairly early, and
becomes the "proper" console. With current mainline this causes the boot
console to be unregistered & lose output over the UART for a while.
- Eventually ttyS0, the proper 8250 console, gets registered & we re-gain
UART output. If the system died between the tty0 & ttyS0 registering, it
dies silently.
With my current approach the difference is that the boot console sticks around
until the last step where ttyS0 is registered (or until the late_initcall
stage if ttyS0 never registers). This solves my problem - would it solve
yours?
I haven't submitted this patch yet, but you can find it here in a v4.13 based
downstream if you want to give it a try:
https://git.linux-mips.org/cgit/linux-mti.git/commit/?
h=eng-201705051946&id=dd144b12c899b591c0370715328199bc958878fe
Thanks,
Paul
signature.asc
Description: This is a digitally signed message part.
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2 2/2] console: don't select first registered console if stdout-path used
Hi Petr,
On Tue, 2017-09-05 at 16:54 +0200, Petr Mladek wrote:
> On Mon 2017-08-28 19:58:07, Eugeniy Paltsev wrote:
> > In the current implementation we take the first console that
> > registers if we didn't select one.
> >
> > But if we specify console via "stdout-path" property in device tree
> > we don't want first console that registers here to be selected.
> > Otherwise we may choose wrong console - for example if some console
> > is registered earlier than console is pointed in "stdout-path"
> > property because console pointed in "stdout-path" property can be add as
> > preferred quite late - when it's driver is probed.
>
> register_console() is really twisted function. I would like to better
> understand your problems before we add yet another twist there.
>
> Could you please be more specific about your problems?
> What was the output of "cat /proc/consoles" before and after the fix?
> What exactly started and stopped working?
Ok, I faced with several problems when I tried to use stdout-path and this
patch solves all of them.
There is the description of some of the problems:
---
Problem 1: choosing wrong serial console device
Context:
Serial console device specified via "stdout-path" property in device tree,
support for console on virtual terminal is disabled (CONFIG_VT_CONSOLE is
not selected, CONFIG_VT is selected)
In this case wrong console device can be selected.
Example:
Device tree:
-->8
chosen {
bootargs = ""
stdout-path = &serial_1;
};
serial_0: uart-0@... {} /* FAIL: serial_0 is used as console (ttyS0) as it is
* probed earlier */
serial_1: uart-1@... {}
-->8
# cat /proc/consoles
ttyS0-W- (EC a)4:64/* FAIL: ttyS0 is used instead of
* ttyS1 */
This FAIL happens because we take the first registered console if we didn't
select
a console via "console=" option in bootargs.
After my patch-v2:
# cat /proc/consoles
ttyS1-W- (EC p a)4:67
---
Problem 2: printing early boot messages twice and pause in boot messages
printing
Context:
We use early console. Serial console device (and early console device) specified
via "stdout-path" property in device tree.
Support for console on virtual terminal is enabled (CONFIG_VT_CONSOLE=y)
In this case early boot messages will be printed twice - firstly by
bootconsole and after that by 'real' serial console.
Also we will get pause in boot messages printing - as bootconsole will be
disabled
mush earlier than 'real' serial console is enabled.
Example:
-->8
chosen {
bootargs = "earlycon"
stdout-path = &serial_3;
};
serial_3: uart-3@... {}
-->8
So output of serial console will be be like that:
-->8
XXX - early boot messages, printed by bootconsole
- FAIL: pause in boot messages printing
XXX - FAIL: again early boot messages, printed by serial console
YYY - rest of boot messages, printed by serial console
-->8
So the order of enabling/disabling consoles will be like that:
-->8
bootconsole [uart0] enabled
console [tty0] enabled /* As no console is select 'tty0' was taken
*/
bootconsole [uart0] disabled/* As we have real (tty0) console we disable
* all bootconsoles */
console [ttyS3] enabled /* We take ttyS3 but don't reset its
* CON_PRINTBUFFER flag (as there is NO
enabled
* bootconsoles) */
-->8
# cat /proc/consoles
ttyS3-W- (EC p a)4:67
tty0 -WU (E )4:1
As you can see CON_PRINTBUFFER flag (p) set for ttyS3 - that is wrong.
After my patch-v2:
# cat /proc/consoles
ttyS3-W- (EC a)4:67
tty0 -WU (E p )4:1
These are the problems I have faced but these are NOT THE ONLY POSSIBLE problems
because current behavior is quite unstable and unpredictable.
And of course I would prefer to use simple solution from v1 patch version
but in this case we will face with someone complaining about "tty0".
So all comments and suggestions are more than welcome.
> > We retain previous behavior for tty0 console (if "stdout-path" used)
> > as a special case:
> > tty0 will be registered even if it was specified neither
> > in "bootargs" nor in "stdout-path".
> > We had to retain this behavior because a lot of ARM boards (and some
> > powerpc) rely on it.
>
> My main concern is the exception for "tty". Yes, it was regiression
> reported in the commit c6c7d83b9c9e6a8b3e ("Revert "console: don't
> prefer first registered if DT specifies stdout-path""). But is this
> the only possibl
Re: Setting CPU clock frequency on early boot
Hi Rob,
On Wed, 2017-09-06 at 10:25 -0500, Rob Herring wrote:
> On Wed, Sep 6, 2017 at 8:51 AM, Alexey Brodkin
> wrote:
> >
> > Hi Vineet, Rob,
> >
> > On Tue, 2017-09-05 at 16:40 -0700, Vineet Gupta wrote:
> > >
> > > On 09/05/2017 03:04 PM, Rob Herring wrote:
> > > >
> > > >
> > > > On Tue, Sep 5, 2017 at 10:37 AM, Alexey Brodkin
> > > > wrote:
[snip]
> > Yeah, that's an interesting question. We may indeed move more smarts to the
> > clock driver
> > but:
> > 1. We'll have duplicate code in different clock drivers. Even today that
> > kind of clock
> > setup is applicable to AXS10x and HSDK platforms (and they use
> > different clock drivers).
>
> No, you could provide a common, shared function to call. Then each
> platform can opt-in. If you can make something that applies to every
> single platform now or in the future, then I'd put it in arch. If you
> have plans to decouple the timer and cpu clocks, then sounds like you
> can't.
Right so we'll implement a function which is called by a platform if required.
That way we escape copy-pasting while keeping enough flexibility for current
and future platforms.
> IMO, if it's not part of the defined CPU architecture, then don't put
> it in arch/. That's how we end up with multiple copies of the same
> thing done arbitrarily different ways because few people look across
> architectures.
So do you propose to have the function [that reads "clock-frequency" from say
CPU node and passes its value to CPU's parent clock driver] in generic
[i.e. architecture agnostic] code somewhere in "init/main.c"?
> >
> > 2. Print out of CPU frequency which is used during boot process for us is
> > important as well
> > especially during bring-up of new HW.
> >
> > 3. If there's no dedicated "clock-frequency" parameter in CPU node we won't
> > change anything so that non-affected platforms will live as they used
> > to.
> >
> > That said IMHO proposed implementation is what we want to kep for now.
> >
> > >
> > > Also note that this code is using a new / adhoc DT binding cpu-freq in
> > > cou node to
> > > do the override - is that acceptable ?
>
> No, I meant to point that out.
Sorry, but for me it's not clear what did you mean here.
Care to elaborate a bit more?
> > I think we'll switch to more common "clock-frequency" in the next respin.
> > Indeed "cpu-freq" might be a bit misleading.
>
> Ideally, you'd use the clock binding eventually.
Again I'm probably missing something :)
I meant we will have both clock phandle and "clock-frequency" at the same time.
Something like this:
>8---
cpus {
#address-cells = <1>;
#size-cells = <0>;
cpu@0 {
device_type = "cpu";
compatible = "snps,archs38";
reg = <0>;
clocks = <&core_clk>;
clock-frequency = <1>; <-- That's where we
want to set desired value
};
...
}
core_clk: core-clk@80 {
compatible = "snps,axs10x-arc-pll-clock";
reg = <0x80 0x10>, <0x100 0x10>;
#clock-cells = <0>;
clocks = <&input_clk>;
};
>8---
Or alternatively we may move "clock-frequency" right to the clock's node and
have
it like that:
>8---
core_clk: core-clk@80 {
compatible = "snps,axs10x-arc-pll-clock";
reg = <0x80 0x10>, <0x100 0x10>;
#clock-cells = <0>;
clocks = <&input_clk>;
clock-frequency = <1>; <-- That's where we want to set
desired value
};
>8---
-Alexey
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: Setting CPU clock frequency on early boot
On Wed, Sep 6, 2017 at 8:51 AM, Alexey Brodkin wrote: > Hi Vineet, Rob, > > On Tue, 2017-09-05 at 16:40 -0700, Vineet Gupta wrote: >> On 09/05/2017 03:04 PM, Rob Herring wrote: >> > >> > On Tue, Sep 5, 2017 at 10:37 AM, Alexey Brodkin >> > wrote: >> > > >> > > Hello, >> > > >> > > I'd like to get some feedback on our idea as well as check >> > > if somebody faces similar situations and if so what would be the best >> > > way to implement some generic solution that suits everyone. >> > > >> > > So that's our problem: >> > > 1. On power-on hardware might start clocking CPU with either >> > > too high frequency (such that CPU may get stuck at some point) >> > > or too low frequency. >> > > >> > > That all sounds stupid but let me elaborate a bit here. >> > > I'm talking about FPGA-based devboards firmware for which >> > > (here I mean just image loaded in FPGA with CPU implementation >> > > but not some software yet) might not be stable or be even >> > > experimental. >> > > >> > > For example we may deal with dual-core or quad-core designs. >> > > Former might be OK running @100MHz and latter is only usable >> > > @75MHz and lower. The simplest solution might be to use some safe >> > > value before something like CPUfreq kicks in. But we don't yet have >> > > CPUfreq for ARC (we do plan to get it working sometime soon) >> >> But even if we had cpufreq driver going - I don't think it would be usable >> for >> doing large freq switches, since in current implementations of SoCs (or >> fpga), the >> clk/pll etc driving core (and all timers etc) are not fixed like say ARM. >> And as >> discussed before (and pointed to by tglx), timer subsys can't tolerate (on >> purpose) such large drifts. > > Essentially cpufreq only makes sense for "compatible" systems and > unfortunately > most of our current boards are not capable due to missing constant [decoupled > from > CPU frequency] clock source. But looking forward we are planning to improve > on that > so that hopefully even our FPGA-based boards will be usable with cpufreq. > >> > > which >> > > means simple change of CPU frequency once time-keeping infrastructure >> > > was brought-up is not an option... I.e. we'll end up with the system >> > > running >> > > much slower compared what could have been possible. >> > > >> > > 2. Up until now we used to do dirty hacks in early platform init code. >> > > Namely (see axs103_early_init() in arch/arc/plat-axs10x/axs10x.c): >> > > 1) Read CPU's "clock-frequency" from .dtb (remember we're on very >> > > early >> > > boot stage still so no expanded DevTree yet exists). >> > > 2) Check how many cores we have and which freq is usable >> > > 3) Update PLL settings right in place if new freq != existing in >> > > PLL. >> > > >> > > Even though it is proven to work but with more platforms in the >> > > pipeline >> > > we'll need to copy-paste pretty much the same stuff across all >> > > affected >> > > plats. Which is not nice. >> > > >> > > Moreover back in the day we didn't have a proper clk driver for >> > > CPU's PLL. >> > > Thus acting on PLL registers right in place was the only thing we >> > > were able >> > > to do. Now with introduction of normal clk driver >> > > (see drivers/clk/axs10x/pll_clock.c in linux-next) we'd like to >> > > utilize >> > > it and have a cleaner and more universal solution to the problem. >> > > >> > > That's how it could be done - >> > > https://urldefense.proofpoint.com/v2/url?u=http-3A__patchwork.ozlabs.org_patch_801240_&d=DwICAg&c=DPL6_X_6JkXF >> > > x7AXWqB0tg&r=c14YS-cH- >> > > kdhTOW89KozFhBtBJgs1zXscZojEZQ0THs&m=wuUcceY8Cz5EhVklWLAgj7RzU3rvpanujvQ3qTJK0Gw&s=N5IBjq_eCyOf_GRkZskzqGhczBPTbxLJW_MUfauKvuA&e= >> > > Basically in architecture's time_init() we check if there's >> > > explicitly >> > > specified "clock-frequency" parameter in cpu's node in Device Tree >> > > and >> > > if there's one we set it via just instantiated clk driver. >> > The patch looks generally okay. I'd move all the logic to the clock >> > driver unless perhaps how to set the cpu freq is defined by the >> > architecture. > > Yeah, that's an interesting question. We may indeed move more smarts to the > clock driver > but: > 1. We'll have duplicate code in different clock drivers. Even today that > kind of clock > setup is applicable to AXS10x and HSDK platforms (and they use different > clock drivers). No, you could provide a common, shared function to call. Then each platform can opt-in. If you can make something that applies to every single platform now or in the future, then I'd put it in arch. If you have plans to decouple the timer and cpu clocks, then sounds like you can't. IMO, if it's not part of the defined CPU architecture, then don't put it in arch/. That's how we end up with multiple copies of the same thing done arbitrarily different ways because f
Re: Setting CPU clock frequency on early boot
Hi Vineet, Rob, On Tue, 2017-09-05 at 16:40 -0700, Vineet Gupta wrote: > On 09/05/2017 03:04 PM, Rob Herring wrote: > > > > On Tue, Sep 5, 2017 at 10:37 AM, Alexey Brodkin > > wrote: > > > > > > Hello, > > > > > > I'd like to get some feedback on our idea as well as check > > > if somebody faces similar situations and if so what would be the best > > > way to implement some generic solution that suits everyone. > > > > > > So that's our problem: > > > 1. On power-on hardware might start clocking CPU with either > > > too high frequency (such that CPU may get stuck at some point) > > > or too low frequency. > > > > > > That all sounds stupid but let me elaborate a bit here. > > > I'm talking about FPGA-based devboards firmware for which > > > (here I mean just image loaded in FPGA with CPU implementation > > > but not some software yet) might not be stable or be even > > > experimental. > > > > > > For example we may deal with dual-core or quad-core designs. > > > Former might be OK running @100MHz and latter is only usable > > > @75MHz and lower. The simplest solution might be to use some safe > > > value before something like CPUfreq kicks in. But we don't yet have > > > CPUfreq for ARC (we do plan to get it working sometime soon) > > But even if we had cpufreq driver going - I don't think it would be usable > for > doing large freq switches, since in current implementations of SoCs (or > fpga), the > clk/pll etc driving core (and all timers etc) are not fixed like say ARM. And > as > discussed before (and pointed to by tglx), timer subsys can't tolerate (on > purpose) such large drifts. Essentially cpufreq only makes sense for "compatible" systems and unfortunately most of our current boards are not capable due to missing constant [decoupled from CPU frequency] clock source. But looking forward we are planning to improve on that so that hopefully even our FPGA-based boards will be usable with cpufreq. > > > which > > > means simple change of CPU frequency once time-keeping infrastructure > > > was brought-up is not an option... I.e. we'll end up with the system > > > running > > > much slower compared what could have been possible. > > > > > > 2. Up until now we used to do dirty hacks in early platform init code. > > > Namely (see axs103_early_init() in arch/arc/plat-axs10x/axs10x.c): > > > 1) Read CPU's "clock-frequency" from .dtb (remember we're on very > > > early > > > boot stage still so no expanded DevTree yet exists). > > > 2) Check how many cores we have and which freq is usable > > > 3) Update PLL settings right in place if new freq != existing in PLL. > > > > > > Even though it is proven to work but with more platforms in the > > > pipeline > > > we'll need to copy-paste pretty much the same stuff across all > > > affected > > > plats. Which is not nice. > > > > > > Moreover back in the day we didn't have a proper clk driver for CPU's > > > PLL. > > > Thus acting on PLL registers right in place was the only thing we > > > were able > > > to do. Now with introduction of normal clk driver > > > (see drivers/clk/axs10x/pll_clock.c in linux-next) we'd like to > > > utilize > > > it and have a cleaner and more universal solution to the problem. > > > > > > That's how it could be done - > > > https://urldefense.proofpoint.com/v2/url?u=http-3A__patchwork.ozlabs.org_patch_801240_&d=DwICAg&c=DPL6_X_6JkXF > > > x7AXWqB0tg&r=c14YS-cH- > > > kdhTOW89KozFhBtBJgs1zXscZojEZQ0THs&m=wuUcceY8Cz5EhVklWLAgj7RzU3rvpanujvQ3qTJK0Gw&s=N5IBjq_eCyOf_GRkZskzqGhczBPTbxLJW_MUfauKvuA&e= > > > Basically in architecture's time_init() we check if there's explicitly > > > specified "clock-frequency" parameter in cpu's node in Device Tree and > > > if there's one we set it via just instantiated clk driver. > > The patch looks generally okay. I'd move all the logic to the clock > > driver unless perhaps how to set the cpu freq is defined by the > > architecture. Yeah, that's an interesting question. We may indeed move more smarts to the clock driver but: 1. We'll have duplicate code in different clock drivers. Even today that kind of clock setup is applicable to AXS10x and HSDK platforms (and they use different clock drivers). 2. Print out of CPU frequency which is used during boot process for us is important as well especially during bring-up of new HW. 3. If there's no dedicated "clock-frequency" parameter in CPU node we won't change anything so that non-affected platforms will live as they used to. That said IMHO proposed implementation is what we want to kep for now. > Also note that this code is using a new / adhoc DT binding cpu-freq in cou > node to > do the override - is that acceptable ? I think we'll switch to more common "clock-frequency" in the next respin. Indeed "cpu-freq" might be a bit misleading. Also FWIW one MIPS platform
