On 13-06-19, 15:24, Viresh Kumar wrote:
> I am confused as hell on what we should be doing and what we are doing
> right now. And if we should do better.
>
> Let me explain with an example.
>
> - The clock provider supports following frequencies: 500, 600, 700,
> 800, 900,
On 20-03-19, 15:19, Rajendra Nayak wrote:
> For devices with performance state, we use dev_pm_opp_set_rate()
> to set the appropriate clk rate and the performance state.
> We do need a way to *remove* the performance state vote when
> we idle the device and turn the clocks off. Use dev_pm_opp_set_r
On 17-06-19, 09:37, Rajendra Nayak wrote:
>
>
> On 6/17/2019 9:20 AM, Viresh Kumar wrote:
> > On 14-06-19, 10:57, Viresh Kumar wrote:
> > > Hmm, so this patch won't break anything and I am inclined to apply it
> > > again :)
> > >
> > >
On 20-03-19, 15:19, Rajendra Nayak wrote:
> This is a v2 of the RFC posted earlier by Stephen Boyd [1]
>
> As part of v2 I still follow the same approach of dev_pm_opp_set_rate()
> API using clk framework to round the frequency passed and making it
> accept 0 as a valid frequency indicating the fr
On 14-06-19, 10:57, Viresh Kumar wrote:
> Hmm, so this patch won't break anything and I am inclined to apply it again :)
>
> Does anyone see any other issues with it, which I might be missing ?
I have updated the commit log a bit more to clarify on things, please let me
know if
CPUFREQ_CREATE_POLICY and
CPUFREQ_REMOVE_POLICY events to it for the acpi stuff specifically. So
the policy notifiers aren't completely removed.
Boot tested on my x86 PC and ARM hikey board. Nothing looked broken :)
This has already gone through build bot for a few days now.
--
viresh
Viresh Kumar (10):
cp
egistering the
notifier.
Remove it.
Signed-off-by: Viresh Kumar
---
drivers/video/fbdev/sa1100fb.c | 27 ---
drivers/video/fbdev/sa1100fb.h | 1 -
2 files changed, 28 deletions(-)
diff --git a/drivers/video/fbdev/sa1100fb.c b/drivers/video/fbdev/sa1100fb.c
index f7
On 16-07-19, 12:06, Rafael J. Wysocki wrote:
> On Tue, Jul 16, 2019 at 11:49 AM Viresh Kumar wrote:
> >
> > Hello,
> >
> > Now that cpufreq core supports taking QoS requests for min/max cpu
> > frequencies, lets migrate rest of the users to using them in
On 16-07-19, 14:25, Bartlomiej Zolnierkiewicz wrote:
>
> Hi Viresh,
>
> Please always Cc: me on fbdev patches.
That happened because I used patter-depth=1 in my script for finding
maintainers from get_maintainers. Sorry about that. I have incremented
that by one now.
--
viresh
tering the
notifier.
Remove it.
Signed-off-by: Viresh Kumar
---
drivers/video/fbdev/pxafb.c | 21 -
drivers/video/fbdev/pxafb.h | 1 -
2 files changed, 22 deletions(-)
diff --git a/drivers/video/fbdev/pxafb.c b/drivers/video/fbdev/pxafb.c
index 4282cb117b92..f70c9f79622e 10
1->V2:
- Added Acked-by tags
- Reordered to keep cleanups at the bottom
- Rebased over 5.3-rc1
--
viresh
Viresh Kumar (10):
cpufreq: Add policy create/remove notifiers
thermal: cpu_cooling: Switch to QoS requests instead of cpufreq
notifier
powerpc: macintosh: Switch to QoS requests in
tering the
notifier.
Remove it.
Acked-by: Bartlomiej Zolnierkiewicz
Signed-off-by: Viresh Kumar
---
drivers/video/fbdev/pxafb.c | 21 -
drivers/video/fbdev/pxafb.h | 1 -
2 files changed, 22 deletions(-)
diff --git a/drivers/video/fbdev/pxafb.c b/drivers/video/fbdev/pxa
egistering the
notifier.
Remove it.
Acked-by: Bartlomiej Zolnierkiewicz
Signed-off-by: Viresh Kumar
---
drivers/video/fbdev/sa1100fb.c | 27 ---
drivers/video/fbdev/sa1100fb.h | 1 -
2 files changed, 28 deletions(-)
diff --git a/drivers/video/fbdev/sa1100fb.c b/drivers/v
try.
This is pushed here:
git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git opp/config
The entire patchset shall get merged via the OPP tree in 5.20-rc1, please do not
merge individual patches.
Thanks.
--
Viresh
Viresh Kumar (31):
OPP: Track if clock name is configured by
The OPP core now provides a unified API for setting all configuration
types, i.e. dev_pm_opp_set_config().
Lets start using it.
Signed-off-by: Viresh Kumar
---
drivers/gpu/drm/lima/lima_devfreq.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm
The OPP core now provides a unified API for setting all configuration
types, i.e. dev_pm_opp_set_config().
Lets start using it.
Signed-off-by: Viresh Kumar
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 8 ++--
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 10 +-
drivers/gpu/drm/msm
The OPP core now provides a unified API for setting all configuration
types, i.e. dev_pm_opp_set_config().
Lets start using it.
Signed-off-by: Viresh Kumar
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu
The OPP core now provides a unified API for setting all configuration
types, i.e. dev_pm_opp_set_config().
Lets start using it.
Signed-off-by: Viresh Kumar
---
drivers/gpu/drm/tegra/gr3d.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tegra/gr3d.c b
to allow multiple clocks.
- Converted few // comments to /* */.
- Added tags by few people.
- Dropped the last patch to rearrange stuff, not required anymore.
Thanks.
--
Viresh
Viresh Kumar (30):
OPP: Track if clock name is configured by platform
OPP: Add dev_pm_opp_set_config() and friends
The OPP core now provides a unified API for setting all configuration
types, i.e. dev_pm_opp_set_config().
Lets start using it.
Signed-off-by: Viresh Kumar
---
drivers/gpu/drm/lima/lima_devfreq.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm
The OPP core now provides a unified API for setting all configuration
types, i.e. dev_pm_opp_set_config().
Lets start using it.
Signed-off-by: Viresh Kumar
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 8 ++--
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 10 +-
drivers/gpu/drm/msm
The OPP core now provides a unified API for setting all configuration
types, i.e. dev_pm_opp_set_config().
Lets start using it.
Acked-by: Steven Price
Signed-off-by: Viresh Kumar
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions
The OPP core now provides a unified API for setting all configuration
types, i.e. dev_pm_opp_set_config().
Lets start using it.
Tested-by: Dmitry Osipenko
Signed-off-by: Viresh Kumar
---
drivers/gpu/drm/tegra/gr3d.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a
.
- Added tags by few people.
- Dropped the last patch to rearrange stuff, not required anymore.
Thanks.
--
Viresh
Viresh Kumar (20):
OPP: Track if clock name is configured by platform
OPP: Make dev_pm_opp_set_regulators() accept NULL terminated list
OPP: Add dev_pm_opp_set_config() and fr
The OPP core now provides a unified API for setting all configuration
types, i.e. dev_pm_opp_set_config().
Lets start using it.
Signed-off-by: Viresh Kumar
---
drivers/gpu/drm/lima/lima_devfreq.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm
Make dev_pm_opp_set_regulators() accept a NULL terminated list of names
instead of making the callers keep the two parameters in sync, which
creates an opportunity for bugs to get in.
Suggested-by: Greg Kroah-Hartman
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/cpufreq-dt.c
On 04-07-22, 15:35, Steven Price wrote:
> I have to say the 'new improved' list ending with NULL approach doesn't
> work out so well for Panfrost. We already have to have a separate
> 'num_supplies' variable for devm_regulator_bulk_get() /
> regulator_bulk_{en,dis}able(), so the keeping everything
Make dev_pm_opp_set_regulators() accept a NULL terminated list of names
instead of making the callers keep the two parameters in sync, which
creates an opportunity for bugs to get in.
Suggested-by: Greg Kroah-Hartman
Signed-off-by: Viresh Kumar
---
V3->V3.1:
- Update panfrost_drv.c to incl
disabling of the
resource unnecessarily.
> Suggested-by: Viresh Kumar
> Signed-off-by: Clément Péron
> ---
> drivers/gpu/drm/panfrost/panfrost_devfreq.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> b/dr
s now in
> a global location along with similar headers. pxa-regs.h and
> addr-map.h are only used in a very small number of drivers now
> and can be moved to arch/arm/mach-pxa/ directly when those drivers
> are to pass the necessary data as resources.
>
> Cc: Michael Turque
On Wed, Feb 12, 2020 at 2:19 PM Nicolas Boichat wrote:
>
> +Viresh Kumar +Stephen Boyd for clock advice.
You missed adding us in the cc list of the email, fixed that now :)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
| 4 ++--
> 3 files changed, 4 insertions(+), 4 deletions(-)
Acked-by: Viresh Kumar
--
viresh
ree.org/meta-schemas/core.yaml#
> +
> +title: Generic OPP (Operating Performance Points) Common Binding
> +
> +maintainers:
> + - Viresh Kumar
> +
> +description: |
> + Devices work at voltage-current-frequency combinations and some
> implementations
> + have the lib
if (machine_is_h3100())
> - name = "KM416S4030CT";
> if (machine_is_jornada720() || machine_is_h3600())
> name = "K4S281632B-1H";
> - if (machine_is_nanoengine())
> - name = "MT
On 26-10-22, 10:39, Erico Nunes wrote:
> Commit d8c32d3971e4 ("drm/lima: Migrate to dev_pm_opp_set_config()")
> introduced a regression as it may undo the clk_names setting in case
> the optional regulator is missing. This resulted in test and performance
> regressions with lima.
>
> Restore the o
, &config);
> + /*
> + * clkname is set separately so it is not affected by the optional
> + * regulator setting which may return error.
> + */
> + ret = devm_pm_opp_set_clkname(dev, "core");
> + if (ret)
> + return ret;
> +
> + ret = devm_pm_opp_set_regulators(dev, regulator_names);
> if (ret) {
> /* Continue if the optional regulator is missing */
> if (ret != -ENODEV)
Acked-by: Viresh Kumar
--
viresh
the first case we were initializing a two
dimensional array with {0} and in the second case we were initializing a
struct containing two arrays with {0}.
Fix them by adding another pair of {}.
Signed-off-by: Viresh Kumar
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c | 4 ++--
drivers/gp
On 15-07-20, 08:36, Rob Clark wrote:
> I can take the first two into msm-next, the 3rd will need to wait
> until dev_pm_opp_set_bw() lands
You can base that on a8351c12c6c7 in linux-next, I will make sure not to rebase
it anymore.
--
viresh
___
dri-dev
On 20-07-20, 08:03, Rob Clark wrote:
> On Mon, Jul 20, 2020 at 3:01 AM Viresh Kumar wrote:
> >
> > On 15-07-20, 08:36, Rob Clark wrote:
> > > I can take the first two into msm-next, the 3rd will need to wait
> > > until dev_pm_opp_set_bw() lands
> >
> &g
On 21-07-20, 07:28, Rob Clark wrote:
> With your ack, I can add the patch the dev_pm_opp_set_bw patch to my
> tree and merge it via msm-next -> drm-next -> linus
I wanted to send it via my tree, but its okay. Pick this patch from
linux-next and add my Ack, I will drop it after that.
a8351c12c6c7
On 22-07-20, 11:00, Viresh Kumar wrote:
> On 21-07-20, 07:28, Rob Clark wrote:
> > With your ack, I can add the patch the dev_pm_opp_set_bw patch to my
> > tree and merge it via msm-next -> drm-next -> linus
>
> I wanted to send it via my tree, but its okay. Pick this
On 30-07-20, 08:27, Rob Clark wrote:
> Hmm, I've already sent my pull request to Dave, dropping the patch
> would require force-push and sending a new PR. Which I can do if Dave
> prefers. OTOH I guess it isn't the end of the world if the patch is
> merged via two different trees.
I don't think
On 12-10-20, 08:43, Rob Clark wrote:
> On Mon, Oct 12, 2020 at 7:35 AM Daniel Vetter wrote:
> >
> > On Sun, Oct 11, 2020 at 07:09:34PM -0700, Rob Clark wrote:
> > > From: Rob Clark
> > >
> > > Unfortunately, due to an dev_pm_opp locking interaction with
> > > mm->mmap_sem, we need to do pm get be
On 20-10-20, 12:56, Daniel Vetter wrote:
> Yeah that's bad practice. Generally you shouldn't need to hold locks
> in setup/teardown code, since there's no other thread which can
> possible hold a reference to anything your touching anymore. Ofc
> excluding quickly grabbing/dropping a lock to insert
On 28-08-20, 11:37, Viresh Kumar wrote:
> dev_pm_opp_of_remove_table() doesn't report any errors when it fails to
> find the OPP table with error -ENODEV (i.e. OPP table not present for
> the device). And we can call dev_pm_opp_of_remove_table()
> unconditionally here.
>
>
On 05-10-20, 11:56, Viresh Kumar wrote:
> On 28-08-20, 11:37, Viresh Kumar wrote:
> > dev_pm_opp_of_remove_table() doesn't report any errors when it fails to
> > find the OPP table with error -ENODEV (i.e. OPP table not present for
> > the device). And we can call
On 21-10-20, 09:58, Rob Clark wrote:
> On Wed, Oct 21, 2020 at 12:24 AM Viresh Kumar wrote:
> >
> > On 05-10-20, 11:56, Viresh Kumar wrote:
> > > On 28-08-20, 11:37, Viresh Kumar wrote:
> > > > dev_pm_opp_of_remove_table() doesn't report any errors when it
On 20-10-20, 07:13, Rob Clark wrote:
> On Tue, Oct 20, 2020 at 4:24 AM Viresh Kumar wrote:
> >
> > On 20-10-20, 12:56, Daniel Vetter wrote:
> > > Yeah that's bad practice. Generally you shouldn't need to hold locks
> > > in setup/teardown co
On 26-10-20, 01:17, Dmitry Osipenko wrote:
> This patch fixes lockup which happens when OPP table is released if
> interconnect provider uses OPP in the icc_provider->set() callback
> and bandwidth of the ICC path is set to 0 by the ICC core when path
> is released. The icc_put() doesn't need the o
On 27-10-20, 23:26, Dmitry Osipenko wrote:
> 27.10.2020 08:10, Viresh Kumar пишет:
> > On 26-10-20, 01:17, Dmitry Osipenko wrote:
> >> This patch fixes lockup which happens when OPP table is released if
> >> interconnect provider uses OPP in the icc_provider->set()
On 12-10-20, 21:55, Frank Lee wrote:
> Hi, this patchset introduce devm_pm_opp_set_prop_name() and
> devm_pm_opp_set_supported_hw().
>
> Yangtao Li (3):
> opp: Add devres wrapper for dev_pm_opp_set_supported_hw
> opp: Add devres wrapper for dev_pm_opp_set_prop_name
> drm/msm: Convert to devm
On 12-10-20, 21:55, Frank Lee wrote:
> From: Yangtao Li
>
> Use the devm_pm_opp_set_supported_hw() to avoid memory leaks in some cases.
>
> Signed-off-by: Yangtao Li
> Signed-off-by: Yangtao Li
> ---
> drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(
dev_pm_opp_of_remove_table() doesn't report any errors when it fails to
find the OPP table with error -ENODEV (i.e. OPP table not present for
the device). And we can call dev_pm_opp_of_remove_table()
unconditionally here.
While at it, also create a label to put clkname.
Signed-off-by: V
On 25-10-20, 10:39, Rob Clark wrote:
> Nope, I suspect any creation of debugfs files will be problematic.
Yeah, so it only fixed part of the problem.
> (btw, _add_opp_dev_unlocked() looks like it should be called
> _add_opp_dev_locked()?)
>
> It does look like 'struct opp_table' is already refcn
dev_pm_opp_of_remove_table() doesn't report any errors when it fails to
find the OPP table with error -ENODEV (i.e. OPP table not present for
the device). And we can call dev_pm_opp_of_remove_table()
unconditionally here.
Reviewed-by: Qiang Yu
Signed-off-by: Viresh Kumar
---
V2: Ap
On 28-10-20, 19:02, Frank Lee wrote:
> On Wed, Oct 28, 2020 at 6:29 PM Viresh Kumar wrote:
> >
> > On 12-10-20, 21:55, Frank Lee wrote:
> > > From: Yangtao Li
> > >
> > > Add devres wrapper for dev_pm_opp_set_prop_name() to simplify driver
> &g
On 12-10-20, 21:55, Frank Lee wrote:
> From: Yangtao Li
>
> Add devres wrapper for dev_pm_opp_set_prop_name() to simplify driver
> code.
>
> Signed-off-by: Yangtao Li
> Signed-off-by: Yangtao Li
> ---
> drivers/opp/core.c | 39 +++
> include/linux/pm_op
On 30-10-20, 19:19, Frank Lee wrote:
> GPU is also a relatively large number of opp consumers.
I was talking about the number of files or locations from which this
routine (the devm_* variant) is going to get called. And it is one
right now. And I don't see if any of the other callers are going to
On 28-10-20, 11:36, Viresh Kumar wrote:
> On 12-10-20, 21:55, Frank Lee wrote:
> > Hi, this patchset introduce devm_pm_opp_set_prop_name() and
> > devm_pm_opp_set_supported_hw().
> >
> > Yangtao Li (3):
> > opp: Add devres wrapper for dev_pm_opp_set_supported
On 06-06-20, 09:55, Sharat Masetty wrote:
> This is a respin of [1]. Incorported review feedback and fixed issues observed
> during testing. Picked up the Georgi's series from opp/linux-next [2], and
> this
> series is also dependent on a helper function needed to set and clear ddr
> bandwidth vot
On 28-08-20, 11:37, Viresh Kumar wrote:
> dev_pm_opp_of_remove_table() doesn't report any errors when it fails to
> find the OPP table with error -ENODEV (i.e. OPP table not present for
> the device). And we can call dev_pm_opp_of_remove_table()
> unconditionally here.
>
7;.
>
> Signed-off-by: Rob Herring
> ---
> Documentation/devicetree/bindings/arm/spear.yaml | 3 +++
Acked-by: Viresh Kumar
--
viresh
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
dev_pm_opp_of_remove_table() doesn't report any errors when it fails to
find the OPP table with error -ENODEV (i.e. OPP table not present for
the device). And we can call dev_pm_opp_of_remove_table()
unconditionally here.
Signed-off-by: Viresh Kumar
---
drivers/gpu/drm/lima/lima_devfreq.
dev_pm_opp_of_remove_table() doesn't report any errors when it fails to
find the OPP table with error -ENODEV (i.e. OPP table not present for
the device). And we can call dev_pm_opp_of_remove_table()
unconditionally here.
Signed-off-by: Viresh Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_
changes are related to qcom stuff, it
would be great if you can give them a try. I wasn't able to test them
due to lack of hardware.
Ulf, I had to revise the sdhci patch, sorry about that. Please pick this
one.
Diff between V1 and V2 is mentioned in each of the patches separately.
Viresh Kum
dev_pm_opp_of_remove_table() doesn't report any errors when it fails to
find the OPP table with error -ENODEV (i.e. OPP table not present for
the device). And we can call dev_pm_opp_of_remove_table()
unconditionally here.
Reviewed-by: Qiang Yu
Signed-off-by: Viresh Kumar
---
V2: Ap
dev_pm_opp_of_remove_table() doesn't report any errors when it fails to
find the OPP table with error -ENODEV (i.e. OPP table not present for
the device). And we can call dev_pm_opp_of_remove_table()
unconditionally here.
While at it, also create a label to put clkname.
Signed-off-by: V
On 28-08-20, 11:37, Viresh Kumar wrote:
> Hello,
>
> This cleans up some of the user code around calls to
> dev_pm_opp_of_remove_table().
>
> All the patches can be picked by respective maintainers directly except
> for the last patch, which needs the previous two to get mer
On 01-09-20, 13:01, Rajendra Nayak wrote:
> So FWIU, dpu_unbind() gets called even when dpu_bind() fails for some reason.
Ahh, I see.
> I tried to address that earlier [1] which I realized did not land.
I don't think that patch was required, as you can call
dev_pm_opp_put_clkname() multiple time
On 01-09-20, 15:15, Rajendra Nayak wrote:
>
> On 9/1/2020 2:08 PM, Viresh Kumar wrote:
> > On 01-09-20, 13:01, Rajendra Nayak wrote:
> > > So FWIU, dpu_unbind() gets called even when dpu_bind() fails for some
> > > reason.
> >
> > Ahh, I see.
> >
On 31-08-20, 16:39, Viresh Kumar wrote:
> On 28-08-20, 11:37, Viresh Kumar wrote:
> > Hello,
> >
> > This cleans up some of the user code around calls to
> > dev_pm_opp_of_remove_table().
> >
> > All the patches can be picked by respective maintainers
changes are related to qcom stuff, it
would be great if you can give them a try. I wasn't able to test them
due to lack of hardware.
Viresh Kumar (8):
cpufreq: imx6q: Unconditionally call dev_pm_opp_of_remove_table()
drm/lima: Unconditionally call dev_pm_opp_of_remove_table()
dr
On 10-10-18, 08:48, Jordan Crouse wrote:
> qcom,level comes straight from:
>
> https://lore.kernel.org/lkml/20180627045234.27403-2-rna...@codeaurora.org/
>
> But in this case instead of using the CPU to program the RPMh we are passing
> the value to a microprocessor (the GMU) and that will do the
On 10-10-18, 08:27, Jordan Crouse wrote:
> I'm not convinced that required-opps would work. I'm worried that the
> format is too vague if we need to use it for multiple paths and possibly
> other uses too, consider this:
>
> required-opp = <&mdp_path0_opp3, &mdp_path1_opp5, &mdp_rpmh_opp1>;
>
> T
On 10-10-18, 08:29, Jordan Crouse wrote:
> On Wed, Oct 10, 2018 at 03:16:28PM +0530, Viresh Kumar wrote:
> > On 27-08-18, 09:11, Jordan Crouse wrote:
> > > Add the nodes to describe the Adreno GPU and GMU devices.
> > >
> > > Signed-off-by: Jordan Crouse
>
On 10-10-18, 09:10, Jordan Crouse wrote:
> On Wed, Oct 10, 2018 at 08:21:39PM +0530, Viresh Kumar wrote:
> > On 10-10-18, 08:48, Jordan Crouse wrote:
> > > qcom,level comes straight from:
> > >
> > > https://lore.kernel.org/lkml/20180627045234.27403-2-rna...
On 27-09-18, 11:23, Georgi Djakov wrote:
> On 08/27/2018 06:11 PM, Jordan Crouse wrote:
> > Add the "opp-interconnect-bw" property to specify the
> > average and peak bandwidth for an interconnect path for
> > a specific operating power point. A separate bandwidth
> > pair can be specified for each
On 27-08-18, 09:11, Jordan Crouse wrote:
> Add the nodes to describe the Adreno GPU and GMU devices.
>
> Signed-off-by: Jordan Crouse
> ---
> arch/arm64/boot/dts/qcom/sdm845.dtsi | 121 +++
> 1 file changed, 121 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm
On 11-10-18, 08:54, Jordan Crouse wrote:
I understand what you are trying to say Jordan and I agree with those
expectations. But what I am looking for is consistency across Qcom
code using the same feature. Which enables better support for the code
going forward, etc. And if we are going to go a d
On 15-10-18, 08:34, Jordan Crouse wrote:
> I agree that consistency is good. But the GPU is by design outside of the
> control of the genpd universe so it is by design not using the same features.
> It unfortunately does happen to use a similar number in an OPP binding to
> construct the level mapp
On 12-12-18, 14:18, Jordan Crouse wrote:
> + gpu_opp_table: opp-table {
> + compatible = "operating-points-v2-qcom-level";
I think you need to mention "operating-points-v2" as well here.
--
viresh
___
dri
+Rob +Stephen,
On 14-12-18, 09:04, Doug Anderson wrote:
> Hi,
>
> On Thu, Dec 13, 2018 at 8:41 PM Viresh Kumar wrote:
> >
> > On 12-12-18, 14:18, Jordan Crouse wrote:
> > > + gpu_opp_table: opp-table {
> > > +
.remove = virtio_gpio_remove,
> .driver = {
> .name = KBUILD_MODNAME,
> - .owner = THIS_MODULE,
> },
> };
> module_virtio_driver(virtio_gpio_driver);
Acked-by: Viresh Kumar
--
viresh
On 05-03-18, 08:28, Jordan Crouse wrote:
> I'm glad you brought this up - I was trying to find a place in the
> documentation
> to put it, but since target specific nodes would be a new trick for OPP I
> didn't
> quite know how to go about doing it. Do we just list them as Optional: or
> should w
On 06-03-18, 08:37, Jordan Crouse wrote:
> I'll try to explain but I might need Stephen or some of the other folks to
> jump
> in and save me.
Maybe you should start using his kernel.org address then ? :)
> On sdm845 there are shared power resources controlled by the RPMh which is
> programed by
On 08-03-18, 13:14, Jordan Crouse wrote:
> It seems to me that performance_state has a direct relationship with genpd
> which is good for CPU votes but in this case, we're just passing along raw
> data
> to an independent microcontroller. The 'qcom,arc-level' is used to construct
> the actual valu
On 09-03-18, 09:03, Jordan Crouse wrote:
> I don't think we are understanding each other. The GMU is a separate
> microcontroller. It is given a magic number (actually a combination of magic
> numbers) that it then uses to directly interact with the other hardware to
> make
> the vote. The only re
On 09-03-18, 10:42, Jordan Crouse wrote:
> On Fri, Mar 09, 2018 at 09:18:41AM -0800, Stephen Boyd wrote:
> > BTW, it's qcom,corner and not qcom-corner right?
>
> http://git.linaro.org/people/viresh.kumar/mylinux.git/commit/?h=opp/genpd/qcom&id=7586600b3bf3f8e79ce9198922fad7d4aa5b3f8d
>
> +
following discussion with Viresh;
> change gmu phandle to qcom,gmu per Rob]
>
> Jordan Crouse (2):
> dt-bindings: Document qcom,adreno-gmu
> arm64: dts: sdm845: Add gpu and gmu device nodes
Acked-by: Viresh Kumar
--
viresh
___
dri
On 02-03-18, 14:43, Jordan Crouse wrote:
> Add a function to return the device node associated with a
> specific opp which will facilitate detailing with custom
> properties in client drivers.
>
> Signed-off-by: Jordan Crouse
> ---
> drivers/opp/of.c | 20
> include/li
On 02-03-18, 14:56, Jordan Crouse wrote:
> Add the nodes and other bits to describe the Adreno GPU and GMU
> devices.
>
> Change-Id: Ibf4dc0ebb0ac03d8b6b8e65747e142c440e70b0a
Remove it ?
> Signed-off-by: Jordan Crouse
> ---
> arch/arm64/boot/dts/qcom/sdm845.dtsi | 120
> ++
On 02-03-18, 14:43, Jordan Crouse wrote:
> +static int a6xx_gmu_build_freq_table(struct device *dev, unsigned long
> *freqs,
> + u32 size)
> +{
> + int count = dev_pm_opp_get_opp_count(dev);
> + struct dev_pm_opp *opp;
> + int i, index = 0;
> + unsigned long freq = 1;
>
On 05-02-18, 02:21, Ulf Magnusson wrote:
> The AVR32 symbol was removed in commit 26202873bb51 ("avr32: remove
> support for AVR32 architecture"). Remove the remaining references to it
> from the Kconfig files.
>
> No references remain to the removed AVR32_AT32AP_CPUFREQ symbol either,
> so remove
On 29-06-17, 14:49, Viresh Kumar wrote:
> Following compilation warnings were observed for these files:
>
> CC [M] drivers/gpu/drm/msm/mdp/mdp5/mdp5_mdss.o
> drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c: In function 'blend_setup':
> drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.
On 19-07-17, 13:13, Chris Wilson wrote:
> Quoting Viresh Kumar (2017-06-29 10:19:59)
> > diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
> > b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
> > index 7d3741215387..0ee9bd0041cd 100644
> > --- a/drivers/gpu/drm/msm/mdp/
On 10-01-18, 16:45, Arnd Bergmann wrote:
> > 7 arch/arm/boot/dts/spear1340-evb.dtb: Warning (dmas_property): Property
> > 'dmas', cell 4 is not a phandle reference in /ahb/apb/serial@b410
> > 7 arch/arm/boot/dts/spear1340-evb.dtb: Warning (dmas_property): Missing
> > property '#dma-cells' in
On 19 March 2013 15:29, Vikas Sajjan wrote:
> While migrating to common clock framework (CCF), found that the FIMD clocks
> were pulled down by the CCF.
> If CCF finds any clock(s) which has NOT been claimed by any of the
> drivers, then such clock(s) are PULLed low by CCF.
>
> By calling clk_prep
On 1 April 2013 14:13, Vikas Sajjan wrote:
> While migrating to common clock framework (CCF), found that the FIMD clocks
s/found/we found/
> were pulled down by the CCF.
> If CCF finds any clock(s) which has NOT been claimed by any of the
> drivers, then such clock(s) are PULLed low by CCF.
>
>
anything to do with CCF pulling clocks down, but
calling clk_prepare() before clk_enable() is must now.. that's it..
nothing more.
> Signed-off-by: Vikas Sajjan
> ---
> Changes since v3:
> - added clk_prepare() in fimd_probe() and clk_unprepare() in
> fimd_remove(
On 20 April 2013 20:56, Inki Dae wrote:
> Sorry for being late. I think clk_prepare/unprepare are nothing to do yet in
> case of Exynos but those might be used for in the future so your patch looks
> good to me as is.
>
> Applied. :)
And you think the comments i gave were incorrect then? Why?
___
101 - 200 of 217 matches
Mail list logo
