Re: [PATCH v3 0/4] regulator_sync_state() support
On Wed, 15 Jul 2020 21:20:49 -0700, Saravana Kannan wrote: > Consider the following example: > - regulator-X is provided by device-X. > - regulator-X is a supplier to device-A, device-B and device-C. > - device-A is off/inactive from boot. > - device-B and device-C are left on/active by the bootloader > - regulator-X is left on boot by the bootloader at 2000 mV to supply > device-B and device-C. > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next Thanks! [1/1] regulator: core: Add destroy_regulator() commit: e1794aa43f17bf2512c10370c6be6ea24a6f29d0 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
Re: [PATCH v3 0/4] regulator_sync_state() support
On Wed, Jul 15, 2020 at 9:20 PM Saravana Kannan wrote: > > Consider the following example: > - regulator-X is provided by device-X. > - regulator-X is a supplier to device-A, device-B and device-C. > - device-A is off/inactive from boot. > - device-B and device-C are left on/active by the bootloader > - regulator-X is left on boot by the bootloader at 2000 mV to supply > device-B and device-C. > > Example boot sequence 1: > 1. device-X is probed successfully. > 2. device-A is probed by driver-A >a. driver-A gets regulator-X >b. driver-A votes on regulator-X >c. driver-A initializes device-A >d. driver-A votes off regulator-X >e. regulator-X is turned off. > 3. System crashes or device-B and device-C become unreliable because >regulator-X was turned off without following the proper quiescing >steps for device-B and device-C. > > Example boot sequence 2: > 1. device-X is probed successfully. > 2. device-B is probed by driver-B >a. driver-B gets regulator-X >b. driver-B votes on regulator-X >c. driver-B lowers device-B performance point. >d. driver-B lowers voltage vote to 1000 mV. >e. regulator-X voltage is lowered to 1000 mV. > 3. System crashes or device-C becomes unreliable because regulator-X >voltage was lowered to 1000 mV when device-C still needed it at 2000 mV Marek, I'd appreciate it if you could test this series to see if it fixes your coupled regulator issue that you reported earlier. I'm expecting it to fix it without needing any special case handling in your regulator drivers. But it'll be good to get confirmation from you. Thanks, Saravana
[PATCH v3 0/4] regulator_sync_state() support
Consider the following example: - regulator-X is provided by device-X. - regulator-X is a supplier to device-A, device-B and device-C. - device-A is off/inactive from boot. - device-B and device-C are left on/active by the bootloader - regulator-X is left on boot by the bootloader at 2000 mV to supply device-B and device-C. Example boot sequence 1: 1. device-X is probed successfully. 2. device-A is probed by driver-A a. driver-A gets regulator-X b. driver-A votes on regulator-X c. driver-A initializes device-A d. driver-A votes off regulator-X e. regulator-X is turned off. 3. System crashes or device-B and device-C become unreliable because regulator-X was turned off without following the proper quiescing steps for device-B and device-C. Example boot sequence 2: 1. device-X is probed successfully. 2. device-B is probed by driver-B a. driver-B gets regulator-X b. driver-B votes on regulator-X c. driver-B lowers device-B performance point. d. driver-B lowers voltage vote to 1000 mV. e. regulator-X voltage is lowered to 1000 mV. 3. System crashes or device-C becomes unreliable because regulator-X voltage was lowered to 1000 mV when device-C still needed it at 2000 mV This patch series makes sure these examples are handled correctly and system crash or device instability is avoided and the system remains usable. More details provided in the commit texts. v2->v3: Patch 2/4 - No functional change. Simple refactor. Patch 3/4 - Was Patch 2/2 in v2. - Rewrote commit text to hopefully address all previous points. - Renamed variable/functions. Hope it's clearer. - Added more comments. - Added logging - Fixed timeout functionality. - Handle exclusive consumers properly - Handle coupled regulators properly Patch 4/4 - Prevents voltage from going too low during boot. v1->v2: Patch 1/2 - New patch Patch 2/2 - This was the only patch in v1 - Made the late_initcall_sync timeout a commandline param - If timeout is set, we also give up waiting for all consumers after the timeout expires. - Made every regulator driver add sync_state() support Saravana Kannan (4): driver core: Add dev_set_drv_sync_state() regulator: core: Add destroy_regulator() regulator: core: Add basic enable/disable support for sync_state() callbacks regulator: core: Add voltage support for sync_state() callbacks drivers/regulator/core.c | 200 --- include/linux/device.h | 12 ++ include/linux/regulator/driver.h | 2 + 3 files changed, 198 insertions(+), 16 deletions(-) -- 2.28.0.rc0.105.gf9edc3c819-goog
