From: Dragan Simic <dsimic@manjaro.org>
To: Diederik de Haas <didi.debian@cknow.org>
Cc: Heiko Stuebner <heiko@sntech.de>, Alex Bee <knaerzche@gmail.com>,
linux-rockchip@lists.infradead.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] arm64: dts: rockchip: Add avdd supplies to hdmi on rock64
Date: Tue, 09 Jul 2024 10:40:58 +0200 [thread overview]
Message-ID: <bc4a7c9e47b1b102f27831509564fc44@manjaro.org> (raw)
In-Reply-To: <6192146.IJkX0fH94T@bagend>
Hello Diederik,
On 2024-07-08 11:55, Diederik de Haas wrote:
> On Sunday, 7 July 2024 23:23:30 CEST Dragan Simic wrote:
>> On 2024-07-04 21:18, Diederik de Haas wrote:
>> > Pine64's Rock64 was missing the avdd supply properties on the hdmi
>> > node,
>> >
>> > causing the following warnings:
>> > dwhdmi-rockchip ff3c0000.hdmi: supply avdd-0v9 not found, using
>> > dummy regulator
>> >
>> > dwhdmi-rockchip ff3c0000.hdmi: supply avdd-1v8 not found, using
>> > dummy regulator
>> >
>> > In the Rock64 Schematic document version 2.0 those supplies are marked
>> > as DVIDEO_AVDD_1V0 and DVIDEO_AVDD_1V8 respectively, but in version 3.0
>> > those are named HDMI_AVDD_1V0 and HDMI_AVDD_1V8, which is a bit
>> > clearer.
>> > In both versions those are connected to LDO3 and LDO1 respectively.
>> >
>> > While the DeviceTree property is named 'avdd-0v9-supply' the
>> >
>> > 'rockchip,dw-hdmi.yaml' binding document notes the following:
>> > A 0.9V supply that powers up the SoC internal circuitry. The actual
>> > pin name varies between the different SoCs and is usually
>> > HDMI_TX_AVDD_0V9 or sometimes HDMI_AVDD_1V0.
>> >
>> > So the 'vdd_10' reference is not an error.
>> >
>> > Signed-off-by: Diederik de Haas <didi.debian@cknow.org>
>>
>> Already verified the above-quoted statement from the .yaml binding
>> in the RK3328 and RK3399 datasheets. Thus, hoping that you agree
>> with the first line:
>>
>> Helped-by: Dragan Simic <dsimic@manjaro.org>
>
> While you helped me in several areas (understanding 'things') and I
> think
> proper attribution is very important, in this case it would be
> incorrect IMO.
> I was helped by Heiko's (big) hint in their counter-proposal (which
> does
> deserve a Helped-by tag), from that point on, it was all my own work.
>
> After Heiko's counter-proposal I had found the regulator I needed to
> reference. I then resolved the DVIDEO vs HDMI remark by looking at v2
> and v3
> of the Schematic document. Which left 1 thing to resolve ...
>
> On Thursday, 4 July 2024 12:34:18 CEST Diederik de Haas wrote:
>> I do wonder about 0.9V vs 1.0V, but I'll bug someone else about that
>> ;-)
>
> I did mean you with that, but in the end I did resolve it myself.
> I found the 'note' in the binding document and when I then found "min:
> 0.9;
> typical: 1.0; max: 1.1" in para 3.2 (page 36) of the RK3328 Datasheet,
> I felt
> I had resolved that issue sufficiently as well and was confident enough
> to sent
> the patch out (without sending you a RFC patch first).
>
>> Reviewed-by: Dragan Simic <dsimic@manjaro.org>
>
> Thanks :-)
>
>> I'd also suggest that a brief comment is added to rk3328-rock64.dts,
>> right above the "avdd-0v9-supply = <&vdd_10>;" line. Perhaps
>> something
>>
>> like this:
>> > + /*
>> > + * RK3328 requires 1.0 V on HDMI_AVDD_1V0, which is HDMI_AVDD_0V9
>> > + * and requires 0.9 V on other Rockchip SoCs
>> > + */
>
> The binding doc mention this: "The actual pin name varies between the
> different
> SoCs and is *usually* HDMI_TX_AVDD_0V9" (emphasis mine)
>
> So that comment would make stronger claims then is present in the
> binding
> document and also uses a different pin name. I also don't think it's
> useful to
> mention what other SoCs (or boards) use in the rk3328-rock64.dts.
>
> While I fully agree that the apparent discrepancy should be documented,
> I
> choose to do that in the commit message and I don't see a value to
> repeat that
> in the dts file itself.
> When I see something which looks 'odd', I'd then use `git blame` to
> find the
> commit which set that and then I'd see the commit message which
> explains it.
Just for the record, I'm fine with your decisions.
>> > ---
>> >
>> > arch/arm64/boot/dts/rockchip/rk3328-rock64.dts | 2 ++
>> > 1 file changed, 2 insertions(+)
>> >
>> > diff --git a/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
>> > b/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
>> > index 229fe9da9c2d..90fef766f3ae 100644
>> > --- a/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
>> > +++ b/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
>> > @@ -154,6 +154,8 @@ &gmac2io {
>> >
>> > };
>> >
>> > &hdmi {
>> >
>> > + avdd-0v9-supply = <&vdd_10>;
>> > + avdd-1v8-supply = <&vcc_18>;
>> >
>> > status = "okay";
>> >
>> > };
>
>
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip
next prev parent reply other threads:[~2024-07-09 8:41 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-04 19:18 [PATCH] arm64: dts: rockchip: Add avdd supplies to hdmi on rock64 Diederik de Haas
2024-07-07 21:23 ` Dragan Simic
2024-07-08 9:55 ` Diederik de Haas
2024-07-09 8:40 ` Dragan Simic [this message]
2024-07-08 14:28 ` Heiko Stuebner
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=bc4a7c9e47b1b102f27831509564fc44@manjaro.org \
--to=dsimic@manjaro.org \
--cc=devicetree@vger.kernel.org \
--cc=didi.debian@cknow.org \
--cc=heiko@sntech.de \
--cc=knaerzche@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.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