On 2018年09月03日 19:19, Christian König wrote:
Am 03.09.2018 um 12:07 schrieb Chunming Zhou:
在 2018/9/3 16:50, Christian König 写道:
Am 03.09.2018 um 06:13 schrieb Chunming Zhou:
在 2018/8/30 19:32, Christian König 写道:
[SNIP]
+
+struct drm_syncobj_wait_pt {
+ struct
This is an initial proposal for format modifiers for AMD hardware.
It uses 48 bits including a chip generation, leaving 8 bits for
a format version number.
On gfx6-gfx8 we have all the fields influencing sample locations
in memory.
Tile split bytes are optional for single sample buffers as no
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/nvkm/engine/disp/Kbuild| 1 +
.../gpu/drm/nouveau/nvkm/engine/disp/hdmigm200.c | 34 ++
drivers/gpu/drm/nouveau/nvkm/engine/disp/ior.h | 2 ++
.../gpu/drm/nouveau/nvkm/engine/disp/sorgm200.c| 1 +
When SCDC is supported, make sure that we configure the GPU and monitor
to the same parameters.
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 40 -
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git
This is the beginnings of HDMI 2.0 support. All of the "extra"
features are left out, such as 12/16bpc, YUV420, etc.
I've verified that with this code, a GP108 (GT1030) can switch between
4k@60 and 1920x1080@60 on a LG 4K TV. Further, I've verified via i2c
tools, that the SCDC writes really do
Scrambling is required for supporting any mode over 340MHz. If it's not
supported, reject any modes that would require it.
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 34 +++--
1 file changed, 22 insertions(+), 12 deletions(-)
diff --git
The register programmed by the clock method needs to contain a different
setting for the link speed as well as special divider settings.
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/nvkm/engine/disp/hdmigm200.c | 2 ++
drivers/gpu/drm/nouveau/nvkm/engine/disp/ior.h | 5 +
High pixel clocks are required to use a 40 TMDS divider instead of 10,
and even low ones may optionally use scrambling depending on device
support.
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/include/nvif/cl5070.h | 5 -
drivers/gpu/drm/nouveau/nvkm/engine/disp/ior.h
For the series,
Reviewed-by: Dave Airlie
On Wed, 29 Aug 2018 at 22:20, Gerd Hoffmann wrote:
>
> Use the dma mapping api and properly add iommu mappings for
> objects, unless virtio is in iommu quirk mode.
>
> Signed-off-by: Gerd Hoffmann
> ---
> drivers/gpu/drm/virtio/virtgpu_drv.h | 1 +
>
On Tue, 14 Aug 2018 at 01:30, Gerd Hoffmann wrote:
>
> Track whenever an virtual output (crtc) is enabled or disabled.
>
> On atomic updates check for both framebuffer being present and crtc
> being enabled to figure whenever the output is active or not.
>
> Signed-off-by: Gerd Hoffmann
>
> I've seen that you dropped this patch:
> https://patchwork.kernel.org/patch/10445393/
>
> Is that patch correct or incorrect? In case it is incorrect, do you have
> an idea how should fbdefio be used properly on KMS drivers?
I suppose I was wondering what use fbdefio really has, modern code
https://bugs.freedesktop.org/show_bug.cgi?id=107690
Gleb Zasyadko changed:
What|Removed |Added
Product|xorg|DRI
On Tue, 31 Jul 2018, Dave Airlie wrote:
> Pull request to myself just so it's logged and linked in right place,
> but this is a set of Mikulas's udl kms patches I've looked over and am
> happy with.
>
> Dave.
I've seen that you dropped this patch:
https://patchwork.kernel.org/patch/10445393/
On Mon, Sep 3, 2018 at 9:50 PM Bjorn Andersson
wrote:
> On Tue 28 Aug 15:39 PDT 2018, Abhinav Kumar wrote:
> > From: "abhin...@codeaurora.org"
> >
> > Add support for Truly NT35597 panel driver used
> > in MSM reference platforms.
> >
> > This panel driver supports both single DSI and dual DSI
>
https://bugs.freedesktop.org/show_bug.cgi?id=107781
--- Comment #6 from Alex Findler ---
I was afraid you'd ask that. Last time I built a kernel myself I was on
Slackware 8. But I cloned the linux git repo yesterday in anticipation. I'll
give it a try.
https://bugs.freedesktop.org/show_bug.cgi?id=107261
--- Comment #4 from Elie B ---
I am also getting a similar error only when using Wayland. When switching to
Xorg I no longer get it.
So is an issue related to Wayland or is it just because Wayland may use a
mechanism that Xorg don't?
--
You
https://bugs.freedesktop.org/show_bug.cgi?id=107572
--- Comment #20 from Paju ---
I ran some Unigine tests with different kernels. No crashes with 4.13.12 and
older kernels. Maybe somebody could try to run these tests too and confirm
this?
--
You are receiving this mail because:
You are the
https://bugs.freedesktop.org/show_bug.cgi?id=107819
Bug ID: 107819
Summary: DRM radeon GPU fault detected (gem object lookup
failed)
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux
On 3 September 2018 at 17:54, Daniel Vetter wrote:
> -Hide legacy cruft better
> -
> -
> -Way back DRM supported only drivers which shadow-attached to PCI devices with
> -userspace or fbdev drivers setting up outputs. Modern DRM drivers take charge
> -of the entire
Hi Daniel.
> -Note that this is well in progress, but ``drmP.h`` is still huge. The updated
> -plan is to switch to per-file driver API headers, which will also structure
> -the kerneldoc better. This should also allow more fine-grained ``#include``
> -directives.
> +The DRM subsystem originally
On Mon, Sep 3, 2018 at 12:45 PM, Daniel Vetter wrote:
> On Mon, Sep 03, 2018 at 12:57:54PM +0200, Gerd Hoffmann wrote:
>> Userspace on big endian machhines typically expects the ADDFB ioctl
>> returns a big endian framebuffer. drm_mode_addfb() will call
>> drm_mode_addfb2() unconditionally with
On 2018-09-03 6:45 p.m., Daniel Vetter wrote:
> On Mon, Sep 03, 2018 at 12:57:54PM +0200, Gerd Hoffmann wrote:
>> Userspace on big endian machhines typically expects the ADDFB ioctl
>> returns a big endian framebuffer. drm_mode_addfb() will call
>> drm_mode_addfb2() unconditionally with little
On 09/03/2018 06:33 PM, Daniel Vetter wrote:
On Mon, Sep 03, 2018 at 11:16:29AM +0200, Thomas Hellstrom wrote:
On 08/31/2018 05:30 PM, Thomas Hellstrom wrote:
On 08/31/2018 05:27 PM, Emil Velikov wrote:
On 31 August 2018 at 15:38, Michel Dänzer wrote:
[ Adding the amd-gfx list ]
On
We already have a separate overview doc for this, makes sense to
untangle it from the overall atomic helpers.
Signed-off-by: Daniel Vetter
---
Documentation/gpu/drm-kms-helpers.rst | 19 +-
drivers/gpu/drm/Makefile | 3 +-
drivers/gpu/drm/drm_atomic_helper.c | 568
Motivated by vmwgfx digging around in core uapi bits it shouldn't dig
around in.
Signed-off-by: Daniel Vetter
---
include/drm/drm_atomic.h | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
index
That's purely for the uapi layer to implement the ALLOW_MODESET flag.
Drivers should instead look at the state, e.g. through
drm_atomic_crtc_needs_modeset(), which vmwgfx already does. Also remove
the confusing comment, since checking allow_modeset is at best a micro
optimization.
Signed-off-by:
The idea behind allowing drivers to override legacy ioctls (instead of
using the generic implementations unconditionally) is to handle bugs
in old driver-specific userspace. Like e.g. vmw_kms_set_config does,
to work around some vmwgfx userspace not clearing its ioctl structs
properly.
But you
For atomic driver this is the default, no need to reimplement it. We
still need to keep the copypasta for not-atomic drivers though, since
no one polished the legacy crtc helpers as much as the atomic ones.
Signed-off-by: Daniel Vetter
Cc: Alex Deucher
Cc: Harry Wentland
Cc: Andrey Grodzovsky
The core _does_ the call to drm_atomic_commit for you. That's pretty
much the entire point of having the fancy new atomic_set/get_prop
callbacks.
Signed-off-by: Daniel Vetter
Cc: VMware Graphics
Cc: Sinclair Yeh
Cc: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 6 --
1 file
This leaves all the commit/check and state handling in drm_atomic.c,
while pulling all the uapi glue and the huge ioctl itself into a
seprate file.
This seems to almost perfectly split the rather big drm_atomic.c file
into 2 equal sizes.
Also adjust the kerneldoc and type a very terse overview
It's the default. The exported version was kinda a transition state,
before we made this the default.
To stop new atomic drivers from using it (instead of just relying on
the default) let's unexport it.
Signed-off-by: Daniel Vetter
Cc: Gustavo Padovan
Cc: Maarten Lankhorst
Cc: Sean Paul
Cc:
- drmP.h is now fully split up.
- vkms is happening (and will gain its own todo and docs under a new
vkms.rst file real soon)
- legacy cruft is completely hidden now, drm_vblank.c is split out
from drm_irq.c now.
- best_encoder atomic cleanup is done (it's now the default, not even
exported
Just a bit of missing includes and pre declarations.
v2: Compiles now, with drm/kernel.h extracted.
Reviewed-by: Sean Paul
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc_internal.h | 8
drivers/gpu/drm/drm_plane.c | 11 ++-
include/drm/drm_color_mgmt.h
We have a bunch of neat little macros all over the place which should
move to kernel.h. But some of them died in bikesheds on lkml, and we
need a decent home for them.
Start out by moving the for_each_if macro there.
Cc: Sean Paul
Signed-off-by: Daniel Vetter
---
This is starting to become easy!
v2: Compiles now, with drm/kernel.h extracted.
Reviewed-by: Sean Paul
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
Remove the kerneldoc and EXPORT_SYMBOL which aren't used and really
shouldn't ever be used by drivers directly.
Unfortunately this means we need to move the set_writeback_fb function
around to avoid a forward decl.
Signed-off-by: Daniel Vetter
Cc: David Airlie
Cc: Gustavo Padovan
Cc: Maarten
Only needed minimal changes in drm_internal.h (for the drm_ioctl_t
type and a few forward declarations), plus a few missing includes in
drm_connector.c.
Yay, the last stage of the drm header cleanup can finally commence!
v2: Compiles now, with drm/kernel.h extracted.
Reviewed-by: Sean Paul
On Wed, Aug 22, 2018 at 10:54:04AM +0200, Daniel Vetter wrote:
> DRM drivers really, really, really don't want random userspace to
> share buffer behind it's back, bypassing the dma-buf buffer sharing
> machanism. For that reason we've ruthlessly rejected any IOCTL
> exposing the physical address
On Mon, Sep 03, 2018 at 12:57:54PM +0200, Gerd Hoffmann wrote:
> Userspace on big endian machhines typically expects the ADDFB ioctl
> returns a big endian framebuffer. drm_mode_addfb() will call
> drm_mode_addfb2() unconditionally with little endian DRM_FORMAT_*
> values though, which is wrong.
On Mon, Sep 03, 2018 at 10:31:55AM +0100, Chris Wilson wrote:
> Using a spinlock to serialize the destroy function, within the destroy
> function itself does not prevent the buggy driver from shooting
> themselves in the foot - either way they still have a use-after-free
> issue.
>
> Reported-by:
On Mon, Sep 03, 2018 at 11:16:29AM +0200, Thomas Hellstrom wrote:
> On 08/31/2018 05:30 PM, Thomas Hellstrom wrote:
> > On 08/31/2018 05:27 PM, Emil Velikov wrote:
> > > On 31 August 2018 at 15:38, Michel Dänzer wrote:
> > > > [ Adding the amd-gfx list ]
> > > >
> > > > On 2018-08-31 3:05 p.m.,
On Mon, Sep 03, 2018 at 01:31:34PM +0200, Bartlomiej Zolnierkiewicz wrote:
> On Monday, September 03, 2018 09:43:15 AM Daniel Vetter wrote:
> > On Sat, Sep 01, 2018 at 04:08:41PM +0200, Michał Mirosław wrote:
> > > This series cleans up duplicated code for replacing firmware FB
> > > driver with
On Sat, Sep 01, 2018 at 04:08:45PM +0200, Michał Mirosław wrote:
> Almost all PCI drivers using remove_conflicting_framebuffers() wrap it
> with the same code.
>
> ---
This cuts away the sob. Just fyi.
-Daniel
> v2: add kerneldoc for DRM helper
> v3: propagate remove_conflicting_framebuffers()
https://bugs.freedesktop.org/show_bug.cgi?id=107781
--- Comment #5 from Michel Dänzer ---
Any chance you can try if the problem also occurs with an upstream 4.17 or 4.18
kernel?
--
You are receiving this mail because:
You are the assignee for the
Hey
On Mon, Sep 3, 2018 at 4:47 PM Hans de Goede wrote:
>
> Hi,
>
> On 03-09-18 16:16, Bartlomiej Zolnierkiewicz wrote:
> >
> > Hi,
> >
> > On Monday, September 03, 2018 03:23:38 PM David Herrmann wrote:
> >> Hey
> >>
> >> Since this commit:
> >>
> >> 34db50e55656 efifb: Copy the ACPI BGRT
https://bugs.freedesktop.org/show_bug.cgi?id=107784
--- Comment #4 from Sylvain BERTRAND ---
I did a manual bisection and got lucky:
faulty commit: 019cddc88f9e4ae0de2c76802f7137210c2101aa on amd-staging-drm-next
this commit is i2c related, right before the commit
Hi,
On 03-09-18 16:16, Bartlomiej Zolnierkiewicz wrote:
Hi,
On Monday, September 03, 2018 03:23:38 PM David Herrmann wrote:
Hey
Since this commit:
34db50e55656 efifb: Copy the ACPI BGRT
the kernel will override boot-splashs unasked. This breaks the
graphical boot-process on our
Den 02.09.2018 22.56, skrev Sam Ravnborg:
Hi Noralf.
Only nitpicks, I have not the background
to review the actual implmentation.
So no tags from me to put on the commit.
Sam
+/**
+ * drm_gem_shmem_create - Allocate an object with the given size
+ * @dev: DRM device
+ * @size: Size
Hi,
On Monday, September 03, 2018 03:23:38 PM David Herrmann wrote:
> Hey
>
> Since this commit:
>
> 34db50e55656 efifb: Copy the ACPI BGRT
>
> the kernel will override boot-splashs unasked. This breaks the
> graphical boot-process on our setups. In particular, we have a setup
> where an
https://bugzilla.kernel.org/show_bug.cgi?id=200621
--- Comment #10 from Jon (jon...@gmail.com) ---
Upgraded to 4.18.5 and have been running that since 8/29. I've had the same
amount of freezing, but no more errors in the journal. This morning it was a
complete freeze while using Firefox.
Commit 08295b3b5bee ("Implement an algorithm choice for Wound-Wait
mutexes") introduced a reference in the documentation to a function
that was removed in an earlier commit.
It also forgot to remove a call to debug_mutex_add_waiter() which is now
unconditionally called by __mutex_add_waiter().
Hardware allow to read the position in scanout buffer so
we can use this information to make wait of vblank more accurate.
Active area bounds (start, end, total height) have already been
computed and written in ltdc registers, read them and get the
current line position to compute vpos value.
Hi Dave,
Please pull omapdrm changes for v4.20.
I'm sending these early to get as much linux-next time as possible. We may get
some more
patches later in the -rc cycle, but this pull request should be the bulk of the
changes.
Tomi
The following changes since commit
https://bugs.freedesktop.org/show_bug.cgi?id=105379
--- Comment #7 from Andrew Sheldon ---
Scratch that; looks like a manual git build works, but not mesa- in the
Gentoo repository. I've tested with minimal cflags too and the problem remains,
so I'm not sure what the difference is.
--
You
https://bugs.freedesktop.org/show_bug.cgi?id=105251
--- Comment #48 from CheatCodesOfLife ---
Created attachment 141425
--> https://bugs.freedesktop.org/attachment.cgi?id=141425=edit
logs and trace
Hi,
I have applied the patch, ran through the process and attached the logs. The
file doesn't
Hey
Since this commit:
34db50e55656 efifb: Copy the ACPI BGRT
the kernel will override boot-splashs unasked. This breaks the
graphical boot-process on our setups. In particular, we have a setup
where an efi-boot-entry draws the early boot-splash on-screen, then
hands-over to the
https://bugs.freedesktop.org/show_bug.cgi?id=105379
--- Comment #6 from Andrew Sheldon ---
It's still broken for me actually, and reverting the commit original commit
works around the issue. Maybe there is something that is specific to my system
that is causing the problem.
--
You are
https://bugs.freedesktop.org/show_bug.cgi?id=106747
Petri Latvala changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=107800
Martin Peres changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #4 from Martin Peres
https://bugs.freedesktop.org/show_bug.cgi?id=107800
Petri Latvala changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=106747
--- Comment #4 from Petri Latvala ---
*** Bug 107800 has been marked as a duplicate of this bug. ***
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing
https://bugs.freedesktop.org/show_bug.cgi?id=107800
--- Comment #2 from Chris Wilson ---
Want to just poke bug 106747?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=107800
Martin Peres changed:
What|Removed |Added
Whiteboard||ReadyForDev
Priority|medium
https://bugs.freedesktop.org/show_bug.cgi?id=107800
Bug ID: 107800
Summary: [CI][BAT] An internal exception that should have been
handled was not: UnicodeDecodeError.
Product: DRI
Version: XOrg git
Hardware: Other
hi,
On Sun, Sep 02, 2018 at 09:26:26AM +0200, Jernej Skrabec wrote:
> H6 is first Allwinner SoC which supports 10 bit colors, HDR and AFBC.
>
> Signed-off-by: Jernej Skrabec
> ---
> drivers/gpu/drm/sun4i/sun4i_drv.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git
https://bugs.freedesktop.org/show_bug.cgi?id=107798
Chris Wilson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Am 03.09.2018 um 09:52 schrieb Daniel Vetter:
On Sat, Sep 01, 2018 at 01:32:54PM +0100, Chris Wilson wrote:
Quoting Jia-Ju Bai (2018-09-01 13:20:41)
The driver may sleep with holding a spinlock.
The function call paths (from bottom to top) in Linux-4.16 are:
[FUNC] kmalloc(GFP_KERNEL)
https://bugs.freedesktop.org/show_bug.cgi?id=107798
Martin Peres changed:
What|Removed |Added
Whiteboard||ReadyForDev
Priority|medium
https://bugs.freedesktop.org/show_bug.cgi?id=107798
Bug ID: 107798
Summary: [CI][BAT] igt@pm_rpm@module-reload - fail - Failed
assertion: is_i915_device(fd)
Product: DRI
Version: XOrg git
Hardware: Other
On Monday, September 03, 2018 09:43:15 AM Daniel Vetter wrote:
> On Sat, Sep 01, 2018 at 04:08:41PM +0200, Michał Mirosław wrote:
> > This series cleans up duplicated code for replacing firmware FB
> > driver with proper DRI driver and adds handover support to
> > Tegra driver.
> >
> > This is a
Am 03.09.2018 um 12:07 schrieb Chunming Zhou:
在 2018/9/3 16:50, Christian König 写道:
Am 03.09.2018 um 06:13 schrieb Chunming Zhou:
在 2018/8/30 19:32, Christian König 写道:
[SNIP]
+
+struct drm_syncobj_wait_pt {
+ struct drm_syncobj_stub_fence base;
+ u64 value;
+ struct
Use DRM_FORMAT_HOST_XRGB, so we are using the correct format code
on bigendian machines. Also add DRIVER_PREFER_HOST_BYTE_ORDER driver
feature flag so drm_mode_addfb() asks for the correct format code.
Both DRM_FORMAT_* and VIRTIO_GPU_FORMAT_* are defined to be little
endian, so using a
After a lng break, here is the next version of the patch series.
It adds some convinience #defines for host byteoder drm formats. It
fixes drm_mode_addfb() behavior on bigendian machines. For bug
compatibility reasons a driver feature flag activates the fix. bochs
and virtio-gpu drivers are
Use DRM_FORMAT_HOST_XRGB, so we are using the correct format code
on bigendian machines. Also add DRIVER_PREFER_HOST_BYTE_ORDER driver
feature flag so drm_mode_addfb() asks for the correct format code.
Create our own plane and use drm_crtc_init_with_planes() instead of
depending on the
framebuffer_check() expects that drm_get_format_info() will not fail if
the __drm_format_info() call was successful. That'll work only in case
both are called with the same pixel_format value, so masking out the
DRM_FORMAT_BIG_ENDIAN flag isn't a good idea.
Signed-off-by: Gerd Hoffmann
---
Userspace on big endian machhines typically expects the ADDFB ioctl
returns a big endian framebuffer. drm_mode_addfb() will call
drm_mode_addfb2() unconditionally with little endian DRM_FORMAT_*
values though, which is wrong. This patch fixes that.
Drivers (both kernel and xorg) have quirks in
Add fourcc variants in host byte order. With these at hand we don't
need #ifdefs in drivers which support framebuffers in cpu endianess.
Signed-off-by: Gerd Hoffmann
---
include/drm/drm_fourcc.h | 22 ++
1 file changed, 22 insertions(+)
diff --git
Hi Sean,
On Fri, Aug 31, 2018 at 11:09:25AM -0400, Sean Paul wrote:
> From: Sean Paul
>
> Adds docs for pixel_blend_mode in drm_plane_state. Fixes the warning
> found by kbuild test robot:
>
> htmldocs: include/drm/drm_plane.h:189: warning: Function parameter or member
> 'pixel_blend_mode'
https://bugs.freedesktop.org/show_bug.cgi?id=107781
--- Comment #4 from Alex Findler ---
I've tried with all kernels that Fedora offered during the last two months,
including 4.16 varieties.
These are the kernel options I tried:
radeon.cik_support=0 amdgpu.cik_support=1 scsi_mod.scan=sync
https://bugs.freedesktop.org/show_bug.cgi?id=107784
--- Comment #3 from Sylvain BERTRAND ---
On Mon, Sep 03, 2018 at 09:17:30AM +, bugzilla-dae...@freedesktop.org
wrote:
> https://bugs.freedesktop.org/show_bug.cgi?id=107784
>
> --- Comment #2 from Michel Dänzer ---
> Can you bisect?
I
https://bugs.freedesktop.org/show_bug.cgi?id=106639
--- Comment #11 from Daniel Drake ---
Also confirmed working after applying these commits from amd-staging-drm-next
Applying: drm/amdgpu/gmc9: rework stolen vga memory handling
Applying: drm/amdgpu/gmc9: don't keep stolen memory on Raven
在 2018/9/3 16:50, Christian König 写道:
Am 03.09.2018 um 06:13 schrieb Chunming Zhou:
在 2018/8/30 19:32, Christian König 写道:
[SNIP]
+
+struct drm_syncobj_wait_pt {
+ struct drm_syncobj_stub_fence base;
+ u64 value;
+ struct rb_node node;
+};
+struct drm_syncobj_signal_pt {
+
https://bugs.freedesktop.org/show_bug.cgi?id=107516
--- Comment #8 from Gian-Carlo Pascutto ---
To clarify the underlying cause of this:
>Earlier commit reworked our sysfs handling to use realpath.
>Sadly that backfired since the Firefox sandboxing mechanism rejects
>that. Despite the
Using a spinlock to serialize the destroy function, within the destroy
function itself does not prevent the buggy driver from shooting
themselves in the foot - either way they still have a use-after-free
issue.
Reported-by: Jia-Ju Bai
Signed-off-by: Chris Wilson
Cc: Davidlohr Bueso
Cc: Liviu
https://bugs.freedesktop.org/show_bug.cgi?id=107781
Michel Dänzer changed:
What|Removed |Added
Component|Driver/AMDgpu |DRM/AMDgpu
QA
https://bugs.freedesktop.org/show_bug.cgi?id=107784
--- Comment #2 from Michel Dänzer ---
Can you bisect?
P.S. Please enable CONFIG_UNWINDER_ORC in your kernel build, to make the
backtraces in dmesg more useful.
--
You are receiving this mail because:
You are the assignee for the
On 08/31/2018 05:30 PM, Thomas Hellstrom wrote:
On 08/31/2018 05:27 PM, Emil Velikov wrote:
On 31 August 2018 at 15:38, Michel Dänzer wrote:
[ Adding the amd-gfx list ]
On 2018-08-31 3:05 p.m., Thomas Hellstrom wrote:
On 08/31/2018 02:30 PM, Emil Velikov wrote:
On 31 August 2018 at 12:54,
On Monday, 2018-09-03 10:43:36 +0200, Daniel Vetter wrote:
> On Mon, Sep 03, 2018 at 09:07:10AM +0100, Eric Engestrom wrote:
> > On Monday, 2018-09-03 09:50:06 +0200, Daniel Vetter wrote:
> > > On Fri, Aug 31, 2018 at 05:13:25PM +0100, Eric Engestrom wrote:
> > > > On Friday, 2018-08-31 16:03:44
Hi,
On Mon, 3 Sep 2018 at 09:45, Daniel Vetter wrote:
> On Fri, Aug 31, 2018 at 03:18:56PM +0100, Eric Engestrom wrote:
> > It currently does 4 builds: 2 using Meson and 2 using Autotools, 2 using
> > the latest dependencies on ArchLinux and 2 using very old dependencies
> > on Debian (including
Am 03.09.2018 um 06:13 schrieb Chunming Zhou:
在 2018/8/30 19:32, Christian König 写道:
[SNIP]
+
+struct drm_syncobj_wait_pt {
+ struct drm_syncobj_stub_fence base;
+ u64 value;
+ struct rb_node node;
+};
+struct drm_syncobj_signal_pt {
+ struct drm_syncobj_stub_fence base;
+
I picked up a bunch of the pieces from wayland's version:
https://gitlab.freedesktop.org/wayland/wayland/blob/master/CONTRIBUTING.md
The weston one is fairly similar. Then I rather massively trimmed it
down since in reality libdrm is a bit a dumping ground with very few
real rules. The commit
https://bugs.freedesktop.org/show_bug.cgi?id=105733
--- Comment #36 from markusr...@gmail.com ---
(In reply to markusraat from comment #35)
> It might be that kernel option apci=ht ( also apci=off ) solve the problem.
> It is taking more time to waiting the possible problem appearance. At least
>
On Fri, Aug 31, 2018 at 03:18:56PM +0100, Eric Engestrom wrote:
> It currently does 4 builds: 2 using Meson and 2 using Autotools, 2 using
> the latest dependencies on ArchLinux and 2 using very old dependencies
> on Debian (including manually building libpciaccess to have the oldest
> version
On Mon, Sep 03, 2018 at 09:07:10AM +0100, Eric Engestrom wrote:
> On Monday, 2018-09-03 09:50:06 +0200, Daniel Vetter wrote:
> > On Fri, Aug 31, 2018 at 05:13:25PM +0100, Eric Engestrom wrote:
> > > On Friday, 2018-08-31 16:03:44 +0100, Daniel Stone wrote:
> > > > Hi Eric,
> > > >
> > > > On Fri,
https://bugs.freedesktop.org/show_bug.cgi?id=107793
--- Comment #2 from Simon Geard ---
Created attachment 141424
--> https://bugs.freedesktop.org/attachment.cgi?id=141424=edit
Output of dmesg on successful boot
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=107793
--- Comment #1 from Simon Geard ---
Created attachment 141423
--> https://bugs.freedesktop.org/attachment.cgi?id=141423=edit
Output of lspci on successful boot
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=107793
Bug ID: 107793
Summary: Black screen on boot for Fedora 28 with 4.17 kernel
(i.e. with amdgpu.dc defaulted)
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
On Mon, Sep 03, 2018 at 09:26:24AM +0200, Daniel Vetter wrote:
> On Fri, Aug 31, 2018 at 05:26:37PM +0100, Alexandru-Cosmin Gheorghe wrote:
> > Hi,
> >
> > On Fri, Aug 31, 2018 at 05:12:24PM +0200, Daniel Vetter wrote:
> > > On Fri, Aug 31, 2018 at 02:20:31PM +0300, Ville Syrjälä wrote:
> > > >
On Monday, 2018-09-03 09:50:06 +0200, Daniel Vetter wrote:
> On Fri, Aug 31, 2018 at 05:13:25PM +0100, Eric Engestrom wrote:
> > On Friday, 2018-08-31 16:03:44 +0100, Daniel Stone wrote:
> > > Hi Eric,
> > >
> > > On Fri, 31 Aug 2018 at 15:22, Eric Engestrom
> > > wrote:
> > > > +-
On Sat, Sep 01, 2018 at 01:32:54PM +0100, Chris Wilson wrote:
> Quoting Jia-Ju Bai (2018-09-01 13:20:41)
> > The driver may sleep with holding a spinlock.
> >
> > The function call paths (from bottom to top) in Linux-4.16 are:
> >
> > [FUNC] kmalloc(GFP_KERNEL)
> > drivers/gpu/drm/drm_mm.c, 130:
1 - 100 of 108 matches
Mail list logo
