On Mon, Jul 04, 2016 at 11:13:44AM +0200, Mark Brown wrote:
> On Mon, Jul 04, 2016 at 11:05:04AM +0200, Boris Brezillon wrote:
>
> > I understand, but can we still expect to have it in 4.8 (I mean,
> > assuming Thierry is okay taking the first 2 patching for 4.8 too)?
>
> Possibly - we are gettin
On Wed, Jul 06, 2016 at 11:30:59AM -0700, Doug Anderson wrote:
> Note: which boards are you thinking would test this? My grep showed
> zero boards using regulator-ramp-delay with PWM regulator. While this
> is an important fix for anyone using the ramp delay, I'm not convinced
> that anyone in m
On Wed, Jul 06, 2016 at 11:31:45AM -0700, Doug Anderson wrote:
> I'll certainly let Mark comment here, but:
> * For enabling the PWM, I think you want want "regulator-enable-ramp-delay".
In the absence of that we should just be treating it as a voltage change
from zero. Some regulators do have
On Wed, Jul 06, 2016 at 02:27:19PM +0200, Boris Brezillon wrote:
> I realize I may have introduced another bug when adding the
> ->enable()/disable() methods: we are only waiting for the ramp up delay
> when changing the voltage, but it should probably be applied when
> enabling the PWM, and condi
Boris,
On Wed, Jul 6, 2016 at 5:27 AM, Boris Brezillon
wrote:
> On Mon, 27 Jun 2016 21:53:11 -0700
> Douglas Anderson wrote:
>
>> The original commit adding support for continuous voltage mode didn't
>> handle the regulator ramp delay properly. It treated the delay as a
>> fixed delay in uS des
Mark,
On Sat, Jul 2, 2016 at 12:59 AM, Mark Brown wrote:
> On Fri, Jul 01, 2016 at 01:17:48PM -0700, Doug Anderson wrote:
>
>> Anyway, let me know if you want me to post the untested, rebased
>> patch... Personally I'd prefer to wait for Boris's patches and the
>> land the tested version.
>
> We
On Mon, 27 Jun 2016 21:53:11 -0700
Douglas Anderson wrote:
> The original commit adding support for continuous voltage mode didn't
> handle the regulator ramp delay properly. It treated the delay as a
> fixed delay in uS despite the property being defined as uV / uS. Let's
> adjust it. Luckily
On Mon, Jul 04, 2016 at 11:05:04AM +0200, Boris Brezillon wrote:
> I understand, but can we still expect to have it in 4.8 (I mean,
> assuming Thierry is okay taking the first 2 patching for 4.8 too)?
Possibly - we are getting very close to the merge window now, I don't
know what Thierry's polici
Hi Mark,
On Mon, 4 Jul 2016 10:53:36 +0200
Mark Brown wrote:
> On Sat, Jul 02, 2016 at 05:47:52PM +0200, Boris Brezillon wrote:
>
> > I'm waiting for reviews or acks. AFAIR, I addressed all the comments
> > Thierry made on my v2, so I guess we're good on the PWM side, but that
> > would be good
On Sat, Jul 02, 2016 at 05:47:52PM +0200, Boris Brezillon wrote:
> I'm waiting for reviews or acks. AFAIR, I addressed all the comments
> Thierry made on my v2, so I guess we're good on the PWM side, but that
> would be good to have a review from Mark now that we agreed on the PWM
> APIs.
I've al
+Thierry
Hi Doug,
On Fri, 1 Jul 2016 13:17:48 -0700
Doug Anderson wrote:
> Mark,
>
> On Fri, Jul 1, 2016 at 1:06 AM, Mark Brown wrote:
> > On Mon, Jun 27, 2016 at 09:53:11PM -0700, Douglas Anderson wrote:
> >
> >> Note that this patch is atop Boris's recent PWM regulator fixes. If
> >> des
On Fri, Jul 01, 2016 at 01:17:48PM -0700, Doug Anderson wrote:
> Anyway, let me know if you want me to post the untested, rebased
> patch... Personally I'd prefer to wait for Boris's patches and the
> land the tested version.
We've got some boards in kernelci.org using PWM regulators I think, or
Mark,
On Fri, Jul 1, 2016 at 1:06 AM, Mark Brown wrote:
> On Mon, Jun 27, 2016 at 09:53:11PM -0700, Douglas Anderson wrote:
>
>> Note that this patch is atop Boris's recent PWM regulator fixes. If
>> desired it wouldn't be too hard to write it atop the old code, though
>> quite honestly anyone u
On Mon, Jun 27, 2016 at 09:53:11PM -0700, Douglas Anderson wrote:
> Note that this patch is atop Boris's recent PWM regulator fixes. If
> desired it wouldn't be too hard to write it atop the old code, though
> quite honestly anyone using a PWM regulator should probably be using his
> new code.
G
On Tue, Jun 28, 2016 at 12:31:19PM -0700, Doug Anderson wrote:
> In all seriousness, I think the design for usleep_range() is to try to
> batch up wakeups to allow longer periods of sleeping and to optimize
> power. This you want to sleep as long as is allowable and then if you
> happen to wakeup
Hi,
On Tue, Jun 28, 2016 at 11:56 AM, Mark Brown wrote:
> On Mon, Jun 27, 2016 at 09:53:11PM -0700, Douglas Anderson wrote:
>
>> Note that this patch is atop Boris's recent PWM regulator fixes. If
>> desired it wouldn't be too hard to write it atop the old code, though
>> quite honestly anyone u
Mark,
On Tue, Jun 28, 2016 at 11:52 AM, Mark Brown wrote:
> On Mon, Jun 27, 2016 at 09:53:11PM -0700, Douglas Anderson wrote:
>
>> Note also that the upper bound of usleep_range probably shouldn't be a
>> full 1 ms longer than the lower bound since I've seen plenty of hardware
>> with a ramp rate
On Mon, Jun 27, 2016 at 09:53:11PM -0700, Douglas Anderson wrote:
> Note that this patch is atop Boris's recent PWM regulator fixes. If
> desired it wouldn't be too hard to write it atop the old code, though
> quite honestly anyone using a PWM regulator should probably be using his
> new code.
O
On Mon, Jun 27, 2016 at 09:53:11PM -0700, Douglas Anderson wrote:
> Note also that the upper bound of usleep_range probably shouldn't be a
> full 1 ms longer than the lower bound since I've seen plenty of hardware
> with a ramp rate of ~5000 uS / uV and for small jumps the total delays
> are in th
On Mon, Jun 27, 2016 at 9:53 PM, Douglas Anderson wrote:
> The original commit adding support for continuous voltage mode didn't
> handle the regulator ramp delay properly. It treated the delay as a
> fixed delay in uS despite the property being defined as uV / uS. Let's
> adjust it. Luckily th
On 2016年06月28日 12:53, Douglas Anderson wrote:
The original commit adding support for continuous voltage mode didn't
handle the regulator ramp delay properly. It treated the delay as a
fixed delay in uS despite the property being defined as uV / uS. Let's
adjust it. Luckily there appear to be
The original commit adding support for continuous voltage mode didn't
handle the regulator ramp delay properly. It treated the delay as a
fixed delay in uS despite the property being defined as uV / uS. Let's
adjust it. Luckily there appear to be no users of this ramp delay for
PWM regulators (a
22 matches
Mail list logo
