qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2] hw/misc/zynq_slcr: Change CPU clock rate for


From: Peter Crosthwaite
Subject: Re: [Qemu-devel] [PATCH v2] hw/misc/zynq_slcr: Change CPU clock rate for Linux boots
Date: Sun, 13 Sep 2015 15:42:26 -0700

On Sun, Sep 13, 2015 at 1:47 PM, Peter Maydell <address@hidden> wrote:
> On 13 September 2015 at 21:22, Peter Crosthwaite
> <address@hidden> wrote:
>> On Sat, Sep 12, 2015 at 2:06 PM, Guenter Roeck <address@hidden> wrote:
>>> The Linux kernel only accepts 333334 Khz and 666667 Khz clock rates, and
>>> may crash if the actual clock rate is too low. The clock rate used to be
>>> (ps-clk-frequency * 26 / 4), which resulted in a CPU frequency of
>>> 216666 Khz if ps-clk-frequency was set to 33333333 Hz. Change it to
>>> (ps-clk-frequency * 20 / 2) = 333333 Khz for to make Linux happy.
>>> Limit the change to Linux boots only.
>>>
>>> Signed-off-by: Guenter Roeck <address@hidden>
>>>
>>
>> Reviewed-by: Peter Crosthwaite <address@hidden>
>>
>> Can this go via target-arm? (cc PMM).
>>
>> There may be more changes worth making on is_linux. I don't have the
>> patch with the full list of FSBL-related SLCR changes handy and can't
>> seem to find it in any modern Yocto trees. Wondering if Yocto still
>> supports booting Zynq without FSBL (Nathan/Alistair may know more)?
>
> I'd prefer us not to propagate lots of "only if Linux boot"
> changes into devices. The GIC *must* have these because the
> kernel can't configure it otherwise from non-secure mode.
> I'm not sure that applies here.
>

At least this change is a must. I have had this discussion with kernel
people before and they insist that initing the PLLs and clocks to
desired values is the job of the bootloader and the kernel reads back
the values from this core. It is same philosophy at the GIC init,
which is at the end of the day, done by some pre-boot software. The
same bootloader (FSBL) makes other changes that kernels past present
and future may rely on and it would be good to have those.

Regards,
Peter

> thanks
> -- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]