https://bugzilla.kernel.org/show_bug.cgi?id=204805
--- Comment #1 from ilkka.pr...@gmail.com ---
Having something such as "make -j 20" of kernel sources while using a browser
in GPU-accelerated mode seems to contribute to this. Repeats on 5.2.14 as well
but logs don't show anything useful for some
Mark switch cases where we are expecting to fall through.
Fix the following warnings (Building: mpc512x_defconfig powerpc):
drivers/video/fbdev/fsl-diu-fb.c: In function ‘fsl_diu_ioctl’:
./include/linux/device.h:1750:2: warning: this statement may fall through
[-Wimplicit-fallthrough=]
_dev_wa
https://bugs.freedesktop.org/show_bug.cgi?id=111638
Bug ID: 111638
Summary: Include tools/ in documentation
Product: DRI
Version: unspecified
Hardware: Other
OS: All
Status: NEW
Severity: not set
https://bugs.freedesktop.org/show_bug.cgi?id=111637
Bug ID: 111637
Summary: Document configuration shadowing and clean up handling
that in igt_core
Product: DRI
Version: unspecified
Hardware: Other
OS: All
On Tue, Sep 10, 2019 at 01:06:50PM -0700, David Riley wrote:
> Factor function in preparation to generating scatterlist prior to locking.
Patches are looking good now, but they don't apply. What tree was used
to create them?
Latest virtio-gpu driver bits are in drm-misc-next (see
https://cgit.fr
https://bugs.freedesktop.org/show_bug.cgi?id=111591
--- Comment #15 from Shmerl ---
(In reply to Timothy Arceri from comment #14)
> Are you sure it is hanging? There is a huge amount of stuttering due to the
> game compiling shaders in-game. Its really bad the first time I run the
> apitrace but
https://bugs.freedesktop.org/show_bug.cgi?id=111591
--- Comment #14 from Timothy Arceri ---
(In reply to Shmerl from comment #13)
> (In reply to Timothy Arceri from comment #12)
> > For now you could try using the environment variable:
> >
> > allow_glsl_cross_stage_interpolation_mismatch=true
>
https://bugs.freedesktop.org/show_bug.cgi?id=111591
--- Comment #13 from Shmerl ---
(In reply to Timothy Arceri from comment #12)
> For now you could try using the environment variable:
>
> allow_glsl_cross_stage_interpolation_mismatch=true
Thanks! I tried setting it, and it shows the message t
https://bugs.freedesktop.org/show_bug.cgi?id=111591
--- Comment #12 from Timothy Arceri ---
For now you could try using the environment variable:
allow_glsl_cross_stage_interpolation_mismatch=true
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=111591
--- Comment #11 from Shmerl ---
Since the game is using Unreal Engine, I wonder if developers control shaders
directly, or it's something produced by UE toolchain that transpiles them from
something else. I mean it could be upstream UE bug.
Jus
https://bugs.freedesktop.org/show_bug.cgi?id=111591
--- Comment #10 from Timothy Arceri ---
Ok. apitrace was pointing me to the incorrect shaders I managed to find the
correct ones and can confirm this is a bug in the game itself. I have reported
the problem to the developers, lets see if they re
https://bugs.freedesktop.org/show_bug.cgi?id=111591
--- Comment #9 from Timothy Arceri ---
Thanks! I can reproduce the problem using the new trace.
It's strange the problem is caused by some shaders failing to link but the
error message doesn't match what the shaders actually do. Also dumping ou
https://bugs.freedesktop.org/show_bug.cgi?id=111077
--- Comment #35 from Matt Turner ---
(In reply to rol...@rptd.ch from comment #34)
> I do not see anything mentioned there. I've wget the file into
> /etc/portage/patches/media-libs/mesa/ directory, which did not exist.
> Anything else I need to
https://bugs.freedesktop.org/show_bug.cgi?id=110199
--- Comment #14 from guimarcalsi...@gmail.com ---
I'm also affected by this bug. I have an MSI Rx 570 and my monitor is an Acer
SA230. I'm using the display through HDMI since it doesn't have DP.
In Linux Manjaro with kernel 4.19 the problem pe
https://bugs.freedesktop.org/show_bug.cgi?id=111635
Bug ID: 111635
Summary: HD4550 fails to complete tests (radeon.test=2)
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
https://bugs.freedesktop.org/show_bug.cgi?id=111634
Bug ID: 111634
Summary: HD4550 lockup when starting blender
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severi
https://bugs.freedesktop.org/show_bug.cgi?id=111591
--- Comment #8 from Shmerl ---
Here is a new trace: https://uploadfiles.io/9uykx7nh
Now it's catching the hang moment. Replaying it doesn't hang the GPU though,
just produces some errors in the trace output.
--
You are receiving this mail bec
https://bugs.freedesktop.org/show_bug.cgi?id=111591
--- Comment #7 from Shmerl ---
Just replayed the trace - it ended before the buggy part. Something must have
interrupted it, or may be it has a size cap? I'll try making it again.
--
You are receiving this mail because:
You are the assignee fo
https://bugs.freedesktop.org/show_bug.cgi?id=111077
--- Comment #34 from rol...@rptd.ch ---
I do not see anything mentioned there. I've wget the file into
/etc/portage/patches/media-libs/mesa/ directory, which did not exist. Anything
else I need to do to get Gentoo to pick up the patch?
--
You
On Sat, Sep 07, 2019 at 09:58:46PM -0400, Ilia Mirkin wrote:
> On Wed, Aug 21, 2019 at 7:55 AM Thierry Reding
> wrote:
> >
> > On Wed, Aug 21, 2019 at 04:33:58PM +1000, Ben Skeggs wrote:
> > > On Wed, 14 Aug 2019 at 20:14, Gerd Hoffmann wrote:
> > > >
> > > > Hi,
> > > >
> > > > > > Changing t
For now just enable it in the probe function to allow i2c
access. Disabling also means resetting the register values
to default and according to the datasheet does not give
power savings
Tested on Kobo Clara HD.
Signed-off-by: Andreas Kemnade
---
changes in v2:
- simplification
- correct gpio di
To be able to handle the HWEN pin of the lm3630a, add
an enable gpio to the driver and a property.
Tested on Kobo Clara HD.
Changes in v2:
simplification and reordering
Andreas Kemnade (2):
dt-bindings: backlight: lm3630a: add enable_gpios
backlight: lm3630a: add an enable gpio for the HWEN
add enable-gpios to describe HWEN pin
Signed-off-by: Andreas Kemnade
---
changes in v2: add example
.../bindings/leds/backlight/lm3630a-backlight.yaml | 5 +
1 file changed, 5 insertions(+)
diff --git
a/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml
b/Do
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #36 from Sebastian Meyer ---
Created attachment 145326
--> https://bugs.freedesktop.org/attachment.cgi?id=145326&action=edit
umr output of sdma0/sdma1 after RotTR freeze
Applied the provided WIP patch to linux-mainline 5.3-rc8 and
https://bugs.freedesktop.org/show_bug.cgi?id=111077
--- Comment #33 from Matt Turner ---
It will show the patch being applied before configuration.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri
Userspace requested command buffer allocations could be too large
to make as a contiguous allocation. Use vmalloc if necessary to
satisfy those allocations.
Signed-off-by: David Riley
---
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 4 +-
drivers/gpu/drm/virtio/virtgpu_vq.c| 79 +++
Factor function in preparation to generating scatterlist prior to locking.
Signed-off-by: David Riley
---
drivers/gpu/drm/virtio/virtgpu_vq.c | 19 +++
1 file changed, 7 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c
b/drivers/gpu/drm/virtio/vir
https://bugs.freedesktop.org/show_bug.cgi?id=111482
--- Comment #17 from Robert ---
Thanks Andrew! I played around a little bit with the refresh rates. Between
40-60Hz there is no difference in idle power consumption. The mem clock stays
at 875Mhz and can't be changed.
The best refresh rate with
https://bugs.freedesktop.org/show_bug.cgi?id=111077
--- Comment #32 from rol...@rptd.ch ---
Is there a way I can verify the rebuilding has picked up the patch file? I
rebuild and started the application but the result is the same. Now I'm not
sure if the patch is not working or not picked up prop
On Tue, 10 Sep 2019 11:21:56 +0100
Daniel Thompson wrote:
[...]
> > > Is this needed?
> > >
> > > This is a remove path, not a power management path, and we have no idea
> > > what the original status of the pin was anyway?
> > >
> >
> > Looking at Ishdn on page 5 of the datasheet, switching
https://bugs.freedesktop.org/show_bug.cgi?id=111633
Bug ID: 111633
Summary: amdgpu driver crash with kernel NULL pointer
dereference
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
Hi Jean,
Please rebase your patch set onto linux-leds.git [0] -
we've had some updates in the meantime and now your
set doesn't apply.
Best regards,
Jacek Anaszewski
On 9/10/19 3:27 PM, Jean-Jacques Hiblot wrote:
> From: Tomi Valkeinen
>
> This patch adds basic support for a kernel driver to g
Devicetree aliases are missing, so that module autoloading
does not work properly.
Signed-off-by: Andreas Kemnade
---
drivers/video/backlight/lm3630a_bl.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/video/backlight/lm3630a_bl.c
b/drivers/video/backlight/lm3630
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #35 from Alexandr Kára ---
Created attachment 145324
--> https://bugs.freedesktop.org/attachment.cgi?id=145324&action=edit
UMR dump of registers on a GPU lockup
Sending dmesg output + UMR registers dump of both sdma0 and sdma1 for
On Tue, Sep 10, 2019 at 12:58:24PM +, Harry Wentland wrote:
> +Manasi, Gaurav
>
> On 2019-09-09 9:52 a.m., Benjamin Gaignard wrote:
> > Change scale_increment_interval and nfl_bpg_offset fields to
> > u32 to avoid W=1 warnings because we are testing them against
> > 65535.
> >
> > Signed-off-
On Tue 10-09-19 09:03:29, Tejun Heo wrote:
> Hello, Michal.
>
> On Tue, Sep 10, 2019 at 01:54:48PM +0200, Michal Hocko wrote:
> > > So, while it'd great to have shrinkers in the longer term, it's not a
> > > strict requirement to be accounted in memcg. It already accounts a
> > > lot of memory wh
On Tue, Sep 10, 2019 at 9:34 AM Robin Murphy wrote:
>
> On 06/09/2019 22:44, Rob Clark wrote:
> > From: Rob Clark
> >
> > One of the challenges we have to enable the aarch64 laptops upstream
> > is dealing with the fact that the bootloader enables the display and
> > takes the corresponding SMMU
On 10/09/2019 16:34, Rob Clark wrote:
On Tue, Sep 10, 2019 at 1:14 AM Joerg Roedel wrote:
On Fri, Sep 06, 2019 at 02:44:01PM -0700, Rob Clark wrote:
@@ -674,7 +674,7 @@ int iommu_group_add_device(struct iommu_group *group,
struct device *dev)
mutex_lock(&group->mutex);
list_ad
On 06/09/2019 22:44, Rob Clark wrote:
From: Rob Clark
One of the challenges we have to enable the aarch64 laptops upstream
is dealing with the fact that the bootloader enables the display and
takes the corresponding SMMU context-bank out of BYPASS. Unfortunately,
currently, the IOMMU framework
Hello, Michal.
On Tue, Sep 10, 2019 at 01:54:48PM +0200, Michal Hocko wrote:
> > So, while it'd great to have shrinkers in the longer term, it's not a
> > strict requirement to be accounted in memcg. It already accounts a
> > lot of memory which isn't reclaimable (a lot of slabs and socket
> > bu
On Tue, Sep 10, 2019 at 9:21 AM Ilia Mirkin wrote:
>
> On Tue, Sep 10, 2019 at 3:34 AM Mun, Gwan-gyeong
> wrote:
> >
> > On Sat, 2019-09-07 at 21:43 -0400, Ilia Mirkin wrote:
> > > On Sat, Sep 7, 2019 at 7:20 PM Mun, Gwan-gyeong
> > > wrote:
> > > > On Fri, 2019-09-06 at 09:24 -0400, Ilia Mirkin
https://bugzilla.kernel.org/show_bug.cgi?id=204805
Bug ID: 204805
Summary: BUG: kernel NULL pointer dereference, address:
0200
Product: Drivers
Version: 2.5
Kernel Version: 5.2.12
Hardware: x86-64
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #34 from Mathieu Belanger ---
Patch applied
Removed nodma from the /etc/environment
Will reboot at lunch time, Usually my IDEs trigger the crash. Will see how it
go.
--
You are receiving this mail because:
You are the assignee fo
This series introduces support for the LogiCVC display controller.
The controller is a bit unusual since it is usually loaded as
programmable logic on Xilinx FPGAs or Zynq-7000 SoCs.
More details are presented on the main commit for the driver.
More information about the controller is available on
https://bugs.freedesktop.org/show_bug.cgi?id=109628
--- Comment #16 from Johannes Hirte ---
Seems to be fixed now. Tested with v5.3-rc8-7-g3120b9a6a3f7 and resume from S3
Works without problems. Interestingly even v5.3-rc6-129-g265381004994 works now
without additional patches.
--
You are recei
On Tue, Sep 10, 2019 at 1:14 AM Joerg Roedel wrote:
>
> On Fri, Sep 06, 2019 at 02:44:01PM -0700, Rob Clark wrote:
> > @@ -674,7 +674,7 @@ int iommu_group_add_device(struct iommu_group *group,
> > struct device *dev)
> >
> > mutex_lock(&group->mutex);
> > list_add_tail(&device->list,
The Xylon LogiCVC is a display controller implemented as programmable
logic in Xilinx FPGAs.
Signed-off-by: Paul Kocialkowski
---
.../bindings/display/xylon,logicvc.txt| 188 ++
1 file changed, 188 insertions(+)
create mode 100644 Documentation/devicetree/bindings/displa
Introduces a driver for the LogiCVC display controller, a programmable
logic controller optimized for use in Xilinx Zynq-7000 SoCs and other
Xilinx FPGAs. The controller is mostly configured at logic synthesis
time so only a subset of configuration is left for the driver to
handle.
The following f
https://bugs.freedesktop.org/show_bug.cgi?id=111591
--- Comment #6 from Shmerl ---
(In reply to Pierre-Eric Pelloux-Prayer from comment #5)
>
>
> The attached trace doesn't cause a GPU hang here.
>
> Does it hang on your machine?
I recorded it until the freeze happened, and then had to do Alt+
https://bugs.freedesktop.org/show_bug.cgi?id=111591
--- Comment #5 from Pierre-Eric Pelloux-Prayer
---
(In reply to Shmerl from comment #4)
> Uploaded the trace here (should be valid for 30 days):
> https://ufile.io/kvf9t1eu
>
> Sorry for huge size, there is an unskippable cutscene in the begin
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #33 from Pierre-Eric Pelloux-Prayer
---
Created attachment 145323
--> https://bugs.freedesktop.org/attachment.cgi?id=145323&action=edit
wip patch
You can give a try to the attached kernel patch which hopefully could prevent
some
On Mon, Sep 09, 2019 at 04:06:33PM +0200, Thomas Zimmermann wrote:
> Support for vblank requires VSYNC to signal an interrupt, which is broken
> on Matrox chipsets. The workaround that is used here and in other free
> Matrox drivers is to program to the value of and
> enable the VLINE interrupt.
Den 10.09.2019 15.51, skrev Thomas Zimmermann:
> Hi
>
> Am 10.09.19 um 15:34 schrieb Noralf Trønnes:
>>
>>
>> Den 10.09.2019 14.48, skrev Thomas Zimmermann:
>>> Hi
>>>
>>> Am 10.09.19 um 13:52 schrieb Gerd Hoffmann:
On Mon, Sep 09, 2019 at 04:06:32PM +0200, Thomas Zimmermann wrote:
> Be
Hi
thanks for the feedback.
Am 10.09.19 um 16:01 schrieb Ville Syrjälä:
> On Mon, Sep 09, 2019 at 04:06:33PM +0200, Thomas Zimmermann wrote:
>> Support for vblank requires VSYNC to signal an interrupt, which is broken
>> on Matrox chipsets.
>
> I don't remember there being anything wrong with th
On Thu, Sep 05, 2019 at 10:17:45AM -0600, Mathieu Poirier wrote:
> From: Roger Quadros
>
> commit 42bf02ec6e420e541af9a47437d0bdf961ca2972 upstream
>
> Some platforms (e.g. TI's DRA7 USB2 instance) have more trouble
> with the metastability workaround as it supports only
> a High-Speed PHY and t
On 05/09/2019 20:05, Rob Clark wrote:
On Thu, Sep 5, 2019 at 10:03 AM Rob Clark wrote:
On Wed, Sep 4, 2019 at 11:06 AM Robin Murphy wrote:
On 04/09/2019 01:12, Rob Clark wrote:
On Tue, Sep 3, 2019 at 12:31 PM Fabio Estevam wrote:
Hi Jonathan,
On Tue, Sep 3, 2019 at 4:25 PM Jonathan Mar
On Thu, Sep 05, 2019 at 10:17:44AM -0600, Mathieu Poirier wrote:
> From: Tony Lindgren
>
> commit e128310ddd379b0fdd21dc41d176c3b3505a0832 upstream
>
> This adds support for get_timings() and check_timings()
> to get the driver working and properly initializes the
> timing information from DT.
>
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #32 from Sebastian Meyer ---
Having the same issues with my new Powercolor RX 5700 XT on Arch Linux.
System freezes after a couple of seconds when I try to run games like RotTR.
Other games I've tested, like Dota 2 for example, are u
On Mon, Sep 09, 2019 at 04:06:33PM +0200, Thomas Zimmermann wrote:
> Support for vblank requires VSYNC to signal an interrupt, which is broken
> on Matrox chipsets.
I don't remember there being anything wrong with the vsync interrupt.
What makes you think it's broken?
> The workaround that is use
Hi
Am 10.09.19 um 15:34 schrieb Noralf Trønnes:
>
>
> Den 10.09.2019 14.48, skrev Thomas Zimmermann:
>> Hi
>>
>> Am 10.09.19 um 13:52 schrieb Gerd Hoffmann:
>>> On Mon, Sep 09, 2019 at 04:06:32PM +0200, Thomas Zimmermann wrote:
Before updating the display from the console's shadow buffer, t
Den 10.09.2019 14.48, skrev Thomas Zimmermann:
> Hi
>
> Am 10.09.19 um 13:52 schrieb Gerd Hoffmann:
>> On Mon, Sep 09, 2019 at 04:06:32PM +0200, Thomas Zimmermann wrote:
>>> Before updating the display from the console's shadow buffer, the dirty
>>> worker now waits for vblank. This allows sever
On Sun, Sep 08, 2019 at 06:04:28PM +0200, Sam Ravnborg wrote:
> Hi Dan.
>
> On Wed, Sep 04, 2019 at 09:55:07PM +0300, Dan Carpenter wrote:
> > The "lvds->backlight" pointer could be NULL in situations were
> > of_parse_phandle() returns NULL. Also it's slightly cleaner to use
> > backlight_put()
On Tue, Sep 10, 2019 at 03:27:34PM +0200, Jean-Jacques Hiblot wrote:
> From: Tomi Valkeinen
>
> This patch adds a led-backlight driver (led_bl), which is similar to
> pwm_bl except the driver uses a LED class driver to adjust the
> brightness in the HW. Multiple LEDs can be used for a single back
From: Tomi Valkeinen
This patch adds basic support for a kernel driver to get a LED device.
This will be used by the led-backlight driver.
Only OF version is implemented for now, and the behavior is similar to
PWM's of_pwm_get() and pwm_put().
Signed-off-by: Tomi Valkeinen
Signed-off-by: Jean-
If the LED is acquired by a consumer device with devm_led_get(), it is
automatically released when the device is detached.
Signed-off-by: Jean-Jacques Hiblot
Acked-by: Pavel Machek
---
drivers/leds/led-class.c | 42
include/linux/leds.h | 2 ++
2 fi
From: Tomi Valkeinen
This patch adds a led-backlight driver (led_bl), which is similar to
pwm_bl except the driver uses a LED class driver to adjust the
brightness in the HW. Multiple LEDs can be used for a single backlight.
Signed-off-by: Tomi Valkeinen
Signed-off-by: Jean-Jacques Hiblot
Acke
This series aims to add a led-backlight driver, similar to pwm-backlight,
but using a LED class device underneath.
A few years ago (2015), Tomi Valkeinen posted a series implementing a
backlight driver on top of a LED device:
https://patchwork.kernel.org/patch/7293991/
https://patchwork.kernel.org
Add DT binding for led-backlight.
Signed-off-by: Jean-Jacques Hiblot
Reviewed-by: Daniel Thompson
---
.../bindings/leds/backlight/led-backlight.txt | 28 +++
1 file changed, 28 insertions(+)
create mode 100644
Documentation/devicetree/bindings/leds/backlight/led-backlight.txt
On Tue, Sep 10, 2019 at 3:34 AM Mun, Gwan-gyeong
wrote:
>
> On Sat, 2019-09-07 at 21:43 -0400, Ilia Mirkin wrote:
> > On Sat, Sep 7, 2019 at 7:20 PM Mun, Gwan-gyeong
> > wrote:
> > > On Fri, 2019-09-06 at 09:24 -0400, Ilia Mirkin wrote:
> > > > On Fri, Sep 6, 2019 at 7:43 AM Ville Syrjälä
> > > >
+Manasi, Gaurav
On 2019-09-09 9:52 a.m., Benjamin Gaignard wrote:
> Change scale_increment_interval and nfl_bpg_offset fields to
> u32 to avoid W=1 warnings because we are testing them against
> 65535.
>
> Signed-off-by: Benjamin Gaignard
> ---
> include/drm/drm_dsc.h | 6 --
> 1 file cha
On Monday, 2019-09-09 16:51:16 -0700, Alan Coopersmith wrote:
> On Solaris, sys/sysmacros.h has long-deprecated copies of major() & minor()
> but not makedev(). sys/mkdev.h has all three and is the preferred choice.
>
> So we check for sys/mkdev.h first, as autoconf's AC_HEADER_MAJOR does.
Revie
Hi
Am 10.09.19 um 13:52 schrieb Gerd Hoffmann:
> On Mon, Sep 09, 2019 at 04:06:32PM +0200, Thomas Zimmermann wrote:
>> Before updating the display from the console's shadow buffer, the dirty
>> worker now waits for vblank. This allows several screen updates to pile
>> up and acts as a rate limiter
https://bugs.freedesktop.org/show_bug.cgi?id=111236
--- Comment #14 from Víctor Jáquez ---
(In reply to Michel Dänzer from comment #13)
> Note that my patch is just a proof of concept pointing at where the issue
> lies. I hope it helps someone else come up with a proper fix.
:(
Who could review
https://bugs.freedesktop.org/show_bug.cgi?id=111232
--- Comment #7 from bibitocarlos ---
Created attachment 145321
--> https://bugs.freedesktop.org/attachment.cgi?id=145321&action=edit
dmesg
Tried this "amdgpu.ppfeaturemask=0x3fff" but iit doesnt work (from here:
https://bugzilla.kernel.or
On Sun, Sep 08, 2019 at 02:34:50PM +1000, Adam Zerella wrote:
> Using strncpy() does not always terminate the destination string.
> stracpy() is a alternative function that does, by using this new
> function we will no longer need to insert a null separator.
>
> Signed-off-by: Adam Zerella
> ---
On Fri 06-09-19 08:45:39, Tejun Heo wrote:
> Hello, Daniel.
>
> On Fri, Sep 06, 2019 at 05:34:16PM +0200, Daniel Vetter wrote:
> > > Hmm... what'd be the fundamental difference from slab or socket memory
> > > which are handled through memcg? Is system memory used by GPUs have
> > > further globa
On Wed, Aug 21, 2019 at 09:50:01PM +0300, Laurent Pinchart wrote:
> This change started as an attempt to remove the forward declaration of
> validate_displayid(), and ended up reorganising the DisplayID parsing
> code to fix serial intertwined issues.
>
> The drm_parse_display_id() function, which
On Mon, Sep 09, 2019 at 04:06:32PM +0200, Thomas Zimmermann wrote:
> Before updating the display from the console's shadow buffer, the dirty
> worker now waits for vblank. This allows several screen updates to pile
> up and acts as a rate limiter.
>
> Signed-off-by: Thomas Zimmermann
> ---
> dri
On Mon, Sep 09, 2019 at 04:06:33PM +0200, Thomas Zimmermann wrote:
> Support for vblank requires VSYNC to signal an interrupt, which is broken
> on Matrox chipsets. The workaround that is used here and in other free
> Matrox drivers is to program to the value of and
> enable the VLINE interrupt.
https://bugs.freedesktop.org/show_bug.cgi?id=110117
--- Comment #15 from leo60228 ---
This issue also occurs on Windows. AMD support says that it will be fixed in
the next Windows update; could they possibly contribute that same fix to Linux?
--
You are receiving this mail because:
You are the
On Tuesday, September 10, 2019 1:38 PM, Pekka Paalanen
wrote:
> On Tue, 10 Sep 2019 10:09:55 +
> Simon Ser cont...@emersion.fr wrote:
>
> > Currently the property docs don't specify whether it's okay for two planes
> > to
> > have the same zpos value and what user-space should expect in thi
On Mon, Sep 09, 2019 at 03:04:49PM +0200, Thomas Zimmermann wrote:
> VRAM MM and GEM VRAM are only used with each other. This patch set
> moves VRAM MM into GEM VRAM source files and cleans up the helper's
> public interface.
>
> Thomas Zimmermann (4):
> drm/vram: Move VRAM memory manager to GEM
https://bugs.freedesktop.org/show_bug.cgi?id=111630
Arek Hiler changed:
What|Removed |Added
CC||petri.latv...@intel.com
--- Comment #1 fro
On Tue, 10 Sep 2019 10:09:55 +
Simon Ser wrote:
> Currently the property docs don't specify whether it's okay for two planes to
> have the same zpos value and what user-space should expect in this case.
>
> The rule mentionned in the past was to disambiguate with object IDs. However
> some d
https://bugs.freedesktop.org/show_bug.cgi?id=111630
Bug ID: 111630
Summary: Generate a list of tags for the machine that runs the
testsuite
Product: DRI
Version: XOrg git
Hardware: Other
OS: All
On Mon, Sep 09, 2019 at 10:13:49PM +0200, Andreas Kemnade wrote:
> On Mon, 9 Sep 2019 11:57:29 +0100
> Daniel Thompson wrote:
>
> > On Sun, Sep 08, 2019 at 10:37:03PM +0200, Andreas Kemnade wrote:
> > > For now just enable it in the probe function to allow i2c
> > > access and disable it on remov
Currently the property docs don't specify whether it's okay for two planes to
have the same zpos value and what user-space should expect in this case.
The rule mentionned in the past was to disambiguate with object IDs. However
some drivers break this rule (that's why the ordering is documented as
On Tue, Sep 10, 2019 at 11:46:20AM +0200, Jean Delvare wrote:
> Hi Ville,
>
> On Mon, 2 Sep 2019 16:15:46 +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Let's make cea_db_offsets() a bit more convenient to use by
> > setting the start/end offsets to zero whenever the data block
> >
Hi
I'm investigating a way to label BO's in panfrost, similar to how VC4 does it
and realised that this could be something that's might be useful to all
drivers.
With that in mind, would anyone be opposed to add a DRM_IOCTL_BO_SET_LABEL in
DRM core that can be utilised by all drivers to label B
Hi,
On 9/10/19 9:50 AM, Michel Dänzer wrote:
On 2019-09-07 10:32 p.m., Hans de Goede wrote:
Bail from the pci_driver probe function instead of from the drm_driver
load function.
This avoid /dev/dri/card0 temporarily getting registered and then
unregistered again, sending unwanted add / remove
For handling PDE updates directly in the fault handler.
v2: fix typo in comment
Signed-off-by: Christian König
Reviewed-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_gem
While handling a page fault we can't wait for other ongoing GPU
operations or we can potentially run into deadlocks.
Signed-off-by: Christian König
Reviewed-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 1 +
drivers/gpu/dr
Setting the no_gpu_wait flag means that the allocate BO must be available
immediately and we can't wait for any GPU operation to finish.
Signed-off-by: Christian König
Acked-by: Felix Kuehling
---
drivers/gpu/drm/ttm/ttm_bo.c | 43 +---
1 file changed, 25 inserti
For handling PTE updates directly in the fault handler.
Signed-off-by: Christian König
Reviewed-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
b/drivers
For handling PD/PT clears directly in the fault handler.
Signed-off-by: Christian König
Reviewed-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
b/drivers
Next step towards HMM support. For now just silence the retry fault and
optionally redirect the request to the dummy page.
v2: make sure the VM is not destroyed while we handle the fault.
v3: fix VM destroy check, cleanup comments
Signed-off-by: Christian König
Reviewed-by: Felix Kuehling
---
This allows us to update page tables directly while in a page fault.
v2: use direct/delayed entities and still wait for moves
Signed-off-by: Christian König
Reviewed-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 5 +
drivers/gpu/drm/amd/amdgpu/amdgpu_vm_cpu.c | 16
Free the pasid only while the root PD is reserved. This prevents use after
free in the page fault handling.
Signed-off-by: Christian König
Reviewed-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 20 +---
1 file changed, 9 insertions(+), 11 deletions(-)
diff --g
For page fault handling we need to use a direct update which can't be
blocked by ongoing user CS.
Signed-off-by: Christian König
Reviewed-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c | 6 +++---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 21 +++--
drive
On Tue, 03 Sep 2019, Lyude Paul wrote:
> Unfortunately the DP MST helpers do not have much in the way of
> debugging utilities. So, let's add some!
>
> This adds basic debugging output for down sideband requests that we send
> from the driver, so that we can actually discern what's happening when
1 - 100 of 112 matches
Mail list logo
