From: Macpaul Lin <macpaul.lin@mediatek.com>
To: Chen-Yu Tsai <wenst@chromium.org>
Cc: Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Conor Dooley <conor+dt@kernel.org>,
Matthias Brugger <matthias.bgg@gmail.com>,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com>,
Fabien Parent <fparent@baylibre.com>,
<devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-mediatek@lists.infradead.org>,
Bear Wang <bear.wang@mediatek.com>,
Pablo Sun <pablo.sun@mediatek.com>,
Macpaul Lin <macpaul@gmail.com>,
Chunfeng Yun <chunfeng.yun@mediatek.com>,
Alexandre Mergnat <amergnat@baylibre.com>
Subject: Re: [PATCH 3/4] arm64: dts: mediatek: mt6360: add PMIC MT6360 related nodes
Date: Wed, 30 Aug 2023 19:10:48 +0800 [thread overview]
Message-ID: <bfff8dc1-5f1c-1da8-488c-58e83cb1e651@mediatek.com> (raw)
In-Reply-To: <CAGXv+5E2kOOz59AMCvQv_as6SesDkt15b9uDOSZ_iJMytgf1gA@mail.gmail.com>
On 8/28/23 18:51, Chen-Yu Tsai wrote:
>
>
> External email : Please do not click links or open attachments until you
> have verified the sender or the content.
>
> On Mon, Aug 28, 2023 at 5:59 PM Macpaul Lin <macpaul.lin@mediatek.com> wrote:
>>
>>
>> On 8/28/23 12:36, Chen-Yu Tsai wrote:
>> >
>> >
>> > External email : Please do not click links or open attachments until you
>> > have verified the sender or the content.
>> >
>> > On Fri, Aug 25, 2023 at 7:46 PM Macpaul Lin <macpaul.lin@mediatek.com> wrote:
>> >>
>> >> MT6360 is the secondary PMIC for MT8195.
>> >> It supports USB Type-C and PD functions.
>> >> Add MT6360 related common nodes which is used for MT8195 platform, includes
>> >> - charger
>> >> - ADC
>> >> - LED
>> >> - regulators
>> >>
>> >> Signed-off-by: Macpaul Lin <macpaul.lin@mediatek.com>
>> >> ---
>> >> arch/arm64/boot/dts/mediatek/mt6360.dtsi | 112 +++++++++++++++++++++++
>>
>> [snip..]
>>
>> >> + regulator {
>> >> + compatible = "mediatek,mt6360-regulator";
>> >> + LDO_VIN3-supply = <&mt6360_buck2>;
>> >> +
>> >> + mt6360_buck1: buck1 {
>> >> + regulator-compatible = "BUCK1";
>> >> + regulator-name = "mt6360,buck1";
>> >
>> > Normally there's no need to provide a default name. Any used regulator
>> > should have been named to match the power rail name from the board's
>> > schematics.
>> >
>>
>> I have 2 schematics on hand. One is mt8195-demo board and the other is
>> genio-1200-evk board. There are 2 PMIC used on these board
>> with "the same" sub power rail name for "BUCK1~BUCK4". One is mt6315,
>> and the other is mt6360.
>
> This is more of an board level integration thing. Regulator names are
> expected to be named after the actual power rail names. For example,
> take a look at Rock Pi 4 schematics [1], the power rail from BUCK1 of
> the RK808 PMIC is named "VDD_CENTER". And in the dts file [1] we can
> see the regulator is named that as well (albeit with some style changes).
>
> Now if a project really chooses meaningless names like BUCKx or LDOy
> for their power rails, then so be it. However those are board level
> decisions. The names are there to help with integration debugging, so
> it makes sense to have names that match the power rail names in the
> schematics. Default names rarely make sense.
>
> [1]https://dl.radxa.com/rockpi4/docs/hw/rockpi4/rockpi4_v13_sch_20181112.pdf <https://urldefense.com/v3/__https://dl.radxa.com/rockpi4/docs/hw/rockpi4/rockpi4_v13_sch_20181112.pdf__;!!CTRNKA9wMg0ARbw!g4T6kWfnETA38Kc_yc6dx6gYi7zzW2m6YU0ybNN5vbTWjK5SfapEQEQMrtxg8E9xRNdpJm678Rj3uLrWHeM$>
> [2]https://elixir.bootlin.com/linux/latest/source/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dtsi#L267 <https://urldefense.com/v3/__https://elixir.bootlin.com/linux/latest/source/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dtsi*L267__;Iw!!CTRNKA9wMg0ARbw!g4T6kWfnETA38Kc_yc6dx6gYi7zzW2m6YU0ybNN5vbTWjK5SfapEQEQMrtxg8E9xRNdpJm678Rj3hdwm0VA$>
>
>> I've also inspected other dtsi of the regulators, such as mt6357 and
>> mt6359. They have regulator nodes with named for their purpose. For the
>> schematics of mt8195-demo and genio-1200-evk boards, there are no
>> explicit usage for "BUCK1~BUCK4" for both mt6135 and mt6360. In order to
>> specify the sub power rail for mt6360, MediaTek chooses name like
>> "mt6360,buck1" instead of simple name "buck1" for distinguish with
>> "buck1" of mt6351.
>>
>> >> + regulator-min-microvolt = <300000>;
>> >> + regulator-max-microvolt = <1300000>;
>> >
>> > These values correspond to the regulator's range. They make no sense as
>> > regulator constraints. The min/max values are supposed to be the most
>> > restrictive set of voltages of the regulator consumers. If what is fed
>> > by this regulator can only take 0.7V ~ 1.1V, then it should save 0.7V
>> > and 1.1V here. If the regulator is unused, then there are no constraints,
>> > and these can be left out.
>> >
>> > Just leave them out of the file.
>> >Alexandre Mergnat <amergnat@baylibre.com>
>> > Both comments apply to all the regulators.
>> >
>> > ChenYu
>>
>> There are some common circuit design for these regulators like mt6359,
>> mt6360 and mt6315 used on many products. MediaTek put the most common
>> and expected default values in their dtsi. However, some changes still
>> need to be applied to derivative boards according to product's
>> requirements. The actual value be used will be applied in board's dts
>> file to override the default settings in dtsi.
>
> The values here are definitely not some product's expected values.
> They are the full range of output voltages supported, as seen in the
> driver.
>
> The regulator binding says:
>
> regulator-min-microvolt:
> description: smallest voltage consumers may set
>
> regulator-max-microvolt:
> description: largest voltage consumers may set
>
> The constraints given in the regulator node are those of the consumers,
> not the PMIC regulator itself. As you mentioned, a board may need to
> adjust the range based on its design, i.e. what the board has connected
> to the regulator.
>
> So either something is connected, and the consumer's constraints are set
> by overriding the default in the board .dts file; or, nothing is connected
> and the constraints don't matter, as nothing is going to set the voltage
> or enable the regulator. So there's no reason to give a default. For
> unused regulator outputs, their device nodes don't even have to exist.
>
> I'm trying to get people to _not_ write default values, as they don't
> make any sense. The full voltage range is already implied by the
> compatible string.
>
> ChenYu
Thanks for the explanation in detail.
I'll update the patch v2 for these modification.
Best regards,
Macpaul Lin
next prev parent reply other threads:[~2023-08-30 18:36 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-25 11:46 [PATCH 1/4] arm64: dts: mediatek: mt8195-demo: fix the memory size to 8GB Macpaul Lin
2023-08-25 11:46 ` [PATCH 2/4] arm64: dts: mediatek: mt8195-demo: update and reorder reserved memory regions Macpaul Lin
2023-08-25 11:46 ` [PATCH 3/4] arm64: dts: mediatek: mt6360: add PMIC MT6360 related nodes Macpaul Lin
2023-08-28 4:36 ` Chen-Yu Tsai
2023-08-28 9:59 ` Macpaul Lin
2023-08-28 10:51 ` Chen-Yu Tsai
2023-08-30 11:10 ` Macpaul Lin [this message]
2023-08-25 11:46 ` [PATCH 4/4] arm64: dts: mediatek: mt8195-demo: simplify mt6360 nodes Macpaul Lin
2023-08-30 11:15 ` [PATCH v2 1/4] arm64: dts: mediatek: mt8195-demo: fix the memory size to 8GB Macpaul Lin
2023-08-30 11:15 ` [PATCH v2 2/4] arm64: dts: mediatek: mt8195-demo: update and reorder reserved memory regions Macpaul Lin
2023-08-30 11:15 ` [PATCH v2 3/4] arm64: dts: mediatek: mt6360: add PMIC MT6360 related nodes Macpaul Lin
2023-08-30 11:20 ` Krzysztof Kozlowski
2023-08-31 5:32 ` Macpaul Lin
2023-08-30 11:15 ` [PATCH v2 4/4] arm64: dts: mediatek: mt8195-demo: simplify mt6360 nodes Macpaul Lin
2023-08-30 11:30 ` Krzysztof Kozlowski
2023-08-31 4:06 ` Macpaul Lin
2023-09-05 3:45 ` [PATCH v3 1/2] arm64: dts: mediatek: mt8195-demo: fix the memory size to 8GB Macpaul Lin
2023-09-05 3:45 ` [PATCH v3 2/2] arm64: dts: mediatek: mt8195-demo: update and reorder reserved memory regions Macpaul Lin
2023-09-05 8:01 ` AngeloGioacchino Del Regno
2023-09-05 8:00 ` [PATCH v3 1/2] arm64: dts: mediatek: mt8195-demo: fix the memory size to 8GB AngeloGioacchino Del Regno
2023-09-05 8:15 ` Macpaul Lin
2023-09-07 9:15 ` AngeloGioacchino Del Regno
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=bfff8dc1-5f1c-1da8-488c-58e83cb1e651@mediatek.com \
--to=macpaul.lin@mediatek.com \
--cc=amergnat@baylibre.com \
--cc=angelogioacchino.delregno@collabora.com \
--cc=bear.wang@mediatek.com \
--cc=chunfeng.yun@mediatek.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=fparent@baylibre.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=macpaul@gmail.com \
--cc=matthias.bgg@gmail.com \
--cc=pablo.sun@mediatek.com \
--cc=robh+dt@kernel.org \
--cc=wenst@chromium.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;
as well as URLs for NNTP newsgroup(s).