[PATCH v2] arm64: dts: imx8mp: Add DT nodes for the two ISPs

Marek Vasut marex at denx.de
Wed Jun 12 18:10:24 PDT 2024


On 6/11/24 5:01 AM, Peng Fan wrote:

[...]

>>>> According to the i.MX8MP Data sheet, the nominal speed for
>>>> MEDIA_ISP_CLOCL_ROOT is 400MHZ with 500MHz being allowed in
>> overdrive
>>>> mode.
>>>>
>>>> I think this clock rate should drop to  the nominal value of 400MHz
>>>> and those boards who support overdrive can increase it to 500MHz to
>>>> avoid stiability issues and/or running out of spec.  I created an
>>>> imx8mm and imx8mn- overdrive.dtsi file.  If there is interest, I can do the
>> same for the 8MP as well.
>>>>
>>>> I haven't gone through all the clocks to determine if/what clocks are
>>>> being overdriven.
>>>
>>> Shouldn't the bootloader take the work to runtime update the freq?
>>> Why need introduce an extra overdrive.dtsi?
>>
>> Shouldn't the overdrive/non-overdrive decision be done in board DT instead ?
> 
> It is bootloader configure voltage to nominal, then bootloader should use
> nominal device tree or runtime update dtb.
> If bootloader configure voltage to over-drive, bootloader could use
> nominal or over-drive dtb

I think the bootloader should always configure the minimal common 
configuration, i.e. nominal voltage, nominal clock, so that it would 
achieve maximum compatibility with any SoC in that SoC line up.

If the user does need overdrive configuration, they should specify that 
in their board DT.

Keep in mind, the kernel is easy to update (including kernel DT), the 
bootloader is not easy to update (esp. in field, bootloader update may 
render a system unbootable if it fails). I would say, it is better to 
keep the complicated things out of the bootloader if at all possible.

> If introduce x.dtsi and x-overdrive.dtsi, how to let board choose which dtsi
> to include?

#include "x.dtsi"
or
#include "x-overdrive.dtsi"

But I think your question is -- how to do that at runtime ?

U-Boot can apply DT overlays onto DT that is passed to Linux, so if the 
user has board variants where they need both nonoverdrive/overdrive 
options, they can apply DT overlay which enables the overdrive mode on 
boards which need it. This can be done from U-Boot boot.scr or similar 
boot script, which can again be easily updated, without the need to 
update the bootloader itself (if something goes wrong or needs to be 
changed in the future).



More information about the linux-arm-kernel mailing list