On Tue, 23 Oct 2018 at 16:13, Michael Tirado wrote:
>
> That preprocessor define worked but I'm still confused about this
> DRM_FILE_PAGE_OFFSET thing. Check out drivers/gpu/drm/drm_gem.c
> right above drm_gem_init.
>
> ---
>
> /*
> * We make up offsets for buffer objects so we can recognize the
Hi Christian
Am 19.10.18 um 18:41 schrieb Christian König:
> As the name says we only need one global instance of ttm_mem_global.
>
> Drop all the driver initialization and just use a single exported
> instance which is initialized during BO global initialization.
>
> Signed-off-by: Christian Kö
https://bugzilla.kernel.org/show_bug.cgi?id=201439
--- Comment #4 from fin4...@hotmail.com ---
Monitor blanking works with the mainline kernel 4.19.0 that was released
yesterday.
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
On Sun, Oct 21, 2018 at 11:00:42PM -0600, Zach Turner wrote:
> This patch fixes 13 occurrences of the chekpatch.pl check:
>
> CHECK: Please don't use multiple blank lines
>
> Signed-off-by: Zach Turner
Outreachy kernel patches need to be submitted to the outreachy mailing
lists (and cc staging
On Sat, Oct 20, 2018 at 02:56:36PM +0800, Aaron Ma wrote:
> Hi David:
>
> get_maintainer.pl still got your old e-mail.
>
> Add airl...@redhat.com.
>
> Loop Sean too.
>
> Please review and apply these 2 patches.
Both pushed to drm-misc-next.
-Daniel
>
> Thanks,
> Aaron
> _
https://bugs.freedesktop.org/show_bug.cgi?id=108521
Bug ID: 108521
Summary: RX 580 as eGPU amdgpu: gpu post error!
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Sev
czw., 18 paź 2018, 12:21 użytkownik Linus Walleij
napisał:
> The DSI devices have a maximum operating frequency specified
> in their data sheet per the MIPI specification, and DSI hosts
> that can scale their frequency need this information to set
> their clock dividers right.
>
> As current pane
v2:
add a mutex between sync_cb execution and free.
v3:
clearly separating the roles for pt_lock and cb_mutex (Chris)
v4:
the cb_mutex should be taken outside of the pt_lock around this if() block.
(Chris)
Tested by syncobj_basic and syncobj_wait of igt.
Signed-off-by: Chunming Zhou
Cc: Daniel
On 10/22/2018 08:35 PM, Christian König wrote:
Am 22.10.18 um 08:45 schrieb Zhang, Jerry(Junwei):
A question in ttm_bo.c
[SNIP]
int ttm_bo_device_release(struct ttm_bo_device *bdev)
{
@@ -1623,18 +1620,25 @@ int ttm_bo_device_release(struct
ttm_bo_device *bdev)
drm_vma_offset_manager_de
https://bugs.freedesktop.org/show_bug.cgi?id=108260
--- Comment #5 from garththei...@hotmail.com ---
Comment on attachment 142147
--> https://bugs.freedesktop.org/attachment.cgi?id=142147
dmesg R9 390
Similar error ...
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
H
https://bugs.freedesktop.org/show_bug.cgi?id=108260
--- Comment #4 from garththei...@hotmail.com ---
Created attachment 142147
--> https://bugs.freedesktop.org/attachment.cgi?id=142147&action=edit
dmesg R9 390
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=106846
Tim Carr changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=108347
--- Comment #3 from Marek Olšák ---
Tesseract is too simple so it's very sensitive to small changes in the CPU
overhead. It's uncertain but likely that Steam games are unaffected. I'm
undecided about whether we need to revert this or not.
--
Y
On 10/22, Emil Velikov wrote:
> Hi all,
Hi Emil,
Thanks for your feedback.
> On Tue, 22 May 2018 at 02:07, Rodrigo Siqueira
> wrote:
>
> > +// SPDX-License-Identifier: GPL-2.0
>
> This
>
> > +/*
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under th
From: Navare, Manasi D
Sent: Friday, October 05, 2018 4:22 PM
To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
Cc: Navare, Manasi D; Jani Nikula; Ville Syrjala; Srivatsa, Anusha; Singh,
Gaurav K
Subject: [PATCH v5 13/28] drm/i915/dp: Co
On 10/22, Daniel Vetter wrote:
> On Mon, Oct 22, 2018 at 09:27:18AM -0300, Rodrigo Siqueira wrote:
> > Hi,
> >
> > I started to work for add the writeback feature into the VKMS, and this
> > RFC represents my first draft. As a result, I have some questions which
> > I list below.
> >
> > 1. In th
From: Intel-gfx [intel-gfx-boun...@lists.freedesktop.org] on behalf of Manasi
Navare [manasi.d.nav...@intel.com]
Sent: Friday, October 05, 2018 4:22 PM
To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
Subject: [Intel-gfx] [PATCH v5 17/2
https://bugs.freedesktop.org/show_bug.cgi?id=108347
--- Comment #2 from Marek Olšák ---
I think the difference is due to the increase in CPU overhead.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
https://bugs.freedesktop.org/show_bug.cgi?id=108317
--- Comment #14 from John Galt ---
It would seem that there was only ever one or two reports of this working on
Polaris, and they're probably either fake or incorrect for other reasons (like
running amdgpu-pro and not realizing).
Unfortunately
https://bugs.freedesktop.org/show_bug.cgi?id=105433
--- Comment #8 from Thomas R. ---
Apart from bootup, coming back from suspend also has that one screen dead at
first, and also fixable by changing resolution and back.
--
You are receiving this mail because:
You are the assignee for the bug.__
From: Navare, Manasi D
Sent: Friday, October 05, 2018 4:22 PM
To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
Cc: Singh, Gaurav K; Jani Nikula; Ville Syrjala; Srivatsa, Anusha; Navare,
Manasi D
Subject: [PATCH v5 16/28] drm/i915/dsc: D
From: Intel-gfx [intel-gfx-boun...@lists.freedesktop.org] on behalf of Manasi
Navare [manasi.d.nav...@intel.com]
Sent: Friday, October 05, 2018 4:22 PM
To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
Subject: [Intel-gfx] [PATCH v5 15/2
https://bugs.freedesktop.org/show_bug.cgi?id=107334
--- Comment #8 from Christian Widmer ---
I took the recently released kernel 4.19 as an incentive to test this again and
it looks like the issue is gone. I do, however, not know if it is indeed the
new kernel driver part or a mesa/LLVM update th
https://bugzilla.kernel.org/show_bug.cgi?id=200667
--- Comment #8 from Christian Widmer (cwid...@umbrox.de) ---
As expected, the warning is indeed gone with the recently released stable
kernel 4.19.
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
Hi,
On Sun, Oct 21, 2018 at 2:07 AM Laurent Pinchart
wrote:
>
> Hi Douglas,
>
> Thank you for the patch.
>
> On Friday, 19 October 2018 23:19:39 EEST Douglas Anderson wrote:
> > The timing diagram of some eDP panels says that you're supposed to
> > wait for HPD to be asserted before the aux chann
Hi,
On Fri, Oct 19, 2018 at 1:20 PM Douglas Anderson wrote:
>
> Let's solve the mystery of commit bf1178c98930 ("drm/bridge:
> ti-sn65dsi86: Add mystery delay to enable()"). Specifically the
> reason we needed that mystery delay is that we weren't paying
> attention to HPD.
>
> Looking at the da
Some eDP panels that are designed to be always connected to a board
use their HPD signal to signal that they've finished powering on and
they're ready to be talked to.
However, for various reasons it's possible that the HPD signal from
the panel isn't actually hooked up. In the case where the HPD
Let's solve the mystery of commit bf1178c98930 ("drm/bridge:
ti-sn65dsi86: Add mystery delay to enable()"). Specifically the
reason we needed that mystery delay is that we weren't paying
attention to HPD.
Looking at the datasheet for the same panel that was tested for the
original commit, I see t
If the HPD signal isn't hooked up to this panel we need a 200 ms
delay. In the datasheet this is shown as the maximum time that HPD
will take to be asserted after power is given to the panel.
Signed-off-by: Douglas Anderson
---
drivers/gpu/drm/panel/panel-simple.c | 2 ++
1 file changed, 2 ins
As far as I can tell the panel that was added in commit da50bd4258db
("drm/panel: simple: Add Innolux TV123WAM panel driver support")
wasn't actually an Innolux TV123WAM but was actually an Innolux
P120ZDG-BF1.
As far as I can tell the Innolux TV123WAM isn't a real panel and but
it's a mosh betwee
Some eDP panels that are designed to be always connected to a board
use their HPD signal to signal that they've finished powering on and
they're ready to be talked to.
However, for various reasons it's possible that the HPD signal from
the panel isn't actually hooked up. In the case where the HPD
As far as I can tell the bindings that were added in commit
9c04400f7ea6 ("dt-bindings: drm/panel: Document Innolux TV123WAM panel
bindings") weren't actually for Innolux TV123WAM but were actually for
Innolux P120ZDG-BF1.
As far as I can tell the Innolux TV123WAM isn't a real panel and but
it's a
Start using drm_gpu_scheduler.ready isntead.
v3:
Add helper function to run ring test and set
sched.ready flag status accordingly, clean explicit
sched.ready sets from the IP specific files.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c| 2 +-
drivers/
Problem:
A particular scheduler may become unsuable (underlying HW) after
some event (e.g. GPU reset). If it's later chosen by
the get free sched. policy a command will fail to be
submitted.
Fix:
Add a driver specific callback to report the sched status so
rq with bad sched can be avoided in favor
https://bugs.freedesktop.org/show_bug.cgi?id=107095
--- Comment #6 from keramidasc...@gmail.com ---
Same problem here.
kernel 4.18.14
mesa 18.0.5
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-d
https://bugs.freedesktop.org/show_bug.cgi?id=108493
--- Comment #6 from Timur Kristóf ---
On freenode in #dri-devel I got the suggestion to run unigine heaven with
GALLIUM_DDEBUG="1000". So I just did that. It created 3 files, which I attached
to this bug report along with the dmesg log that I to
https://bugs.freedesktop.org/show_bug.cgi?id=108317
--- Comment #13 from John Galt ---
llvm 6.0.1 + above patch + mesa mild + polaris still has the same regression.
At this point unsure personally if this has ever worked despite users saying it
worked at one point on polaris.
--
You are receivi
https://bugs.freedesktop.org/show_bug.cgi?id=108493
--- Comment #5 from Timur Kristóf ---
Created attachment 142142
--> https://bugs.freedesktop.org/attachment.cgi?id=142142&action=edit
ddebug dumb from unigine heaven 2
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=108493
--- Comment #3 from Timur Kristóf ---
Created attachment 142140
--> https://bugs.freedesktop.org/attachment.cgi?id=142140&action=edit
ddebug dumb from unigine heaven 0
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=108493
--- Comment #4 from Timur Kristóf ---
Created attachment 142141
--> https://bugs.freedesktop.org/attachment.cgi?id=142141&action=edit
ddebug dumb from unigine heaven 1
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=108493
--- Comment #2 from Timur Kristóf ---
Created attachment 142139
--> https://bugs.freedesktop.org/attachment.cgi?id=142139&action=edit
dmesg after the crash
--
You are receiving this mail because:
You are the assignee for the bug.
Quoting Mamta Shukla (2018-10-20 18:49:26)
> Use DRM_DEV_INFO/ERROR/WARN instead of dev_info/err/debug to generate
> drm-formatted specific log messages so that it will be easy to
> differentiate in case of multiple instances of driver.
Do you not think this is a bit backwards? Both dev_* and DRM_
https://bugs.freedesktop.org/show_bug.cgi?id=108493
--- Comment #1 from keramidasc...@gmail.com ---
I have the exact same problem.
The only differences are the following:
* I have the Asus Radeon RX 580 ROG Strix TOP OC 8GB GPU
* I use the Unigine Superposition to reproduce the problem quickly
*
Hi Mamta.
On Sat, Oct 20, 2018 at 11:19:26PM +0530, Mamta Shukla wrote:
> Use DRM_DEV_INFO/ERROR/WARN instead of dev_info/err/debug to generate
> drm-formatted specific log messages so that it will be easy to
> differentiate in case of multiple instances of driver.
While touching all these lines
https://bugs.freedesktop.org/show_bug.cgi?id=108317
--- Comment #12 from John Galt ---
llvm 5.0.2 + mesa mild + http://sprunge.us/oPqhzd + polaris, still not past the
regression: https://i.imgur.com/RAOwPtM.png
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugzilla.kernel.org/show_bug.cgi?id=200695
Claude Heiland-Allen (cla...@mathr.co.uk) changed:
What|Removed |Added
Kernel Version|4.17.19, 4.18.0-rc7,|4.17.19, 4.18.
On Fri, Oct 05, 2018 at 04:22:56PM -0700, Manasi Navare wrote:
> From: Gaurav K Singh
>
> This patch enables decompression support in sink device
> before link training and disables the same during the
> DDI disabling.
>
> v2:(From Manasi)
> * Change the enable/disable function to take crtc_stat
On Mon, Oct 22, 2018 at 09:27:18AM -0300, Rodrigo Siqueira wrote:
> Hi,
>
> I started to work for add the writeback feature into the VKMS, and this
> RFC represents my first draft. As a result, I have some questions which
> I list below.
>
> 1. In this patch, I replaced the virtual connector by t
Hi,
On 22-10-18 17:42, Emil Velikov wrote:
On Mon, 22 Oct 2018 at 15:58, Hans de Goede wrote:
Add #ifdef CONFIG_PM_SLEEP around the suspend/hibernate functions.
Remove unnecessary #ifdef CONFIG_COMPAT, the .compat_ioctl member is
always available and if CONFIG_COMPAT is not set then drm_comp
https://bugs.freedesktop.org/show_bug.cgi?id=108514
--- Comment #1 from Alex Deucher ---
Any chance you can narrow down when the regression occurred and bisect it using
git? Please attach your dmesg output and xorg log (if using X).
--
You are receiving this mail because:
You are the assignee
The BIOS signature check does not guarantee integrity of the BIOS image
either way. As I understand it, the signature is just a magic number.
It's not a cryptographic signature. The check is just a sanity check.
Therefore this change doesn't add any meaningful protection against the
scenario you de
https://bugs.freedesktop.org/show_bug.cgi?id=105433
--- Comment #7 from Thomas R. ---
I've got news! With 4.19, the first modeset will still disable the second
monitor, including when going into X (without mode change), but after changing
the resolution to something else and back again, it now c
https://bugs.freedesktop.org/show_bug.cgi?id=108514
Bug ID: 108514
Summary: heavy screen flickering with Mobility Radeon X1600 and
kernel version onwards 3.13
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
On Mon, 22 Oct 2018 at 15:58, Hans de Goede wrote:
>
> Add #ifdef CONFIG_PM_SLEEP around the suspend/hibernate functions.
>
> Remove unnecessary #ifdef CONFIG_COMPAT, the .compat_ioctl member is
> always available and if CONFIG_COMPAT is not set then drm_compat_ioctl
> is defined to NULL.
>
> Sign
Hi all,
On Tue, 22 May 2018 at 02:07, Rodrigo Siqueira
wrote:
> +// SPDX-License-Identifier: GPL-2.0
This
> +/*
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundati
Hi All,
Note this series applies on top of my serious from a couple of days ago
which starts with
"[PATCH 1/6] staging: vboxvideo: Stop accessing crtc_state->active"
Regards,
Hans
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://list
Use DRM_FB_HELPER_DEFAULT_OPS rather then open-coding it.
Signed-off-by: Hans de Goede
---
drivers/staging/vboxvideo/vbox_fb.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/staging/vboxvideo/vbox_fb.c
b/drivers/staging/vboxvideo/vbox_fb.c
index d3a5255c93b6.
Add #ifdef CONFIG_PM_SLEEP around the suspend/hibernate functions.
Remove unnecessary #ifdef CONFIG_COMPAT, the .compat_ioctl member is
always available and if CONFIG_COMPAT is not set then drm_compat_ioctl
is defined to NULL.
Signed-off-by: Hans de Goede
---
drivers/staging/vboxvideo/vbox_drv.
Use PCI_DEVICE() for our pci_id table and also simplify the terminating
entry tio just "{ }".
Signed-off-by: Hans de Goede
---
drivers/staging/vboxvideo/vbox_drv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/vboxvideo/vbox_drv.c
b/drivers/staging/vbox
This is a leftover from when the driver was out of tree and also build
against older kernels.
Signed-off-by: Hans de Goede
---
drivers/staging/vboxvideo/vbox_drv.h | 4 +---
drivers/staging/vboxvideo/vbox_fb.c | 2 +-
drivers/staging/vboxvideo/vbox_main.c | 2 +-
3 files changed, 3 insertions
Add myself as MODULE_AUTHOR.
Signed-off-by: Hans de Goede
---
drivers/staging/vboxvideo/vbox_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/vboxvideo/vbox_drv.c
b/drivers/staging/vboxvideo/vbox_drv.c
index b6e6530aa4be..80d7395e48dc 100644
--- a/drivers/staging/vboxvi
Stop adding -Iinclude/drm to the CFLAGS and stop using the obsolete
"include-all" drm/drmP.h header.
Signed-off-by: Hans de Goede
---
drivers/staging/vboxvideo/Makefile | 2 --
drivers/staging/vboxvideo/vbox_drv.c | 1 -
drivers/staging/vboxvideo/vbox_drv.h | 2 +-
drivers/staging/vboxvideo/vb
On Mon, Oct 22, 2018 at 03:20:27PM +0200, Niklas Cassel wrote:
> On Mon, Oct 22, 2018 at 04:08:11PM +0530, Viresh Kumar wrote:
> > On 15-10-18, 08:34, Jordan Crouse wrote:
> > > I agree that consistency is good. But the GPU is by design outside of the
> > > control of the genpd universe so it is by
On Mon, Oct 22, 2018 at 04:08:11PM +0530, Viresh Kumar wrote:
> On 15-10-18, 08:34, Jordan Crouse wrote:
> > I agree that consistency is good. But the GPU is by design outside of the
> > control of the genpd universe so it is by design not using the same
> > features.
> > It unfortunately does hap
Hi,
Thank you for the review.
On 18-10-18 20:12, Sam Ravnborg wrote:
Hi Hans.
Just a bunch of random observations that I hope you find use of.
Sam
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index cb88528e7b10..6b4d6c957da8 100644
--- a/drivers/gpu/drm/Kconfig
+++
Den 17.10.2018 17.46, skrev Daniel Vetter:
On Wed, Oct 17, 2018 at 03:04:53PM +0200, Noralf Trønnes wrote:
This adds a library for shmem backed GEM objects.
v5:
- Drop drm_gem_shmem_prime_mmap() (Daniel Vetter)
- drm_gem_shmem_mmap(): Subtract drm_vma_node_start() to get the real
vma->vm_pg
https://bugs.freedesktop.org/show_bug.cgi?id=108513
Rodrigo Siqueira changed:
What|Removed |Added
Attachment #142137|GPG pub key |ssh pub key
description|
https://bugs.freedesktop.org/show_bug.cgi?id=108513
--- Comment #1 from Rodrigo Siqueira ---
Created attachment 142138
--> https://bugs.freedesktop.org/attachment.cgi?id=142138&action=edit
GPG pub key
Add my pub key
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=108513
Bug ID: 108513
Summary: Request for new account
Product: DRI
Version: DRI git
Hardware: Other
OS: All
Status: NEW
Severity: normal
Priority: me
On Mon, Oct 22, 2018 at 11:46:08AM +0100, Chris Wilson wrote:
> Quoting Jonathan Gray (2018-10-21 09:57:32)
> > Commit b24413180f5600bcb3bb70fbed5cf186b60864bd added
> > "SPDX-License-Identifier: GPL-2.0" to files which previously had no
> > license, change this to MIT for the tracing header matchi
Am 17.10.18 um 15:04 schrieb Noralf Trønnes:
This adds an optional function table on GEM objects.
The main benefit is for drivers that support more than one type of
memory (shmem,vram,cma) for their buffers depending on the hardware it
runs on. With the callbacks attached to the GEM object itself
Am 18.10.18 um 17:37 schrieb :
> If the hardware queue for a scheduler is empty then we don't
> need to the shift the entities from their current scheduler
> as they are not getting scheduled because of some dependency.
That is most likely not a good idea. The scheduler might not have
anything to
Am 22.10.18 um 08:45 schrieb Zhang, Jerry(Junwei):
A question in ttm_bo.c
[SNIP]
int ttm_bo_device_release(struct ttm_bo_device *bdev)
{
@@ -1623,18 +1620,25 @@ int ttm_bo_device_release(struct
ttm_bo_device *bdev)
drm_vma_offset_manager_destroy(&bdev->vma_manager);
+ if (!ret)
+
On Sun, Oct 21, 2018 at 10:27:01PM -0300, Rodrigo Siqueira wrote:
> Add maintainers and reviewers for VKMS driver
>
> Signed-off-by: Rodrigo Siqueira
Acked-by: Sean Paul
> ---
> Changes in v2:
> - Insert the section in alphabetical order
>
> MAINTAINERS | 10 ++
> 1 file changed, 1
From: Rob Clark
Follow the same pattern of locking as with other state objects. This
avoids boilerplate in the driver.
Signed-off-by: Rob Clark
Signed-off-by: Boris Brezillon
Reviewed-by: Daniel Vetter
---
Changes in v3:
- Improve doc as suggested by Daniel
- Add Daniel's R-b
Changes in v2:
Hi,
I started to work for add the writeback feature into the VKMS, and this
RFC represents my first draft. As a result, I have some questions which
I list below.
1. In this patch, I replaced the virtual connector by the writeback
connector. Is it a good idea? Or should I keep both connectors? If
https://bugzilla.kernel.org/show_bug.cgi?id=201285
Philip Armstrong (p...@kantaka.co.uk) changed:
What|Removed |Added
Kernel Version|4.19-rc5|4.19.0
--- Commen
Quoting Jonathan Gray (2018-10-21 09:57:32)
> Commit b24413180f5600bcb3bb70fbed5cf186b60864bd added
> "SPDX-License-Identifier: GPL-2.0" to files which previously had no
> license, change this to MIT for the tracing header matching the license
> text of most of the other core drm files.
I'm not su
Quoting Chunming Zhou (2018-10-22 10:08:59)
> v2:
> add a mutex between sync_cb execution and free.
> v3:
> clearly separating the roles for pt_lock and cb_mutex (Chris)
>
> Signed-off-by: Chunming Zhou
> Cc: Daniel Vetter
> Cc: Chris Wilson
> Cc: Christian König
> ---
> drivers/gpu/drm/drm_s
On Fri, Oct 19, 2018 at 05:29:15PM +0200, Daniel Vetter wrote:
> On Fri, Oct 19, 2018 at 11:57:52AM +0100, Alexandru Gheorghe wrote:
> > Add selftests for the following newly added functions:
> > - drm_format_info_block_width
> > - drm_format_info_block_height
> > - drm_format_info_min_pitch
> >
On Fri, Oct 19, 2018 at 02:21:46PM +0100, Brian Starkey wrote:
> Hi Alex,
>
> On Fri, Oct 19, 2018 at 11:57:48AM +0100, Alexandru Gheorghe wrote:
> >For formats that are supported only with non-linear modifiers it
> >doesn't make to much sense to define cpp or char_per_block, so that
> >will be se
On Fri, Oct 19, 2018 at 02:17:22PM +0100, Brian Starkey wrote:
> Hi Alex,
>
> On Fri, Oct 19, 2018 at 11:57:47AM +0100, Alexandru Gheorghe wrote:
> >Enable the following formats
> >- DRM_FORMAT_X0L0: DP650
> >- DRM_FORMAT_X0L2: DP550, DP650
> >
> >Signed-off-by: Alexandru Gheorghe
>
> A couple o
On Fri, Oct 19, 2018 at 02:09:38PM +0100, Brian Starkey wrote:
> Hi Alex,
>
> On Fri, Oct 19, 2018 at 11:57:45AM +0100, Alexandru Gheorghe wrote:
> >For some pixel formats .cpp structure in drm_format info it's not
> >enough to describe the peculiarities of the pixel layout, for example
> >tiled f
Hi Daniel,
On Fri, Oct 19, 2018 at 05:14:51PM +0200, Daniel Vetter wrote:
> On Fri, Oct 19, 2018 at 11:57:51AM +0100, Alexandru Gheorghe wrote:
> > The idea is to split test implementations in different compilation
> > units, but have one single place where we define the list of tests,
> > in this
Am 19.10.18 um 22:52 schrieb Andrey Grodzovsky:
> Start using drm_gpu_scheduler.ready isntead.
Please drop all occurrences of setting sched.ready manually around the
ring tests.
Instead add a helper function into amdgpu_ring.c which does the ring
tests and sets ready depending on the result.
R
Hi Maxime,
Thanks for the review, pushed the patch to drm-misc-next.
On Fri, Oct 19, 2018 at 02:54:18PM +0200, Maxime Ripard wrote:
> On Fri, Oct 19, 2018 at 11:57:44AM +0100, Alexandru Gheorghe wrote:
> > In-line member documentation seems to be desired way of documenting
> > structure members.
Am 19.10.18 um 22:52 schrieb Andrey Grodzovsky:
> Problem:
> A particular scheduler may become unsuable (underlying HW) after
> some event (e.g. GPU reset). If it's later chosen by
> the get free sched. policy a command will fail to be
> submitted.
>
> Fix:
> Add a driver specific callback to repor
On Sat, Oct 20, 2018 at 01:27:48PM +, Deepak Singh Rawat wrote:
>
> > Hi Deepak,
> >
> > Something to consider, with this approach we kind of break the
> > following behaviour:
> > "Only tests enabled as module parameters are run, if no test is
> > explicitly enabled then all of them are run"
https://bugs.freedesktop.org/show_bug.cgi?id=108505
Michel Dänzer changed:
What|Removed |Added
Attachment #142115|text/x-log |text/plain
mime type|
v2:
add a mutex between sync_cb execution and free.
v3:
clearly separating the roles for pt_lock and cb_mutex (Chris)
Signed-off-by: Chunming Zhou
Cc: Daniel Vetter
Cc: Chris Wilson
Cc: Christian König
---
drivers/gpu/drm/drm_syncobj.c | 51 ++-
include/drm/drm
On 2018年10月22日 16:34, Chris Wilson wrote:
Quoting Chunming Zhou (2018-10-21 12:14:24)
v2:
add a mutex between sync_cb execution and free.
The result would appear to be that syncobj->lock is relegated to
protecting the pt_list and the mutex would only be needed for the
syncobj->cb_list.
The p
Quoting Chunming Zhou (2018-10-21 12:14:24)
> v2:
> add a mutex between sync_cb execution and free.
The result would appear to be that syncobj->lock is relegated to
protecting the pt_list and the mutex would only be needed for the
syncobj->cb_list.
The patch looks correct for resolving the deadlo
Ping...
Btw:
The patch is tested by syncobj_basic and syncobj_wait of IGT.
> -Original Message-
> From: Chunming Zhou
> Sent: Sunday, October 21, 2018 7:14 PM
> To: dri-devel@lists.freedesktop.org
> Cc: Zhou, David(ChunMing) ; Daniel Vetter
> ; Chris Wilson ; Koenig, Christian
>
> Subjec
On 20/10/18 03:38, Tony Lindgren wrote:
> * Sebastian Reichel [181019 15:58]:
>> I uploaded my current status here. It's not based on the newest
>> -next, but contains the interesting patches from Laurent. Also
>> the last few patches are not yet cleaned up, sorry for the mess.
>
> Way to go, tha
The default-on property - or the def_value via legacy pdata) should be
handled as:
if it is 1, the backlight must be enabled (kept enabled)
if it is 0, the backlight must be disabled (kept disabled)
This only works for the case when default-on is set. If it is not set then
the brightness of the ba
In sisfb_find_rom(), the official pci ROM is checked to see whether it
contains the expected value at specific locations. This is done by firstly
mapping the rom into the IO memory region 'rom_base' and then invoking
sisfb_check_rom() to perform the checks. If the checks succeed, i.e.,
sisfb_check_
Remove some duplicated include.
Signed-off-by: YueHaibing
---
drivers/gpu/drm/amd/powerplay/inc/hwmgr.h | 1 -
drivers/gpu/drm/amd/powerplay/inc/smu7_common.h | 4
drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smumgr.c | 1 -
drivers/gpu/drm/amd/powerplay/smumgr/smu10
On Thu, Oct 18, 2018 at 3:59 PM Jordan Crouse wrote:
>
> The functions in dpu_dbg.c aren't used. The two main dump functions
> fail after a lookup from dpu_dbg_base.reg_base_list which turns out
> to never be populated and once those are removed the rest of the
> file doesn't make any sense.
>
> S
Hi David:
get_maintainer.pl still got your old e-mail.
Add airl...@redhat.com.
Loop Sean too.
Please review and apply these 2 patches.
Thanks,
Aaron
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/list
I got tired of fixing this in Renesas drivers manually, so I took the big
hammer. Remove this cumbersome code pattern which got copy-pasted too much
already:
- struct platform_device *pdev = to_platform_device(dev);
- struct ep93xx_keypad *keypad = platform_get_drvdata(pdev);
+ s
1 - 100 of 113 matches
Mail list logo
