Am 03.02.21 um 21:20 schrieb Suren Baghdasaryan:
[SNIP]
If there is a reason to set this flag other than historical use of
carveout memory then we wanted to catch such cases and fix the drivers
that moved to using dmabuf heaps. However maybe there are other
reasons and if so I would be very
On 12/15/20 1:27 PM, Jianxin Xiong wrote:
This patch series adds dma-buf importer role to the RDMA driver in
attempt to support RDMA using device memory such as GPU VRAM. Dma-buf is
chosen for a few reasons: first, the API is relatively simple and allows
a lot of flexibility in implementing the
Remove code for resetting frl related members from intel_disable_dp, as
this is not applicable for older platforms.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_dp.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
Currently the FRL training mode (Concurrent, Sequential) and
training type (Normal, Extended) are not defined properly and
are passed as bool values in drm_helpers for pcon
configuration for FRL training.
This patch:
-Defines FRL training type and link bring up sequence mode as enum.
-Fixes the
DP-HDMI2.1 PCON has DSC encoder caps defined in registers 0x92-0x9E.
Do not read the registers if DPCD rev < 1.4.
Fixes: https://gitlab.freedesktop.org/drm/intel/-/issues/2868
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_dp.c | 4 +++-
1 file changed, 3 insertions(+), 1
Patch1: fixes gitlab issue:
https://gitlab.freedesktop.org/drm/intel/-/issues/2868
Patch2: Tweaks the drm_helpers for PCON configuration
Patch3: Removes unwanted code not applicable for older platforms.
Ankit Nautiyal (3):
i915/display/intel_dp: Read PCON DSC ENC caps only for DPCD rev >= 1.4
Hi all,
Today's linux-next merge of the drivers-x86 tree got a conflict in:
drivers/gpu/drm/gma500/Kconfig
drivers/gpu/drm/gma500/mdfld_device.c
drivers/gpu/drm/gma500/mdfld_dsi_output.c
drivers/gpu/drm/gma500/mdfld_output.c
drivers/gpu/drm/gma500/tc35876x-dsi-lvds.c
between commits:
Hi Dave, Daniel,
More fixes for 5.12. Same PR from last week with the issue Felix reported
fixed and a few more additional fixes on top.
The following changes since commit a6b8720c2f85143561c3453e1cf928a2f8586ac0:
Merge tag 'amd-drm-next-5.12-2021-01-20' of
https://bugzilla.kernel.org/show_bug.cgi?id=211033
--- Comment #16 from Shawn Anastasio (sh...@anastas.io) ---
Created attachment 295063
--> https://bugzilla.kernel.org/attachment.cgi?id=295063=edit
kernel log
I have encountered the same issue on 5.10.10 which contains the revert.
Attached is
Hi Dave, Daniel,
Fixes for 5.11.
The following changes since commit e0ecafede87eb1a3d1e708f0365fad0d59489285:
Merge tag 'amd-drm-fixes-5.11-2021-01-28' of
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes (2021-01-29 11:36:38
+1000)
are available in the Git repository at:
On Thu, 4 Feb 2021 at 09:22, Chun-Kuang Hu wrote:
>
> Hi, Dave & Daniel:
>
> This includes:
>
> 1. Decouple Mediatek DRM sub driver
> 2. Share mtk mutex driver for both DRM and MDP
> 3. Add support for SoC MT8183
Hi Chun-Kuang,
dim: e83421b9acad ("drm/mediatek: Fix aal size config"): Subject
On 2/3/2021 5:25 AM, Joonas Lahtinen wrote:
> Quoting Brian Welty (2021-01-26 23:46:24)
>> Single control below is added to DRM cgroup controller in order to track
>> user execution time for GPU devices. It is up to device drivers to
>> charge execution time to the cgroup via
From: Ville Syrjälä
drm_vblank_restore() exists because certain power saving states
can clobber the hardware frame counter. The way it does this is
by guesstimating how many frames were missed purely based on
the difference between the last stored timestamp vs. a newly
sampled timestamp.
If we
Hi, Dave & Daniel:
This includes:
1. Decouple Mediatek DRM sub driver
2. Share mtk mutex driver for both DRM and MDP
3. Add support for SoC MT8183
Regards,
Chun-Kuang.
The following changes since commit 5c8fe583cce542aa0b84adc939ce85293de36e5e:
Linux 5.11-rc1 (2020-12-27 15:30:22 -0800)
On Wed, Feb 3, 2021 at 1:46 PM Will Deacon wrote:
>
> On Tue, Feb 02, 2021 at 11:56:27AM +0530, Sai Prakash Ranjan wrote:
> > On 2021-02-01 23:50, Jordan Crouse wrote:
> > > On Mon, Feb 01, 2021 at 08:20:44AM -0800, Rob Clark wrote:
> > > > On Mon, Feb 1, 2021 at 3:16 AM Will Deacon wrote:
> > >
On Wed, Feb 3, 2021 at 1:58 PM Stephen Boyd wrote:
>
> Quoting Rob Clark (2021-02-03 09:29:09)
> > On Wed, Feb 3, 2021 at 2:10 AM Daniel Vetter wrote:
> > >
> > > On Tue, Feb 02, 2021 at 08:51:25AM -0800, Rob Clark wrote:
> > > > On Tue, Feb 2, 2021 at 7:46 AM Daniel Vetter wrote:
> > > > >
> >
On Thu, Feb 4, 2021 at 12:23 AM Petr Mladek wrote:
>
> On Tue 2021-02-02 09:44:22, John Ogness wrote:
> > On 2021-02-02, Masahiro Yamada wrote:
> > > CONSOLE_LOGLEVEL_DEFAULT is nothing more than a shorthand of
> > > CONFIG_CONSOLE_LOGLEVEL_DEFAULT.
> > >
> > > When you change
On Tue, Feb 02, 2021 at 11:56:27AM +0530, Sai Prakash Ranjan wrote:
> On 2021-02-01 23:50, Jordan Crouse wrote:
> > On Mon, Feb 01, 2021 at 08:20:44AM -0800, Rob Clark wrote:
> > > On Mon, Feb 1, 2021 at 3:16 AM Will Deacon wrote:
> > > > On Fri, Jan 29, 2021 at 03:12:59PM +0530, Sai Prakash
On Wed, 2021-02-03 at 15:58 -0500, Rodrigo Vivi wrote:
> On Mon, Jan 25, 2021 at 07:10:30PM -0500, Lyude Paul wrote:
> > Since we're about to implement eDP backlight support in nouveau using the
> > standard protocol from VESA, we might as well just take the code that's
> > already written for
On Wed, Feb 3, 2021 at 9:29 PM Daniel Vetter wrote:
>
> On Wed, Feb 3, 2021 at 9:20 PM Suren Baghdasaryan wrote:
> >
> > On Wed, Feb 3, 2021 at 12:52 AM Daniel Vetter
> > wrote:
> > >
> > > On Wed, Feb 3, 2021 at 2:57 AM Matthew Wilcox wrote:
> > > >
> > > > On Tue, Feb 02, 2021 at 04:31:33PM
tldr; DMA buffers aren't normal memory, expecting that you can use
them like that (like calling get_user_pages works, or that they're
accounting like any other normal memory) cannot be guaranteed.
Since some userspace only runs on integrated devices, where all
buffers are actually all resident
On Mon, Feb 01, 2021 at 02:01:42PM +0200, Imre Deak wrote:
> Reporting a port as connected if nothing is attached to them leads to
> any i2c transactions on this port trying to use an uninitialized i2c
> adapter, fix this.
>
> Let's account for this case even if branch devices have no good reason
On Mon, Jan 25, 2021 at 07:10:30PM -0500, Lyude Paul wrote:
> Since we're about to implement eDP backlight support in nouveau using the
> standard protocol from VESA, we might as well just take the code that's
> already written for this and move it into a set of shared DRM helpers.
>
> Note that
On Mon, 01 Feb 2021 17:33:14 +0100, Michael Tretter wrote:
> On Tue, 15 Sep 2020 21:40:40 +0200, Andrzej Hajda wrote:
> > W dniu 14.09.2020 o 23:19, Andrzej Hajda pisze:
> > > On 14.09.2020 22:01, Michael Tretter wrote:
> > >> On Mon, 14 Sep 2020 14:31:19 +0200, Marek Szyprowski wrote:
> > >>> On
On Wed, Feb 3, 2021 at 9:20 PM Suren Baghdasaryan wrote:
>
> On Wed, Feb 3, 2021 at 12:52 AM Daniel Vetter wrote:
> >
> > On Wed, Feb 3, 2021 at 2:57 AM Matthew Wilcox wrote:
> > >
> > > On Tue, Feb 02, 2021 at 04:31:33PM -0800, Suren Baghdasaryan wrote:
> > > > Replace BUG_ON(vma->vm_flags &
Hi Sebastian,
Am Mittwoch, 3. Februar 2021, 19:14:22 CET schrieb Sebastian Fricke:
> Hey Heiko,
>
> I have tested your patch set on my nanoPC-T4, here is a complete log
> with:
> - relevant kernel log entries
> - system information
> - media ctl output
> - sysfs entry information
>
>
On Mon, 05 Oct 2020 15:42:50 +0200, Marek Vasut wrote:
> This adds basic i.MX8MM glue code for the Samsung DSIM PHY.
> There are still a couple of items which need to be sorted out
> in drivers/gpu/drm/bridge/samsung-dsim.c before this can even
> be merged, specifically:
>
> - The dsi->out_bridge
Reviewed-by: Lyude Paul
Let me know when this has been pushed somewhere
On Mon, 2021-02-01 at 11:01 +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> Since I wrote the below patch if you run a debug kernel you can a
> dma debug warning like:
> nouveau :1f:00.0: DMA-API: device driver
Daniel,
I will have to get back to you later on the details of this because my
head is currently context switched to some infrastructure and
Kubernetes/golang work, so I am having a hard time digesting what you
are saying. I am new to the bpf stuff so this is about my own
learning as well as a
https://bugzilla.kernel.org/show_bug.cgi?id=211501
--- Comment #2 from Jasen Borisov (borisovja...@protonmail.com) ---
OK, it just happened again. More info:
The secondary monitor lights up, but just shows a black screen with the mouse
cursor, but the primary monitor does not. This makes me
On Wed, 3 Feb 2021 at 17:58, Xiong, Jianxin wrote:
>
> > -Original Message-
> > From: Daniel Vetter
> > Sent: Wednesday, February 03, 2021 9:53 AM
> > To: Xiong, Jianxin
> > Cc: Leon Romanovsky ; Jason Gunthorpe ; Gal
> > Pressman ; Yishai Hadas
> > ; linux-rdma ; Edward
> > Srouji ;
On 2/3/2021 4:22 AM, Bjorn Andersson wrote:
On Fri 08 Jan 12:15 CST 2021, Akhil P Oommen wrote:
Please align the $subject prefix with other changes in the same file.
I fixed it up while picking up the patch this time.
Will take of this in future. Thanks, Bjorn.
-Akhil.
Regards,
Bjorn
Add
> -Original Message-
> From: Daniel Vetter
> Sent: Wednesday, February 03, 2021 9:53 AM
> To: Xiong, Jianxin
> Cc: Leon Romanovsky ; Jason Gunthorpe ; Gal
> Pressman ; Yishai Hadas
> ; linux-rdma ; Edward Srouji
> ; dri-devel de...@lists.freedesktop.org>; Christian Koenig ;
> Doug
On Wed, Feb 3, 2021 at 5:57 PM Xiong, Jianxin wrote:
>
> > -Original Message-
> > From: Leon Romanovsky
> > Sent: Tuesday, February 02, 2021 10:03 PM
> > To: Daniel Vetter
> > Cc: Xiong, Jianxin ; Jason Gunthorpe
> > ; Gal Pressman ; Yishai Hadas
> > ; linux-rdma ; Edward
> > Srouji ;
On Wed, Feb 3, 2021 at 6:14 PM Daniel Vetter wrote:
>
> On Wed, Feb 3, 2021 at 5:42 PM Alex Deucher wrote:
> >
> > On Wed, Feb 3, 2021 at 9:42 AM Daniel Vetter wrote:
> > >
> > > On Wed, Feb 3, 2021 at 3:33 PM Bridgman, John
> > > wrote:
> > > >
> > > > >>Uh, that doesn't work. If you want
On Wed, Feb 3, 2021 at 2:10 AM Daniel Vetter wrote:
>
> On Tue, Feb 02, 2021 at 08:51:25AM -0800, Rob Clark wrote:
> > On Tue, Feb 2, 2021 at 7:46 AM Daniel Vetter wrote:
> > >
> > > On Mon, Jan 25, 2021 at 03:49:01PM -0800, Stephen Boyd wrote:
> > > > Lockdep complains about an AA deadlock when
On Wed, Feb 3, 2021 at 5:42 PM Alex Deucher wrote:
>
> On Wed, Feb 3, 2021 at 9:42 AM Daniel Vetter wrote:
> >
> > On Wed, Feb 3, 2021 at 3:33 PM Bridgman, John wrote:
> > >
> > > >>Uh, that doesn't work. If you want infinite compute queues you need the
> > > amdkfd model with preempt-ctx
> -Original Message-
> From: Leon Romanovsky
> Sent: Tuesday, February 02, 2021 10:03 PM
> To: Daniel Vetter
> Cc: Xiong, Jianxin ; Jason Gunthorpe
> ; Gal Pressman ; Yishai Hadas
> ; linux-rdma ; Edward Srouji
> ; dri-devel de...@lists.freedesktop.org>; Christian Koenig ;
> Doug
On Wed, Feb 3, 2021 at 9:42 AM Daniel Vetter wrote:
>
> On Wed, Feb 3, 2021 at 3:33 PM Bridgman, John wrote:
> >
> > >>Uh, that doesn't work. If you want infinite compute queues you need the
> > amdkfd model with preempt-ctx dma_fence. If you allow normal cs ioctl to
> > run forever, you just
On Tue, Jan 19, 2021 at 5:03 PM Daniel Vetter wrote:
>
> On Tue, Jan 19, 2021 at 4:20 PM Greg Kroah-Hartman
> wrote:
> >
> > On Tue, Jan 19, 2021 at 03:34:47PM +0100, Daniel Vetter wrote:
> > > On Tue, Jan 19, 2021 at 3:32 PM Greg Kroah-Hartman
> > > wrote:
> > > >
> > > > On Tue, Jan 19, 2021
Hi, Hsin-Yi:
Hsin-Yi Wang 於 2021年2月2日 週二 下午4:14寫道：
>
> From: Yongqiang Niu
>
> Add matrix_bits and coeffs_precision to ccorr private data:
> - matrix bits of mt8183 is 10
> - matrix bits of mt8192 is 11
Applied to mediatek-drm-next [1], thanks.
[1]
Hi, Hsin-Yi:
Hsin-Yi Wang 於 2021年2月2日 週二 下午4:13寫道：
>
> From: Yongqiang Niu
>
> Fix setting to follow hardware datasheet. The original error setting
> affects mt8192 display.
>
Applied to mediatek-drm-next [1], thanks.
[1]
Hi, Hsin-Yi:
Hsin-Yi Wang 於 2021年2月2日 週二 下午4:13寫道：
>
> From: Yongqiang Niu
>
> ccorr ctm matrix bits will be different in mt8192
Applied to mediatek-drm-next [1], thanks.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next
Regards,
Chun-Kuang.
Hi Rob,
On Wed, Feb 3, 2021 at 4:55 PM Rob Herring wrote:
> On Wed, Feb 03, 2021 at 09:01:23AM +0100, Geert Uytterhoeven wrote:
> > On Tue, Feb 2, 2021 at 9:55 PM Rob Herring wrote:
> > > Properties in if/then schemas weren't getting checked by the meta-schemas.
> > > Enabling meta-schema
On Wed, Feb 3, 2021 at 4:54 PM Christian König wrote:
>
> Am 03.02.21 um 16:51 schrieb Luben Tuikov:
> > On 2021-02-03 5:36 a.m., Daniel Vetter wrote:
> >> On Fri, Jan 29, 2021 at 04:54:39PM +0100, Patrik Jakobsson wrote:
> >>> The commit a6a1f036c74e ("drm/scheduler: Job timeout handler returns
On Wed, Feb 03, 2021 at 09:01:23AM +0100, Geert Uytterhoeven wrote:
> Hi Rob,
>
> On Tue, Feb 2, 2021 at 9:55 PM Rob Herring wrote:
> > Properties in if/then schemas weren't getting checked by the meta-schemas.
> > Enabling meta-schema checks finds several errors.
> >
> > The use of an 'items'
Am 03.02.21 um 16:51 schrieb Luben Tuikov:
On 2021-02-03 5:36 a.m., Daniel Vetter wrote:
On Fri, Jan 29, 2021 at 04:54:39PM +0100, Patrik Jakobsson wrote:
The commit a6a1f036c74e ("drm/scheduler: Job timeout handler returns
status (v3)") incorrectly uses "enum drm_task_status" for v3d and
On 2021-02-03 5:36 a.m., Daniel Vetter wrote:
> On Fri, Jan 29, 2021 at 04:54:39PM +0100, Patrik Jakobsson wrote:
>> The commit a6a1f036c74e ("drm/scheduler: Job timeout handler returns
>> status (v3)") incorrectly uses "enum drm_task_status" for v3d and causes
>> a build failure. "enum
On 03/02/2021 14:45, Rob Herring wrote:
On Mon, Feb 1, 2021 at 2:21 AM Boris Brezillon
wrote:
Doing a hw-irq -> threaded-irq round-trip is counter-productive, stay
in the threaded irq handler as long as we can.
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/panfrost/panfrost_mmu.c | 7
Am 03.02.21 um 16:29 schrieb Daniel Vetter:
Recently there was a fairly long thread about recoreable hardware page
faults, how they can deadlock, and what to do about that.
While the discussion is still fresh I figured good time to try and
document the conclusions a bit. This documentation
Recently there was a fairly long thread about recoreable hardware page
faults, how they can deadlock, and what to do about that.
While the discussion is still fresh I figured good time to try and
document the conclusions a bit. This documentation section explains
what's the potential problem, and
is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Gerd-Hoffmann/drm-qxl-fix-driver-shutdown-issues/20210203-211739
base: git
On Wed, Feb 3, 2021 at 3:26 PM Thomas Zimmermann wrote:
>
> Hi
>
> Am 03.02.21 um 15:01 schrieb Daniel Vetter:
> > On Wed, Feb 03, 2021 at 02:10:42PM +0100, Thomas Zimmermann wrote:
> >> Several drivers use GEM SHMEM buffer objects as shadow buffers for
> >> the actual framebuffer memory. Right
On Wed, 3 Feb 2021 at 15:37, Christian König wrote:
>
> Hi Daniel,
>
> I've talked a bit with our internal team.
>
> The problem is that the 20.20 release still uses the older OpenCL stack
> which obviously has a bug here and causes a hang.
>
> The best approach I can give you is to switch to the
On Mon, Feb 1, 2021 at 2:21 AM Boris Brezillon
wrote:
>
> Doing a hw-irq -> threaded-irq round-trip is counter-productive, stay
> in the threaded irq handler as long as we can.
>
> Signed-off-by: Boris Brezillon
> ---
> drivers/gpu/drm/panfrost/panfrost_mmu.c | 7 +++
> 1 file changed, 7
On Wed, Feb 3, 2021 at 3:33 PM Bridgman, John wrote:
>
> >>Uh, that doesn't work. If you want infinite compute queues you need the
> amdkfd model with preempt-ctx dma_fence. If you allow normal cs ioctl to
> run forever, you just hang the kernel whenever userspace feels like. Not
> just the gpu,
On Tue, Jan 05, 2021 at 09:46:07PM +0800, Kevin Tang wrote:
> Adds dsi host controller support for the Unisoc's display subsystem.
> Adds dsi phy support for the Unisoc's display subsystem.
> Only MIPI DSI Displays supported, DP/TV/HMDI will be support
> in the feature.
>
> v1:
> - Remove dphy
Hi Daniel,
I've talked a bit with our internal team.
The problem is that the 20.20 release still uses the older OpenCL stack
which obviously has a bug here and causes a hang.
The best approach I can give you is to switch to the ROCm stack instead.
Regards,
Christian.
Am 03.02.21 um 09:33
>>Uh, that doesn't work. If you want infinite compute queues you need the
amdkfd model with preempt-ctx dma_fence. If you allow normal cs ioctl to
run forever, you just hang the kernel whenever userspace feels like. Not
just the gpu, the kernel (anything that allocates memory, irrespective of
On Wed, Feb 03, 2021 at 08:56:17AM -0500, Alex Deucher wrote:
> On Wed, Feb 3, 2021 at 7:30 AM Christian König
> wrote:
> >
> > Am 03.02.21 um 13:24 schrieb Daniel Vetter:
> > > On Wed, Feb 03, 2021 at 01:21:20PM +0100, Christian König wrote:
> > >> Am 03.02.21 um 12:45 schrieb Daniel Gomez:
> >
Hi
Am 03.02.21 um 15:01 schrieb Daniel Vetter:
On Wed, Feb 03, 2021 at 02:10:42PM +0100, Thomas Zimmermann wrote:
Several drivers use GEM SHMEM buffer objects as shadow buffers for
the actual framebuffer memory. Right now, drivers do these vmap
operations in their commit tail, which is
On Tue, Jan 05, 2021 at 09:46:05PM +0800, Kevin Tang wrote:
> Adds DPU(Display Processor Unit) support for the Unisoc's display subsystem.
> It's support multi planes, scaler, rotation, PQ(Picture Quality) and more.
>
> Cc: Orson Zhai
> Cc: Chunyan Zhang
> Signed-off-by: Kevin Tang
>
> v2:
>
On Wednesday, February 3rd, 2021 at 3:13 PM, Emil Velikov
wrote:
> As said before, there are multiple ways to handle this without
> introducing yet another UAPI header. I don't see why you're dismissing
> all of them, can you elaborate?
Because I hate it when I have to adjust my compiler flags
From: Colin Ian King
Currently the for_each_set_bit loop is iterating index engn from 0..31 and
calls to tu102_fifo_recover_engn can potentiall access fifo->engine[engn]
where engn is larger than the array engine (which is currently hard coded
as 16 elements). Avoid any potential array out of
On Tue, Jan 05, 2021 at 09:46:05PM +0800, Kevin Tang wrote:
> Adds DPU(Display Processor Unit) support for the Unisoc's display subsystem.
> It's support multi planes, scaler, rotation, PQ(Picture Quality) and more.
>
> Cc: Orson Zhai
> Cc: Chunyan Zhang
> Signed-off-by: Kevin Tang
>
> v2:
>
Am 03.02.21 um 14:16 schrieb Gerd Hoffmann:
Now that we have the new release_event wait queue we can just
use that in qxl_fence_wait() and simplify the code alot.
Signed-off-by: Gerd Hoffmann
Acked-by: Thomas Zimmermann
---
drivers/gpu/drm/qxl/qxl_release.c | 42
On Wed, 3 Feb 2021 at 13:47, Simon Ser wrote:
>
> On Wednesday, February 3rd, 2021 at 12:03 PM, Emil Velikov
> wrote:
>
> > No issue then, great. Let's merge this trivial solution and move on to
> > other things.
>
> Just because one compositor isn't affected isn't an excuse for the
> kernel to
Am 03.02.21 um 14:16 schrieb Gerd Hoffmann:
Reorganize qxl_device_fini() a bit.
Add missing unpin() calls.
Count releases. Add wait queue for releases. That way
qxl_device_fini() can easily wait until everything is
ready for proper shutdown.
Signed-off-by: Gerd Hoffmann
Acked-by: Thomas
On Tue, Jan 05, 2021 at 09:46:03PM +0800, Kevin Tang wrote:
> Adds drm support for the Unisoc's display subsystem.
>
> This is drm kms driver, this driver provides support for the
> application framework in Android, Yocto and more.
>
> Application framework can access Unisoc's display internel
>
Am 03.02.21 um 14:16 schrieb Gerd Hoffmann:
qxl_primary_atomic_disable must check whenever the framebuffer bo has a
shadow surface and in case it has check the shadow primary status.
I believe you :)
Acked-by: Thomas Zimmermann
Signed-off-by: Gerd Hoffmann
---
Hi
Am 03.02.21 um 14:16 schrieb Gerd Hoffmann:
In case we have a shadow surface on shutdown release
it so it doesn't leak.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_display.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/qxl/qxl_display.c
On Wed, Feb 03, 2021 at 02:10:42PM +0100, Thomas Zimmermann wrote:
> Several drivers use GEM SHMEM buffer objects as shadow buffers for
> the actual framebuffer memory. Right now, drivers do these vmap
> operations in their commit tail, which is actually not allowed by the
> locking rules for the
Am 03.02.21 um 14:16 schrieb Gerd Hoffmann:
Balances the qxl_create_bo(..., pinned=true, ...);
call in qxl_release_bo_alloc().
Signed-off-by: Gerd Hoffmann
Acked-by: Thomas Zimmermann
---
drivers/gpu/drm/qxl/qxl_release.c | 1 +
1 file changed, 1 insertion(+)
diff --git
On Wed, Feb 3, 2021 at 7:30 AM Christian König wrote:
>
> Am 03.02.21 um 13:24 schrieb Daniel Vetter:
> > On Wed, Feb 03, 2021 at 01:21:20PM +0100, Christian König wrote:
> >> Am 03.02.21 um 12:45 schrieb Daniel Gomez:
> >>> On Wed, 3 Feb 2021 at 10:47, Daniel Gomez wrote:
> On Wed, 3 Feb
On Wednesday, February 3rd, 2021 at 12:03 PM, Emil Velikov
wrote:
> No issue then, great. Let's merge this trivial solution and move on to
> other things.
Just because one compositor isn't affected isn't an excuse for the
kernel to force its users to use a specific C standard.
Quoting Brian Welty (2021-01-26 23:46:24)
> Single control below is added to DRM cgroup controller in order to track
> user execution time for GPU devices. It is up to device drivers to
> charge execution time to the cgroup via drm_cgroup_try_charge().
>
> sched.runtime
> Read-only
Hi Uwe,
On 1/26/21 5:58 PM, Uwe Kleine-König wrote:
> All amba drivers return 0 in their remove callback. Together with the
> driver core ignoring the return value anyhow, it doesn't make sense to
> return a value here.
>
> Change the remove prototype to return void, which makes it explicit that
qxl_primary_atomic_disable must check whenever the framebuffer bo has a
shadow surface and in case it has check the shadow primary status.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_display.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/qxl/qxl_display.c
Reorganize qxl_device_fini() a bit.
Add missing unpin() calls.
Count releases. Add wait queue for releases. That way
qxl_device_fini() can easily wait until everything is
ready for proper shutdown.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_drv.h | 2 ++
Now that we have the new release_event wait queue we can just
use that in qxl_fence_wait() and simplify the code alot.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_release.c | 42 +++
1 file changed, 4 insertions(+), 38 deletions(-)
diff --git
Balances the qxl_create_bo(..., pinned=true, ...);
call in qxl_release_bo_alloc().
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_release.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/qxl/qxl_release.c
b/drivers/gpu/drm/qxl/qxl_release.c
index
In case we have a shadow surface on shutdown release
it so it doesn't leak.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_display.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/qxl/qxl_display.c
b/drivers/gpu/drm/qxl/qxl_display.c
index
Almost there. Still getting this on driver unbind:
kobject: '(null)' ((ptrval)): is not initialized, yet kobject_put(=
) is being called
[ ... ]
Call Trace:
ttm_device_fini+0x133/0x1b0 [ttm]
qxl_ttm_fini+0x2f/0x40 [qxl]
qxl_device_fini+0x88/0x120 [qxl]
Signed-off-by: Gerd Hoffmann
Reviewed-by: Daniel Vetter
Acked-by: Thomas Zimmermann
---
drivers/gpu/drm/qxl/qxl_display.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_display.c
b/drivers/gpu/drm/qxl/qxl_display.c
index
On Fri, Jan 22, 2021 at 03:06:44PM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 22.01.21 um 14:36 schrieb Daniel Vetter:
> > Requested by Thomas. I think it justifies a new level, since I tried
> > to make some forward progress on this last summer, and gave up (for
> > now). This is very tricky.
>
Vmap operations may acquire the dmabuf reservation lock, which is not
allowed within atomic commit-tail functions. Therefore move vmap and
vunmap from the damage handler into prepare_fb and cleanup_fb callbacks.
The mapping is provided as GEM SHMEM shadow plane. The enable and prepare
callbacks
Vmap operations may acquire the dmabuf reservation lock, which is not
allowed within atomic commit-tail functions. Therefore move vmap and
vunmap from the damage handler into prepare_fb and cleanup_fb callbacks.
The mapping is provided as GEM SHMEM shadow plane. The enable and prepare
callbacks
Vmap operations may acquire the dmabuf reservation lock, which is not
allowed within atomic commit-tail functions. Therefore move vmap and
vunmap from the damage handler into prepare_fb and cleanup_fb callbacks.
The mapping is provided as GEM SHMEM shadow plane. The enable and prepare
callbacks
Vmap operations may acquire the dmabuf reservation lock, which is not
allowed within atomic commit-tail functions. Therefore move vmap and
vunmap from the damage handler into prepare_fb and cleanup_fb callbacks.
The mapping is provided as GEM SHMEM shadow plane. The enable and prepare
callbacks
Several drivers use GEM SHMEM buffer objects as shadow buffers for
the actual framebuffer memory. Right now, drivers do these vmap
operations in their commit tail, which is actually not allowed by the
locking rules for the dma-buf reservation lock. The involved SHMEM
BO has to be vmapped in the
Just like regular plane-state helpers, drivers can use these new
callbacks to create and destroy private plane state.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_simple_kms_helper.c | 40 +++--
include/drm/drm_simple_kms_helper.h | 28 +
2
Several SHMEM-based drivers use the BO as shadow buffer for the real
framebuffer memory. Damage handling requires a vmap of the BO memory.
Vmap/vunmap can acquire the dma-buf reservation lock, which is not
allowed in commit tails.
This patchset introduces a set of helpers that implement
> > + /*
> > +* Ask host to release resources (+fill release ring),
> > +* then wait for the release actually happening.
> > +*/
> > + qxl_io_notify_oom(qdev);
> > + for (try = 0; try < 20 && atomic_read(>release_count) > 0; try++)
> > + msleep(20);
>
> A bit icky, why
Hi,
here are two patches handling the issues in the backlight control.
The first one is to fix the sysfs brightness read for devices with the
backlight controlled by aux channel. The second one is to add a new
module option, aux_backlight, to forcibly enable/disable the aux
channel backlight
There seem devices that don't work with the aux channel backlight
control. For allowing such users to test with the other backlight
control method, provide a new module option, aux_backlight, to specify
enabling or disabling the aux backport support explicitly. As
default, the aux support is
The current code tries to read the brightness value via
dc_link_get_backlight_level() no matter whether it's controlled via
aux or not, and this results in a bogus value returned.
Fix it to read the current value via
dc_link_get_backlight_level_nits() for the aux.
BugLink:
Am 03.02.21 um 13:24 schrieb Daniel Vetter:
On Wed, Feb 03, 2021 at 01:21:20PM +0100, Christian König wrote:
Am 03.02.21 um 12:45 schrieb Daniel Gomez:
On Wed, 3 Feb 2021 at 10:47, Daniel Gomez wrote:
On Wed, 3 Feb 2021 at 10:17, Daniel Vetter wrote:
On Wed, Feb 3, 2021 at 9:51 AM
On Wed, Feb 03, 2021 at 01:21:20PM +0100, Christian König wrote:
> Am 03.02.21 um 12:45 schrieb Daniel Gomez:
> > On Wed, 3 Feb 2021 at 10:47, Daniel Gomez wrote:
> > > On Wed, 3 Feb 2021 at 10:17, Daniel Vetter wrote:
> > > > On Wed, Feb 3, 2021 at 9:51 AM Christian König
> > > > wrote:
> > >
Am 03.02.21 um 12:45 schrieb Daniel Gomez:
On Wed, 3 Feb 2021 at 10:47, Daniel Gomez wrote:
On Wed, 3 Feb 2021 at 10:17, Daniel Vetter wrote:
On Wed, Feb 3, 2021 at 9:51 AM Christian König wrote:
Am 03.02.21 um 09:48 schrieb Daniel Vetter:
On Wed, Feb 3, 2021 at 9:36 AM Christian König
Am 03.02.21 um 12:26 schrieb Daniel Vetter:
On Thu, Jan 28, 2021 at 02:16:02PM +0100, Christian König wrote:
TTM implements a rather extensive accounting of allocated memory.
There are two reasons for this:
1. It tries to block userspace allocating a huge number of very small
BOs without
1 - 100 of 198 matches
Mail list logo
