bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150909/d63e981f/attachment.html>
was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150909/e800ca29/attachment.html>
mpler inside a struct or something.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150909/650677ae/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150909/9b8d6629/attachment.html>
now if I can provide more information.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150909/cde65bb2/attachment.html>
On Wed, Sep 9, 2015 at 6:36 PM, Tvrtko Ursulin
wrote:
> I am not even going that far, just talking about last frame stuck on screen.
> For me making that easier is a regression.
So let's look at various systems:
- super-modern fbdev less system: logind keeps a dup of every
master-capabel drm fd.
Drivers may wish to duplicate in-flight states internally, but the
__drm_atomic_helper_{crtc,plane}_duplicate_state helper functions can
only be used to make a copy of state that has already been committed to
obj->state. Let's update the helpers to take any existing state object
as their first par
Op 09-09-15 om 18:15 schreef Tvrtko Ursulin:
>
> On 09/09/2015 05:07 PM, Daniel Vetter wrote:
>> On Wed, Sep 9, 2015 at 6:03 PM, Tvrtko Ursulin
>> wrote:
>>> It was just an example of a class of vulnerabilities which would be possible
>>> with these changes. If they, as you said, will preserve the
Signed-off-by: Emil Velikov
---
tests/drmdevice.c | 23 +--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/tests/drmdevice.c b/tests/drmdevice.c
index 4055f45..c336327 100644
--- a/tests/drmdevice.c
+++ b/tests/drmdevice.c
@@ -23,6 +23,9 @@
#include
#includ
Similar interface to the *Devices() ones but they obtain/free the
information of the opened device (as given by its fd).
Note there is a fair bit of duplication between the two Get functions,
and anyone interested is more than welcome to consolidate it.
Signed-off-by: Emil Velikov
---
xf86drm.c
Will be reused in the next commit.
Signed-off-by: Emil Velikov
---
xf86drm.c | 123 +-
1 file changed, 74 insertions(+), 49 deletions(-)
diff --git a/xf86drm.c b/xf86drm.c
index a783a28..aa0fbe4 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@
Signed-off-by: Emil Velikov
---
xf86drm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/xf86drm.c b/xf86drm.c
index 3d03cbf..a783a28 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -2822,6 +2822,8 @@ static char *drmGetMinorNameForFD(int fd, int type)
out_close_dir:
closedir(sysdir);
Signed-off-by: Emil Velikov
---
xf86drm.c | 33 +++--
1 file changed, 15 insertions(+), 18 deletions(-)
diff --git a/xf86drm.c b/xf86drm.c
index 8105b42..3d03cbf 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -2836,9 +2836,9 @@ char *drmGetRenderDeviceNameFromFd(int fd)
Do a once off memory allocation for each drmDevice.
This allows us to ease the error handling and simplify the
de-duplication loop. As part of this we need to rework drmFreeDevice()
such so that it frees the relevant hunks, rather than leaving that to
the caller.
Some memory stats from the drmdev
Signed-off-by: Emil Velikov
---
util_math.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/util_math.h b/util_math.h
index 3bc5f64..02b15a8 100644
--- a/util_math.h
+++ b/util_math.h
@@ -26,6 +26,7 @@
#define MIN2( A, B ) ( (A)<(B) ? (A) : (B) )
#define MAX2( A, B ) ( (A)>(B) ? (A) :
Move away form the boolean name, change the return value
appropriately and check if either argument is NULL.
Signed-off-by: Emil Velikov
---
xf86drm.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/xf86drm.c b/xf86drm.c
index dc1782d..310d1e8 100644
--- a/xf86
Third and final piece of making drmGetDevices less crazy/ugly.
Signed-off-by: Emil Velikov
---
xf86drm.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/xf86drm.c b/xf86drm.c
index 1174a64..dc1782d 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -2835,21 +2835,
As with previous commit let's try to keep drmGetDevices clean of linux
specifics.
Signed-off-by: Emil Velikov
---
xf86drm.c | 36 +++-
1 file changed, 15 insertions(+), 21 deletions(-)
diff --git a/xf86drm.c b/xf86drm.c
index b4c5aa0..1174a64 100644
--- a/xf86drm
This will allow one to reuse the core drmGetDevices implementation on
other platforms. Keeping all the platform specifics in ParseFoo.
On the plus side this saves a bit of code :)
Signed-off-by: Emil Velikov
---
xf86drm.c | 46 --
1 file changed, 20 i
A simple example of how to use/what is the new drm{Get,Free}Devices()
interface.
Signed-off-by: Emil Velikov
---
tests/Makefile.am | 1 +
tests/drmdevice.c | 93 +++
2 files changed, 94 insertions(+)
create mode 100644 tests/drmdevice.c
diff
Hello all,
With this series, we add a couple of new functions drm{Get,Free}Device,
which will be used to query information about the opened device.
To do that some refactoring was done, plus an extra test is added to
demonstrate how the drm{Get,Free}Device{,s} can be used.
Any and all input wi
If backing->stolen is true then we were freeing backing by calling
psb_gtt_free_range() but we called it again after unlocking the mutex.
Lets make it NULL after freeing in psb_gtt_free_range() and check for
NULL before calling the function for the second time.
Signed-off-by: Sudip Mukherjee
---
On Wed, Sep 9, 2015 at 6:03 PM, Tvrtko Ursulin
wrote:
> It was just an example of a class of vulnerabilities which would be possible
> with these changes. If they, as you said, will preserve the last frame on
> screen when the compositor crashes.
If your compositor crashes something should take o
On Wed, Sep 09, 2015 at 04:47:08PM +0100, Tvrtko Ursulin wrote:
>
> On 09/09/2015 04:29 PM, Daniel Vetter wrote:
> >On Wed, Sep 09, 2015 at 04:18:02PM +0100, Tvrtko Ursulin wrote:
> >>
> >>On 09/09/2015 04:04 PM, Daniel Vetter wrote:
> >>>On Wed, Sep 09, 2015 at 03:51:50PM +0100, Tvrtko Ursulin wr
On 09/09/2015 05:26 PM, Maarten Lankhorst wrote:
> Op 09-09-15 om 18:15 schreef Tvrtko Ursulin:
>>
>> On 09/09/2015 05:07 PM, Daniel Vetter wrote:
>>> On Wed, Sep 9, 2015 at 6:03 PM, Tvrtko Ursulin
>>> wrote:
It was just an example of a class of vulnerabilities which would be
possible
On Wed, Sep 09, 2015 at 04:18:02PM +0100, Tvrtko Ursulin wrote:
>
> On 09/09/2015 04:04 PM, Daniel Vetter wrote:
> >On Wed, Sep 09, 2015 at 03:51:50PM +0100, Tvrtko Ursulin wrote:
> >>
> >>Hi,
> >>
> >>On 09/09/2015 03:40 PM, Maarten Lankhorst wrote:
> >>>Previously RMFB and fd close chose to disa
On 09/09/2015 05:07 PM, Daniel Vetter wrote:
> On Wed, Sep 9, 2015 at 6:03 PM, Tvrtko Ursulin
> wrote:
>> It was just an example of a class of vulnerabilities which would be possible
>> with these changes. If they, as you said, will preserve the last frame on
>> screen when the compositor crashes
On Wed, Sep 09, 2015 at 03:51:50PM +0100, Tvrtko Ursulin wrote:
>
> Hi,
>
> On 09/09/2015 03:40 PM, Maarten Lankhorst wrote:
> >Previously RMFB and fd close chose to disable any plane that had
> >an active framebuffer from this file. If it was a primary plane the
> >crtc was disabled. However the
On 09/09/2015 04:56 PM, Daniel Vetter wrote:
> On Wed, Sep 09, 2015 at 04:47:08PM +0100, Tvrtko Ursulin wrote:
>>
>> On 09/09/2015 04:29 PM, Daniel Vetter wrote:
>>> On Wed, Sep 09, 2015 at 04:18:02PM +0100, Tvrtko Ursulin wrote:
On 09/09/2015 04:04 PM, Daniel Vetter wrote:
> On Wed,
On Wed, Sep 09, 2015 at 04:40:56PM +0200, Maarten Lankhorst wrote:
> Previously RMFB and fd close chose to disable any plane that had
> an active framebuffer from this file. If it was a primary plane the
> crtc was disabled. However the fbdev code or any system compositor
> should restore the plane
On Wed, Sep 09, 2015 at 04:33:33PM +0200, Maarten Lankhorst wrote:
> Op 09-09-15 om 13:59 schreef Daniel Vetter:
> > On Wed, Sep 9, 2015 at 1:51 PM, Ville Syrjälä
> > wrote:
> >> On Wed, Sep 09, 2015 at 01:46:21PM +0200, Maarten Lankhorst wrote:
> >>> This may cause issues because encoders are a
On 09/09/2015 04:29 PM, Daniel Vetter wrote:
> On Wed, Sep 09, 2015 at 04:18:02PM +0100, Tvrtko Ursulin wrote:
>>
>> On 09/09/2015 04:04 PM, Daniel Vetter wrote:
>>> On Wed, Sep 09, 2015 at 03:51:50PM +0100, Tvrtko Ursulin wrote:
Hi,
On 09/09/2015 03:40 PM, Maarten Lankhorst wr
With kms all the data getparam looks at is actually invariant, and
certainly not protected by the global kms mutex. With ums all the
setup code is already racy as hell, so this won't make things any
worse.
I've done this change so that all ioctl still used by kms drivers
are marked as DRM_UNLOCKED
We already express the drm/agp depencies correctly in Kconfig, so we
can rip this remnant from the shared drm core days.
Aside: Pretty much all the #ifdefs in radeon/nouveau could be killed
if ttm would provide dummy functions. I'm not going to volunteer for
that though.
v2: Use IS_ENABLED(CONFIG
Keep the fb_id, which means that any application exiting without
unsetting the framebuffer from all planes will preserve its contents.
This is similar to preserving the initial framebuffer, except all
planes are preserved.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_crtc.c | 11 +--
badly breaks vmwgfx multimon since the crtcs are no longer turned off at
framebuffer removal,
which is part of the user-space contract.
Also isn't this a security issue, since at, for example, Xorg crash, the
crtcs can be left scanning out from memory
DRM no longer owns?
/Thomas
Previously RMFB and fd close chose to disable any plane that had
an active framebuffer from this file. If it was a primary plane the
crtc was disabled. However the fbdev code or any system compositor
should restore the planes anyway so there's no need to do it twice.
The old fb_id is zero'd, so th
This is breaks the abi slightly, but allows preserving the framebuffer contents
across processes.
Any system compositor or fbdev should take care of resetting the planes and
mode anyway.
Restoring a framebuffer requires a call to getfb, which checks for
CAP_SYS_ADMIN, DRM_MASTER or access to the
Op 09-09-15 om 13:59 schreef Daniel Vetter:
> On Wed, Sep 9, 2015 at 1:51 PM, Ville Syrjälä
> wrote:
>> On Wed, Sep 09, 2015 at 01:46:21PM +0200, Maarten Lankhorst wrote:
>>> This may cause issues because encoders are already destroyed so removing
>>> active primaries may use freed memory. Inste
On 09/09/2015 04:04 PM, Daniel Vetter wrote:
> On Wed, Sep 09, 2015 at 03:51:50PM +0100, Tvrtko Ursulin wrote:
>>
>> Hi,
>>
>> On 09/09/2015 03:40 PM, Maarten Lankhorst wrote:
>>> Previously RMFB and fd close chose to disable any plane that had
>>> an active framebuffer from this file. If it was a
Remove the hack of including xf86drm.c (and friends), by reworking the
only requirement drmOpenMinor() to an open(buf...).
After all we do know the exact name of the device we're going to open,
so might as well use it. Replace hard-coded 16 with DRM_MAX_MINOR while
we're here.
Note that this does
Softpin allows userspace to take greater control of GPU virtual address
space and eliminates the need of relocations. It can also be used to
mirror addresses between GPU and CPU (shared virtual memory).
Calls to drm_intel_bo_emit_reloc are still required to build the list of
drm_i915_gem_exec_objec
From: Chris Wilson
Userspace can pass in an offset that it presumes the object is located
at. The kernel will then do its utmost to fit the object into that
location. The assumption is that userspace is handling its own object
locations (for example along with full-ppgtt) and that the kernel will
While support for 48b ppgtt is here, parameter enabling it is not known
to the sanitize function. Let's update it to allow selecting
full_48bit_ppgtt using module parameter.
Cc: Michel Thierry
Cc: Mika Kuoppala
Signed-off-by: MichaÅ Winiarski
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 5 +
The goal of this series is to start a discussion whether the interface and
implementation of softpin support proposed for libdrm is acceptable by all
interested parties.
The i915 patches are added so that it's easy to apply the series on latest
drm-intel-nightly and libdrm master and start using so
https://bugzilla.kernel.org/show_bug.cgi?id=103271
--- Comment #16 from Kevin McCormack ---
Right, I thought so. :) I have a busy day today and this week so it will take
me a couple of days to do the bisect. I hope I can be helpful!
--
You are receiving this mail because:
You are watching the a
On 7 September 2015 at 11:02, Michel Dänzer wrote:
> From: Michel Dänzer
>
> Fixes build failure due to unresolved log2.
>
Sigh I've completely forgot that we still have the #include
"xf86drm.c" hack around.
I'll resent the patch that nukes it shortly but until that gets
reviewed this fix will
On Tue, Sep 08, 2015 at 01:56:24PM +0200, Daniel Vetter wrote:
> This was only used for the ums+gem combo, so ripe for removal now that
> we only have kms code left.
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_dma.c | 31 +--
> 1 file changed, 1
On Tue, Sep 08, 2015 at 01:56:21PM +0200, Daniel Vetter wrote:
> We already express the drm/agp depencies correctly in Kconfig, so we
> can rip this remnant from the shared drm core days.
>
> Aside: Pretty much all the #ifdefs in radeon/nouveau could be killed
> if ttm would provide dummy function
Hi,
On 09/09/2015 03:40 PM, Maarten Lankhorst wrote:
> Previously RMFB and fd close chose to disable any plane that had
> an active framebuffer from this file. If it was a primary plane the
> crtc was disabled. However the fbdev code or any system compositor
> should restore the planes anyway so
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150909/4731dd16/attachment.html>
As the hardware description for this chip is the same as the sama5d4, we use
this SoC structures for layers and DC descriptions. Thus only 2 lines are added
to the atmel_hlcdc_of_match table.
The compatible string is already documented in the parent MFD driver's binding.
Signed-off-by: Nicolas Fer
ssignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150909/b43e061c/attachment-0001.html>
On Wed, Sep 09, 2015 at 04:07:09PM +0200, MichaÅ Winiarski wrote:
> From: Chris Wilson
>
> Userspace can pass in an offset that it presumes the object is located
> at. The kernel will then do its utmost to fit the object into that
> location. The assumption is that userspace is handling its own
Hi
On Wed, Sep 9, 2015 at 3:11 PM, Daniel Vetter wrote:
> On Wed, Sep 09, 2015 at 02:21:31PM +0200, David Herrmann wrote:
>> Various cleanups to the DRM core initialization and exit handlers:
>>
>> - Register chrdev last: Once register_chrdev() returns, open() will
>>succeed on the given chr
On Wed, Sep 09, 2015 at 02:21:30PM +0200, David Herrmann wrote:
> Right now, drm_sysfs_create() returns the newly allocated "struct class"
> to the caller (which is drm_core_init()), which then has to set the
> global variable 'drm_class'. During cleanup, though, we call
> drm_sysfs_destroy() which
On Wed, Sep 09, 2015 at 02:21:31PM +0200, David Herrmann wrote:
> Various cleanups to the DRM core initialization and exit handlers:
>
> - Register chrdev last: Once register_chrdev() returns, open() will
>succeed on the given chrdevs. This is usually not an issue, as no
>chardevs are reg
On Wed, Sep 09, 2015 at 02:21:33PM +0200, David Herrmann wrote:
> Now that we support connector hotplugging, user-space might see
> mode-object IDs coming and going asynchronously. Therefore, we must make
> sure to not re-use object IDs, so to not confuse user-space and introduce
> races. Therefore
On Wed, Sep 09, 2015 at 08:45:14AM -0400, Alex Deucher wrote:
> On Mon, Sep 7, 2015 at 11:22 AM, wrote:
> > From: Ville Syrjälä
> >
> > drm_av_sync_delay() doesn't change the passed in mode, so make it const.
> >
> > Signed-off-by: Ville Syrjälä
>
> For the series:
> Reviewed-by: Alex Deuc
On Wed, Sep 09, 2015 at 01:46:21PM +0200, Maarten Lankhorst wrote:
> This may cause issues because encoders are already destroyed so removing
> active primaries may use freed memory. Instead free the fb directly,
> ignoring refcount.
So what about fixing the cause, not the symptom? That is remove
Hi
On Tue, Sep 8, 2015 at 1:56 PM, Daniel Vetter wrote:
> And use it in radeon to replace all the ioctls no longer valid in kms
> mode. I plan to also use this later on when nuking the ums support for
> i915.
>
> Note that setting the function pointer in the ioctl table to NULL
> would amount to
Now that we support connector hotplugging, user-space might see
mode-object IDs coming and going asynchronously. Therefore, we must make
sure to not re-use object IDs, so to not confuse user-space and introduce
races. Therefore, all kernel-allocated objects will no longer recycle
IDs. Instead, we u
The drm_core.h header contains a set of constants meant to be used
throughout DRM. However, as it turns out, they're each used just once and
don't bring any benefit. They're also grossly mis-named and lack
name-spacing. This patch inlines them, or moves them into drm_internal.h
as appropriate:
-
Various cleanups to the DRM core initialization and exit handlers:
- Register chrdev last: Once register_chrdev() returns, open() will
succeed on the given chrdevs. This is usually not an issue, as no
chardevs are registered, yet. However, nodes can be created by
user-space via mknod(2),
Right now, drm_sysfs_create() returns the newly allocated "struct class"
to the caller (which is drm_core_init()), which then has to set the
global variable 'drm_class'. During cleanup, though, we call
drm_sysfs_destroy() which implicitly uses the global 'drm_class'. This is
confusing, as ownership
Simplify `foo == NULL || IS_ERR(foo)` via IS_ERR_OR_NULL(). This is
pretty commonly used all over the kernel, especially for debugfs/sysfs
cleanup paths.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/drm_sysfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/
Hey
Just a set of 5 random cleanup patches for DRM-core: Simplifying
drm_core_init/exit(), dropping drm_core.h and fixing the mode-object ID
allocations.
Thanks
David
David Herrmann (5):
drm: simplify drm_sysfs_destroy() via IS_ERR_OR_NULL()
drm: move drm_class into drm_sysfs.c
drm: cleanu
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150909/d1afff3f/attachment.html>
On Wed, Sep 9, 2015 at 1:51 PM, Ville Syrjälä
wrote:
> On Wed, Sep 09, 2015 at 01:46:21PM +0200, Maarten Lankhorst wrote:
>> This may cause issues because encoders are already destroyed so removing
>> active primaries may use freed memory. Instead free the fb directly,
>> ignoring refcount.
>
>
This may cause issues because encoders are already destroyed so removing
active primaries may use freed memory. Instead free the fb directly,
ignoring refcount.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_crtc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/dri
From: Dave Airlie
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c
b/drivers/gpu/drm/virtio/virtgpu_drv.c
index 1245d09..e00298e 100644
--- a/drivers/gpu/drm/virtio/vir
From: Dave Airlie
This is enough to enable DRI3.
Signed-off-by: Dave Airlie
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/Makefile| 2 +-
drivers/gpu/drm/virtio/virtgpu_drv.c | 13 +-
drivers/gpu/drm/virtio/virtgpu_drv.h | 12 ++
drivers/gpu/drm/virtio/virtgpu_p
Add the bits needed for opengl rendering support: query
capabilities, new virtio commands, drm ioctls.
Signed-off-by: Dave Airlie
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/Makefile| 3 +-
drivers/gpu/drm/virtio/virtgpu_drv.c | 10 +
drivers/gpu/drm/virtio/virtgpu_drv.
Add helper function to handle the submission of fenced control requests.
Make sure we initialize the fence while holding the virtqueue lock, so
requests can't be reordered.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_fence.c | 2 +-
drivers/gpu/drm/virtio/virtgpu_vq.c| 4
Add virtio_gpu_queue_ctrl_buffer_nolock function, which does the same as
virtio_gpu_queue_ctrl_buffer but does not take the virtqueue lock. The
caller must hold the lock instead.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_vq.c | 17 +
1 file changed, 13 inse
Hi,
Here comes the 3d rendering support patch series for virtio-gpu.
Corresponsing qemu patches have just been posted, patch series is here:
https://www.mail-archive.com/qemu-devel at nongnu.org/msg319956.html
The code is also available here:
https://www.kraxel.org/cgit/linux/log/?h=virtio-g
From: Daniel Kurtz
All the user of these functions are inside exynos-drm driver and
you don't need to export the symbols for that case.
Signed-off-by: Daniel Kurtz
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_core.c | 6 --
drivers/gpu/drm/exynos/exynos_drm_g2d.c
ee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150909/34814875/attachment-0001.html>
On 9 September 2015 at 03:33, Rob Herring wrote:
> On 09/08/2015 02:30 AM, Tomeu Vizoso wrote:
>> On 7 September 2015 at 22:50, Rob Herring wrote:
>>> On Mon, Sep 7, 2015 at 7:23 AM, Tomeu Vizoso >> collabora.com> wrote:
Hello,
I have a problem with the panel on my Tegra Chromebook
Hi Eric,
Thanks for starting to upstream this Analogix Slimport driver!
As Greg says, please move this driver to its intended directory, I presume:
/drivers/gpu/drm/bridge
And when you submit, use get_maintainer.pl to add the proper reviewers
and lists.
At present, you have no DRM folks, nor dri-
Hi Dave -
An atomic bookkeeping fix from Maarten, and DP i2c-over-aux retry loop
fixes from Ville.
BR,
Jani.
The following changes since commit 879a37d00f1882b1e56a66e626af4194d592d257:
Merge branch 'exynos-drm-next' of
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into d
|--- |NOTOURBUG
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150909/130821c8/attachment-0001.html>
Hi Dan,
Many thanks for this first review.
2015-09-09 5:38 GMT+02:00 Daniel Kurtz :
> Hi Eric,
>
> Thanks for starting to upstream this Analogix Slimport driver!
> As Greg says, please move this driver to its intended directory, I presume:
> /drivers/gpu/drm/bridge
>
I sent yesterday another ver
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150909/f66575b4/attachment.html>
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150909/cae21593/attachment.html>
this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150909/766876b7/attachment.html>
On Mon, Sep 7, 2015 at 11:22 AM, wrote:
> From: Ville Syrjälä
>
> drm_av_sync_delay() doesn't change the passed in mode, so make it const.
>
> Signed-off-by: Ville Syrjälä
For the series:
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/drm_edid.c | 2 +-
> include/drm/drm_edid.h |
https://bugzilla.kernel.org/show_bug.cgi?id=104251
--- Comment #1 from beta992 at gmail.com ---
Created attachment 187111
--> https://bugzilla.kernel.org/attachment.cgi?id=187111&action=edit
lspci
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=104251
Bug ID: 104251
Summary: [drm:si_dpm_set_power_state [radeon]] *ERROR*
si_set_sw_state failed
Product: Drivers
Version: 2.5
Kernel Version: Linux 4.2.0-1-mainline #1 SMP Mon Aug 3
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150909/060f2790/attachment-0001.html>
[ TO INTEL DRM DRIVERS maintainers ]
Hi,
out of curiosity and to play with the new bindeb-pkg make-target I
built pre-v4.3-rc1 (git-describe says v4.2-10463-g9a9952bbd76a)
Debian-kernel packages.
I see several bugs and call-traces.
Two hit a warning in i915 (one snippet here, full dmesg-log and
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20150909/784c0eb9/attachment.html>
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150909/d611bfc6/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20150909/d38feb51/attachment.html>
> -Original Message-
> From: Peter Senna Tschudin [mailto:peter.senna at gmail.com]
> Sent: Monday, September 07, 2015 11:09 AM
> To: David Airlie; Deucher, Alexander; Koenig, Christian; Zhou, Jammy; dri-
> devel at lists.freedesktop.org; linux-kernel at vger.kernel.org
> Subject: similar f
...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150909/42d9c839/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=103271
--- Comment #15 from Michel Dänzer ---
(In reply to Michel Dänzer from comment #13)
> You should only run "git bisect" for commits which exhibit the same symptoms
> as described in this report.
That should have said "git bisect bad" BTW.
--
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150909/8d6285db/attachment.sig>
98 matches
Mail list logo
