In cases where the scheduler instance is used a base object of another
vendor driver object, it's not clear if the driver can call sched cleanup on
the fail path. Set the sched->thread to NULL, so that the vendor driver
can safely call drm_sched_fini() during cleanup.
Signed-off-by: Sharat Masetty
This patch fixes a trivial leak when trying to create a submitqueue.
Signed-off-by: Sharat Masetty
---
drivers/gpu/drm/msm/msm_submitqueue.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/msm_submitqueue.c
b/drivers/gpu/drm/msm/msm_submitqueue.c
index
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 Fri, Aug 31, 2018 at 10:14:14AM +0200, Daniel Vetter wrote:
> > > > On Th
On Sat, Sep 01, 2018 at 08:53:52PM +0300, Haneen Mohammed wrote:
> On Fri, Aug 31, 2018 at 10:41:40AM +0200, Daniel Vetter wrote:
> > On Fri, Aug 24, 2018 at 02:16:34AM +0300, Haneen Mohammed wrote:
> > > crtc_state is accessed by both vblank_handle() and the ordered
> > > work_struct handle vkms_c
On Fri, Aug 31, 2018 at 07:31:10PM -0400, Lyude Paul wrote:
> On Fri, 2018-08-31 at 10:53 +0200, Daniel Vetter wrote:
> > On Mon, Aug 27, 2018 at 08:36:24PM -0400, Lyude Paul wrote:
> > > Currently all debugfs related initialization for the DRM core happens in
> > > drm_debugfs_init(), which is cal
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 sligtly updated version of a series sent on 24 Nov 2017.
>
> ---
> v2:
> -
On Fri, Aug 31, 2018 at 11:07:12AM -0700, Abhinav Kumar wrote:
> Hi Sean/Ville
>
> Thanks for the comments.
>
> This mode 640x480 @ 72Hz comes directly from the VESA spec ( DMT Standards
> and Guidelines Summary ).
>
> Yes, I understand that the hardware will still be running at 72.8 Hz.
>
> Th
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:
> > > +- LIBPCIACCESS_VERSION=libpciaccess-0.10 &&
> > > + wget --no-check-certificate
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:
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:
> > > > +- LIBPCIACC
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:
> > > > O
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)
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&action=edit
Output of lspci on successful boot
--
You are receiving this mail because:
You are the assignee for the bug._
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&action=edit
Output of dmesg on successful boot
--
You are receiving this mail because:
You are the assignee for the bug._
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,
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 supp
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
>
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 rig
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;
+
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
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 +0
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, T
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 bug._
https://bugs.freedesktop.org/show_bug.cgi?id=107781
Michel Dänzer changed:
What|Removed |Added
Component|Driver/AMDgpu |DRM/AMDgpu
QA Contact|xorg-t...
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 Du
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 files/fold
在 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=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
Applyi
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 don'
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
amdgp
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' not
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 p
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 a/include/drm/drm_fourcc.h
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
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
---
driv
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 defaul
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 diffe
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 rb_node
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 s
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
OS:
https://bugs.freedesktop.org/show_bug.cgi?id=107798
Martin Peres changed:
What|Removed |Added
Whiteboard||ReadyForDev
Priority|medium
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)
drivers
https://bugs.freedesktop.org/show_bug.cgi?id=107798
Chris Wilson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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 a/drivers/gpu/drm/sun4i
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
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=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 lis
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=107800
Martin Peres changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #4 from Martin Peres
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=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 receiving
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 linux-kernel
https://bugs.freedesktop.org/show_bug.cgi?id=105251
--- Comment #48 from CheatCodesOfLife ---
Created attachment 141425
--> https://bugs.freedesktop.org/attachment.cgi?id=141425&action=edit
logs and trace
Hi,
I have applied the patch, ran through the process and attached the logs. The
file do
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 a
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 5b394b2ddf0347bef56e50c69a
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.
Sig
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().
Fi
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. Nothi
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 e
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 o
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 setups
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
5e8704ac1cfa9fceef94fcc457e186
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=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 bug.
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() r
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 pr
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., T
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 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 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 o
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
Sign
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
---
drivers/gpu/drm/i915/i915_drv.
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
ind
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
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 L
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 te
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: D
- 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 a
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 c
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 can
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
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 -
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:
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 4aff40886acb..91d896e
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 2018-08-
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 end
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 l
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 h
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 device,
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 (All)
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 ass
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 a
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://fedoraproject.org/wiki/Building_a_c
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
>
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/
https://bugs.freedesktop.org/show_bug.cgi?id=107690
Gleb Zasyadko changed:
What|Removed |Added
Product|xorg|DRI
Assignee|xorg-driver-...@
>
> 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
sh
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
Reviewed
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 +
> d
1 - 100 of 111 matches
Mail list logo
