Hi Linus,
On 22/02/18 15:30, Linus Walleij wrote:
> On Mon, Feb 19, 2018 at 8:23 PM, Marc Zyngier wrote:
>>> Am Montag, 19. Februar 2018, 19:03:27 CET schrieb Florian Fainelli:
>
Can you indicate which DTS file is used for your Chromebook model? Sorry
about the
Hi Linus,
On 22/02/18 15:30, Linus Walleij wrote:
> On Mon, Feb 19, 2018 at 8:23 PM, Marc Zyngier wrote:
>>> Am Montag, 19. Februar 2018, 19:03:27 CET schrieb Florian Fainelli:
>
Can you indicate which DTS file is used for your Chromebook model? Sorry
about the breakage.
>>>
>>> that
On Mon, Feb 19, 2018 at 8:23 PM, Marc Zyngier wrote:
>> Am Montag, 19. Februar 2018, 19:03:27 CET schrieb Florian Fainelli:
>> > Can you indicate which DTS file is used for your Chromebook model? Sorry
>> > about the breakage.
>>
>> that should be
>>
On Mon, Feb 19, 2018 at 8:23 PM, Marc Zyngier wrote:
>> Am Montag, 19. Februar 2018, 19:03:27 CET schrieb Florian Fainelli:
>> > Can you indicate which DTS file is used for your Chromebook model? Sorry
>> > about the breakage.
>>
>> that should be
>>
On Mon, 19 Feb 2018 18:57:23 +,
Heiko Stuebner wrote:
>
> Am Montag, 19. Februar 2018, 19:03:27 CET schrieb Florian Fainelli:
> > On February 19, 2018 9:25:26 AM PST, Marc Zyngier
> > wrote:
> > >Hi all,
> > >
> > >On 2017-03-01 18:32, Florian Fainelli wrote:
> > >> In
On Mon, 19 Feb 2018 18:57:23 +,
Heiko Stuebner wrote:
>
> Am Montag, 19. Februar 2018, 19:03:27 CET schrieb Florian Fainelli:
> > On February 19, 2018 9:25:26 AM PST, Marc Zyngier
> > wrote:
> > >Hi all,
> > >
> > >On 2017-03-01 18:32, Florian Fainelli wrote:
> > >> In case a platform only
On Mon, 19 Feb 2018 18:03:27 +,
Florian Fainelli wrote:
>
> On February 19, 2018 9:25:26 AM PST, Marc Zyngier
> wrote:
> >Hi all,
> >
> >On 2017-03-01 18:32, Florian Fainelli wrote:
> >> In case a platform only defaults a "default" set of pins, but not a
> >> "sleep"
On Mon, 19 Feb 2018 18:03:27 +,
Florian Fainelli wrote:
>
> On February 19, 2018 9:25:26 AM PST, Marc Zyngier
> wrote:
> >Hi all,
> >
> >On 2017-03-01 18:32, Florian Fainelli wrote:
> >> In case a platform only defaults a "default" set of pins, but not a
> >> "sleep" set of pins, and this
Am Montag, 19. Februar 2018, 19:03:27 CET schrieb Florian Fainelli:
> On February 19, 2018 9:25:26 AM PST, Marc Zyngier
> wrote:
> >Hi all,
> >
> >On 2017-03-01 18:32, Florian Fainelli wrote:
> >> In case a platform only defaults a "default" set of pins, but not a
> >>
Am Montag, 19. Februar 2018, 19:03:27 CET schrieb Florian Fainelli:
> On February 19, 2018 9:25:26 AM PST, Marc Zyngier
> wrote:
> >Hi all,
> >
> >On 2017-03-01 18:32, Florian Fainelli wrote:
> >> In case a platform only defaults a "default" set of pins, but not a
> >> "sleep" set of pins, and
On February 19, 2018 9:25:26 AM PST, Marc Zyngier wrote:
>Hi all,
>
>On 2017-03-01 18:32, Florian Fainelli wrote:
>> In case a platform only defaults a "default" set of pins, but not a
>> "sleep" set of pins, and this particular platform suspends and
>> resumes
>> in a way
On February 19, 2018 9:25:26 AM PST, Marc Zyngier wrote:
>Hi all,
>
>On 2017-03-01 18:32, Florian Fainelli wrote:
>> In case a platform only defaults a "default" set of pins, but not a
>> "sleep" set of pins, and this particular platform suspends and
>> resumes
>> in a way that the pin states
Hi all,
On 2017-03-01 18:32, Florian Fainelli wrote:
In case a platform only defaults a "default" set of pins, but not a
"sleep" set of pins, and this particular platform suspends and
resumes
in a way that the pin states are not preserved by the hardware, when
we
resume, we would call
Hi all,
On 2017-03-01 18:32, Florian Fainelli wrote:
In case a platform only defaults a "default" set of pins, but not a
"sleep" set of pins, and this particular platform suspends and
resumes
in a way that the pin states are not preserved by the hardware, when
we
resume, we would call
On Thu, Jun 29, 2017 at 9:38 PM, Florian Fainelli wrote:
> On 06/29/2017 02:17 AM, Linus Walleij wrote:
>> So if it is not desireable to have every driver know which exact
>> state it came from like S3 this or S2 that and on this laptop
>> we have S2' which is slightly
On Thu, Jun 29, 2017 at 9:38 PM, Florian Fainelli wrote:
> On 06/29/2017 02:17 AM, Linus Walleij wrote:
>> So if it is not desireable to have every driver know which exact
>> state it came from like S3 this or S2 that and on this laptop
>> we have S2' which is slightly different and such mess
On 06/29/2017 02:17 AM, Linus Walleij wrote:
> Sorry for slowness...
>
> On Wed, Jun 21, 2017 at 11:23 PM, Florian Fainelli
> wrote:
>> On 03/16/2017 07:08 AM, Linus Walleij wrote:
>
>>> I guess then it is better to assume we will loose the state, or
>>> push for more
On 06/29/2017 02:17 AM, Linus Walleij wrote:
> Sorry for slowness...
>
> On Wed, Jun 21, 2017 at 11:23 PM, Florian Fainelli
> wrote:
>> On 03/16/2017 07:08 AM, Linus Walleij wrote:
>
>>> I guess then it is better to assume we will loose the state, or
>>> push for more granular handling of S2/3
Sorry for slowness...
On Wed, Jun 21, 2017 at 11:23 PM, Florian Fainelli wrote:
> On 03/16/2017 07:08 AM, Linus Walleij wrote:
>> I guess then it is better to assume we will loose the state, or
>> push for more granular handling of S2/3 etc states in the
>> PM core (I
Sorry for slowness...
On Wed, Jun 21, 2017 at 11:23 PM, Florian Fainelli wrote:
> On 03/16/2017 07:08 AM, Linus Walleij wrote:
>> I guess then it is better to assume we will loose the state, or
>> push for more granular handling of S2/3 etc states in the
>> PM core (I guess these states comes
(sorry for the lag)
On 03/16/2017 07:08 AM, Linus Walleij wrote:
> On Wed, Mar 15, 2017 at 3:18 AM, Florian Fainelli
> wrote:
>> On 03/14/2017 03:16 AM, Linus Walleij wrote:
>
>>> The most obvious would be to use the API as many already do:
>>> define "sleep" states in
(sorry for the lag)
On 03/16/2017 07:08 AM, Linus Walleij wrote:
> On Wed, Mar 15, 2017 at 3:18 AM, Florian Fainelli
> wrote:
>> On 03/14/2017 03:16 AM, Linus Walleij wrote:
>
>>> The most obvious would be to use the API as many already do:
>>> define "sleep" states in the core, and switch to
On Wed, Mar 15, 2017 at 3:18 AM, Florian Fainelli wrote:
> On 03/14/2017 03:16 AM, Linus Walleij wrote:
>> The most obvious would be to use the API as many already do:
>> define "sleep" states in the core, and switch to these before
>> going to sleep. If CONFIG_PM is
On Wed, Mar 15, 2017 at 3:18 AM, Florian Fainelli wrote:
> On 03/14/2017 03:16 AM, Linus Walleij wrote:
>> The most obvious would be to use the API as many already do:
>> define "sleep" states in the core, and switch to these before
>> going to sleep. If CONFIG_PM is available simply by calling
On 03/14/2017 03:16 AM, Linus Walleij wrote:
> On Thu, Mar 2, 2017 at 11:19 PM, Florian Fainelli
> wrote:
>
>> So actually, I have been thinking about this some more, and while this
>> definitively fixes my original problem with pinctrl-single, I just had
>> to make
On 03/14/2017 03:16 AM, Linus Walleij wrote:
> On Thu, Mar 2, 2017 at 11:19 PM, Florian Fainelli
> wrote:
>
>> So actually, I have been thinking about this some more, and while this
>> definitively fixes my original problem with pinctrl-single, I just had
>> to make another driver
On Thu, Mar 2, 2017 at 11:19 PM, Florian Fainelli wrote:
> So actually, I have been thinking about this some more, and while this
> definitively fixes my original problem with pinctrl-single, I just had
> to make another driver (sdhci-brcmstb.c) pinctrl aware. And then
On Thu, Mar 2, 2017 at 11:19 PM, Florian Fainelli wrote:
> So actually, I have been thinking about this some more, and while this
> definitively fixes my original problem with pinctrl-single, I just had
> to make another driver (sdhci-brcmstb.c) pinctrl aware. And then again,
> same thing, it
On 03/02/2017 12:54 AM, Andy Shevchenko wrote:
> On Wed, Mar 1, 2017 at 8:32 PM, Florian Fainelli wrote:
>> In case a platform only defaults a "default" set of pins, but not a
>> "sleep" set of pins, and this particular platform suspends and resumes
>> in a way that the pin
On 03/02/2017 12:54 AM, Andy Shevchenko wrote:
> On Wed, Mar 1, 2017 at 8:32 PM, Florian Fainelli wrote:
>> In case a platform only defaults a "default" set of pins, but not a
>> "sleep" set of pins, and this particular platform suspends and resumes
>> in a way that the pin states are not
On Wed, Mar 1, 2017 at 8:32 PM, Florian Fainelli wrote:
> In case a platform only defaults a "default" set of pins, but not a
> "sleep" set of pins, and this particular platform suspends and resumes
> in a way that the pin states are not preserved by the hardware, when we
>
On Wed, Mar 1, 2017 at 8:32 PM, Florian Fainelli wrote:
> In case a platform only defaults a "default" set of pins, but not a
> "sleep" set of pins, and this particular platform suspends and resumes
> in a way that the pin states are not preserved by the hardware, when we
> resume, we would call
32 matches
Mail list logo