Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1479755

Re: [PATCH v6 0/8] power: add power sequence library

From Ulf Hansson <ulf.hansson@linaro.org>
Newsgroups linux.kernel
Subject Re: [PATCH v6 0/8] power: add power sequence library
Date 2016-09-09 10:50 +0200
Message-ID <sfpFv-zV-9@gated-at.bofh.it> (permalink)
References (4 earlier) <sc8Uy-8n3-25@gated-at.bofh.it> <scatj-KH-1@gated-at.bofh.it> <sch1M-4Rl-21@gated-at.bofh.it> <scLsR-17o-3@gated-at.bofh.it> <selDX-HZ-13@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


[...]

>>>>
>>>> We had an agreement that keep mmc's pwrseq framework unchanging.
>>>> Unless Ulf and rob both agree to change.
>>>
>>> Why 2 separate approach for same problem ?
>>> And I see this as possible duplication of code/functionality :)
>>
>> How the new kernel compatibles old dts? If we do not need to
>> consider this problem, the mmc can try to use power sequence library
>> too in future.
>
>
> I think we should attempt to get both MMC and USB power seq
> come on one agreement, so that it can be reused.

That would be nice. Although, to do that you would have to allow some
DT bindings to be deprecated in the new generic power seq bindings, as
otherwise you would break existing DTBs.

I guess that is what Rob was objecting to!?

>
> MMC Power Seq :
>  It is based on platform_device/platform_driver approach,

We recently converted MMC to this. It's has a clear benefit as you can
rely on the behaviour from the driver core and PM core. So, it simply
avoids duplication of code.

>
> USB Power seq :
>  We are trying to propose library approach, with compatible string match.
>
> We should try to have one approach.
>>
>>
>>>>>   - Lets also add suspend/resume callback to struct pwrseq
>>>>>
>>>> Why suspend/resume can't do at related driver's suspend/resume API?
>>>
>>> Nope...
>>> The pwrseq library would have taken ownership of resources, so
>>> related driver cannot suspend the device. Again it is architecture
>>> specific, but we should have provision to handle this.
>>>
>>> The system I am dealing with today, does need suspend/resume
>>> callback. To be precise, suspend is close to off state for some devices
>>> or
>>> they could enter standby or different low power state, but to do that,
>>> we need same resource as used for ON/OFF functionality.
>>>
>> Ok, I will have API for suspend/resume. You can implement it at your own
>> library or generic one.

As stated, using a platform device + driver would simplify this, as
you wouldn't need an API but only a driver. I guess.

Kind regards
Uffe

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Re: [PATCH v6 0/8] power: add power sequence library Peter Chen <hzpeterchen@gmail.com> - 2016-08-29 05:20 +0200
  Re: [PATCH v6 0/8] power: add power sequence library Vaibhav Hiremath <vaibhav.hiremath@linaro.org> - 2016-08-31 10:20 +0200
    Re: [PATCH v6 0/8] power: add power sequence library Peter Chen <hzpeterchen@gmail.com> - 2016-08-31 12:00 +0200
      Re: [PATCH v6 0/8] power: add power sequence library Vaibhav Hiremath <vaibhav.hiremath@linaro.org> - 2016-08-31 19:00 +0200
        Re: [PATCH v6 0/8] power: add power sequence library Peter Chen <hzpeterchen@gmail.com> - 2016-09-02 03:30 +0200
          Re: [PATCH v6 0/8] power: add power sequence library Vaibhav Hiremath <vaibhav.hiremath@linaro.org> - 2016-09-06 12:20 +0200
            Re: [PATCH v6 0/8] power: add power sequence library Ulf Hansson <ulf.hansson@linaro.org> - 2016-09-09 10:50 +0200
              Re: [PATCH v6 0/8] power: add power sequence library Peter Chen <hzpeterchen@gmail.com> - 2016-09-19 09:50 +0200
                Re: [PATCH v6 0/8] power: add power sequence library Vaibhav Hiremath <vaibhav.hiremath@linaro.org> - 2016-09-19 10:20 +0200
              Re: [PATCH v6 0/8] power: add power sequence library Vaibhav Hiremath <vaibhav.hiremath@linaro.org> - 2016-09-19 09:50 +0200

csiph-web