From: Viresh Kumar <viresh.kumar@linaro.org>
To: Dmitry Osipenko <digetx@gmail.com>
Cc: Viresh Kumar <vireshk@kernel.org>, Nishanth Menon <nm@ti.com>,
Stephen Boyd <sboyd@kernel.org>,
linux-pm@vger.kernel.org,
Vincent Guittot <vincent.guittot@linaro.org>,
Rafael Wysocki <rjw@rjwysocki.net>,
Sibi Sankar <sibis@codeaurora.org>,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 03/13] opp: Keep track of currently programmed OPP
Date: Mon, 25 Jan 2021 08:42:29 +0530 [thread overview]
Message-ID: <20210125031229.adthgnbzlcpt4btj@vireshk-i7> (raw)
In-Reply-To: <8af5abe4-fc3f-8ce4-ff14-542754f0275d@gmail.com>
On 22-01-21, 17:31, Dmitry Osipenko wrote:
> This may not be true for all kinds of hardware, a display controller is
> one example. If display's pixclock is raised before the memory bandwidth
> of the display's memory client, then display controller may get a memory
> underflow since it won't be able to fetch memory fast enough and it's
> not possible to pause data transmission to display panel, hence display
> panel may get out of sync and a full hardware reset will be needed in
> order to recover. At least this is the case for NVIDIA Tegra SoCs.
Hmm, but I expected that the request for more data will only come after the
opp-set-rate has finished and not in between. May be I am wrong. There is
nothing wrong in doing it the regulator way if required.
> I guess it's not a real problem for any of OPP API users right now, but
> this is something to keep in mind.
Sure, I am not against it. Just that we thought it isn't worth the code.
--
viresh
WARNING: multiple messages have this Message-ID
From: Viresh Kumar <viresh.kumar@linaro.org>
To: Dmitry Osipenko <digetx@gmail.com>
Cc: Nishanth Menon <nm@ti.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
linux-pm@vger.kernel.org, Stephen Boyd <sboyd@kernel.org>,
Viresh Kumar <vireshk@kernel.org>,
Rafael Wysocki <rjw@rjwysocki.net>,
linux-kernel@vger.kernel.org, Sibi Sankar <sibis@codeaurora.org>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 03/13] opp: Keep track of currently programmed OPP
Date: Mon, 25 Jan 2021 08:42:29 +0530 [thread overview]
Message-ID: <20210125031229.adthgnbzlcpt4btj@vireshk-i7> (raw)
In-Reply-To: <8af5abe4-fc3f-8ce4-ff14-542754f0275d@gmail.com>
On 22-01-21, 17:31, Dmitry Osipenko wrote:
> This may not be true for all kinds of hardware, a display controller is
> one example. If display's pixclock is raised before the memory bandwidth
> of the display's memory client, then display controller may get a memory
> underflow since it won't be able to fetch memory fast enough and it's
> not possible to pause data transmission to display panel, hence display
> panel may get out of sync and a full hardware reset will be needed in
> order to recover. At least this is the case for NVIDIA Tegra SoCs.
Hmm, but I expected that the request for more data will only come after the
opp-set-rate has finished and not in between. May be I am wrong. There is
nothing wrong in doing it the regulator way if required.
> I guess it's not a real problem for any of OPP API users right now, but
> this is something to keep in mind.
Sure, I am not against it. Just that we thought it isn't worth the code.
--
viresh
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-01-25 3:13 UTC|newest]
Thread overview: 73+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-21 11:17 [PATCH 00/13] opp: Implement dev_pm_opp_set_opp() Viresh Kumar
2021-01-21 11:17 ` Viresh Kumar
2021-01-21 11:17 ` Viresh Kumar
2021-01-21 11:17 ` [PATCH 01/13] opp: Rename _opp_set_rate_zero() Viresh Kumar
2021-01-21 11:17 ` Viresh Kumar
2021-01-21 11:17 ` [PATCH 02/13] opp: No need to check clk for errors Viresh Kumar
2021-01-21 11:17 ` Viresh Kumar
2021-01-21 11:17 ` [PATCH 03/13] opp: Keep track of currently programmed OPP Viresh Kumar
2021-01-21 11:17 ` Viresh Kumar
2021-01-21 21:41 ` Dmitry Osipenko
2021-01-21 21:41 ` Dmitry Osipenko
2021-01-22 4:45 ` Viresh Kumar
2021-01-22 4:45 ` Viresh Kumar
2021-01-22 14:31 ` Dmitry Osipenko
2021-01-22 14:31 ` Dmitry Osipenko
2021-01-25 3:12 ` Viresh Kumar [this message]
2021-01-25 3:12 ` Viresh Kumar
2021-01-27 16:31 ` Akhil P Oommen
2021-01-28 4:14 ` Viresh Kumar
2021-01-28 4:14 ` Viresh Kumar
2021-07-07 10:24 ` Ionela Voinescu
2021-07-07 10:24 ` Ionela Voinescu
2021-07-08 7:53 ` Viresh Kumar
2021-07-08 7:53 ` Viresh Kumar
2021-07-09 8:57 ` Ionela Voinescu
2021-07-09 8:57 ` Ionela Voinescu
2021-07-12 4:14 ` Viresh Kumar
2021-07-12 4:14 ` Viresh Kumar
2021-01-21 11:17 ` [PATCH 04/13] opp: Split _set_opp() out of dev_pm_opp_set_rate() Viresh Kumar
2021-01-21 11:17 ` Viresh Kumar
2021-01-21 11:17 ` [PATCH 05/13] opp: Allow _set_opp() to work for non-freq devices Viresh Kumar
2021-01-21 11:17 ` Viresh Kumar
2021-01-21 11:17 ` [PATCH 06/13] opp: Allow _generic_set_opp_regulator() " Viresh Kumar
2021-01-21 11:17 ` Viresh Kumar
2021-01-21 11:17 ` [PATCH 07/13] opp: Allow _generic_set_opp_clk_only() " Viresh Kumar
2021-01-21 11:17 ` Viresh Kumar
2021-01-21 20:26 ` Dmitry Osipenko
2021-01-21 20:26 ` Dmitry Osipenko
2021-01-22 4:35 ` Viresh Kumar
2021-01-22 4:35 ` Viresh Kumar
2021-01-25 21:09 ` Dmitry Osipenko
2021-01-25 21:09 ` Dmitry Osipenko
2021-01-27 6:58 ` Viresh Kumar
2021-01-27 6:58 ` Viresh Kumar
2021-01-21 11:17 ` [PATCH 08/13] opp: Update parameters of _set_opp_custom() Viresh Kumar
2021-01-21 11:17 ` Viresh Kumar
2021-01-21 11:17 ` [PATCH 09/13] opp: Implement dev_pm_opp_set_opp() Viresh Kumar
2021-01-21 11:17 ` Viresh Kumar
2021-01-21 11:17 ` [PATCH 10/13] cpufreq: qcom: Migrate to dev_pm_opp_set_opp() Viresh Kumar
2021-01-21 11:17 ` Viresh Kumar
2021-01-21 11:17 ` [PATCH 11/13] devfreq: tegra30: " Viresh Kumar
2021-01-21 11:17 ` Viresh Kumar
2021-01-21 21:36 ` Dmitry Osipenko
2021-01-21 21:36 ` Dmitry Osipenko
2021-01-22 6:26 ` Viresh Kumar
2021-01-22 6:26 ` Viresh Kumar
2021-01-22 15:28 ` Dmitry Osipenko
2021-01-22 15:28 ` Dmitry Osipenko
2021-01-25 3:14 ` Viresh Kumar
2021-01-25 3:14 ` Viresh Kumar
2021-01-25 16:00 ` Dmitry Osipenko
2021-01-25 16:00 ` Dmitry Osipenko
2021-01-27 9:10 ` [PATCH V2 " Viresh Kumar
2021-01-27 10:02 ` Viresh Kumar
2021-01-27 15:58 ` Dmitry Osipenko
2021-01-28 7:01 ` Viresh Kumar
2021-02-01 0:21 ` Chanwoo Choi
2021-02-01 19:57 ` Dmitry Osipenko
2021-01-21 11:17 ` [PATCH 12/13] drm: msm: " Viresh Kumar
2021-01-21 11:17 ` Viresh Kumar
2021-01-21 11:17 ` Viresh Kumar
2021-01-21 11:17 ` [PATCH 13/13] opp: Remove dev_pm_opp_set_bw() Viresh Kumar
2021-01-21 11:17 ` Viresh Kumar
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=20210125031229.adthgnbzlcpt4btj@vireshk-i7 \
--to=viresh.kumar@linaro.org \
--cc=digetx@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=nm@ti.com \
--cc=rjw@rjwysocki.net \
--cc=sboyd@kernel.org \
--cc=sibis@codeaurora.org \
--cc=vincent.guittot@linaro.org \
--cc=vireshk@kernel.org \
--subject='Re: [PATCH 03/13] opp: Keep track of currently programmed OPP' \
/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
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.