- 26 8月, 2022 2 次提交
-
-
由 Douglas Anderson 提交于
Apparently the device trees of some boards have the property "regulator-allow-set-load" for some of their regulators but then they don't specify anything for "regulator-allowed-modes". That's not really legit, but... ...before commit efb0cb50 ("regulator: qcom-rpmh: Implement get_optimum_mode(), not set_load()") they used to get away with it, at least on boards using RPMH regulators. That's because when a regulator driver implements set_load() then the core doesn't look at "regulator-allowed-modes" when trying to automatically adjust things in response to the regulator's load. The core doesn't know what mode we'll end up in, so how could it validate it? Said another way: before commit efb0cb50 ("regulator: qcom-rpmh: Implement get_optimum_mode(), not set_load()") some boards _were_ having the regulator mode adjusted despite listing no allowed modes. After commit efb0cb50 ("regulator: qcom-rpmh: Implement get_optimum_mode(), not set_load()") these same boards were now getting an error returned when trying to use their regulators, since simply enabling a regulator tries to update its load and that was failing. We don't really want to go back to the behavior from before commit efb0cb50 ("regulator: qcom-rpmh: Implement get_optimum_mode(), not set_load()"). Boards shouldn't have been changing modes if no allowed modes were listed. However, the behavior after commit efb0cb50 ("regulator: qcom-rpmh: Implement get_optimum_mode(), not set_load()") isn't the best because now boards can't even turn their regulators on. Let's choose to detect this case and return "no error" from drms_uA_update(). The net-result will be _different_ behavior than we had before commit efb0cb50 ("regulator: qcom-rpmh: Implement get_optimum_mode(), not set_load()"), but this new behavior seems more correct. If a board truly needed the mode switched then its device tree should be updated to list the allowed modes. Reported-by: NAndrew Halaney <ahalaney@redhat.com> Fixes: efb0cb50 ("regulator: qcom-rpmh: Implement get_optimum_mode(), not set_load()") Signed-off-by: NDouglas Anderson <dianders@chromium.org> Tested-by: NAndrew Halaney <ahalaney@redhat.com> Link: https://lore.kernel.org/r/20220824142229.RFT.v2.2.I6f77860e5cd98bf5c67208fa9edda4a08847c304@changeidSigned-off-by: NMark Brown <broonie@kernel.org>
-
由 Douglas Anderson 提交于
The get_optimum_mode() for regulator drivers is passed the input voltage and output voltage as well as the current. This is because, in theory, the optimum mode can depend on all three things. It turns out that for all regulator drivers in mainline only the current is looked at when implementing get_optimum_mode(). None of the drivers take the input or output voltage into account. Despite the fact that none of the drivers take the input or output voltage into account, though, the regulator framework will error out before calling into get_optimum_mode() if it doesn't know the input or output voltage. The above behavior turned out to be a probelm for some boards when we landed commit efb0cb50 ("regulator: qcom-rpmh: Implement get_optimum_mode(), not set_load()"). Before that change we'd have no problems running drms_uA_update() for RPMH regulators even if a regulator's input or output voltage was unknown. After that change drms_uA_update() started to fail. This is because typically boards using RPMH regulators don't model the input supplies of RPMH regulators. Input supplies for RPMH regulators nearly always come from the output of other RPMH regulators (or always-on regulators) and RPMH firmware is initialized with this knowledge and handles enabling (and adjusting the voltage of) input supplies. While we could model the parent/child relationship of the regulators in Linux, many boards don't bother since it adds extra overhead. Let's change the regulator core to make things work again. Now if we fail to get the input or output voltage we'll still call into get_optimum_mode() and we'll just pass error codes in for input_uV and/or output_uV parameters. Since no existing regulator drivers even look at input_uV and output_uV we don't need to add this error handling anywhere right now. We'll add some comments in the core so that it's obvious that (if regulator drivers care) it's up to them to add the checks. Reported-by: NAndrew Halaney <ahalaney@redhat.com> Fixes: efb0cb50 ("regulator: qcom-rpmh: Implement get_optimum_mode(), not set_load()") Signed-off-by: NDouglas Anderson <dianders@chromium.org> Tested-by: NAndrew Halaney <ahalaney@redhat.com> Link: https://lore.kernel.org/r/20220824142229.RFT.v2.1.I137e6bef4f6d517be7b081be926059321102fd3d@changeidSigned-off-by: NMark Brown <broonie@kernel.org>
-
- 25 8月, 2022 1 次提交
-
-
由 Yang Li 提交于
The print function dev_err() is redundant because platform_get_irq_byname() already prints an error. Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=1986Reported-by: NAbaci Robot <abaci@linux.alibaba.com> Signed-off-by: NYang Li <yang.lee@linux.alibaba.com> Link: https://lore.kernel.org/r/20220825070438.128093-1-yang.lee@linux.alibaba.comSigned-off-by: NMark Brown <broonie@kernel.org>
-
- 24 8月, 2022 11 次提交
-
-
由 ye xingchen 提交于
Return the value from regmap_write() directly instead of storing it in another redundant variable. Reported-by: NZeal Robot <zealci@zte.com.cn> Signed-off-by: Nye xingchen <ye.xingchen@zte.com.cn> Link: https://lore.kernel.org/r/20220824074707.221159-1-ye.xingchen@zte.com.cnSigned-off-by: NMark Brown <broonie@kernel.org>
-
由 Jerome Neanne 提交于
The regulators set consists of 3 bucks DCDCs and 4 LDOs. The output voltages are configurable and are meant to supply power to the main processor and other components. Validation: Visual check: cat /sys/kernel/debug/regulator/regulator_summary Validation: userspace-consumer and virtual-regulator required to test further Enable/Disable: cat /sys/devices/platform/userspace-consumer-VDDSHV_SD_IO_PMIC/state echo disabled > /sys/devices/platform/ userspace-consumer-VDDSHV_SD_IO_PMIC/state echo enabled > /sys/devices/platform/ userspace-consumer-VDDSHV_SD_IO_PMIC/state Change voltage: cat /sys/devices/platform/regulator-virtual-ldo1/min_microvolts echo 1000000 > /sys/devices/platform/regulator-virtual-ldo1/ min_microvolts echo 3000000 > /sys/devices/platform/regulator-virtual-ldo1/ max_microvolts Signed-off-by: NJerome Neanne <jneanne@baylibre.com> Link: https://lore.kernel.org/r/20220805121852.21254-9-jneanne@baylibre.comSigned-off-by: NMark Brown <broonie@kernel.org>
-
由 Iskren Chernev 提交于
The ranges and types are taken from the relevant SPMI driver: - ftsmps_510: s1-s4, s8 - buck_510: s5-s7 - ldo_nX_510: l1-l4, l6-l8, l17-18 - ldo_mv_pX_510: l5, l15, l19-l24 - ldo_lv_pX_510: l9-l14, l16 Signed-off-by: NAdam Skladowski <a39.skl@gmail.com> Signed-off-by: NIskren Chernev <iskren.chernev@gmail.com> Reviewed-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20220802221112.2280686-14-iskren.chernev@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>
-
由 Iskren Chernev 提交于
The sorting is split in multiple commits for easier reviewing. Signed-off-by: NIskren Chernev <iskren.chernev@gmail.com> Link: https://lore.kernel.org/r/20220802221112.2280686-13-iskren.chernev@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>
-
由 Iskren Chernev 提交于
The sorting is split in multiple commits for easier reviewing. Signed-off-by: NIskren Chernev <iskren.chernev@gmail.com> Link: https://lore.kernel.org/r/20220802221112.2280686-12-iskren.chernev@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>
-
由 Iskren Chernev 提交于
The sorting is split in multiple commits for easier reviewing. Signed-off-by: NIskren Chernev <iskren.chernev@gmail.com> Link: https://lore.kernel.org/r/20220802221112.2280686-11-iskren.chernev@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>
-
由 Iskren Chernev 提交于
Add support for PM6125 PMIC which is found on SM4250/6115 SoCs. S1, S2, S3, S4, S8 are FTS+FTSMPS_510, rev 2 - range is 0.3-1.372V by 4mV increments S5, S6, s7 are BUCK+HFSMPS_510, rev 4 - range is 0.32-2.04V by 8mV increment L1, L3, L7 are LDO+N600_510, rev 2 L2, L4, L8, L17, L18 are LDO+N300_510, rev 2 L6 is LDO+N1200_510, rev 2 - range is 0.32-1.304V by 8mV increment L5 is LDO+MV_P50_510, rev 2 L15, L19, L20 are LDO+MV_P150_510, rev 2 L21, L22, L23, L24 are LDO+MV_P600_510, rev 2 - range is 1.504-3.544V by 8mV increment L9, L11, L14 are LDO+LV_P600_510, rev 2 L10, L16 are LDO+LV_P150_510, rev 2 L12, L13 are LDO+LV_P300_510, rev 2 - range 1.504-2V by 8mV increment Signed-off-by: NAdam Skladowski <a39.skl@gmail.com> Signed-off-by: NIskren Chernev <iskren.chernev@gmail.com> Reviewed-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20220802221112.2280686-10-iskren.chernev@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>
-
由 Iskren Chernev 提交于
The sorting is split in multiple commits for easier reviewing. Signed-off-by: NIskren Chernev <iskren.chernev@gmail.com> Link: https://lore.kernel.org/r/20220802221112.2280686-9-iskren.chernev@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>
-
由 Iskren Chernev 提交于
The sorting is split in multiple commits for easier reviewing. Signed-off-by: NIskren Chernev <iskren.chernev@gmail.com> Link: https://lore.kernel.org/r/20220802221112.2280686-8-iskren.chernev@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>
-
由 Iskren Chernev 提交于
Add support for LDO_510 and FTSMPS3 regulators, all belonging to register layout HFSMPS. This is done in preparation for adding support for the PM6125 PMIC. For FTSMPS3 and LDO_510, only IDLE and NORMAL modes are selectable (no FAST). The inspiration for the magic constants was taken from [1] [1]: https://source.codeaurora.org/quic/la/kernel/msm-5.4/commit/?h=kernel.lnx.5.4.r1-rel&id=d1220daeffaa440ffff0a8c47322eb0033bf54f5Signed-off-by: NAdam Skladowski <a39.skl@gmail.com> Signed-off-by: NIskren Chernev <iskren.chernev@gmail.com> Link: https://lore.kernel.org/r/20220802221112.2280686-7-iskren.chernev@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>
-
由 Iskren Chernev 提交于
This is preparation for supporing PM6125. The HFSMPS is a BUCK type regulator with subtype 0x0a, same as the existing HFS430 regulator. Even though the HFSMPS and HFS430 share a type and subtype, the HFSMPS has an updated register map, including different mode values, moved pull down register, and different slew rate address and formula. In addition to NORMAL (NPM), FAST (AUTO_LPM) and IDLE (LPM), the regulator also supports RETENTION and AUTO_RM which are currently unselectable by the driver. The inspiration of this is taken from [1]. [1] https://source.codeaurora.org/quic/la/kernel/msm-5.4/commit/?h=kernel.lnx.5.4.r1-rel&id=d1220daeffaa440ffff0a8c47322eb0033bf54f5Signed-off-by: NIskren Chernev <iskren.chernev@gmail.com> Link: https://lore.kernel.org/r/20220802221112.2280686-6-iskren.chernev@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>
-
- 22 8月, 2022 1 次提交
-
-
由 Christian Kohlschütter 提交于
This message shows up occasionally but in bursts (seen up to 30 times per second on my ODROID N2+). According to Matthias Kaehlcke's comment in 'regulator: core: silence warning: "VDD1: ramp_delay not set"', this message should have been removed after restructuring previous code that assumed that ramp_delay being zero in that function was an error. Link: https://lore.kernel.org/lkml/625675256c0d75805f088b4be17a3308dc1b7ea4.1477571498.git.hns@goldelico.com/T/Signed-off-by: NChristian Kohlschütter <christian@kohlschutter.com> Link: https://lore.kernel.org/r/20220820131420.16608-1-christian@kohlschutter.comSigned-off-by: NMark Brown <broonie@kernel.org>
-
- 18 8月, 2022 2 次提交
-
-
由 Christian Kohlschütter 提交于
Previously, an unresolved regulator supply reference upon calling regulator_register on an always-on or boot-on regulator caused set_machine_constraints to be called twice. This in turn may initialize the regulator twice, leading to voltage glitches that are timing-dependent. A simple, unrelated configuration change may be enough to hide this problem, only to be surfaced by chance. One such example is the SD-Card voltage regulator in a NanoPI R4S that would not initialize reliably unless the registration flow was just complex enough to allow the regulator to properly reset between calls. Fix this by re-arranging regulator_register, trying resolve the regulator's supply early enough that set_machine_constraints does not need to be called twice. Signed-off-by: NChristian Kohlschütter <christian@kohlschutter.com> Link: https://lore.kernel.org/r/20220818124646.6005-1-christian@kohlschutter.comSigned-off-by: NMark Brown <broonie@kernel.org>
-
由 Matti Vaittinen 提交于
A few regulator consumer drivers seem to be just getting a regulator, enabling it and registering a devm-action to disable the regulator at the driver detach and then forget about it. We can simplify this a bit by adding a devm-helper for this pattern. Add devm_regulator_get_enable() and devm_regulator_get_enable_optional() Signed-off-by: NMatti Vaittinen <mazziesaccount@gmail.com> Link: https://lore.kernel.org/r/ed7b8841193bb9749d426f3cb3b199c9460794cd.1660292316.git.mazziesaccount@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>
-
- 15 8月, 2022 1 次提交
-
-
由 Douglas Anderson 提交于
Since we don't actually pass the load to the firmware, switch to using get_optimum_mode() instead of open-coding it. This is intended to have no effect other than cleanup. Signed-off-by: NDouglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20220726102024.1.Icc838fe7bf0ef54a014ab2fee8af311654f5342a@changeidSigned-off-by: NMark Brown <broonie@kernel.org>
-
- 10 8月, 2022 1 次提交
-
-
由 Douglas Anderson 提交于
In commit 6eabfc01 ("regulator: core: Allow specifying an initial load w/ the bulk API") I changed the error handling but had a subtle that caused us to always return no error even if there was an error. Fix it. Fixes: 6eabfc01 ("regulator: core: Allow specifying an initial load w/ the bulk API") Signed-off-by: NDouglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20220809142738.1.I91625242f137c707bb345c51c80c5ecee02eeff3@changeidSigned-off-by: NMark Brown <broonie@kernel.org>
-
- 27 7月, 2022 3 次提交
-
-
由 Douglas Anderson 提交于
Drivers tend to want to define the names of their regulators somewhere in their source file as "static const". This means, inevitable, that every driver out there open codes something like this: static const char * const supply_names[] = { "vcc", "vccl", }; static int get_regulators(struct my_data *data) { int i; data->supplies = devm_kzalloc(...) if (!data->supplies) return -ENOMEM; for (i = 0; i < ARRAY_SIZE(supply_names); i++) data->supplies[i].supply = supply_names[i]; return devm_regulator_bulk_get(data->dev, ARRAY_SIZE(supply_names), data->supplies); } Let's make this more convenient by doing providing a helper that does the copy. I have chosen to have the "const" input structure here be the exact same structure as the normal one passed to devm_regulator_bulk_get(). This is slightly inefficent since the input data can't possibly have anything useful for "ret" or consumer and thus we waste 8 bytes per structure. This seems an OK tradeoff for not introducing an extra structure. Signed-off-by: NDouglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20220726103631.v2.6.I38fc508a73135a5c1b873851f3553ff2a3a625f5@changeidSigned-off-by: NMark Brown <broonie@kernel.org>
-
由 Douglas Anderson 提交于
There are a number of drivers that follow a pattern that looks like this: 1. Use the regulator bulk API to get a bunch of regulators. 2. Set the load on each of the regulators to use whenever the regulators are enabled. Let's make this easier by just allowing the drivers to pass the load in. As part of this change we need to move the error printing in regulator_bulk_get() around; let's switch to the new dev_err_probe() to simplify it. Signed-off-by: NDouglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20220726103631.v2.4.Ie85f68215ada39f502a96dcb8a1f3ad977e3f68a@changeidSigned-off-by: NMark Brown <broonie@kernel.org>
-
由 Jean Delvare 提交于
With the following configuration options: CONFIG_OF is not set CONFIG_REGULATOR_MT6380=y we get the following build warning: CC drivers/regulator/mt6380-regulator.o drivers/regulator/mt6380-regulator.c:322:34: warning: ‘mt6380_of_match’ defined but not used [-Wunused-const-variable=] Fix this by annotating that array with __maybe_unused, as done in various regulator drivers. Signed-off-by: NJean Delvare <jdelvare@suse.de> Reported-by: Nkernel test robot <lkp@intel.com> Link: https://lore.kernel.org/all/202207240252.ZY5hSCNB-lkp@intel.com/ Cc: Liam Girdwood <lgirdwood@gmail.com> Cc: Mark Brown <broonie@kernel.org> Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: Chenglin Xu <chenglin.xu@mediatek.com> Link: https://lore.kernel.org/r/20220727132637.76d6073f@endymion.delvareSigned-off-by: NMark Brown <broonie@kernel.org>
-
- 20 7月, 2022 1 次提交
-
-
由 Christian Kohlschütter 提交于
Regulators marked with "regulator-always-on" or "regulator-boot-on" as well as an "off-on-delay-us", may run into cycling issues that are hard to detect. This is caused by the "last_off" state not being initialized in this case. Fix the "last_off" initialization by setting it to the current kernel time upon initialization, regardless of always_on/boot_on state. Signed-off-by: NChristian Kohlschütter <christian@kohlschutter.com> Link: https://lore.kernel.org/r/FAFD5B39-E9C4-47C7-ACF1-2A04CD59758D@kohlschutter.comSigned-off-by: NMark Brown <broonie@kernel.org>
-
- 15 7月, 2022 2 次提交
-
-
由 Liang He 提交于
We should call the of_node_put() for the reference returned by of_get_child_by_name() which has increased the refcount. Fixes: 40e20d68 ("regulator: of: Add support for parsing regulator_state for suspend state") Signed-off-by: NLiang He <windhl@126.com> Link: https://lore.kernel.org/r/20220715111027.391032-1-windhl@126.comSigned-off-by: NMark Brown <broonie@kernel.org>
-
由 Axel Lin 提交于
Remove the code checking and returning uninitialized variable. Signed-off-by: NAxel Lin <axel.lin@ingics.com> Link: https://lore.kernel.org/r/20220714101212.502824-1-axel.lin@ingics.comSigned-off-by: NMark Brown <broonie@kernel.org>
-
- 11 7月, 2022 4 次提交
-
-
由 Robert Marko 提交于
PMP8074 is a companion PMIC for the Qualcomm IPQ8074 WiSoC-s. It features 5 HF-SMPS and 13 LDO regulators. HF-SMPS regulators are Buck HFS430 regulators. L1, L2 and L3 are HT_N1200_ST subtype LDO regulators. L4 is HT_N300_ST subtype LDO regulator. L5 and L6 are HT_P600 subtype LDO regulators. L7, L11, L12 and L13 are HT_P150 subtype LDO regulators. L10 is HT_P50 subtype LDO regulator. This commit adds support for all of the buck regulators and LDO-s except for L10 as I dont have documentation on its output voltage range. S3 is the CPU cluster voltage supply, S4 supplies the UBI32 NPU cores and L11 is the SDIO/eMMC I/O voltage regulator required for high speeds. Signed-off-by: NRobert Marko <robimarko@gmail.com> Link: https://lore.kernel.org/r/20220704212402.1715182-7-robimarko@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>
-
由 Robert Marko 提交于
HT_P600 is a LDO PMOS regulator based on LV P600 using HFS430 layout found in PMP8074 and PMS405 PMIC-s. Both PMP8074 and PMS405 define the programmable range as 1.704 to 1.896V but the actual MAX output voltage depends on the exact LDO in each of the PMIC-s. Their usual voltage that they are used is 1.8V. It has a max current of 600mA, voltage step of 8mV. Signed-off-by: NRobert Marko <robimarko@gmail.com> Link: https://lore.kernel.org/r/20220704212402.1715182-5-robimarko@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>
-
由 Robert Marko 提交于
HT_P150 is a LDO PMOS regulator based on LV P150 using HFS430 layout found in PMP8074 and PMS405 PMIC-s. Both PMP8074 and PMS405 define the programmable range as 1.616V to 3.304V but the actual MAX output voltage depends on the exact LDO in each of the PMIC-s. It has a max current of 150mA, voltage step of 8mV. Signed-off-by: NRobert Marko <robimarko@gmail.com> Link: https://lore.kernel.org/r/20220704212402.1715182-4-robimarko@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>
-
由 Jiapeng Chong 提交于
The patch makes sense but these are not compile warnings. They come from scripts/checkversion.pl, which can be called by 'make versioncheck', so I suppose that something in your build system is running 'make versioncheck'. Eliminate the follow versioncheck warning: ./drivers/regulator/max597x-regulator.c: 21 linux/version.h not needed. Reported-by: NAbaci Robot <abaci@linux.alibaba.com> Signed-off-by: NJiapeng Chong <jiapeng.chong@linux.alibaba.com> Link: https://lore.kernel.org/r/20220711034011.46096-1-jiapeng.chong@linux.alibaba.comSigned-off-by: NMark Brown <broonie@kernel.org>
-
- 07 7月, 2022 1 次提交
-
-
由 Mark Brown 提交于
Drivers should depend on rather than select their MFDs. Reported-by: NStephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: NMark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20220707111753.16581-1-broonie@kernel.orgSigned-off-by: NMark Brown <broonie@kernel.org>
-
- 06 7月, 2022 1 次提交
-
-
由 Zhang Jiaming 提交于
Use Complete data type declaration of 'sel' in ti_abb_set_voltage_sel(). Fix spelling of 'are'nt' in comments. Signed-off-by: NZhang Jiaming <jiaming@nfschina.com> Link: https://lore.kernel.org/r/20220705071445.21124-1-jiaming@nfschina.comSigned-off-by: NMark Brown <broonie@kernel.org>
-
- 05 7月, 2022 1 次提交
-
-
由 Patrick Rudolph 提交于
max597x is hot swap controller. This regulator driver controls the same & also configures fault protection features supported by the chip. Signed-off-by: NPatrick Rudolph <patrick.rudolph@9elements.com> Signed-off-by: NMarcello Sylvester Bauer <sylv@sylv.io> Signed-off-by: NNaresh Solanki <Naresh.Solanki@9elements.com> Link: https://lore.kernel.org/r/20220705122244.472894-4-Naresh.Solanki@9elements.comSigned-off-by: NMark Brown <broonie@kernel.org>
-
- 30 6月, 2022 1 次提交
-
-
由 Liang He 提交于
In scmi_regulator_probe(), of_find_node_by_name() will decrease the refcount of its first argument and we need a of_node_get() to keep reference balance. Signed-off-by: NLiang He <windhl@126.com> Reviewed-by: NCristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20220622034816.4094043-1-windhl@126.comSigned-off-by: NMark Brown <broonie@kernel.org>
-
- 29 6月, 2022 4 次提交
-
-
由 Stephan Gerhold 提交于
The set of regulators available in the PM8909 PMIC is similar to PM8916 which is already supported by the driver. s3, s4 and l16 are missing. However, probing the SPMI hardware identification registers using the qcom_spmi-regulator driver reveals that the regulators in PM8909 are actually some kind of mixture between PM8916 and PM8226: - ult_lo_smps (= pm8916_buck_lvo_smps): s1 - ult_ho_smps (= pm8916_buck_hvo_smps): s2 - ult_nldo (= pm8916_nldo): l1, l2, l3, l10 - ult_pldo (= pm8916_pldo): l4, l8, l9, l12-l15, l17, l18 - pldo (= pm8226_pldo): l5, l6, l7, l11 Use this mapping to add the rpm_regulator_data for PM8909 by reusing the existing regulator definitions. Signed-off-by: NStephan Gerhold <stephan.gerhold@kernkonzept.com> Link: https://lore.kernel.org/r/20220623094614.1410180-4-stephan.gerhold@kernkonzept.comSigned-off-by: NMark Brown <broonie@kernel.org>
-
由 Stephan Gerhold 提交于
The PM8916 device specification [1] documents a programmable range of 1.75V to 3.337V with 12.5mV steps for the PMOS LDOs in PM8916. This range is also used when controlling the regulator directly using the qcom_spmi-regulator driver ("ult_pldo" there). However, for some reason the qcom_smd-regulator driver allows a much larger range for the same hardware component. This could be simply a typo, since the start of the range is essentially just missing a '1'. In practice this does not cause any major problems, since the driver just sends the actual voltage to the RPM firmware instead of making use of the incorrect voltage selector. Still, having the wrong range there is confusing and prevents the regulator core from validating requests correctly. [1]: https://developer.qualcomm.com/download/sd410/pm8916pm8916-1-power-management-ic-device-specification.pdf Fixes: 57d65676 ("regulator: qcom-smd: Add PM8916 support") Signed-off-by: NStephan Gerhold <stephan.gerhold@kernkonzept.com> Link: https://lore.kernel.org/r/20220623094614.1410180-2-stephan.gerhold@kernkonzept.comSigned-off-by: NMark Brown <broonie@kernel.org>
-
由 ChiYuan Huang 提交于
'platform_device_id' struct is defined in 'mod_devicetable.h'. Even 'of.h' also includes this header usage. The 'of.h' cannot be removed due to 'of_match_ptr' function. Signed-off-by: NChiYuan Huang <cy_huang@richtek.com> Reviewed-by: NAngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/1656466861-7737-2-git-send-email-u0084500@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>
-
由 ChiYuan Huang 提交于
From the common binding, 'enable-gpio' or 'enable-gpios' are all well for external 'enable' gpio. 'gpiod_get_from_of_node' only parse the 'enable' property, it need to add the gpio suffix. It's more convenient to use fwnode_gpiod_get_index. Although fwnode parsing is not preferred, but 'of_parse_cb' already can guarantee the callback will only be used by regulator of_node parsing. Signed-off-by: NChiYuan Huang <cy_huang@richtek.com> Link: https://lore.kernel.org/r/1656466861-7737-1-git-send-email-u0084500@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>
-
- 23 6月, 2022 2 次提交
-
-
由 ChiYuan Huang 提交于
Add mt6370 DisplayBias and VibLDO support. Signed-off-by: NChiYuan Huang <cy_huang@richtek.com> Link: https://lore.kernel.org/r/20220623115631.22209-10-peterwu.pub@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>
-
由 ChiYuan Huang 提交于
Add RT5120 PMIC regulator support. It integrates 4 buck convertes, 1 LDO voltage regulator, 1 external enable signal to control the external power source. Signed-off-by: NChiYuan Huang <cy_huang@richtek.com> Link: https://lore.kernel.org/r/1655892104-10874-4-git-send-email-u0084500@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>
-
- 13 6月, 2022 1 次提交
-
-
由 Stephen Kitt 提交于
backlight_properties.fb_blank is deprecated. The states it represents are handled by other properties; but instead of accessing those properties directly, drivers should use the helpers provided by backlight.h. Instead of retrieving the backlight brightness in struct backlight_properties manually, and then checking whether the backlight should be on at all, use backlight_get_brightness() which does all this and insulates this from future changes. Signed-off-by: NStephen Kitt <steve@sk2.org> Cc: Liam Girdwood <lgirdwood@gmail.com> Cc: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20220607185304.1128962-1-steve@sk2.orgSigned-off-by: NMark Brown <broonie@kernel.org>
-