From: Marek Vasut <marex@denx.de>
To: Peng Fan <peng.fan@nxp.com>, Adam Ford <aford173@gmail.com>,
Alexander Stein <alexander.stein@ew.tq-group.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
"imx@lists.linux.dev" <imx@lists.linux.dev>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Paul Elder <paul.elder@ideasonboard.com>,
Conor Dooley <conor+dt@kernel.org>,
Fabio Estevam <festevam@gmail.com>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Pengutronix Kernel Team <kernel@pengutronix.de>,
Rob Herring <robh@kernel.org>,
Sascha Hauer <s.hauer@pengutronix.de>,
Shawn Guo <shawnguo@kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>
Subject: Re: [PATCH v2] arm64: dts: imx8mp: Add DT nodes for the two ISPs
Date: Thu, 13 Jun 2024 03:10:24 +0200 [thread overview]
Message-ID: <3cc52973-61b0-4698-98b7-402634f2b620@denx.de> (raw)
In-Reply-To: <AM6PR04MB594198421BCC895B506C408A88C72@AM6PR04MB5941.eurprd04.prod.outlook.com>
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).
next prev parent reply other threads:[~2024-06-13 1:44 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-25 15:13 [PATCH v2] arm64: dts: imx8mp: Add DT nodes for the two ISPs Laurent Pinchart
2024-03-25 15:16 ` Adam Ford
2024-03-25 15:52 ` Alexander Stein
2024-03-25 20:49 ` Laurent Pinchart
2024-03-26 7:14 ` Alexander Stein
2024-06-09 20:21 ` Adam Ford
2024-06-11 1:04 ` Peng Fan
2024-06-11 1:34 ` Marek Vasut
2024-06-11 3:01 ` Peng Fan
2024-06-13 1:10 ` Marek Vasut [this message]
2024-06-13 8:24 ` Marco Felsch
2024-08-13 22:22 ` Laurent Pinchart
2024-08-14 6:29 ` Adam Ford
2024-08-14 14:47 ` Laurent Pinchart
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3cc52973-61b0-4698-98b7-402634f2b620@denx.de \
--to=marex@denx.de \
--cc=aford173@gmail.com \
--cc=alexander.stein@ew.tq-group.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=festevam@gmail.com \
--cc=imx@lists.linux.dev \
--cc=kernel@pengutronix.de \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-media@vger.kernel.org \
--cc=paul.elder@ideasonboard.com \
--cc=peng.fan@nxp.com \
--cc=robh@kernel.org \
--cc=s.hauer@pengutronix.de \
--cc=shawnguo@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox