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
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 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 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
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(
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
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 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 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 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 27-10-20, 17:05, Viresh Kumar wrote:
> It isn't that straight forward unfortunately, we need to make sure the
> table doesn't get allocated for the same device twice, so
> find+allocate needs to happen within a locked region.
>
> I have taken, not so straight forward
On 03-11-20, 08:50, Rob Clark wrote:
> sorry, it didn't apply cleanly (which I guess is due to some other
> dependencies that need to be picked back to v5.4 product kernel), and
> due to some other things I'm in middle of debugging I didn't have time
> yet to switch to v5.10-rc or look at what else
On 05-11-20, 11:24, Rob Clark wrote:
> On Tue, Nov 3, 2020 at 7:04 PM Viresh Kumar wrote:
> >
> > On 03-11-20, 08:50, Rob Clark wrote:
> > > sorry, it didn't apply cleanly (which I guess is due to some other
> > > dependencies that need to be picked back to
On Fri, 6 Nov 2020 at 12:46, Viresh Kumar wrote:
>
> On 05-11-20, 11:24, Rob Clark wrote:
> > On Tue, Nov 3, 2020 at 7:04 PM Viresh Kumar wrote:
> > >
> > > On 03-11-20, 08:50, Rob Clark wrote:
> > > > sorry, it didn't apply cleanly (which I guess
On 17-11-20, 09:02, Rob Clark wrote:
> With that on top of the previous patch,
Don't you still have this ? Which fixed the lockdep in the remove path.
https://lore.kernel.org/lkml/20201022080644.2ck4okrxygmkuatn@vireshk-i7/
To make it clear you need these patches to fix the OPP stuff:
//From 5.
On 18-11-20, 08:53, Rob Clark wrote:
> On Tue, Nov 17, 2020 at 9:28 PM Viresh Kumar wrote:
> >
> > On 17-11-20, 09:02, Rob Clark wrote:
> > > With that on top of the previous patch,
> >
> > Don't you still have this ? Which fixed the lockdep in the rem
On 19-11-20, 11:35, Viresh Kumar wrote:
> On 18-11-20, 08:53, Rob Clark wrote:
> > On Tue, Nov 17, 2020 at 9:28 PM Viresh Kumar
> > wrote:
> > >
> > > On 17-11-20, 09:02, Rob Clark wrote:
> > > > With that on top of the previous patch,
> >
On 07-12-20, 11:46, Viresh Kumar wrote:
> On 19-11-20, 11:35, Viresh Kumar wrote:
> > On 18-11-20, 08:53, Rob Clark wrote:
> > > On Tue, Nov 17, 2020 at 9:28 PM Viresh Kumar
> > > wrote:
> > > >
> > > > On 17-11-20, 09:02, Rob Clark wrot
Dropped lots of people from cc list
On 04-01-21, 12:49, Viresh Kumar wrote:
> On 01-01-21, 16:54, Yangtao Li wrote:
> > Use devm_pm_opp_* API to simplify code, and we don't need
> > to make opp_table glabal.
> >
> > Let's remove opp_table from geni_se late
On 03-01-21, 03:57, Yangtao Li wrote:
> Use devm_pm_opp_* API to simplify code.
>
> Signed-off-by: Yangtao Li
> ---
> drivers/devfreq/devfreq.c | 66 +--
> include/linux/devfreq.h | 23 --
> 2 files changed, 1 insertion(+), 88 deletions(-)
Remo
On 01-01-21, 16:54, Yangtao Li wrote:
> +/**
> + * devm_pm_opp_put_clkname() - Releases resources blocked for clk.
> + * @dev: Device for which we do this operation.
> + * @opp_table: OPP table returned from devm_pm_opp_set_clkname().
> + */
> +void devm_pm_opp_put_clkname(struct device *dev, struc
On 01-01-21, 16:54, Yangtao Li wrote:
> Use devm_pm_opp_* API to simplify code, and we don't need
> to make opp_table glabal.
>
> Let's remove opp_table from geni_se later.
>
> Signed-off-by: Yangtao Li
> ---
> drivers/tty/serial/qcom_geni_serial.c | 23 +--
> 1 file changed
On 01-01-21, 16:54, Yangtao Li wrote:
> There is no need to manually release devm related resources.
>
> Signed-off-by: Yangtao Li
> ---
> drivers/gpu/drm/lima/lima_devfreq.c | 5 -
> 1 file changed, 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/lima/lima_devfreq.c
> b/drivers/gpu/drm/li
On 01-01-21, 16:54, Yangtao Li wrote:
> We should use dev_pm_opp_put_clkname() to free opp table each time
> dev_pm_opp_of_add_table() got error.
>
> Signed-off-by: Yangtao Li
> ---
> drivers/tty/serial/qcom_geni_serial.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> di
On 01-01-21, 16:54, Yangtao Li wrote:
> Hi,
>
> This patchset add devm_pm_opp_set_clkname, devm_pm_opp_put_clkname,
> devm_pm_opp_set_regulators, devm_pm_opp_put_regulators,
> devm_pm_opp_set_supported_hw, devm_pm_opp_of_add_table and
> devm_pm_opp_register_notifier.
Please also mention next time
On 03-01-21, 03:54, Yangtao Li wrote:
> Use devm_pm_opp_* API to simplify code, and remove opp_table
> from tegra_devfreq.
Patches starting this one didn't appear in the same thread and it is a
nightmare to apply these now. Please send everything properly next
time.
--
viresh
___
On 01-01-21, 16:54, Yangtao Li wrote:
> Add devres wrapper for dev_pm_opp_register_notifier() to simplify driver
> code.
>
> Signed-off-by: Yangtao Li
> ---
> drivers/opp/core.c | 38 ++
> include/linux/pm_opp.h | 6 ++
> 2 files changed, 44 insertion
On 01-01-21, 16:54, Yangtao Li wrote:
> Hi,
>
> This patchset add devm_pm_opp_set_clkname, devm_pm_opp_put_clkname,
> devm_pm_opp_set_regulators, devm_pm_opp_put_regulators,
> devm_pm_opp_set_supported_hw, devm_pm_opp_of_add_table and
> devm_pm_opp_register_notifier.
You can't put so many names i
to go through OPP tree here. Please provide
your Acks for platform specific bits.
--
Viresh
Viresh Kumar (13):
opp: Rename _opp_set_rate_zero()
opp: No need to check clk for errors
opp: Keep track of currently programmed OPP
opp: Split _set_opp() out of dev_pm_opp_set_rate()
opp: Allow _se
dev_pm_opp_set_bw() is getting removed and dev_pm_opp_set_opp() should
be used instead. Migrate to the new API.
Signed-off-by: Viresh Kumar
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
On 02-03-21, 16:40, Dmitry Osipenko wrote:
> 20.01.2021 19:01, Dmitry Osipenko пишет:
> > 01.01.2021 19:54, Yangtao Li пишет:
> >> Hi,
> >>
> >> This patchset add devm_pm_opp_set_clkname, devm_pm_opp_put_clkname,
> >> devm_pm_opp_set_regulators, devm_pm_opp_put_regulators,
> >> devm_pm_opp_set_supp
On 11-03-21, 22:20, Dmitry Osipenko wrote:
> From: Yangtao Li
>
> Add devres wrapper for dev_pm_opp_register_notifier() to simplify driver
> code.
>
> Signed-off-by: Yangtao Li
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/opp/core.c | 38 ++
> inclu
On 11-03-21, 22:20, Dmitry Osipenko wrote:
> +struct opp_table *devm_pm_opp_set_clkname(struct device *dev, const char
> *name)
> +{
> + struct opp_table *opp_table;
> + int err;
> +
> + opp_table = dev_pm_opp_set_clkname(dev, name);
> + if (IS_ERR(opp_table))
> + retur
+), 68 deletions(-)
This patch has some updates in linux-next, which I don't have. Please
get this merged with the drm tree over 5.13-rc1 later.
Acked-by: Viresh Kumar
--
viresh
___
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
On 14-03-21, 19:33, Dmitry Osipenko wrote:
> This series adds resource-managed OPP API helpers and makes drivers
> to use them.
>
> Changelog:
>
> v3: - Dropped dev_pm_opp_register_notifier().
>
> - Changed return type of the devm helpers from opp_table pointer
> to errno.
>
> - C
On 25-03-21, 10:13, Stanimir Varbanov wrote:
> Hi,
>
> On 3/14/21 6:34 PM, Dmitry Osipenko wrote:
> > From: Yangtao Li
> >
> > Use resource-managed OPP API to simplify code.
> >
> > Signed-off-by: Yangtao Li
> > Signed-off-by: Dmitry Osipenko
> > ---
> > drivers/media/platform/qcom/venus/cor
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 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 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, 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, 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 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
___
Fre
+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 {
> > > +
On 18-12-18, 11:05, Doug Anderson wrote:
> OK, it's fine with me to have the fallback, but if we do we should be
> consistent about it and make sure it's in all the bindings and device
> tree files...
Sure.
I am not sure what's the right way to do it is, i.e. should we keep the
"operating-points-
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 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
___
Freedre
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
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.
Viresh Kumar (8):
cpufreq: imx6q: Unconditionally call dev_pm_opp_of_remove_table()
drm/lima: Unconditionally call dev_pm_opp_of_remove_table()
dr
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.
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
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 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
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 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 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: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 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 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
___
Fre
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/msm/adreno/a5xx_gpu.c | 8 ++--
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 10 +-
drivers/gpu/drm/msm
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/msm/adreno/a5xx_gpu.c | 8 ++--
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 10 +-
drivers/gpu/drm/msm
83 matches
Mail list logo
