| Message ID | 20211003083141.613509-4-luca@z3ntu.xyz (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | Initial Fairphone 4 support | expand |
On Sun, Oct 03, 2021 at 10:31:26AM +0200, Luca Weiss wrote: > Add the configuration for pm6350 regulators. The supplies are not known > so use dummy ones for now. If you don't know don't fix it into ABI, just don't specify anything until someone figures out something accurate to put in there. > Additionally leave out configuration of smps3 - smps5 and ldo17 as these > are not configured in the downstream kernel. Just describe everything that's there - nothing will get touched if the board doesn't explicitly enable doing so, otherwise everything is read only.
Hi Mark, On Montag, 4. Oktober 2021 14:37:31 CEST Mark Brown wrote: > On Sun, Oct 03, 2021 at 10:31:26AM +0200, Luca Weiss wrote: > > Add the configuration for pm6350 regulators. The supplies are not known > > so use dummy ones for now. > > If you don't know don't fix it into ABI, just don't specify anything > until someone figures out something accurate to put in there. > The RPMH_VREG macro expects _supply_name so what should I put there instead? > > Additionally leave out configuration of smps3 - smps5 and ldo17 as these > > are not configured in the downstream kernel. > > Just describe everything that's there - nothing will get touched if the > board doesn't explicitly enable doing so, otherwise everything is read > only. Problem is I do not know which types those regulators are, e.g. pldo or nldo. The ones I described are experimentally verified because the wrong configuration makes the driver probe fail. So I can't really put anything there, unless there's another way to do this. Regards Luca
On Mon, Oct 04, 2021 at 10:44:25PM +0200, Luca Weiss wrote: > On Montag, 4. Oktober 2021 14:37:31 CEST Mark Brown wrote: > > If you don't know don't fix it into ABI, just don't specify anything > > until someone figures out something accurate to put in there. > The RPMH_VREG macro expects _supply_name so what should I put there instead? NULL should do the right thing, or make a new macro. > > > Additionally leave out configuration of smps3 - smps5 and ldo17 as these > > > are not configured in the downstream kernel. > > Just describe everything that's there - nothing will get touched if the > > board doesn't explicitly enable doing so, otherwise everything is read > > only. > Problem is I do not know which types those regulators are, e.g. pldo or nldo. > The ones I described are experimentally verified because the wrong configuration > makes the driver probe fail. > So I can't really put anything there, unless there's another way to do this. That makes sense, please explain in the commit log that only are they not initialized but also you don't know what types they are.
diff --git a/drivers/regulator/qcom-rpmh-regulator.c b/drivers/regulator/qcom-rpmh-regulator.c index 7f458d510483..6ea111bccadb 100644 --- a/drivers/regulator/qcom-rpmh-regulator.c +++ b/drivers/regulator/qcom-rpmh-regulator.c @@ -1047,6 +1047,34 @@ static const struct rpmh_vreg_init_data pm6150l_vreg_data[] = { {} }; +static const struct rpmh_vreg_init_data pm6350_vreg_data[] = { + RPMH_VREG("smps1", "smp%s1", &pmic5_ftsmps510, "vdd-s1"), + RPMH_VREG("smps2", "smp%s2", &pmic5_hfsmps510, "vdd-s2"), + /* smps3 - smps5 not configured */ + RPMH_VREG("ldo1", "ldo%s1", &pmic5_nldo, "vdd-l1"), + RPMH_VREG("ldo2", "ldo%s2", &pmic5_pldo, "vdd-l2"), + RPMH_VREG("ldo3", "ldo%s3", &pmic5_pldo, "vdd-l3"), + RPMH_VREG("ldo4", "ldo%s4", &pmic5_nldo, "vdd-l4"), + RPMH_VREG("ldo5", "ldo%s5", &pmic5_pldo, "vdd-l5"), + RPMH_VREG("ldo6", "ldo%s6", &pmic5_pldo, "vdd-l6"), + RPMH_VREG("ldo7", "ldo%s7", &pmic5_pldo, "vdd-l7"), + RPMH_VREG("ldo8", "ldo%s8", &pmic5_pldo, "vdd-l8"), + RPMH_VREG("ldo9", "ldo%s9", &pmic5_pldo, "vdd-l9"), + RPMH_VREG("ldo10", "ldo%s10", &pmic5_pldo, "vdd-l10"), + RPMH_VREG("ldo11", "ldo%s11", &pmic5_pldo, "vdd-l11"), + RPMH_VREG("ldo12", "ldo%s12", &pmic5_pldo, "vdd-l12"), + RPMH_VREG("ldo13", "ldo%s13", &pmic5_nldo, "vdd-l13"), + RPMH_VREG("ldo14", "ldo%s14", &pmic5_pldo, "vdd-l14"), + RPMH_VREG("ldo15", "ldo%s15", &pmic5_nldo, "vdd-l15"), + RPMH_VREG("ldo16", "ldo%s16", &pmic5_nldo, "vdd-l16"), + /* ldo17 not configured */ + RPMH_VREG("ldo18", "ldo%s18", &pmic5_nldo, "vdd-l18"), + RPMH_VREG("ldo19", "ldo%s19", &pmic5_nldo, "vdd-l19"), + RPMH_VREG("ldo20", "ldo%s20", &pmic5_nldo, "vdd-l20"), + RPMH_VREG("ldo21", "ldo%s21", &pmic5_nldo, "vdd-l21"), + RPMH_VREG("ldo22", "ldo%s22", &pmic5_nldo, "vdd-l22"), +}; + static const struct rpmh_vreg_init_data pmx55_vreg_data[] = { RPMH_VREG("smps1", "smp%s1", &pmic5_ftsmps510, "vdd-s1"), RPMH_VREG("smps2", "smp%s2", &pmic5_hfsmps510, "vdd-s2"), @@ -1201,6 +1229,10 @@ static const struct of_device_id __maybe_unused rpmh_regulator_match_table[] = { .compatible = "qcom,pm6150l-rpmh-regulators", .data = pm6150l_vreg_data, }, + { + .compatible = "qcom,pm6350-rpmh-regulators", + .data = pm6350_vreg_data, + }, { .compatible = "qcom,pmc8180-rpmh-regulators", .data = pm8150_vreg_data,
Add the configuration for pm6350 regulators. The supplies are not known so use dummy ones for now. Additionally leave out configuration of smps3 - smps5 and ldo17 as these are not configured in the downstream kernel. Signed-off-by: Luca Weiss <luca@z3ntu.xyz> --- If anybody has a datasheet for pm6350 lying around, please double check if the configuration is correct, I'm relatively sure it is correct though as the driver doesn't probe when e.g. pldo instead of nldo is configured. drivers/regulator/qcom-rpmh-regulator.c | 32 +++++++++++++++++++++++++ 1 file changed, 32 insertions(+)