Re: [PATCH v2 3/3] arm64: dts: qcom: sa8295p-adp: Add max20411 on i2c12

From: Andrew Halaney
Date: Thu Jan 26 2023 - 18:45:37 EST


On Fri, Jan 27, 2023 at 12:35:37AM +0100, Konrad Dybcio wrote:
>
>
> On 26.01.2023 23:54, Andrew Halaney wrote:
> > On Tue, Jan 24, 2023 at 10:44:40AM -0800, Bjorn Andersson wrote:
> >> From: Bjorn Andersson <bjorn.andersson@xxxxxxxxxx>
> >>
> >> The SA8295P ADP has a Maxim max20411 step-down converter on i2c12.
> >>
> >> Signed-off-by: Bjorn Andersson <bjorn.andersson@xxxxxxxxxx>
> >> Signed-off-by: Bjorn Andersson <quic_bjorande@xxxxxxxxxxx>
> >> ---
> >>
> >> Changes since v1:
> >> - i2c node had changed name
> >>
> >> arch/arm64/boot/dts/qcom/sa8295p-adp.dts | 41 ++++++++++++++++++++++++
> >> 1 file changed, 41 insertions(+)
> >
> > I realized today this has to do with the comment over at:
> >
> > https://lore.kernel.org/all/30166208-ba9d-e6e6-1cd2-807a80536052@xxxxxxxxxxx/
> >
> > and I just didn't realize that the schematic I've started looking at
> > black boxes the SOM/SIP which holds this... darn I thought I could see
> > more than I could :(
> >
> > I took a similiar patch for a spin on sa8540p-ride (which I'll later
> > submit), and things worked fine (I'm not really consuming the output of
> > the regulator mind you).
> >
> > Downstream devicetree indicates all of this looks ok except for possibly
> > the below comment:
> >
> >>
> >> diff --git a/arch/arm64/boot/dts/qcom/sa8295p-adp.dts b/arch/arm64/boot/dts/qcom/sa8295p-adp.dts
> >> index bb4270e8f551..642000d95812 100644
> >> --- a/arch/arm64/boot/dts/qcom/sa8295p-adp.dts
> >> +++ b/arch/arm64/boot/dts/qcom/sa8295p-adp.dts
> >> @@ -266,6 +266,27 @@ &dispcc1 {
> >> status = "okay";
> >> };
> >>
> >> +&i2c12 {
> >> + pinctrl-names = "default";
> >> + pinctrl-0 = <&i2c12_state>;
> >> +
> >> + status = "okay";
> >> +
> >> + vdd_gfx: regulator@39 {
> >> + compatible = "maxim,max20411";
> >> + reg = <0x39>;
> >> +
> >> + regulator-name = "vdd_gfx";
> >> + regulator-min-microvolt = <800000>;
> >
> > Is there a reason you chose this instead of the 500000 I see downstream?
> >
> >> + regulator-max-microvolt = <968750>;
> >
> > Likewise, I see in this brief description of the regulator
> > that the upper bound is higher than this (1.275 V). I am not sure if
> > the values in the devicetree are supposed to describe the
> > min/max of the regulator itself, or of what your board can really
> > handle/needs (the latter I guess makes more sense since you wouldn't want to
> > accidentally request a current draw that could melt something.. that can
> > be fun). I do see you've got that min/max in the driver itself (now that
> > I peaked at that patch).
> Yes, your suspicions are correct and the DT sets the actual ranges
> for the voltage regulators on this specific board while the
> hardware reachable ranges are defined in the .c driver.
>
> Konrad

Thanks Konrad, then I think:

Reviewed-by: Andrew Halaney <ahalaney@xxxxxxxxxx>
Tested-by: Andrew Halaney <ahalaney@xxxxxxxxxx>

is appropriate since things are within range on all accounts. I would
appreciate an explanation on the current min/max values though if possible!