On Wed, Aug 14, 2019 at 05:09:30PM +0300, Dan Carpenter wrote:
> Hello james qian wang (Arm Technology China),
>
> The patch 5d51f6c0da1b: "drm/komeda: Add writeback support" from May
> 23, 2019, leads to the following static checker warning:
>
> drivers/gpu/drm/arm/display/komeda/komeda_wb
On Wed, 2019-08-07 at 23:07 +0200, Daniel Vetter wrote:
> On Wed, Aug 07, 2019 at 07:43:18AM +, Lisovskiy, Stanislav wrote:
> > On Tue, 2019-08-06 at 19:43 +0200, Daniel Vetter wrote:
> > > On Tue, Aug 6, 2019 at 4:06 PM Lisovskiy, Stanislav
> > > wrote:
> > > >
> > > > On Tue, 2019-08-06 at
On 19/08/2019 10:23, Lisovskiy, Stanislav wrote:
> On Wed, 2019-08-07 at 23:07 +0200, Daniel Vetter wrote:
>> On Wed, Aug 07, 2019 at 07:43:18AM +, Lisovskiy, Stanislav wrote:
>>> On Tue, 2019-08-06 at 19:43 +0200, Daniel Vetter wrote:
On Tue, Aug 6, 2019 at 4:06 PM Lisovskiy, Stanislav
>>
On Wed, Aug 14, 2019 at 02:29:57PM +, Shankar, Uma wrote:
>
>
> >-Original Message-
> >From: james qian wang (Arm Technology China) [mailto:james.qian.w...@arm.com]
> >Sent: Tuesday, August 13, 2019 3:12 PM
> >To: Shankar, Uma
> >Cc: intel-...@lists.freedesktop.org; dri-devel@lists.f
The patch 5d51f6c0da1b: "drm/komeda: Add writeback support" from May
23, 2019, leads to the following static checker warning:
drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c:151
komeda_wb_connector_add()
error: not allocating enough data 1592 vs 1584
This is a typo which
https://bugs.freedesktop.org/show_bug.cgi?id=111416
--- Comment #3 from Alfie Day ---
Created attachment 145089
--> https://bugs.freedesktop.org/attachment.cgi?id=145089&action=edit
xorg log
Log of starting X (at 4k30hz) and then increasing to 4k 60hz
--
You are receiving this mail because:
https://bugs.freedesktop.org/show_bug.cgi?id=111416
--- Comment #4 from Alfie Day ---
Created attachment 145090
--> https://bugs.freedesktop.org/attachment.cgi?id=145090&action=edit
dmesg
Log of dmesg, starting at 4k 30hz and increasing to 4k 60hz
--
You are receiving this mail because:
You
https://bugs.freedesktop.org/show_bug.cgi?id=111416
--- Comment #5 from Alfie Day ---
Thanks for getting back to me, I'm using this one right now:
https://aur.archlinux.org/packages/linux-amd-staging-drm-next-git/
I have tested on Arches standard kernel (5.2.8) and LTS kernel (4.19.67) all of
wh
On 14.08.2019 14:40, Daniel Vetter wrote:
> On Wed, Aug 14, 2019 at 01:04:03PM +0300, Laurent Pinchart wrote:
>> Hi Andrzej,
>>
>> On Wed, Aug 14, 2019 at 08:23:12AM +0200, Andrzej Hajda wrote:
>>> Hi Laurent,
>>>
>>> Sorry for late response.
>> No worries.
>>
>>> On 11.08.2019 00:43, Laurent Pinch
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #107 from magist3r ---
(In reply to reject5514 from comment #106)
> (In reply to magist3r from comment #105)
> > (In reply to reject5514 from comment #103)
> > > I have this problem on Archlinux 5.2.8-arch1-1-ARCH when connected 2
>
On Wed, Aug 14, 2019 at 10:47:40AM +, Mihail Atanassov wrote:
> On Wednesday, 14 August 2019 08:52:18 BST james qian wang (Arm Technology
> China) wrote:
> > On Tue, Aug 13, 2019 at 09:51:08AM +, Mihail Atanassov wrote:
> > > Hi James,
> > >
> > > On Tuesday, 13 August 2019 05:56:07 BST j
https://bugs.freedesktop.org/show_bug.cgi?id=110886
--- Comment #16 from Kai-Heng Feng ---
(In reply to Samantha McVey from comment #13)
> Created attachment 145085 [details]
> amd-staging-drm-net dmesg log
Doesn't look like the same one.
--
You are receiving this mail because:
You are the ass
Thank you Sam for review,
On Fri, 2019-08-09 at 17:25 +0200, Sam Ravnborg wrote:
> [External]
>
> Hi Bogdan.
>
> This patch triggered a few general comments.
>
> > --- a/drivers/gpu/drm/bridge/adv7511/Makefile
> > +++ b/drivers/gpu/drm/bridge/adv7511/Makefile
> > @@ -2,5 +2,5 @@
> > adv7511-y
On Mon, 2019-08-19 at 08:35 +0100, Peres, Martin wrote:
> On 19/08/2019 10:23, Lisovskiy, Stanislav wrote:
> > On Wed, 2019-08-07 at 23:07 +0200, Daniel Vetter wrote:
> > >
> > >
> > > So igt isn't valid userspace (it's just good testcases). Can we
> > > repro
> > > the
> > > same on real userspa
On 8/14/19 12:45 PM, Dariusz Marcinkiewicz wrote:
> Use the new cec_notifier_conn_(un)register() functions to
> (un)register the notifier for the HDMI connector, and fill
> in the cec_connector_info.
>
> Changes since v6:
> - move cec_notifier_conn_unregister to tda998x_bridge_detach,
>
On 8/14/19 12:45 PM, Dariusz Marcinkiewicz wrote:
> Use the new cec_notifier_conn_(un)register() functions to
> (un)register the notifier for the HDMI connector, and fill in
> the cec_connector_info.
>
> Changes since v6:
> - move cec_notifier_conn_unregister to a bridge detach
> f
On 8/14/19 12:45 PM, Dariusz Marcinkiewicz wrote:
> Use the new cec_notifier_conn_(un)register() functions to
> (un)register the notifier for the HDMI connector, and fill in
> the cec_connector_info.
>
> Changes since v2:
> - removed unnecessary call to invalidate phys address before
>
On 8/14/19 12:45 PM, Dariusz Marcinkiewicz wrote:
> Use the new cec_notifier_conn_(un)register() functions to
> (un)register the notifier for the HDMI connector, and fill in
> the cec_connector_info.
>
> Changes since v4:
> - only create a CEC notifier for HDMI connectors
>
> Signed-off-by:
On 8/14/19 12:45 PM, Dariusz Marcinkiewicz wrote:
> Use the new cec_notifier_conn_(un)register() functions to
> (un)register the notifier for the HDMI connector, and fill
> in the cec_connector_info.
>
> Changes since v2:
> Don't invalidate physical address before unregistering the
> n
https://bugs.freedesktop.org/show_bug.cgi?id=111416
--- Comment #6 from Alfie Day ---
Hi, based on your comment I went and plugged my nvidia machine into the TV
using the same cable and port. I then used xvidtune -show to extract the
modeline it was using: "3840x2160" 593.41 3840 4016 4104 44
https://bugs.freedesktop.org/show_bug.cgi?id=111416
--- Comment #7 from Alfie Day ---
Created attachment 145091
--> https://bugs.freedesktop.org/attachment.cgi?id=145091&action=edit
dmesg (with hotplugging)
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=111416
--- Comment #8 from Alfie Day ---
Created attachment 145092
--> https://bugs.freedesktop.org/attachment.cgi?id=145092&action=edit
Xorg log (with hotplugging)
--
You are receiving this mail because:
You are the assignee for the bug.__
On Mon, Aug 19, 2019 at 07:46:28AM +0200, Uwe Kleine-König wrote:
> Hello Matthias,
>
> On Fri, Aug 16, 2019 at 02:10:51PM -0700, Matthias Kaehlcke wrote:
> > On Fri, Aug 16, 2019 at 09:47:54PM +0200, Uwe Kleine-König wrote:
> > > On Fri, Aug 16, 2019 at 10:51:57AM -0700, Matthias Kaehlcke wrote:
On Thursday, August 15, 2019 12:47:35 AM CEST Dave Airlie wrote:
> On Thu, 15 Aug 2019 at 07:31, Karol Herbst wrote:
> >
> > This reverts commit 28586a51eea666d5531bcaef2f68e4abbd87242c.
> >
> > The original commit message didn't even make sense. AMD _does_ support it
> > and
> > it works with No
In light of recent review slip ups, the absence of a suite of tests for
dma-buf became apparent. Given the current plethora of testing
frameworks, opt for one already in use by Intel's CI and so allow easy
hook up into igt.
We introduce a new module that when loaded will execute the list of
selfte
Exercise the dma-fence API exported to drivers.
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
---
drivers/dma-buf/Makefile | 5 +-
drivers/dma-buf/selftests.h| 1 +
drivers/dma-buf/st-dma-fence.c | 571 +
3 files changed, 576 insertions(+), 1 deleti
Now that the timestamp and cb_list share the same slot in the fence,
with the current order of setting the timestamp before notifying the
cb_list, we have to take a temporary copy of the list. If we don't set
the timestamp, we can simply process the list in situ. This also gives
us the advantage th
On Fri, Aug 16, 2019 at 10:53:17AM -0700, Matthias Kaehlcke wrote:
> On Fri, Aug 16, 2019 at 04:54:18PM +0100, Daniel Thompson wrote:
> > On 07/08/2019 21:15, Matthias Kaehlcke wrote:
> > > On Tue, Jul 09, 2019 at 12:00:05PM -0700, Matthias Kaehlcke wrote:
> > > > Backlight brightness curves can ha
'_navi10_ip_offset_HEADER' is already used in 'navi10_ip_offset.h', so use
'_navi12_ip_offset_HEADER' instead here.
Signed-off-by: Christophe JAILLET
---
drivers/gpu/drm/amd/include/navi12_ip_offset.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/inc
On Saturday 17 August 2019 14:50:33 Alex Dewar wrote:
> Hi all,
>
> I'm getting frequent system crashes (every few hours or so) and it seems
> that the nouveau driver is causing the issue (dmesg output below). I see it
> with both v5.2.8 and the v4.19 LTS kernel. Sometimes the system
> completely f
Hi all,
The patches in this series can be applied independently from each other.
If you maintain one of these drivers and you want to merge it for v5.4
yourself, then please do so and let me know. If you prefer I commit it
to drm-misc, then please review and (hopefully) Ack the patch.
I would re
Static structure dlfb_ops, of type fb_ops, is not used except to be
copied into another variable. Hence make dlfb_ops constant to protect it
from unintended modification.
Issue found with Coccinelle.
Signed-off-by: Nishka Dasgupta
---
drivers/video/fbdev/udlfb.c | 2 +-
1 file changed, 1 inserti
From: Wei Hu Sent: Tuesday, August 13, 2019 2:55 AM
>
> Beginning from Windows 10 RS5+, VM screen resolution is obtained from host.
> The "video=hyperv_fb" boot time option is not needed, but still can be
> used to overwrite the VM resolution. The VM resolution on the host could be
I would word
Hello Daniel,
On Mon, Aug 19, 2019 at 10:50:37AM +0100, Daniel Thompson wrote:
> On Mon, Aug 19, 2019 at 07:46:28AM +0200, Uwe Kleine-König wrote:
> > Hello Matthias,
> >
> > On Fri, Aug 16, 2019 at 02:10:51PM -0700, Matthias Kaehlcke wrote:
> > > On Fri, Aug 16, 2019 at 09:47:54PM +0200, Uwe Kle
Hi Bogdan.
> > > adv7533_detach_dsi(adv7511);
> > > i2c_unregister_device(adv7511->i2c_cec);
> > > if (adv7511->cec_clk)
> > > @@ -1266,8 +1278,9 @@ static const struct i2c_device_id
> > > adv7511_i2c_ids[] = {
> > > { "adv7511", ADV7511 },
> > > { "adv7511w", ADV7511 },
> > >
On Monday, 19 August 2019 09:50:55 BST james qian wang (Arm Technology China)
wrote:
> On Wed, Aug 14, 2019 at 10:47:40AM +, Mihail Atanassov wrote:
> > On Wednesday, 14 August 2019 08:52:18 BST james qian wang (Arm Technology
> > China) wrote:
> > > On Tue, Aug 13, 2019 at 09:51:08AM +,
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #108 from tempel.jul...@gmail.com ---
I suppose also the Windows driver enforces maximum VRAM clock in your case all
the time? If that is true, it would definitely be a cool thing if we could get
a patch into upstream to cover that as
On Mon, Aug 19, 2019 at 12:21:27PM +0200, Uwe Kleine-König wrote:
> > > > In an ideal world the backlight interface would be consistent as you
> > > > suggest, however there are plenty of existing devices which use the
> > > > 'other' scaling (regardless of which is chosen as the 'correct'
> > > >
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #109 from magist3r ---
(In reply to tempel.julian from comment #108)
> I suppose also the Windows driver enforces maximum VRAM clock in your case
> all the time? If that is true, it would definitely be a cool thing if we
> could get
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #110 from tempel.jul...@gmail.com ---
(In reply to magist3r from comment #109)
> My patch fixes a bug that breaks this behavior when OverDrive mask is
> enabled, nothing more.
It unfortunately also forces my single display 1440p 75Hz
Use the new cec_notifier_conn_(un)register() functions to
(un)register the notifier for the HDMI connector, and fill
in the cec_connector_info.
Changes since v7:
- typo fix
Changes since v6:
- move cec_notifier_conn_unregister to tda998x_bridge_detach,
- add a mutex protect
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #111 from magist3r ---
(In reply to tempel.julian from comment #110)
> (In reply to magist3r from comment #109)
> > My patch fixes a bug that breaks this behavior when OverDrive mask is
> > enabled, nothing more.
>
> It unfortunatel
On Wed, Aug 14, 2019 at 10:28 AM Linus Walleij wrote:
> On Mon, Aug 12, 2019 at 9:30 AM Geert Uytterhoeven
> wrote:
> > When test-compiling the BCM2835 pin control driver on m68k:
> >
> > In file included from arch/m68k/include/asm/io_mm.h:32:0,
> > from arch/m68k/includ
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #112 from tempel.jul...@gmail.com ---
(In reply to magist3r from comment #111)
> It's not caused by my patch. Try to disable overdrive mask, revert the patch
> and you will see the same behavior.
There is dynamic VRAM clocking enable
On Mon, Aug 19, 2019 at 12:16:13PM +0100, Daniel Thompson wrote:
> On Mon, Aug 19, 2019 at 12:21:27PM +0200, Uwe Kleine-König wrote:
> > > > > In an ideal world the backlight interface would be consistent as you
> > > > > suggest, however there are plenty of existing devices which use the
> > > > >
https://bugs.freedesktop.org/show_bug.cgi?id=105651
--- Comment #6 from Redsandro ---
I'm having the same issue with a 4K Dell UP2414Q with 3840x2160 as
1920x2160+0+0, 1920x2160 +1920+0.
Is it possible to do a workaround in xorg.conf, similar to nVidia's TwinView
and nvidiaXineramaInfoOrder as d
https://bugs.freedesktop.org/show_bug.cgi?id=105651
--- Comment #7 from Alex Deucher ---
You need to be using the amdgpu driver if you are running xorg. I'm not sure
if the modesetting driver supports the tile property yet.
--
You are receiving this mail because:
You are the assignee for the b
https://bugs.freedesktop.org/show_bug.cgi?id=105651
--- Comment #8 from Tomas Bzatek ---
FYI starting with kernel 5.2 the tile property is propagated properly on Dell
UP2715K. The Mate desktop picks this up just fine.
--
You are receiving this mail because:
You are the assignee for the bug.
This patch fix a spelling typo in test-drm_mm.c
Signed-off-by: Masanari Iida
---
drivers/gpu/drm/selftests/test-drm_mm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/selftests/test-drm_mm.c
b/drivers/gpu/drm/selftests/test-drm_mm.c
index 388f9844f4ba..bb29
Applied. thanks!
Alex
On Sun, Aug 18, 2019 at 9:33 PM Yuan, Xiaojie wrote:
>
> Reviewed-by: Xiaojie Yuan
>
> Xiaojie
>
> > On Aug 19, 2019, at 12:00 AM, Christophe JAILLET
> > wrote:
> >
> > '_navi10_ip_offset_HEADER' is already used in 'navi10_ip_offset.h', so use
> > '_navi12_ip_offset_HEA
Quoting Masanari Iida (2019-08-19 14:05:52)
> This patch fix a spelling typo in test-drm_mm.c
>
> Signed-off-by: Masanari Iida
Reviewed-by: Chris Wilson
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mai
https://bugs.freedesktop.org/show_bug.cgi?id=111261
--- Comment #2 from Alex Deucher ---
Please attach your xorg log (if using X) and your dmesg output. What GPU are
you using?
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=204241
--- Comment #11 from Alex Deucher (alexdeuc...@gmail.com) ---
Does this patch fix it?
https://cgit.freedesktop.org/drm/drm/commit/?h=drm-fixes&id=72cda9bb5e219aea0f2f62f56ae05198c59022a7
--
You are receiving this mail because:
You are watching t
https://bugzilla.kernel.org/show_bug.cgi?id=204181
--- Comment #33 from Nicholas Kazlauskas (nicholas.kazlaus...@amd.com) ---
I(In reply to Sergey Kondakov from comment #26)
> Created attachment 284083 [details]
> dmesg_2019-08-02-amdgpu_fail_on_patched_5.2.5
>
> (In reply to Nicholas Kazlauskas
https://bugs.freedesktop.org/show_bug.cgi?id=105651
--- Comment #9 from Redsandro ---
@AlexDeucher I am using xserver-xorg-video-amdgpu. I can use 18.0.1 (No TILE
support, need workaround) or 19.0.1 (Cinnamon crashes, need workaround for time
being). I'm looking for a xorg config or xrandr comman
Hi Jacopo,
On Mon, Jul 8, 2019 at 9:58 AM Geert Uytterhoeven wrote:
> On Sat, Jul 6, 2019 at 4:07 PM Jacopo Mondi wrote:
> > Add device tree bindings documentation for the Renesas R-Car Display
> > Unit Color Management Module.
> >
> > CMM is the image enhancement module available on each R-Car
On 8/17/19 10:40 AM, Hans de Goede wrote:
> Hi,
Hi Hans,
> On 21-07-19 15:19, Hans de Goede wrote:
>> For various reasons, at least with x86 EFI firmwares, the xoffset and
>> yoffset in the BGRT info are not always reliable.
>>
>> Extensive testing has shown that when the info is correct, the
>>
On 7/22/19 10:33 PM, Gustavo A. R. Silva wrote:
> There is no need to compare *var->xoffset* or *var->yoffset* with < 0
> because such variables are of type unsigned, making it impossible to
> hold a negative value.
>
> Fix this by removing such comparisons.
>
> Addresses-Coverity-ID: 1451964 (
On 7/24/19 3:17 PM, Chuhong Yuan wrote:
> Instead of using to_pci_dev + pci_get_drvdata,
> use dev_get_drvdata to make code simpler.
>
> Signed-off-by: Chuhong Yuan
Patch queued for v5.4, thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
Hi,
On 19-08-19 16:01, Bartlomiej Zolnierkiewicz wrote:
On 8/17/19 10:40 AM, Hans de Goede wrote:
Hi,
Hi Hans,
On 21-07-19 15:19, Hans de Goede wrote:
For various reasons, at least with x86 EFI firmwares, the xoffset and
yoffset in the BGRT info are not always reliable.
Extensive testing
On 7/24/19 3:19 PM, Chuhong Yuan wrote:
> Instead of using to_pci_dev + pci_get_drvdata,
> use dev_get_drvdata to make code simpler.
>
> Signed-off-by: Chuhong Yuan
Patch queued for v5.4, thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
___
On 7/30/19 5:25 PM, Anders Roxell wrote:
> Now that -Wimplicit-fallthrough is passed to GCC by default, the
> following warnings shows up:
>
> ../drivers/video/fbdev/sh_mobile_lcdcfb.c: In function
> ‘sh_mobile_lcdc_channel_fb_init’:
> ../drivers/video/fbdev/sh_mobile_lcdcfb.c:2086:22: warning:
On 8/18/19 6:59 PM, Souptick Joarder wrote:
> On Mon, Aug 12, 2019 at 5:37 PM Souptick Joarder wrote:
>>
>> On Wed, Aug 7, 2019 at 2:11 PM Souptick Joarder wrote:
>>>
>>> On Wed, Jul 31, 2019 at 12:59 AM Souptick Joarder
>>> wrote:
This is dead code since 3.15. If there is no plan to
On 8/14/19 2:23 PM, Souptick Joarder wrote:
> On Wed, Aug 7, 2019 at 2:12 PM Souptick Joarder wrote:
>>
>> On Wed, Jul 31, 2019 at 12:38 AM Souptick Joarder
>> wrote:
>>>
>>> This is dead code since 3.15. If there is no plan to use it
>>> further, this can be removed forever.
>>
>> Any comment
On 8/19/19 11:32 AM, Hans Verkuil wrote:
> On 8/14/19 12:45 PM, Dariusz Marcinkiewicz wrote:
>> Use the new cec_notifier_conn_(un)register() functions to
>> (un)register the notifier for the HDMI connector, and fill in
>> the cec_connector_info.
>>
>> Changes since v6:
>> - move cec_notifie
On 8/7/19 6:13 PM, Gustavo A. R. Silva wrote:
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct mmp_path {
> ...
On 8/19/19 9:52 AM, Nishka Dasgupta wrote:
> Static structure dlfb_ops, of type fb_ops, is not used except to be
> copied into another variable. Hence make dlfb_ops constant to protect it
> from unintended modification.
> Issue found with Coccinelle.
>
> Signed-off-by: Nishka Dasgupta
Patch queu
On 8/16/19 3:32 PM, Laurent Pinchart wrote:
> On Fri, Aug 16, 2019 at 04:20:46PM +0300, Tomi Valkeinen wrote:
>> On 16/08/2019 15:22, Laurent Pinchart wrote:
>>> Standard DRM panel drivers for several panels used by omapfb2 are now
>>> available. Their module name clashes with the modules from
>>>
https://bugs.freedesktop.org/show_bug.cgi?id=111261
--- Comment #3 from Fab Stz ---
Thanks for your interest in that issue.
How could I do that with nothing visible on my monitors ? Is there any
parameter I can add to the kernel to keep a log ?
--
You are receiving this mail because:
You are t
Hi Daniel, Dave,
Here is a respin of the last drm-misc-next PR with the dma-buf revert
mentionned by Chris Wilson on the last mail.
Thanks!
Maxime
drm-misc-next-2019-08-19:
drm-misc-next for 5.4:
UAPI Changes:
Cross-subsystem Changes:
Core Changes:
- dma-buf: add reservation_object_fences h
Hi Chris,
On Fri, Aug 16, 2019 at 12:47:06PM +0100, Chris Wilson wrote:
> Quoting Maxime Ripard (2019-08-16 12:32:01)
> > Hi Daniel, Dave,
> >
> > Here's this week drm-misc-next PR.
> >
> > Maxime
> >
> > drm-misc-next-2019-08-16:
> > drm-misc-next for 5.4:
> >
> > UAPI Changes:
> >
> > Cross-subs
On 2019-08-18 11:27 a.m., Ondrej Zary wrote:
On Saturday 17 August 2019 14:50:33 Alex Dewar wrote:
Hi all,
I'm getting frequent system crashes (every few hours or so) and it seems
that the nouveau driver is causing the issue (dmesg output below). I see it
with both v5.2.8 and the v4.19 LTS kern
https://bugs.freedesktop.org/show_bug.cgi?id=111261
--- Comment #4 from Fab Stz ---
Created attachment 145098
--> https://bugs.freedesktop.org/attachment.cgi?id=145098&action=edit
System information (part1)
Please find attached:
- basic configuration details.
- addition information
As instruc
Hi,
On 7/22/19 3:14 AM, Shobhit Kukreti wrote:
> Fix RB2D_DC_BUSY and HORZ_AUTO_RATIO_INC defines to use "U" cast to
> avoid shifting signed 32 bit values by 31 bit problem. This is not a
> problem for gcc built kernel.
>
> However, the header file being a public api, other compilers may not
> h
On 14/08/2019 12:45, Dariusz Marcinkiewicz wrote:
> Use the new cec_notifier_cec_adap_(un)register() functions to
> (un)register the notifier for the CEC adapter.
>
> Also adds CEC_CAP_CONNECTOR_INFO capability to the adapter.
>
> Changes since v3:
> - add CEC_CAP_CONNECTOR_INFO to cec_allo
Hi Hans,
On 19/08/2019 16:05, Hans Verkuil wrote:
> On 8/19/19 11:32 AM, Hans Verkuil wrote:
>> On 8/14/19 12:45 PM, Dariusz Marcinkiewicz wrote:
>>> Use the new cec_notifier_conn_(un)register() functions to
>>> (un)register the notifier for the HDMI connector, and fill in
>>> the cec_connector_in
On 8/19/19 4:38 PM, Neil Armstrong wrote:
> Hi Hans,
>
> On 19/08/2019 16:05, Hans Verkuil wrote:
>> On 8/19/19 11:32 AM, Hans Verkuil wrote:
>>> On 8/14/19 12:45 PM, Dariusz Marcinkiewicz wrote:
Use the new cec_notifier_conn_(un)register() functions to
(un)register the notifier for the
On 8/17/19 2:20 AM, Petr Vandrovec wrote:
> Vlastimil Babka wrote on 8/16/2019 5:47 AM:
>> On 8/15/19 9:13 PM, Petr Vandrovec wrote:
>>> With iommu=off disks are visible, but USB keyboard (and other USB
>>> devices) does not work:
>>
>> I've been told iommu=soft might help.
>
> Thanks. I've rebui
On 19/08/2019 16:41, Hans Verkuil wrote:
> On 8/19/19 4:38 PM, Neil Armstrong wrote:
>> Hi Hans,
>>
>> On 19/08/2019 16:05, Hans Verkuil wrote:
>>> On 8/19/19 11:32 AM, Hans Verkuil wrote:
On 8/14/19 12:45 PM, Dariusz Marcinkiewicz wrote:
> Use the new cec_notifier_conn_(un)register() func
Hi Dariusz, Hans,
I can apply the dw-hdmi patches if necessary.
Neil
On 19/08/2019 11:38, Hans Verkuil wrote:
> Hi all,
>
> The patches in this series can be applied independently from each other.
>
> If you maintain one of these drivers and you want to merge it for v5.4
> yourself, then pleas
https://bugs.freedesktop.org/show_bug.cgi?id=109607
--- Comment #15 from CI Bug Log ---
The CI Bug Log issue associated to this bug has been updated.
### New filters associated
* shard-iclb5: igt@kms_flip@flip-vs-modeset-vs-hang-interruptible - dmesg-warn
- watchdog: BUG: soft lockup - CPU#\d s
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #113 from Adrian Przekwas ---
(In reply to tempel.julian from comment #108)
> I suppose also the Windows driver enforces maximum VRAM clock in your case
> all the time?
Windows users are reporting max vram clock if 2 (especially hi
On Mon, Aug 19, 2019 at 03:14:42PM +0200, Andrey Konovalov wrote:
> Fix tagged_ptr not being initialized when TBI is not enabled.
>
> Dan Carpenter
Guessing this was Reported-by, or has Dan introduced his own tag now? ;)
Got a link to the report?
Will
__
On 2019-08-15 at 11:43:54 +0300, Jani Nikula wrote:
> On Sat, 16 Feb 2019, Ramalingam C via dri-devel
> wrote:
> > Implements the DP adaptation specific HDCP2.2 functions.
> >
> > These functions perform the DPCD read and write for communicating the
> > HDCP2.2 auth message back and forth.
> >
>
https://bugzilla.kernel.org/show_bug.cgi?id=204181
--- Comment #34 from Sergey Kondakov (virtuous...@gmail.com) ---
(In reply to Nicholas Kazlauskas from comment #33)
> I(In reply to Sergey Kondakov from comment #26)
> > Created attachment 284083 [details]
> > dmesg_2019-08-02-amdgpu_fail_on_patch
Hi Bartlomiej
On Mon, Aug 19, 2019 at 04:16:26PM +0200, Bartlomiej Zolnierkiewicz wrote:
>
> On 8/16/19 3:32 PM, Laurent Pinchart wrote:
> > On Fri, Aug 16, 2019 at 04:20:46PM +0300, Tomi Valkeinen wrote:
> >> On 16/08/2019 15:22, Laurent Pinchart wrote:
> >>> Standard DRM panel drivers for sever
Enabling the HDCP1.4 and 2.2 on TGL by supporting the HW block movement
from DDI into transcoder.
v6:
Extending the I915-MEI HDCP interface to include the transcoder.
For register programming, transcoder is used instead of PIPE. Just
readability improvement
pipe and transcoder defini
ME FW takes the transcoder details for Gen12+ platforms, as HDCP HW
block is moved to transcoders.
hdcp_port_data is extended with enum transcoder. Payload structure is
modified and populated from the hdcp_port_data.
Signed-off-by: Ramalingam C
---
drivers/misc/mei/hdcp/mei_hdcp.c | 27 +++
For the reusability of the enum transcoder and enum pipe in other driver
modules (like mei_hdcp), enum port definition is moved from I915 local
header intel_display.h to drm/i915_drm.h
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/display/intel_display.h | 44 ---
include/
From Gen12 onwards, HDCP HW block is implemented within transcoders.
Till Gen11 HDCP HW block was part of DDI.
Hence required changes in HW programming is handled here.
As ME FW needs the transcoder detail on which HDCP is enabled
on Gen12+ platform, we are populating the detail in hdcp_port_data
https://bugs.freedesktop.org/show_bug.cgi?id=111261
--- Comment #5 from Fab Stz ---
Created attachment 145101
--> https://bugs.freedesktop.org/attachment.cgi?id=145101&action=edit
System information (part2 = logs)
I could get the logs/info through SSH
There was no Xorg.log probably because the
Hi Tomi, Laurent,
For the CEC framework we (Dariusz and myself) are working on code to associate
a drm_connector with a CEC adapter, making it easier for userspace to link the
two.
In order to do that I need the drm_connector structure when creating the
CEC adapter in hdmi4_cec.c. That's easy eno
On Mon, Aug 19, 2019 at 05:16:37PM +0200, Andrey Konovalov wrote:
> On Mon, Aug 19, 2019 at 5:03 PM Will Deacon wrote:
> >
> > On Mon, Aug 19, 2019 at 03:14:42PM +0200, Andrey Konovalov wrote:
> > > Fix tagged_ptr not being initialized when TBI is not enabled.
> > >
> > > Dan Carpenter
> >
> > Gu
Hi Hans,
On Mon, Aug 19, 2019 at 05:23:31PM +0200, Hans Verkuil wrote:
> Hi Tomi, Laurent,
>
> For the CEC framework we (Dariusz and myself) are working on code to associate
> a drm_connector with a CEC adapter, making it easier for userspace to link the
> two.
>
> In order to do that I need the
This reverts commit 5f2fd347eeff7d4ce271920efd47baaa18fe968c.
Re-enable enc2_dp_set_dsc_config. This function caused warnings
due to missing register definitions. With the registers added,
this now works
Signed-off-by: David Francis
Reviewed-by: Roman Li
Reviewed-by: Harry Wentland
---
.../gp
This reverts commit 55ad81f3510ec1a1c19e6a4d8a6319812d07d256.
optc dsc config was causing warnings due to missing register
definitions. With the registers restored, the function can
be re-enabled
The reverted commit also disabled sanity checks and dsc
power gating. The sanity check warnings are n
This reverts commit 80e80ec817f161560b4159608fb41bd289abede3.
This commit fixed an issue with underscan commits not updating all
needed timing values, but through various refactors it is no longer
necessary. It causes corruption on odm combine by
overwriting the halved h_active in the stream timin
We were using drm helpers to convert a timing into its
bandwidth, its bandwidth into pbn, and its pbn into timeslots
These helpers
-Did not take DSC timings into account
-Used the link rate and lane count of the link's aux device,
which are not the same as the link's current cap
-Did not take FEC
This reverts commit 55a6f5bbcf00a49565946c0a9b8c716313dc6c05.
This commit was accidentally promoted twice
Signed-off-by: David Francis
Reviewed-by: Roman Li
Reviewed-by: Harry Wentland
---
.../drm/amd/display/dc/dcn20/dcn20_hwseq.c| 4 --
.../gpu/drm/amd/display/dc/dcn20/dcn20_optc.c | 6
For DSC MST, sometimes monitors would break out
in full-screen static. The issue traced back to the
PPS generation code, where these variables were being used
uninitialized and were picking up garbage.
memset to 0 to avoid this
Signed-off-by: David Francis
---
drivers/gpu/drm/amd/display/dc/cor
1 - 100 of 244 matches
Mail list logo
