https://bugs.freedesktop.org/show_bug.cgi?id=108521
Christian König changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Intel HDCP2.2 registers are defined with addr offsets and bit details.
v2:
Replaced the arith calc with _PICK [Sean Paul]
v3:
No changes.
v4:
%s/HDCP2_CTR_DDI/HDCP2_CTL_DDI [Uma]
v5:
Added parentheses for the parameters of macro.
v6:
No changes
v7:
No changes
Signed-off-by: Ramalingam
This patch adds HDCP register definitions for HDMI and DP HDCP
adaptations.
HDMI specific HDCP2.2 register definitions are added into drm_hdcp.h,
where as HDCP2.2 register offsets in DPCD offsets are defined at
drm_dp_helper.h.
v2:
bit_field definitions are replaced by macros. [Tomas and Jani]
This series defines the HDCP2.2 authentication messages at drm header
along with intel specific HDCP2.2 registers. And introduces a
structure intel_hdcp to wrap all hdcp related variables into it.
These patches were previously reviewed at
https://patchwork.freedesktop.org/series/38254/
Ramalingam
Considering significant number of HDCP specific variables, it will
be clean to have separate struct for HDCP.
New structure called intel_hdcp is added within intel_connector.
v2:
struct hdcp statically allocated. [Sean Paul]
enable and disable function parameters are retained.[Sean Paul]
v3:
This patch defines the hdcp2.2 protocol messages for authentication.
v2:
bit_fields are removed. Instead bitmasking used. [Tomas and Jani]
prefix HDCP_2_2_ is added to the macros. [Tomas]
v3:
No Changes.
v4:
Style and spellings are fixed [Uma]
v5:
Fix for macros.
v6:
comment for Type i
https://bugs.freedesktop.org/show_bug.cgi?id=108464
--- Comment #8 from Duncan Roe ---
(In reply to Alex Deucher from comment #1)
> Are you sure the bisect is correct? This commit just changes debugfs which
> shouldn't be triggered unless you actually write to the file in question.
> Please att
https://bugs.freedesktop.org/show_bug.cgi?id=108464
--- Comment #9 from Duncan Roe ---
(In reply to Alex Deucher from comment #7)
> (In reply to Duncan Roe from comment #6)
> > (In reply to Duncan Roe from comment #3)
> > > halt is fine btw, it's only reboot that breaks.
> > > Do you want extra d
Op 24-10-18 om 20:57 schreef Julia Lawall:
> The containing function is called with a spin_lock held, so GFP_KERNEL
> can't be used.
>
> julia
>
> -- Forwarded message --
> Date: Tue, 23 Oct 2018 17:14:25 +0800
> From: kbuild test robot
> To: kbu...@01.org
> Cc: Julia Lawall
> Sub
Op 25-10-18 om 08:53 schreef Christian König:
> Am 25.10.18 um 03:28 schrieb Zhou, David(ChunMing):
>> Reviewed-by: Chunming Zhou
>
> NAK, GFP_ATOMIC should be avoided.
>
> The correct solution is to move the allocation out of the spinlock or drop
> the lock and reacquire.
Yeah +1. Especially in
Am 25.10.18 um 09:51 schrieb Maarten Lankhorst:
> Op 25-10-18 om 08:53 schreef Christian König:
>> Am 25.10.18 um 03:28 schrieb Zhou, David(ChunMing):
>>> Reviewed-by: Chunming Zhou
>> NAK, GFP_ATOMIC should be avoided.
>>
>> The correct solution is to move the allocation out of the spinlock or dr
On Tue, 23 Oct 2018 15:44:43 +0200
Daniel Vetter wrote:
> On Tue, Oct 23, 2018 at 09:55:08AM +0200, Boris Brezillon wrote:
> > Hi Daniel,
> >
> > On Tue, 16 Oct 2018 14:57:43 +0200
> > Daniel Vetter wrote:
> >
> > > On Tue, Oct 16, 2018 at 11:40:45AM +0200, Boris Brezillon wrote:
> > > > T
https://bugs.freedesktop.org/show_bug.cgi?id=108547
Bug ID: 108547
Summary: RX550 amdgpu_job_timedout ring sdma0 timeout; failed
to send message; uvd_v6_0_enc_ring_test_ring;
amdgpu_device_ip_resume failed
Product: DRI
will send a fix soon.
Thanks,
David
On 2018年10月25日 15:57, Koenig, Christian wrote:
Am 25.10.18 um 09:51 schrieb Maarten Lankhorst:
Op 25-10-18 om 08:53 schreef Christian König:
Am 25.10.18 um 03:28 schrieb Zhou, David(ChunMing):
Reviewed-by: Chunming Zhou
NAK, GFP_ATOMIC should be avoid
drivers/gpu/drm/drm_syncobj.c:202:4-14: ERROR: function
drm_syncobj_find_signal_pt_for_point called on line 390 inside lock on line 389
but uses GFP_KERNEL
Find functions that refer to GFP_KERNEL but are called with locks held.
Semantic patch information:
The proposed change of converting t
https://bugs.freedesktop.org/show_bug.cgi?id=108547
Michel Dänzer changed:
What|Removed |Added
Component|DRM/AMDgpu |DRM/other
--- Comment #1 from Michel Dä
drivers/gpu/drm/drm_syncobj.c:202:4-14: ERROR: function
drm_syncobj_find_signal_pt_for_point called on line 390 inside lock on line 389
but uses GFP_KERNEL
Find functions that refer to GFP_KERNEL but are called with locks held.
Semantic patch information:
The proposed change of converting t
pls ignore this one, please review v2.
On 2018年10月25日 16:36, Chunming Zhou wrote:
drivers/gpu/drm/drm_syncobj.c:202:4-14: ERROR: function
drm_syncobj_find_signal_pt_for_point called on line 390 inside lock on line 389
but uses GFP_KERNEL
Find functions that refer to GFP_KERNEL but are ca
Am 25.10.18 um 10:53 schrieb Chunming Zhou:
drivers/gpu/drm/drm_syncobj.c:202:4-14: ERROR: function
drm_syncobj_find_signal_pt_for_point called on line 390 inside lock on line 389
but uses GFP_KERNEL
Find functions that refer to GFP_KERNEL but are called with locks held.
Semantic patch inf
On 2018年10月25日 16:56, Christian König wrote:
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -111,15 +111,16 @@ static struct dma_fence
uint64_t point)
{
struct drm_syncobj_signal_pt *signal_pt;
+ struct dma_fence *f = NULL;
+ struct drm_syncobj_stub_fence *fence =
Am 25.10.18 um 11:03 schrieb zhoucm1:
On 2018年10月25日 16:56, Christian König wrote:
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -111,15 +111,16 @@ static struct dma_fence
uint64_t point)
{
struct drm_syncobj_signal_pt *signal_pt;
+struct dma_fence *f = NULL;
+str
Op 25-10-18 om 10:53 schreef Chunming Zhou:
> drivers/gpu/drm/drm_syncobj.c:202:4-14: ERROR: function
> drm_syncobj_find_signal_pt_for_point called on line 390 inside lock on line
> 389 but uses GFP_KERNEL
>
> Find functions that refer to GFP_KERNEL but are called with locks held.
>
> Semantic
On 2018年10月25日 17:11, Koenig, Christian wrote:
Am 25.10.18 um 11:03 schrieb zhoucm1:
On 2018年10月25日 16:56, Christian König wrote:
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -111,15 +111,16 @@ static struct dma_fence
uint64_t point)
{
struct drm_syncobj_signal_pt
Am 25.10.18 um 11:20 schrieb zhoucm1:
On 2018年10月25日 17:11, Koenig, Christian wrote:
Am 25.10.18 um 11:03 schrieb zhoucm1:
On 2018年10月25日 16:56, Christian König wrote:
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -111,15 +111,16 @@ static struct dma_fence
uint64_t point)
{
On 2018年10月25日 17:23, Koenig, Christian wrote:
Am 25.10.18 um 11:20 schrieb zhoucm1:
On 2018年10月25日 17:11, Koenig, Christian wrote:
Am 25.10.18 um 11:03 schrieb zhoucm1:
On 2018年10月25日 16:56, Christian König wrote:
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -111,15 +111,16 @@ static struc
Am 25.10.18 um 11:28 schrieb zhoucm1:
On 2018年10月25日 17:23, Koenig, Christian wrote:
Am 25.10.18 um 11:20 schrieb zhoucm1:
On 2018年10月25日 17:11, Koenig, Christian wrote:
Am 25.10.18 um 11:03 schrieb zhoucm1:
On 2018年10月25日 16:56, Christian König wrote:
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -
On Thu, Oct 25, 2018 at 10:09:31AM +0200, Boris Brezillon wrote:
> On Tue, 23 Oct 2018 15:44:43 +0200
> Daniel Vetter wrote:
>
> > On Tue, Oct 23, 2018 at 09:55:08AM +0200, Boris Brezillon wrote:
> > > Hi Daniel,
> > >
> > > On Tue, 16 Oct 2018 14:57:43 +0200
> > > Daniel Vetter wrote:
> > >
On Thu, Oct 25, 2018 at 04:36:34PM +0800, Chunming Zhou wrote:
> drivers/gpu/drm/drm_syncobj.c:202:4-14: ERROR: function
> drm_syncobj_find_signal_pt_for_point called on line 390 inside lock on line
> 389 but uses GFP_KERNEL
>
> Find functions that refer to GFP_KERNEL but are called with locks
On 2018年10月25日 17:30, Koenig, Christian wrote:
Am 25.10.18 um 11:28 schrieb zhoucm1:
On 2018年10月25日 17:23, Koenig, Christian wrote:
Am 25.10.18 um 11:20 schrieb zhoucm1:
On 2018年10月25日 17:11, Koenig, Christian wrote:
Am 25.10.18 um 11:03 schrieb zhoucm1:
On 2018年10月25日 16:56, Chri
On Thu, 25 Oct 2018 11:33:14 +0200
Daniel Vetter wrote:
> On Thu, Oct 25, 2018 at 10:09:31AM +0200, Boris Brezillon wrote:
> > On Tue, 23 Oct 2018 15:44:43 +0200
> > Daniel Vetter wrote:
> >
> > > On Tue, Oct 23, 2018 at 09:55:08AM +0200, Boris Brezillon wrote:
> > > > Hi Daniel,
> > > >
>
On 2018年10月25日 17:38, Christian König wrote:
Am 25.10.18 um 11:35 schrieb Daniel Vetter:
On Thu, Oct 25, 2018 at 04:36:34PM +0800, Chunming Zhou wrote:
drivers/gpu/drm/drm_syncobj.c:202:4-14: ERROR: function
drm_syncobj_find_signal_pt_for_point called on line 390 inside lock
on line 389 but
On Fri, Oct 19, 2018 at 10:50:49AM +0200, Daniel Vetter wrote:
> Hi all,
Hi,
(Replying from my personal address as the work email seems to have let
this one go to /dev/null)
>
> This is just to collect feedback on this idea, and see whether the
> overall dri-devel community stands on all this.
drivers/gpu/drm/drm_syncobj.c:202:4-14: ERROR: function
drm_syncobj_find_signal_pt_for_point called on line 390 inside lock on line 389
but uses GFP_KERNEL
Find functions that refer to GFP_KERNEL but are called with locks held.
Generated by: scripts/coccinelle/locks/call_kern.cocci
v2:
synco
On Thu, Oct 25, 2018 at 11:58 AM Liviu Dudau wrote:
> On Fri, Oct 19, 2018 at 10:50:49AM +0200, Daniel Vetter wrote:
> > Hi all,
>
> Hi,
>
> (Replying from my personal address as the work email seems to have let
> this one go to /dev/null)
>
> >
> > This is just to collect feedback on this idea, a
Op 25-10-18 om 12:21 schreef Chunming Zhou:
> drivers/gpu/drm/drm_syncobj.c:202:4-14: ERROR: function
> drm_syncobj_find_signal_pt_for_point called on line 390 inside lock on line
> 389 but uses GFP_KERNEL
>
> Find functions that refer to GFP_KERNEL but are called with locks held.
>
> Generated
Am 25.10.18 um 12:36 schrieb Maarten Lankhorst:
> Op 25-10-18 om 12:21 schreef Chunming Zhou:
>> drivers/gpu/drm/drm_syncobj.c:202:4-14: ERROR: function
>> drm_syncobj_find_signal_pt_for_point called on line 390 inside lock on line
>> 389 but uses GFP_KERNEL
>>
>>Find functions that refer to
在 2018/10/25 18:36, Maarten Lankhorst 写道:
> Op 25-10-18 om 12:21 schreef Chunming Zhou:
>> drivers/gpu/drm/drm_syncobj.c:202:4-14: ERROR: function
>> drm_syncobj_find_signal_pt_for_point called on line 390 inside lock on line
>> 389 but uses GFP_KERNEL
>>
>>Find functions that refer to GFP_
Give this a nice summary,
drm/syncobj: Avoid kmalloc(GFP_KERNEL) under spinlock
Quoting Chunming Zhou (2018-10-25 11:21:05)
> drivers/gpu/drm/drm_syncobj.c:202:4-14: ERROR: function
> drm_syncobj_find_signal_pt_for_point called on line 390 inside lock on line
> 389 but uses GFP_KERNEL
>
> Fi
https://bugs.freedesktop.org/show_bug.cgi?id=107333
--- Comment #4 from Benjamin Hodgetts ---
To anyone checking, this is still an issue with versions:
Kernel 4.18.16, LLVM 8.0.0, Mesa 18.3.0-devel, XOrg 1.20.2.
Monitor is connected, but powered off:
Screen 0: minimum 320 x 200, current 1024 x
Hello,
This is the 2nd version of the VC4 load tracker patch.
Daniel, as you suggested, I've implemented a generic infrastructure to
track and report underrun errors (patch 1). Not sure this is what you
had in mind, but it seems to do the job for my use case, and should
allow me to easily track r
The DRM framework provides a generic way to report underrun errors.
Let's implement the necessary hooks to support it in the VC4 driver.
Signed-off-by: Boris Brezillon
---
Changes in v2:
- New patch
---
drivers/gpu/drm/vc4/vc4_drv.h | 3 ++
drivers/gpu/drm/vc4/vc4_hvs.c | 71 +
Display controllers usually provide a lot features like overlay planes,
hardware scalers, hardware rotations, ...
Most of the time those features work just fine when enabled
independently, but activating all of them at the same time tend to
show other limitations like the limited memory bus or scal
The HVS block is supposed to fill the pixelvalve FIFOs fast enough to
meet the requested framerate. The problem is, the HVS and memory bus
bandwidths are limited, and if we don't take these limitations into
account we might end up with HVS underflow errors.
This patch is trying to model the per-pl
https://bugs.freedesktop.org/show_bug.cgi?id=108542
--- Comment #1 from Nicholas Kazlauskas ---
Thanks for the bisection.
Would you mind posting a full dmesg log for your 4.18.8 kernel?
--
You are receiving this mail because:
You are the assignee for the bug.___
On Fri, Oct 19, 2018 at 10:50:49AM +0200, Daniel Vetter wrote:
> Hi all,
>
> This is just to collect feedback on this idea, and see whether the
> overall dri-devel community stands on all this. I think the past few
> cross-vendor uapi extensions all came with igts attached, and
> personally I thin
Hi Dave,
One fix to avoid applying link retraining workaround on eDP monitors
that was missing Fixes: (kindly pointed out by Jani) in addition
to the patches in previous PR.
I also got GVT PR for -next-fixes, but it had an issue with S-o-bs,
so I'll include it then in -fixes pull.
Regards, Joona
On Thu, 18 Oct 2018 at 21:07, Christian Gmeiner
wrote:
>
> Signed-off-by: Christian Gmeiner
> ---
> xf86drm.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/xf86drm.c b/xf86drm.c
> index 10df682b..4ee1337b 100644
> --- a/xf86drm.c
> +++ b/xf86drm.c
> @@ -3516,6 +3516,8 @@ static int
Am 24.10.18 um 16:55 schrieb Jordan Crouse:
> On Wed, Oct 24, 2018 at 07:10:23PM +0530, Sharat Masetty wrote:
>> Hi,
>>
>> Can you please review this and share your thoughts on this approach. We
>> primarily need a clean way to release the finished fence in case the job
>> was not pushed to the que
On Wed, Oct 24, 2018 at 03:28:30PM -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 Wed, Oct 24, 2018 at 03:28:33PM -0700, Manasi Navare wrote:
> Infoframes are used to send secondary data packets. This patch
> adds support for DSC Picture parameter set secondary data packets
> in the existing write_infoframe helpers.
>
> v2:
> * Rebase on drm-tip (Manasi)
>
> Cc: Jani Nikula
On Wed, Oct 24, 2018 at 03:28:34PM -0700, Manasi Navare wrote:
> DSC PPS secondary data packet infoframes are filled with
> DSC picure parameter set metadata according to the DSC standard.
> These infoframes are sent to the sink device and used during DSC
> decoding.
>
> v2:
> * Rebase ond drm-tip
On Wed, Oct 24, 2018 at 03:28:36PM -0700, Manasi Navare wrote:
> Display Stream Splitter registers need to be programmed to enable
> the joiner if two DSC engines are used and also to enable
> the left and the right DSC engines. This happens as part of
> the DSC enabling routine in the source in at
On Wed, Oct 24, 2018 at 03:28:37PM -0700, Manasi Navare wrote:
> 1. Disable Left/right VDSC branch in DSS Ctrl reg
> depending on the number of VDSC engines being used
> 2. Disable joiner in DSS Ctrl reg
>
> v3 (From Manasi):
> * Add Disable PG2 for VDSC on eDP
> v2 (From Manasi):
> * Use old_
On Wed, Oct 24, 2018 at 03:28:38PM -0700, Manasi Navare wrote:
> A separate power well 2 (PG2) is required for VDSC on eDP transcoder
> whereas all other transcoders use the power wells associated with the
> transcoders for VDSC.
> This patch adds a helper to obtain correct power domain depending o
Hi all,
So this is my 2nd attempt (more successful I hope also with CI) at
catching the mmu notifier deadlock using lockdep. Ingredients:
- cross-release patches resurrect (so that lockdep see through
flush_workqueue).
- fake lock context for mmu notifier callbacks (similar trick to
fs_reclaim
Since -rc1 we're hitting a bunch of lockdep splats using the new
cross-release stuff around the 2 kthread completions. In all cases
they are because totally independent uses of kthread are mixed up by
lockdep into the same locking class, creating artificial deadlocks.
Fix this by converting kthrea
This reverts the following commits:
commit 527187d28569e39c5d489d6306d3b79605cf85a6
Author: Ingo Molnar
Date: Mon Jan 8 17:27:19 2018 +0100
locking/lockdep: Remove cross-release leftovers
commit dba04eb76df982703fefc021a4d278347b6176a9
Author: David Sterba
Date: Mon Jan 8 16:27:31 2018
Just a bit of paranoia, since if we start pushing this deep into
callchains it's hard to spot all.
Signed-off-by: Daniel Vetter
---
mm/mmu_notifier.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c
index 82bb1a939c0e..744840e5636e 100644
--- a/mm/mmu_n
This is a similar idea to the fs_reclaim fake lockdep lock. It's
fairly easy to provoke a specific notifier to be run on a specific
range: Just prep it, and then munmap() it.
A bit harder, but still doable, is to provoke the mmu notifiers for
all the various callchains that might lead to them. But
We need to make sure implementations don't cheat and don't have a
possible schedule/blocking point deeply burried where review can't
catch it.
Signed-off-by: Daniel Vetter
---
mm/mmu_notifier.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/mm/mmu_notifier.c b/mm/mmu_
This was originally added in 7e7844226f10 ("lockdep: allow to disable
reclaim lockup detection") but a git log -G "GFP_NOLOCKDEP" indicates
it was never used.
Cc: Andrew Morton
Cc: Vlastimil Babka
Cc: Michal Hocko
Cc: Mel Gorman
Cc: Daniel Vetter
Cc: "Levin, Alexander (Sasha Levin)"
Cc: Mike
https://bugs.freedesktop.org/show_bug.cgi?id=108318
--- Comment #9 from John Galt ---
R600_DEBUG=nir works around this issue. If requested, I can provide apidoc of
this rendering issue.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=108521
--- Comment #14 from Robert Strube ---
Created attachment 142200
--> https://bugs.freedesktop.org/attachment.cgi?id=142200&action=edit
lspci (no eGPU)
lspci -t -nn -v output when the eGPU is *not* connected.
--
You are receiving this mail b
https://bugs.freedesktop.org/show_bug.cgi?id=108521
--- Comment #15 from Robert Strube ---
Created attachment 142201
--> https://bugs.freedesktop.org/attachment.cgi?id=142201&action=edit
sudo cat /proc/iomem when eGPU *not* connected
sudo cat /proc/iomem when eGPU *not* connected
--
You are
https://bugs.freedesktop.org/show_bug.cgi?id=108521
Robert Strube changed:
What|Removed |Added
Attachment #142200|lspci (no eGPU) |lspci with eGPU *not*
descriptio
https://bugzilla.kernel.org/show_bug.cgi?id=201505
--- Comment #5 from Jan Ziak (http://atom-symbol.net)
(0xe2.0x9a.0...@gmail.com) ---
Created attachment 279151
--> https://bugzilla.kernel.org/attachment.cgi?id=279151&action=edit
bisect.log
I bisected the issue but encountered some inconsiste
https://bugs.freedesktop.org/show_bug.cgi?id=108521
--- Comment #16 from Robert Strube ---
Created attachment 142202
--> https://bugs.freedesktop.org/attachment.cgi?id=142202&action=edit
fresh dmesg log booting system *without* eGPU
--
You are receiving this mail because:
You are the assignee
drivers/gpu/drm/drm_syncobj.c:202:4-14: ERROR: function
drm_syncobj_find_signal_pt_for_point called on line 390 inside lock on line 389
but uses GFP_KERNEL
Find functions that refer to GFP_KERNEL but are called with locks held.
Generated by: scripts/coccinelle/locks/call_kern.cocci
v2:
synco
Den 03.10.2018 21.24, skrev Neil Armstrong:
Hi Noralf,
Le 08/09/2018 15:46, Noralf Trønnes a écrit :
The CMA helper is already using the drm_fb_helper_generic_probe part of
the generic fbdev emulation. This patch makes full use of the generic
fbdev emulation by using its drm_client callbacks.
Den 27.09.2018 13.45, skrev Yannick FERTRE:
Hi Noralf,
many thanks for your patch.
Acked-by: Yannick Fertré
Applied to drm-misc-next, thanks.
Noralf.
On 09/08/2018 03:46 PM, Noralf Trønnes wrote:
The CMA helper is already using the drm_fb_helper_generic_probe part of
the generic fbdev
https://bugs.freedesktop.org/show_bug.cgi?id=108521
--- Comment #17 from Robert Strube ---
Created attachment 142203
--> https://bugs.freedesktop.org/attachment.cgi?id=142203&action=edit
lspci *with* eGPU attached at boot
--
You are receiving this mail because:
You are the assignee for the bu
https://bugs.freedesktop.org/show_bug.cgi?id=108521
--- Comment #18 from Robert Strube ---
Created attachment 142204
--> https://bugs.freedesktop.org/attachment.cgi?id=142204&action=edit
sudo cat /proc/iomem *with* eGPU connected at boot
--
You are receiving this mail because:
You are the ass
https://bugs.freedesktop.org/show_bug.cgi?id=108521
Robert Strube changed:
What|Removed |Added
Attachment #142205|fresh dmesg log booting |fresh dmesg log booting
descript
https://bugs.freedesktop.org/show_bug.cgi?id=108521
--- Comment #19 from Robert Strube ---
Created attachment 142205
--> https://bugs.freedesktop.org/attachment.cgi?id=142205&action=edit
fresh dmesg log booting system *wite* eGPU connected at boot
--
You are receiving this mail because:
You a
https://bugs.freedesktop.org/show_bug.cgi?id=108554
Bug ID: 108554
Summary: In kernel 4.14.59, monitor resolution is detected
correctly. In kernels after that, they are not
detected correctly.
Product: DRI
Version
https://bugs.freedesktop.org/show_bug.cgi?id=108554
Alex Deucher changed:
What|Removed |Added
CC||harry.wentl...@amd.com
--- Comment #1 fr
On Thu, Oct 25, 2018 at 12:11 PM Alex Gonzalez wrote:
>
> Select CONFIG_TOUCHSCREEN_GOODIX so that we can have functional touch
> screen by default on Digi International's AUO/Goodix LCD accessory kit used
> with the ConnectCore 6UL SBC Pro (ccimx6ulsbcpro) board.
>
> Signed-off-by: Alex Gonzalez
On Thu, Oct 25, 2018 at 12:10 PM Alex Gonzalez wrote:
>
> The ConnectCore 6UL SBC Pro has an AUO/Goodix LCD accessory kit that is
> connected on the LVDS interface through an on-board LVDS transceiver.
>
> This change adds support for the touch interface.
>
> Signed-off-by: Alex Gonzalez
Reviewe
On Thu, Oct 25, 2018 at 12:11 PM Alex Gonzalez wrote:
>
> This change adds support for the AUO G101EVN010 lcdif panel for the
> mxsfb DRM driver.
>
> Signed-off-by: Alex Gonzalez
> ---
> arch/arm/boot/dts/imx6ul-ccimx6ulsbcpro.dts | 18 ++
> 1 file changed, 18 insertions(+)
>
> d
Am Do., 25. Okt. 2018 um 15:35 Uhr schrieb Emil Velikov
:
>
> On Thu, 18 Oct 2018 at 21:07, Christian Gmeiner
> wrote:
> >
> > Signed-off-by: Christian Gmeiner
> > ---
> > xf86drm.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/xf86drm.c b/xf86drm.c
> > index 10df682b..4ee1337
Without this, the xserver relies on what the 3D driver exposes and
assumes that the display can handle it, and then the DRM driver
happily tries to scan out a tiled format.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/drm_simple_kms_helper.c | 8
drivers/gpu/drm/tinydrm/core/tinyd
Eric Anholt writes:
> I was going to start working on making the vc4 driver work with
> tinydrm panels, but it turned out tinydrm didn't have the panel I had
> previously bought. So, last night I ported the fbtft staging
> driver over to DRM.
>
> It seems to work (with DT at
> https://github.com
Quoting Chunming Zhou (2018-10-25 16:08:31)
> drivers/gpu/drm/drm_syncobj.c:202:4-14: ERROR: function
> drm_syncobj_find_signal_pt_for_point called on line 390 inside lock on line
> 389 but uses GFP_KERNEL
>
> Find functions that refer to GFP_KERNEL but are called with locks held.
>
> Generat
Sean Paul writes:
> On Fri, Oct 19, 2018 at 10:50:49AM +0200, Daniel Vetter wrote:
>> Hi all,
>>
>> This is just to collect feedback on this idea, and see whether the
>> overall dri-devel community stands on all this. I think the past few
>> cross-vendor uapi extensions all came with igts attach
On Thu, Oct 25, 2018 at 12:17:11PM -0400, thesve...@gmail.com wrote:
> From: Sven Van Asbroeck
>
> We used an oscilloscope to observe the actual polarity of the
> DI's pixel clock, and saw the following:
>
> DI_GENERAL bit 17 is SET:
> pixel data is stable on the pixel clock's FALLING edge
On 10/23/2018 05:57 PM, Brendan Higgins wrote:
> This patch set proposes KUnit, a lightweight unit testing and mocking
> framework for the Linux kernel.
>
> Unlike Autotest and kselftest, KUnit is a true unit testing framework;
> it does not require installing the kernel on a test machine or in a
On 2018-10-12 4:31 a.m., Koenig, Christian wrote:
> Am 12.10.2018 um 10:26 schrieb Michel Dänzer:
>> On 2018-10-11 9:44 p.m., Harry Wentland wrote:
>>> On 2018-10-03 04:25 AM, Mike Lothian wrote:
I'm curious to know whether this will/could work over PRIME
>>> I don't see why this shouldn't w
Op 25-10-18 om 14:01 schreef Chunming Zhou:
>
> 在 2018/10/25 18:36, Maarten Lankhorst 写道:
>> Op 25-10-18 om 12:21 schreef Chunming Zhou:
>>> drivers/gpu/drm/drm_syncobj.c:202:4-14: ERROR: function
>>> drm_syncobj_find_signal_pt_for_point called on line 390 inside lock on line
>>> 389 but uses GFP
On 2018-10-12 12:44 p.m., Nicholas Kazlauskas wrote:
> Modern display hardware is capable of supporting variable refresh rates.
> This patch introduces the "vrr_capable" property on the connector to
> allow userspace to query support for variable refresh rates.
>
> Atomic drivers should attach thi
On Mon, Oct 22, 2018 at 01:46:34PM -0700, Douglas Anderson wrote:
> 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 HP
On Mon, Oct 22, 2018 at 01:46:35PM -0700, Douglas Anderson wrote:
> 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 HP
On 2018-10-12 12:44 p.m., Nicholas Kazlauskas wrote:
> This patch introduces the 'vrr_enabled' CRTC property to allow
> dynamic control over variable refresh rate support for a CRTC.
>
> This property should be treated like a content hint to the driver -
> if the hardware or driver is not capable
On Mon, Oct 22, 2018 at 01:46:37PM -0700, 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
On 2018-10-12 12:44 p.m., Nicholas Kazlauskas wrote:
> These include the drm_connector 'vrr_capable' and the drm_crtc
> 'vrr_enabled' properties.
>
> Signed-off-by: Nicholas Kazlauskas
> ---
> Documentation/gpu/drm-kms.rst | 7 +++
> drivers/gpu/drm/drm_connector.c | 22
On Mon, Oct 22, 2018 at 01:46:38PM -0700, Douglas Anderson wrote:
> 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
On Mon, Oct 22, 2018 at 01:46:39PM -0700, Douglas Anderson wrote:
> 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.
>
On 2018-10-12 12:44 p.m., Nicholas Kazlauskas wrote:
> Support for AMDGPU specific FreeSync properties and ioctls are dropped
> from amdgpu_dm in favor of supporting drm variable refresh rate
> properties.
>
> The notify_freesync and set_freesync_property functions are dropped
> from amdgpu_displa
On Sun, Oct 21, 2018 at 11:32 PM YueHaibing wrote:
>
> 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 [-Wu
On Sun, Oct 21, 2018 at 11:32 PM YueHaibing wrote:
>
> Remove some duplicated include.
>
> Signed-off-by: YueHaibing
Applied. Thanks!
Alex
> ---
> drivers/gpu/drm/amd/powerplay/inc/hwmgr.h | 1 -
> drivers/gpu/drm/amd/powerplay/inc/smu7_common.h | 4
> drivers/gpu/
On Thu, Oct 18, 2018 at 08:40:11PM +0800, Icenowy Zheng wrote:
> 在 2018-10-18四的 14:23 +0300，Laurent Pinchart写道：
> > Hi Icenowy,
> >
> > On Thursday, 18 October 2018 13:00:05 EEST Icenowy Zheng wrote:
> > > 在 2018-10-18四的 11:53 +0300，Laurent Pinchart写道：
> > > > On Thursday, 18 October 2018 10:33:22
1 - 100 of 163 matches
Mail list logo
