On Thu, Jan 26, 2023 at 05:43:54PM -0600, Andrew Halaney wrote: > 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! > I will add a line about the range as I resubmit the patch. Thanks, Bjorn
