All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
To: MyungJoo Ham <myungjoo.ham@gmail.com>,
	Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
Cc: Markus Reichl <m.reichl@fivetechno.de>,
	"moderated list:ARM/S5P EXYNOS AR..."
	<linux-samsung-soc@vger.kernel.org>,
	Chanwoo Choi <cw00.choi@samsung.com>
Subject: Re: PM / devfreq: exynos-bus: need for suspend OPP?
Date: Wed, 23 Nov 2016 14:55:03 +0100	[thread overview]
Message-ID: <58359FB7.4010406@math.uni-bielefeld.de> (raw)
In-Reply-To: <CAJ0PZbSMzpr76X8swG7YDFagphjBrE+Fb41pP3cu6=bucFeGSQ@mail.gmail.com>

Hello again,

I've just send a draft for the patch(set) I have in mind.

It's still in bad shape and I would appreciate some comments from the
guys more versed with the DevFreq subsystem than me. In particular I'm
not sure how exactly the various components (exynos-bus, devfreq,
devfreq-event, governor) work together.

- Tobias

MyungJoo Ham wrote:
> On Tue, Nov 22, 2016 at 7:15 AM, Tobias Jakobi
> <tjakobi@math.uni-bielefeld.de> wrote:
>> OK, I don't think this is as easy implementable as MyungJoo implied.
>>
>> - exynos_bus_suspend() and exynos_bus_resume() are not called during
>> shutdown/reboot.
> 
> You don't need them at shutdown/reboot. probe() is going to be called
> afterwards anyway.
> 
>>
>> - devfreq_suspend_device() and devfreq_resume_device() have to be called
>> from driver code.
> 
> Yes. That's the limitation.
> 
> The easiest way is to fix the freq/volt at device driver.
> 
> Unless devfreq manages struct device directly at subsystem, it won't
> be easy to manage device's suspend/resume directly.
> 
> 
> MyungJoo
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

  reply	other threads:[~2016-11-23 13:55 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-21 13:33 PM / devfreq: exynos-bus: need for suspend OPP? Tobias Jakobi
2016-11-21 14:48 ` Markus Reichl
2016-11-21 15:06   ` MyungJoo Ham
2016-11-21 15:23     ` Tobias Jakobi
2016-11-21 16:21       ` MyungJoo Ham
2016-11-21 22:15         ` Tobias Jakobi
2016-11-22 12:39           ` MyungJoo Ham
2016-11-23 13:55             ` Tobias Jakobi [this message]
2016-11-21 15:16   ` Tobias Jakobi
2016-11-21 18:10     ` Markus Reichl

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=58359FB7.4010406@math.uni-bielefeld.de \
    --to=tjakobi@math.uni-bielefeld.de \
    --cc=cw00.choi@samsung.com \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=m.reichl@fivetechno.de \
    --cc=myungjoo.ham@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.