[Bug 94171] ati multihead black on one output

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=94171

--- Comment #3 from Alex Deucher  ---
The fix works.  Tested by another user on this bug:
https://bugs.freedesktop.org/show_bug.cgi?id=89505
Just waiting for feedback from Christian.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 84648] Lag/Pause When VRAM->GTT or GTT->VRAM transfer occur

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=84648

--- Comment #15 from Alex Deucher  ---
(In reply to J0k3r from comment #14)
> Alex, as I understand it these kernel changes are just going to make it into
> 4.1. That's a long time in the future. Will the fixes be backported to
> 3.19/4.0?

They were applied to 4.0 and they will also show up in the stable kernels.

-- 
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/20150315/d66961fa/attachment.html>

[PATCH 2/2] drm_atomic_helper.c: connector => tmp_connector

[John Hunter]

I'm not sure whether this is right, as far as I can see, for the
macro 'list_for_each_entry', if not use the tmp_connector, it does
make sense.

Hope I am right with that.
---
 drivers/gpu/drm/drm_atomic_helper.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index bc17019..2abded1 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2027,10 +2027,10 @@ retry:
WARN_ON(!drm_modeset_is_locked(>connection_mutex));

list_for_each_entry(tmp_connector, >connector_list, head) {
-   if (connector->state->crtc != crtc)
+   if (tmp_connector->state->crtc != crtc)
continue;

-   if (connector->dpms == DRM_MODE_DPMS_ON) {
+   if (tmp_connector->dpms == DRM_MODE_DPMS_ON) {
active = true;
break;
}
-- 
1.9.1

[PATCH 1/2] drm_atomic_helper.c: cosmetic: fix some typos and add some empty line

[John Hunter]

there are some duplication in the annotations
add some empty line to make it easier to read
---
 drivers/gpu/drm/drm_atomic_helper.c | 48 +
 1 file changed, 38 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index a745881..bc17019 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -346,7 +346,7 @@ needs_modeset(struct drm_crtc_state *state)
 }

 /**
- * drm_atomic_helper_check - validate state object for modeset changes
+ * drm_atomic_helper_check_modeset - validate state object for modeset changes
  * @dev: DRM device
  * @state: the driver state object
  *
@@ -461,7 +461,7 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
 EXPORT_SYMBOL(drm_atomic_helper_check_modeset);

 /**
- * drm_atomic_helper_check - validate state object for modeset changes
+ * drm_atomic_helper_check_planes - validate state object for planes changes
  * @dev: DRM device
  * @state: the driver state object
  *
@@ -605,7 +605,7 @@ disable_outputs(struct drm_device *dev, struct 
drm_atomic_state *old_state)

/*
 * Each encoder has at most one connector (since we always steal
-* it away), so we won't call call disable hooks twice.
+* it away), so we won't call disable hooks twice.
 */
if (encoder->bridge)
encoder->bridge->funcs->disable(encoder->bridge);
@@ -757,7 +757,7 @@ crtc_set_mode(struct drm_device *dev, struct 
drm_atomic_state *old_state)

/*
 * Each encoder has at most one connector (since we always steal
-* it away), so we won't call call mode_set hooks twice.
+* it away), so we won't call mode_set hooks twice.
 */
if (funcs->mode_set)
funcs->mode_set(encoder, mode, adjusted_mode);
@@ -858,7 +858,7 @@ void drm_atomic_helper_commit_modeset_enables(struct 
drm_device *dev,

/*
 * Each encoder has at most one connector (since we always steal
-* it away), so we won't call call enable hooks twice.
+* it away), so we won't call enable hooks twice.
 */
if (encoder->bridge)
encoder->bridge->funcs->pre_enable(encoder->bridge);
@@ -1025,7 +1025,7 @@ int drm_atomic_helper_commit(struct drm_device *dev,

/*
 * Everything below can be run asynchronously without the need to grab
-* any modeset locks at all under one conditions: It must be guaranteed
+* any modeset locks at all under one condition: It must be guaranteed
 * that the asynchronous work has either been cancelled (if the driver
 * supports it, which at least requires that the framebuffers get
 * cleaned up with drm_atomic_helper_cleanup_planes()) or completed
@@ -1151,7 +1151,6 @@ fail:

if (fb && funcs->cleanup_fb)
funcs->cleanup_fb(plane, fb, plane_state);
-
}

return ret;
@@ -1301,8 +1300,11 @@ void drm_atomic_helper_swap_state(struct drm_device *dev,
  struct drm_atomic_state *state)
 {
int i;
+   int nconnectors = dev->mode_config.num_connector;
+   int ncrtcs = dev->mode_config.num_crtc;
+   int nplanes = dev->mode_config.num_total_plane;

-   for (i = 0; i < dev->mode_config.num_connector; i++) {
+   for (i = 0; i < nconnectors; i++) {
struct drm_connector *connector = state->connectors[i];

if (!connector)
@@ -1313,7 +1315,7 @@ void drm_atomic_helper_swap_state(struct drm_device *dev,
connector->state->state = NULL;
}

-   for (i = 0; i < dev->mode_config.num_crtc; i++) {
+   for (i = 0; i < ncrtcs; i++) {
struct drm_crtc *crtc = state->crtcs[i];

if (!crtc)
@@ -1324,7 +1326,7 @@ void drm_atomic_helper_swap_state(struct drm_device *dev,
crtc->state->state = NULL;
}

-   for (i = 0; i < dev->mode_config.num_total_plane; i++) {
+   for (i = 0; i < nplanes; i++) {
struct drm_plane *plane = state->planes[i];

if (!plane)
@@ -1373,6 +1375,7 @@ int drm_atomic_helper_update_plane(struct drm_plane 
*plane,
return -ENOMEM;

state->acquire_ctx = drm_modeset_legacy_acquire_ctx(crtc);
+
 retry:
plane_state = drm_atomic_get_plane_state(state, plane);
if (IS_ERR(plane_state)) {
@@ -1402,6 +1405,7 @@ retry:

/* Driver takes ownership of state on successful commit. */
return 0;
+
 fail:
if (ret == -EDEADLK)
goto backoff;
@@ -1409,6 +1413,7 @@ fail:
drm_atomic_state_free(state);

return ret;
+
 backoff:
drm_atomic_state_clear(state);

[git pull] drm fixes - slightly urgent

[Dave Airlie]

Hi Linus,

hope this can make -rc4, an oops snuck in in -rc3 patch, this fixes it.

Dave.

The following changes since commit 6981e2af36b0d96404b60df29e90068855a81225:

  Merge tag 'fixes-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc (2015-03-15 10:49:38 
-0700)

are available in the git repository at:


  git://people.freedesktop.org/~airlied/linux drm-fixes

for you to fetch changes up to 046d669c62f37323ef0329c41d83a03c06b2087d:

  [PATCH] drm/mm: Fix support 4 GiB and larger ranges (2015-03-16 06:28:50 
+1000)


Krzysztof Kolasa (1):
  drm/mm: Fix support 4 GiB and larger ranges

 drivers/gpu/drm/drm_mm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

commit 440fd52 drm/mm: Support 4GiB and larger ranges oops on 32bit kernel

[Krzysztof Kolasa]

Problem solved and tested:

[PATCH] drm/mm: Fix support 4 GiB and larger ranges

bad argument if(tmp)... in check_free_hole

fix oops: kernel BUG at drivers/gpu/drm/drm_mm.c:305!

Signed-off-by: Krzysztof Kolasa 
---
 drivers/gpu/drm/drm_mm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index 7fc6f8b..1134526 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -403,7 +403,7 @@ static int check_free_hole(u64 start, u64 end, u64 size, 
unsigned alignment)
 unsigned rem;

 rem = do_div(tmp, alignment);
-if (tmp)
+if (rem)
 start += alignment - rem;
 }

-- 
2.3.3.dirty

On 11.03.2015 09:13, Chris Wilson wrote:
> [cc'ing lists]
>
> On Tue, Mar 10, 2015 at 07:17:22PM +0100, Krzysztof Kolasa wrote:
>> System ( 32bit, Intel 945GM ) hangs after some short time, oops:
>>
>> [ cut here ]
>> kernel BUG at drivers/gpu/drm/drm_mm.c:305!
>> invalid opcode:  [#1] SMP
>> Modules linked in: arc4 md4 cfg80211 8192cu(O) pci_stub vboxpci(O)
>> vboxnetadp(O) vboxnetflt(O) vboxdrv(O) snd_hda_codec_si3054
>> snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel
>> snd_hda_controller snd_hda_codec snd_hwdep snd_pcm microcode
>> snd_seq_midi snd_seq_midi_event snd_rawmidi joydev serio_raw snd_seq
>> snd_timer snd_seq_device rfcomm bnep bluetooth i915 snd lpc_ich
>> drm_kms_helper soundcore drm i2c_algo_bit parport_pc ppdev video
>> mac_hid coretemp lp parport nls_utf8 cifs usb_storage psmouse
>> 8139too 8139cp mii
>> CPU: 0 PID: 1165 Comm: Xorg Tainted: G   O
>> 4.0.0-rc3-winsoft-x86+ #11
>> Hardware name: FUJITSU SIEMENS AMILO Pro Edition V3405/AMILO
>> Pro Edition V3405, BIOS R01-B0E03/20/2007
>> task: f64e0db0 ti: f4566000 task.ti: f4566000
>> EIP: 0060:[] EFLAGS: 00213206 CPU: 0
>> EIP is at drm_mm_insert_node_in_range_generic+0x432/0x4d0 [drm]
>> EAX: 0100 EBX: 00c78000 ECX: f6d4c908 EDX: 
>> ESI: f6d4c900 EDI: f6d4c900 EBP: f4567c78 ESP: f4567bf8
>> DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
>> CR0: 8005003b CR2: b4a02000 CR3: 345f2000 CR4: 07f0
>> Stack:
>>  f4567c64  0080  0080 f6d4c900  f4882700
>>     00a88000  1000 00478000 
>>     00f0    f472c33c
>> Call Trace:
>>  [] i915_gem_object_pin_view+0x3ce/0x840 [i915]
>>  [] ? i915_gem_obj_lookup_or_create_vma_view+0x41/0x160 [i915]
>>  [] i915_gem_execbuffer_reserve_vma.isra.11+0x62/0x100 [i915]
>>  [] i915_gem_execbuffer_reserve+0x291/0x2e0 [i915]
>>  [] i915_gem_do_execbuffer.isra.16+0x4f0/0xd10 [i915]
>>  [] ? poll_select_copy_remaining+0x100/0x100
>>  [] ? __kmalloc+0x4d/0x190
>>  [] i915_gem_execbuffer2+0x8b/0x2c0 [i915]
>>  [] ? i915_gem_execbuffer+0x4e0/0x4e0 [i915]
>>  [] drm_ioctl+0x1b7/0x510 [drm]
>>  [] ? i915_gem_execbuffer+0x4e0/0x4e0 [i915]
>>  [] ? ktime_get_ts64+0x52/0x1a0
>>  [] ? drm_getmap+0xb0/0xb0 [drm]
>>  [] do_vfs_ioctl+0x30a/0x530
>>  [] ? _copy_to_user+0x26/0x30
>>  [] ? ktime_get_ts64+0x52/0x1a0
>>  [] ? __fget_light+0x22/0x60
>>  [] SyS_ioctl+0x60/0x90
>>  [] sysenter_do_call+0x12/0x12
>> Code: ff ff 3b 55 e8 8d 74 26 00 77 10 73 04 0f 0b 66 90 3b 45 e4 90
>> 8d 74 26 00 72 f2 8b 75 94 03 46 20 13 56 24 3b 55 f0 72 0d 76 06
>> <0f> 0b 8d 74 26 00 3b 45 ec 77 f5 39 55 c4 77 10 73 04 0f 0b 66
>> EIP: [] drm_mm_insert_node_in_range_generic+0x432/0x4d0
>> [drm] SS:ESP 0068:f4567bf8
>> ---[ end trace 4648f53699b9eb32 ]---
>>
>> after revert commit 440fd52 system working OK
>>
>> Krzysztof
>>

commit 440fd52 drm/mm: Support 4GiB and larger ranges oops on 32bit kernel

[Chris Wilson]

On Sun, Mar 15, 2015 at 08:22:36PM +0100, Krzysztof Kolasa wrote:
> Problem solved and tested:
> 
> [PATCH] drm/mm: Fix support 4 GiB and larger ranges
> 
> bad argument if(tmp)... in check_free_hole
> 
> fix oops: kernel BUG at drivers/gpu/drm/drm_mm.c:305!
> 
> Signed-off-by: Krzysztof Kolasa 

Nice catch!
Reviewed-by: Chris wilson 
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Connection to the remote recipient's server was denied for unknown reason

[John Hunter]

Hi,
I was trying to send some patches using git send email, but I got the error
msg:
"Connection to the remote recipient's server was denied for unknown reason"
Can anybody help?

-- 
Best regards
Junwang Zhao
Microprocessor Research and Develop Center
Department of Computer Science 
Peking University
Beijing, 100871, PRC
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150315/ba00e8dc/attachment.html>

[PATCH] nouveau: add coherent BO attribute

[Alexandre Courbot]

On 03/14/2015 04:33 AM, Maarten Lankhorst wrote:
> Hey,
>
> Op 13-03-15 om 07:27 schreef Alexandre Courbot:
>> Add a flag allowing Nouveau to specify that an object should be coherent
>> at allocation time. This is required for some class of objects like
>> fences which are randomly-accessed by both the CPU and GPU. This flag
>> instructs the kernel driver to make sure the object remains coherent
>> even on architectures for which coherency is not guaranteed by the bus.
>>
>> Signed-off-by: Alexandre Courbot 
> I don't see a problem with this patch, but similar patches to intel to libdrm 
> have been shot down when the changes weren't in an official kernel yet, so I 
> think this should wait until the change is at least in drm-next. ;-)

Sounds good. I will ping you again once the kernel change reaches -next.

[PATCH] drm/radeon: fix TOPDOWN handling for bo_create

[Oded Gabbay]

On 03/12/2015 11:36 AM, Christian König wrote:
> On 12.03.2015 10:30, Oded Gabbay wrote:
>>
>> On 03/12/2015 11:23 AM, Christian König wrote:
>>> On 12.03.2015 10:02, Michel Dänzer wrote:
 On 12.03.2015 06:14, Alex Deucher wrote:
> On Wed, Mar 11, 2015 at 4:51 PM, Alex Deucher  
> wrote:
>> On Wed, Mar 11, 2015 at 2:21 PM, Christian König
>>  wrote:
>>> On 11.03.2015 16:44, Alex Deucher wrote:
 radeon_bo_create() calls radeon_ttm_placement_from_domain()
 before ttm_bo_init() is called.  radeon_ttm_placement_from_domain()
 uses the ttm bo size to determine when to select top down
 allocation but since the ttm bo is not initialized yet the
 check is always false.

 Noticed-by: Oded Gabbay 
 Signed-off-by: Alex Deucher 
 Cc: stable at vger.kernel.org
>>> And I was already wondering why the heck the BOs always made this
>>> ping/pong
>>> in memory after creation.
>>>
>>> Patch is Reviewed-by: Christian König 
>> And fixing that promptly broke VCE due to vram location requirements.
>> Updated patch attached.  Thoughts?
> And one more take to make things a bit more explicit for static kernel
> driver allocations.
 struct ttm_place::lpfn is honoured even with TTM_PL_FLAG_TOPDOWN, so
 latter should work with RADEON_GEM_CPU_ACCESS. It sounds like the
 problem is really that some BOs are expected to be within a certain
 range from the beginning of VRAM, but lpfn isn't set accordingly. It
 would be better to fix that by setting lpfn directly than indirectly via
 RADEON_GEM_CPU_ACCESS.
>>> Yeah, agree. We should probably try to find the root cause of this instead.
>>>
>>> As far as I know VCE has no documented limitation on where buffers are
>>> placed (unlike UVD). So this is a bit strange. Are you sure that it isn't
>>> UVD which breaks here?
>>>
>>> Regards,
>>> Christian.
>> I noticed this bug when trying to allocate very large BOs (385MB) from the
>> other side of VRAM.
>> However, even with this fix, the following scenario still fails:
>> 1. Allocate BO of 385MB on VRAM with no CPU access.
>> 2. Map it to VRAM
>> 3. Allocate second BO of 385MB on VRAM with no CPU access
>>
>> The last step fails as the ttm can't find a place to put this second BO. I
>> suspect the Top-Down thing isn't being respected at all by the
>> creation/pinning of BO.
>>
>> I think that what happens is that the first BO is pinned right after the
>> first 256 MB, instead of pinning it at the end of the VRAM.
>> Then, when trying to create the second BO, there is no room for it, as there
>> is only 256MB before the first BO, and 383MB after the first BO.
>>
>> I need to debug it further, but will probably only do that on Sunday.
>
> What is the content of radeon_vram_mm (in debugfs) after you allocated the 
> first
> BO?
>
> The placement should be visible there pretty fine.
>
> Regards,
> Christian.
>
Here are the contents before the allocation:
root at odedg-test:/sys/kernel/debug/dri/0# cat radeon_vram_mm
0x-0x0040: 0x0040: used
0x0040-0x0041: 0x0001: used
0x0041-0x0042: 0x0001: used
0x0042-0x0043: 0x0001: used
0x0043-0x0044: 0x0001: used
0x0044-0xeab4: 0xea70: free
0xeab4-0xedb4: 0x0300: used
0xedb4-0xf3b4: 0x0600: free
0xf3b4-0xf6b4: 0x0300: used
0xf6b4-0xf8b4: 0x0200: used
0xf8b4-0xfdc8: 0x0514: used
0xfdc8-0x0001: 0x0238: used
0x0001-0x0004: 0x0003: free
total: 262144, used 3984 free 258160

And here they are after the allocation of 385MB BO (not pinned yet):

root at odedg-test:/sys/kernel/debug/dri/0# cat radeon_vram_mm
0x-0x0040: 0x0040: used
0x0040-0x0041: 0x0001: used
0x0041-0x0042: 0x0001: used
0x0042-0x0043: 0x0001: used
0x0043-0x0044: 0x0001: used
0x0044-0xeab4: 0xea70: free
0xeab4-0xedb4: 0x0300: used
0xedb4-0xedb8: 0x0004: free
0xedb8-0xedb9: 0x0001: used
0xedb9-0xedc1: 0x0008: used
0xedc1-0xedc9: 0x0008: used
0xedc9-0xedd1: 0x0008: used
0xedd1-0xedd9: 0x0008: used
0xedd9-0xede1: 0x0008: used
0xede1-0xede9: 0x0008: used
0xede9-0xedf1: 0x0008: used
0xedf1-0xedf9: 0x0008: used
0xedf9-0xee01: 0x0008: used
0xee01-0xee09: 0x0008: used
0xee09-0xee11: 0x0008: used
0xee11-0xee19: 0x0008: used
0xee19-0xee21: 0x0008: used
0xee21-0xee29: 0x0008: used
0xee29-0xee31: 0x0008: used
0xee31-0xee39: 0x0008: used
0xee39-0xee41: 0x0008: used
0xee41-0xee49: 0x0008: used
0xee49-0xee51: 0x0008: used
0xee51-0xee59: 0x0008: used
0xee59-0xee61: 0x0008: used

[PATCH 3/3] drm: rcar-du: Enable the atomic updates API

[Laurent Pinchart]

Set the DRIVER_ATOMIC flag to enable usage of the atomic updates API
with the driver.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_drv.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c 
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index 1d9e4f8568ae..da1216a73969 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -252,7 +252,8 @@ static const struct file_operations rcar_du_fops = {
 };

 static struct drm_driver rcar_du_driver = {
-   .driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME,
+   .driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME
+   | DRIVER_ATOMIC,
.load   = rcar_du_load,
.unload = rcar_du_unload,
.preclose   = rcar_du_preclose,
-- 
2.0.5

[PATCH 2/3] drm: rcar-du: Don't initialize event->pipe field

[Laurent Pinchart]

The field is set by drm_send_vblank_event(), there's no need to
preinitialize it.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 9e72133bb64b..7d0b8ef9bea2 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -486,8 +486,6 @@ static void rcar_du_crtc_atomic_begin(struct drm_crtc *crtc)
unsigned long flags;

if (event) {
-   event->pipe = rcrtc->index;
-
WARN_ON(drm_crtc_vblank_get(crtc) != 0);

spin_lock_irqsave(>event_lock, flags);
-- 
2.0.5

[PATCH 1/3] drm: rcar-du: Fix framebuffer reference leak through plane state

[Laurent Pinchart]

Plane state duplication takes a reference to the framebuffer stored in
the state, but state destroy doesn't release it. This causes a reference
leak. Fix it.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_plane.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c 
b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
index 35a2f04ab799..210e5c3fd982 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
@@ -316,6 +316,9 @@ rcar_du_plane_atomic_duplicate_state(struct drm_plane 
*plane)
 static void rcar_du_plane_atomic_destroy_state(struct drm_plane *plane,
   struct drm_plane_state *state)
 {
+   if (state->fb)
+   drm_framebuffer_unreference(state->fb);
+
kfree(to_rcar_du_plane_state(state));
 }

-- 
2.0.5

[PATCH 0/3] R-Car DU fixes

[Laurent Pinchart]

Hello,

Here are three patches that fix issues with the R-Car DU driver implementation
of the atomic updates API. There's not much else to be said, please see
individual patches for details.

Laurent Pinchart (3):
  drm: rcar-du: Fix framebuffer reference leak through plane state
  drm: rcar-du: Don't initialize event->pipe field
  drm: rcar-du: Enable the atomic updates API

 drivers/gpu/drm/rcar-du/rcar_du_crtc.c  | 2 --
 drivers/gpu/drm/rcar-du/rcar_du_drv.c   | 3 ++-
 drivers/gpu/drm/rcar-du/rcar_du_plane.c | 3 +++
 3 files changed, 5 insertions(+), 3 deletions(-)

-- 
Regards,

Laurent Pinchart

[PATCH libdrm 4/8] xf86drmSL: Fix neighbour printing

[Jan Vesely]

Hi Kristian,

this patch partially reverts e4a519635:
Tidy up compile warnings by cleaning up types.

it looks to me that the xf86drmSL.c bits slipped in by accident.

thanks,
Jan

On Fri, 2015-02-27 at 13:07 -0500, Jan Vesely wrote:
> Signed-off-by: Jan Vesely 
> ---
>  xf86drmSL.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/xf86drmSL.c b/xf86drmSL.c
> index acddb54..2160bb8 100644
> --- a/xf86drmSL.c
> +++ b/xf86drmSL.c
> @@ -266,11 +266,14 @@ int drmSLLookupNeighbors(void *l, unsigned long key,
>  SkipListPtr   list = (SkipListPtr)l;
>  SLEntryPtrupdate[SL_MAX_LEVEL + 1];
>  int   retcode = 0;
> +SLEntryPtrentry;
> +
> +entry = SLLocate(list, key, update);
>  
>  *prev_key   = *next_key   = key;
>  *prev_value = *next_value = NULL;
> - 
> -if (update[0]) {
> +
> +if (entry && update[0]) {
>   *prev_key   = update[0]->key;
>   *prev_value = update[0]->value;
>   ++retcode;

-- 
Jan Vesely 
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150315/e69c32b0/attachment.sig>

[PATCH libdrm v2 1/8] Add static qualifier to local functions

[Jan Vesely]

v2: Don't bother marking dead functions static
(handler, xf86VDrvMsgVerb, drmSetDebugMsgFunction)

Signed-off-by: Jan Vesely 
---
 tests/drmstat.c |  2 +-
 tests/kmstest/main.c|  2 +-
 tests/modeprint/modeprint.c | 18 +-
 tests/proptest/proptest.c   |  2 +-
 tests/radeon/radeon_ttm.c   |  4 ++--
 5 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/tests/drmstat.c b/tests/drmstat.c
index 0ed5caf..c800ebb 100644
--- a/tests/drmstat.c
+++ b/tests/drmstat.c
@@ -82,7 +82,7 @@ static void getversion(int fd)
 }
 }

-void process_sigio(char *device)
+static void process_sigio(char *device)
 {
 int  fd;

diff --git a/tests/kmstest/main.c b/tests/kmstest/main.c
index 59e6113..1d4c63e 100644
--- a/tests/kmstest/main.c
+++ b/tests/kmstest/main.c
@@ -37,7 +37,7 @@
return ret; \
}

-int test_bo(struct kms_driver *kms)
+static int test_bo(struct kms_driver *kms)
 {
struct kms_bo *bo;
int ret;
diff --git a/tests/modeprint/modeprint.c b/tests/modeprint/modeprint.c
index 2d998d5..508c9f2 100644
--- a/tests/modeprint/modeprint.c
+++ b/tests/modeprint/modeprint.c
@@ -53,7 +53,7 @@ int crtcs;
 int fbs;
 char *module_name;

-const char* getConnectionText(drmModeConnection conn)
+static const char* getConnectionText(drmModeConnection conn)
 {
switch (conn) {
case DRM_MODE_CONNECTED:
@@ -67,7 +67,7 @@ const char* getConnectionText(drmModeConnection conn)

 }

-int printMode(struct drm_mode_modeinfo *mode)
+static int printMode(struct drm_mode_modeinfo *mode)
 {
if (full_modes) {
printf("Mode: %s\n", mode->name);
@@ -91,7 +91,7 @@ int printMode(struct drm_mode_modeinfo *mode)
return 0;
 }

-int printProperty(int fd, drmModeResPtr res, drmModePropertyPtr props, 
uint64_t value)
+static int printProperty(int fd, drmModeResPtr res, drmModePropertyPtr props, 
uint64_t value)
 {
const char *name = NULL;
int j;
@@ -162,7 +162,7 @@ static const char * const output_names[] = { "None",
 "DSI",
 };

-int printConnector(int fd, drmModeResPtr res, drmModeConnectorPtr connector, 
uint32_t id)
+static int printConnector(int fd, drmModeResPtr res, drmModeConnectorPtr 
connector, uint32_t id)
 {
int i = 0;
struct drm_mode_modeinfo *mode = NULL;
@@ -215,7 +215,7 @@ int printConnector(int fd, drmModeResPtr res, 
drmModeConnectorPtr connector, uin
return 0;
 }

-int printEncoder(int fd, drmModeResPtr res, drmModeEncoderPtr encoder, 
uint32_t id)
+static int printEncoder(int fd, drmModeResPtr res, drmModeEncoderPtr encoder, 
uint32_t id)
 {
printf("Encoder\n");
printf("\tid :%i\n", id);
@@ -226,7 +226,7 @@ int printEncoder(int fd, drmModeResPtr res, 
drmModeEncoderPtr encoder, uint32_t
return 0;
 }

-int printCrtc(int fd, drmModeResPtr res, drmModeCrtcPtr crtc, uint32_t id)
+static int printCrtc(int fd, drmModeResPtr res, drmModeCrtcPtr crtc, uint32_t 
id)
 {
printf("Crtc\n");
printf("\tid : %i\n", id);
@@ -240,7 +240,7 @@ int printCrtc(int fd, drmModeResPtr res, drmModeCrtcPtr 
crtc, uint32_t id)
return 0;
 }

-int printFrameBuffer(int fd, drmModeResPtr res, drmModeFBPtr fb)
+static int printFrameBuffer(int fd, drmModeResPtr res, drmModeFBPtr fb)
 {
printf("Framebuffer\n");
printf("\thandle: %i\n", fb->handle);
@@ -254,7 +254,7 @@ int printFrameBuffer(int fd, drmModeResPtr res, 
drmModeFBPtr fb)
return 0;
 }

-int printRes(int fd, drmModeResPtr res)
+static int printRes(int fd, drmModeResPtr res)
 {
int i;
drmModeFBPtr fb;
@@ -330,7 +330,7 @@ int printRes(int fd, drmModeResPtr res)
return 0;
 }

-void args(int argc, char **argv)
+static void args(int argc, char **argv)
 {
int i;

diff --git a/tests/proptest/proptest.c b/tests/proptest/proptest.c
index 4b7234d..9b2eb3f 100644
--- a/tests/proptest/proptest.c
+++ b/tests/proptest/proptest.c
@@ -44,7 +44,7 @@ static inline int64_t U642I64(uint64_t val)
 int fd;
 drmModeResPtr res = NULL;

-const char *connector_type_str(uint32_t type)
+static const char *connector_type_str(uint32_t type)
 {
switch (type) {
case DRM_MODE_CONNECTOR_Unknown:
diff --git a/tests/radeon/radeon_ttm.c b/tests/radeon/radeon_ttm.c
index ac3297a..8346e85 100644
--- a/tests/radeon/radeon_ttm.c
+++ b/tests/radeon/radeon_ttm.c
@@ -32,7 +32,7 @@
 /* allocate as many single page bo to try to starve the kernel
  * memory zone (below highmem)
  */
-void ttm_starve_kernel_private_memory(int fd)
+static void ttm_starve_kernel_private_memory(int fd)
 {
 struct list_head list;
 struct rbo *bo, *tmp;
@@ -55,7 +55,7 @@ void ttm_starve_kernel_private_memory(int fd)
 }
 }

-int radeon_open_fd(void)
+static int radeon_open_fd(void)
 {
 return drmOpen("radeon", NULL);
 }
-- 
2.1.0

[Bug 94171] ati multihead black on one output

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=94171

--- Comment #2 from Felix Miata  ---
Using the HD from the comment 0 system with the same cedar PCIe card installed
in a slightly older P965 system , which has no onboard Intel gfx, both VGA-0
and DVI-0 outputs remain functional in X also with Mageia 4's kernel 3.14.32,
as well as with all installations reported in comment 0, just as when using
x600. IOW, no failures of x600 or cedar in the P965 system regardless of
kernel.

Using the same x1300 in the P965 however, DVI-0 in X is always black and VGA-0
in X always works, in the installations using kernels newer than 3.14.32.

I subsequently retested the comment 0 system with the 2 of the same 3 ATI
cards, but using a HD cloned from the original. Instead of using the same rv370
x600 of the original 3 I used an rv380 x600. Only the x1300 failed to produce X
output on DVI-0, and only with kernels newer than 3.14.2, matching the behavior
of the P965 system with all 3 ATI cards.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.