Am 20.10.21 um 21:32 schrieb Andrey Grodzovsky:
On 2021-10-04 4:14 a.m., Christian König wrote:
The problem is a bit different.
The callback is on the dependent fence, while we need to signal the
scheduler fence.
Daniel is right that this needs an irq_work struct to handle this
properly
Hi, Matthew,
On Mon, 2021-10-11 at 16:47 -0700, Matthew Brost wrote:
> The hangcheck selftest blocks per engine resets by setting magic bits
> in
> the reset flags. This is incorrect for GuC submission because if the
> GuC
> fails to reset an engine we would like to do a full GT reset. Do no
> set
On Mon, 2021-10-11 at 12:40 -0700, Matthew Brost wrote:
> The hangcheck selftest blows on DG1 CI and aborts the BAT run.
> Investigation is underway to root cause the failure but in the
> meantime
> disable to this test on DG1 to unblock CI.
>
> Signed-off-by: Matthew Brost
Reviewed-by: Thomas H
On Wed, 2021-10-20 at 12:21 -0700, Matthew Brost wrote:
> Use __release_guc_id (lock held) rather than release_guc_id (acquires
> lock), add lockdep annotations.
>
> 213.280129] i915: Running i915_perf_live_selftests/live_noa_gpr
> [ 213.283459]
> [ 213
On Wed, 2021-10-20 at 13:34 -0700, John Harrison wrote:
> On 10/11/2021 10:57, Matthew Brost wrote:
> > perf_parallel_engines is micro benchmark to test i915 request
> > scheduling. The test creates a thread per physical engine and
> > submits
> > NOP requests and waits the requests to complete in
Use DP 2.0 DPCD 248h new name (LINK_QUAL_PATTERN_SELECT) and rename selected
phy test patterns to LINK_QUAL_PATTERN_*
Note: TPS4 LT pattern is CP2520 Pattern 3 (refer to DP2.0 spaces Table 3-11,
DPCD 00248h
LINK_QUAL_PATTERN_SELECT, and DP PHY 1.4 CTS - Appendix A - Compliance EYE
Pattern(CP252
Update selected phy test pattern names to use the new names/definitions of DPCD
248h in DP2.0/drm_dp_helpers.h
No functional changes
Cc: Manasi Navare
CC: Jani Nikula
Cc: Imre Deak
Signed-off-by: Khaled Almahallawy
---
drivers/gpu/drm/i915/display/intel_dp.c | 12 ++--
1 file changed
Use the new definition of DPCD 248h (DP_LINK_QUAL_PATTERN_SELECT)
No functional changes.
Cc: Harry Wentland
Cc: Alex Deucher
Signed-off-by: Khaled Almahallawy
---
drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/dr
This series updates DPCD 248h register name and PHY test patterns names to
follow DP 2.0 Specs.
Also updates the DP PHY CTS codes of the affected drivers (i915, amd, msm)
No functional changes expected.
Reference: “DPCD 248h/10Bh/10Ch/10Dh/10Eh Name/Description Consistency”
https://groups.vesa.o
DPCD 248h name was changed from “PHY_TEST_PATTERN” in DP 1.4 to
“LINK_QUAL_PATTERN_SELECT” in DP 2.0.
Also, DPCD 248h [6:0] is the same as DPCDs 10Bh/10Ch/10Dh/10Eh [6:0]. So
removed the repeated definition of PHY patterns.
Reference: “DPCD 248h/10Bh/10Ch/10Dh/10Eh Name/Description Consistency”
On Wed, 20 Oct 2021 20:10:24 -0700
Gurchetan Singh wrote:
> @@ -305,6 +306,7 @@ drm_gem_object_release_handle(int id, void *ptr, void
> *data)
> drm_gem_remove_prime_handles(obj, file_priv);
> drm_vma_node_revoke(&obj->vma_node, file_priv);
>
> + drm_gem_trace_gpu_mem_instance(
On Wed, 20 Oct 2021 20:10:23 -0700
Gurchetan Singh wrote:
> - drm_gem_private_object_init(..) increases the total memory
> counter.
>
> * All GEM objects (whether allocated or imported) seem to begin
> there.
> * If there's a better place/method, please do let
> me know.
>
> - drm
- drm_gem_prime_import_dev increases the per-device import memory
counter
* Most drivers use it.
* drivers that have a (*gem_prime_import) callback will need
additional changes, which can be done if everyone likes the
overall RFC.
- drm_prime_gem_destroy decreases the per-device im
For struct drm_device, add:
- mem_total
- import_mem_total
For struct drm_file, add:
- mem_instance
- import_mem_instance
Signed-off-by: Gurchetan Singh
---
include/drm/drm_device.h | 16
include/drm/drm_file.h | 16
2 files changed, 32 insert
- drm_gem_private_object_init(..) increases the total memory
counter.
* All GEM objects (whether allocated or imported) seem to begin
there.
* If there's a better place/method, please do let
me know.
- drm_gem_object_free(..) decreases the total memory counter.
Signed-off-by: Gurch
- drm_gem_prime_fd_to_handle increases the per-instance imported
memory counter
- drm_gem_remove_prime_handles decreases the per-instance imported
memory counter on non-fake imports.
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/drm_gem.c | 3 +++
drivers/gpu/drm/drm_prime.c | 2 ++
- drm_gem_handle_create_tail(..) increases the per instance
memory counter.
- drm_gem_object_release_handle(..) decreases the per instance
memory counter.
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/drm_gem.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/drm_
Sometimes, an exported dma-buf is added to the import list.
That messes up with trace point accounting, so track real vs.
fake imports to correct this.
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/drm_gem.c | 5 -
drivers/gpu/drm/drm_internal.h | 4 ++--
drivers/gpu/drm/drm_prim
The existing gpu_mem_total tracepoint [1] is not currently used by
any in-tree consumers, we should add some.
In addition, there's a desire to report imported memory via the
counters too [2].
To do this, we'll have to redefine the event to:
a) Change 'pid' to 'ctx_id'
The reason is DRM subsyst
- Add helper functions for above tracepoints in the drm_gem.{h,c}
files
- Given more tracepoints, a drm_trace.* file may be started
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/Kconfig | 1 +
drivers/gpu/drm/drm_gem.c | 49 +++
include/drm/drm_gem.
This is latest iteration of GPU memory tracepoints [1].
In the past, there were questions about the "big picture" of memory
accounting [2], especially given related work on dma-buf heaps and DRM
cgroups [3]. Also, there was a desire for a non-driver specific solution.
The great news is the dma
(Dropping Andrzej, because that address keeps bouncing. Does
MAINTAINERS and/or .mailmap need updating?)
Apologies for the double reply here, but I forgot to mention one last
thing for now:
On Wed, Oct 20, 2021 at 5:40 PM Sean Paul wrote:
>
> On Wed, Oct 20, 2021 at 04:17:28PM -0700, Brian Norri
Hi all,
On Tue, 5 Oct 2021 10:23:23 +0200 Christian König
wrote:
>
> Am 05.10.21 um 09:59 schrieb Stephen Rothwell:
> >
> > After merging the drm-misc tree, today's linux-next build (htmldocs)
> > produced this warning:
> >
> > include/linux/dma-buf.h:456: warning: Function parameter or member '
On Wed, Oct 20, 2021 at 5:40 PM Sean Paul wrote:
> On Wed, Oct 20, 2021 at 04:17:28PM -0700, Brian Norris wrote:
> > Prior to commit 6c836d965bad ("drm/rockchip: Use the helpers for PSR"),
> > "PSR disable" used non-blocking analogix_dp_send_psr_spd(). The refactor
> > accidentally (?) set blockin
On Wed, Oct 20, 2021 at 04:17:28PM -0700, Brian Norris wrote:
> Prior to commit 6c836d965bad ("drm/rockchip: Use the helpers for PSR"),
> "PSR disable" used non-blocking analogix_dp_send_psr_spd(). The refactor
> accidentally (?) set blocking=true.
IIRC this wasn't accidental.
The reason it becam
From: Rob Clark
[ Upstream commit f6f59072e821901d96c791864a07d57d8ec8d312 ]
I've seen some crashes in our crash reporting that *look* like multiple
threads stomping on each other while communicating with GMU. So wrap
all those paths in a lock.
Signed-off-by: Rob Clark
Signed-off-by: Sasha Le
Prior to commit 6c836d965bad ("drm/rockchip: Use the helpers for PSR"),
"PSR disable" used non-blocking analogix_dp_send_psr_spd(). The refactor
accidentally (?) set blocking=true.
This can cause upwards of 60-100ms of unneeded latency when exiting
self-refresh, which can cause very noticeable lag
On Fri, Oct 01, 2021 at 02:52:41PM -0300, Jason Gunthorpe wrote:
> This addresses Cornelia's remark on the earlier patch that ccw has a
> confusing lifecycle. While it doesn't seem like the original attempt was
> functionally wrong, the result can be made better with a lot of further
> work.
>
> R
A weak implementation of parallel submission (multi-bb execbuf IOCTL) for
execlists. Doing as little as possible to support this interface for
execlists - basically just passing submit fences between each request
generated and virtual engines are not allowed. This is on par with what
is there for t
On Tue, 2021-10-19 at 21:09 +0300, Ville Syrjälä wrote:
> On Tue, Oct 05, 2021 at 10:40:14PM -0400, Lyude Paul wrote:
> > This simply adds proper support for panel backlights that can be
> > controlled
> > via VESA's backlight control protocol, but which also require that we
> > enable and disable
Set all engine props values for GuC virtual engines as a request can
point to a virtual engine with GuC submission and these props are used
all over the driver. This differs from execlists where a request can
only point to a virtual engine.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/g
The fallback was introduced in commit 80c33624e472 ("io-mapping: Fixup
for different names of writecombine") to fix the build on microblaze.
5 years later, it seems all archs now provide a pgprot_writecombine(),
so just remove the other possible fallbacks. For microblaze,
pgprot_writecombine() is
On 10/11/2021 10:57, Matthew Brost wrote:
perf_parallel_engines is micro benchmark to test i915 request
scheduling. The test creates a thread per physical engine and submits
NOP requests and waits the requests to complete in a loop. In execlists
mode this works perfectly fine as powerful CPU has
FWIW, I'm using this IOCTL in a wlroots patchset [1].
To detect support for this IOCTL, is there anything better than creating a
DMA-BUF and checking for ENOTTY? I'd like to disable explicit sync at init-time
if this is missing.
[1]: https://github.com/swaywm/wlroots/pull/3282
https://bugzilla.kernel.org/show_bug.cgi?id=214197
--- Comment #6 from Alex Deucher (alexdeuc...@gmail.com) ---
Does this patch help?
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=60b78ed088ebe1a872ee1320b6c5ad6ee2c4bd9a
--
You may reply to this email to add a com
From: Fangzhi Zuo
[Why]
configure/call DC interface for DP2 mst support. This is needed to make DP2
mst work.
[How]
- add encoding type, logging, mst update/reduce payload functions
Use the link encoding to determine the DP type (1.4 or 2.0) and add a
flag to dc_stream_update to determine wheth
On Wed, Oct 20, 2021 at 3:50 PM Bhawanpreet Lakha
wrote:
>
> From: Fangzhi Zuo
Please include a patch description.
Alex
>
> Signed-off-by: Fangzhi Zuo
> ---
> drivers/gpu/drm/amd/display/dc/core/dc.c | 14 +
> drivers/gpu/drm/amd/display/dc/core/dc_link.c | 280 ++
> ..
8b/10b encoding format requires to reserve the first slot for
recording metadata. Real data transmission starts from the second slot,
with a total of available 63 slots available.
In 128b/132b encoding format, metadata is transmitted separately
in LLCP packet before MTP. Real data transmission sta
Add a helper to sort through the SLPC/RPS cases of get/set methods.
Boost frequency will be modified as long as it is within the constraints
of RP0 and if it is different from the existing one. We will set min
freq to boost only if there is an active waiter.
Signed-off-by: Vinay Belgaumkar
---
d
Add helpers in RPS code for handling SLPC and non-SLPC cases.
When a boost is requested in the SLPC case, we can ask GuC to ramp
up the frequency by setting the minimum frequency to RP0. Reset the
frequency back to the min softlimit when there are no more waiters.
Signed-off-by: Vinay Belgaumkar
Boost frequency is initialized at RP0. Also define num_waiters
which can track the pending boost requests. This is set to 0 when
we enable SLPC.
Signed-off-by: Vinay Belgaumkar
---
drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 10 ++
drivers/gpu/drm/i915/gt/uc/intel_guc_slpc_types.
Waitboost is a legacy feature implemented in the Host Turbo algorithm. This
patch set implements it for the SLPC path. A "boost" happens when user
calls gem_wait ioctl on a submission that has not landed on HW yet. GT
frequency gets temporarily bumped to RP0 to allow the previous request
to finish
[Why]
Add DP2 MST and debugfs support
[How]
Update the slot info based on the link encoding format
Signed-off-by: Bhawanpreet Lakha
Signed-off-by: Fangzhi Zuo
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 29 +++
.../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 3 ++
.../
From: Fangzhi Zuo
Signed-off-by: Fangzhi Zuo
---
drivers/gpu/drm/amd/display/dc/core/dc.c | 14 +
drivers/gpu/drm/amd/display/dc/core/dc_link.c | 280 ++
.../gpu/drm/amd/display/dc/core/dc_link_dp.c | 19 ++
drivers/gpu/drm/amd/display/dc/dc_link.h | 7 +
drivers/
8b/10b encoding format requires to reserve the first slot for
recording metadata. Real data transmission starts from the second slot,
with a total of available 63 slots available.
In 128b/132b encoding format, metadata is transmitted separately
in LLCP packet before MTP. Real data transmission sta
This code path is used during commit, and we dont expect things to fail
during the commit stage, so remove this.
Signed-off-by: Bhawanpreet Lakha
Reviewed-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_mst_topology.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gp
On Wed, Oct 20, 2021 at 08:40:05AM -0700, Lucas De Marchi wrote:
> On Fri, Mar 26, 2021 at 06:55:03AM +0100, Christoph Hellwig wrote:
> > Add a helper that calls remap_pfn_range for an struct io_mapping, relying
> > on the pgprot pre-validation done when creating the mapping instead of
> > doing it
On Wed, Oct 20, 2021 at 08:41:24AM +0200, Christian König wrote:
> > I think the patch subject needs updating to reflect that we're disabling
> > PUD/PMDs completely.
> > With that fixed,
Everyone is OK with this?
drm/ttm: remove ttm_bo_vm_insert_huge()
The huge page functionality in TTM does n
Hi Rob,
On Mon, Oct 18, 2021 at 02:38:33PM -0500, Rob Herring wrote:
> On Mon, Oct 18, 2021 at 9:19 AM Markus Schneider-Pargmann
> wrote:
> >
> > Hi Rob,
> >
> > On Mon, Oct 11, 2021 at 07:43:16PM -0500, Rob Herring wrote:
> > > On Mon, Oct 11, 2021 at 11:46:19AM +0200, Markus Schneider-Pargmann
On 2021-10-04 4:14 a.m., Christian König wrote:
The problem is a bit different.
The callback is on the dependent fence, while we need to signal the
scheduler fence.
Daniel is right that this needs an irq_work struct to handle this
properly.
Christian.
So we had some discussions with Ch
Use __release_guc_id (lock held) rather than release_guc_id (acquires
lock), add lockdep annotations.
213.280129] i915: Running i915_perf_live_selftests/live_noa_gpr
[ 213.283459]
[ 213.283462] WARNING: possible recursive locking detected
{{[ 213.283466
Awesome! So this all looks fine to me, just some formatting changes:
On Wed, 2021-10-20 at 10:16 -0400, Bhawanpreet Lakha wrote:
> 8b/10b encoding format requires to reserve the first slot for
> recording metadata. Real data transmission starts from the second slot,
> with a total of available 63
Reviewed-by: Lyude Paul
On Wed, 2021-10-20 at 10:16 -0400, Bhawanpreet Lakha wrote:
> This code path is used during commit, and we dont expect things to fail
> during the commit stage, so remove this.
>
> Signed-off-by: Bhawanpreet Lakha
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 6 +-
Hi Rob,
On Mon, Oct 11, 2021 at 06:44:53PM -0500, Rob Herring wrote:
> On Mon, 11 Oct 2021 11:46:18 +0200, Markus Schneider-Pargmann wrote:
> > DP_INTF is a similar functional block to mediatek,dpi but is different
> > in that it serves the DisplayPort controller on mediatek SoCs and uses
> > diff
Use __release_guc_id (lock held) rather than release_guc_id (acquires
lock), add lockdep annotations.
213.280129] i915: Running i915_perf_live_selftests/live_noa_gpr
[ 213.283459]
[ 213.283462] WARNING: possible recursive locking detected
{{[ 213.283466
Hi Chun-Kuang,
On Fri, Oct 15, 2021 at 12:04:10AM +0800, Chun-Kuang Hu wrote:
> Hi, Markus:
>
> Markus Schneider-Pargmann 於 2021年10月1日 週五 下午5:44寫道：
> >
> > dpintf is the displayport interface hardware unit. This unit is similar
> > to dpi and can reuse most of the code.
> >
> > This patch adds s
Add NULL checks in KMS CRTC funcs to avoid potential NULL
dereference.
Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
Reported-by: Dan Carpenter
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c | 8
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
Change byte_clk_rate, pixel_clk_rate, esc_clk_rate, and src_clk_rate
from u32 to unsigned long, since clk_get_rate() returns an unsigned long.
Fixes: a6bcddbc2ee1 ("drm/msm: dsi: Handle dual-channel for 6G as well")
Reported-by: Dan Carpenter
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm
Following kernel crash noticed on linux next 20211020 tag.
while booting on arm64 architecture dragonboard 410c device.
I see the following config is enabled in 20211020 tag builds.
CONFIG_STACKDEPOT=y
Crash log,
[ 18.583097] Unable to handle kernel paging request at virtual
address
There are no users left of drm_bridge_chain_mode_fixup() and we
do not want to have this function available, so drop it.
Signed-off-by: Sam Ravnborg
Reviewed-by: Maxime Ripard
Cc: Laurent Pinchart
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vett
drm_atomic_get_new_crtc_for_bridge() will be used by bridge
drivers to provide easy access to the mode from the
drm_bridge_funcs operations.
The helper will be useful in the conversion to the atomic
operations of struct drm_bridge_funcs.
v2:
- Renamed to drm_atomic_get_new_crtc_for_bridge (Maxi
- deprecated callbacks in drm_bridge_funcs
- move connector creation to display drivers
v2:
- Updated descriptions in todo.rst
Signed-off-by: Sam Ravnborg
Acked-by: Maxime Ripard
Cc: Laurent Pinchart
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Danie
The atomic variants of enable/disable in drm_bridge_funcs are the
preferred operations - introduce these.
Use of mode_set is deprecated - merge the functionality with
atomic_enable()
v2:
- Added check if crtc_state is NULL (Maxime)
- Updated to use drm_atomic_get_new_crtc_for_bridge()
Signed
The mode_valid implementation had a call to
drm_bridge_chain_mode_fixup() which would be wrong as the mode_valid is
not allowed to change anything - only to validate the mode.
As the next bridge is often/always a connector the call had no effect
anyway. So drop it.
>From the git history I could s
The drm_bridge_chain_{pre_enable,enable,disable,post_disable} has no
users left and we have atomic variants that should be used.
Drop them so they do not gain new users.
Adjust a few comments to avoid references to the dropped functions.
Signed-off-by: Sam Ravnborg
Reviewed-by: Maxime Ripard
Cc
The atomic variants of enable/disable in drm_bridge_funcs are the
preferred operations - introduce these.
The ps8640 driver used the non-atomic variants of the
drm_bridge_chain_pre_enable/
drm_bridge_chain_post_disable - convert these to the atomic variants.
v2:
- Added a few more people to cc
Over time we have accumulated some deprecated functions etc. in drm_bridge.
This patch-set starts to move over to the atomic variants and deletes what
is not used anymore.
There was only one user of the non-atomic drm_bridge_chain functions in
parade-ps8640 - migrate it to the atomic variants and
Move initialization of sblk in _sspp_subblk_offset() after NULL check to
avoid potential NULL pointer dereference.
Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
Reported-by: Dan Carpenter
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 8 +---
1 file
On 18/10/2021 23:13, Andrzej Hajda wrote:
> Beside updating email, the patch updates maintainers
> of Samsung drivers.
>
> Signed-off-by: Andrzej Hajda
> ---
> .mailmap| 1 +
> MAINTAINERS | 13 -
> 2 files changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/.mailmap b/.m
Am 20.10.21 um 19:43 schrieb Alex Deucher:
On Wed, Oct 20, 2021 at 1:32 PM Christian König
wrote:
We need to cleanup the fences for ghost objects as well.
Signed-off-by: Christian König
CC:
Does this fix this bug?
https://bugzilla.kernel.org/show_bug.cgi?id=214029
Yeah, I was already addi
https://bugzilla.kernel.org/show_bug.cgi?id=214029
--- Comment #19 from Christian König (christian.koe...@amd.com) ---
Created attachment 299277
--> https://bugzilla.kernel.org/attachment.cgi?id=299277&action=edit
Potential fix
--
You may reply to this email to add a comment.
You are receivin
On Wed, Oct 20, 2021 at 1:32 PM Christian König
wrote:
>
> We need to cleanup the fences for ghost objects as well.
>
> Signed-off-by: Christian König
> CC:
Does this fix this bug?
https://bugzilla.kernel.org/show_bug.cgi?id=214029
Alex
> ---
> drivers/gpu/drm/ttm/ttm_bo_util.c | 1 +
> 1 fi
Hi,
On Wed, Oct 20, 2021 at 5:14 AM Sankeerth Billakanti
wrote:
>
> From: Sankeerth Billakanti
>
> The Qualcomm SC7280 platform supports an eDP controller, add
> compatible string for it to dp-controller.
>
> Signed-off-by: Sankeerth Billakanti
> ---
> Documentation/devicetree/bindings/display
We need to cleanup the fences for ghost objects as well.
Signed-off-by: Christian König
CC:
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 82af095f6b81..f37a8c53b35f 100644
--
https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-misc.html
gives HTTP 404, and
https://01.org/linuxgraphics/gfx-docs/maintainer-tools/ redirects to
freedesktop.org now.
Let's save people the pain of figuring that out.
Signed-off-by: Brian Norris
Reviewed-by: Sean Paul
---
Changes in
On Tue, Oct 19, 2021 at 5:59 PM Brian Norris wrote:
>
> https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html gives
> HTTP 404, and https://drm.pages.freedesktop.org/maintainer-tools/
> redirects to freedesktop.org now.
With a dash of irony, I actually listed the wrong URLs in the
desc
On Wed, Oct 20, 2021 at 10:09 AM Joao Martins wrote:
>
> On 10/19/21 20:21, Dan Williams wrote:
> > On Tue, Oct 19, 2021 at 9:02 AM Jason Gunthorpe wrote:
> >>
> >> On Tue, Oct 19, 2021 at 04:13:34PM +0100, Joao Martins wrote:
> >>> On 10/19/21 00:06, Jason Gunthorpe wrote:
> On Mon, Oct 18,
This reverts commit b3484d2b03e4c940a9598aa841a52d69729c582a.
That change attempted to improve the DRM drivers fbdev emulation device
names to avoid having confusing names like "simpledrmdrmfb" in /proc/fb.
But unfortunately, there are user-space programs such as pm-utils that
match against the f
Hello Daniel,
On 10/13/21 14:27, Daniel Vetter wrote:
>>>
>>> info->par = fb_helper;
>>> - snprintf(info->fix.id, sizeof(info->fix.id), "%s",
>
> Please add a comment here that drmfb is uapi because pm-utils matches
> against it ...
>
Sure, I'll do that and send a v2.
Best regards,
--
Allow the standard rotation property from panel-common for ILI9881C
based panels.
Signed-off-by: John Keeping
---
.../devicetree/bindings/display/panel/ilitek,ili9881c.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git
a/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.
Support the "rotation" DT property for ILI9881C based panels.
The first patch is a fix for the binding, then the usual binding update
followed by the corresponding driver update.
John Keeping (3):
dt-bindings: ili9881c: add missing panel-common inheritance
dt-bindings: ili9881c: add rotation
The panel orientation needs to parsed from a device-tree and assigned to
the panel's connector in order to make orientation property available to
userspace. That's what this patch does for ILI9881C based panels.
Signed-off-by: John Keeping
---
drivers/gpu/drm/panel/panel-ilitek-ili9881c.c | 11 +
The properties below refer to items in panel-common.yaml, which means
that needs to be referenced in the schema.
Signed-off-by: John Keeping
---
.../devicetree/bindings/display/panel/ilitek,ili9881c.yaml | 3 +++
1 file changed, 3 insertions(+)
diff --git
a/Documentation/devicetree/binding
On Fri, Mar 26, 2021 at 06:55:03AM +0100, Christoph Hellwig wrote:
Add a helper that calls remap_pfn_range for an struct io_mapping, relying
on the pgprot pre-validation done when creating the mapping instead of
doing it at runtime.
Signed-off-by: Christoph Hellwig
---
include/linux/io-mapping.
https://bugzilla.kernel.org/show_bug.cgi?id=214621
Erhard F. (erhar...@mailbox.org) changed:
What|Removed |Added
Status|NEW |RESOLVED
Resol
https://bugzilla.kernel.org/show_bug.cgi?id=213983
--- Comment #2 from Erhard F. (erhar...@mailbox.org) ---
*** Bug 214621 has been marked as a duplicate of this bug. ***
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the b
On Mon, 2021-10-18 at 18:45 +0100, Matthew Auld wrote:
> While the pages can't be swapped out, they can be discarded by the
> shrinker.
> Normally such objects are marked with __I915_MADV_PURGED, which can't
> be
> unset, and therefore requires a new object. For kernel internal
> objects
> this is
On Mon, 2021-10-18 at 18:45 +0100, Matthew Auld wrote:
> Just like we do for internal objects. Also just use
> i915_gem_object_set_cache_coherency() here. No need for over-flushing
> on
> LLC platforms.
>
> Signed-off-by: Matthew Auld
> Cc: Thomas Hellström
> ---
> drivers/gpu/drm/i915/gem/self
On 10/18/21 19:45, Matthew Auld wrote:
Add some details around non-LLC platforms and cflushing, when dealing
with the flush-on-acquire, which is potentially security sensitive.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Daniel Vetter
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.
On 10/18/21 19:45, Matthew Auld wrote:
On non-LLC platforms, force the flush-on-acquire if this is ever
swapped-in. Our async flush path is not trust worthy enough yet(and
happens in the wrong order), and with some tricks it's conceivable for
userspace to change the cache-level to I915_CACHE_NO
On 10/18/21 19:45, Matthew Auld wrote:
Even though userptr objects are always coherent with the GPU, with no
way for userspace to change this with the set_caching ioctl, even on
non-LLC platforms, there is still the 'Bypass LCC' mocs setting, which
might permit reading the contents of main memo
https://bugzilla.kernel.org/show_bug.cgi?id=211425
Andreas (icedragon...@web.de) changed:
What|Removed |Added
Kernel Version|5.14.6 |5.14.13
--- Comment #22 f
On Mon, 2021-10-18 at 18:45 +0100, Matthew Auld wrote:
> As pointed out by Thomas, we likely need to flush the pages here if
> the
> GPU can read the page contents directly from main memory. Underneath
> we
> don't know what the sg_table is pointing to, so just add a
> wbinvd_on_all_cpus() here, fo
On Mon, 2021-10-18 at 18:45 +0100, Matthew Auld wrote:
> It looks like we will need this in some more places, so extract as a
> helper.
>
> Signed-off-by: Matthew Auld
> Cc: Thomas Hellström
> ---
> drivers/gpu/drm/i915/gem/i915_gem_object.c | 26
> ++
> drivers/gpu/drm/i915
On Mon, 2021-10-18 at 18:45 +0100, Matthew Auld wrote:
> These are userspace objects, so mark them as such. In a later patch
> it's
> useful to determine how paranoid we need to be when managing cache
> flushes. In theory no functional changes.
>
> Signed-off-by: Matthew Auld
> Cc: Thomas Hellstr
On Mon, 2021-10-18 at 18:45 +0100, Matthew Auld wrote:
> These are userspace objects, so mark them as such. In a later patch
> it's
> useful to determine how paranoid we need to be when managing cache
> flushes. In theory no functional changes.
>
> Signed-off-by: Matthew Auld
> Cc: Thomas Hellstr
On Mon, 2021-10-18 at 10:10 +0100, Matthew Auld wrote:
> We currently just evict lmem objects to system memory when under
> memory
> pressure. For this case we might lack the usual object mm.pages,
> which
> effectively hides the pages from the i915-gem shrinker, until we
> actually "attach" the TT
From: Fangzhi Zuo
Signed-off-by: Fangzhi Zuo
---
drivers/gpu/drm/amd/display/dc/core/dc.c | 14 +
drivers/gpu/drm/amd/display/dc/core/dc_link.c | 280 ++
.../gpu/drm/amd/display/dc/core/dc_link_dp.c | 19 ++
drivers/gpu/drm/amd/display/dc/dc_link.h | 7 +
drivers/
This code path is used during commit, and we dont expect things to fail
during the commit stage, so remove this.
Signed-off-by: Bhawanpreet Lakha
---
drivers/gpu/drm/drm_dp_mst_topology.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology
[Why]
Add DP2 MST and debugfs support
[How]
Update the slot info based on the link encoding format
Signed-off-by: Bhawanpreet Lakha
Signed-off-by: Fangzhi Zuo
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 29 +++
.../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 3 ++
.../
1 - 100 of 128 matches
Mail list logo
