By simply copy/pasting a big document under LibreOffice my system hangs
itself up. Only a hard reset gets it working again.
see also: https://bugs.freedesktop.org/show_bug.cgi?id=66551
I've bisected the issue to:
commit ecff665f5e3f1c6909353e00b9420e45ae23d995
Author: Maarten Lankhorst
Date: T
Op 10-07-13 11:22, Markus Trippelsdorf schreef:
> By simply copy/pasting a big document under LibreOffice my system hangs
> itself up. Only a hard reset gets it working again.
> see also: https://bugs.freedesktop.org/show_bug.cgi?id=66551
>
> I've bisected the issue to:
>
> commit ecff665f5e3f1c690
On 2013.07.10 at 11:29 +0200, Maarten Lankhorst wrote:
> Op 10-07-13 11:22, Markus Trippelsdorf schreef:
> > By simply copy/pasting a big document under LibreOffice my system hangs
> > itself up. Only a hard reset gets it working again.
> > see also: https://bugs.freedesktop.org/show_bug.cgi?id=665
Op 10-07-13 11:46, Markus Trippelsdorf schreef:
> On 2013.07.10 at 11:29 +0200, Maarten Lankhorst wrote:
>> Op 10-07-13 11:22, Markus Trippelsdorf schreef:
>>> By simply copy/pasting a big document under LibreOffice my system hangs
>>> itself up. Only a hard reset gets it working again.
>>> see als
On 2013.07.10 at 11:56 +0200, Maarten Lankhorst wrote:
> Op 10-07-13 11:46, Markus Trippelsdorf schreef:
> > On 2013.07.10 at 11:29 +0200, Maarten Lankhorst wrote:
> >> Op 10-07-13 11:22, Markus Trippelsdorf schreef:
> >>> By simply copy/pasting a big document under LibreOffice my system hangs
> >>
Op 10-07-13 12:03, Markus Trippelsdorf schreef:
> On 2013.07.10 at 11:56 +0200, Maarten Lankhorst wrote:
>> Op 10-07-13 11:46, Markus Trippelsdorf schreef:
>>> On 2013.07.10 at 11:29 +0200, Maarten Lankhorst wrote:
Op 10-07-13 11:22, Markus Trippelsdorf schreef:
> By simply copy/pasting a
Hi Mark,
Thanks for the patch.
On Wednesday 10 July 2013 11:52:14 Mark Brown wrote:
> From: Mark Brown
>
> The driver uses CMA APIs so won't link if CMA is not being built.
>
> Signed-off-by: Mark Brown
> ---
> drivers/gpu/drm/rcar-du/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 delet
drivers/gpu/drm/drm_edid_load.c: In function ‘drm_load_edid_firmware’:
drivers/gpu/drm/drm_edid_load.c:245: warning: initialization discards
qualifiers from pointer target type
drm_get_connector_name() returns a "const char *", hence propagate the
const where needed.
Signed-off-by: Geert Uytterh
drivers/gpu/drm/drm_edid_load.c: In function ‘edid_load’:
drivers/gpu/drm/drm_edid_load.c:141: warning: ‘edid’ may be used uninitialized
in this function
In some error cases, edid_load() will return the uninitialized variable.
Initialize it to NULL to fix this.
Signed-off-by: Geert Uytterhoeven
Always use "void *" for arbitrary memory buffers, as this allows to drop
casts in assignments.
Signed-off-by: Geert Uytterhoeven
---
drivers/gpu/drm/drm_edid_load.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid_load.c b/drivers/gpu/drm/drm_ed
https://bugs.freedesktop.org/show_bug.cgi?id=66767
Priority: medium
Bug ID: 66767
Assignee: dri-devel@lists.freedesktop.org
Summary: atombios stuck in loop for more than 5secs aborting
after suspend to ram
Severity: normal
https://bugs.freedesktop.org/show_bug.cgi?id=66767
Johannes Hirte changed:
What|Removed |Added
Hardware|Other |x86-64 (AMD64)
OS|All
https://bugs.freedesktop.org/show_bug.cgi?id=66768
Priority: medium
Bug ID: 66768
Assignee: dri-devel@lists.freedesktop.org
Summary: UVD decoding of MPEG2 streams doesn't work on CEDAR
Severity: normal
Classification: Unclassified
On Wednesday 10 July 2013 12:07:24 Mark Brown wrote:
> On Wed, Jul 10, 2013 at 12:54:40PM +0200, Laurent Pinchart wrote:
> > On Wednesday 10 July 2013 11:52:14 Mark Brown wrote:
> > > config DRM_RCAR_DU
> > >
> > > tristate "DRM Support for R-Car Display Unit"
> > >
> > > - depends on DRM &&
I've checked both implementations (radeon/nouveau) and they both grab
the page array from ttm simply by dereferencing it and then wrapping
it up with drm_prime_pages_to_sg in the callback and map it with
dma_map_sg (in the helper).
Only the grabbing of the underlying page array is anything we need
Hi all,
This patch set introduces a buffer synchronization framework based
on DMA BUF[1] and reservation[2] to use dma-buf resource, and based
on ww-mutexes[3] for lock mechanism.
The purpose of this framework is to provide not only buffer access
control to CPU and CPU, and CPU and DMA, and DMA a
This patch adds a buffer synchronization framework based on DMA BUF[1]
and reservation[2] to use dma-buf resource, and based on ww-mutexes[3]
for lock mechanism.
The purpose of this framework is to provide not only buffer access control
to CPU and DMA but also easy-to-use interfaces for device dri
This patch adds lock callback to dma buf file operations,
and this callback will be called by fcntl system call.
With this patch, fcntl system call can be used for buffer
synchronization between CPU and CPU, and CPU and DMA in user mode.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
Op 10-07-13 13:54, Daniel Vetter schreef:
> I've checked both implementations (radeon/nouveau) and they both grab
> the page array from ttm simply by dereferencing it and then wrapping
> it up with drm_prime_pages_to_sg in the callback and map it with
> dma_map_sg (in the helper).
>
> Only the grab
Hi all,
I've figured that it's again time for a bit of (late) drm spring cleanup. This
series here consists of a pile of "rip old stuff out" patches interleaved with
"disable old cruft for kms drivers and hide it better".
Comments, flames and review highly welcome. I'd be especially happy if the
It doesn't do anything, so kill the code.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_context.c | 6 --
drivers/gpu/drm/drm_drv.c | 2 +-
include/drm/drmP.h| 2 --
3 files changed, 1 insertion(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_context.c b/drivers/g
No one ever waits on this waitqueue, so the wake_up call is wasted.
Remove it all.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_context.c | 1 -
drivers/gpu/drm/drm_fops.c| 1 -
include/drm/drmP.h| 1 -
3 files changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_con
Only ever assigned in the context code for real, with no readers
anywhere. Remove it.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_context.c | 1 -
drivers/gpu/drm/drm_fops.c| 1 -
include/drm/drmP.h| 1 -
3 files changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_
Completely unused, so just remove them.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_fops.c | 2 --
include/drm/drmP.h | 2 --
2 files changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index c14fdc1..386c304 100644
--- a/drivers/gpu/drm
Again completely unused, so just remove it.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_fops.c | 3 ---
include/drm/drmP.h | 2 --
2 files changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index 386c304..a3714a0 100644
--- a/drivers/gp
No need to create a dummy ioctl function to return -EINVAL, since
that's what the core already does in the absence of the dma_ioctl
callback. So we can safely remove this.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/radeon/radeon_drv.c | 3 ---
drivers/gpu/drm/radeon/radeon_kms.c | 10
Again totally unused, so just remove them.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_fops.c | 2 --
include/drm/drmP.h | 2 --
2 files changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index a3714a0..57e3014 100644
--- a/drivers/gpu/
We kzalloc the driver node at init time, so no need to do this again.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_fops.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index 57e3014..9610997 100644
--- a/drivers/gpu/dr
KMS drivers really shouldn't need to do anything on firstopen, so kill
empty callbacks.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/omapdrm/omap_drv.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
b/drivers/gpu/drm/omapdrm/omap_drv.c
index 826
Again, it does nothing.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/radeon/radeon_drv.c | 2 --
drivers/gpu/drm/radeon/radeon_kms.c | 13 -
2 files changed, 15 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
b/drivers/gpu/drm/radeon/radeon_drv.c
index c07b681..1
This thing seems to do some kind of delayed setup. Really, real kms
drivers shouldn't do that at all. Either stuff needs to be dynamically
hotplugged or the driver setup sequence needs to be fixed.
This patch here just moves the setup at the very end of the driver
load callback, with the locking a
So if we survey kms drivers there's a bunch of things they commonly do
in ->lastclose
- delayed processing of vga switcheroo requests (i915, nouveau,
radeon)
- force-restoring the fbcon (most)
- resetting a bunch properties to make fbcon work better (omap)
- disabling all outputs (vmwgfx)
In sho
It has way too much potential for driver writers to do stupid things
like delayed hw setup because the load sequence is somehow racy (e.g.
the imx driver in staging). So don't call it for modesetting drivers,
which reduces the complexity of the drm core -> driver interface a
notch.
Signed-off-by:
Totally unused, so just rip it out. Anyway, we want drivers to be
fully backwards compatible, allowing them to change behaviour is just
a recipe for them to break badly.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_ioctl.c | 3 ---
include/drm/drmP.h | 2 --
2 files changed, 5 d
Really, this is all old-style stuff and just copy-pasta from the
ums driver.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/radeon/radeon_drv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
b/drivers/gpu/drm/radeon/radeon_drv.c
ind
There's no other caller from driver code, so we can fold this in.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_drv.c | 2 +-
drivers/gpu/drm/drm_scatter.c | 13 +++--
include/drm/drmP.h| 3 +--
3 files changed, 5 insertions(+), 13 deletions(-)
diff --git a/driv
Only the radeon/r128/ati ums drivers use this. Furthermore the cleanup
was already only done for UMS drivers. Also a quick check of the ATI
ddx git history shows that only the UMS code ever used this facility.
So we can safely disallow these pair of ioctls for modesetting
drivers.
Signed-off-by:
I've decided that some clear markers for what's legacy dri1/non-gem
code is useful. I've opted to use the drm_legacy prefix and then hide
all the checks in that function for better readability in the common
code.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_drv.c | 7 ++-
driver
And hide the checks a bit better. This was already disallowed for
modesetting drivers, so no functinal change here.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_dma.c | 17 +++--
drivers/gpu/drm/drm_drv.c | 4 +---
drivers/gpu/drm/drm_fops.c | 12 +++-
include/drm/
The former doesn't do anything without DRIVER_HAVE_DMA (which is
force-disabled for kms drivers anyway). The latter isn't used by the
(kms) nouveau ddx.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/driv
Now only legacy ums drivers have the DRIVER_HAVE_DMA driver feature
flag set, so strictly speaking the modesetting check is redundant. But
adding it has the upside that it makes it very clear that the dma
support is legacy stuff.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_bufs.c | 15 +
It fiddles the sarea out of the maps which are also handled in
drm_bufs.c
With this drm_drv.c is a notch more legacy free.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_bufs.c | 14 ++
drivers/gpu/drm/drm_drv.c | 15 ---
2 files changed, 14 insertions(+), 15 dele
The version offered by the core is ridiculously optimized and
does the same thing. So use it.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_bufs.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index
Again just use the version provided by the linux core.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/r128/r128_cce.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/r128/r128_cce.c b/drivers/gpu/drm/r128/r128_cce.c
index d4660cf..c451257 100644
--- a/driver
Last driver and pretty obviously a major user of this little function.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/radeon/cik.c | 14 +++---
drivers/gpu/drm/radeon/evergreen.c | 4 ++--
drivers/gpu/drm/radeon/ni.c| 6 +++---
drivers/gpu/drm/radeon/r100.c | 2 +-
All users of it are now gone!
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_bufs.c | 23 ---
include/drm/drmP.h | 1 -
2 files changed, 24 deletions(-)
diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index 31a971d..25f 100644
--- a/dr
So after a lot of digging around in git histories it looks like this
has only ever be used by dri1 render clients. Hence we can fully
disable the entire thing for modesetting drivers and so greatly reduce
the attack surface for potential exploits (or at least tools like
trinity ...).
Also add the
It's kzalloced ...
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 3e43578..3e75dfa 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/driv
So I've stumbled over drm_fasync and wondered what it does. Digging
that up is quite a story.
First I've had to read up on what this does and ended up being rather
bewildered why peopled loved signals so much back in the days that
they've created SIGIO just for that ...
Then I wondered how this e
No driver ever sets that flag, so good riddance!
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_bufs.c | 161 +
include/drm/drmP.h | 1 -
2 files changed, 2 insertions(+), 160 deletions(-)
diff --git a/drivers/gpu/drm/drm_bufs.c b/driv
The gma500 driver somehow set the DRIVER_IRQ_VBL flag, but since
there's no code at all to check for this we can kill it. The other two
are completely unused.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/gma500/psb_drv.c | 2 +-
include/drm/drmP.h | 3 ---
2 files changed, 1 in
Signed-off-by: Daniel Vetter
---
include/drm/drmP.h | 9 -
1 file changed, 9 deletions(-)
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 2a7001f..62e9e41 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -164,13 +164,7 @@ int drm_err(const char *func, const char *fo
The new arch_phys_wc_add/del functions do the right thing both with
and without MTRR support in the kernel. So we can drop these
additional checks.
Cc: Andy Lutomirski
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_bufs.c | 13 +
drivers/gpu/drm/drm_pci.c | 11 +--
dr
We might as well have a real ioctl function which checks for the
callbacks. This seems to be a remnant from back in the days when each
drm driver had their own complete ioctl table, with no shared core
drm table at all.
To make really sure no mis-guided user in a kms driver pops up again
explicitl
They're only used by the agpgart support code in drm_agpgart.c,
not by any drivers.
I think long-term we should create a drm_internal.h include file with
all the various functions only used by the drm core and not exported
to drivers, and remove them from drmP.h. Oh, and someone should kill
that u
We not only have debugfs files to do pretty much the equivalent of
lsof, we also have an ioctl. Not that compared to lsof this dumps a
wee bit more information, but we can still get at that from debugfs
easily.
I've dug around in mesa, libdrm and ddx histories and the only users
seem to be drm/tes
Again only used by a tests in libdrm and by dristat. Nowadays we have
much better tracing tools to get detailed insights into what a drm
driver is doing. And for a simple "does it work" kind of question that
these stats could answer we have plenty of dmesg debug log spew.
So I don't see any use fo
The idr is protected with our spinlock, if we don't hold that nothing
prevents the gem objects from disappearing from under us.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_info.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/drm_info.c b/drivers/gpu/drm/drm_inf
So almost two years ago I've tried to nuke the procfs code already
once before:
http://lists.freedesktop.org/archives/dri-devel/2011-October/015707.html
The conclusion was that userspace drivers (specifically libdrm device
node detection) stopped relying on procfs in 2011. But after some
digging
On Wed, Jul 10, 2013 at 2:03 PM, Maarten Lankhorst
wrote:
> Op 10-07-13 13:54, Daniel Vetter schreef:
>> I've checked both implementations (radeon/nouveau) and they both grab
>> the page array from ttm simply by dereferencing it and then wrapping
>> it up with drm_prime_pages_to_sg in the callback
Signed-off-by: Maarten Lankhorst
---
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a416645..d1b1928 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1080,8 +1080,6 @@ typedef struct drm_i915_private {
} backlight;
On Wed, Jul 10, 2013 at 02:27:31PM +0200, Maarten Lankhorst wrote:
> Signed-off-by: Maarten Lankhorst
Queued for -next, thanks for the patch.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
d
https://bugs.freedesktop.org/show_bug.cgi?id=66551
--- Comment #2 from Alex Deucher ---
Can you use git to bisect and identify what commit broke your system?
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel maili
https://bugs.freedesktop.org/show_bug.cgi?id=66551
octoploid changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=66767
--- Comment #1 from Alex Deucher ---
Please attach your full dmesg output. Also, is this a hybrid laptop with
multiple GPUs?
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=66768
Alex Deucher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=66450
Alex Deucher changed:
What|Removed |Added
CC||johannes.hi...@fem.tu-ilmen
On Wed, Jul 10, 2013 at 7:16 AM, Geert Uytterhoeven
wrote:
> drivers/gpu/drm/drm_edid_load.c: In function ‘drm_load_edid_firmware’:
> drivers/gpu/drm/drm_edid_load.c:245: warning: initialization discards
> qualifiers from pointer target type
>
> drm_get_connector_name() returns a "const char *",
Hi
On Wed, Jul 10, 2013 at 2:11 PM, Daniel Vetter wrote:
> We kzalloc the driver node at init time, so no need to do this again.
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_fops.c | 9 -
> 1 file changed, 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fops.c b/driv
https://bugs.freedesktop.org/show_bug.cgi?id=66450
Christian König changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #2 from Christian
Hi Daniel,
On Wednesday 10 July 2013 13:54:33 Daniel Vetter wrote:
> I've checked both implementations (radeon/nouveau) and they both grab
> the page array from ttm simply by dereferencing it and then wrapping
> it up with drm_prime_pages_to_sg in the callback and map it with
> dma_map_sg (in the
https://bugs.freedesktop.org/show_bug.cgi?id=66450
--- Comment #3 from Christian König ---
Created attachment 82275
--> https://bugs.freedesktop.org/attachment.cgi?id=82275&action=edit
Possible fix.
--
You are receiving this mail because:
You are the assignee for the bug.
Hi
On Wed, Jul 10, 2013 at 2:12 PM, Daniel Vetter wrote:
> The new arch_phys_wc_add/del functions do the right thing both with
> and without MTRR support in the kernel. So we can drop these
> additional checks.
>
> Cc: Andy Lutomirski
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_
Hi Dave,
These two patches fix compilation breakages in drm-next due to the removal of
drm_gem_cma_dmabuf_import() and drm_gem_cma_dmabuf_export() without updating
the existing users (I don't blame anyone here, the patch that removed those
functions and the patches that made use of them were merge
The GEM CMA PRIME import/export helpers have been removed in favor of
generic GEM PRIME helpers with GEM CMA low-level operations. Fix the
driver accordingly.
Reported-by: Mark Brown
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 9 +++--
1 file changed, 7 inser
The GEM CMA PRIME import/export helpers have been removed in favor of
generic GEM PRIME helpers with GEM CMA low-level operations. Fix the
driver accordingly.
Reported-by: Mark Brown
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/shmobile/shmob_drm_drv.c | 9 +++--
1 file changed, 7 in
https://bugs.freedesktop.org/show_bug.cgi?id=66450
--- Comment #4 from Johannes Hirte ---
With this patch applied, mplayer2 crashes on mpeg2 file with:
Detected file format: MPEG-PS (MPEG-2 Program Stream) (libavformat)
[mpeg @ 0x7fa7bec14cc0]max_analyze_duration 500 reached at 5005000
[lavf
https://bugs.freedesktop.org/show_bug.cgi?id=66450
--- Comment #5 from Johannes Hirte ---
(In reply to comment #2)
> The vdpauinfo output is wrong, JUNIPER has an uvd 2.3 block and that can't
> decode MPEG2 in vld mode.
So the wikipedia article is wrong?
"The UVD 2 features full bitstream decod
Hi
On Wed, Jul 10, 2013 at 2:12 PM, Daniel Vetter wrote:
> We might as well have a real ioctl function which checks for the
> callbacks. This seems to be a remnant from back in the days when each
> drm driver had their own complete ioctl table, with no shared core
> drm table at all.
>
> To make
https://bugs.freedesktop.org/show_bug.cgi?id=66450
--- Comment #6 from Christian König ---
(In reply to comment #5)
> (In reply to comment #2)
> > The vdpauinfo output is wrong, JUNIPER has an uvd 2.3 block and that can't
> > decode MPEG2 in vld mode.
>
> So the wikipedia article is wrong?
>
>
On Wed, Jul 10, 2013 at 3:46 PM, Laurent Pinchart
wrote:
> On Wednesday 10 July 2013 13:54:33 Daniel Vetter wrote:
>> I've checked both implementations (radeon/nouveau) and they both grab
>> the page array from ttm simply by dereferencing it and then wrapping
>> it up with drm_prime_pages_to_sg in
I've checked both implementations (radeon/nouveau) and they both grab
the page array from ttm simply by dereferencing it and then wrapping
it up with drm_prime_pages_to_sg in the callback and map it with
dma_map_sg (in the helper).
Only the grabbing of the underlying page array is anything we need
So I've stumbled over drm_fasync and wondered what it does. Digging
that up is quite a story.
First I've had to read up on what this does and ended up being rather
bewildered why peopled loved signals so much back in the days that
they've created SIGIO just for that ...
Then I wondered how this e
We might as well have a real ioctl function which checks for the
callbacks. This seems to be a remnant from back in the days when each
drm driver had their own complete ioctl table, with no shared core
drm table at all.
To make really sure no mis-guided user in a kms driver pops up again
explicitl
> So after a bit of irc chatting with Maarten this seems to be more
> involved. The above check is to cache the dma mapping, but the
> implementation is bogus in tons of ways:
> - If direction changes we don't bother with unmaping and freeing the
> mapping, but simply leak it.
> - This will break i
On Wed, Jul 10, 2013 at 3:28 PM, David Herrmann wrote:
> drm_setup() is called on every first open. I digged through core DRM
> and noticed that we have a lot of code that cleans up on lastclose and
> reinitializes on firstopen which is skipped for non-UMS drivers to
> preserve KMS state if no use
On Wed, Jul 10, 2013 at 5:18 PM, Konrad Rzeszutek Wilk
wrote:
>> So after a bit of irc chatting with Maarten this seems to be more
>> involved. The above check is to cache the dma mapping, but the
>> implementation is bogus in tons of ways:
>> - If direction changes we don't bother with unmaping a
On Wed, Jul 10, 2013 at 3:51 PM, David Herrmann wrote:
>> -#if __OS_HAS_MTRR
>> -static inline int drm_core_has_MTRR(struct drm_device *dev)
>> -{
>> - return drm_core_check_feature(dev, DRIVER_USE_MTRR);
>> -}
>> -#else
>> -#define drm_core_has_MTRR(dev) (0)
>> -#endif
>> -
>
> That was the
So I've stumbled over drm_fasync and wondered what it does. Digging
that up is quite a story.
First I've had to read up on what this does and ended up being rather
bewildered why peopled loved signals so much back in the days that
they've created SIGIO just for that ...
Then I wondered how this e
So I've stumbled over drm_fasync and wondered what it does. Digging
that up is quite a story.
First I've had to read up on what this does and ended up being rather
bewildered why peopled loved signals so much back in the days that
they've created SIGIO just for that ...
Then I wondered how this e
Hi
On Wed, Jul 10, 2013 at 2:11 PM, Daniel Vetter wrote:
> Hi all,
>
> I've figured that it's again time for a bit of (late) drm spring cleanup. This
> series here consists of a pile of "rip old stuff out" patches interleaved with
> "disable old cruft for kms drivers and hide it better".
>
> Comm
Hi
On Wed, Jul 10, 2013 at 5:22 PM, Daniel Vetter wrote:
> On Wed, Jul 10, 2013 at 3:51 PM, David Herrmann wrote:
>>> -#if __OS_HAS_MTRR
>>> -static inline int drm_core_has_MTRR(struct drm_device *dev)
>>> -{
>>> - return drm_core_check_feature(dev, DRIVER_USE_MTRR);
>>> -}
>>> -#else
>>>
Only ever re-cleared in drm_setup, otherwise completely unused.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_fops.c | 1 -
include/drm/drmP.h | 1 -
2 files changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index d1b4771..5679971 100644
We kzalloc this structure, and for real kms devices we should never
loose track of things really.
But ums/legacy drivers rely on the drm core to clean up a bit of cruft
between lastclose and firstopen (i.e. when X is being restarted), so
keep this around. But give it a clear drm_legacy_ prefix and
On Wed, Jul 10, 2013 at 5:41 PM, David Herrmann wrote:
> On Wed, Jul 10, 2013 at 5:22 PM, Daniel Vetter wrote:
>> On Wed, Jul 10, 2013 at 3:51 PM, David Herrmann
>> wrote:
-#if __OS_HAS_MTRR
-static inline int drm_core_has_MTRR(struct drm_device *dev)
-{
- return drm_c
The new arch_phys_wc_add/del functions do the right thing both with
and without MTRR support in the kernel. So we can drop these
additional checks.
David Herrmann suggest to also kill the DRIVER_USE_MTRR flag since
it's now unused, which spurred me to do a bit a better audit of the
affected driver
I've forgotten this and shuffling all the little pieces into the
respective patches is rather cumbersome ...
Signed-off-by: Daniel Vetter
---
Documentation/DocBook/drm.tmpl | 29 -
1 file changed, 29 deletions(-)
diff --git a/Documentation/DocBook/drm.tmpl b/Document
Op 10-07-13 16:48, Daniel Vetter schreef:
> I've checked both implementations (radeon/nouveau) and they both grab
> the page array from ttm simply by dereferencing it and then wrapping
> it up with drm_prime_pages_to_sg in the callback and map it with
> dma_map_sg (in the helper).
>
> Only the grab
On Wed, Jul 10, 2013 at 6:27 PM, Andy Lutomirski wrote:
> Are all of those codepaths really inaccessible in non-legacy drm
> drivers? I didn't try to fully unravel all the ioctls and such, but
> it seems like userspace could add bufs and map them. Since the mtrr
> code isn't very robust (referen
https://bugs.freedesktop.org/show_bug.cgi?id=65723
Michel Dänzer changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
1 - 100 of 254 matches
Mail list logo
