| Message ID | 20220726173824.1166873-1-dianders@chromium.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | drm/msm/dsi regulator improvements | expand |
On Tue, 26 Jul 2022 10:38:17 -0700, Douglas Anderson wrote: > The main goal of this series is to make a small dent in cleaning up > the way we deal with regulator loads. The idea is to add some extra > functionality to the regulator "bulk" API so that consumers can > specify the load using that. Though I didn't convert everyone over, I > include patches in this series that show how the Qualcomm DSI driver > is improved by this. > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next Thanks! [4/7] regulator: core: Allow specifying an initial load w/ the bulk API commit: 6eabfc018e8d1033e7fc1efce30a872e2dccb537 [6/7] regulator: core: Allow drivers to define their init data as const commit: 1de452a0edda26f1483d1d934f692eab13ba669a All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
On Tue, Jul 26, 2022 at 10:38:17AM -0700, Douglas Anderson wrote: > * After that I have patches that add to the regulator API and then > show a usage of those in the DSI driver. I'd expect that the two > regulator patches could land in the regulator tree. The DSI patches > would need to wait until the new regulator changes are available. The following changes since commit f2906aa863381afb0015a9eb7fefad885d4e5a56: Linux 5.19-rc1 (2022-06-05 17:18:54 -0700) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git tags/regulator-load-bulk-api for you to fetch changes up to 1de452a0edda26f1483d1d934f692eab13ba669a: regulator: core: Allow drivers to define their init data as const (2022-07-27 13:47:30 +0100) ---------------------------------------------------------------- regulator: Consumer load management improvements The main goal of this series is to make a small dent in cleaning up the way we deal with regulator loads. The idea is to add some extra functionality to the regulator "bulk" API so that consumers can specify the load using that. ---------------------------------------------------------------- Douglas Anderson (2): regulator: core: Allow specifying an initial load w/ the bulk API regulator: core: Allow drivers to define their init data as const drivers/regulator/core.c | 20 ++++++++++++-------- drivers/regulator/devres.c | 28 ++++++++++++++++++++++++++++ include/linux/regulator/consumer.h | 16 ++++++++++++---- 3 files changed, 52 insertions(+), 12 deletions(-)
The main goal of this series is to make a small dent in cleaning up the way we deal with regulator loads. The idea is to add some extra functionality to the regulator "bulk" API so that consumers can specify the load using that. Though I didn't convert everyone over, I include patches in this series that show how the Qualcomm DSI driver is improved by this. I'd expect: * The first two patches are bugfixes found while converting the DSI driver over. Those could land any time. * The third patch ("drm/msm/dsi: Don't set a load before disabling a regulator") is a patch a sent the other day verbatim, included in this series because it's highly related. It could land any time. That's why I called this series "v2". * After that I have patches that add to the regulator API and then show a usage of those in the DSI driver. I'd expect that the two regulator patches could land in the regulator tree. The DSI patches would need to wait until the new regulator changes are available. Changes in v2: - ("Fix number of regulators for msm8996_dsi_cfg") new for v2. - ("Fix number of regulators for SDM660") new for v2. - ("Allow specifying an initial load w/ the bulk API") new for v2. - ("Use the new regulator bulk feature to specify the load") new for v2. - ("Allow drivers to define their init data as const") new for v2. - ("Take advantage of devm_regulator_bulk_get_const") new for v2. Douglas Anderson (7): drm/msm/dsi: Fix number of regulators for msm8996_dsi_cfg drm/msm/dsi: Fix number of regulators for SDM660 drm/msm/dsi: Don't set a load before disabling a regulator regulator: core: Allow specifying an initial load w/ the bulk API drm/msm/dsi: Use the new regulator bulk feature to specify the load regulator: core: Allow drivers to define their init data as const drm/msm/dsi: Take advantage of devm_regulator_bulk_get_const() drivers/gpu/drm/msm/dsi/dsi.h | 1 - drivers/gpu/drm/msm/dsi/dsi_cfg.c | 172 +++++++++--------- drivers/gpu/drm/msm/dsi/dsi_cfg.h | 3 +- drivers/gpu/drm/msm/dsi/dsi_host.c | 61 +------ drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 41 +---- drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c | 4 +- drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c | 6 +- drivers/gpu/drm/msm/dsi/phy/dsi_phy_20nm.c | 4 +- drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c | 6 +- .../gpu/drm/msm/dsi/phy/dsi_phy_28nm_8960.c | 2 +- drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c | 6 +- drivers/regulator/core.c | 20 +- drivers/regulator/devres.c | 28 +++ include/linux/regulator/consumer.h | 16 +- 14 files changed, 165 insertions(+), 205 deletions(-)