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
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
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
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
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_
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
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
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
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
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
https://bugzilla.kernel.org/show_bug.cgi?id=213917
Samuel Sieb (samuel-kb...@sieb.net) changed:
What|Removed |Added
CC||samuel-kb...@sieb.ne
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
---
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
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
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
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
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
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/
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 @@
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
x27;m confused because I'm not even seeing this function anywhere in
upstream.
It is still here:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/gpu/drm/mxsfb/mxsfb_drv.c#n171
as of:
999569d59a0aa ("Add linux-next specific files for 20210908")
Is there some other tree I should be looking at ?
W dniu 08.09.2021 o 13:11, Dave Stevenson pisze:
> Hi Marek and Andrzej
>
> On Tue, 7 Sept 2021 at 22:24, Marek Vasut wrote:
>> On 9/7/21 7:29 PM, Andrzej Hajda wrote:
>>> W dniu 07.09.2021 o 16:25, Marek Vasut pisze:
On 9/7/21 9:31 AM, Andrzej Hajda wrote:
> On 07.09.2021 04:39, Marek
Hi,
On Sun, Sep 5, 2021 at 11:46 AM Sam Ravnborg wrote:
>
> On Wed, Sep 01, 2021 at 01:19:28PM -0700, Douglas Anderson wrote:
> > All of the "HPD" handling added to panel-simple recently was for eDP
> > panels. Remove it from panel-simple now that panel-simple-edp handles
> > eDP panels. The "pre
On Wed, Sep 8, 2021 at 9:36 PM Rob Clark wrote:
> On Wed, Sep 8, 2021 at 11:49 AM Daniel Vetter wrote:
> > On Wed, Sep 08, 2021 at 11:23:42AM -0700, Rob Clark wrote:
> > > On Wed, Sep 8, 2021 at 10:50 AM Daniel Vetter wrote:
> > > >
> > > > On Fri, Sep 03, 2021 at 11:47:59AM -0700, Rob Clark wro
On Wed, Sep 08, 2021 at 11:07:07AM +0100, Tvrtko Ursulin wrote:
>
> On 07/09/2021 18:19, Matt Roper wrote:
> > The reset domain is shared between render and all compute engines,
> > so resetting one will affect the others.
> >
> > Note: Before performing a reset on an RCS or CCS engine, the GuC
On Wed, Sep 8, 2021 at 11:49 AM Daniel Vetter wrote:
>
> On Wed, Sep 08, 2021 at 11:23:42AM -0700, Rob Clark wrote:
> > On Wed, Sep 8, 2021 at 10:50 AM Daniel Vetter wrote:
> > >
> > > On Fri, Sep 03, 2021 at 11:47:59AM -0700, Rob Clark wrote:
> > > > From: Rob Clark
> > > >
> > > > The initial
tree: git://people.freedesktop.org/~airlied/linux.git i915-uncore-vfunc
head: b42168f90718a90b11f2d52306d9aeaa9468
commit: 99aebd17891290abfca80c48eca01f4e02413fb3 [30/31] drm/i915/uncore:
constify the register vtables.
config: i386-allyesconfig (attached as .config)
compiler: gcc-9 (Debia
Hi Thomas,
On Wed, Sep 08, 2021 at 07:50:42PM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 03.08.21 um 07:10 schrieb Sam Ravnborg:
> > Hi Anitha,
> >
> > On Mon, Aug 02, 2021 at 08:44:26PM +, Chrisanthus, Anitha wrote:
> > > Hi Sam,
> > > Thanks. Where should this go, drm-misc-fixes or drm-mi
nvkm test builds fail with the following error.
drivers/gpu/drm/nouveau/nvkm/engine/device/ctrl.c:
In function 'nvkm_control_mthd_pstate_info':
drivers/gpu/drm/nouveau/nvkm/engine/device/ctrl.c:60:35: error:
overflow in conversion from 'int' to '__s8' {aka 'signed char'}
Disabling interrupts and invoking the irq_work function directly breaks
on PREEMPT_RT.
PREEMPT_RT does not invoke all irq_work from hardirq context because
some of the user have spinlock_t locking in the callback function.
These locks are then turned into a sleeping locks which can not be
acquired
execlists_dequeue() is invoked from a function which uses
local_irq_disable() to disable interrupts so the spin_lock() behaves
like spin_lock_irq().
This breaks PREEMPT_RT because local_irq_disable() + spin_lock() is not
the same as spin_lock_irq().
execlists_dequeue_irq() and execlists_dequeue()
Clark Williams reported two issues with the i915 driver running on
PREEMPT_RT. While #1 looks simple I have no idea about #2 thus the RFC.
Sebastian
On Wed, Sep 08, 2021 at 11:23:42AM -0700, Rob Clark wrote:
> On Wed, Sep 8, 2021 at 10:50 AM Daniel Vetter wrote:
> >
> > On Fri, Sep 03, 2021 at 11:47:59AM -0700, Rob Clark wrote:
> > > From: Rob Clark
> > >
> > > The initial purpose is for igt tests, but this would also be useful for
> > > comp
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-chain.c | 13
On Tue, Sep 07, 2021 at 10:08:36AM -0400, Alex Xu (Hello71) wrote:
> 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 p
On Wed, Sep 08, 2021 at 12:14:23PM +0200, Peter Zijlstra wrote:
> 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!
On Tue, Sep 07, 2021 at 11:28:23AM +0200, Christian König wrote:
> Am 07.09.21 um 11:05 schrieb Daniel Vetter:
> > On Tue, Sep 07, 2021 at 08:22:20AM +0200, Christian König wrote:
> > > Added a Fixes tag and pushed this to drm-misc-fixes.
> > We're in the merge window, this should have been drm-mis
On Tue, Sep 07, 2021 at 04:49:00AM +0200, Marek Vasut wrote:
> The mxsfb->crtc.funcs may already be NULL when unloading the driver,
> in which case calling mxsfb_irq_disable() via drm_irq_uninstall() from
> mxsfb_unload() leads to NULL pointer dereference.
>
> Since all we care about is masking th
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 between different devices, such as on Optimus systems, and
> res
On Wed, Sep 8, 2021 at 10:50 AM Daniel Vetter wrote:
>
> On Fri, Sep 03, 2021 at 11:47:59AM -0700, Rob Clark wrote:
> > From: Rob Clark
> >
> > The initial purpose is for igt tests, but this would also be useful for
> > compositors that wait until close to vblank deadline to make decisions
> > ab
Implement the first version of AUX support, which will be useful as
we expand the driver to support varied use cases.
Signed-off-by: Philip Chen
---
drivers/gpu/drm/bridge/parade-ps8640.c | 123 +
1 file changed, 123 insertions(+)
diff --git a/drivers/gpu/drm/bridge/par
Replace the direct i2c access (i2c_smbus_* functions) with regmap APIs,
which will simplify the future update on ps8640 driver.
Signed-off-by: Philip Chen
---
drivers/gpu/drm/bridge/parade-ps8640.c | 66 +++---
1 file changed, 39 insertions(+), 27 deletions(-)
diff --git a/
On Sun, Sep 05, 2021 at 01:27:42PM +0100, Daniel Stone wrote:
> Since there's a lot of confusion around this, document both the rules
> and the best practice around negotiating, allocating, importing, and
> using buffers when crossing context/process/device/subsystem boundaries.
>
> This ties up a
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-chain.c | 13 +
> > 1 file changed, 13 insertions(+)
> >
> > diff --git a/dr
Hi
Am 07.09.21 um 13:57 schrieb Noralf Trønnes:
For devices that don't support XRGB give the user the ability to
choose what's most important: Color depth or frames per second.
Add an 'xrgb' module parameter to override the emulation format.
Assume the user wants full control if xrgb88
On Wed, Sep 08, 2021 at 08:53:56AM -0500, Chris Morgan wrote:
> From: Chris Morgan
>
> After commit 928f9e268611 ("clk: fractional-divider: Hide
> clk_fractional_divider_ops from wide audience") was merged it appears
> that the DSI panel on my Odroid Go Advance stopped working. Upon closer
> exam
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/drivers/dma-buf/dma-fence-array.c
> i
On Fri, Sep 03, 2021 at 11:47:52AM -0700, Rob Clark wrote:
> From: Rob Clark
>
> Add a way to hint to the fence signaler of an upcoming deadline, such as
> vblank, which the fence waiter would prefer not to miss. This is to aid
> the fence signaler in making power management decisions, like boos
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-chain.c | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/dma-buf/dma-fence-chain.c
> b/drivers/dma-buf/dma-fence-chain.c
>
On Wed, Sep 8, 2021 at 10:48 AM Daniel Vetter wrote:
>
> On Fri, Sep 03, 2021 at 11:47:56AM -0700, Rob Clark wrote:
> > From: Rob Clark
> >
> > Signed-off-by: Rob Clark
>
> Why do you need a kthread_work here? Is this just to make sure you're
> running at realtime prio? Maybe a comment to that e
Hi
Am 03.08.21 um 07:10 schrieb Sam Ravnborg:
Hi Anitha,
On Mon, Aug 02, 2021 at 08:44:26PM +, Chrisanthus, Anitha wrote:
Hi Sam,
Thanks. Where should this go, drm-misc-fixes or drm-misc-next?
Looks like a drm-misc-next candidate to me.
I may improve something for existing users, but it
On Fri, Sep 03, 2021 at 11:47:59AM -0700, Rob Clark wrote:
> From: Rob Clark
>
> The initial purpose is for igt tests, but this would also be useful for
> compositors that wait until close to vblank deadline to make decisions
> about which frame to show.
>
> Signed-off-by: Rob Clark
Needs user
On Fri, Sep 03, 2021 at 11:47:56AM -0700, Rob Clark wrote:
> From: Rob Clark
>
> Signed-off-by: Rob Clark
Why do you need a kthread_work here? Is this just to make sure you're
running at realtime prio? Maybe a comment to that effect would be good.
-Daniel
> ---
> drivers/gpu/drm/msm/msm_fence
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 deadline from from the finished
> fence to
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 AFAICT.
Best regards
Thomas
drm-misc-fixes-2021-09-08:
Short summ
On Fri, Sep 03, 2021 at 01:00:16PM +, Simon Ser wrote:
> validate_lease expects one CRTC, one connector and one plane.
>
> Signed-off-by: Simon Ser
> Cc: Daniel Vetter
> Cc: Pekka Paalanen
> Cc: Keith Packard
Reviewed-by: Daniel Vetter
> ---
> include/uapi/drm/drm_mode.h | 3 +++
> 1 f
On Fri, Sep 03, 2021 at 12:24:05PM +0100, Matthew Auld wrote:
> Currently we blow up in trace_dma_fence_init, when calling into
> get_driver_name or get_timeline_name, since both the engine and context
> might be NULL(or contain some garbage address) in the case of newly
> allocated slab objects vi
On Fri, Sep 03, 2021 at 02:05:54PM +0200, Boris Brezillon wrote:
> drm_sched_job_cleanup() will pass an uninitialized fence to
> drm_sched_fence_free(), which will cause to_drm_sched_fence() to return
> a NULL fence object, causing a NULL pointer deref when this NULL object
> is passed to kmem_cach
On Thu, Sep 02, 2021 at 10:57:37PM +0100, Colin King wrote:
> From: Colin Ian King
>
> There is a statement that is indented one character too deeply,
> clean this up.
>
> Signed-off-by: Colin Ian King
Queued to drm-intel-gt-next, thanks for patch.
-Daniel
> ---
> drivers/gpu/drm/i915/gt/int
On Sat, Sep 04, 2021 at 11:50:37AM +0800, David Gow wrote:
> On Thu, Sep 2, 2021 at 10:46 PM Daniel Vetter wrote:
> >
> > On Thu, Sep 02, 2021 at 07:19:01AM +0100, Anton Ivanov wrote:
> > > On 02/09/2021 06:52, Randy Dunlap wrote:
> > > > On 9/1/21 10:48 PM, Anton Ivanov wrote:
> > > > > On 02/09/
On Thu, Sep 02, 2021 at 04:01:40PM +0100, Tvrtko Ursulin wrote:
>
> On 02/09/2021 15:33, Daniel Vetter wrote:
> > On Tue, Aug 31, 2021 at 02:18:15PM +0100, Tvrtko Ursulin wrote:
> > >
> > > On 31/08/2021 13:43, Daniel Vetter wrote:
> > > > On Tue, Aug 31, 2021 at 10:15:03AM +0100, Tvrtko Ursulin
1 - 100 of 159 matches
Mail list logo
