On 17.03.2023 16:06, Neil Armstrong wrote:
> Add the Display Port controller subnode to the MDSS node.
>
> Signed-off-by: Neil Armstrong
> ---
Reviewed-by: Konrad Dybcio
Konrad
> arch/arm64/boot/dts/qcom/sm8450.dtsi | 79
>
> 1 file changed, 79 insertio
From: Rob Clark
Inspired by
https://lore.kernel.org/dri-devel/20200604081224.863494-10-daniel.vet...@ffwll.ch/
it seemed like a good idea to get rid of memory allocation in job_run()
fence signaling path, and use lockdep annotations to yell at us about
anything that could deadlock against shrink
From: Rob Clark
The flags are only accessed (1) when submit is constructed, before
enqueuing to gpu sched (ie. when still visible to only the task calling
the submit ioctl), (2) here, where we own a reference to the submit and
are serialized on the gpu sched thread, and (3) after the submit is
re
From: Rob Clark
Avoid allocating memory in job_run() by pre-allocating the hw_fence.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_fence.c | 12 +---
drivers/gpu/drm/msm/msm_fence.h | 3 ++-
drivers/gpu/drm/msm/msm_gem_submit.c | 7 +++
drivers/gpu/drm/msm/msm_ri
From: Rob Clark
Export the locked version or lru's move_tail().
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_gem.c | 11 ++-
include/drm/drm_gem.h | 1 +
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index
From: Rob Clark
vmap'ing is just pinning in disguise. So treat it as such and simplify
the LRU tracking.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu
From: Rob Clark
Stop open coding VMA construction, which will be needed in the next
commit. And since the VMA already has a ptr to the adress space, stop
passing that around everywhere. (Also, an aspace always has an mmu so
we can drop a couple pointless NULL checks.)
Signed-off-by: Rob Clark
From: Rob Clark
We need to use the inuse count to track that a BO is pinned until
we have the hw_fence. But we want to remove the obj lock from the
job_run() path as this could deadlock against reclaim/shrinker
(because it is blocking the hw_fence from eventually being signaled).
So split that t
From: Rob Clark
Just code-motion.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 46 +--
1 file changed, 22 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 009a34b3a49b..c97dddf3e2f2
From: Rob Clark
Since the LRU lock is already acquired when moving an obj between LRUs,
we can use it to protect pin_count and madv, without any significant
change in locking (ie. it just expands the scope of the lock by a hand-
ful of instructions). This prepares the way to decrement the pin_co
From: Rob Clark
Now that everything that controls which LRU an obj lives in *except* the
backing pages is protected by the LRU lock, add a special path to unpin
in the job_run() path, we we are assured that we already have backing
pages and will not be racing against eviction (because the GEM obj
From: Rob Clark
Needed to idr_preload() which returns with preemption disabled.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_drv.c | 6 ++
drivers/gpu/drm/msm/msm_gem_submit.c | 10 +-
drivers/gpu/drm/msm/msm_gpu.h | 2 +-
drivers/gpu/drm/msm/msm_submitqu
From: Rob Clark
Avoid allocation under idr_lock, to prevent deadlock against the
job_free() path (which runs on same thread as job_run(), which makes
it also part of the fence-signaling path.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem_submit.c | 8 ++--
1 file changed, 6 inse
From: Rob Clark
It is already a no-op, since we've already loaded the fw from
adreno_load_gpu(), so drop the redundant call.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/adre
From: Rob Clark
These allocations are only done the first (successful) time through
hw_init() so they won't actually happen in the job_run() path. But
lockdep doesn't know this. So dis-entangle them from the hw_init()
path.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c
From: Rob Clark
Move the one-time RPMh setup to a6xx_gmu_init(). To get rid of the hack
for one-time init vs start, add in an extra a6xx_rpmh_stop() at the end
of the init sequence.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 18 --
1 file changed, 8 i
From: Rob Clark
In the process of adding lockdep annotation for GPU job_run() path to
catch potential deadlocks against the shrinker/reclaim path, I turned
up this lockdep splat:
==
WARNING: possible circular locking dependency detected
From: Rob Clark
Similar to the previous patch, move the allocation out from under
dev_pm_qos_mtx, by speculatively doing the allocation and handle
any race after acquiring dev_pm_qos_mtx by freeing the redundant
allocation.
Signed-off-by: Rob Clark
---
drivers/base/power/qos.c | 12 +++
From: Rob Clark
In the process of adding lockdep annotation for drm GPU scheduler's
job_run() to detect potential deadlock against shrinker/reclaim, I hit
this lockdep splat:
==
WARNING: possible circular locking dependency detected
6.
From: Rob Clark
This will make it easier to catch places doing allocations that can
trigger reclaim under devfreq->lock.
Because devfreq->lock is held over various devfreq_dev_profile
callbacks, there might be some fallout if those callbacks do allocations
that can trigger reclaim, but I've look
From: Rob Clark
Annotate dev_pm_qos_mtx to teach lockdep to scream about allocations
that could trigger reclaim under dev_pm_qos_mtx.
Signed-off-by: Rob Clark
---
drivers/base/power/qos.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/base/power/qos.c b/drivers/base/p
From: Rob Clark
For cases where icc_bw_set() can be called in callbaths that could
deadlock against shrinker/reclaim, such as runpm resume, we need to
decouple the icc locking. Introduce a new icc_bw_lock for cases where
we need to serialize bw aggregation and update to decouple that from
paths
From: Rob Clark
Preparing for better lockdep annotations for things that happen in runpm
suspend/resume path vs shrinker/reclaim in the following patches, we
need to avoid allocations that can trigger reclaim in the icc_set_bw()
path. In the RPMh case, rpmh_write_batch() already uses GFP_ATOMIC,
From: Rob Clark
Based on
https://lore.kernel.org/dri-devel/20200604081224.863494-10-daniel.vet...@ffwll.ch/
but made to be optional.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_ringbuffer.c | 1 +
drivers/gpu/drm/scheduler/sched_main.c | 9 +
include/drm/gpu_scheduler.h
From: Rob Clark
Teach lockdep that icc_bw_lock is needed in code paths that could
deadlock if they trigger reclaim.
Signed-off-by: Rob Clark
---
drivers/interconnect/core.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/interconnect/core.c b/drivers/inter
Hi, Rob:
Rob Herring 於 2023年3月18日 週六 上午7:36寫道：
>
> Cleanup bindings dropping unneeded quotes. Once all these are fixed,
> checking for this can be enabled in yamllint.
For MediaTek part,
Reviewed-by: Chun-Kuang Hu
>
> Signed-off-by: Rob Herring
> ---
> .../bindings/auxdisplay/holtek,ht16k33
Am 20.03.23 um 15:43 schrieb Rob Clark:
From: Rob Clark
Avoid allocating memory in job_run() by pre-allocating the hw_fence.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_fence.c | 12 +---
drivers/gpu/drm/msm/msm_fence.h | 3 ++-
drivers/gpu/drm/msm/msm_gem_s
On Mon, Mar 13, 2023 at 9:54 AM Konrad Dybcio wrote:
>
>
>
> On 24.02.2023 16:04, Jonathan Marek wrote:
> > This won't work because a2xx freedreno userspace expects to own all the
> > perfcounters.
> >
> > This will break perfcounters for userspace, and when userspace isn't using
> > perfcounter
From: Rob Clark
The next generated header update will drop the _LO/_HI suffix, now that
the userspace tooling properly understands 64b vs 32b regs (and the _LO/
_HI workarounds are getting cleaned up). So convert to using the 64b
reg helpers in prep.
Signed-off-by: Rob Clark
---
drivers/gpu/d
On 20.03.2023 19:56, Konrad Dybcio wrote:
>
>
> On 20.03.2023 19:54, Rob Clark wrote:
>> From: Rob Clark
>>
>> The next generated header update will drop the _LO/_HI suffix, now that
>> the userspace tooling properly understands 64b vs 32b regs (and the _LO/
>> _HI workarounds are getting cle
On 20.03.2023 19:54, Rob Clark wrote:
> From: Rob Clark
>
> The next generated header update will drop the _LO/_HI suffix, now that
> the userspace tooling properly understands 64b vs 32b regs (and the _LO/
> _HI workarounds are getting cleaned up). So convert to using the 64b
> reg helpers i
Hi Rob,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on rafael-pm/linux-next drm-intel/for-linux-next
drm-intel/for-linux-next-fixes drm-tip/drm-tip linus/master v6.3-rc3
next-20230320]
[cannot apply to chanwoo
On Mon, Mar 20, 2023 at 11:57 AM Konrad Dybcio wrote:
>
>
>
> On 20.03.2023 19:56, Konrad Dybcio wrote:
> >
> >
> > On 20.03.2023 19:54, Rob Clark wrote:
> >> From: Rob Clark
> >>
> >> The next generated header update will drop the _LO/_HI suffix, now that
> >> the userspace tooling properly unde
On Mon, Mar 20, 2023 at 9:52 AM Christian König
wrote:
>
>
>
> Am 20.03.23 um 15:43 schrieb Rob Clark:
> > From: Rob Clark
> >
> > Avoid allocating memory in job_run() by pre-allocating the hw_fence.
> >
> > Signed-off-by: Rob Clark
> > ---
> > drivers/gpu/drm/msm/msm_fence.c | 12 +++
Hi Rob,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on rafael-pm/linux-next drm-intel/for-linux-next
drm-intel/for-linux-next-fixes drm-tip/drm-tip linus/master v6.3-rc3
next-20230320]
[cannot apply to chanwoo
Cleanup bindings dropping unneeded quotes. Once all these are fixed,
checking for this can be enabled in yamllint.
Reviewed-by: Chun-Kuang Hu
Reviewed-by: Krzysztof Kozlowski
Reviewed-by: Laurent Pinchart
Signed-off-by: Rob Herring
---
v2:
- Also drop quotes on URLs
---
.../bindings/auxdispl
On 18/03/2023 21:45, Leonard Lausen wrote:
Commit da7716a249b699978fb5 ("drm/msm/dpu: Add support for XR30 format") enabled
support for the 10-bit XR30 color format but missed AR30 color format.
This can trigger bugs in userspace. KDE KWin compositor for example always
prefers 10-bit color forma
On 21/03/2023 01:38, Rob Herring wrote:
Cleanup bindings dropping unneeded quotes. Once all these are fixed,
checking for this can be enabled in yamllint.
Reviewed-by: Chun-Kuang Hu
Reviewed-by: Krzysztof Kozlowski
Reviewed-by: Laurent Pinchart
Signed-off-by: Rob Herring
---
v2:
- Also dro
As promised in the basic wide planes support ([1]) here comes a series
supporting 2*max_linewidth for all the planes.
Note: this iteration features handling of rotation and reflection of the
wide plane. However rot90 is still not tested: it is enabled on sc7280
and it only supports UBWC (tiled) fr
The helper drm_atomic_helper_check_plane_state() runs several checks on
plane src and dst rectangles, including the check whether required
scaling fits into the required margins. The msm driver would benefit
from having a function that does all these checks except the scaling
one. Split them into a
Take into account the plane rotation and flipping when calculating src
positions for the wide plane parts.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 27 ++-
1 file changed, 17 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/m
Remove historical fields intfs_swapped and topology fields from struct
dpu_encoder_virt and also remove even more historical docs.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/gpu/drm/msm/di
As the debugfs is fully cleared on drm device removal, drop the
encoder-specific cleanup function, remove debugfs_root from dpu_encoder
struct and also remove phys_encoder late_register() ops which has been
unused since the driver being added.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/
All resource allocation is centered around the LMs. Then other blocks
(except DSCs) are allocated basing on the LMs that was selected, and LM
powers up the CRTC rather than the encoder.
Moreover if at some point the driver supports encoder cloning,
allocating resources from the encoder will be inc
Stop poking into CRTC state from dpu_encoder.c, fill CRTC HW resources
from dpu_crtc_assign_resources().
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c| 27 +
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 24 ++
2 files change
Up to now the driver has been using encoder to allocate hardware
resources. Switch it to use CRTC id in preparation for the next step.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 16 +--
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 10 +-
drivers/gpu/drm/
As we are going to add virtual planes, add the list of supported formats
to the hw catalog entry. It will be used to setup universal planes, with
later selecting a pipe depending on whether the YUV format is used for
the framebuffer.
Signed-off-by: Dmitry Baryshkov
---
.../gpu/drm/msm/disp/dpu1/
The struct dpu_rm_requirements was used to wrap display topology and
hw resources, which meant INTF indices. As of commit ef58e0ad3436
("drm/msm/dpu: get INTF blocks directly rather than through RM") the hw
resources struct was removed, leaving struct dpu_rm_requirements
containing a single field (
Virtual wide planes give high amount of flexibility, but it is not
always enough:
In parallel multirect case only the half of the usual width is supported
for tiled formats. Thus the whole width of two tiled multirect
rectangles can not be greater than max_linewidth, which is not enough
for some p
In preparation to virtualized planes support, move pstate->pipe
initialization from dpu_plane_reset() to dpu_plane_atomic_check(). In
case of virtual planes the plane's pipe will not be known up to the
point of atomic_check() callback.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp
We need to know if the platform supports inline rotation on any of the
SSPP blocks or not. Add this information to struct dpu_caps in a form of
the boolean field has_inline_rot.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 1 +
drivers/gpu/drm/msm/disp/dpu
Only several SSPP blocks support such features as YUV output or scaling,
thus different DRM planes have different features. Properly utilizing
all planes requires the attention of the compositor, who should
prefer simpler planes to YUV-supporting ones. Otherwise it is very easy
to end up in a situ
This is good. Hopefully it helps us catch lockdep bugs.
Reviewed-by: Luben Tuikov
Regards,
Luben
On 2023-03-20 10:43, Rob Clark wrote:
> From: Rob Clark
>
> Based on
> https://lore.kernel.org/dri-devel/20200604081224.863494-10-daniel.vet...@ffwll.ch/
> but made to be optional.
>
> Signed-off
Commit da7716a249b699978fb5 ("drm/msm/dpu: Add support for XR30 format") enabled
support for the 10-bit XR30 color format but missed enabling support for the
corresponding per-pixel alpha-blending AR30 color format.
Declaring only XR30 but not AR30 color format support can trigger bugs in
userspac
Hi Rob,
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Rob-Clark/drm-msm-Pre-allocate-hw_fence/20230320-224826
base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link:
https://lore.kernel.org/r
55 matches
Mail list logo
