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@xxxxxxxxx>
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@xxxxxxxxxxx>
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@xxxxxxxxxxx>
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@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/linux-rockchip
