On Wed, 2016-02-03 at 12:29 +0000, Mark Brown wrote: > On Wed, Feb 03, 2016 at 01:39:02PM +0800, menghui lin wrote: > > On Tue, 2016-02-02 at 19:38 +0000, Mark Brown wrote: > > > > How does the driver know if it needs to change the mode (ie, how can it > > > tell if the current mode is inadequate) and surely if we can only change > > > in one direction this isn't terribly useful? > > > I think the datasheet of buck/ldo could provide information about power > > capability of each mode. The driver should adjust regulator mode per its > > device's power requirement. > > That's of no help for a consumer driver which doesn't know what > regulator is supplying it. > > > case 1: > > > We have a USB typeC micro-controller, which has two modes - standby and > > normal. It requires 1.8V and 3.3V to operate (both powers are always > > on). The device stays in standby mode when there is no cable in. When > > cable in, we got an interrupt and change device into normal mode. > > > The standby mode power consumption is quite small, so we would like the > > change mode of regulator into STANDBY to save more power. And we change > > into NORMAL when we receive cable-in interrupt. > > This seems like something that we ought to be doing via runtime PM > anyway which should be going through the suspend mode bindings, though > that would need some plumbing in. > > > case 2: > > > About buck regulator for CPU, it usually provides PWM mode, PWM/PFM Auto > > mode, PFM mode. I think it could map to FAST, NORMAL, IDLE mode > > respectively. Most of time we would use just normal mode. However, we > > would change regulator into PWM mode time to time to test buck output > > performance on the tested board. > > That's a test use that doesn't seem a good fit for upstream at all.
Hi Mark, Thanks for your response. It seems more work is required for dynamic mode switch. For MT6323 regulator patch, we would remove mode-switch related code for now to provide basic regulator support first.
