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.
Signed-off-by: Mamta Shukla
---
drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 4 +--
drivers/gpu/drm/
We should get 'driver_data' from 'struct device' directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy.
drivers/gpu/drm/msm/dsi/dsi_host.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --
* Pavel Machek [181018 22:15]:
> Hi!
>
> > > I want to make it clear that I don't want to claim any privilege in
> > > getting
> > > patches merged first. I am however worried that, without an easy way to
> > > test
> > > DSI support, and without enough time to focus on it, I would break
> >
In amdgpu_read_bios_from_rom(), the header of the VBIOS is firstly copied
to 'header' from an IO memory region through
amdgpu_asic_read_bios_from_rom(). Then the header is checked to see whether
it is a valid header. If yes, the whole VBIOS, including the header, is
then copied to 'adev->bios'. The
On 10/18/2018 03:58 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.
Signed-off-by: Jord
We should get 'driver_data' from 'struct device' directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy.
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
di
We should get 'driver_data' from 'struct device' directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy.
.../gpu/drm/omapdrm/displays/panel-dsi-cm.c| 18 ++
1 file changed, 6 insertions(+)
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/radeon/radeon_legacy_tv.c: In function
'radeon_legacy_tv_init_restarts':
drivers/gpu/drm/radeon/radeon_legacy_tv.c:435:21: warning:
variable 'pll' set but not used [-Wunused-but-set-variable]
struct radeon_pll *pll;
It never use
* 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, thanks :) Here's a quick fix for issues with loading
We should get 'driver_data' from 'struct device' directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy.
drivers/gpu/drm/msm/msm_drv.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/dri
We should get 'driver_data' from 'struct device' directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy.
drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
d
On Sat, Oct 20, 2018 at 2:11 AM Sean Paul wrote:
>
> On Thu, Oct 18, 2018 at 2:33 PM 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
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
We should get 'driver_data' from 'struct device' directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy.
drivers/gpu/drm/msm/adreno/adreno_device.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
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
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_
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
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
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
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
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
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
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|
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"
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
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.
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
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
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: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 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
> >
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
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
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
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
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:
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
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)
+
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 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
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
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
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
Rodrigo Siqueira changed:
What|Removed |Added
Attachment #142137|GPG pub key |ssh pub key
description|
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
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
+++
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
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
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
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.
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 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
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 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
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
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
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)
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
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=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
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
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
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
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.
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=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
*
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 #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.
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 #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 #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=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 #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=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
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
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/
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
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
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
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
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
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.
___
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
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
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
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.__
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=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
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
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: 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, 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
1 - 100 of 113 matches
Mail list logo
