The devfreq framework requires the drivers to provide busy time estimations.
The GPU driver relies on the hardware performance counteres for the busy time
estimations, but different hardware revisions have counters which can be
sourced from different clocks. So the busy time estimation will be
Add a simple function to read 64 registers in the GMU domain
Signed-off-by: Sharat Masetty
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
index
Implement routines to estimate GPU busy time and fetching the
current frequency for the polling interval. This is required by
the devfreq framework which recommends a frequency change if needed.
The driver code then tries to set this new frequency on the GPU by
sending an Out Of Band(OOB) request
On Tue, Aug 28, 2018 at 05:39:57PM -0700, Jeykumar Sankaran wrote:
> Resource manager assigns hw_intf blocks for the encoder only on
> modeset. If queried for hw_intf objects during init, it will be
> NULL. Since hw_intf objects are needed only during encoder enable,
s/during/after/ it looks like
On Tue, Aug 28, 2018 at 05:39:56PM -0700, Jeykumar Sankaran wrote:
> Instead of iterating for hw ctrl per physical encoder, this
> patch moves the iterations and assignment to the virtual encoder.
>
Missing "Changes in" section as well as _why_ you're doing this in your
description.
>
On Tue, Aug 28, 2018 at 05:39:54PM -0700, Jeykumar Sankaran wrote:
> Identify slave-master encoders during initialization and enable
> the encoders explicitly as the current logic has redundant and
> ambiguous loops.
Please include a "Changes in vX" section so I don't need to figure it out
On Tue, Aug 28, 2018 at 05:39:50PM -0700, Jeykumar Sankaran wrote:
> Strip down debugfs support for misr data read on layer mixers
> and interfaces.
Could you please start explaining not only the what, but also the why? I'm
certain there's a very good reason for this change, however you don't
On Tue, Aug 28, 2018 at 04:02:15PM -0700, Jeykumar Sankaran wrote:
> DPU is broken with patch [1]. This patch cleans up few stale codes
> and fixes the DPU bug by using encoder type to identify displays.
>
> [1] https://patchwork.kernel.org/patch/10568269/
>
> Thanks.
>
> Jeykumar Sankaran (3):
From: Sricharan R
Finally add the device link between the master device and
smmu, so that the smmu gets runtime enabled/disabled only when the
master needs it. This is done from add_device callback which gets
called once when the master is added to the smmu.
Signed-off-by: Sricharan R
qcom,smmu-v2 is an arm,smmu-v2 implementation with specific
clock and power requirements.
On msm8996, multiple cores, viz. mdss, video, etc. use this
smmu. On sdm845, this smmu is used with gpu.
Add bindings for the same.
Signed-off-by: Vivek Gautam
Reviewed-by: Rob Herring
Reviewed-by: Tomasz
Add bindings doc for Qcom's smmu-v2 implementation.
Signed-off-by: Vivek Gautam
Reviewed-by: Tomasz Figa
Tested-by: Srinivas Kandagatla
---
.../devicetree/bindings/iommu/arm,smmu.txt | 39 ++
1 file changed, 39 insertions(+)
diff --git
From: Sricharan R
The smmu needs to be functional only when the respective
master's using it are active. The device_link feature
helps to track such functional dependencies, so that the
iommu gets powered when the master device enables itself
using pm_runtime. So by adapting the smmu driver for
From: Sricharan R
The smmu device probe/remove and add/remove master device callbacks
gets called when the smmu is not linked to its master, that is without
the context of the master device. So calling runtime apis in those places
separately.
Global locks are also initialized before enabling
This series provides the support for turning on the arm-smmu's
clocks/power domains using runtime pm. This is done using
device links between smmu and client devices. The device link
framework keeps the two devices in correct order for power-cycling
across runtime PM or across system-wide PM.
On Thu, Aug 30, 2018 at 3:04 PM Tomasz Figa wrote:
>
> On Thu, Aug 30, 2018 at 6:22 PM Vivek Gautam
> wrote:
> >
> > On Mon, Aug 27, 2018 at 4:27 PM Vivek Gautam
> > wrote:
> > >
> > > From: Sricharan R
> > >
> > > The smmu device probe/remove and add/remove master device callbacks
> > > gets
On Thu, Aug 30, 2018 at 6:22 PM Vivek Gautam
wrote:
>
> On Mon, Aug 27, 2018 at 4:27 PM Vivek Gautam
> wrote:
> >
> > From: Sricharan R
> >
> > The smmu device probe/remove and add/remove master device callbacks
> > gets called when the smmu is not linked to its master, that is without
> > the
On Mon, Aug 27, 2018 at 4:27 PM Vivek Gautam
wrote:
>
> From: Sricharan R
>
> The smmu device probe/remove and add/remove master device callbacks
> gets called when the smmu is not linked to its master, that is without
> the context of the master device. So calling runtime apis in those places
>
17 matches
Mail list logo
