[Bug 78453] [HAWAII] Get acceleration working

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

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

--- Comment #89 from Kai  ---
Created attachment 103477
  --> https://bugs.freedesktop.org/attachment.cgi?id=103477=edit
dmesg output after restarting X after lockup from comment #87

Oh, forgot to add: if I restart X after that, I get the attached additional
lines in dmesg.

After that I rebooted, logged into KDE (acceleration disabled), killed Konsole,
so it wouldn't automatically get startet and tried a login with acceleration
again. But still no luck: I'm still stuck on the last icon of the KDE loading
screen just before the desktop get's drawn the first time. After killing X I'm
seeing the GPU stall (see comment #83) again, just without the segfault in
Konsole.

Maybe it has something to do with the composition type and Qt graphic system
I've chosen in KDE for desktop effects? The composition type is set to "OpenGL
3.1" and the Qt graphic system is set to "Native".

-- 
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/20140725/74e7b7d6/attachment.html>

[Bug 78453] [HAWAII] Get acceleration working

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

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

--- Comment #88 from Alex Deucher  ---
Try re-grabbing my drm-next-3.17-wip tree.  I dropped the last commit.

-- 
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/20140725/7c5bf9e2/attachment.html>

[Bug 78453] [HAWAII] Get acceleration working

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

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

--- Comment #87 from Kai  ---
(In reply to comment #86) 
> If you want working desktop you can use this patch to disable the packet
> that is the issue. With that mesa patch i have stable acceleration and
> desktop.

Thanks J?r?me! The "EQ overflowing" is gone (same stack as detailed in comment
#82, except for Mesa, which is now at Git master/5eb11eb192 + the patch from
attachment 103474), but I'm still stuck on the KDE loading screen, just before
the desktop is drawn. After I kill X I see the three lines, I pasted in comment
#83, appearing again at the end of dmesg's output. So, no luck for me yet.

-- 
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/20140725/39d0a311/attachment.html>

[PATCHv2 2/2] gpu: drm: omapdrm: Change struct pat data_pa type to dma_addr_t

[Matwey V. Kornilov]

From: "Matwey V. Kornilov" 

The single one use-case for data_pa member of the struct pat is to carry a 
value of dma_addr_t type.
This patch solves the following compilation error:

../drivers/gpu/drm/omapdrm/omap_dmm_tiler.c: In function 'dmm_txn_append':
../drivers/gpu/drm/omapdrm/omap_dmm_tiler.c:226:2: error: passing argument 3 of 
'alloc_dma' from incompatible pointer type [-Werror]
  data = alloc_dma(txn, 4*i, >data_pa);
  ^
../drivers/gpu/drm/omapdrm/omap_dmm_tiler.c:77:14: note: expected 'dma_addr_t 
*' but argument is of type 'uint32_t *'
 static void *alloc_dma(struct dmm_txn *txn, size_t sz, dma_addr_t *pa)
  ^

Signed-off-by: Matwey V. Kornilov 
---
 drivers/gpu/drm/omapdrm/omap_dmm_priv.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_priv.h 
b/drivers/gpu/drm/omapdrm/omap_dmm_priv.h
index 58bcd6a..4142525 100644
--- a/drivers/gpu/drm/omapdrm/omap_dmm_priv.h
+++ b/drivers/gpu/drm/omapdrm/omap_dmm_priv.h
@@ -105,7 +105,7 @@ struct pat {
uint32_t next_pa;
struct pat_area area;
struct pat_ctrl ctrl;
-   uint32_t data_pa;
+   dma_addr_t data_pa;
 };

 #define DMM_FIXED_RETRY_COUNT 1000
-- 
1.8.1.4

[PATCHv2 1/2] gpu: drm: omapdrm: Use %pad format for values of the dma_addr_t type

[Matwey V. Kornilov]

From: "Matwey V. Kornilov" 

The format change is to fix the following compilation issue:

../drivers/gpu/drm/omapdrm/omap_plane.c: In function 'omap_plane_pre_apply':
../drivers/gpu/drm/omapdrm/omap_plane.c:145:2: error: format '%x' expects 
argument of type 'unsigned int', but argument 5 has type 'dma_addr_t' 
[-Werror=format=]
  DBG("%d,%d %08x %08x", info->pos_x, info->pos_y,
  ^
../drivers/gpu/drm/omapdrm/omap_plane.c:145:2: error: format '%x' expects 
argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' 
[-Werror=format=]
cc1: all warnings being treated as errors
../scripts/Makefile.build:273: recipe for target 
'drivers/gpu/drm/omapdrm/omap_plane.o' failed

Signed-off-by: Matwey V. Kornilov 
---
 drivers/gpu/drm/omapdrm/omap_gem.c   | 10 +-
 drivers/gpu/drm/omapdrm/omap_plane.c |  4 ++--
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c 
b/drivers/gpu/drm/omapdrm/omap_gem.c
index 95dbce2..d9f5e524 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem.c
@@ -791,7 +791,7 @@ int omap_gem_get_paddr(struct drm_gem_object *obj,
omap_obj->paddr = tiler_ssptr(block);
omap_obj->block = block;

-   DBG("got paddr: %08x", omap_obj->paddr);
+   DBG("got paddr: %pad", _obj->paddr);
}

omap_obj->paddr_cnt++;
@@ -985,9 +985,9 @@ void omap_gem_describe(struct drm_gem_object *obj, struct 
seq_file *m)

off = drm_vma_node_start(>vma_node);

-   seq_printf(m, "%08x: %2d (%2d) %08llx %08Zx (%2d) %p %4d",
+   seq_printf(m, "%08x: %2d (%2d) %08llx %pad (%2d) %p %4d",
omap_obj->flags, obj->name, 
obj->refcount.refcount.counter,
-   off, omap_obj->paddr, omap_obj->paddr_cnt,
+   off, _obj->paddr, omap_obj->paddr_cnt,
omap_obj->vaddr, omap_obj->roll);

if (omap_obj->flags & OMAP_BO_TILED) {
@@ -1467,8 +1467,8 @@ void omap_gem_init(struct drm_device *dev)
entry->paddr = tiler_ssptr(block);
entry->block = block;

-   DBG("%d:%d: %dx%d: paddr=%08x stride=%d", i, j, w, h,
-   entry->paddr,
+   DBG("%d:%d: %dx%d: paddr=%pad stride=%d", i, j, w, h,
+   >paddr,
usergart[i].stride_pfn << PAGE_SHIFT);
}
}
diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c 
b/drivers/gpu/drm/omapdrm/omap_plane.c
index 3cf31ee..6af3398 100644
--- a/drivers/gpu/drm/omapdrm/omap_plane.c
+++ b/drivers/gpu/drm/omapdrm/omap_plane.c
@@ -142,8 +142,8 @@ static void omap_plane_pre_apply(struct omap_drm_apply 
*apply)
DBG("%dx%d -> %dx%d (%d)", info->width, info->height,
info->out_width, info->out_height,
info->screen_width);
-   DBG("%d,%d %08x %08x", info->pos_x, info->pos_y,
-   info->paddr, info->p_uv_addr);
+   DBG("%d,%d %pad %pad", info->pos_x, info->pos_y,
+   >paddr, >p_uv_addr);

/* TODO: */
ilace = false;
-- 
1.8.1.4

[Bug 78453] [HAWAII] Get acceleration working

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

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

--- Comment #86 from Jerome Glisse  ---
Created attachment 103474
  --> https://bugs.freedesktop.org/attachment.cgi?id=103474=edit
Hack to temporarily fix accel

If you want working desktop you can use this patch to disable the packet that
is the issue. With that mesa patch i have stable acceleration and desktop.

-- 
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/20140725/177810a3/attachment.html>

[PATCH] drm/exynos: control blending of mixer graphic layer 0

[Joonyoung Shim]

The mixer graphic layer 0 isn't blended as default by commit
0377f4ed9f1aed30292c4e3c87f24e028ae26f36(drm/exynos: Don't blend mixer
layer 0). But it needs to be blended with graphic layer 0 if video layer
is enabled by vp because video layer is bottom.

Signed-off-by: Joonyoung Shim 
---
 drivers/gpu/drm/exynos/exynos_mixer.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 9d0c21a..0a1a065 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -365,6 +365,11 @@ static void mixer_cfg_layer(struct mixer_context *ctx, int 
win, bool enable)
vp_reg_writemask(res, VP_ENABLE, val, VP_ENABLE_ON);
mixer_reg_writemask(res, MXR_CFG, val,
MXR_CFG_VP_ENABLE);
+
+   /* control blending of graphic layer 0 */
+   mixer_reg_writemask(res, MXR_GRAPHIC_CFG(0), val,
+   MXR_GRP_CFG_BLEND_PRE_MUL |
+   MXR_GRP_CFG_PIXEL_BLEND_EN);
}
break;
}
-- 
1.8.1.2

[PATCH] drm: refcnt drm_display_mode

[Rob Clark]

We're going to need this for atomic.

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/drm_crtc.c|  4 +--
 drivers/gpu/drm/drm_crtc_helper.c |  2 +-
 drivers/gpu/drm/drm_edid.c|  6 ++--
 drivers/gpu/drm/drm_fb_helper.c   |  6 ++--
 drivers/gpu/drm/drm_modes.c   | 41 ---
 drivers/gpu/drm/exynos/exynos_drm_connector.c |  2 +-
 drivers/gpu/drm/gma500/psb_intel_sdvo.c   |  3 +-
 drivers/gpu/drm/i915/intel_panel.c|  8 ++
 drivers/gpu/drm/i915/intel_sdvo.c |  3 +-
 drivers/gpu/drm/nouveau/nouveau_connector.c   |  2 +-
 drivers/gpu/drm/omapdrm/omap_connector.c  |  2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c   |  4 +--
 include/drm/drm_modes.h   |  5 +++-
 13 files changed, 52 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 1ccf5cb..7a7fced 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -822,7 +822,7 @@ static void drm_mode_remove(struct drm_connector *connector,
struct drm_display_mode *mode)
 {
list_del(>head);
-   drm_mode_destroy(connector->dev, mode);
+   drm_mode_unreference(mode);
 }

 /**
@@ -2602,7 +2602,7 @@ out:
drm_framebuffer_unreference(fb);

kfree(connector_set);
-   drm_mode_destroy(dev, mode);
+   drm_mode_unreference(mode);
drm_modeset_unlock_all(dev);
return ret;
 }
diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
b/drivers/gpu/drm/drm_crtc_helper.c
index 6c65a0a..757de8b 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -384,7 +384,7 @@ bool drm_crtc_helper_set_mode(struct drm_crtc *crtc,

/* FIXME: add subpixel order */
 done:
-   drm_mode_destroy(dev, adjusted_mode);
+   drm_mode_unreference(adjusted_mode);
if (!ret) {
crtc->enabled = saved_enabled;
crtc->mode = saved_mode;
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 087d608..cbc021d 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1705,7 +1705,7 @@ drm_mode_std(struct drm_connector *connector, struct edid 
*edid,
if (!mode)
return NULL;
if (drm_mode_hsync(mode) > drm_gtf2_hbreak(edid)) {
-   drm_mode_destroy(dev, mode);
+   drm_mode_unreference(mode);
mode = drm_gtf_mode_complex(dev, hsize, vsize,
vrefresh_rate, 0, 0,
drm_gtf2_m(edid),
@@ -2021,7 +2021,7 @@ drm_gtf_modes_for_range(struct drm_connector *connector, 
struct edid *edid,
fixup_mode_1366x768(newmode);
if (!mode_in_range(newmode, edid, timing) ||
!valid_inferred_mode(connector, newmode)) {
-   drm_mode_destroy(dev, newmode);
+   drm_mode_unreference(newmode);
continue;
}

@@ -2050,7 +2050,7 @@ drm_cvt_modes_for_range(struct drm_connector *connector, 
struct edid *edid,
fixup_mode_1366x768(newmode);
if (!mode_in_range(newmode, edid, timing) ||
!valid_inferred_mode(connector, newmode)) {
-   drm_mode_destroy(dev, newmode);
+   drm_mode_unreference(newmode);
continue;
}

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 3144db9..5c96a6a 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -588,7 +588,7 @@ static void drm_fb_helper_crtc_free(struct drm_fb_helper 
*helper)
for (i = 0; i < helper->crtc_count; i++) {
kfree(helper->crtc_info[i].mode_set.connectors);
if (helper->crtc_info[i].mode_set.mode)
-   drm_mode_destroy(helper->dev, 
helper->crtc_info[i].mode_set.mode);
+   
drm_mode_unreference(helper->crtc_info[i].mode_set.mode);
}
kfree(helper->crtc_info);
 }
@@ -1606,7 +1606,7 @@ static void drm_setup_crtcs(struct drm_fb_helper 
*fb_helper)
  mode->name, 
fb_crtc->mode_set.crtc->base.id);
fb_crtc->desired_mode = mode;
if (modeset->mode)
-   drm_mode_destroy(dev, modeset->mode);
+   drm_mode_unreference(modeset->mode);
modeset->mode = drm_mode_duplicate(dev,
   
fb_crtc->desired_mode);
modeset->connectors[modeset->num_connectors++] = 
fb_helper->connector_info[i]->connector;
@@ -1621,7 +1621,7 @@ static void 

[Radeon RV280] radeon_cs_gem.c:181: cs_gem_write_reloc: Assertion »boi->space_accounted« failed, core dumped

[Jochen Rollwagen]

I've recently ported the peopsxgl OpenGL-GPU-Plugin for the pcsx 
Playstation1 Emulator to the Powerpc-architecture. When running certain 
games (for instance "Vagrant Stories") during longer cut-scenes i get a 
reproducible crash of the radeon drm driver (i.e. it always crashes at 
certain points in the scene) with the following message (in german):

pcsx: radeon_cs_gem.c:181: cs_gem_write_reloc: Zusicherung 
?boi->space_accounted? nicht erf?llt.
Abgebrochen (Speicherabzug geschrieben)

This happens with all the latest 3.10, 3.12 and 3.14 kernels.

Other than that i'm running the latest xorg-ati driver, libdrm and mesa 
from git on a Mac Mini G4 (PowerPC).

OpenGL vendor string: Mesa Project
OpenGL renderer string: Mesa DRI R200 (RV280 5962)  TCL DRI2
OpenGL version string: 1.3 Mesa 10.1.6 (git-42f86ef)

I guess the issue is memory/vm/swap-related since the machine only has 1 
gb RAM. The GPU has 64 MB VRAM.

Any ideas what i could do to avoid these crashes ?

[Bug 78453] [HAWAII] Get acceleration working

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

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

--- Comment #85 from Kai  ---
I think I can answer your questions, since I got acceleration working up to the
point where it crashed (see comment #82).

(In reply to comment #84)
> I did as instructed, but couldn't yet get accel to work (llvmpipe is used).
> A few questions:
> 1. Do I need to rename the firmware files to uppercase ? (HAWAII_ce.bin
> instead of hawaii_ce.bin) ?

No. I didn't rename the files and they were correctly loaded.

> 2. Does the current radeon stuff already work with the glamor that got
> merged into xorg-server 1.16 or do I need the external glamor ? (does that
> work with 1.16 ?)

Yes. My 7.4.0 came up with the integrated GLAMOR. And just yesterday I helped a
friend with an OLAND to get it set up with the free drivers. His setup uses
also a 1.16.0 server and the DDX uses the integrated GLAMOR.

> 3. As far as I know, the "NoAccel" xorg.conf option was renamed to "Accel".
> Is that still necessary with your xf86-video-ati patch ?

My xorg.conf had only a 'Driver "radeon"' line (since I don't have the -ati
loader shim around). No "Accel" or other option was set (and yes, it's Accel
with 7.4.0).

-- 
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/20140725/a1e8215d/attachment.html>

[Bug 78453] [HAWAII] Get acceleration working

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

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

--- Comment #84 from Luzipher  ---
First: Thanks Alex for looking into this and making progress !

I did as instructed, but couldn't yet get accel to work (llvmpipe is used). A
few questions:
1. Do I need to rename the firmware files to uppercase ? (HAWAII_ce.bin instead
of hawaii_ce.bin) ?
2. Does the current radeon stuff already work with the glamor that got merged
into xorg-server 1.16 or do I need the external glamor ? (does that work with
1.16 ?)
3. As far as I know, the "NoAccel" xorg.conf option was renamed to "Accel". Is
that still necessary with your xf86-video-ati patch ?

-- 
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/20140725/5b6e7d76/attachment.html>

[PATCH] drm/radeon: use packet2 for nop on hawaii with old firmware

[Alex Deucher]

Older firmware didn't support the new nop packet.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/cik.c | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index 44d25da..80a7ce0 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -8259,6 +8259,7 @@ restart_ih:
 static int cik_startup(struct radeon_device *rdev)
 {
struct radeon_ring *ring;
+   u32 nop;
int r;

/* enable pcie gen2/3 link */
@@ -8392,9 +8393,18 @@ static int cik_startup(struct radeon_device *rdev)
}
cik_irq_set(rdev);

+   if (rdev->family == CHIP_HAWAII) {
+   if (rdev->new_fw)
+   nop = PACKET3(PACKET3_NOP, 0x3FFF);
+   else
+   nop = RADEON_CP_PACKET2;
+   } else {
+   nop = PACKET3(PACKET3_NOP, 0x3FFF);
+   }
+
ring = >ring[RADEON_RING_TYPE_GFX_INDEX];
r = radeon_ring_init(rdev, ring, ring->ring_size, 
RADEON_WB_CP_RPTR_OFFSET,
-PACKET3(PACKET3_NOP, 0x3FFF));
+nop);
if (r)
return r;

@@ -8402,7 +8412,7 @@ static int cik_startup(struct radeon_device *rdev)
/* type-2 packets are deprecated on MEC, use type-3 instead */
ring = >ring[CAYMAN_RING_TYPE_CP1_INDEX];
r = radeon_ring_init(rdev, ring, ring->ring_size, 
RADEON_WB_CP1_RPTR_OFFSET,
-PACKET3(PACKET3_NOP, 0x3FFF));
+nop);
if (r)
return r;
ring->me = 1; /* first MEC */
@@ -8413,7 +8423,7 @@ static int cik_startup(struct radeon_device *rdev)
/* type-2 packets are deprecated on MEC, use type-3 instead */
ring = >ring[CAYMAN_RING_TYPE_CP2_INDEX];
r = radeon_ring_init(rdev, ring, ring->ring_size, 
RADEON_WB_CP2_RPTR_OFFSET,
-PACKET3(PACKET3_NOP, 0x3FFF));
+nop);
if (r)
return r;
/* dGPU only have 1 MEC */
-- 
1.8.3.1

[PATCH 2/2] drm/exynos: dsi: add LPM (Low Power Mode) transfer support

[Inki Dae]

On 2014? 07? 24? 19:48, Andrzej Hajda wrote:
> +CC: Thierry and Alexandre
> 
> On 07/18/2014 12:56 PM, Inki Dae wrote:
>> This patch adds LPM transfer support for video or command data.
>>
>> With this patch, Exynos MIPI DSI controller can transfer command or
>> video data with HS or LP mode in accordance with mode_flags set
>> by LCD Panel driver.
>>
>> Signed-off-by: Inki Dae 
>> Acked-by: Kyungmin Park 
>> ---
>>  drivers/gpu/drm/exynos/exynos_drm_dsi.c |   22 --
>>  1 file changed, 20 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> index 2df3592..b120554 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> @@ -426,13 +426,28 @@ static int exynos_dsi_enable_clock(struct exynos_dsi 
>> *dsi)
>>  | DSIM_ESC_PRESCALER(esc_div)
>>  | DSIM_LANE_ESC_CLK_EN_CLK
>>  | DSIM_LANE_ESC_CLK_EN_DATA(BIT(dsi->lanes) - 1)
>> -| DSIM_BYTE_CLK_SRC(0)
>> -| DSIM_TX_REQUEST_HSCLK;
>> +| DSIM_BYTE_CLK_SRC(0);
>> +
>> +if (!(dsi->mode_flags & MIPI_DSI_MODE_CMD_LPM))
>> +reg |= DSIM_TX_REQUEST_HSCLK;
>> +
> 
> Maybe I missed sth but it seems to me slightly unrelated to LPM flag.
> According to specs some panels can require this clock even in LPM mode.
> I wonder if recently introduced  MIPI_DSI_CLOCK_NON_CONTINUOUS wouldn't
> handle it.

It's different. MIPI DSI spec says,
"For continuous clock behaviour, the Clock Lane remains in high-speed
mode generating active clock signals between HS data packet
transmissions. For non-continuous clock behaviour, *the Clock Lane
enters the LP-11 state between HS data packet transmissions*."

> 
>>  writel(reg, dsi->reg_base + DSIM_CLKCTRL_REG);
>>  
>>  return 0;
>>  }
>>  
>> +static void exynos_dsi_enable_hs_clock(struct exynos_dsi *dsi,
>> +bool enable)
>> +{
>> +u32 reg = readl(dsi->reg_base + DSIM_CLKCTRL_REG);
>> +
>> +reg &= ~DSIM_TX_REQUEST_HSCLK;
>> +if (enable)
>> +reg |= DSIM_TX_REQUEST_HSCLK;
>> +
>> +writel(reg, dsi->reg_base + DSIM_CLKCTRL_REG);
>> +}
>> +
>>  static void exynos_dsi_disable_clock(struct exynos_dsi *dsi)
>>  {
>>  u32 reg;
>> @@ -575,6 +590,9 @@ static void exynos_dsi_set_display_enable(struct 
>> exynos_dsi *dsi, bool enable)
>>  {
>>  u32 reg;
>>  
>> +if (!(dsi->mode_flags & MIPI_DSI_MODE_VIDEO_LPM))
>> +exynos_dsi_enable_hs_clock(dsi, true);
>> +
> 
> It does not care about enable argument of the function, I guess it should.
> 

Yes, it's better to enable HS clock only in case of enabling. So will
add one more flag like below,

if (!(dsi->mode_flags & MIPI_DSI_MODE_VIDEO_LPM) && enable)

Thank,
Inki Dae

> Regards
> Andrzej
> 
>>  reg = readl(dsi->reg_base + DSIM_MDRESOL_REG);
>>  if (enable)
>>  reg |= DSIM_MAIN_STAND_BY;
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

[PATCH 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support

[Inki Dae]

On 2014? 07? 24? 19:23, Andrzej Hajda wrote:
> Hi Inki,
> 
> +CC: Thierry and Alexandre
> 
> On 07/18/2014 12:56 PM, Inki Dae wrote:
>> This patch adds below two flags for LPM transfer, and it attaches LPM flags
>> to a msg in accordance with master's mode_flags set by LCD Panel driver.
>>
>> MIPI_DSI_MODE_CMD_LPM: low power command transfer
>> MIPI_DSI_MODE_VIDEO_LPM: low power video transfer
> What is the difference between these two?

They mean that MIPI DSI controller have to transfer command or video to
Panel in Low Power Mode according to these flags.

> Why not just MIPI_DSI_MODE_LPM combined optionally with
> MIPI_DSI_MODE_VIDEO ?
> Anyway as I understand the only role of this flag is to always trigger
> MIPI_DSI_MSG_USE_LPM flag in DSI message. Maybe better is to check both
> flags in DSI host, using some helper function.

No any flag would mean that video and command data have to be
transferred in HS mode. On the other hands, if there is one of above
flags, the data would be transferred in Low Power Mode. So I think
separated flags, MIPI_DSI_MODE_VIDEO/COMMAND and MIPI_DSI_MODE_LPM
causes unnecessary flag combination.

> 
>>
>> MIPI DSI spec says,
>>  "the host processor controls the desired mode of clock operation.
>>   Host protocol and applications control Clock Lane operating mode
>>   (High Speed or Low Power mode). System designers are responsible
>>   for understanding the clock requirements for peripherals attached
>>   to DSI and controlling clock behavior in accordance with those
>>   requirements."
>>
>> Some LCD Panel devices, nt35502a, would need LPM transfer support
>> because they should receive some initial commands with LPM by default
>> hardware setting.
> 
> It would be good to see usage of this flag in the driver. Is it possible
> to post it?

Yes, but that driver is needed for more cleanup works. Anyway I will
post it in the near future.
> 
> I have posted few months ago TC358764 driver[1] which also uses LPM for
> initialization, have you look at it.
> 
> [1]:
> http://lists.freedesktop.org/archives/dri-devel/2014-February/053713.html
> 
> Regards
> Andrzej
> 
>>
>> Signed-off-by: Inki Dae 
>> Acked-by: Kyungmin Park 
>> ---
>>  drivers/gpu/drm/drm_mipi_dsi.c |3 +++
>>  include/drm/drm_mipi_dsi.h |4 
>>  2 files changed, 7 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
>> index e633df2..6b2bbda 100644
>> --- a/drivers/gpu/drm/drm_mipi_dsi.c
>> +++ b/drivers/gpu/drm/drm_mipi_dsi.c
>> @@ -232,6 +232,9 @@ int mipi_dsi_dcs_write(struct mipi_dsi_device *dsi, 
>> unsigned int channel,
>>  break;
>>  }
>>  
>> +if (dsi->mode_flags & MIPI_DSI_MODE_CMD_LPM)
>> +msg.flags = MIPI_DSI_MSG_USE_LPM;
>> +
>>  return ops->transfer(dsi->host, );
>>  }
>>  EXPORT_SYMBOL(mipi_dsi_dcs_write);
>> diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
>> index 944f33f..1c41e49 100644
>> --- a/include/drm/drm_mipi_dsi.h
>> +++ b/include/drm/drm_mipi_dsi.h
>> @@ -94,6 +94,10 @@ void mipi_dsi_host_unregister(struct mipi_dsi_host *host);
>>  #define MIPI_DSI_MODE_VSYNC_FLUSH   BIT(8)
>>  /* disable EoT packets in HS mode */
>>  #define MIPI_DSI_MODE_EOT_PACKETBIT(9)
>> +/* command low power mode */
>> +#define MIPI_DSI_MODE_CMD_LPM   BIT(10)
>> +/* video low power mode */
>> +#define MIPI_DSI_MODE_VIDEO_LPM BIT(11)
>>  
>>  enum mipi_dsi_pixel_format {
>>  MIPI_DSI_FMT_RGB888,
> 
> 

[Bug 81644] Random crashes on RadeonSI with Chromium.

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

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

--- Comment #6 from Aaron B  ---
Created attachment 103455
  --> https://bugs.freedesktop.org/attachment.cgi?id=103455=edit
Xorg crash, no recover.

-- 
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/20140725/732e1b77/attachment.html>

[ANNOUNCE] libdrm 2.4.55

[Maarten Lankhorst]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Damien Lespiau (2):
  intel: Sync the command parser version parameter from kernel
  intel: Sync typo fix from the kernel sources.

Daniel Kurtz (8):
  eyxnos: install exynos tests if HAVE_INSTALL_TESTS
  exynos: fix two warnings
  exynos_fimg2d: fix cast from pointer to integer of different size
  exynos: remove unusable "run" target
  exynos_fimg2d_test: fix drmModeRmFB
  exynos: prime: use drmPrime*() helpers
  exynos: removed unused fd field
  drmOpenByName: remove redundant drmAvailable check

Maarten Lankhorst (2):
  exynos: do not build fimg2d_test when building without libkms support.
  bump to version 2.4.55 for release

Matt Roper (1):
  drm: Add universal plane capability bit and plane type enums

Rob Clark (2):
  freedreno: sync kernel header
  freedreno: add chip-id property

Thomas Klausner (2):
  radeon: Remove superfluous parentheses.
  radeon: Add missing header includes.

Tobias Jakobi (3):
  exynos: fix coordinate computation in g2d_copy
  exynos: fix G2D_DOUBLE_TO_FIXED for non-integer input
  exynos: fix scaling factor computation in g2d_copy_with_scale

Tvrtko Ursulin (1):
  intel: Add new userptr ioctl

git tag: libdrm-2.4.55

http://dri.freedesktop.org/libdrm/libdrm-2.4.55.tar.bz2
MD5:  cf2d77b0324479b428fcc98e92eea87e  libdrm-2.4.55.tar.bz2
SHA1: fcff4f407456f719b51b98343567269bba75a71e  libdrm-2.4.55.tar.bz2
SHA256: 5caf273766147ec57c7acfb9d468ed59baf767828e51517abc161057ca70c643  
libdrm-2.4.55.tar.bz2
PGP:  http://dri.freedesktop.org/libdrm/libdrm-2.4.55.tar.bz2.sig

http://dri.freedesktop.org/libdrm/libdrm-2.4.55.tar.gz
MD5:  fdaa07c2a0c6ab724080c411cadafe30  libdrm-2.4.55.tar.gz
SHA1: a1edc42ce2115fa2f2ecea4bd0fe42056920f1a4  libdrm-2.4.55.tar.gz
SHA256: 27d919cb9efb6e52e26f45d1da25e5466b6cdac4aa1043d776d6799095c1517e  
libdrm-2.4.55.tar.gz
PGP:  http://dri.freedesktop.org/libdrm/libdrm-2.4.55.tar.gz.sig

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJT0loYAAoJEP5VjHKmcBPD1z0P/RiQPBbvpx20+cXXe5DBm6Fl
mlAvHuJz5VyOMQhka4jy+9EYYDUrY8TbEUSXdULBnbImtF9OPKBo9QQCCkkH54uy
0vvOFeKa+9HB8Ku3YHQEuuN6/3erxMDpAku4Y9lzyqSZ76sqqa4R5kpKMbpwcWuG
0zWc4YDKpQjajDWyHnu+FAPKtxiDEuoCmX5EtXkgFL6GUHcsnX7VTQ5j2b32XbLt
TU7hXo7Vk7kobaDdfJGHFYo/93pFDctREk8h3ViT81xhrOSKM8RghQhP/oUcn6Ez
5KkjmUu6vGMO7KEHZDTBnmCOS2rXQlIo0bkKDcNvrCDpp7Cf6hM8h/SaHJQyXFEh
mdI4kYcvQAIj+FVG8QNqW9/SPSr/EFbkG5KqLoVaqZgwdjl8dSOCMrf2X64FKr+e
O4fdXruYKSti0AGRWGapUluV51M4sT7s+3QH9DZLkiS39+17MmyHkCwR1qZBISHV
NfHLu6NxtPRdI1hrFIyF9Ej8W1rOy4lUCvoq3M97VKf9NCB/T7ii5AoONYM70flO
Lq2IZ2lS9uwx3WPQ0oolzEFzFnDAeUuXVKO/4X2U1ws9kzZqf62idphrVEGj3jgQ
C7dCzaO529zayCmdPOcBk9PxpNSdOFN0/m/5wgQ4Tqn4P8PWk3UoIv0Hyb4hsqVc
zpJV+aLDqCpSSWnQyDGt
=gc8c
-END PGP SIGNATURE-

[Bug 78453] [HAWAII] Get acceleration working

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

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

--- Comment #83 from Kai  ---
After I killed X the following three lines appeared in dmesg's output:
> [ 1421.048407] konsole[1509]: segfault at e0 ip 7fa9e928a1dd sp 
> 7fff046f5160 error 4 in libkdeui.so.5.13.3[7fa9e8f1e000+445000]
> [ 1431.576124] radeon :01:00.0: ring 0 stalled for more than 1msec
> [ 1431.576130] radeon :01:00.0: GPU lockup (waiting for 
> 0x01eb last fence id 0x01de on ring 0)

-- 
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/20140725/415bc473/attachment.html>

[Bug 78453] [HAWAII] Get acceleration working

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

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

--- Comment #82 from Kai  ---
Created attachment 103450
  --> https://bugs.freedesktop.org/attachment.cgi?id=103450=edit
Xorg.0.log showing "EQ overflowing"

(In reply to comment #81)
> it's now working more or less.  grab the latest ucode here
> http://people.freedesktop.org/~agd5f/radeon_ucode/ucode.tar.gz and use my
> http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.17-wip kernel
> tree, plus this patch for ddx:
> http://people.freedesktop.org/~agd5f/0001-radeon-enable-hawaii-accel-
> conditionally.patch

I followed these instructions and everything seems to work, until KDM wants to
draw the desktop for the first time, then I see the following:
> (EE) [mi] EQ overflowing.  Additional events will be discarded until existing 
> events are processed.
> (EE) 
>(EE) Backtrace:
> [...]
> (EE) 
> (EE) [mi] These backtraces from mieqEnqueue may point to a culprit higher up 
> the stack.
> (EE) [mi] mieq is *NOT* the cause.  It is a victim.
> (EE) [mi] EQ overflow continuing.  100 events have been dropped.

The backtrace and "EQ overflow continuing" part repeats two times more. See the
attached Xorg.0.log for the backtraces.

The stack I used was (base is Debian Testing):
GPU: Hawaii PRO [Radeon R9 290] (ChipID = 0x67b1)
Linux: ~agdf5/linux:drm-next-3.17-wip (calls itself 3.16-rc4?)
libdrm: 2.4.54-1
LLVM: 3.5 RC1
libclc: Git:master/0ec7437d9c
Mesa: Git:master/bf1247936a
DDX: 1:7.4.0-2 + Patch
X: 2:1.16.0-1 (1.16.0)

Firmeware was put into /lib/firmware/updates/$(uname -r)/radeon (which
translates to /lib/firmware/updates/3.16.0-rc4-citadel/radeon).

Do I need to do something else? Disable tiling? DPM? Is this a remaining issue?
Or did I misunderstand, something and it is expected not to get KDE up and
running?

-- 
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/20140725/6a27b95f/attachment.html>

[PATCH] imx-drm: imx-drm-core: add suspend/resume support

[Shawn Guo]

On Thu, Jul 24, 2014 at 11:56:32AM +0200, Marc Kleine-Budde wrote:
> >> @@ -696,6 +696,44 @@ static int imx_drm_platform_remove(struct 
> >> platform_device *pdev)
> >>return 0;
> >>  }
> >>  
> >> +#if CONFIG_PM_SLEEP
> > 
> > use #ifdef
> 
> ...or remove #if/#ifdef and mark as __maybe_unused

I personally do not like the idea of __maybe_unused.  Will there be a
compile error if I call some helper functions which are only available
with CONFIG_PM_SLEEP?

Shawn

[PATCH] imx-drm: imx-drm-core: add suspend/resume support

[Shawn Guo]

On Thu, Jul 24, 2014 at 11:38:52AM +0200, Philipp Zabel wrote:
> Hi Shawn,
> 
> Am Donnerstag, den 24.07.2014, 17:17 +0800 schrieb Shawn Guo:
> > HDMI currently stops working after a system suspend/resume cycle.  It
> > turns out that the cause is the imx-hdmi encoder .dpms hook doesn't get
> > called from anywhere across suspend/resume cycle.
> > 
> > The patch follows what exynos drm driver does to walk the list of
> > connectors and call their .dpms function from suspend/resume hook.  And
> > the connectors' .dpms function will in turn filter down to the .dpms
> > hooks of encoders and CRTCs.
> > 
> > With this change, HDMI can continue working after a suspend/resume
> > cycle.
> > 
> > Signed-off-by: Shawn Guo 
> > ---
> > Tested with HDMI and LVDS.  It'd be great if someone can help test TVE
> > to ensure the patch doesn't break anything.
> 
> Tested-by: Philipp Zabel 
> 
> on i.MX53-QSB with VGA via TVE.

Thanks much, Philipp.

Shawn

[PATCH v2] imx-drm: imx-drm-core: add suspend/resume support

[Shawn Guo]

HDMI currently stops working after a system suspend/resume cycle.  The
cause is that the mode setting states in hardware gets lost and isn't
restored across the suspend/resume cycle.

The patch adds a very basic suspend/resume support to imx-drm driver,
and calls drm_helper_resume_force_mode() in .resume hook to restore the
mode setting states, so that HDMI can continue working after a system
suspend/resume cycle.

Signed-off-by: Shawn Guo 
---
Changs since v1:
 - Do not walk through connector->funcs->dpms() but only call
   drm_helper_resume_force_mode() in .resume.

 drivers/staging/imx-drm/imx-drm-core.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/drivers/staging/imx-drm/imx-drm-core.c 
b/drivers/staging/imx-drm/imx-drm-core.c
index def8280d7ee6..ab41152089a3 100644
--- a/drivers/staging/imx-drm/imx-drm-core.c
+++ b/drivers/staging/imx-drm/imx-drm-core.c
@@ -696,6 +696,29 @@ static int imx_drm_platform_remove(struct platform_device 
*pdev)
return 0;
 }

+#ifdef CONFIG_PM_SLEEP
+static int imx_drm_suspend(struct device *dev)
+{
+   struct drm_device *drm_dev = dev_get_drvdata(dev);
+
+   drm_kms_helper_poll_disable(drm_dev);
+
+   return 0;
+}
+
+static int imx_drm_resume(struct device *dev)
+{
+   struct drm_device *drm_dev = dev_get_drvdata(dev);
+
+   drm_helper_resume_force_mode(drm_dev);
+   drm_kms_helper_poll_enable(drm_dev);
+
+   return 0;
+}
+#endif
+
+static SIMPLE_DEV_PM_OPS(imx_drm_pm_ops, imx_drm_suspend, imx_drm_resume);
+
 static const struct of_device_id imx_drm_dt_ids[] = {
{ .compatible = "fsl,imx-display-subsystem", },
{ /* sentinel */ },
@@ -708,6 +731,7 @@ static struct platform_driver imx_drm_pdrv = {
.driver = {
.owner  = THIS_MODULE,
.name   = "imx-drm",
+   .pm = _drm_pm_ops,
.of_match_table = imx_drm_dt_ids,
},
 };
-- 
1.9.1

drm/i915: CONFIG_DRM_I915_UMS

[Paul Bolle]

Daniel,

Your commit 2225a28fd916 ("drm/i915: Ditch UMS config option") is
included in today's linux-next (ie, next-20140725). It removes the
Kconfig symbol DRM_I915_UMS.

It didn't remove the two (negative) checks for CONFIG_DRM_I915_UMS.
These checks are superfluous as they now will always evaluate to true.
Is the trivial cleanup to remove them already queued somewhere?


Paul Bolle

[PATCH] imx-drm: imx-drm-core: add suspend/resume support

[Shawn Guo]

On Thu, Jul 24, 2014 at 11:47:55AM +0200, Lucas Stach wrote:
> > +static int imx_drm_resume(struct device *dev)
> > +{
> > +   struct drm_device *drm_dev = dev_get_drvdata(dev);
> > +   struct drm_connector *connector;
> > +
> > +   drm_modeset_lock_all(drm_dev);
> > +   list_for_each_entry(connector, _dev->mode_config.connector_list, 
> > head) {
> > +   if (connector->funcs->dpms)
> > +   connector->funcs->dpms(connector, DRM_MODE_DPMS_ON);
> > +   }
> > +   drm_modeset_unlock_all(drm_dev);
> > +
> This forcefully enables all connectors, which might not have been the
> state before suspend. Have a look at simply using
> drm_helper_resume_force_mode(), which should do the right thing.

With a bit more testing, I found that simply calling
drm_helper_resume_force_mode() from .resume hook can get HDMI back to
work.  So it seems the issue is not caused by that hdmi .dpms function
isn't being called but some mode setting states gets lost and isn't
being restored.

It can fix the HDMI issue we're facing right now, and I will send V2
with this change.  But it doesn't address Russell's concern, the HDMI
hardware isn't actually put into low power mode since hdmi .dpms
function isn't called anywhere during suspend/resume cycle.

Shawn

[PATCH 0/8] tilcdc-panel: Backlight and GPIO devicetree support

[Ezequiel Garcia]

On 24 Jul 04:25 PM, Darren Etheridge wrote:
> On 07/11/2014 09:18 AM, Ezequiel Garcia wrote:
> >Hello all,
> >
> >This patchset adds the required changes to support an optional backlight
> >and GPIO for the tilcdc panel driver.
> >
> >There was some code to support a backlight, but it was somewhat broken
> >and undocumented. I've followed the nice implementation in panel-simple
> >and added a similar one here.
> >
> >The enable GPIO is required to turn on and off devices with such capability.
> >Also here, I've followed panel-simple which looks correct.
> >
> >In addition to this there are very minor cosmetic cleanups and a larger
> >error path fix in tilcdc's DRM driver .load error path.
> >
> >This patchset applies on top of drm-next branch which contains the latest
> >tilcdc pushed by Guido.
> >
> >If at all possible, I'd like to get this merged for v3.17. If a pull request
> >is needed, don't hesitate to ask and I'll prepare one.
> >
> >Comments and tests welcome!
> >
> 
> All of the changes seem to make sense and I tested on AM335x-EVM both with
> and without the addition "backlight = " in the dts for the panel node.
> 
> I see no issues in either case, continued to work as before.
> 
> Tested against 3.16-rc6 with this patchset and the earlier patchset from
> Guido applied.
> 
> Also tested on BeagleBone Black even though it doesn't have a panel, just to
> make sure nothing changed there.
> 
> For the series:
> Tested-by: Darren Etheridge 
> 

Thanks a lot for the test!
-- 
Ezequiel Garcia, VanguardiaSur
www.vanguardiasur.com.ar

[PATCH 2/2] drm/radeon: add new info ioctl query for hawaii accel

[Christian König]

Am 25.07.2014 um 05:05 schrieb Alex Deucher:
> On Thu, Jul 24, 2014 at 10:24 PM, Michel D?nzer  wrote:
>> On 25.07.2014 11:06, Michel D?nzer wrote:
>>> On 25.07.2014 11:05, Michel D?nzer wrote:
 On 25.07.2014 08:51, Alex Deucher wrote:
> We need to make sure we have a new enough firmware with
> the fixed nop packet.
>
> Signed-off-by: Alex Deucher 
> ---
>   drivers/gpu/drm/radeon/radeon_kms.c | 6 ++
>   include/uapi/drm/radeon_drm.h   | 1 +
>   2 files changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_kms.c 
> b/drivers/gpu/drm/radeon/radeon_kms.c
> index 35d9318..3ea9f59 100644
> --- a/drivers/gpu/drm/radeon/radeon_kms.c
> +++ b/drivers/gpu/drm/radeon/radeon_kms.c
> @@ -529,6 +529,12 @@ static int radeon_info_ioctl(struct drm_device *dev, 
> void *data, struct drm_file
>  else
>  *value = 1;
>  break;
> +   case RADEON_INFO_HAWAII_ACCEL:
> +   if (rdev->new_fw)
> +   *value = 1;
> +   else
> +   *value = 0;
> +   break;
>  default:
>  DRM_DEBUG_KMS("Invalid request %d\n", info->request);
>  return -EINVAL;
> diff --git a/include/uapi/drm/radeon_drm.h b/include/uapi/drm/radeon_drm.h
> index 509b2d7..a41dec3 100644
> --- a/include/uapi/drm/radeon_drm.h
> +++ b/include/uapi/drm/radeon_drm.h
> @@ -1010,6 +1010,7 @@ struct drm_radeon_cs {
>   #define RADEON_INFO_VRAM_USAGE 0x1e
>   #define RADEON_INFO_GTT_USAGE  0x1f
>   #define RADEON_INFO_ACTIVE_CU_COUNT0x20
> +#define RADEON_INFO_HAWAII_ACCEL   0x21
>
>   struct drm_radeon_info {
>  uint32_trequest;
>
 Please make the RADEON_INFO_ACCEL_WORKING(2) ioctl do the right thing
 for Hawaii instead of adding yet another one.
>>> Ugh, s/ioctl/info query/ of course.
>> Hmm, I guess that doesn't work because older kernels returned 1 for
>> those on Hawaii...
> Right.  The hawaii problems came down to two things:
>
> 1. missing tiling info setup (fixed with Jerome's patch:
> http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-3.17-wip=78e758aa27d9d430c61999160ddf72e829c5cf26)
> for hawaii.  This was due to merging hawaii support after we fixed up
> CI tiling.  Dave already merged this and it should show up in stable.
>
> 2. The current Hawaii CP firmware doesn't support the special case
> 0x1000 type 3 NOP packet.  The newer firmware version I added
> support for in 3.17 supports this packet.
>
> So we can either patch mesa to use the type 2 packets for now and
> allow it to work with kernels with older firmware.  The problem is the
> compute rings don't support type 2 packets anymore and they are
> deprecated on gfx, plus we'd still have to deal with existing versions
> of mesa that still use the problematic packet.
>
> It just seemed easier to add a new kernel check.

Can we still make the check a bit more generic? E.g. not so HAWAII 
specific name and maybe returning more information from the new firmware 
header?

Something like this,
Christian.

>
> Alex
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] drm/radeon: add new info ioctl query for hawaii accel

[Michel Dänzer]

On 25.07.2014 11:06, Michel D?nzer wrote:
> On 25.07.2014 11:05, Michel D?nzer wrote:
>> On 25.07.2014 08:51, Alex Deucher wrote:
>>> We need to make sure we have a new enough firmware with
>>> the fixed nop packet.
>>>
>>> Signed-off-by: Alex Deucher 
>>> ---
>>>  drivers/gpu/drm/radeon/radeon_kms.c | 6 ++
>>>  include/uapi/drm/radeon_drm.h   | 1 +
>>>  2 files changed, 7 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/radeon/radeon_kms.c 
>>> b/drivers/gpu/drm/radeon/radeon_kms.c
>>> index 35d9318..3ea9f59 100644
>>> --- a/drivers/gpu/drm/radeon/radeon_kms.c
>>> +++ b/drivers/gpu/drm/radeon/radeon_kms.c
>>> @@ -529,6 +529,12 @@ static int radeon_info_ioctl(struct drm_device *dev, 
>>> void *data, struct drm_file
>>> else
>>> *value = 1;
>>> break;
>>> +   case RADEON_INFO_HAWAII_ACCEL:
>>> +   if (rdev->new_fw)
>>> +   *value = 1;
>>> +   else
>>> +   *value = 0;
>>> +   break;
>>> default:
>>> DRM_DEBUG_KMS("Invalid request %d\n", info->request);
>>> return -EINVAL;
>>> diff --git a/include/uapi/drm/radeon_drm.h b/include/uapi/drm/radeon_drm.h
>>> index 509b2d7..a41dec3 100644
>>> --- a/include/uapi/drm/radeon_drm.h
>>> +++ b/include/uapi/drm/radeon_drm.h
>>> @@ -1010,6 +1010,7 @@ struct drm_radeon_cs {
>>>  #define RADEON_INFO_VRAM_USAGE 0x1e
>>>  #define RADEON_INFO_GTT_USAGE  0x1f
>>>  #define RADEON_INFO_ACTIVE_CU_COUNT0x20
>>> +#define RADEON_INFO_HAWAII_ACCEL   0x21
>>>  
>>>  struct drm_radeon_info {
>>> uint32_trequest;
>>>
>>
>> Please make the RADEON_INFO_ACCEL_WORKING(2) ioctl do the right thing
>> for Hawaii instead of adding yet another one.
> 
> Ugh, s/ioctl/info query/ of course.

Hmm, I guess that doesn't work because older kernels returned 1 for
those on Hawaii...


-- 
Earthling Michel D?nzer|  http://www.amd.com
Libre software enthusiast  |Mesa and X developer

[PATCH 2/2] drm/radeon: add new info ioctl query for hawaii accel

[Michel Dänzer]

On 25.07.2014 11:05, Michel D?nzer wrote:
> On 25.07.2014 08:51, Alex Deucher wrote:
>> We need to make sure we have a new enough firmware with
>> the fixed nop packet.
>>
>> Signed-off-by: Alex Deucher 
>> ---
>>  drivers/gpu/drm/radeon/radeon_kms.c | 6 ++
>>  include/uapi/drm/radeon_drm.h   | 1 +
>>  2 files changed, 7 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/radeon/radeon_kms.c 
>> b/drivers/gpu/drm/radeon/radeon_kms.c
>> index 35d9318..3ea9f59 100644
>> --- a/drivers/gpu/drm/radeon/radeon_kms.c
>> +++ b/drivers/gpu/drm/radeon/radeon_kms.c
>> @@ -529,6 +529,12 @@ static int radeon_info_ioctl(struct drm_device *dev, 
>> void *data, struct drm_file
>>  else
>>  *value = 1;
>>  break;
>> +case RADEON_INFO_HAWAII_ACCEL:
>> +if (rdev->new_fw)
>> +*value = 1;
>> +else
>> +*value = 0;
>> +break;
>>  default:
>>  DRM_DEBUG_KMS("Invalid request %d\n", info->request);
>>  return -EINVAL;
>> diff --git a/include/uapi/drm/radeon_drm.h b/include/uapi/drm/radeon_drm.h
>> index 509b2d7..a41dec3 100644
>> --- a/include/uapi/drm/radeon_drm.h
>> +++ b/include/uapi/drm/radeon_drm.h
>> @@ -1010,6 +1010,7 @@ struct drm_radeon_cs {
>>  #define RADEON_INFO_VRAM_USAGE  0x1e
>>  #define RADEON_INFO_GTT_USAGE   0x1f
>>  #define RADEON_INFO_ACTIVE_CU_COUNT 0x20
>> +#define RADEON_INFO_HAWAII_ACCEL0x21
>>  
>>  struct drm_radeon_info {
>>  uint32_trequest;
>>
> 
> Please make the RADEON_INFO_ACCEL_WORKING(2) ioctl do the right thing
> for Hawaii instead of adding yet another one.

Ugh, s/ioctl/info query/ of course.


-- 
Earthling Michel D?nzer|  http://www.amd.com
Libre software enthusiast  |Mesa and X developer

[PATCH 2/2] drm/radeon: add new info ioctl query for hawaii accel

[Michel Dänzer]

On 25.07.2014 08:51, Alex Deucher wrote:
> We need to make sure we have a new enough firmware with
> the fixed nop packet.
> 
> Signed-off-by: Alex Deucher 
> ---
>  drivers/gpu/drm/radeon/radeon_kms.c | 6 ++
>  include/uapi/drm/radeon_drm.h   | 1 +
>  2 files changed, 7 insertions(+)
> 
> diff --git a/drivers/gpu/drm/radeon/radeon_kms.c 
> b/drivers/gpu/drm/radeon/radeon_kms.c
> index 35d9318..3ea9f59 100644
> --- a/drivers/gpu/drm/radeon/radeon_kms.c
> +++ b/drivers/gpu/drm/radeon/radeon_kms.c
> @@ -529,6 +529,12 @@ static int radeon_info_ioctl(struct drm_device *dev, 
> void *data, struct drm_file
>   else
>   *value = 1;
>   break;
> + case RADEON_INFO_HAWAII_ACCEL:
> + if (rdev->new_fw)
> + *value = 1;
> + else
> + *value = 0;
> + break;
>   default:
>   DRM_DEBUG_KMS("Invalid request %d\n", info->request);
>   return -EINVAL;
> diff --git a/include/uapi/drm/radeon_drm.h b/include/uapi/drm/radeon_drm.h
> index 509b2d7..a41dec3 100644
> --- a/include/uapi/drm/radeon_drm.h
> +++ b/include/uapi/drm/radeon_drm.h
> @@ -1010,6 +1010,7 @@ struct drm_radeon_cs {
>  #define RADEON_INFO_VRAM_USAGE   0x1e
>  #define RADEON_INFO_GTT_USAGE0x1f
>  #define RADEON_INFO_ACTIVE_CU_COUNT  0x20
> +#define RADEON_INFO_HAWAII_ACCEL 0x21
>  
>  struct drm_radeon_info {
>   uint32_trequest;
> 

Please make the RADEON_INFO_ACCEL_WORKING(2) ioctl do the right thing
for Hawaii instead of adding yet another one.


-- 
Earthling Michel D?nzer|  http://www.amd.com
Libre software enthusiast  |Mesa and X developer

[PATCH] gpio: extend gpiod_get*() with flags parameter

[Alexandre Courbot]

On Fri, Jul 25, 2014 at 1:23 AM, Laurent Pinchart
 wrote:
>> diff --git a/Documentation/gpio/consumer.txt
>> b/Documentation/gpio/consumer.txt index 7ff30d2..a3fb1d7 100644
>> --- a/Documentation/gpio/consumer.txt
>> +++ b/Documentation/gpio/consumer.txt
>> @@ -29,13 +29,24 @@ gpiod_get() functions. Like many other kernel
>> subsystems, gpiod_get() takes the device that will use the GPIO and the
>> function the requested GPIO is supposed to fulfill:
>>
>> - struct gpio_desc *gpiod_get(struct device *dev, const char *con_id)
>> + struct gpio_desc *gpiod_get(struct device *dev, const char *con_id,
>> + enum gpio_flags flags)
>
> I assume you mean enum gpiod_flags here and in the rest of the documentation.

Indeed, thanks for pointing it out.

>
>>  If a function is implemented by using several GPIOs together (e.g. a simple
>> LED device that displays digits), an additional index argument can be
>> specified:
>>
>>   struct gpio_desc *gpiod_get_index(struct device *dev,
>> -   const char *con_id, unsigned int idx)
>> +   const char *con_id, unsigned int idx,
>> +   enum gpio_flags flags)
>> +
>> +The flags parameter is used to optionally specify a direction and initial
>> value +for the GPIO. Values can be:
>> +
>> +* AS_IS or 0 to not initialize the GPIO at all. The direction must be set
>> later
>> +  with one of the dedicated functions.
>> +* INPUT to initialize the GPIO as input.
>> +* OUTPUT_LOW to initialize the GPIO as output with a value of 0.
>> +* OUTPUT_HIGH to initialize the GPIO as output with a value of 1.
>
> Pretty please, could you at least prefix that with GPIOD_ ? Those names are
> too generic.
>
> How about renaming them to GPIOD_AS_IS, GPIOD_IN, GPIOD_OUT_INIT_LOW and
> GPIOD_OUT_INIT_HIGH in order to match the GPIOF_ flags ?

Yeah, you're right, the possibility of name collision is quite high here.

Thanks,
Alex.

[PATCH] gpio: extend gpiod_get*() with flags parameter

[Alexandre Courbot]

On Fri, Jul 25, 2014 at 1:10 AM, Arnd Bergmann  wrote:
> On Friday 25 July 2014 00:04:58 Alexandre Courbot wrote:
>> I'm not sure how this could be applied harmlessly though - maybe through
>> a dedicated branch for -next? Problem is that a lot of new code is not
>> yet merged into mainline, and conflicts are very likely to occur. Linus,
>> do you have any suggestion as to how this can be done without blood being
>> spilled?
>
> There is a trick that we sometime use in this situation,
> though it has to be done carefully:
>
>> diff --git a/Documentation/gpio/consumer.txt 
>> b/Documentation/gpio/consumer.txt
>> index 7ff30d2..a3fb1d7 100644
>> --- a/Documentation/gpio/consumer.txt
>> +++ b/Documentation/gpio/consumer.txt
>> @@ -29,13 +29,24 @@ gpiod_get() functions. Like many other kernel 
>> subsystems, gpiod_get() takes the
>>  device that will use the GPIO and the function the requested GPIO is 
>> supposed to
>>  fulfill:
>>
>> -   struct gpio_desc *gpiod_get(struct device *dev, const char *con_id)
>> +   struct gpio_desc *gpiod_get(struct device *dev, const char *con_id,
>> +   enum gpio_flags flags)
>>
>>
>
>
> -   struct gpio_desc *gpiod_get(struct device *dev, const char *con_id)
> +   struct gpio_desc *__gpiod_get(struct device *dev, const char *con_id,
> +   enum gpio_flags flags);
> +
> +#define __gpiod_get(dev, con_id, flags, ...) __gpiod_get(dev, con_id, flags)
> +#define gpiod_get(varargs ...) __gpiod_get(varargs, 0)
>
> This will allow both variants to be called, and any users of the 
> three-argument
> version will pass zero as the fourth argument (or whatever you choose there).
>
> Once the conversion is complete, the macros can be removed.

Wow, that works great, thanks! Indeed, this will allow me to send more
localized patches and to not spam half of the kernel developers. Sorry
about the noise.

Let's close this thread, I will submit the gpiolib update with this
trick first, then update each user before eventually removing the
macros.

Thanks,
Alex.

[PATCH] imx-drm: imx-drm-core: add suspend/resume support

[Daniel Vetter]

On Thu, Jul 24, 2014 at 10:59:36PM +0800, Shawn Guo wrote:
> On Thu, Jul 24, 2014 at 12:38:59PM +0200, Daniel Vetter wrote:
> > > > > +static int imx_drm_suspend(struct device *dev)
> > > > > +{
> > > > > + struct drm_device *drm_dev = dev_get_drvdata(dev);
> > > > > + struct drm_connector *connector;
> > > > > +
> > > > > + drm_kms_helper_poll_disable(drm_dev);
> > > > > +
> > > > 
> > > > That's ok.
> > > > 
> > > > > + drm_modeset_lock_all(drm_dev);
> > > > > + list_for_each_entry(connector, 
> > > > > _dev->mode_config.connector_list, head) {
> > > > > + if (connector->funcs->dpms)
> > > > > + connector->funcs->dpms(connector, 
> > > > > DRM_MODE_DPMS_OFF);
> > > > > + }
> > > > 
> > > > Don't touch DPMS state here. See below.
> > > 
> > > In which case, how else does the hardware get placed into a low power
> > > mode on suspend?
> > > 
> > > DRM has nothing provided, and this is left up to each DRM driver to
> > > implement (probably because it tends to be very driver specific.)
> > > i915 for example calls the CRTC DPMS function with DRM_MODE_DPMS_OFF.
> > > 
> > > This provides a similar mechanism, but also informs the connector, any
> > > bridge, and encoder associated with the connector as well as the CRTC
> > > to place themselves into a low power mode (which is what
> > > DRM_MODE_DPMS_OFF should be doing anyway.)
> > 
> > Well you need to call internal functions to make sure you can restore the
> > state again. Not sure any more how that all works with the crtc helpers
> > and whether they restore dpms state properly at all. i915 uses something
> > completely different nowadays.
> 
> Is it okay to do what exynos driver does, i.e. saving/restoring the dpms
> state before/after calling connector .dpms function?
> 
> list_for_each_entry(connector, _dev->mode_config.connector_list, 
> head) {
> int old_dpms = connector->dpms;
> 
> if (connector->funcs->dpms)
> connector->funcs->dpms(connector, DRM_MODE_DPMS_OFF);
> 
> /* Set the old mode back to the connector for resume */
> connector->dpms = old_dpms;
> }

I'm not sure whether that will get you correct behavior since iirc the
crtc helpers aren't terribly good at restoring the right dpms state.
drm_helper_resume_force_mode simple does a modeset, and that has an
implicit dpms on when enabling the crtc. Someone might want to tackle
this, but thus far it doesn't seem to have been too annoying. I think the
best way would be to do this as part of atomic modeset, where we can
supply the desired dpms state directly.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH 0/7] prepare for atomic.. the great propertyification

[Daniel Vetter]

On Thu, Jul 24, 2014 at 10:56:07AM -0400, Rob Clark wrote:
[snip]

> ok, it's entirely possibly that I'm missunderstanding a bit your proposal..

Yeah I get that feeling a bit too. I'll cut out the technical details for
now and will try to concentrate on one example. Maybe that clarifies.


[snip]

> >> > So here's my proposal for how to get this in without breaking the world
> >> >
> >> > 1. We add a complete new set of ->atomic_foo driver entry points to all
> >> > relevant objects. So instead of changing all the set_prop functions in a
> >> > flag-day like operation we just add a new interface. I haven't double
> >> > checked, but I guess that means per-obj ->atomic_set_prop functions plus 
> >> > a
> >> > global ->atomic_check and ->atomic_commit.
> >>
> >> that sounds much worse
> >
> > Why that? Afaics your patch only changes the interfaces but leaves the
> > semantics the same (i915 does set_config_internal all over the place in
> > set_prop). So essentially you have both interface, but merged into one.
> > And especially for the set_prop the semantics our different.
> 
> well, it was the doubling up of code paths in core for handling legacy
> and atomic side-by-side that I was trying to avoid
> 
> I do remember seeing i915 set_config_internal (looks like it has been
> refactored into intel_set_mode())..  iirc, it was all on
> connector->set_prop(), so it would essentially be it's own
> atomic/transaction.

So currently our set_prop functions work like that:
1. We parse the property, sanity check it and store it in the relevant
object structure.
2. We check whether (after all the checking and parsing) there has been an
actual change in configuration. E.g. for the audio stuff if the use sets
back to "auto" we check whether the old config matches the new autoconfig
state or not. So it's not just "has the prop value changed", we actually
diff the resulting hw config.
3. If there is a change, we update the hw state with a call to mode_set
iff the pipe is on.

There's a few reasons why this works and why it looks like that.
- Our internal mode set code currently doesn't notice changes in property
  values. We plan to fix this eventually by shuffling the compute_config
  code around, but that's a lot of work.
- Our internal mode set function _always_ forces a full modeset on the
  crtc you pass it (besides doing modeset on other crtcs where tracked
  state has changed). We need to have this hack to make the above set_prop
  sequence work.

Now with atomic we want completely different semantics:
- Set_prop only updates state. We need to drop the state computation and
  diffing and the forced mode_set.
- The eventual commit will force a mode_set. Note that calling
  ->set_config will not be enough since that doesn't have the "force full
  mode-set" hack which the internal version has. And we can't do this
  since userspace uses set_crtc/->set_config to update frontbuffers which
  absolutely must not result in a full modeset.

So looking just at the ->set_prop function we have 2 completely different
semantics. Now I agree that with your patch i915 keeps on working. But the
problem I have is converting i915 over to the new world. Since you've
removed the old entry point I am left with no other choice than to convert
everything at once. And there's a lot more than just the hdmi audio
property - page_flip has slightly different semantics with atomic,
update_plane dito, set-crtc the same.

Which means I either have to convert i915 in one go (impossible given the
usual churn I face) or I just end up implementing the infrastructure I've
asked for (which means I get to reinstante all the old legacy ioctl
paths). Since with the doubled-up entry points I can e.g. just convert
hdmi set_prop to atomic, which means I have a minimal use-case to validate
the core infrastructure in i915 (i.e. the state diffing we need to improve
in the mode_set code) and can ignore all the nonsense in the tv connectors
and sdvo encoders and plane props and crtcs props and hacked-up other crap
we have all around. It's still going to be a major pain, but I expect the
transition to be much more smoothly.

My experience with the universal plane stuff really is that even slight
semantic differences in the interfaces bite you hard and there's no way to
work around that. The only sane way really is to have parallel entry
points with helpers so that transitioned drivers can remap legacy
interfaces to the more powerful new ones.

I hope this explains a bit better where I see the big risk with your
approach and what exactly I'm proposing.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH 2/2] drm/radeon: add new info ioctl query for hawaii accel

[Jerome Glisse]

On Fri, Jul 25, 2014 at 11:30:55AM +0200, Christian K?nig wrote:
> Am 25.07.2014 um 05:05 schrieb Alex Deucher:
> >On Thu, Jul 24, 2014 at 10:24 PM, Michel D?nzer  
> >wrote:
> >>On 25.07.2014 11:06, Michel D?nzer wrote:
> >>>On 25.07.2014 11:05, Michel D?nzer wrote:
> On 25.07.2014 08:51, Alex Deucher wrote:
> >We need to make sure we have a new enough firmware with
> >the fixed nop packet.
> >
> >Signed-off-by: Alex Deucher 
> >---
> >  drivers/gpu/drm/radeon/radeon_kms.c | 6 ++
> >  include/uapi/drm/radeon_drm.h   | 1 +
> >  2 files changed, 7 insertions(+)
> >
> >diff --git a/drivers/gpu/drm/radeon/radeon_kms.c 
> >b/drivers/gpu/drm/radeon/radeon_kms.c
> >index 35d9318..3ea9f59 100644
> >--- a/drivers/gpu/drm/radeon/radeon_kms.c
> >+++ b/drivers/gpu/drm/radeon/radeon_kms.c
> >@@ -529,6 +529,12 @@ static int radeon_info_ioctl(struct drm_device 
> >*dev, void *data, struct drm_file
> > else
> > *value = 1;
> > break;
> >+   case RADEON_INFO_HAWAII_ACCEL:
> >+   if (rdev->new_fw)
> >+   *value = 1;
> >+   else
> >+   *value = 0;
> >+   break;
> > default:
> > DRM_DEBUG_KMS("Invalid request %d\n", info->request);
> > return -EINVAL;
> >diff --git a/include/uapi/drm/radeon_drm.h 
> >b/include/uapi/drm/radeon_drm.h
> >index 509b2d7..a41dec3 100644
> >--- a/include/uapi/drm/radeon_drm.h
> >+++ b/include/uapi/drm/radeon_drm.h
> >@@ -1010,6 +1010,7 @@ struct drm_radeon_cs {
> >  #define RADEON_INFO_VRAM_USAGE 0x1e
> >  #define RADEON_INFO_GTT_USAGE  0x1f
> >  #define RADEON_INFO_ACTIVE_CU_COUNT0x20
> >+#define RADEON_INFO_HAWAII_ACCEL   0x21
> >
> >  struct drm_radeon_info {
> > uint32_trequest;
> >
> Please make the RADEON_INFO_ACCEL_WORKING(2) ioctl do the right thing
> for Hawaii instead of adding yet another one.
> >>>Ugh, s/ioctl/info query/ of course.
> >>Hmm, I guess that doesn't work because older kernels returned 1 for
> >>those on Hawaii...
> >Right.  The hawaii problems came down to two things:
> >
> >1. missing tiling info setup (fixed with Jerome's patch:
> >http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-3.17-wip=78e758aa27d9d430c61999160ddf72e829c5cf26)
> >for hawaii.  This was due to merging hawaii support after we fixed up
> >CI tiling.  Dave already merged this and it should show up in stable.
> >
> >2. The current Hawaii CP firmware doesn't support the special case
> >0x1000 type 3 NOP packet.  The newer firmware version I added
> >support for in 3.17 supports this packet.
> >
> >So we can either patch mesa to use the type 2 packets for now and
> >allow it to work with kernels with older firmware.  The problem is the
> >compute rings don't support type 2 packets anymore and they are
> >deprecated on gfx, plus we'd still have to deal with existing versions
> >of mesa that still use the problematic packet.
> >
> >It just seemed easier to add a new kernel check.
> 
> Can we still make the check a bit more generic? E.g. not so HAWAII specific
> name and maybe returning more information from the new firmware header?
> 
> Something like this,
> Christian.

I would rather not add anything, let just dump drm version in 3.17 and use
that to enable compute and in mean time disable compute for hawaii but enable
gfx if we detect 3.16. This would be a lot cleaner and no need for yet another
get_info ie we make 3.17 only report accel if new firmware is detected.

Cheers,
J?r?me

[PATCH 07/12] drm: drop redundant drm_file->is_master

[Daniel Vetter]

On Thu, Jul 24, 2014 at 11:38:28PM +0200, David Herrmann wrote:
> On Thu, Jul 24, 2014 at 11:52 AM, Daniel Vetter  wrote:
> > On Wed, Jul 23, 2014 at 05:26:42PM +0200, David Herrmann wrote:
> >> +static inline bool drm_is_master(const struct drm_file *file)
> >> +{
> >
> > Hm, we don't have any means to synchronize is_master checks with
> > concurrent ioctls and stuff. Do we care? Orthogonal issue really.
> 
> We don't.. My drm-master reworks contains a comment about that. It's
> not really problematic as all ioctls run for a determinate time in
> kernel-code except for drm_read(), but drm_read() is per-file, not
> per-device, so we're fine. However, with unfortunate timings, we might
> really end up with problems.
> 
> vmwgfx solves this by using separate locks and verifying them against
> the current master. it's not perfect and I'm not sure I like it better
> than no locks, but at least they were aware of the problem.
> 
> Btw., the only thing I know how to solve it properly is to make
> "master_mutex" an rwlock and all f_op entries take the read-lock,
> while master modifications take the write-lock. Not sure it's worth
> it, though.

Imo that's terrible. And I'm not even sure we need to care, e.g. if we do
a master switch to a different compositor any ioctl the new compositor
does will grab some locks, which will force the old ioctl to complete.

Well mostly, and only if we don't do lockless tricks or lock-dropping and
it's racy.

I guess a proper fix would be to wait for all ioctls on a device to
complete. The vfs doesn't have any cool infrastructure for this as part of
the general revoke work that we could reuse?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH] imx-drm: imx-drm-core: Convert to drm_is_master()

[David Herrmann]

Hi

On Fri, Jul 25, 2014 at 5:08 AM, Fabio Estevam  wrote:
> From: Fabio Estevam 
>
> Since commit fe32c9f34b9e ("drm: drop redundant drm_file->is_master")
> we should use drm_is_master, otherwise the following build error is seen:
>
> drivers/staging/imx-drm/imx-drm-core.c: In function 'imx_drm_driver_preclose':
> drivers/staging/imx-drm/imx-drm-core.c:185:11: error: 'struct drm_file' has 
> no member named 'is_master'
>
> Reported-by: kbuild test robot 
> Signed-off-by: Fabio Estevam 

Sorry, I totally missed staging. I amended the imx changes now.

Thanks
David

> ---
> This one should go via David Herrmann's tree.
>
>  drivers/staging/imx-drm/imx-drm-core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/imx-drm/imx-drm-core.c 
> b/drivers/staging/imx-drm/imx-drm-core.c
> index 6b22106..7974854 100644
> --- a/drivers/staging/imx-drm/imx-drm-core.c
> +++ b/drivers/staging/imx-drm/imx-drm-core.c
> @@ -182,7 +182,7 @@ static void imx_drm_driver_preclose(struct drm_device 
> *drm,
>  {
> int i;
>
> -   if (!file->is_master)
> +   if (!drm_is_master(file))
> return;
>
> for (i = 0; i < MAX_CRTC; i++)
> --
> 1.8.3.2
>

[PATCH 0/7] prepare for atomic.. the great propertyification

[Rob Clark]

On Fri, Jul 25, 2014 at 4:15 AM, Daniel Vetter  wrote:
> On Thu, Jul 24, 2014 at 10:56:07AM -0400, Rob Clark wrote:
> [snip]
>
>> ok, it's entirely possibly that I'm missunderstanding a bit your proposal..
>
> Yeah I get that feeling a bit too. I'll cut out the technical details for
> now and will try to concentrate on one example. Maybe that clarifies.
>
>
> [snip]
>
>> >> > So here's my proposal for how to get this in without breaking the world
>> >> >
>> >> > 1. We add a complete new set of ->atomic_foo driver entry points to all
>> >> > relevant objects. So instead of changing all the set_prop functions in a
>> >> > flag-day like operation we just add a new interface. I haven't double
>> >> > checked, but I guess that means per-obj ->atomic_set_prop functions 
>> >> > plus a
>> >> > global ->atomic_check and ->atomic_commit.
>> >>
>> >> that sounds much worse
>> >
>> > Why that? Afaics your patch only changes the interfaces but leaves the
>> > semantics the same (i915 does set_config_internal all over the place in
>> > set_prop). So essentially you have both interface, but merged into one.
>> > And especially for the set_prop the semantics our different.
>>
>> well, it was the doubling up of code paths in core for handling legacy
>> and atomic side-by-side that I was trying to avoid
>>
>> I do remember seeing i915 set_config_internal (looks like it has been
>> refactored into intel_set_mode())..  iirc, it was all on
>> connector->set_prop(), so it would essentially be it's own
>> atomic/transaction.
>
> So currently our set_prop functions work like that:
> 1. We parse the property, sanity check it and store it in the relevant
> object structure.
> 2. We check whether (after all the checking and parsing) there has been an
> actual change in configuration. E.g. for the audio stuff if the use sets
> back to "auto" we check whether the old config matches the new autoconfig
> state or not. So it's not just "has the prop value changed", we actually
> diff the resulting hw config.
> 3. If there is a change, we update the hw state with a call to mode_set
> iff the pipe is on.
>
> There's a few reasons why this works and why it looks like that.
> - Our internal mode set code currently doesn't notice changes in property
>   values. We plan to fix this eventually by shuffling the compute_config
>   code around, but that's a lot of work.
> - Our internal mode set function _always_ forces a full modeset on the
>   crtc you pass it (besides doing modeset on other crtcs where tracked
>   state has changed). We need to have this hack to make the above set_prop
>   sequence work.
>
> Now with atomic we want completely different semantics:
> - Set_prop only updates state. We need to drop the state computation and
>   diffing and the forced mode_set.

So probably the first thing, is that we need to bring connectors into
the atomic game..  probably that is something that i915 should take
the lead on, since you actually have a bunch of connector properties
which, from the sounds of it, should play by atomic rules.  I don't
have anything as complicated in msm, and wasn't entirely sure what
would be needed for connectors, so I punted on that part.

That said, crtc_state->set_config, etc, flags should be what you need
to know if you need a full modeset or not.  You just need your
connector's set_prop to grab the appropriate crtc_state and set the
appropriate flag(s).  So I'm not sure that I see any fundamental
problem here[*].

[*] well, combining connector changes w/ connector property changes
perhaps..  you may actually need your ->atomic_check() step to
propagate the "I need a modeset" flag from connector to crtc.. but
otoh a connector change is a full modeset, so maybe not.

> - The eventual commit will force a mode_set. Note that calling
>   ->set_config will not be enough since that doesn't have the "force full
>   mode-set" hack which the internal version has. And we can't do this
>   since userspace uses set_crtc/->set_config to update frontbuffers which
>   absolutely must not result in a full modeset.
>
> So looking just at the ->set_prop function we have 2 completely different
> semantics. Now I agree that with your patch i915 keeps on working. But the
> problem I have is converting i915 over to the new world. Since you've
> removed the old entry point I am left with no other choice than to convert
> everything at once. And there's a lot more than just the hdmi audio
> property - page_flip has slightly different semantics with atomic,
> update_plane dito, set-crtc the same.
>
> Which means I either have to convert i915 in one go (impossible given the
> usual churn I face) or I just end up implementing the infrastructure I've
> asked for (which means I get to reinstante all the old legacy ioctl
> paths). Since with the doubled-up entry points I can e.g. just convert
> hdmi set_prop to atomic, which means I have a minimal use-case to validate
> the core infrastructure in i915 (i.e. the state diffing we need to 

[PATCH] gpio: extend gpiod_get*() with flags parameter

[Lee Jones]

On Thu, 24 Jul 2014, Greg Kroah-Hartman wrote:

> On Fri, Jul 25, 2014 at 12:04:58AM +0900, Alexandre Courbot wrote:
> > The huge majority of GPIOs have their direction and initial value set
> > right after being obtained by one of the gpiod_get() functions. The
> > integer GPIO API had gpio_request_one() that took a convenience flags
> > parameter allowing to specify an direction and value applied to the
> > returned GPIO. This feature greatly simplifies client code and ensures
> > errors are always handled properly.
> > 
> > A similar feature has been requested for the gpiod API. Since GPIOs need
> > a direction to be used anyway, we prefer to extend the existing
> > functions instead of introducing new functions that would raise the
> > number of gpiod getters to 16 (!).
> > 
> > The drawback of this approach is that all gpiod clients need to be
> > updated, but there aren't that many and the moment and this results in
> > smaller (and hopefully safer) code.
> > 
> > Signed-off-by: Alexandre Courbot 
> > ---
> > This change will be difficult to apply without breaking things, but
> > let's try to do it right. Hopefully the benefit will outweight the
> > disturbance.
> > 
> > This is a patch against -next to list and update all current gpiod
> > consumers. Updates are trivial at first sight, but it would be nice to
> > get as many acks as possible from the respective subsystem maintainers.
> > 
> > I'm not sure how this could be applied harmlessly though - maybe through
> > a dedicated branch for -next? Problem is that a lot of new code is not
> > yet merged into mainline, and conflicts are very likely to occur. Linus,
> > do you have any suggestion as to how this can be done without blood being
> > spilled?
> 
> Do this in 3 steps, not all at once.
> 
> Make a new function that takes the new argument, get that merged
> 
> Submit patches that convert drivers over to use the new function.
> 
> Once all of those are merged, remove the old function.
> 
> That way there are no "flag days" needed, and everyone is happy you
> don't send out emails with 40+ people in the To: and Cc: lines :)

+9

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[PATCH] drm: Fix race when checking for fb in the generic kms obj lookup

[Rob Clark]

On Thu, Jul 24, 2014 at 6:12 AM, Daniel Vetter  
wrote:
> In my review of
>
> commit 98f75de40e9d83c3a90d294b8fd25fa2874212a9
> Author: Rob Clark 
> Date:   Fri May 30 11:37:03 2014 -0400
>
> drm: add object property typ
>
> I asked for a check to make sure that we never leak an fb from the
> generic mode object lookup since those have completely different
> lifetime rules. Rob added it, but outside of the idr mutex, which
> means that our dereference of obj->type can already chase free'd
> memory.
>
> Somehow I didn't spot this, so fix this asap.
>
> v2: Simplify the conditionals as suggested by Chris.
>
> Cc: Rob Clark 
> Cc: Chris Wilson 
> Signed-off-by: Daniel Vetter 

Reviewed-by: Rob Clark 

> ---
>  drivers/gpu/drm/drm_crtc.c | 11 ++-
>  1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index f0a47907..d87df8836aa5 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -426,8 +426,12 @@ static struct drm_mode_object *_object_find(struct 
> drm_device *dev,
>
> mutex_lock(>mode_config.idr_mutex);
> obj = idr_find(>mode_config.crtc_idr, id);
> -   if (!obj || (type != DRM_MODE_OBJECT_ANY && obj->type != type) ||
> -   (obj->id != id))
> +   if (obj && type != DRM_MODE_OBJECT_ANY && obj->type != type)
> +   obj = NULL;
> +   if (obj && obj->id != id)
> +   obj = NULL;
> +   /* don't leak out unref'd fb's */
> +   if (obj && (obj->type == DRM_MODE_OBJECT_FB))
> obj = NULL;
> mutex_unlock(>mode_config.idr_mutex);
>
> @@ -454,9 +458,6 @@ struct drm_mode_object *drm_mode_object_find(struct 
> drm_device *dev,
>  * function.*/
> WARN_ON(type == DRM_MODE_OBJECT_FB);
> obj = _object_find(dev, id, type);
> -   /* don't leak out unref'd fb's */
> -   if (obj && (obj->type == DRM_MODE_OBJECT_FB))
> -   obj = NULL;
> return obj;
>  }
>  EXPORT_SYMBOL(drm_mode_object_find);
> --
> 2.0.1
>

[Bug 75649] Glitchy output using only HDMI on laptop with AMD Mobility Radeon HD 3450/3470

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

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

--- Comment #7 from tderensis at gmail.com ---
I can confirm that only switching modes to 1920x1080 causes the issue. The
latest I have tested is Arch 3.15.5, Cinnamon desktop, Mesa 10.2.4, and
xf86-video-ati 1:7.4.0. Maybe this is an xrandr issue?

-- 
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/20140725/51a35e37/attachment.html>

[Bug 81644] Random crashes on RadeonSI with Chromium.

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

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

--- Comment #5 from Aaron B  ---
Created attachment 103417
  --> https://bugs.freedesktop.org/attachment.cgi?id=103417=edit
Hardware report.

Important hardware:

R9 270X - 2GB GDDR5 - ASUS.
FX-8350 - AMD.
M5A99FX PRO 2.0 - ASUS.

-- 
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/20140725/cd8aaf18/attachment.html>

[Bug 81644] Random crashes on RadeonSI with Chromium.

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

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

--- Comment #4 from Aaron B  ---
Created attachment 103416
  --> https://bugs.freedesktop.org/attachment.cgi?id=103416=edit
XOrg log, with crash+recover.

-- 
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/20140725/e2b64684/attachment.html>

[Bug 81644] Random crashes on RadeonSI with Chromium.

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

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

--- Comment #3 from Aaron B  ---
Created attachment 103415
  --> https://bugs.freedesktop.org/attachment.cgi?id=103415=edit
GLXInfo

-- 
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/20140725/2e69e470/attachment.html>

[Bug 81644] Random crashes on RadeonSI with Chromium.

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

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

--- Comment #2 from Aaron B  ---
Created attachment 103414
  --> https://bugs.freedesktop.org/attachment.cgi?id=103414=edit
DMesg

I have moved to Arch. Bug just happened and is in these logs. I'm currently on
Mesa-git. And the bug not being present isn't solid. My friend told me it
didn't happen, and has the same tower. But he didn't stay on it long enough to
happen so I'm going to take that back for now. I don't remember this bug in
Mesa from around January, but yet my card was unusable in January. So I'd ping
it to somewhere around 2-5 months old tbh. But yes, Chromium has this problem
on arch, and I switched not only OS's but DE's so it's not a Cinnamon problem.

-- 
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/20140725/299be71d/attachment-0001.html>

[git pull] drm fixes (make Linus grumpy)

[Dave Airlie]

Hi Linus,

This is radeon and intel fixes, and is a small bit larger than I'm 
guessing you'd like it to be,

i915: fixes 32-bit highmem i915 blank screen, semaphore hang and runtime 
pm fix
radeon: gpuvm stability fix for hangs since 3.15, and hang/reboot 
regression on TN/RL devices,

The only slightly controversial one is the change to use GB forthe 
vm_size, which I'm letting through as its a new interface we defined in
this merge window, and I'd prefer to have the released kernel have the 
final interface rather than changing it later.

but push back if you really don't like anything!

Dave.

The following changes since commit 67dd8f35c2d8ed80f26c9654b474cffc11c6674d:

  Merge branch 'v4l_for_linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media (2014-07-21 
11:44:34 -0700)

are available in the git repository at:


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

for you to fetch changes up to 1b2c4869d8247f9e202fa8a73777c34adc62d409:

  drm/radeon: fix cut and paste issue for hawaii. (2014-07-25 09:17:35 +1000)


Alex Deucher (1):
  drm/radeon/TN: only enable bapm on MSI systems

Chris Wilson (2):
  drm/i915: Reorder the semaphore deadlock check, again
  drm/i915: Simplify i915_gem_release_all_mmaps()

Christian K?nig (5):
  drm/radeon: let's use GB for vm_size (v2)
  drm/radeon: fix handling of radeon_vm_bo_rmv v3
  drm/radeon: fix VM IB handling
  drm/radeon: fix error handling in radeon_vm_bo_set_addr
  drm/radeon: fix irq ring buffer overflow handling

Dave Airlie (3):
  Merge branch 'drm-fixes-3.16' of 
git://people.freedesktop.org/~agd5f/linux into drm-fixes
  Merge tag 'drm-intel-fixes-2014-07-24' of 
git://anongit.freedesktop.org/drm-intel into drm-fixes
  Merge branch 'drm-fixes-3.16' of 
git://people.freedesktop.org/~agd5f/linux into drm-fixes

Hugh Dickins (1):
  drm/i915: fix freeze with blank screen booting highmem

Jerome Glisse (1):
  drm/radeon: fix cut and paste issue for hawaii.

 drivers/gpu/drm/i915/i915_gem.c  | 25 +++-
 drivers/gpu/drm/i915/i915_gem_render_state.c |  4 +-
 drivers/gpu/drm/i915/i915_irq.c  | 11 ++--
 drivers/gpu/drm/radeon/cik.c |  2 +
 drivers/gpu/drm/radeon/evergreen.c   |  1 +
 drivers/gpu/drm/radeon/r600.c|  1 +
 drivers/gpu/drm/radeon/radeon.h  | 15 +++--
 drivers/gpu/drm/radeon/radeon_cs.c   | 20 ++-
 drivers/gpu/drm/radeon/radeon_device.c   | 22 +++
 drivers/gpu/drm/radeon/radeon_drv.c  |  4 +-
 drivers/gpu/drm/radeon/radeon_kms.c  | 26 -
 drivers/gpu/drm/radeon/radeon_vm.c   | 87 
 drivers/gpu/drm/radeon/si.c  |  1 +
 drivers/gpu/drm/radeon/trinity_dpm.c | 15 ++---
 14 files changed, 146 insertions(+), 88 deletions(-)

[Bug 81680] [r600g] Firefox crashes with hardware acceleration turned on

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

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

--- Comment #3 from Eugene  ---
(In reply to comment #2)
> Can you resolve the r600_dri.so symbols?

If you'll explain me how to.

-- 
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/20140725/0dbab815/attachment.html>

[PATCH] imx-drm: imx-drm-core: Convert to drm_is_master()

[Fabio Estevam]

From: Fabio Estevam 

Since commit fe32c9f34b9e ("drm: drop redundant drm_file->is_master")
we should use drm_is_master, otherwise the following build error is seen:

drivers/staging/imx-drm/imx-drm-core.c: In function 'imx_drm_driver_preclose':
drivers/staging/imx-drm/imx-drm-core.c:185:11: error: 'struct drm_file' has no 
member named 'is_master'

Reported-by: kbuild test robot  
Signed-off-by: Fabio Estevam 
---
This one should go via David Herrmann's tree.

 drivers/staging/imx-drm/imx-drm-core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/imx-drm/imx-drm-core.c 
b/drivers/staging/imx-drm/imx-drm-core.c
index 6b22106..7974854 100644
--- a/drivers/staging/imx-drm/imx-drm-core.c
+++ b/drivers/staging/imx-drm/imx-drm-core.c
@@ -182,7 +182,7 @@ static void imx_drm_driver_preclose(struct drm_device *drm,
 {
int i;

-   if (!file->is_master)
+   if (!drm_is_master(file))
return;

for (i = 0; i < MAX_CRTC; i++)
-- 
1.8.3.2

[PATCH] gpio: extend gpiod_get*() with flags parameter

[Alexandre Courbot]

The huge majority of GPIOs have their direction and initial value set
right after being obtained by one of the gpiod_get() functions. The
integer GPIO API had gpio_request_one() that took a convenience flags
parameter allowing to specify an direction and value applied to the
returned GPIO. This feature greatly simplifies client code and ensures
errors are always handled properly.

A similar feature has been requested for the gpiod API. Since GPIOs need
a direction to be used anyway, we prefer to extend the existing
functions instead of introducing new functions that would raise the
number of gpiod getters to 16 (!).

The drawback of this approach is that all gpiod clients need to be
updated, but there aren't that many and the moment and this results in
smaller (and hopefully safer) code.

Signed-off-by: Alexandre Courbot 
---
This change will be difficult to apply without breaking things, but
let's try to do it right. Hopefully the benefit will outweight the
disturbance.

This is a patch against -next to list and update all current gpiod
consumers. Updates are trivial at first sight, but it would be nice to
get as many acks as possible from the respective subsystem maintainers.

I'm not sure how this could be applied harmlessly though - maybe through
a dedicated branch for -next? Problem is that a lot of new code is not
yet merged into mainline, and conflicts are very likely to occur. Linus,
do you have any suggestion as to how this can be done without blood being
spilled?

 Documentation/gpio/consumer.txt| 26 ---
 drivers/gpio/devres.c  | 24 ++
 drivers/gpio/gpiolib.c | 53 --
 drivers/gpu/drm/panel/panel-ld9040.c   |  7 +--
 drivers/gpu/drm/panel/panel-s6e8aa0.c  |  7 +--
 drivers/gpu/drm/panel/panel-simple.c   | 16 ++-
 drivers/hsi/clients/nokia-modem.c  |  7 +--
 drivers/i2c/muxes/i2c-mux-pca954x.c|  4 +-
 drivers/iio/accel/kxcjk-1013.c |  6 +--
 drivers/input/keyboard/clps711x-keypad.c   |  6 +--
 drivers/input/misc/gpio-beeper.c   |  6 +--
 drivers/input/misc/soc_button_array.c  |  2 +-
 drivers/media/i2c/adv7604.c|  6 +--
 drivers/mfd/intel_soc_pmic_core.c  |  2 +-
 drivers/mmc/core/slot-gpio.c   |  6 +--
 drivers/net/phy/at803x.c   |  4 +-
 drivers/power/reset/gpio-poweroff.c| 21 ++---
 drivers/tty/serial/serial_mctrl_gpio.c |  2 +-
 drivers/video/backlight/pwm_bl.c   |  6 +--
 drivers/video/fbdev/omap2/displays-new/panel-dpi.c | 12 ++---
 .../omap2/displays-new/panel-lgphilips-lb035q02.c  |  6 +--
 .../omap2/displays-new/panel-sharp-ls037v7dw01.c   |  7 +--
 include/linux/gpio/consumer.h  | 38 
 net/rfkill/rfkill-gpio.c   | 16 ++-
 sound/soc/codecs/adau1977.c| 11 ++---
 sound/soc/codecs/cs4265.c  |  5 +-
 sound/soc/codecs/sta350.c  |  9 ++--
 sound/soc/codecs/tas2552.c |  4 +-
 sound/soc/jz4740/qi_lb60.c | 10 +---
 sound/soc/omap/rx51.c  | 29 +++-
 sound/soc/soc-jack.c   |  9 ++--
 31 files changed, 160 insertions(+), 207 deletions(-)

diff --git a/Documentation/gpio/consumer.txt b/Documentation/gpio/consumer.txt
index 7ff30d2..a3fb1d7 100644
--- a/Documentation/gpio/consumer.txt
+++ b/Documentation/gpio/consumer.txt
@@ -29,13 +29,24 @@ gpiod_get() functions. Like many other kernel subsystems, 
gpiod_get() takes the
 device that will use the GPIO and the function the requested GPIO is supposed 
to
 fulfill:

-   struct gpio_desc *gpiod_get(struct device *dev, const char *con_id)
+   struct gpio_desc *gpiod_get(struct device *dev, const char *con_id,
+   enum gpio_flags flags)

 If a function is implemented by using several GPIOs together (e.g. a simple LED
 device that displays digits), an additional index argument can be specified:

struct gpio_desc *gpiod_get_index(struct device *dev,
- const char *con_id, unsigned int idx)
+ const char *con_id, unsigned int idx,
+ enum gpio_flags flags)
+
+The flags parameter is used to optionally specify a direction and initial value
+for the GPIO. Values can be:
+
+* AS_IS or 0 to not initialize the GPIO at all. The direction must be set later
+  with one of the dedicated functions.
+* INPUT to initialize the GPIO as input.
+* OUTPUT_LOW to initialize the GPIO as output with a value of 0.
+* OUTPUT_HIGH to initialize the GPIO as output with a value of 1.

 Both functions return either a 

[Bug 78453] [HAWAII] Get acceleration working

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

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

--- Comment #81 from Alex Deucher  ---
it's now working more or less.  grab the latest ucode here
http://people.freedesktop.org/~agd5f/radeon_ucode/ucode.tar.gz and use my
http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.17-wip kernel tree,
plus this patch for ddx:
http://people.freedesktop.org/~agd5f/0001-radeon-enable-hawaii-accel-conditionally.patch

-- 
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/20140725/ee35011f/attachment.html>

[PATCH 07/12] drm: drop redundant drm_file->is_master

[David Herrmann]

Hi

On Thu, Jul 24, 2014 at 11:52 AM, Daniel Vetter  wrote:
> On Wed, Jul 23, 2014 at 05:26:42PM +0200, David Herrmann wrote:
>> The drm_file->is_master field is redundant as it's equivalent to:
>> drm_file->master && drm_file->master == drm_file->minor->master
>>
>> 1) "=>"
>>   Whenever we set drm_file->is_master, we also set:
>>   drm_file->minor->master = drm_file->master;
>>
>>   Whenever we clear drm_file->is_master, we also call:
>>   drm_master_put(_file->minor->master);
>>   which implicitly clears it to NULL.
>>
>> 2) "<="
>>   minor->master cannot be set if it is non-NULL. Therefore, it stays as
>>   is unless a file drops it.
>>
>>   If minor->master is NULL, it is only set by places that also adjust
>>   drm_file->is_master.
>>
>> Therefore, we can safely drop is_master and replace it by an inline helper
>> that matches:
>> drm_file->master && drm_file->master == drm_file->minor->master
>>
>> Signed-off-by: David Herrmann 
>
> Docbook for drm_is_master is missing, otherwise Reviewed-by: Daniel Vetter 
> 
>
> And one question below which doesn't really matter for this patch here.
> See below

Fixed, thanks!

> [snip]
>
>> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
>> index d91e09f..e1bb585 100644
>> --- a/include/drm/drmP.h
>> +++ b/include/drm/drmP.h
>> @@ -387,8 +387,6 @@ struct drm_prime_file_private {
>>  struct drm_file {
>>   unsigned always_authenticated :1;
>>   unsigned authenticated :1;
>> - /* Whether we're master for a minor. Protected by master_mutex */
>> - unsigned is_master :1;
>>   /* true when the client has asked us to expose stereo 3D mode flags */
>>   unsigned stereo_allowed :1;
>>   /*
>> @@ -1034,7 +1032,7 @@ struct drm_device {
>>   /** \name Locks */
>>   /*@{ */
>>   struct mutex struct_mutex;  /**< For others */
>> - struct mutex master_mutex;  /**< For drm_minor::master and 
>> drm_file::is_master */
>> + struct mutex master_mutex;  /**< For drm_minor::master */
>>   /*@} */
>>
>>   /** \name Usage Counters */
>> @@ -1172,6 +1170,11 @@ static inline bool drm_is_primary_client(const struct 
>> drm_file *file_priv)
>>   return file_priv->minor->type == DRM_MINOR_LEGACY;
>>  }
>>
>
> Docbook here please ...
>> +static inline bool drm_is_master(const struct drm_file *file)
>> +{
>
> Hm, we don't have any means to synchronize is_master checks with
> concurrent ioctls and stuff. Do we care? Orthogonal issue really.

We don't.. My drm-master reworks contains a comment about that. It's
not really problematic as all ioctls run for a determinate time in
kernel-code except for drm_read(), but drm_read() is per-file, not
per-device, so we're fine. However, with unfortunate timings, we might
really end up with problems.

vmwgfx solves this by using separate locks and verifying them against
the current master. it's not perfect and I'm not sure I like it better
than no locks, but at least they were aware of the problem.

Btw., the only thing I know how to solve it properly is to make
"master_mutex" an rwlock and all f_op entries take the read-lock,
while master modifications take the write-lock. Not sure it's worth
it, though.

Thanks
David

>> + return file->master && file->master == file->minor->master;
>> +}
>> +
>>  /**/
>>  /** \name Internal function definitions */
>>  /*@{*/
>> --
>> 2.0.2
>>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH 2/2] drm/radeon: add new info ioctl query for hawaii accel

[Alex Deucher]

On Thu, Jul 24, 2014 at 10:24 PM, Michel D?nzer  wrote:
> On 25.07.2014 11:06, Michel D?nzer wrote:
>> On 25.07.2014 11:05, Michel D?nzer wrote:
>>> On 25.07.2014 08:51, Alex Deucher wrote:
 We need to make sure we have a new enough firmware with
 the fixed nop packet.

 Signed-off-by: Alex Deucher 
 ---
  drivers/gpu/drm/radeon/radeon_kms.c | 6 ++
  include/uapi/drm/radeon_drm.h   | 1 +
  2 files changed, 7 insertions(+)

 diff --git a/drivers/gpu/drm/radeon/radeon_kms.c 
 b/drivers/gpu/drm/radeon/radeon_kms.c
 index 35d9318..3ea9f59 100644
 --- a/drivers/gpu/drm/radeon/radeon_kms.c
 +++ b/drivers/gpu/drm/radeon/radeon_kms.c
 @@ -529,6 +529,12 @@ static int radeon_info_ioctl(struct drm_device *dev, 
 void *data, struct drm_file
 else
 *value = 1;
 break;
 +   case RADEON_INFO_HAWAII_ACCEL:
 +   if (rdev->new_fw)
 +   *value = 1;
 +   else
 +   *value = 0;
 +   break;
 default:
 DRM_DEBUG_KMS("Invalid request %d\n", info->request);
 return -EINVAL;
 diff --git a/include/uapi/drm/radeon_drm.h b/include/uapi/drm/radeon_drm.h
 index 509b2d7..a41dec3 100644
 --- a/include/uapi/drm/radeon_drm.h
 +++ b/include/uapi/drm/radeon_drm.h
 @@ -1010,6 +1010,7 @@ struct drm_radeon_cs {
  #define RADEON_INFO_VRAM_USAGE 0x1e
  #define RADEON_INFO_GTT_USAGE  0x1f
  #define RADEON_INFO_ACTIVE_CU_COUNT0x20
 +#define RADEON_INFO_HAWAII_ACCEL   0x21

  struct drm_radeon_info {
 uint32_trequest;

>>>
>>> Please make the RADEON_INFO_ACCEL_WORKING(2) ioctl do the right thing
>>> for Hawaii instead of adding yet another one.
>>
>> Ugh, s/ioctl/info query/ of course.
>
> Hmm, I guess that doesn't work because older kernels returned 1 for
> those on Hawaii...

Right.  The hawaii problems came down to two things:

1. missing tiling info setup (fixed with Jerome's patch:
http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-3.17-wip=78e758aa27d9d430c61999160ddf72e829c5cf26)
for hawaii.  This was due to merging hawaii support after we fixed up
CI tiling.  Dave already merged this and it should show up in stable.

2. The current Hawaii CP firmware doesn't support the special case
0x1000 type 3 NOP packet.  The newer firmware version I added
support for in 3.17 supports this packet.

So we can either patch mesa to use the type 2 packets for now and
allow it to work with kernels with older firmware.  The problem is the
compute rings don't support type 2 packets anymore and they are
deprecated on gfx, plus we'd still have to deal with existing versions
of mesa that still use the problematic packet.

It just seemed easier to add a new kernel check.

Alex