Chris, On Tue, Sep 23, 2014 at 6:47 PM, Chris Zhong <zyw at rock-chips.com> wrote: > > On 09/24/2014 07:43 AM, Doug Anderson wrote: >> >> Chris, >> >> On Tue, Sep 23, 2014 at 8:53 AM, Chris Zhong <zyw at rock-chips.com> wrote: >>> >>> Get voltage & duty table from device tree might be better, other >>> platforms can also use this >>> driver without any modify. >>> >>> Signed-off-by: Chris Zhong <zyw at rock-chips.com> >>> Reviewed-by: Doug Anderson <dianders at chromium.org> >> >> I finally managed to get everything setup and I've now tested this >> myself on an rk3288-based board. >> >> Tested-by: Doug Anderson <dianders at chromium.org> >> >> I'd imagine the next step is for Lee to comment on the patch and when >> he's happy with it Mark Brown will land it? >> >> >> One thing that's still a bit odd (though no different than the >> behavior of the driver from before you touched it, so it shouldn't >> block landing IMHO) is that at boot time this regulator will report >> that it's at the highest voltage but the voltage won't actually change >> until the first client sets the voltage. > > Yes, I knew this problem, since the default of duty cycle is 0, not a true > value. > If we can get duty from pwm, this regulator will report a correct voltage. I don't think it's possible in all cases to figure out what the voltage was before this regulator was probed. * pin might have been input w/ pullup, pulldown, or no pull * pin might have been driven high or driven low In that case trying to read the duty from the pwm wouldn't make sense. ...but I guess you could add a property to the PWM driver to say that it stays enabled at boot if the FW left it enabled (and keep the same duty cycle / clocks?). That would at least solve the problem where the firmware configured the PWM and left it in a specific state even if it doesn't solve the above problem... -Doug
