On Thu, Aug 28, 2014 at 11:59:16AM +0200, Javier Martinez Canillas wrote:
> > On 28/08/2014, at 10:28, Mark Brown wrote:
> >> Yes, AFAIK the bootloader (none of them because Chromebooks use two
> >> chained U-boots) change the regulators default opmode so once is set
> >> to OFF on .disable, that
Hello Mark,
> On 28/08/2014, at 10:28, Mark Brown wrote:
>> Yes, AFAIK the bootloader (none of them because Chromebooks use two
>> chained U-boots) change the regulators default opmode so once is set
>> to OFF on .disable, that value is preserved on warm reboot. This made
>> sense with the Chrome
On Thu, Aug 28, 2014 at 12:44:18AM +0200, Javier Martinez Canillas wrote:
> On Wed, Aug 27, 2014 at 11:03 PM, Tomasz Figa wrote:
> This is the case for Chromebooks as well but the solution implemented
> in the downstream Chrome OS 3.8 kernel is what Tomasz suggested
*sigh* This is not what you
Hello Tomasz and Mark,
Sorry for not answering before but I'm on vacations until Sep, 5 and I
have limited access to my email.
On Wed, Aug 27, 2014 at 11:03 PM, Tomasz Figa wrote:
From what I know based on my experience with Samsung boards we used, the
opmodes of regulators are preconf
On 27.08.2014 22:41, Tomasz Figa wrote:
> On 27.08.2014 22:25, Mark Brown wrote:
>> On Wed, Aug 27, 2014 at 09:58:55PM +0200, Tomasz Figa wrote:
>>> On 27.08.2014 21:44, Mark Brown wrote:
>>
The point is that if anything was setting the mode to something other
than normal it was almost ce
On Wed, Aug 27, 2014 at 10:41:42PM +0200, Tomasz Figa wrote:
> On 27.08.2014 22:25, Mark Brown wrote:
> > Well, presumably the bootloader is going to run again even for a warm
> > reboot?
> This is strange, but apparently it's not the case for the hardware which
> this patch is supposed to fix or
On 27.08.2014 22:25, Mark Brown wrote:
> On Wed, Aug 27, 2014 at 09:58:55PM +0200, Tomasz Figa wrote:
>> On 27.08.2014 21:44, Mark Brown wrote:
>
>>> The point is that if anything was setting the mode to something other
>>> than normal it was almost certainly a previously running copy of Linux
>>>
On Wed, Aug 27, 2014 at 09:58:55PM +0200, Tomasz Figa wrote:
> On 27.08.2014 21:44, Mark Brown wrote:
> > The point is that if anything was setting the mode to something other
> > than normal it was almost certainly a previously running copy of Linux
> > and one would expect that if the mode does
On 27.08.2014 21:44, Mark Brown wrote:
> On Wed, Aug 27, 2014 at 09:21:02PM +0200, Tomasz Figa wrote:
>> On 27.08.2014 21:15, Mark Brown wrote:
>
>>> This is in the scenario where the previously running Linux changed the
>>> mode to something other than normal and where the freshly booted Linux
>>
On Wed, Aug 27, 2014 at 09:21:02PM +0200, Tomasz Figa wrote:
> On 27.08.2014 21:15, Mark Brown wrote:
> > This is in the scenario where the previously running Linux changed the
> > mode to something other than normal and where the freshly booted Linux
> > can't figure out how to do that when it ne
On 27.08.2014 21:15, Mark Brown wrote:
> On Wed, Aug 27, 2014 at 08:52:49PM +0200, Tomasz Figa wrote:
>> On 27.08.2014 20:47, Mark Brown wrote:
>
>>> I'm not convinced that's worth it - chances are that if anything changed
>>> the mode it was a previously running Linux which will most likely be
>>
On Wed, Aug 27, 2014 at 08:52:49PM +0200, Tomasz Figa wrote:
> On 27.08.2014 20:47, Mark Brown wrote:
> > I'm not convinced that's worth it - chances are that if anything changed
> > the mode it was a previously running Linux which will most likely be
> > doing the same things when it starts runni
On 27.08.2014 20:47, Mark Brown wrote:
> On Wed, Aug 27, 2014 at 08:39:39PM +0200, Tomasz Figa wrote:
>> On 27.08.2014 20:37, Mark Brown wrote:
>
>>> That's essentially the situation the patch is trying to fix - if we boot
>>> and the regulator is off there's no way to figure out what the operatin
On Wed, Aug 27, 2014 at 08:39:39PM +0200, Tomasz Figa wrote:
> On 27.08.2014 20:37, Mark Brown wrote:
> > That's essentially the situation the patch is trying to fix - if we boot
> > and the regulator is off there's no way to figure out what the operating
> > mode would have been so we have to pic
On 27.08.2014 20:37, Mark Brown wrote:
> On Wed, Aug 27, 2014 at 08:32:38PM +0200, Tomasz Figa wrote:
>> On 26.08.2014 13:37, Javier Martinez Canillas wrote:
>
>>> + /*
>>> +* If the regulator is disabled and the system warm rebooted,
>>> +* the hardware reports O
On Wed, Aug 27, 2014 at 08:32:38PM +0200, Tomasz Figa wrote:
> On 26.08.2014 13:37, Javier Martinez Canillas wrote:
> > + /*
> > +* If the regulator is disabled and the system warm rebooted,
> > +* the hardware reports OFF as the regulator operating mode.
> > +
On 26.08.2014 13:37, Javier Martinez Canillas wrote:
> + /*
> + * If the regulator is disabled and the system warm rebooted,
> + * the hardware reports OFF as the regulator operating mode.
> + * Default to operating mode NORMAL in that case.
> +
On Tue, Aug 26, 2014 at 01:37:41PM +0200, Javier Martinez Canillas wrote:
> The max77802 driver reads the default operating mode (opmode)
> set for regulators when enabled from the hardware registers.
Applied, thanks.
signature.asc
Description: Digital signature
Tested-by: Yuvaraj Kumar CD
On Tue, Aug 26, 2014 at 5:07 PM, Javier Martinez Canillas
wrote:
> The max77802 driver reads the default operating mode (opmode)
> set for regulators when enabled from the hardware registers.
>
> But if a regulator is disabled and the system warm restarted,
> the hard
Javier,
On Tue, Aug 26, 2014 at 4:37 AM, Javier Martinez Canillas
wrote:
> The max77802 driver reads the default operating mode (opmode)
> set for regulators when enabled from the hardware registers.
>
> But if a regulator is disabled and the system warm restarted,
> the hardware reports OFF as t
The max77802 driver reads the default operating mode (opmode)
set for regulators when enabled from the hardware registers.
But if a regulator is disabled and the system warm restarted,
the hardware reports OFF as the opmode so the regulator is
not enabled. Default to operating mode NORMAL if OFF i
21 matches
Mail list logo
