Re: [PATCH 1/2] drm/bridge: parade-ps8640: Use regmap APIs

Quoting Philip Chen (2021-09-08 11:18:05) > diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c > b/drivers/gpu/drm/bridge/parade-ps8640.c > index 685e9c38b2db..a16725dbf912 100644 > --- a/drivers/gpu/drm/bridge/parade-ps8640.c > +++ b/drivers/gpu/drm/bridge/parade-ps8640.c > @@ -64,12 +65,29 @@ s

Re: [PATCH 2/2] drm/bridge: parade-ps8640: Add support for AUX channel

Quoting Philip Chen (2021-09-08 11:18:06) > diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c > b/drivers/gpu/drm/bridge/parade-ps8640.c > index a16725dbf912..3f0241a60357 100644 > --- a/drivers/gpu/drm/bridge/parade-ps8640.c > +++ b/drivers/gpu/drm/bridge/parade-ps8640.c > @@ -93,6 +115,102 @@

Re: [PATCH 1/2] drm/nouveau/ga102-: support ttm buffer moves via copy engine

On Thu, 9 Sept 2021 at 04:19, Daniel Vetter wrote: > > On Mon, Sep 06, 2021 at 10:56:27AM +1000, Ben Skeggs wrote: > > From: Ben Skeggs > > > > We don't currently have any kind of real acceleration on Ampere GPUs, > > but the TTM memcpy() fallback paths aren't really designed to handle > > copies

Re: [PATCH v3 06/16] ARM: configs: Everyone who had PANEL_SIMPLE now gets PANEL_SIMPLE_EDP

Hi, On Fri, Sep 3, 2021 at 1:38 PM Stephen Boyd wrote: > > Quoting Doug Anderson (2021-09-01 16:10:15) > > Hi, > > > > On Wed, Sep 1, 2021 at 2:12 PM Olof Johansson wrote: > > > > > > On Wed, Sep 1, 2021 at 1:20 PM Douglas Anderson > > > wrote: > > > > > > > > In the patch ("drm/panel-simple-e

[PATCH v3 0/8] Implement generic cc_platform_has() helper function

This patch series provides a generic helper function, cc_platform_has(), to replace the sme_active(), sev_active(), sev_es_active() and mem_encrypt_active() functions. It is expected that as new confidential computing technologies are added to the kernel, they can all be covered by a single functi

[PATCH v3 1/8] x86/ioremap: Selectively build arch override encryption functions

In prep for other uses of the cc_platform_has() function besides AMD's memory encryption support, selectively build the AMD memory encryption architecture override functions only when CONFIG_AMD_MEM_ENCRYPT=y. These functions are: - early_memremap_pgprot_adjust() - arch_memremap_can_ram_remap() Ad

[PATCH v3 2/8] mm: Introduce a function to check for confidential computing features

In prep for other confidential computing technologies, introduce a generic helper function, cc_platform_has(), that can be used to check for specific active confidential computing attributes, like memory encryption. This is intended to eliminate having to add multiple technology-specific checks to

[PATCH v3 3/8] x86/sev: Add an x86 version of cc_platform_has()

Introduce an x86 version of the cc_platform_has() function. This will be used to replace vendor specific calls like sme_active(), sev_active(), etc. Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Cc: Dave Hansen Cc: Andy Lutomirski Cc: Peter Zijlstra Co-developed-by: Andi Kleen Sig

[PATCH v3 4/8] powerpc/pseries/svm: Add a powerpc version of cc_platform_has()

Introduce a powerpc version of the cc_platform_has() function. This will be used to replace the powerpc mem_encrypt_active() implementation, so the implementation will initially only support the CC_ATTR_MEM_ENCRYPT attribute. Cc: Michael Ellerman Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Si

[PATCH v3 5/8] x86/sme: Replace occurrences of sme_active() with cc_platform_has()

Replace uses of sme_active() with the more generic cc_platform_has() using CC_ATTR_HOST_MEM_ENCRYPT. If future support is added for other memory encryption technologies, the use of CC_ATTR_HOST_MEM_ENCRYPT can be updated, as required. This also replaces two usages of sev_active() that are really g

[PATCH v3 6/8] x86/sev: Replace occurrences of sev_active() with cc_platform_has()

Replace uses of sev_active() with the more generic cc_platform_has() using CC_ATTR_GUEST_MEM_ENCRYPT. If future support is added for other memory encryption technologies, the use of CC_ATTR_GUEST_MEM_ENCRYPT can be updated, as required. Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Cc

[PATCH v3 7/8] x86/sev: Replace occurrences of sev_es_active() with cc_platform_has()

Replace uses of sev_es_active() with the more generic cc_platform_has() using CC_ATTR_GUEST_STATE_ENCRYPT. If future support is added for other memory encyrption techonologies, the use of CC_ATTR_GUEST_STATE_ENCRYPT can be updated, as required. Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Pe

[PATCH v3 8/8] treewide: Replace the use of mem_encrypt_active() with cc_platform_has()

Replace uses of mem_encrypt_active() with calls to cc_platform_has() with the CC_ATTR_MEM_ENCRYPT attribute. Remove the implementation of mem_encrypt_active() across all arches. For s390, since the default implementation of the cc_platform_has() matches the s390 implementation of mem_encrypt_acti

Re: [PATCH v3 06/16] ARM: configs: Everyone who had PANEL_SIMPLE now gets PANEL_SIMPLE_EDP

On Wed, Sep 8, 2021 at 3:36 PM Doug Anderson wrote: > > Hi, > > On Fri, Sep 3, 2021 at 1:38 PM Stephen Boyd wrote: > > > > Quoting Doug Anderson (2021-09-01 16:10:15) > > > Hi, > > > > > > On Wed, Sep 1, 2021 at 2:12 PM Olof Johansson wrote: > > > > > > > > On Wed, Sep 1, 2021 at 1:20 PM Douglas

Re: [PATCH v5 25/25] drm/i915/guc: Add GuC kernel doc

On 9/3/2021 12:59, Daniele Ceraolo Spurio wrote: From: Matthew Brost Add GuC kernel doc for all structures added thus far for GuC submission and update the main GuC submission section with the new interface details. v2: - Drop guc_active.lock DOC v3: - Fixup a few kernel doc comments (Dani

Re: [PATCH v5 11/16] drm/mediatek: add display MDP RDMA support for MT8195

Hi, Nancy: Nancy.Lin 於 2021年9月6日 週一 下午3:15寫道： > > Add MDP_RDMA driver for MT8195. MDP_RDMA is the DMA engine of > the ovl_adaptor component. > > Signed-off-by: Nancy.Lin > --- > drivers/gpu/drm/mediatek/Makefile | 3 +- > drivers/gpu/drm/mediatek/mtk_disp_drv.h | 7 + > drivers/gpu/dr

Re: [PATCH v3 03/16] drm/edid: Allow the querying/working with the panel ID from the EDID

Hi, On Mon, Sep 6, 2021 at 3:05 AM Jani Nikula wrote: > > > +{ > > + struct edid *edid; > > + u32 val; > > + > > + edid = drm_do_get_edid_blk0(drm_do_probe_ddc_edid, adapter, NULL, > > NULL); > > + > > + /* > > + * There are no manufacturer IDs of 0, so if there is a problem

Re: [PATCH v3 00/16] eDP: Support probing eDP panels dynamically instead of hardcoding

Hi, On Sun, Sep 5, 2021 at 11:55 AM Sam Ravnborg wrote: > > Hi Douglas, > > On Wed, Sep 01, 2021 at 01:19:18PM -0700, Douglas Anderson wrote: > > The goal of this patch series is to move away from hardcoding exact > > eDP panels in device tree files. As discussed in the various patches > > in thi

[PATCH 4/4] drm/i915: deduplicate frequency dump on debugfs

Although commit 9dd4b065446a ("drm/i915/gt: Move pm debug files into a gt aware debugfs") says it was moving debug files to gt/, the i915_frequency_info file was left behind and its implementation copied into drivers/gpu/drm/i915/gt/debugfs_gt_pm.c. Over time we had several patches having to change

[PATCH 2/4] drm/i915: rename debugfs_engines files

We shouldn't be using debugfs_ namespace for this functionality. Rename debugfs_engines.[ch] to intel_gt_engines_debugfs.[ch] and then make functions, defines and structs follow suit. Signed-off-by: Lucas De Marchi --- drivers/gpu/drm/i915/Makefile | 2 +- drivers/gpu/drm/i

[PATCH 3/4] drm/i915: rename debugfs_gt_pm files

We shouldn't be using debugfs_ namespace for this functionality. Rename debugfs_gt_pm.[ch] to intel_gt_pm_debugfs.[ch] and then make functions, defines and structs follow suit. Signed-off-by: Lucas De Marchi --- drivers/gpu/drm/i915/Makefile | 2 +- drivers/gpu/drm/i915/gt/

[PATCH 1/4] drm/i915: rename debugfs_gt files

We shouldn't be using debugfs_ namespace for this functionality. Rename debugfs_gt.[ch] to intel_gt_debugfs.[ch] and then make functions, defines and structs follow suit. While at it and since we are renaming the header, sort the includes alphabetically. Signed-off-by: Lucas De Marchi --- drive

[PATCH v2] drm/plane-helper: fix uninitialized variable reference

drivers/gpu/drm/drm_plane_helper.c: In function 'drm_primary_helper_update': drivers/gpu/drm/drm_plane_helper.c:113:32: error: 'visible' is used uninitialized [-Werror=uninitialized] 113 | struct drm_plane_state plane_state = { |^~~ drivers/g

[PATCH v1 01/12] virtio-gpu api: multiple context types with explicit initialization

This feature allows for each virtio-gpu 3D context to be created with a "context_init" variable. This variable can specify: - the type of protocol used by the context via the capset id. This is useful for differentiating virgl, gfxstream, and venus protocols by host userspace. - other th

[PATCH v1 00/12] Context types

Version 1 of context types: https://lists.oasis-open.org/archives/virtio-dev/202108/msg00141.html Changes since RFC: * le32 info --> {u8 ring_idx + u8 padding[3]). * Max rings is now 64. Anthoine Bourgeois (2): drm/virtio: implement context init: probe for feature drm/virtio: implement

[PATCH v1 02/12] drm/virtgpu api: create context init feature

This change allows creating contexts of depending on set of context parameters. The meaning of each of the parameters is listed below: 1) VIRTGPU_CONTEXT_PARAM_CAPSET_ID This determines the type of a context based on the capability set ID. For example, the current capsets: VIRTIO_GPU_CAPSET_VI

[PATCH v1 03/12] drm/virtio: implement context init: track valid capabilities in a mask

The valid capability IDs are between 1 to 63, and defined in the virtio gpu spec. This is used for error checking the subsequent patches. We're currently only using 2 capability IDs, so this should be plenty for the immediate future. Signed-off-by: Gurchetan Singh Acked-by: Lingfeng Yang ---

[PATCH v1 04/12] drm/virtio: implement context init: probe for feature

From: Anthoine Bourgeois Let's probe for VIRTIO_GPU_F_CONTEXT_INIT. Create a new DRM_INFO(..) line since the current one is getting too long. Signed-off-by: Anthoine Bourgeois Acked-by: Lingfeng Yang --- drivers/gpu/drm/virtio/virtgpu_debugfs.c | 1 + drivers/gpu/drm/virtio/virtgpu_drv.c

[PATCH v1 06/12] drm/virtio: implement context init: track {ring_idx, emit_fence_info} in virtio_gpu_fence

Each fence should be associated with a [fence ID, fence_context, seqno]. The seqno number is just the fence id. To get the fence context, we add the ring_idx to the 3D context's base_fence_ctx. The ring_idx is between 0 and 31, inclusive. Each 3D context will have it's own base_fence_ctx. The r

[PATCH v1 07/12] drm/virtio: implement context init: plumb {base_fence_ctx, ring_idx} to virtio_gpu_fence_alloc

These were defined in the previous commit. We'll need these parameters when allocating a dma_fence. The use case for this is multiple synchronizations timelines. The maximum number of timelines per 3D instance will be 32. Usually, only 2 are needed -- one for CPU commands, and another for GPU com

[PATCH v1 08/12] drm/virtio: implement context init: stop using drv->context when creating fence

The plumbing is all here to do this. Since we always use the default fence context when allocating a fence, this makes no functional difference. We can't process just the largest fence id anymore, since it's it's associated with different timelines. It's fine for fence_id 260 to signal before 25

[PATCH v1 05/12] drm/virtio: implement context init: support init ioctl

From: Anthoine Bourgeois This implements the context initialization ioctl. A list of params is passed in by userspace, and kernel driver validates them. The only currently supported param is VIRTGPU_CONTEXT_PARAM_CAPSET_ID. If the context has already been initialized, -EEXIST is returned. This

[PATCH v1 09/12] drm/virtio: implement context init: allocate an array of fence contexts

We don't want fences from different 3D contexts (virgl, gfxstream, venus) to be on the same timeline. With explicit context creation, we can specify the number of ring each context wants. Execbuffer can specify which ring to use. Signed-off-by: Gurchetan Singh Acked-by: Lingfeng Yang --- driv

[PATCH v1 10/12] drm/virtio: implement context init: handle VIRTGPU_CONTEXT_PARAM_POLL_RINGS_MASK

For the Sommelier guest Wayland proxy, it's desirable for the DRM fd to be pollable in response to an host compositor event. This can also be used by the 3D driver to poll events on a CPU timeline. This enables the DRM fd associated with a particular 3D context to be polled independent of KMS even

[PATCH v1 11/12] drm/virtio: implement context init: add virtio_gpu_fence_event

Similar to DRM_VMW_EVENT_FENCE_SIGNALED. Sends a pollable event to the DRM file descriptor when a fence on a specific ring is signaled. One difference is the event is not exposed via the UAPI -- this is because host responses are on a shared memory buffer of type BLOB_MEM_GUEST [this is the commo

[PATCH v1 12/12] drm/virtio: implement context init: advertise feature to userspace

This advertises the context init feature to userspace, along with a mask of supported capabilities. Signed-off-by: Gurchetan Singh Acked-by: Lingfeng Yang --- drivers/gpu/drm/virtio/virtgpu_ioctl.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c

[PATCH AUTOSEL 5.14 001/252] drm/bridge: ti-sn65dsi86: Don't read EDID blob over DDC

From: Douglas Anderson [ Upstream commit a70e558c151043ce46a5e5999f4310e0b3551f57 ] This is really just a revert of commit 58074b08c04a ("drm/bridge: ti-sn65dsi86: Read EDID blob over DDC"), resolving conflicts. The old code failed to read the EDID properly in a very important case: before the

[PATCH AUTOSEL 5.14 002/252] drm/vmwgfx: Fix subresource updates with new contexts

From: Zack Rusin [ Upstream commit a12be0277316ed923411c9c80b2899ee74d2b033 ] The has_dx variable was only set during the initialization which meant that UPDATE_SUBRESOURCE was never used. We were emulating it with UPDATE_GB_IMAGE but that's always been a stop-gap. Instead of has_dx which has be

[PATCH AUTOSEL 5.14 003/252] drm/vmwgfx: Fix some static checker warnings

From: Zack Rusin [ Upstream commit 74231041d14030f1ae6582b9233bfe782ac23e33 ] Fix some minor issues that Coverity spotted in the code. None of that are serious but they're all valid concerns so fixing them makes sense. Signed-off-by: Zack Rusin Reviewed-by: Roland Scheidegger Reviewed-by: Mar

[PATCH AUTOSEL 5.14 004/252] drm/vc4: hdmi: Set HD_CTL_WHOLSMP and HD_CTL_CHALIGN_SET

From: Dom Cobley [ Upstream commit 1698ecb218eb82587dbfc71a2e26ded66e5ecf59 ] Symptom is random switching of speakers when using multichannel. Repeatedly running speakertest -c8 occasionally starts with channels jumbled. This is fixed with HD_CTL_WHOLSMP. The other bit looks beneficial and ape

[PATCH AUTOSEL 5.14 005/252] drm/ttm: Fix multihop assert on eviction.

From: Andrey Grodzovsky [ Upstream commit 403797925768d9fa870f5b1ebcd20016b397083b ] Problem: Under memory pressure when GTT domain is almost full multihop assert will come up when trying to evict LRU BO from VRAM to SYSTEM. Fix: Don't assert on multihop error in evict code but rather do a retr

[PATCH AUTOSEL 5.14 006/252] drm/omap: Follow implicit fencing in prepare_fb

From: Daniel Vetter [ Upstream commit 942d8344d5f14b9ea2ae43756f319b9f44216ba4 ] I guess no one ever tried running omap together with lima or panfrost, not even sure that's possible. Anyway for consistency, fix this. Reviewed-by: Tomi Valkeinen Signed-off-by: Daniel Vetter Cc: Tomi Valkeinen

[PATCH AUTOSEL 5.14 007/252] drm/amdgpu: Fix amdgpu_ras_eeprom_init()

From: Luben Tuikov [ Upstream commit dce4400e6516d18313d23de45b5be8a18980b00e ] No need to account for the 2 bytes of EEPROM address--this is now well abstracted away by the fixes the the lower layers. Cc: Andrey Grodzovsky Cc: Alexander Deucher Signed-off-by: Luben Tuikov Acked-by: Alexande

[PATCH AUTOSEL 5.14 009/252] drm: vc4: Fix pixel-wrap issue with DVP teardown

From: Tim Gover [ Upstream commit 0b066a6809d0f8fd9868e383add36aa5a2fa409d ] Adjust the DVP enable/disable sequence to avoid a pixel getting stuck in an internal, non resettable FIFO within PixelValve when changing HDMI resolution. The blank pixels features of the DVP can prevent signals back t

[PATCH AUTOSEL 5.14 008/252] drm/amdgpu: Fix koops when accessing RAS EEPROM

From: Luben Tuikov [ Upstream commit 1d9d2ca85b32605ac9c74c8fa42d0c1cfbe019d4 ] Debugfs RAS EEPROM files are available when the ASIC supports RAS, and when the debugfs is enabled, an also when "ras_enable" module parameter is set to 0. However in this case, we get a kernel oops when accessing so

[PATCH AUTOSEL 5.14 010/252] dma-buf: fix dma_resv_test_signaled test_all handling v2

From: Christian König [ Upstream commit 9d38814d1e346ea37a51cbf31f4424c9d059459e ] As the name implies if testing all fences is requested we should indeed test all fences and not skip the exclusive one because we see shared ones. v2: fix logic once more Signed-off-by: Christian König Reviewed

[PATCH] dma-buf: system_heap: Avoid warning on mid-order allocations

When trying to do mid-order allocations, set __GFP_NOWARN to avoid warning messages if the allocation fails, as we will still fall back to single page allocatitions in that case. This is the similar to what we already do for large order allocations. Cc: Daniel Vetter Cc: Christian Koenig Cc: Sum

Re: [PULL] drm-misc-fixes

On Thu, 9 Sept 2021 at 03:44, Thomas Zimmermann wrote: > > Hi Dave and Daniel, > > here's this week's PR for drm-misc-fixes. One patch is a potential deadlock > in TTM, the other enables an additional plane in kmb. I'm slightly unhappy > that the latter one ended up in -fixes as it's not a bugfix

[Bug 213917] Screen starts flickering when laptop(amdgpu) wakes up after suspend.

https://bugzilla.kernel.org/show_bug.cgi?id=213917 Samuel Sieb (samuel-kb...@sieb.net) changed: What|Removed |Added CC||samuel-kb...@sieb.ne

Re: [PATCH v1 03/14] mm: add iomem vma selection for memory migration

Am 2021-09-02 um 4:18 a.m. schrieb Christoph Hellwig: > On Wed, Sep 01, 2021 at 11:40:43AM -0400, Felix Kuehling wrote: > It looks like I'm totally misunderstanding what you are adding here > then. Why do we need any special treatment at all for memory that > has normal struct pages an

[PATCH v2 0/2] drm/panel: Add support for LG.Philips SW43101 DSI video mode panel

This adds a driver for the LG.Philips SW43101 FHD (1080x1920) 58Hz OLED DSI video mode panel, found on the Xiaomi Mi Note 2. Changes since v1: - Add regulator support. - Add MAINTAINERS entry. - Dual-license DT binding. Yassine Oudjana (2): drm/panel: Add driver for LG.Philips SW43101 DSI vi

[PATCH v2 1/2] drm/panel: Add driver for LG.Philips SW43101 DSI video mode panel

Add a driver for the LG.Philips SW43101 FHD (1080x1920) OLED DSI video mode panel. This driver has been generated using linux-mdss-dsi-panel-driver-generator. Signed-off-by: Yassine Oudjana --- Changes since v1: - Add regulator support. - Add MAINTAINERS entry. MAINTAINERS

[PATCH v2 2/2] dt-bindings: display: Add binding for LG.Philips SW43101

Add a device tree binding for LG.Philips SW43101. Signed-off-by: Yassine Oudjana --- Changes since v1: - Add regulator support. - Add MAINTAINERS entry. - Dual-license DT binding. .../display/panel/lgphilips,sw43101.yaml | 75 +++ MAINTAINERS

Re: [PATCH v1 03/14] mm: add iomem vma selection for memory migration

Am 2021-09-01 um 9:14 p.m. schrieb Dave Chinner: > On Wed, Sep 01, 2021 at 07:07:34PM -0400, Felix Kuehling wrote: >> On 2021-09-01 6:03 p.m., Dave Chinner wrote: >>> On Wed, Sep 01, 2021 at 11:40:43AM -0400, Felix Kuehling wrote: Am 2021-09-01 um 4:29 a.m. schrieb Christoph Hellwig: > On

Re: [PATCH] drm/amd/amdkfd: fix possible memory leak in svm_range_restore_pages

Hi Xiyu Yang, This bug was already fixed by this commit: https://gitlab.freedesktop.org/agd5f/linux/-/commit/598a118db0d85a432f8cd541a6a5d31e31c56b6b Regards,  Felix Am 2021-09-09 um 12:27 a.m. schrieb Xiyu Yang: > The memory leak issue may take place in an error handling path. When > p->xnack_

Re: [PATCH] kernel/locking: Add context to ww_mutex_trylock.

Op 08-09-2021 om 12:14 schreef Peter Zijlstra: > On Tue, Sep 07, 2021 at 03:20:44PM +0200, Maarten Lankhorst wrote: >> i915 will soon gain an eviction path that trylock a whole lot of locks >> for eviction, getting dmesg failures like below: >> >> BUG: MAX_LOCK_DEPTH too low! >> turning off the loc

Re: [PATCH v3 4/9] drm/scheduler: Add fence deadline support

Am 08.09.21 um 19:45 schrieb Daniel Vetter: On Fri, Sep 03, 2021 at 11:47:55AM -0700, Rob Clark wrote: From: Rob Clark As the finished fence is the one that is exposed to userspace, and therefore the one that other operations, like atomic update, would block on, we need to propagate the deadli

Re: [PATCH v3 7/9] dma-buf/fence-chain: Add fence deadline support

Am 08.09.21 um 20:45 schrieb Daniel Vetter: On Wed, Sep 08, 2021 at 11:19:15AM -0700, Rob Clark wrote: On Wed, Sep 8, 2021 at 10:54 AM Daniel Vetter wrote: On Fri, Sep 03, 2021 at 11:47:58AM -0700, Rob Clark wrote: From: Rob Clark Signed-off-by: Rob Clark --- drivers/dma-buf/dma-fence-ch

Re: [PATCH v3 6/9] dma-buf/fence-array: Add fence deadline support

Am 08.09.21 um 20:00 schrieb Daniel Vetter: On Fri, Sep 03, 2021 at 11:47:57AM -0700, Rob Clark wrote: From: Rob Clark Signed-off-by: Rob Clark --- drivers/dma-buf/dma-fence-array.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/drivers/dma-buf/dma-fence-array.c b/driver

<    1   2