date:20130419

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

Ben Widawsky  changed:

   What|Removed |Added

   Assignee|dri-devel at lists.freedesktop |intel-gfx-bugs at 
lists.freede
   |.org|sktop.org
 QA Contact||intel-gfx-bugs at lists.freede
   ||sktop.org
  Component|General |DRM/Intel

-- 
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/20130419/53b8b24b/attachment.html>

[Bug 63632] mesa +r600 llvm = segfault

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

Andy Furniss  changed:

   What|Removed |Added

Summary|RS880 + mesa/llvm heads -   |mesa +r600 llvm = segfault
   |segfault|

--- Comment #1 from Andy Furniss  ---
I am still getting segfaults with updated mesa/llvm, though the bt is a bit
different.

I can reproduce with a new 64 bit LFS and an old 32 bit one.

Have put RV790 back in this box so it's not just RS880.

Program received signal SIGSEGV, Segmentation fault.
0xb6451433 in r600_llvm_compile (mod=0x80658c0,
inst_bytes=inst_bytes at entry=0xbfffa7d4,
inst_byte_count=inst_byte_count at entry=0xbfffa7d8, family=CHIP_RV770,
ngpr=0x806425c, dump=dump at entry=0) at r600_llvm.c:567
567 *ngpr = util_le32_to_cpu(*(uint32_t*)binary.config);
(gdb) bt
#0  0xb6451433 in r600_llvm_compile (mod=0x80658c0,
inst_bytes=inst_bytes at entry=0xbfffa7d4,
inst_byte_count=inst_byte_count at entry=0xbfffa7d8, family=CHIP_RV770,
ngpr=0x806425c, dump=dump at entry=0) at r600_llvm.c:567
#1  0xb6433f16 in r600_shader_from_tgsi (rscreen=0x8074cf0,
pipeshader=pipeshader at entry=0x8064230, key=...) at r600_shader.c:1464
#2  0xb6435135 in r600_pipe_shader_create (ctx=ctx at entry=0x805b850,
shader=0x8064230, key=...) at r600_shader.c:132
#3  0xb6448f6b in r600_shader_select (ctx=ctx at entry=0x805b850,
sel=sel at entry=0x8094230, dirty=dirty at entry=0x0) at r600_state_common.c:747
#4  0xb6449134 in r600_create_shader_state (ctx=0x805b850, state=, pipe_shader_type=0) at r600_state_common.c:794
#5  0xb633d0a3 in ureg_create_shader (ureg=ureg at entry=0x808f8f0,
pipe=pipe at entry=0x805b850, so=so at entry=0x0) at tgsi/tgsi_ureg.c:1701
#6  0xb636a434 in ureg_create_shader_with_so_and_destroy (so=0x0,
pipe=0x805b850, p=0x808f8f0) at ./tgsi/tgsi_ureg.h:131
#7  util_make_vertex_passthrough_shader_with_so (pipe=pipe at entry=0x805b850,
num_attribs=num_attribs at entry=2,
semantic_names=semantic_names at entry=0xb16c,
semantic_indexes=semantic_indexes at entry=0xb20c, so=so at entry=0x0) at
util/u_simple_shaders.c:98
#8  0xb636a48f in util_make_vertex_passthrough_shader
(pipe=pipe at entry=0x805b850, num_attribs=num_attribs at entry=2,
semantic_names=semantic_names at entry=0xb16c,
semantic_indexes=semantic_indexes at entry=0xb20c) at
util/u_simple_shaders.c:64
#9  0xb634c604 in util_blitter_create (pipe=pipe at entry=0x805b850) at
util/u_blitter.c:301
#10 0xb64248a1 in r600_create_context (screen=0x8074cf0, priv=0x0) at
r600_pipe.c:466
#11 0xb6261a9b in st_api_create_context (stapi=0xb77752c0 ,
smapi=0x80747b0, attribs=0xb474, error=0xb470, shared_stctxi=0x0) at
../../src/mesa/state_tracker/st_manager.c:633
#12 0xb645777c in dri_create_context (api=API_OPENGL_COMPAT, visual=0x80787f8,
cPriv=0x807fc28, major_version=1, minor_version=0, flags=0, error=0xb53c,
sharedContextPrivate=0x0) at dri_context.c:124
#13 0xb611b89d in dri2CreateContextAttribs (screen=screen at entry=0x80746f8,
api=api at entry=0, config=config at entry=0x80787f8, shared=shared at 
entry=0x0,
num_attribs=num_attribs at entry=0, attribs=attribs at entry=0x0,
error=error at entry=0xb53c, data=data at entry=0x807f518)
at ../../../../src/mesa/drivers/dri/common/dri_util.c:288
#14 0xb611ba17 in dri2CreateNewContextForAPI (screen=screen at entry=0x80746f8,
api=api at entry=0, config=config at entry=0x80787f8, shared=shared at 
entry=0x0,
data=data at entry=0x807f518) at
../../../../src/mesa/drivers/dri/common/dri_util.c:306
#15 0xb611ba4f in dri2CreateNewContext (screen=0x80746f8, config=0x80787f8,
shared=0x0, data=0x807f518) at
../../../../src/mesa/drivers/dri/common/dri_util.c:314
#16 0xb7f11209 in dri2_create_context (base=0x805b300, config_base=0x809ed70,
shareList=0x0, renderType=32788) at dri2_glx.c:230
#17 0xb7ee73f9 in CreateContext (dpy=dpy at entry=0x804c050, generic_id=545,
config=0x809ed70, shareList_user=shareList_user at entry=0x0,
allowDirect=allowDirect at entry=1, code=code at entry=3, renderType=32788,
screen=screen at entry=0) at glxcmds.c:274
#18 0xb7ee7c15 in glXCreateContext (dpy=0x804c050, vis=0x805b6b8,
shareList=0x0, allowDirect=1) at glxcmds.c:379
#19 0xb7cb7c6a in __glutCreateWindow (parent=0x0, x=0, y=0, width=300,
height=300, gameMode=0) at glut_win.c:609
#20 0xb7cb7e11 in glutCreateWindow (title=title at entry=0x804a900 "Gears") at
glut_win.c:731
#21 0x0804906f in main (argc=1, argv=0xb7f4) at gears.c:391

-- 
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/20130419/71a6c00c/attachment.html>

UVD status on loongson 3a platform

2013-04-19 Thread Dieter Nützel

Am 2013-04-19 17:34, schrieb Christian K?nig:
> Am 19.04.2013 10:51, schrieb Chen Jie:
> Hi all,
> 
> Recently, the uvd supporting is released, and we've tried it on
> loongson 3a platform.
> Brief introduction about loongson 3a, it's a MIPS III compatible, 4
> cores processor.
> 
> More details about the platform [1]:
> * The Board: RS780E + SB710 chipset, with an AMD radeon HD6570 video 
> card
> * The kernel is 64bits(n64 ABI), and the userland is 32bits(o32 ABI)
> * OS: LOonux 3.3.6 [2] + LTP-uvd-installer-20130419.bin [3]
> ** kernel: 3.9 + uvd related patches
> ** mesa: git master version (d0e9aa)
> 
> We tried three video samples:
> * big_buck_bunny_1080p_h264.mov
> (http://mirrorblender.top-ix.org/peach/bigbuckbunny_movies/big_buck_bunny_1080p_h264.mov)
> * Sintel.2010.2K.x264-VODO.mp4
> (http://dev.lemote.com/files/upload/software/UVD-debug/Sintel.2010.2K.x264-VODO.mp4)
> * test.avi 
> (http://dev.lemote.com/files/upload/software/UVD-debug/test.avi)
> 
> For big_buck_bunny_1080p_h264.mov, the playback is not very fluent at
> the beginning, and it has some video mosaic. We've recorded a video
> for it, see 
> http://dev.lemote.com/files/upload/software/UVD-debug/bbb-1080P.mp4
> For video mosaic, what could it be caused by?
> 
> That looks like a known problem with the semaphores and also happens
> on X86, it gets worse when you have a slower CPU and/or less bandwidth
> cause then UVD needs to block on the DMA to wait till everything is in
> place. I'm going to try to release the workaround for it.

With '...when you have a slower CPU and/or less bandwidth...' you 
naturally mean my Duron 1800/RV730 AGP (!!!) system, am I right? ;-)

Yes, that's the problem I get since the 'shadow' is fixed.
I can get it much faster when I go forward or backward in mplayer.

Do you have anything released?

> For Sintel.2010.2K.x264-VODO.mp4, it has a very long wait for the first 
> frame.
> We've also recorded a video for it, see
> http://dev.lemote.com/files/upload/software/UVD-debug/sintel.2K.mp4
> Any idea about the long wait for the first frame?
> 
> No idea, that also happens on X86, but the wait is actually not as
> long. If I'm not completely wrong it seems to be mplayer who is
> causing this startup delay.

I mostly don't see such delay, here.
But hey, I get this with test.avi, now:

[VD_FFMPEG] Trying pixfmt=0.
Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
VO: [vdpau] 1920x1080 => 1920x1080 H.264 VDPAU acceleration
[VD_FFMPEG] XVMC-accelerated MPEG-2.
radeon: The kernel rejected CS, see dmesg for more information.105 0
radeon: The kernel rejected CS, see dmesg for more information.107 0

[ 8362.657224] [drm:radeon_uvd_cs_msg] *ERROR* Invalid UVD handle!
[ 8362.657236] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !
[ 8362.693846] [drm:radeon_uvd_cs_msg] *ERROR* Invalid UVD handle!
[ 8362.693859] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !
[ 8362.726656] [drm:radeon_uvd_cs_reloc] *ERROR* buffer to small 
(3342336 / 7077888)!
[ 8362.726668] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !
[ 8427.206169] [drm:radeon_uvd_cs_reloc] *ERROR* buffer to small 
(3342336 / 7077888)!
[ 8427.206179] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !
[ 8428.296537] [drm:radeon_uvd_cs_reloc] *ERROR* buffer to small 
(3342336 / 7077888)!
[ 8428.296548] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !

> For test.avi(video: ITU H.264, 1920x1080), it's playing back
> perfectly! Thanks for the effort on UVD!

Perfectly, with such mosaic, after some few seconds?
And your test.avi is not seekable.

A:   7.7 V:   7.7 A-V:  0.002 ct: -0.074 231/231 49% 108%  3.5% 131 0
Cannot seek in raw AVI streams. (Index required, try with the -idx 
switch.)
A:   8.7 V:   8.5 A-V:  0.198 ct: -0.076 254/254 45% 104%  3.3% 132 0
Cannot seek in raw AVI streams. (Index required, try with the -idx 
switch.)
A:   9.6 V:   9.1 A-V:  0.495 ct: -0.063 272/272 42% 107%  3.8% 139 0
Cannot seek in raw AVI streams. (Index required, try with the -idx 
switch.)
A:  10.7 V:  10.6 A-V:  0.076 ct: -0.068 319/319 36% 100%  3.4% 178 0
Cannot seek in raw AVI streams. (Index required, try with the -idx 
switch.)
A:  36.4 V:  36.4 A-V: -0.004 ct: -0.081 1092/1092 12% 32%  1.6% 182 0

Cheers,
Dieter

PS Alex's drm-next-3.10, mesa master, drm-2.4.44 master

[PATCH 3/3] drm/exynos: Add device tree support for fimc ipp driver

Dear Sylwester Nawrocki.

Sorry. I didn't check your third patch. I understand the "mux", "parent" 
meaning. please ignore my comment of "mux", "parent"

and please check below comments.

Thank's
BR
Eunchul Kim.

On 04/17/2013 02:31 AM, Sylwester Nawrocki wrote:
> This patch adds OF initialization support for the FIMC driver.
> The binding documentation can be found at Documentation/devicetree/
> bindings/media/samsung-fimc.txt.
>
> The syscon regmap interface is used to serialize access to the
> shared CAMBLK registers from within the V4L2 FIMC-IS and the DRM
> FIMC drivers. The DRM driver uses this interface for setting up
> the FIFO data link between FIMD and FIMC IP blocks, while the V4L2
> one for setting up a data link between the camera ISP and FIMC for
> camera capture. The CAMBLK registers are not accessed any more
> through a statically mapped IO. Synchronized access to these
> registers is required for simultaneous operation of the camera
> ISP and the DRM IPP on Exynos4x12.
>
> Exynos4 is going to be a dt-only platform since 3.10, thus the
> driver data and driver_ids static data structures are removed.
>
> Camera input signal polarities are not currently parsed from the
> device tree.
>
> Signed-off-by: Sylwester Nawrocki 
> Signed-off-by: Kyungmin Park 
> ---
>   drivers/gpu/drm/exynos/Kconfig   |2 +-
>   drivers/gpu/drm/exynos/exynos_drm_fimc.c |  101 
> +++---
>   drivers/gpu/drm/exynos/regs-fimc.h   |7 +--
>   3 files changed, 53 insertions(+), 57 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
> index 406f32a..5c4be2a 100644
> --- a/drivers/gpu/drm/exynos/Kconfig
> +++ b/drivers/gpu/drm/exynos/Kconfig
> @@ -56,7 +56,7 @@ config DRM_EXYNOS_IPP
>
>   config DRM_EXYNOS_FIMC
>   bool "Exynos DRM FIMC"
> - depends on DRM_EXYNOS_IPP
> + depends on DRM_EXYNOS_IPP && MFD_SYSCON && OF
>   help
> Choose this option if you want to use Exynos FIMC for DRM.
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> index 9bea585..f25801e 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> @@ -12,11 +12,12 @@
>*
>*/
>   #include 
> +#include 
>   #include 
>   #include 
> +#include 
>   #include 
>   #include 
> -#include 
>
>   #include 
>   #include 
> @@ -140,15 +141,6 @@ struct fimc_capability {
>   };
>
>   /*
> - * A structure of fimc driver data.
> - *
> - * @parent_clk: name of parent clock.
> - */
> -struct fimc_driverdata {
> - char*parent_clk;
> -};
> -
> -/*
>* A structure of fimc context.
>*
>* @ippdrv: prepare initialization using ippdrv.
> @@ -158,6 +150,7 @@ struct fimc_driverdata {
>* @lock: locking of operations.
>* @clocks: fimc clocks.
>* @clk_frequency: LCLK clock frequency.
> + * @sysreg: handle to SYSREG block regmap.
>* @sc: scaler infomations.
>* @pol: porarity of writeback.
>* @id: fimc id.
> @@ -172,8 +165,8 @@ struct fimc_context {
>   struct mutexlock;
>   struct clk  *clocks[FIMC_CLKS_MAX];
>   u32 clk_frequency;
> + struct regmap   *sysreg;
>   struct fimc_scaler  sc;
> - struct fimc_driverdata  *ddata;
>   struct exynos_drm_ipp_pol   pol;
>   int id;
>   int irq;
> @@ -217,17 +210,13 @@ static void fimc_sw_reset(struct fimc_context *ctx)
>   fimc_write(0x0, EXYNOS_CIFCNTSEQ);
>   }
>
> -static void fimc_set_camblk_fimd0_wb(struct fimc_context *ctx)
> +static int fimc_set_camblk_fimd0_wb(struct fimc_context *ctx)
>   {
> - u32 camblk_cfg;
> -
>   DRM_DEBUG_KMS("%s\n", __func__);
>
> - camblk_cfg = readl(SYSREG_CAMERA_BLK);
> - camblk_cfg &= ~(SYSREG_FIMD0WB_DEST_MASK);
> - camblk_cfg |= ctx->id << (SYSREG_FIMD0WB_DEST_SHIFT);
> -
> - writel(camblk_cfg, SYSREG_CAMERA_BLK);
> + return regmap_update_bits(ctx->sysreg, SYSREG_CAMERA_BLK,
> +   SYSREG_FIMD0WB_DEST_MASK,
> +   ctx->id << SYSREG_FIMD0WB_DEST_SHIFT);
>   }
>
>   static void fimc_set_type_ctrl(struct fimc_context *ctx, enum fimc_wb wb)
> @@ -1628,7 +1617,9 @@ static int fimc_ippdrv_start(struct device *dev, enum 
> drm_exynos_ipp_cmd cmd)
>   fimc_handle_lastend(ctx, true);
>
>   /* setup FIMD */
> - fimc_set_camblk_fimd0_wb(ctx);
> + ret = fimc_set_camblk_fimd0_wb(ctx);
> + if (ret < 0)

- please adds error log information for indicating error.

> + return ret;
>
>   set_wb.enable = 1;
>   set_wb.refresh = property->refresh_rate;
> @@ -1784,26 +1775,50 @@ e_clk_free:
>   return ret;
>   }
>
> +static int fimc_parse_dt(struct fimc_context *ctx)
> +{
> + struct device_node *node = ctx->dev->of_node;
> +
> + if (!of_property_read_bool(node, "samsung,lcd-wb"))

- It also need error

[PATCH v2 2/3] drm/exynos: Rework fimc clocks handling

Dear Sylwester Nawrocki

Thank you for your update. I have some question of your patch.
please give your information to me.

Thank's
BR
Eunchul Kim.

On 04/17/2013 06:53 PM, Sylwester Nawrocki wrote:
> The clocks handling is refactored and a "mux" clock handling is
> added to account for changes in the clocks driver. After switching
> to the common clock framework the sclk_fimc clock is now split
> into two clocks: a gate and a mux clock. In order to retain the
> exisiting functionality two additional consumer clocks are passed
> to the driver from device tree: "mux" and "parent". Then the driver
> sets "parent" clock as a parent clock of the "mux" clock. These two
> additional clocks are optional, and should go away when there is a
> standard way of setting up parent clocks on DT platforms.
>
> Signed-off-by: Sylwester Nawrocki 
> Signed-off-by: Kyungmin Park 
> ---
>   drivers/gpu/drm/exynos/exynos_drm_fimc.c |  167 
> +-
>   1 file changed, 97 insertions(+), 70 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> index d812c57..bc8411a 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> @@ -76,6 +76,27 @@ enum fimc_wb {
>   FIMC_WB_B,
>   };
>
> +enum {
> + FIMC_CLK_LCLK,
> + FIMC_CLK_GATE,
> + FIMC_CLK_WB_A,
> + FIMC_CLK_WB_B,
> + FIMC_CLK_MUX,
> + FIMC_CLK_PARENT,

- What is MUX, PARENT ?

> + FIMC_CLKS_MAX
> +};
> +
> +static const char * fimc_clock_names[] = {
> + [FIMC_CLK_LCLK]   = "sclk_fimc",
> + [FIMC_CLK_GATE]   = "fimc",
> + [FIMC_CLK_WB_A]   = "pxl_async0",
> + [FIMC_CLK_WB_B]   = "pxl_async1",
> + [FIMC_CLK_MUX]= "mux",
> + [FIMC_CLK_PARENT] = "parent",


- How can I get "mux", "parent" clock information ?
   Normally we are using "mout_mpll" in exynos4210, "mout_mpll_user" in 
  exynos 4412. I want to get this two kind of clock name information.


> +};
> +
> +#define FIMC_DEFAULT_LCLK_FREQUENCY 13300UL


- When do I use this value in the patch ?
   If not use. please remove this macro. If you want to use this value.
   please use platform data instead of macro.


> +
>   /*
>* A structure of scaler.
>*
> @@ -132,15 +153,12 @@ struct fimc_driverdata {
>*
>* @ippdrv: prepare initialization using ippdrv.
>* @regs_res: register resources.
> + * @dev: pointer to the fimc device structure.


- We already set the dev information in ippdrv structure.
   I think this value is duplicated value.


>* @regs: memory mapped io registers.
>* @lock: locking of operations.
> - * @sclk_fimc_clk: fimc source clock.
> - * @fimc_clk: fimc clock.
> - * @wb_clk: writeback a clock.
> - * @wb_b_clk: writeback b clock.
> + * @clocks: fimc clocks.
> + * @clk_frequency: LCLK clock frequency.
>* @sc: scaler infomations.
> - * @odr: ordering of YUV.
> - * @ver: fimc version.
>* @pol: porarity of writeback.
>* @id: fimc id.
>* @irq: irq number.
> @@ -148,13 +166,12 @@ struct fimc_driverdata {
>*/
>   struct fimc_context {
>   struct exynos_drm_ippdrvippdrv;
> + struct device   *dev;

- please check this value about really need ?

>   struct resource *regs_res;
>   void __iomem*regs;
>   struct mutexlock;
> - struct clk  *sclk_fimc_clk;
> - struct clk  *fimc_clk;
> - struct clk  *wb_clk;
> - struct clk  *wb_b_clk;
> + struct clk  *clocks[FIMC_CLKS_MAX];
> + u32 clk_frequency;
>   struct fimc_scaler  sc;
>   struct fimc_driverdata  *ddata;
>   struct exynos_drm_ipp_pol   pol;
> @@ -1301,14 +1318,12 @@ static int fimc_clk_ctrl(struct fimc_context *ctx, 
> bool enable)
>   DRM_DEBUG_KMS("%s:enable[%d]\n", __func__, enable);
>
>   if (enable) {
> - clk_enable(ctx->sclk_fimc_clk);
> - clk_enable(ctx->fimc_clk);
> - clk_enable(ctx->wb_clk);
> + clk_prepare_enable(ctx->clocks[FIMC_CLK_GATE]);
> + clk_prepare_enable(ctx->clocks[FIMC_CLK_WB_A]);
>   ctx->suspended = false;
>   } else {
> - clk_disable(ctx->sclk_fimc_clk);
> - clk_disable(ctx->fimc_clk);
> - clk_disable(ctx->wb_clk);
> + clk_disable_unprepare(ctx->clocks[FIMC_CLK_GATE]);
> + clk_disable_unprepare(ctx->clocks[FIMC_CLK_WB_A]);
>   ctx->suspended = true;
>   }
>
> @@ -1713,11 +1728,66 @@ static void fimc_ippdrv_stop(struct device *dev, enum 
> drm_exynos_ipp_cmd cmd)
>   fimc_write(cfg, EXYNOS_CIGCTRL);
>   }
>
> +static void fimc_put_clocks(struct fimc_context *ctx)
> +{
> + int i;
> +
> + for (i = 0; i < FIMC_CLKS_MAX; i++) {
> + if (IS_ERR(ctx->clocks[i]))
> + continue;
> + clk_put(ctx->clocks[i]);
> + ctx->clocks[i] = ERR_PTR(-EINVAL);
> + }
> +}
> +
> +static int

UVD status on loongson 3a platform

2013-04-19 Thread Huacai Chen

Due to platform limitation, Loongson-3a use 16KB page, and X86 use 4KB
page, maybe this has some relationship with the video mosaic?


On Fri, Apr 19, 2013 at 4:51 PM, Chen Jie  wrote:

> Hi all,
>
> Recently, the uvd supporting is released, and we've tried it on
> loongson 3a platform.
> Brief introduction about loongson 3a, it's a MIPS III compatible, 4
> cores processor.
>
> More details about the platform [1]:
> * The Board: RS780E + SB710 chipset, with an AMD radeon HD6570 video card
> * The kernel is 64bits(n64 ABI), and the userland is 32bits(o32 ABI)
> * OS: LOonux 3.3.6 [2] + LTP-uvd-installer-20130419.bin [3]
> ** kernel: 3.9 + uvd related patches
> ** mesa: git master version (d0e9aa)
>
> We tried three video samples:
> * big_buck_bunny_1080p_h264.mov
> (
> http://mirrorblender.top-ix.org/peach/bigbuckbunny_movies/big_buck_bunny_1080p_h264.mov
> )
> * Sintel.2010.2K.x264-VODO.mp4
> (
> http://dev.lemote.com/files/upload/software/UVD-debug/Sintel.2010.2K.x264-VODO.mp4
> )
> * test.avi (http://dev.lemote.com/files/upload/software/UVD-debug/test.avi
> )
>
> For big_buck_bunny_1080p_h264.mov, the playback is not very fluent at
> the beginning, and it has some video mosaic. We've recorded a video
> for it, see
> http://dev.lemote.com/files/upload/software/UVD-debug/bbb-1080P.mp4
> For video mosaic, what could it be caused by?
>
> For Sintel.2010.2K.x264-VODO.mp4, it has a very long wait for the first
> frame.
> We've also recorded a video for it, see
> http://dev.lemote.com/files/upload/software/UVD-debug/sintel.2K.mp4
> Any idea about the long wait for the first frame?
>
> For test.avi(video: ITU H.264, 1920x1080), it's playing back
> perfectly! Thanks for the effort on UVD!
>
> In all of these tests, the CPU usage is around 50%, and all three
> video samples play well on X86 platform with the same video card.
>
> BTW, 785G also has UVD2.0, is it supported currently? Or will it be
> supported in the near future?
>
>
>
> Regards,
>
> Chen Jie
> 
> [1] http://www.lemote.com/products/computer/fulong/348.html (zh_CN)
> [2] http://dev.lemote.com/653.html (zh_CN)
> [3] http://dev.lemote.com/663.html (zh_CN)
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130419/1be454d4/attachment.html>

[PATCH 1/2] drm: add drm_edid_to_eld helper extracting SADs from EDID

Am 19.04.2013 19:01, schrieb Rafa? Mi?ecki:
> Some devices (ATI/AMD cards) don't support passing ELD struct to the
> hardware but just require filling specific registers and then the
> hardware/firmware does the rest. In such cases we need to read the info
> from SAD blocks and put them in the correct registers.
>
> Signed-off-by: Rafa? Mi?ecki 

Maybe add some comment that the returned pointer needs to be kfreed, but 
apart from that it is good enough for me and:

Reviewed-by: Christian K?nig 

> ---
> Changes since RFC:
> 1) Fixed allocation (and kcalloc instead of kzalloc)
> 2) Don't duplicate defines for audio codecs
> 3) Some variables scope
> ---
>   drivers/gpu/drm/drm_edid.c |   58 
> 
>   include/drm/drm_edid.h |9 +++
>   2 files changed, 67 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index e2acfdb..89ae211 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -2511,6 +2511,64 @@ void drm_edid_to_eld(struct drm_connector *connector, 
> struct edid *edid)
>   EXPORT_SYMBOL(drm_edid_to_eld);
>   
>   /**
> + * drm_edid_to_sad - extracts SADs from EDID
> + * @edid: EDID to parse
> + * @sads: pointer that will be set to the extracted SADs
> + *
> + * Looks for CEA EDID block and extracts SADs (Short Audio Descriptors) from 
> it.
> + *
> + * Return number of found SADs or negative number on error.
> + */
> +int drm_edid_to_sad(struct edid *edid, struct cea_sad **sads)
> +{
> + int count = 0;
> + int i, start, end, dbl;
> + u8 *cea;
> +
> + cea = drm_find_cea_extension(edid);
> + if (!cea) {
> + DRM_DEBUG_KMS("SAD: no CEA Extension found\n");
> + return -ENOENT;
> + }
> +
> + if (cea_revision(cea) < 3) {
> + DRM_DEBUG_KMS("SAD: wrong CEA revision\n");
> + return -ENOTSUPP;
> + }
> +
> + if (cea_db_offsets(cea, , )) {
> + DRM_DEBUG_KMS("SAD: invalid data block offsets\n");
> + return -EPROTO;
> + }
> +
> + for_each_cea_db(cea, i, start, end) {
> + u8 *db = [i];
> +
> + if (cea_db_tag(db) == AUDIO_BLOCK) {
> + dbl = cea_db_payload_len(db);
> + int j;
> +
> + count = dbl / 3; /* SAD is 3B */
> + *sads = kcalloc(count, sizeof(**sads), GFP_KERNEL);
> + if (!*sads)
> + return -ENOMEM;
> + for (j = 0; j < count; j++) {
> + u8 *sad = [1 + j * 3];
> +
> + (*sads)[j].format = (sad[0] & 0x78) >> 3;
> + (*sads)[j].channels = sad[0] & 0x7;
> + (*sads)[j].freq = sad[1] & 0x7F;
> + (*sads)[j].byte2 = sad[2];
> + }
> + break;
> + }
> + }
> +
> + return count;
> +}
> +EXPORT_SYMBOL(drm_edid_to_sad);
> +
> +/**
>* drm_av_sync_delay - HDMI/DP sink audio-video sync delay in millisecond
>* @connector: connector associated with the HDMI/DP sink
>* @mode: the display mode
> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> index 5da1b4a..fc481fc 100644
> --- a/include/drm/drm_edid.h
> +++ b/include/drm/drm_edid.h
> @@ -244,12 +244,21 @@ struct edid {
>   
>   #define EDID_PRODUCT_ID(e) ((e)->prod_code[0] | ((e)->prod_code[1] << 8))
>   
> +/* Short Audio Descriptor */
> +struct cea_sad {
> + u8 format;
> + u8 channels; /* max number of channels - 1 */
> + u8 freq;
> + u8 byte2; /* meaning depends on format */
> +};
> +
>   struct drm_encoder;
>   struct drm_connector;
>   struct drm_display_mode;
>   struct hdmi_avi_infoframe;
>   
>   void drm_edid_to_eld(struct drm_connector *connector, struct edid *edid);
> +int drm_edid_to_sad(struct edid *edid, struct cea_sad **sads);
>   int drm_av_sync_delay(struct drm_connector *connector,
> struct drm_display_mode *mode);
>   struct drm_connector *drm_select_eld(struct drm_encoder *encoder,

[PATCH 2/2] drm/radeon/evergreen: set SAD registers

This allows audio (alsa) driver to read them and have a clue about audio
capabilities of connected receiver. This has been verified to be
compatible with fglrx behaviour for Onkyo TX-SR605 and Denon 1912.

Signed-off-by: Rafa? Mi?ecki 
---
 drivers/gpu/drm/radeon/evergreen_hdmi.c |   63 +++
 1 file changed, 63 insertions(+)

diff --git a/drivers/gpu/drm/radeon/evergreen_hdmi.c 
b/drivers/gpu/drm/radeon/evergreen_hdmi.c
index 380933b..1e046d15 100644
--- a/drivers/gpu/drm/radeon/evergreen_hdmi.c
+++ b/drivers/gpu/drm/radeon/evergreen_hdmi.c
@@ -54,6 +54,68 @@ static void evergreen_hdmi_update_ACR(struct drm_encoder 
*encoder, uint32_t cloc
WREG32(HDMI_ACR_48_1 + offset, acr.n_48khz);
 }

+static void evergreen_hdmi_write_sad_regs(struct drm_encoder *encoder)
+{
+   struct radeon_device *rdev = encoder->dev->dev_private;
+   struct drm_connector *connector;
+   struct radeon_connector *radeon_connector = NULL;
+   struct cea_sad *sads;
+   int i, sad_count;
+
+   static const u16 eld_reg_to_type[][2] = {
+   { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR0, 
HDMI_AUDIO_CODING_TYPE_PCM },
+   { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR1, 
HDMI_AUDIO_CODING_TYPE_AC3 },
+   { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR2, 
HDMI_AUDIO_CODING_TYPE_MPEG1 },
+   { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR3, 
HDMI_AUDIO_CODING_TYPE_MP3 },
+   { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR4, 
HDMI_AUDIO_CODING_TYPE_MPEG2 },
+   { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR5, 
HDMI_AUDIO_CODING_TYPE_AAC_LC },
+   { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR6, 
HDMI_AUDIO_CODING_TYPE_DTS },
+   { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR7, 
HDMI_AUDIO_CODING_TYPE_ATRAC },
+   { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR9, 
HDMI_AUDIO_CODING_TYPE_EAC3 },
+   { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR10, 
HDMI_AUDIO_CODING_TYPE_DTS_HD },
+   { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR11, 
HDMI_AUDIO_CODING_TYPE_MLP },
+   { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR13, 
HDMI_AUDIO_CODING_TYPE_WMA_PRO },
+   };
+
+   list_for_each_entry(connector, 
>dev->mode_config.connector_list, head) {
+   if (connector->encoder == encoder)
+   radeon_connector = to_radeon_connector(connector);
+   }
+
+   if (!radeon_connector) {
+   DRM_ERROR("Couldn't find encoder's connector\n");
+   return;
+   }
+
+   sad_count = drm_edid_to_sad(radeon_connector->edid, );
+   if (sad_count < 0) {
+   DRM_ERROR("Couldn't read SADs: %d\n", sad_count);
+   return;
+   }
+   BUG_ON(!sads);
+
+   for (i = 0; i < ARRAY_SIZE(eld_reg_to_type); i++) {
+   u32 value = 0;
+   int j;
+
+   for (j = 0; j < sad_count; j++) {
+   struct cea_sad *sad = [j];
+
+   if (sad->format == eld_reg_to_type[i][1]) {
+   value = MAX_CHANNELS(sad->channels) |
+   DESCRIPTOR_BYTE_2(sad->byte2) |
+   SUPPORTED_FREQUENCIES(sad->freq);
+   if (sad->format == HDMI_AUDIO_CODING_TYPE_PCM)
+   value |= 
SUPPORTED_FREQUENCIES_STEREO(sad->freq);
+   break;
+   }
+   }
+   WREG32(eld_reg_to_type[i][0], value);
+   }
+
+   kfree(sads);
+}
+
 /*
  * build a HDMI Video Info Frame
  */
@@ -163,6 +225,7 @@ void evergreen_hdmi_setmode(struct drm_encoder *encoder, 
struct drm_display_mode
   AFMT_AUDIO_CHANNEL_ENABLE(0xff));

/* fglrx sets 0x40 in 0x5f80 here */
+   evergreen_hdmi_write_sad_regs(encoder);

err = drm_hdmi_avi_infoframe_from_display_mode(, mode);
if (err < 0) {
-- 
1.7.10.4

[PATCH 1/2] drm: add drm_edid_to_eld helper extracting SADs from EDID

Some devices (ATI/AMD cards) don't support passing ELD struct to the
hardware but just require filling specific registers and then the
hardware/firmware does the rest. In such cases we need to read the info
from SAD blocks and put them in the correct registers.

Signed-off-by: Rafa? Mi?ecki 
---
Changes since RFC:
1) Fixed allocation (and kcalloc instead of kzalloc)
2) Don't duplicate defines for audio codecs
3) Some variables scope
---
 drivers/gpu/drm/drm_edid.c |   58 
 include/drm/drm_edid.h |9 +++
 2 files changed, 67 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index e2acfdb..89ae211 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2511,6 +2511,64 @@ void drm_edid_to_eld(struct drm_connector *connector, 
struct edid *edid)
 EXPORT_SYMBOL(drm_edid_to_eld);

 /**
+ * drm_edid_to_sad - extracts SADs from EDID
+ * @edid: EDID to parse
+ * @sads: pointer that will be set to the extracted SADs
+ *
+ * Looks for CEA EDID block and extracts SADs (Short Audio Descriptors) from 
it.
+ *
+ * Return number of found SADs or negative number on error.
+ */
+int drm_edid_to_sad(struct edid *edid, struct cea_sad **sads)
+{
+   int count = 0;
+   int i, start, end, dbl;
+   u8 *cea;
+
+   cea = drm_find_cea_extension(edid);
+   if (!cea) {
+   DRM_DEBUG_KMS("SAD: no CEA Extension found\n");
+   return -ENOENT;
+   }
+
+   if (cea_revision(cea) < 3) {
+   DRM_DEBUG_KMS("SAD: wrong CEA revision\n");
+   return -ENOTSUPP;
+   }
+
+   if (cea_db_offsets(cea, , )) {
+   DRM_DEBUG_KMS("SAD: invalid data block offsets\n");
+   return -EPROTO;
+   }
+
+   for_each_cea_db(cea, i, start, end) {
+   u8 *db = [i];
+
+   if (cea_db_tag(db) == AUDIO_BLOCK) {
+   dbl = cea_db_payload_len(db);
+   int j;
+
+   count = dbl / 3; /* SAD is 3B */
+   *sads = kcalloc(count, sizeof(**sads), GFP_KERNEL);
+   if (!*sads)
+   return -ENOMEM;
+   for (j = 0; j < count; j++) {
+   u8 *sad = [1 + j * 3];
+
+   (*sads)[j].format = (sad[0] & 0x78) >> 3;
+   (*sads)[j].channels = sad[0] & 0x7;
+   (*sads)[j].freq = sad[1] & 0x7F;
+   (*sads)[j].byte2 = sad[2];
+   }
+   break;
+   }
+   }
+
+   return count;
+}
+EXPORT_SYMBOL(drm_edid_to_sad);
+
+/**
  * drm_av_sync_delay - HDMI/DP sink audio-video sync delay in millisecond
  * @connector: connector associated with the HDMI/DP sink
  * @mode: the display mode
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 5da1b4a..fc481fc 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -244,12 +244,21 @@ struct edid {

 #define EDID_PRODUCT_ID(e) ((e)->prod_code[0] | ((e)->prod_code[1] << 8))

+/* Short Audio Descriptor */
+struct cea_sad {
+   u8 format;
+   u8 channels; /* max number of channels - 1 */
+   u8 freq;
+   u8 byte2; /* meaning depends on format */
+};
+
 struct drm_encoder;
 struct drm_connector;
 struct drm_display_mode;
 struct hdmi_avi_infoframe;

 void drm_edid_to_eld(struct drm_connector *connector, struct edid *edid);
+int drm_edid_to_sad(struct edid *edid, struct cea_sad **sads);
 int drm_av_sync_delay(struct drm_connector *connector,
  struct drm_display_mode *mode);
 struct drm_connector *drm_select_eld(struct drm_encoder *encoder,
-- 
1.7.10.4

[Bug 63730] UVD broken on HD5470 by "drm/radeon: raise UVD clocks only on demand"

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

--- Comment #2 from Johannes Hirte  ---
No, still the same error.

-- 
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/20130419/68dc5bc3/attachment.html>

drm/radeon: add radeon_atom_get_clock_dividers helper

Am 18.04.2013 20:47, schrieb Dan Carpenter:
> Hello Christian K?nig,
>
> The patch 7062ab67d4c6: "drm/radeon: add
> radeon_atom_get_clock_dividers helper" from Apr 8, 2013, has endian
> bugs.
>
> drivers/gpu/drm/radeon/radeon_atombios.c
>2712  if (clock_type == COMPUTE_ENGINE_PLL_PARAM) {
>2713  args.v3.ulClock.ulComputeClockFlag = 
> clock_type;
>2714  args.v3.ulClock.ulClockFreq = 
> cpu_to_le32(clock);   /* 10 khz */
>  ^^^
> This is 24 bit bitfield so it can't store a __le32.  On little endian
> systems it will truncate high bits away so that's ok, but on big endian
> it will break.
>
>2715
>2716  
> atom_execute_table(rdev->mode_info.atom_context, index, (uint32_t *));
>2717
>2718  dividers->post_div = 
> args.v3.ucPostDiv;
>2719  dividers->enable_post_div = 
> (args.v3.ucCntlFlag &
>2720   
> ATOM_PLL_CNTL_FLAG_PLL_POST_DIV_EN) ? true : false;
>
> There are a lot of other Sparse endian warnings but I haven't looked
> at them.  Here is how to check:  http://lwn.net/Articles/205624/

Hi Dan,

in general I'm not sure that we support any big endian system with that 
code any more.

But Alex wrote most of the atombios code, so that is probably more a 
question for him.

Christian.

> regards,
> dan carpenter
>
>

UVD status on loongson 3a platform

Am 19.04.2013 10:51, schrieb Chen Jie:
> Hi all,
>
> Recently, the uvd supporting is released, and we've tried it on
> loongson 3a platform.
> Brief introduction about loongson 3a, it's a MIPS III compatible, 4
> cores processor.
>
> More details about the platform [1]:
> * The Board: RS780E + SB710 chipset, with an AMD radeon HD6570 video card
> * The kernel is 64bits(n64 ABI), and the userland is 32bits(o32 ABI)
> * OS: LOonux 3.3.6 [2] + LTP-uvd-installer-20130419.bin [3]
> ** kernel: 3.9 + uvd related patches
> ** mesa: git master version (d0e9aa)
>
> We tried three video samples:
> * big_buck_bunny_1080p_h264.mov
> (http://mirrorblender.top-ix.org/peach/bigbuckbunny_movies/big_buck_bunny_1080p_h264.mov)
> * Sintel.2010.2K.x264-VODO.mp4
> (http://dev.lemote.com/files/upload/software/UVD-debug/Sintel.2010.2K.x264-VODO.mp4)
> * test.avi (http://dev.lemote.com/files/upload/software/UVD-debug/test.avi)
>
> For big_buck_bunny_1080p_h264.mov, the playback is not very fluent at
> the beginning, and it has some video mosaic. We've recorded a video
> for it, see 
> http://dev.lemote.com/files/upload/software/UVD-debug/bbb-1080P.mp4
> For video mosaic, what could it be caused by?

That looks like a known problem with the semaphores and also happens on 
X86, it gets worse when you have a slower CPU and/or less bandwidth 
cause then UVD needs to block on the DMA to wait till everything is in 
place. I'm going to try to release the workaround for it.

> For Sintel.2010.2K.x264-VODO.mp4, it has a very long wait for the first frame.
> We've also recorded a video for it, see
> http://dev.lemote.com/files/upload/software/UVD-debug/sintel.2K.mp4
> Any idea about the long wait for the first frame?

No idea, that also happens on X86, but the wait is actually not as long. 
If I'm not completely wrong it seems to be mplayer who is causing this 
startup delay.

> For test.avi(video: ITU H.264, 1920x1080), it's playing back
> perfectly! Thanks for the effort on UVD!
>
> In all of these tests, the CPU usage is around 50%, and all three
> video samples play well on X86 platform with the same video card.
>
> BTW, 785G also has UVD2.0, is it supported currently? Or will it be
> supported in the near future?

No, as Alex already stated that chip is quite different to the other UVD 
generations, and we are currently looking into releasing code for it, 
but can't promise anything.

Cheers,
Christian.

>
>
> Regards,
>
> Chen Jie
> 
> [1] http://www.lemote.com/products/computer/fulong/348.html (zh_CN)
> [2] http://dev.lemote.com/653.html (zh_CN)
> [3] http://dev.lemote.com/663.html (zh_CN)
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

UVD status on loongson 3a platform

2013-04-19 Thread Chen Jie

Hi all,

Recently, the uvd supporting is released, and we've tried it on
loongson 3a platform.
Brief introduction about loongson 3a, it's a MIPS III compatible, 4
cores processor.

More details about the platform [1]:
* The Board: RS780E + SB710 chipset, with an AMD radeon HD6570 video card
* The kernel is 64bits(n64 ABI), and the userland is 32bits(o32 ABI)
* OS: LOonux 3.3.6 [2] + LTP-uvd-installer-20130419.bin [3]
** kernel: 3.9 + uvd related patches
** mesa: git master version (d0e9aa)

We tried three video samples:
* big_buck_bunny_1080p_h264.mov
(http://mirrorblender.top-ix.org/peach/bigbuckbunny_movies/big_buck_bunny_1080p_h264.mov)
* Sintel.2010.2K.x264-VODO.mp4
(http://dev.lemote.com/files/upload/software/UVD-debug/Sintel.2010.2K.x264-VODO.mp4)
* test.avi (http://dev.lemote.com/files/upload/software/UVD-debug/test.avi)

For big_buck_bunny_1080p_h264.mov, the playback is not very fluent at
the beginning, and it has some video mosaic. We've recorded a video
for it, see http://dev.lemote.com/files/upload/software/UVD-debug/bbb-1080P.mp4
For video mosaic, what could it be caused by?

For Sintel.2010.2K.x264-VODO.mp4, it has a very long wait for the first frame.
We've also recorded a video for it, see
http://dev.lemote.com/files/upload/software/UVD-debug/sintel.2K.mp4
Any idea about the long wait for the first frame?

For test.avi(video: ITU H.264, 1920x1080), it's playing back
perfectly! Thanks for the effort on UVD!

In all of these tests, the CPU usage is around 50%, and all three
video samples play well on X86 platform with the same video card.

BTW, 785G also has UVD2.0, is it supported currently? Or will it be
supported in the near future?



Regards,

Chen Jie

[1] http://www.lemote.com/products/computer/fulong/348.html (zh_CN)
[2] http://dev.lemote.com/653.html (zh_CN)
[3] http://dev.lemote.com/663.html (zh_CN)

[Bug 63732] [KDE] - display switching problem with kwin_gles and radeon driver.

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

--- Comment #4 from Honza Tvrznik  ---
Created attachment 78248
  --> https://bugs.freedesktop.org/attachment.cgi?id=78248=edit
dmesg part

-- 
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/20130419/8cb91bac/attachment.html>

[Bug 63732] [KDE] - display switching problem with kwin_gles and radeon driver.

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

--- Comment #3 from Honza Tvrznik  ---
Created attachment 78247
  --> https://bugs.freedesktop.org/attachment.cgi?id=78247=edit
xorg log

-- 
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/20130419/cbbb9a53/attachment.html>

[Bug 63732] [KDE] - display switching problem with kwin_gles and radeon driver.

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

--- Comment #2 from Honza Tvrznik  ---
I must say that I don't have any problem with kwin (but kwin is too slow for
me). This bug is present only when I'am using kwin_gles.

Maybe this bug: https://bugs.freedesktop.org/show_bug.cgi?id=61600 is like this
one, but, for intel driver.

Parts of dmesg and full Xorg.0.log attached.

-- 
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/20130419/d8c62126/attachment.html>

[DVO][PATCH] drm/i915: Fall back to bit banging mode for DVO transmitter detection

On Fri, Apr 19, 2013 at 12:54:00PM +0200, "David M?ller (ELSOFT AG)" wrote:
> Daniel Vetter wrote:
> > On Fri, Apr 19, 2013 at 10:41:50AM +0200, "David M?ller (ELSOFT AG)" wrote:
> >> +  /* GMBUS NAK handling seems to be unstable, hence let the
> >> +   * transmitter detection run in bit banging mode for now.
> >> +   */
> >> +  intel_gmbus_force_bit(i2c, true);
> >> +
> >> +  dvoinit = dvo->dev_ops->init(_dvo->dev, i2c);
> >> +
> >> +  intel_gmbus_force_bit(i2c, false);
> > 
> > Shouldn't we keep the dvo i2c line in bit-banging mode always, i.e.
> > restore gmbus mode only when dvo init failed?
> > 
> > I suspect that for fickle hw not just init will fail ...
> 
> As far as i can tell, the critical part is the NAK handling.

Ok, I've merged the patch for 3.10 with cc: stable.

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

[Bug 63732] [KDE] - display switching problem with kwin_gles and radeon driver.

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

Alex Deucher  changed:

   What|Removed |Added

  Component|Drivers/DRI/Radeon  |Drivers/DRI/r300

--- Comment #1 from Alex Deucher  ---
Please attach your xorg log and dmesg output.  I suspect this may be related to
bug 61182.

-- 
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/20130419/2e2eb033/attachment.html>

[Bug 63732] [KDE] - display switching problem with kwin_gles and radeon driver.

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

Alex Deucher  changed:

   What|Removed |Added

  Attachment #78244|text/plain  |image/png
  mime type||

-- 
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/20130419/69629120/attachment.html>

linux-next: Tree for Apr 18 [ call-trace: drm | x86 | smp | rcu related? ]

2013-04-19 Thread Linus Torvalds

On Fri, Apr 19, 2013 at 3:55 PM, Sedat Dilek  wrote:
>
> Davidlohr pointed to this patch (tested the triplet):
>
> ipc, sem: do not call sem_lock when bogus sma:
> https://lkml.org/lkml/2013/3/31/12
>
> Is that what you mean?

Yup.

Linus

[Bug 63732] New: [KDE] - display switching problem with kwin_gles and radeon driver.

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

  Priority: medium
Bug ID: 63732
  Assignee: dri-devel at lists.freedesktop.org
   Summary: [KDE] - display switching problem with kwin_gles and
radeon driver.
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: flateric at atlas.cz
  Hardware: Other
Status: NEW
   Version: 9.1
 Component: Drivers/DRI/Radeon
   Product: Mesa

Created attachment 78244
  --> https://bugs.freedesktop.org/attachment.cgi?id=78244=edit
Dualdisplay bug.

Hello,

with radeon driver and mesa in version 9.1.1 I have problem with switching
display between notebook and external display in KDE 4.10.2 with kwin_gles
compositor in compositing type OpenGL.

Setting dual display (left/right/above) or switching between displays, causes
broken screen. Please, check attached screenshot.

Downgrading to mesa version 9.0.2 solve this problem. 

With intel GPU/Driver is everything OK.

KDE version 4.10.2
GPU: ATI x1400, driver - radeon
Kernel: 3.8.7
mesa version: 9.1.1
ati-dri version: 9.1.1

-- 
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/20130419/5bf0b380/attachment.html>

linux-next: Tree for Apr 18 [ call-trace: drm | x86 | smp | rcu related? ]

2013-04-19 Thread Linus Torvalds

On Fri, Apr 19, 2013 at 3:34 PM, Sedat Dilek  wrote:
>
> See attached dmesg.

This still has the bug Davidlohr pointed at:

>> This looks like what Emmanuel was/is running into:
>> https://lkml.org/lkml/2013/3/30/1

you need to move the "IS_ERR()" check before the sem_lock.

  Linus

[Bug 63702] tiling2d in radeon trash vdpau UVD textures

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

--- Comment #4 from Rafael Castillo  ---
i just emerged mesa/drm/llvm git i did not modify the source code

-- 
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/20130419/35df8509/attachment.html>

[PATCH v4] drm/exynos: prepare FIMD clocks

2013-04-19 Thread Vikas Sajjan

Hi Inki Dae and Viresh,

On 8 April 2013 16:41, Viresh Kumar  wrote:

> On 8 April 2013 16:37, Vikas Sajjan  wrote:
> > While migrating to common clock framework (CCF), I found that the FIMD
> clocks
> > were pulled down by the CCF.
> > If CCF finds any clock(s) which has NOT been claimed by any of the
> > drivers, then such clock(s) are PULLed low by CCF.
> >
> > Calling clk_prepare() for FIMD clocks fixes the issue.
> >
> > This patch also replaces clk_disable() with clk_unprepare() during exit,
> since
> > clk_prepare() is called in fimd_probe().
>
> I asked you about fixing your commit log too.. It still looks incorrect to
> me.
>
> This patch doesn't have anything to do with CCF pulling clocks down, but
> calling clk_prepare() before clk_enable() is must now.. that's it..
> nothing more.
>
>   what I noticed is the fimd_clock() which in turn calls clk_enable(),
will only be called if the RUNTIME PM is enabled. So the current patch
breaks and display won't appear, if we don't enable the RUNTIME PM. So it
becomes mandatory to enable  RUNTIME PM, to FIMD to work.
I am NOT sure whether it is a good idea make FIMD work if and only if
RUMTIME PM is enabled.
I guess Mr. Inki Dae can throw more light on this.
Or else make it like the earlier V1 version where clk_prepare_enable() was
called in fimd_probe() itself.

> Signed-off-by: Vikas Sajjan 
> > ---
> > Changes since v3:
> > - added clk_prepare() in fimd_probe() and clk_unprepare() in
> fimd_remove()
> >  as suggested by Viresh Kumar 
> > Changes since v2:
> > - moved clk_prepare_enable() and clk_disable_unprepare() from
> > fimd_probe() to fimd_clock() as suggested by Inki Dae <
> inki.dae at samsung.com>
> > Changes since v1:
> > - added error checking for clk_prepare_enable() and also replaced
> > clk_disable() with clk_disable_unprepare() during exit.
> > ---
> >  drivers/gpu/drm/exynos/exynos_drm_fimd.c |   14 --
> >  1 file changed, 12 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> > index 9537761..aa22370 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> > @@ -934,6 +934,16 @@ static int fimd_probe(struct platform_device *pdev)
> > return ret;
> > }
> >
> > +   ret = clk_prepare(ctx->bus_clk);
> > +   if (ret < 0)
> > +   return ret;
> > +
> > +   ret = clk_prepare(ctx->lcd_clk);
> > +   if  (ret < 0) {
> > +   clk_unprepare(ctx->bus_clk);
> > +   return ret;
> > +   }
> > +
> > ctx->vidcon0 = pdata->vidcon0;
> > ctx->vidcon1 = pdata->vidcon1;
> > ctx->default_win = pdata->default_win;
> > @@ -981,8 +991,8 @@ static int fimd_remove(struct platform_device *pdev)
> > if (ctx->suspended)
> > goto out;
> >
> > -   clk_disable(ctx->lcd_clk);
> > -   clk_disable(ctx->bus_clk);
> > +   clk_unprepare(ctx->lcd_clk);
> > +   clk_unprepare(ctx->bus_clk);
>
> This looks wrong again.. You still need to call clk_disable() to make
> clk enabled
> count zero...
>

Viresh had an suggestion, that the original code had a call
clk_disable() in fimd_remove(), which is really NOT required as there is NO
clk_enable() in fimd_probe() and we can right away delete clk_disable()
from fimd_remove().

And also i think i should be breaking this patch into 2, 1st patch for
adding clk_prepare_enable() ( if we want remove dependency on RUNTIME PM )
in fimd_probe() for CCF migration another one for idea of replacing
clk_disable() with adding clk_disable_unprepare() (since we will be adding
clk_prepare_enable() in probe ) in fimd_remove() .

Mr. Inki Dae any thoughts on this.

-- 
Thanks and Regards
 Vikas Sajjan
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130419/5c2e9403/attachment-0001.html>

linux-next: Tree for Apr 18 [ call-trace: drm | x86 | smp | rcu related? ]

2013-04-19 Thread Linus Torvalds

On Fri, Apr 19, 2013 at 2:09 PM, Sedat Dilek  wrote:
>
> I have applied all three patches and see still call-traces.
> New are apparmor related messages.

Can you try the crazy rcu double-free debug hack?

See

https://lkml.org/lkml/2013/3/30/113

and I'm re-attaching the ugly-ass crazy hack patch here too..

Linus
-- next part --
A non-text attachment was scrubbed...
Name: rcu-double-free-hack.patch
Type: application/octet-stream
Size: 2252 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130419/98b60ff0/attachment.obj>

[Bug 63730] UVD broken on HD5470 by "drm/radeon: raise UVD clocks only on demand"

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

--- Comment #1 from Christian K?nig  ---
Created attachment 78243
  --> https://bugs.freedesktop.org/attachment.cgi?id=78243=edit
Possible fix

Does this patch fixes the 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/20130419/601ab84e/attachment-0001.html>

[Bug 63702] tiling2d in radeon trash vdpau UVD textures

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

Christian K?nig  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #3 from Christian K?nig  ---
That just looks like incorrect tilling parameters, what did you do to trigger
that?

Did you update anything? Different parameters?

-- 
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/20130419/c581616a/attachment.html>

[Bug 63714] UVD acceleration does not properly detect kernel support

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

Christian K?nig  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |NOTABUG

--- Comment #2 from Christian K?nig  ---
That indeed just sounds like you're kernel is outdated.

The kernel interface changed while merging the patches and the patches in mesa
uses the end result in drm-next-3.10, so it is highly likely that you just have
a outdated kernel.

-- 
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/20130419/45c4f3be/attachment.html>

[Bug 63709] Desktop Effects on 3D desktop environments are jerky/stutter.

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

--- Comment #4 from equites.vero at gmail.com ---
Created attachment 78241
  --> https://bugs.freedesktop.org/attachment.cgi?id=78241=edit
xorg.conf that was tried

-- 
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/20130419/6201571d/attachment.html>

[Bug 63709] Desktop Effects on 3D desktop environments are jerky/stutter.

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

--- Comment #3 from equites.vero at gmail.com ---
Created attachment 78240
  --> https://bugs.freedesktop.org/attachment.cgi?id=78240=edit
dmesg output

-- 
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/20130419/c817d0a6/attachment.html>

confused about a BUG_ON in drm_mm_dump_table

2013-04-19 Thread Christopher Harvey


I've been trying to wrap my head around ttm and gem these last couple of
weeks. I found the nice 'drm_mm_dump_table' function and ran it on the
mgag200 drm_mm struct. Instant BUG in include/drm/drm_mm.h line 100.

static inline unsigned long drm_mm_hole_node_start(struct drm_mm_node 
*hole_node)
{
BUG_ON(!hole_node->hole_follows);
return __drm_mm_hole_node_start(hole_node);
}

where drm_mm_hole_node_start is called from drm_mm_dump_table like so:

int drm_mm_dump_table(struct seq_file *m, struct drm_mm *mm)
{
struct drm_mm_node *entry;
unsigned long total_used = 0, total_free = 0, total = 0;
unsigned long hole_start, hole_end, hole_size;

hole_start = drm_mm_hole_node_start(>head_node);
...
...
...

as far as I can tell the head_node is a list of page offsets that point
to free memory chunks. It seems drm_mm_dump_table expects a free chunk
at the beginning of the list. What if all the memory is used? How can we
ALWAYS expect a free chunk at the first element? Is this a bug in
drm_mm_dump_table? Can't we just remove the first print and let the loop
do all the work that comes right after? They look the same to me.

This all started from me trying to figure out where ttm/gem is putting
buffer objects in VRAM. All the variables in a ttm_buffer_object that
looks like they hold variables either have address outside of the total
VRAM size, or 0.

When I removed the first print in drm_mm_dump_table I get the following
output:
0x0010-0x001007e9: 0x07e9: used
0x001007e9-0x1010: 0x0817: free
total: 268435456, used 2025 free 268433431

The board only has 16M of VRAM.

thanks,
Chris

[Bug 63709] Desktop Effects on 3D desktop environments are jerky/stutter.

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

--- Comment #2 from equites.vero at gmail.com ---
Created attachment 78239
  --> https://bugs.freedesktop.org/attachment.cgi?id=78239=edit
Xorg log file

-- 
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/20130419/681fc348/attachment.html>

[Bug 63730] New: UVD broken on HD5470 by "drm/radeon: raise UVD clocks only on demand"

ost kernel: [drm] ib test on ring 0 succeeded in 0 usecs
Apr 19 15:32:10 localhost kernel: [drm] ib test on ring 3 succeeded in 0 usecs
Apr 19 15:32:10 localhost kernel: Switching to clocksource tsc
Apr 19 15:32:10 localhost kernel: [drm] radeon atom DIG backlight initialized
Apr 19 15:32:10 localhost kernel: [drm] Radeon Display Connectors
Apr 19 15:32:10 localhost kernel: [drm] Connector 0:
Apr 19 15:32:10 localhost kernel: [drm]   LVDS-1
Apr 19 15:32:10 localhost kernel: [drm]   DDC: 0x6560 0x6560 0x6564 0x6564
0x6568 0x6568 0x656c 0x656c
Apr 19 15:32:10 localhost kernel: [drm]   Encoders:
Apr 19 15:32:10 localhost kernel: [drm] LCD1: INTERNAL_UNIPHY
Apr 19 15:32:10 localhost kernel: [drm] Connector 1:
Apr 19 15:32:10 localhost kernel: [drm]   HDMI-A-1
Apr 19 15:32:10 localhost kernel: [drm]   HPD1
Apr 19 15:32:10 localhost kernel: [drm]   DDC: 0x6430 0x6430 0x6434 0x6434
0x6438 0x6438 0x643c 0x643c
Apr 19 15:32:10 localhost kernel: [drm]   Encoders:
Apr 19 15:32:10 localhost kernel: [drm] DFP1: INTERNAL_UNIPHY1
Apr 19 15:32:10 localhost kernel: [drm] Connector 2:
Apr 19 15:32:10 localhost kernel: [drm]   VGA-1
Apr 19 15:32:10 localhost NetworkManager[1538]:  (wlan0): supplicant
interface state: disconnected -> inactive
Apr 19 15:32:10 localhost kernel: [drm]   DDC: 0x6460 0x6460 0x6464 0x6464
0x6468 0x6468 0x646c 0x646c
Apr 19 15:32:10 localhost kernel: [drm]   Encoders:
Apr 19 15:32:10 localhost kernel: [drm] CRT1: INTERNAL_KLDSCP_DAC1
Apr 19 15:32:10 localhost kernel: [drm] Internal thermal controller with fan
control
Apr 19 15:32:10 localhost kernel: [drm] radeon: power management initialized
Apr 19 15:32:10 localhost kernel: [drm] fb mappable at 0xE035F000
Apr 19 15:32:10 localhost kernel: [drm] vram apper at 0xE000
Apr 19 15:32:10 localhost kernel: [drm] size 4325376
Apr 19 15:32:10 localhost kernel: [drm] fb depth is 24
Apr 19 15:32:10 localhost kernel: [drm]pitch is 5632
Apr 19 15:32:10 localhost kernel: fbcon: radeondrmfb (fb0) is primary device
Apr 19 15:32:10 localhost kernel: Console: switching to colour frame buffer
device 170x48
Apr 19 15:32:10 localhost kernel: radeon :01:00.0: fb0: radeondrmfb frame
buffer device
Apr 19 15:32:10 localhost kernel: radeon :01:00.0: registered panic
notifier
Apr 19 15:32:10 localhost kernel: [drm] Initialized radeon 2.33.0 20080528 for
:01:00.0 on minor 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/20130419/f5102058/attachment-0001.html>

[Bug 63709] Desktop Effects on 3D desktop environments are jerky/stutter.

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

--- Comment #1 from Alex Deucher  ---
please attach your xorg log and config and dmesg output.

-- 
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/20130419/6240b89d/attachment.html>

[Bug 63714] UVD acceleration does not properly detect kernel support

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

--- Comment #1 from Alex Deucher  ---
You are probably using an old set of kernel patches.  There were several
revisions.  The mesa code checks to see if the kernel is new enough and the
latest kernel patch revision bumps the kernel driver version.  You can get
everything you need from my kernel tree:
http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.10

-- 
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/20130419/7f44af95/attachment.html>

[DVO][PATCH] drm/i915: Fall back to bit banging mode for DVO transmitter detection

2013-04-19 Thread "David Müller (ELSOFT AG)"

Daniel Vetter wrote:
> On Fri, Apr 19, 2013 at 10:41:50AM +0200, "David M?ller (ELSOFT AG)" wrote:
>> +/* GMBUS NAK handling seems to be unstable, hence let the
>> + * transmitter detection run in bit banging mode for now.
>> + */
>> +intel_gmbus_force_bit(i2c, true);
>> +
>> +dvoinit = dvo->dev_ops->init(_dvo->dev, i2c);
>> +
>> +intel_gmbus_force_bit(i2c, false);
> 
> Shouldn't we keep the dvo i2c line in bit-banging mode always, i.e.
> restore gmbus mode only when dvo init failed?
> 
> I suspect that for fickle hw not just init will fail ...

As far as i can tell, the critical part is the NAK handling.

Dave

3.9.0-rc7-next: i915: render error detected

2013-04-19 Thread Jiri Slaby

Hi, with today's -next I got this:

[drm] capturing error event; look for more information in
/sys/kernel/debug/dri/0/i915_error_state
i915: render error detected, EIR: 0x0010
i915: page table error
i915:   PGTBL_ER: 0x0002
[drm:i915_report_and_clear_eir] *ERROR* EIR stuck: 0x0010, masking
i915: render error detected, EIR: 0x0010
i915: page table error
i915:   PGTBL_ER: 0x0002


The error state is here:
http://www.fi.muni.cz/~xslaby/sklad/panics/i915_error_state

thanks,
-- 
js
suse labs

[DVO][PATCH] drm/i915: Fall back to bit banging mode for DVO transmitter detection

On Fri, Apr 19, 2013 at 10:41:50AM +0200, "David M?ller (ELSOFT AG)" wrote:
> Hello
> 
> As discussed in this thread
> http://lists.freedesktop.org/archives/dri-devel/2013-April/037411.html
> GMBUS based DVO transmitter detection seems to be unreliable which could
> result in an unusable DVO port.
> 
> The attached patch fixes this by falling back to bit banging mode for
> the time DVO transmitter detection is in progress.
> 

> Signed-off-by: David M?ller 
> Tested-by: David M?ller 
> 
> ---
> diff -dpurN a/drivers/gpu/drm/i915/intel_dvo.c 
> b/drivers/gpu/drm/i915/intel_dvo.c
> --- a/drivers/gpu/drm/i915/intel_dvo.c2012-12-11 10:09:35.113446850 
> +0100
> +++ b/drivers/gpu/drm/i915/intel_dvo.c2013-04-19 07:21:54.054546365 
> +0200
> @@ -449,6 +449,7 @@ void intel_dvo_init(struct drm_device *d
>   const struct intel_dvo_device *dvo = _dvo_devices[i];
>   struct i2c_adapter *i2c;
>   int gpio;
> + bool dvoinit;
>  
>   /* Allow the I2C driver info to specify the GPIO to be used in
>* special cases, but otherwise default to what's defined
> @@ -468,7 +469,17 @@ void intel_dvo_init(struct drm_device *d
>   i2c = intel_gmbus_get_adapter(dev_priv, gpio);
>  
>   intel_dvo->dev = *dvo;
> - if (!dvo->dev_ops->init(_dvo->dev, i2c))
> +
> + /* GMBUS NAK handling seems to be unstable, hence let the
> +  * transmitter detection run in bit banging mode for now.
> +  */
> + intel_gmbus_force_bit(i2c, true);
> +
> + dvoinit = dvo->dev_ops->init(_dvo->dev, i2c);
> +
> + intel_gmbus_force_bit(i2c, false);

Shouldn't we keep the dvo i2c line in bit-banging mode always, i.e.
restore gmbus mode only when dvo init failed?

I suspect that for fickle hw not just init will fail ...
-Daniel

> +
> + if (!dvoinit)
>   continue;
>  
>   intel_encoder->type = INTEL_OUTPUT_DVO;


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

[PATCH] udl: bind the framebuffer to the correct device.

This just moves the fb sysfs node beside the drm sysfs node which
I fixed before.

just noticed it in passing.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/udl/udl_fb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/udl/udl_fb.c b/drivers/gpu/drm/udl/udl_fb.c
index 9f4be3d..dc0c065 100644
--- a/drivers/gpu/drm/udl/udl_fb.c
+++ b/drivers/gpu/drm/udl/udl_fb.c
@@ -482,7 +482,7 @@ static int udlfb_create(struct drm_fb_helper *helper,
struct udl_fbdev *ufbdev = (struct udl_fbdev *)helper;
struct drm_device *dev = ufbdev->helper.dev;
struct fb_info *info;
-   struct device *device = >usbdev->dev;
+   struct device *device = dev->dev;
struct drm_framebuffer *fb;
struct drm_mode_fb_cmd2 mode_cmd;
struct udl_gem_object *obj;
-- 
1.8.2

[PATCH 2/2] drm: prime: fix refcounting on the dmabuf import error path

From: Imre Deak 

In commit be8a42ae60 we inroduced a refcount problem, where on the
drm_gem_prime_fd_to_handle() error path we'll call dma_buf_put() for
self imported dma buffers.

Fix this by taking a reference on the dma buffer in the .gem_import
hook instead of assuming the caller had taken one. Besides fixing the
bug this is also more logical.

Signed-off-by: Imre Deak 
Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/drm_prime.c| 8 +++-
 drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 4 +++-
 drivers/gpu/drm/i915/i915_gem_dmabuf.c | 5 -
 drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c  | 1 -
 drivers/gpu/drm/udl/udl_gem.c  | 4 
 5 files changed, 18 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index eb7c38d..71f02ff 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -276,7 +276,6 @@ struct drm_gem_object *drm_gem_prime_import(struct 
drm_device *dev,
 * refcount on gem itself instead of f_count of dmabuf.
 */
drm_gem_object_reference(obj);
-   dma_buf_put(dma_buf);
return obj;
}
}
@@ -285,6 +284,8 @@ struct drm_gem_object *drm_gem_prime_import(struct 
drm_device *dev,
if (IS_ERR(attach))
return ERR_PTR(PTR_ERR(attach));

+   get_dma_buf(dma_buf);
+
sgt = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL);
if (IS_ERR_OR_NULL(sgt)) {
ret = PTR_ERR(sgt);
@@ -305,6 +306,8 @@ fail_unmap:
dma_buf_unmap_attachment(attach, sgt, DMA_BIDIRECTIONAL);
 fail_detach:
dma_buf_detach(dma_buf, attach);
+   dma_buf_put(dma_buf);
+
return ERR_PTR(ret);
 }
 EXPORT_SYMBOL(drm_gem_prime_import);
@@ -347,6 +350,9 @@ int drm_gem_prime_fd_to_handle(struct drm_device *dev,
goto fail;

mutex_unlock(_priv->prime.lock);
+
+   dma_buf_put(dma_buf);
+
return 0;

 fail:
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c 
b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
index ba0a3aa..ff7f2a8 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
@@ -235,7 +235,6 @@ struct drm_gem_object *exynos_dmabuf_prime_import(struct 
drm_device *drm_dev,
 * refcount on gem itself instead of f_count of dmabuf.
 */
drm_gem_object_reference(obj);
-   dma_buf_put(dma_buf);
return obj;
}
}
@@ -244,6 +243,7 @@ struct drm_gem_object *exynos_dmabuf_prime_import(struct 
drm_device *drm_dev,
if (IS_ERR(attach))
return ERR_PTR(-EINVAL);

+   get_dma_buf(dma_buf);

sgt = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL);
if (IS_ERR_OR_NULL(sgt)) {
@@ -298,6 +298,8 @@ err_unmap_attach:
dma_buf_unmap_attachment(attach, sgt, DMA_BIDIRECTIONAL);
 err_buf_detach:
dma_buf_detach(dma_buf, attach);
+   dma_buf_put(dma_buf);
+
return ERR_PTR(ret);
 }

diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c 
b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
index 6a5af68..c303de1 100644
--- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
@@ -271,7 +271,6 @@ struct drm_gem_object *i915_gem_prime_import(struct 
drm_device *dev,
 * refcount on gem itself instead of f_count of dmabuf.
 */
drm_gem_object_reference(>base);
-   dma_buf_put(dma_buf);
return >base;
}
}
@@ -281,6 +280,8 @@ struct drm_gem_object *i915_gem_prime_import(struct 
drm_device *dev,
if (IS_ERR(attach))
return ERR_CAST(attach);

+   get_dma_buf(dma_buf);
+
obj = i915_gem_object_alloc(dev);
if (obj == NULL) {
ret = -ENOMEM;
@@ -300,5 +301,7 @@ struct drm_gem_object *i915_gem_prime_import(struct 
drm_device *dev,

 fail_detach:
dma_buf_detach(dma_buf, attach);
+   dma_buf_put(dma_buf);
+
return ERR_PTR(ret);
 }
diff --git a/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c 
b/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
index ac74d1b..1bdf7e1 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
@@ -212,7 +212,6 @@ struct drm_gem_object *omap_gem_prime_import(struct 
drm_device *dev,
 * refcount on gem itself instead of f_count of dmabuf.
 */
drm_gem_object_reference(obj);
-   dma_buf_put(buffer);
return obj;
}
}
diff --git a/drivers/gpu/drm/udl/udl_gem.c b/drivers/gpu/drm/udl/udl_gem.c
index 3816270..ef034fa 100644
---

[PATCH 1/2] drm/prime: keep a reference from the handle to exported dma-buf (v5)

Currently we have a problem with this:
1. i915: create gem object
2. i915: export gem object to prime
3. radeon: import gem object
4. close prime fd
5. radeon: unref object
6. i915: unref object

i915 has an imported object reference in its file priv, that isn't
cleaned up properly until fd close. The reference gets added at step 2,
but at step 6 we don't have enough info to clean it up.

The solution is to take a reference on the dma-buf when we export it,
and drop the reference when the gem handle goes away.

So when we export a dma_buf from a gem object, we keep track of it
with the handle, we take a reference to the dma_buf. When we close
the handle (i.e. userspace is finished with the buffer), we drop
the reference to the dma_buf, and it gets collected.

This patch isn't meant to fix any other problem or bikesheds, and it doesn't
fix any races with other scenarios.

v1.1: move export symbol line back up.

v2: okay I had to do a bit more, as the first patch showed a leak
on one of my tests, that I found using the dma-buf debugfs support,
the problem case is exporting a buffer twice with the same handle,
we'd add another export handle for it unnecessarily, however
we now fail if we try to export the same object with a different gem handle,
however I'm not sure if that is a case I want to support, and I've
gotten the code to WARN_ON if we hit something like that.

v2.1: rebase this patch, write better commit msg.
v3: cleanup error handling, track import vs export in linked list,
these two patches were separate previously, but seem to work better
like this.
v4: danvet is correct, this code is no longer useful, since the buffer
better exist, so remove it.
v5: always take a reference to the dma buf object, import or export.
(Imre Deak contributed this originally)

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/drm_gem.c   |  4 +-
 drivers/gpu/drm/drm_prime.c | 93 -
 include/drm/drmP.h  |  4 +-
 3 files changed, 63 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index af779ae..cf919e3 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -205,11 +205,11 @@ static void
 drm_gem_remove_prime_handles(struct drm_gem_object *obj, struct drm_file *filp)
 {
if (obj->import_attach) {
-   drm_prime_remove_imported_buf_handle(>prime,
+   drm_prime_remove_buf_handle(>prime,
obj->import_attach->dmabuf);
}
if (obj->export_dma_buf) {
-   drm_prime_remove_imported_buf_handle(>prime,
+   drm_prime_remove_buf_handle(>prime,
obj->export_dma_buf);
}
 }
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 366910d..eb7c38d 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -57,10 +57,14 @@
  * use the drm_gem_prime_{import,export} helpers.
  */

+#define PRIME_IMPORT 1
+#define PRIME_EXPORT 2
+
 struct drm_prime_member {
struct list_head entry;
struct dma_buf *dma_buf;
uint32_t handle;
+   int type;
 };

 static struct sg_table *drm_gem_map_dma_buf(struct dma_buf_attachment *attach,
@@ -157,6 +161,8 @@ static const struct dma_buf_ops drm_gem_prime_dmabuf_ops =  
{
.vunmap = drm_gem_dmabuf_vunmap,
 };

+static int drm_prime_add_exported_buf_handle(struct drm_prime_file_private 
*prime_fpriv, struct dma_buf *dma_buf, uint32_t handle);
+
 /**
  * DOC: PRIME Helpers
  *
@@ -200,7 +206,8 @@ int drm_gem_prime_handle_to_fd(struct drm_device *dev,
 {
struct drm_gem_object *obj;
void *buf;
-   int ret;
+   int ret = 0;
+   struct dma_buf *dmabuf;

obj = drm_gem_object_lookup(dev, file_priv, handle);
if (!obj)
@@ -209,43 +216,44 @@ int drm_gem_prime_handle_to_fd(struct drm_device *dev,
mutex_lock(_priv->prime.lock);
/* re-export the original imported object */
if (obj->import_attach) {
-   get_dma_buf(obj->import_attach->dmabuf);
-   *prime_fd = dma_buf_fd(obj->import_attach->dmabuf, flags);
-   drm_gem_object_unreference_unlocked(obj);
-   mutex_unlock(_priv->prime.lock);
-   return 0;
+   dmabuf = obj->import_attach->dmabuf;
+   goto out_have_obj;
}

if (obj->export_dma_buf) {
-   get_dma_buf(obj->export_dma_buf);
-   *prime_fd = dma_buf_fd(obj->export_dma_buf, flags);
-   drm_gem_object_unreference_unlocked(obj);
-   } else {
-   buf = dev->driver->gem_prime_export(dev, obj, flags);
-   if (IS_ERR(buf)) {
-   /* normally the created dma-buf takes ownership of the 
ref,
-* but if that fails then drop the ref
-*/
-   drm_gem_object_unreference_unlocked(obj);
-

[PATCH] drm/prime: keep a reference from the handle to exported dma-buf (v4)

On Thu, Apr 18, 2013 at 2:16 AM, Imre Deak  wrote:
> On Wed, 2013-04-17 at 10:21 +0200, Daniel Vetter wrote:
>> On Wed, Apr 17, 2013 at 02:38:02PM +1000, Dave Airlie wrote:
>> > Currently we have a problem with this:
>> > 1. i915: create gem object
>> > 2. i915: export gem object to prime
>> > 3. radeon: import gem object
>> > 4. close prime fd
>> > 5. radeon: unref object
>> > 6. i915: unref object
>> >
>> > i915 has an imported object reference in its file priv, that isn't
>> > cleaned up properly until fd close. The reference gets added at step 2,
>> > but at step 6 we don't have enough info to clean it up.
>> >
>> > The solution is to take a reference on the dma-buf when we export it,
>> > and drop the reference when the gem handle goes away.
>> >
>> > So when we export a dma_buf from a gem object, we keep track of it
>> > with the handle, we take a reference to the dma_buf. When we close
>> > the handle (i.e. userspace is finished with the buffer), we drop
>> > the reference to the dma_buf, and it gets collected.
>> >
>> > This patch isn't meant to fix any other problem or bikesheds, and it 
>> > doesn't
>> > fix any races with other scenarios.
>> >
>> > v1.1: move export symbol line back up.
>> >
>> > v2: okay I had to do a bit more, as the first patch showed a leak
>> > on one of my tests, that I found using the dma-buf debugfs support,
>> > the problem case is exporting a buffer twice with the same handle,
>> > we'd add another export handle for it unnecessarily, however
>> > we now fail if we try to export the same object with a different gem 
>> > handle,
>> > however I'm not sure if that is a case I want to support, and I've
>> > gotten the code to WARN_ON if we hit something like that.
>> >
>> > v2.1: rebase this patch, write better commit msg.
>> > v3: cleanup error handling, track import vs export in linked list,
>> > these two patches were separate previously, but seem to work better
>> > like this.
>> > v4: danvet is correct, this code is no longer useful, since the buffer
>> > better exist, so remove it.
>> >
>> > Signed-off-by: Dave Airlie 
>>
>> Reviewed-by: Daniel Vetter 
>>
>> On bikeshed review level I wonder whether we shouldn't just grab a
>> reference unconditonally when inserting it into the handle_to_fd lookup
>> lists. But I need to think through a few other cases and apparently the
>> self-import test is still a bit broken. So this is material for follow-up
>> patches.
>
> Yes, this is needed, otherwise closing the prime fd will leave stale
> pointers to the dma buf in the importer's lookup table. I've sent an
> update to igt/prime_self_test to intel-gfx for showing this.
>

Okay I've spent time on this today and yes I agree, so I'll post v5 of my patch
with that in it.

I'd like to also merge your other patch, it seems fine.

Dave.

[PATCH 3/3] drm/i915: Relax the sprite scaling limits checks

2013-04-19 Thread ville.syrj...@linux.intel.com

From: Ville Syrj?l? 

Reduce the size of the the src/dst viewport to keep the scalign ratios
in check.

Also treat sprites below the minimum size as invisble.

Signed-off-by: Ville Syrj?l? 
---
 drivers/gpu/drm/i915/intel_sprite.c | 60 -
 1 file changed, 32 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index 93a6657..c3a5688 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -679,26 +679,19 @@ intel_update_plane(struct drm_plane *plane, struct 
drm_crtc *crtc,
return -EINVAL;
}

+   /*
+* FIXME the following code does a bunch of fuzzy adjustments to the
+* coordinates and sizes. We probably need some way to decide whether
+* more strict checking should be done instead.
+*/
max_scale = intel_plane->max_downscale << 16;
min_scale = intel_plane->can_scale ? 1 : (1 << 16);

-   hscale = drm_rect_calc_hscale(, , min_scale, max_scale);
-   if (hscale < 0) {
-   DRM_DEBUG_KMS("Horizontal scaling factor out of limits\n");
-   drm_rect_debug_print(, true);
-   drm_rect_debug_print(, false);
+   hscale = drm_rect_calc_hscale_relaxed(, , min_scale, max_scale);
+   BUG_ON(hscale < 0);

-   return hscale;
-   }
-
-   vscale = drm_rect_calc_vscale(, , min_scale, max_scale);
-   if (vscale < 0) {
-   DRM_DEBUG_KMS("Vertical scaling factor out of limits\n");
-   drm_rect_debug_print(, true);
-   drm_rect_debug_print(, false);
-
-   return vscale;
-   }
+   vscale = drm_rect_calc_vscale_relaxed(, , min_scale, max_scale);
+   BUG_ON(vscale < 0);

visible = drm_rect_clip_scaled(, , , hscale, vscale);

@@ -708,6 +701,25 @@ intel_update_plane(struct drm_plane *plane, struct 
drm_crtc *crtc,
crtc_h = drm_rect_height();

if (visible) {
+   /* check again in case clipping clamped the results */
+   hscale = drm_rect_calc_hscale(, , min_scale, max_scale);
+   if (hscale < 0) {
+   DRM_DEBUG_KMS("Horizontal scaling factor out of 
limits\n");
+   drm_rect_debug_print(, true);
+   drm_rect_debug_print(, false);
+
+   return hscale;
+   }
+
+   vscale = drm_rect_calc_vscale(, , min_scale, max_scale);
+   if (vscale < 0) {
+   DRM_DEBUG_KMS("Vertical scaling factor out of 
limits\n");
+   drm_rect_debug_print(, true);
+   drm_rect_debug_print(, false);
+
+   return vscale;
+   }
+
/* Make the source viewport size an exact multiple of the 
scaling factors. */
drm_rect_adjust_size(,
 drm_rect_width() * hscale - 
drm_rect_width(),
@@ -718,10 +730,6 @@ intel_update_plane(struct drm_plane *plane, struct 
drm_crtc *crtc,
 * Adjust to (macro)pixel boundary, but be careful not to
 * increase the source viewport size, because that could
 * push the downscaling factor out of bounds.
-*
-* FIXME Should we be really strict and reject the
-* config if it results in non (macro)pixel aligned
-* coords?
 */
src_x = src.x1 >> 16;
src_w = drm_rect_width() >> 16;
@@ -752,15 +760,11 @@ intel_update_plane(struct drm_plane *plane, struct 
drm_crtc *crtc,

/* FIXME interlacing min height is 6 */

-   if (crtc_w < 3 || crtc_h < 3) {
-   DRM_DEBUG_KMS("Destination dimensions too small\n");
-   return -EINVAL;
-   }
+   if (crtc_w < 3 || crtc_h < 3)
+   visible = false;

-   if (src_w < 3 || src_h < 3) {
-   DRM_DEBUG_KMS("Source dimensions too small\n");
-   return -EINVAL;
-   }
+   if (src_w < 3 || src_h < 3)
+   visible = false;

width_bytes = ((src_x * pixel_size) & 63) + src_w * pixel_size;

-- 
1.8.1.5

[PATCH v4 2/3] drm/i915: Implement proper clipping for video sprites

2013-04-19 Thread ville.syrj...@linux.intel.com

From: Ville Syrj?l? 

Properly clip the source when the destination gets clipped
by the pipe dimensions.

Sadly the video sprite hardware is rather limited so it can't do proper
sub-pixel postitioning. Resort to truncating the source coordinates to
(macro)pixel boundary.

The scaling checks are done using the strict drm_region functions.
Which means that an error is returned when the min/max scaling
ratios are exceeded.

Also do some additional checking against various hardware limits.

v2: Truncate src coords instead of rounding to avoid increasing src
viewport size, and adapt to changes in drm_calc_{h,v}scale().
v3: Adapt to drm_region->drm_rect rename. Fix misaligned crtc_w for
packed YUV formats when scaling isn't supported.
v4: Use stricter scaling checks, use drm_rect_equals()

Signed-off-by: Ville Syrj?l? 
---
 drivers/gpu/drm/i915/intel_sprite.c | 202 ++--
 1 file changed, 150 insertions(+), 52 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index c7d25c5..93a6657 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "intel_drv.h"
 #include 
 #include "i915_drv.h"
@@ -583,6 +584,20 @@ ilk_get_colorkey(struct drm_plane *plane, struct 
drm_intel_sprite_colorkey *key)
key->flags = I915_SET_COLORKEY_NONE;
 }

+static bool
+format_is_yuv(uint32_t format)
+{
+   switch (format) {
+   case DRM_FORMAT_YUYV:
+   case DRM_FORMAT_UYVY:
+   case DRM_FORMAT_VYUY:
+   case DRM_FORMAT_YVYU:
+   return true;
+   default:
+   return false;
+   }
+}
+
 static int
 intel_update_plane(struct drm_plane *plane, struct drm_crtc *crtc,
   struct drm_framebuffer *fb, int crtc_x, int crtc_y,
@@ -600,9 +615,27 @@ intel_update_plane(struct drm_plane *plane, struct 
drm_crtc *crtc,
enum transcoder cpu_transcoder = intel_pipe_to_cpu_transcoder(dev_priv,
  pipe);
int ret = 0;
-   int x = src_x >> 16, y = src_y >> 16;
-   int primary_w = crtc->mode.hdisplay, primary_h = crtc->mode.vdisplay;
bool disable_primary = false;
+   bool visible;
+   int hscale, vscale;
+   int max_scale, min_scale;
+   int pixel_size = drm_format_plane_cpp(fb->pixel_format, 0);
+   struct drm_rect src = {
+   .x1 = src_x,
+   .x2 = src_x + src_w,
+   .y1 = src_y,
+   .y2 = src_y + src_h,
+   };
+   struct drm_rect dst = {
+   .x1 = crtc_x,
+   .x2 = crtc_x + crtc_w,
+   .y1 = crtc_y,
+   .y2 = crtc_y + crtc_h,
+   };
+   const struct drm_rect clip = {
+   .x2 = crtc->mode.hdisplay,
+   .y2 = crtc->mode.vdisplay,
+   };

intel_fb = to_intel_framebuffer(fb);
obj = intel_fb->obj;
@@ -618,19 +651,23 @@ intel_update_plane(struct drm_plane *plane, struct 
drm_crtc *crtc,
intel_plane->src_w = src_w;
intel_plane->src_h = src_h;

-   src_w = src_w >> 16;
-   src_h = src_h >> 16;
-
/* Pipe must be running... */
-   if (!(I915_READ(PIPECONF(cpu_transcoder)) & PIPECONF_ENABLE))
-   return -EINVAL;
-
-   if (crtc_x >= primary_w || crtc_y >= primary_h)
+   if (!(I915_READ(PIPECONF(cpu_transcoder)) & PIPECONF_ENABLE)) {
+   DRM_DEBUG_KMS("Pipe disabled\n");
return -EINVAL;
+   }

/* Don't modify another pipe's plane */
-   if (intel_plane->pipe != intel_crtc->pipe)
+   if (intel_plane->pipe != intel_crtc->pipe) {
+   DRM_DEBUG_KMS("Wrong plane <-> crtc mapping\n");
return -EINVAL;
+   }
+
+   /* FIXME check all gen limits */
+   if (fb->width < 3 || fb->height < 3 || fb->pitches[0] > 16384) {
+   DRM_DEBUG_KMS("Unsuitable framebuffer for plane\n");
+   return -EINVAL;
+   }

/* Sprite planes can be linear or x-tiled surfaces */
switch (obj->tiling_mode) {
@@ -638,55 +675,113 @@ intel_update_plane(struct drm_plane *plane, struct 
drm_crtc *crtc,
case I915_TILING_X:
break;
default:
+   DRM_DEBUG_KMS("Unsupported tiling mode\n");
return -EINVAL;
}

-   /*
-* Clamp the width & height into the visible area.  Note we don't
-* try to scale the source if part of the visible region is offscreen.
-* The caller must handle that by adjusting source offset and size.
-*/
-   if ((crtc_x < 0) && ((crtc_x + crtc_w) > 0)) {
-   crtc_w += crtc_x;
-   crtc_x = 0;
+   max_scale = intel_plane->max_downscale << 16;
+   min_scale =

[PATCH 1/3] drm: Add drm_rect_equals()

2013-04-19 Thread ville.syrj...@linux.intel.com

From: Ville Syrj?l? 

drm_rect_equals() tells whether two drm_rects are equal.

Signed-off-by: Ville Syrj?l? 
---
 include/drm/drm_rect.h | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/include/drm/drm_rect.h b/include/drm/drm_rect.h
index fe767b7..64fa265 100644
--- a/include/drm/drm_rect.h
+++ b/include/drm/drm_rect.h
@@ -124,6 +124,21 @@ static inline bool drm_rect_visible(const struct drm_rect 
*r)
return drm_rect_width(r) > 0 && drm_rect_height(r) > 0;
 }

+/**
+ * drm_rect_equals - determine if two rectangles are equal
+ * @r1: first rectangle
+ * @r2: second rectangle
+ *
+ * RETURNS:
+ * %true if the rectangles are equal, %false otherwise.
+ */
+static inline bool drm_rect_equals(const struct drm_rect *r1,
+  const struct drm_rect *r2)
+{
+   return r1->x1 == r2->x1 && r1->x2 == r2->x2 &&
+   r1->y1 == r2->y1 && r1->y2 == r2->y2;
+}
+
 bool drm_rect_intersect(struct drm_rect *r, const struct drm_rect *clip);
 bool drm_rect_clip_scaled(struct drm_rect *src, struct drm_rect *dst,
  const struct drm_rect *clip,
-- 
1.8.1.5

[DVO][PATCH] drm/i915: Fall back to bit banging mode for DVO transmitter detection

2013-04-19 Thread "David Müller (ELSOFT AG)"

Hello

As discussed in this thread
http://lists.freedesktop.org/archives/dri-devel/2013-April/037411.html
GMBUS based DVO transmitter detection seems to be unreliable which could
result in an unusable DVO port.

The attached patch fixes this by falling back to bit banging mode for
the time DVO transmitter detection is in progress.

-- next part --
Signed-off-by: David M?ller 
Tested-by: David M?ller 

---
diff -dpurN a/drivers/gpu/drm/i915/intel_dvo.c 
b/drivers/gpu/drm/i915/intel_dvo.c
--- a/drivers/gpu/drm/i915/intel_dvo.c  2012-12-11 10:09:35.113446850 +0100
+++ b/drivers/gpu/drm/i915/intel_dvo.c  2013-04-19 07:21:54.054546365 +0200
@@ -449,6 +449,7 @@ void intel_dvo_init(struct drm_device *d
const struct intel_dvo_device *dvo = _dvo_devices[i];
struct i2c_adapter *i2c;
int gpio;
+   bool dvoinit;

/* Allow the I2C driver info to specify the GPIO to be used in
 * special cases, but otherwise default to what's defined
@@ -468,7 +469,17 @@ void intel_dvo_init(struct drm_device *d
i2c = intel_gmbus_get_adapter(dev_priv, gpio);

intel_dvo->dev = *dvo;
-   if (!dvo->dev_ops->init(_dvo->dev, i2c))
+
+   /* GMBUS NAK handling seems to be unstable, hence let the
+* transmitter detection run in bit banging mode for now.
+*/
+   intel_gmbus_force_bit(i2c, true);
+
+   dvoinit = dvo->dev_ops->init(_dvo->dev, i2c);
+
+   intel_gmbus_force_bit(i2c, false);
+
+   if (!dvoinit)
continue;

intel_encoder->type = INTEL_OUTPUT_DVO;

Standalone DRM application

2013-04-19 Thread Byron Stanoszek

On Thu, 18 Apr 2013, David Herrmann wrote:

> You can acquire/drop DRM-Master via drmSetMaster/drmDropMaster.
>
> If your DRM card is a PCI device, you can use the sysfs "boot_vga"
> attribute of the parent PCI device.
> (/sys/class/drm/card0/device/boot_vga)

David,

Thanks! That was exactly what I was looking for. Both ideas work wonderfully.

Regards,
  -Byron

3.9.0-rc7-next: i915: render error detected

2013-04-19 Thread Chris Wilson

On Fri, Apr 19, 2013 at 11:16:36AM +0200, Jiri Slaby wrote:
> Hi, with today's -next I got this:
> 
> [drm] capturing error event; look for more information in
> /sys/kernel/debug/dri/0/i915_error_state
> i915: render error detected, EIR: 0x0010
> i915: page table error
> i915:   PGTBL_ER: 0x0002
> [drm:i915_report_and_clear_eir] *ERROR* EIR stuck: 0x0010, masking
> i915: render error detected, EIR: 0x0010
> i915: page table error
> i915:   PGTBL_ER: 0x0002

These feel like they are becoming more common, though we have had
reports of this style of error since the dawn of time. The error means
that the CPU accessed an invalid PTE - so the most likely a missing mb
or chipset flush.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[patch] drm: add a couple __user annotations

2013-04-19 Thread Dan Carpenter

"list" and "request" are already declared as __user pointers, it's just
this cast which is missing the annotation.

Signed-off-by: Dan Carpenter 
---
Sparse doesn't complain about this because it hits the "error: bad
integer constant expression" and stops printing warnings.

diff --git a/drivers/gpu/drm/drm_ioc32.c b/drivers/gpu/drm/drm_ioc32.c
index 2f4c434..764794b 100644
--- a/drivers/gpu/drm/drm_ioc32.c
+++ b/drivers/gpu/drm/drm_ioc32.c
@@ -457,7 +457,7 @@ static int compat_drm_infobufs(struct file *file, unsigned 
int cmd,
request = compat_alloc_user_space(nbytes);
if (!access_ok(VERIFY_WRITE, request, nbytes))
return -EFAULT;
-   list = (struct drm_buf_desc *) (request + 1);
+   list = (struct drm_buf_desc __user *) (request + 1);

if (__put_user(count, >count)
|| __put_user(list, >list))
@@ -518,7 +518,7 @@ static int compat_drm_mapbufs(struct file *file, unsigned 
int cmd,
request = compat_alloc_user_space(nbytes);
if (!access_ok(VERIFY_WRITE, request, nbytes))
return -EFAULT;
-   list = (struct drm_buf_pub *) (request + 1);
+   list = (struct drm_buf_pub __user *) (request + 1);

if (__put_user(count, >count)
|| __put_user(list, >list))

[PATCH 2/3] drm/radeon: clean up audio dto programming

On Fri, Apr 19, 2013 at 2:10 AM, Rafa? Mi?ecki  wrote:
> 2013/4/18  :
>> -   switch (radeon_encoder->encoder_id) {
>> -   case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_TMDS1:
>> -   case ENCODER_OBJECT_ID_INTERNAL_LVTM1:
>> -   WREG32_P(R600_AUDIO_TIMING, 0, ~0x301);
>> -   break;
>> -   case ENCODER_OBJECT_ID_INTERNAL_UNIPHY:
>> -   case ENCODER_OBJECT_ID_INTERNAL_UNIPHY1:
>> -   case ENCODER_OBJECT_ID_INTERNAL_UNIPHY2:
>> -   case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_LVTMA:
>> -   WREG32_P(R600_AUDIO_TIMING, 0x100, ~0x301);
>> -   break;
>> -   default:
>> -   dev_err(rdev->dev, "Unsupported encoder type 0x%02X\n",
>> - radeon_encoder->encoder_id);
>> -   return;
>> -   }
>
> Are you sure we can just drop that part?

Yes we should be able to drop that part.  The only relevant bits are
9:8 which allows you to force which DTO is used by the audio block.  0
= auto, 1 = force dto0, 2 = force dto1.  Additionally, that register
doesn't exist on evergreen and newer.  On evergreen and newer there is
a DIG PHY register at the same offset which may explain the display
problems some people are experiencing.

>
> I'd appreciate waiting with this patch until next week, I'll test it
> over the weekend on my RV620.

Sounds good.

Alex

[Bug 63714] New: UVD acceleration does not properly detect kernel support

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

  Priority: medium
Bug ID: 63714
  Assignee: dri-devel at lists.freedesktop.org
   Summary: UVD acceleration does not properly detect kernel
support
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: ryszardzonk at yahoo.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: git
 Component: Drivers/Gallium/r600
   Product: Mesa

Created attachment 78220
  --> https://bugs.freedesktop.org/attachment.cgi?id=78220=edit
udv_fix.patch

Hardware: AMD E-350
00:01.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI
Wrestler [Radeon HD 6310]

1)Kernel 3.9.0-rc7 + uvd v3 patches  (Gentoo self compiled)
2)Libdrm-2.4.44
3)Mesa master git: e87015f5089a2c4a99e0288e1adeeabb5a7ca7e3
4)Xorg-server-1.13.4
5)ddx: xf86-video-ati git: 6e74aacc5e5da3b51744153dad1645caa6ea4ce3

I have been able to use UVD acceleration when it first appeared using mesa v2
of UVD code, but from the time it has been introduced in the mesa mainline with
v5 it does not work anymore. I believe it has to do with mesa not properly
detecting kernel support "[1.638460] [drm] UVD initialized successfully."
and reverting to the vdpau support in shaders. Could it be that it requires
some kernel option I am missing?

As I have been trying to find exact reason I revered some changes that has been
introduced in mesa after v2 and it works again. I am not sure if all of those
are needed or which change in particular by itself would be enough but any way
it gets it working again so it is in there somewhere

-- 
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/20130419/2745e641/attachment-0001.html>

[Bug 61182] r600g causes KWin crashes with kernel 3.8

/kapplication.cpp:311
#37 0x00399df77abe in QCoreApplication::notifyInternal
(this=0x7fff5779a3f0, receiver=receiver at entry=0x1edf240,
event=event at entry=0x7f59a4001770) at kernel/qcoreapplication.cpp:946
#38 0x00399df7b571 in sendEvent (event=0x7f59a4001770, receiver=0x1edf240)
at kernel/qcoreapplication.h:231
#39 QCoreApplicationPrivate::sendPostedEvents (receiver=0x0, event_type=0,
data=0x1ce1360) at kernel/qcoreapplication.cpp:1570
#40 0x003043a6b3bc in sendPostedEvents () at
../../src/corelib/kernel/qcoreapplication.h:236
#41 QEventDispatcherX11::processEvents (this=0x1ce2cc0, flags=...) at
kernel/qeventdispatcher_x11.cpp:75
#42 0x00399df7680f in QEventLoop::processEvents
(this=this at entry=0x7fff5779a100, flags=...) at kernel/qeventloop.cpp:149
#43 0x00399df76a98 in QEventLoop::exec (this=0x7fff5779a100, flags=...) at
kernel/qeventloop.cpp:204
#44 0x00399df7b888 in QCoreApplication::exec () at
kernel/qcoreapplication.cpp:1218
#45 0x00304ba67d6a in kdemain (argc=1, argv=0x7fff5779a538) at
/usr/src/debug/kde-workspace-4.10.1/kwin/main.cpp:537
#46 0x003994c21a05 in __libc_start_main (main=0x400960 <main(int, char**)>,
argc=1, ubp_av=0x7fff5779a538, init=, fini=,
rtld_fini=, stack_end=0x7fff5779a528) at libc-start.c:225
#47 0x00400991 in _start ()

-- 
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/20130419/6bbf5380/attachment.html>

[PATCH 1/2] drm/prime: keep a reference from the handle to exported dma-buf (v5)

2013-04-19 Thread Imre Deak

On Fri, 2013-04-19 at 11:11 +1000, Dave Airlie wrote:
> Currently we have a problem with this:
> 1. i915: create gem object
> 2. i915: export gem object to prime
> 3. radeon: import gem object
> 4. close prime fd
> 5. radeon: unref object
> 6. i915: unref object
> 
> i915 has an imported object reference in its file priv, that isn't
> cleaned up properly until fd close. The reference gets added at step 2,
> but at step 6 we don't have enough info to clean it up.
> 
> The solution is to take a reference on the dma-buf when we export it,
> and drop the reference when the gem handle goes away.
> 
> So when we export a dma_buf from a gem object, we keep track of it
> with the handle, we take a reference to the dma_buf. When we close
> the handle (i.e. userspace is finished with the buffer), we drop
> the reference to the dma_buf, and it gets collected.
> 
> This patch isn't meant to fix any other problem or bikesheds, and it doesn't
> fix any races with other scenarios.
> 
> v1.1: move export symbol line back up.
> 
> v2: okay I had to do a bit more, as the first patch showed a leak
> on one of my tests, that I found using the dma-buf debugfs support,
> the problem case is exporting a buffer twice with the same handle,
> we'd add another export handle for it unnecessarily, however
> we now fail if we try to export the same object with a different gem handle,
> however I'm not sure if that is a case I want to support, and I've
> gotten the code to WARN_ON if we hit something like that.
> 
> v2.1: rebase this patch, write better commit msg.
> v3: cleanup error handling, track import vs export in linked list,
> these two patches were separate previously, but seem to work better
> like this.
> v4: danvet is correct, this code is no longer useful, since the buffer
> better exist, so remove it.
> v5: always take a reference to the dma buf object, import or export.
> (Imre Deak contributed this originally)
> 
> Signed-off-by: Dave Airlie 

drm_prime_destroy_file_private() lacks a drm_buf_put(). A separate
issue, but the list should actually be empty at that point so perhaps we
should warn if it's not.

bikeshed: we don't really need the PRIME_{EXPORT,IMPORT} tracking.

Otherwise looks ok:
Reviewed-by: Imre Deak 

> ---
>  drivers/gpu/drm/drm_gem.c   |  4 +-
>  drivers/gpu/drm/drm_prime.c | 93 
> -
>  include/drm/drmP.h  |  4 +-
>  3 files changed, 63 insertions(+), 38 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index af779ae..cf919e3 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -205,11 +205,11 @@ static void
>  drm_gem_remove_prime_handles(struct drm_gem_object *obj, struct drm_file 
> *filp)
>  {
>   if (obj->import_attach) {
> - drm_prime_remove_imported_buf_handle(>prime,
> + drm_prime_remove_buf_handle(>prime,
>   obj->import_attach->dmabuf);
>   }
>   if (obj->export_dma_buf) {
> - drm_prime_remove_imported_buf_handle(>prime,
> + drm_prime_remove_buf_handle(>prime,
>   obj->export_dma_buf);
>   }
>  }
> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> index 366910d..eb7c38d 100644
> --- a/drivers/gpu/drm/drm_prime.c
> +++ b/drivers/gpu/drm/drm_prime.c
> @@ -57,10 +57,14 @@
>   * use the drm_gem_prime_{import,export} helpers.
>   */
>  
> +#define PRIME_IMPORT 1
> +#define PRIME_EXPORT 2
> +
>  struct drm_prime_member {
>   struct list_head entry;
>   struct dma_buf *dma_buf;
>   uint32_t handle;
> + int type;
>  };
>  
>  static struct sg_table *drm_gem_map_dma_buf(struct dma_buf_attachment 
> *attach,
> @@ -157,6 +161,8 @@ static const struct dma_buf_ops drm_gem_prime_dmabuf_ops 
> =  {
>   .vunmap = drm_gem_dmabuf_vunmap,
>  };
>  
> +static int drm_prime_add_exported_buf_handle(struct drm_prime_file_private 
> *prime_fpriv, struct dma_buf *dma_buf, uint32_t handle);
> +
>  /**
>   * DOC: PRIME Helpers
>   *
> @@ -200,7 +206,8 @@ int drm_gem_prime_handle_to_fd(struct drm_device *dev,
>  {
>   struct drm_gem_object *obj;
>   void *buf;
> - int ret;
> + int ret = 0;
> + struct dma_buf *dmabuf;
>  
>   obj = drm_gem_object_lookup(dev, file_priv, handle);
>   if (!obj)
> @@ -209,43 +216,44 @@ int drm_gem_prime_handle_to_fd(struct drm_device *dev,
>   mutex_lock(_priv->prime.lock);
>   /* re-export the original imported object */
>   if (obj->import_attach) {
> - get_dma_buf(obj->import_attach->dmabuf);
> - *prime_fd = dma_buf_fd(obj->import_attach->dmabuf, flags);
> - drm_gem_object_unreference_unlocked(obj);
> - mutex_unlock(_priv->prime.lock);
> - return 0;
> + dmabuf = obj->import_attach->dmabuf;
> + goto out_have_obj;
>   }
>  
>   if (obj->export_dma_buf) {
> -

UVD status on loongson 3a platform

On Fri, Apr 19, 2013 at 4:51 AM, Chen Jie  wrote:
> Hi all,
>
> Recently, the uvd supporting is released, and we've tried it on
> loongson 3a platform.
> Brief introduction about loongson 3a, it's a MIPS III compatible, 4
> cores processor.
>
> More details about the platform [1]:
> * The Board: RS780E + SB710 chipset, with an AMD radeon HD6570 video card
> * The kernel is 64bits(n64 ABI), and the userland is 32bits(o32 ABI)
> * OS: LOonux 3.3.6 [2] + LTP-uvd-installer-20130419.bin [3]
> ** kernel: 3.9 + uvd related patches
> ** mesa: git master version (d0e9aa)
>
> We tried three video samples:
> * big_buck_bunny_1080p_h264.mov
> (http://mirrorblender.top-ix.org/peach/bigbuckbunny_movies/big_buck_bunny_1080p_h264.mov)
> * Sintel.2010.2K.x264-VODO.mp4
> (http://dev.lemote.com/files/upload/software/UVD-debug/Sintel.2010.2K.x264-VODO.mp4)
> * test.avi (http://dev.lemote.com/files/upload/software/UVD-debug/test.avi)
>
> For big_buck_bunny_1080p_h264.mov, the playback is not very fluent at
> the beginning, and it has some video mosaic. We've recorded a video
> for it, see 
> http://dev.lemote.com/files/upload/software/UVD-debug/bbb-1080P.mp4
> For video mosaic, what could it be caused by?
>
> For Sintel.2010.2K.x264-VODO.mp4, it has a very long wait for the first frame.
> We've also recorded a video for it, see
> http://dev.lemote.com/files/upload/software/UVD-debug/sintel.2K.mp4
> Any idea about the long wait for the first frame?
>
> For test.avi(video: ITU H.264, 1920x1080), it's playing back
> perfectly! Thanks for the effort on UVD!
>
> In all of these tests, the CPU usage is around 50%, and all three
> video samples play well on X86 platform with the same video card.
>
> BTW, 785G also has UVD2.0, is it supported currently? Or will it be
> supported in the near future?

Early UVD 2 chips like RS780/880 and RV770 are not yet supported due
to differences in the UVD hardware compared to later generations.  We
are currently looking into supporting UVD on those chips in open
source, but nothing is available yet.

Alex

[PATCH 1/3] drm/radeon: clean up audio supported check

2013/4/18  :
> From: Alex Deucher 
>
> Signed-off-by: Alex Deucher 
> ---
>  drivers/gpu/drm/radeon/r600_audio.c |5 +
>  1 files changed, 1 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/r600_audio.c 
> b/drivers/gpu/drm/radeon/r600_audio.c
> index cb03fe2..72561e4 100644
> --- a/drivers/gpu/drm/radeon/r600_audio.c
> +++ b/drivers/gpu/drm/radeon/r600_audio.c
> @@ -57,10 +57,7 @@ static bool radeon_dig_encoder(struct drm_encoder *encoder)
>   */
>  static int r600_audio_chipset_supported(struct radeon_device *rdev)
>  {
> -   return (rdev->family >= CHIP_R600 && !ASIC_IS_DCE6(rdev))
> -   || rdev->family == CHIP_RS600
> -   || rdev->family == CHIP_RS690
> -   || rdev->family == CHIP_RS740;
> +   return ASIC_IS_DCE2(rdev) && !ASIC_IS_DCE6(rdev);
>  }
>
>  struct r600_audio r600_audio_status(struct radeon_device *rdev)

Looks fine :)

-- 
Rafa?

[PATCH 2/3] drm/radeon: clean up audio dto programming

2013/4/18  :
> -   switch (radeon_encoder->encoder_id) {
> -   case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_TMDS1:
> -   case ENCODER_OBJECT_ID_INTERNAL_LVTM1:
> -   WREG32_P(R600_AUDIO_TIMING, 0, ~0x301);
> -   break;
> -   case ENCODER_OBJECT_ID_INTERNAL_UNIPHY:
> -   case ENCODER_OBJECT_ID_INTERNAL_UNIPHY1:
> -   case ENCODER_OBJECT_ID_INTERNAL_UNIPHY2:
> -   case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_LVTMA:
> -   WREG32_P(R600_AUDIO_TIMING, 0x100, ~0x301);
> -   break;
> -   default:
> -   dev_err(rdev->dev, "Unsupported encoder type 0x%02X\n",
> - radeon_encoder->encoder_id);
> -   return;
> -   }

Are you sure we can just drop that part?

I'd appreciate waiting with this patch until next week, I'll test it
over the weekend on my RV620.

-- 
Rafa?

[Bug 63709] New: Desktop Effects on 3D desktop environments are jerky/stutter.

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

Priority: medium
Bug ID: 63709
Assignee: dri-devel at lists.freedesktop.org
Summary: Desktop Effects on 3D desktop environments are
jerky/stutter.
Severity: critical
Classification: Unclassified
OS: Linux (All)
Reporter: equites.vero at gmail.com
Hardware: x86-64 (AMD64)
Status: NEW
Version: unspecified
Component: DRM/Radeon
Product: DRI

Hardware: Gigabyte GA-880GM-d2h, Radeon HD4250 512 shared VRAM, 4GB RAM total,
Phenom x4 965BE (3.4Ghz quad). Everything at stock clock speed and voltages.
BIOS flashed to latest stable version FF from Gigabyte.

user at user-GA-880GM-D2H:~$ glxinfo | grep OpenGL
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD RS880
OpenGL version string: 3.0 Mesa 9.1.1
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
user at user-GA-880GM-D2H:~$ glxinfo | grep render
direct rendering: Yes
OpenGL renderer string: Gallium 0.4 on AMD RS880
GL_NV_conditional_render, GL_AMD_conservative_depth,

In a default KDE install on Ubuntu: Default settings are Use OpenGL 2 shaders
enabled and VSync enabled. In Desktop effects such as translucent background
when dragging windows and Minimize Animation, dragging a window results in
stuttering movement in the former (the screen does not shift. but the window
stutters as if it stops for a second and catches up but it's fast so it looks
like a stutter [missing frames?]) and in Minimize animation the window stutters
also as the animation takes place. Disabling VSync and OpenGL 2 shaders
options, there is still stuttering animation. This seems to be OpenGL specific
as XRender compositing provides a smooth experience.

In a Gnome Shell 3.8 install: In previous versions of Gnome Shell, there were
jerky animations also. In 3.8, which is what is installed on my computer right
now in Ubuntu 13.04, the animations are not ALWAYS noticeably jerky, but
sometimes they do jerk when happening, it's noticeable in the animation when
switching to a new window from the overview and the window slides in front of
the desktop. It does not always jerk but often enough. In glxgears I get 58/59
fps normally, and with glxgears window maximized, it still gives the same frame
rate. But when switching between three or four windows, there's a jerk in the
animation and it shows up in glxgears as a drop in the fps and it goes down to
50-51 fps and is unable to keep up with the refresh rate. Also, in glxgears, I
have noticed that the gears move smoothly but after maximizing them, they run
smoothly for some seconds, and then I notice a jerk/stutter in the gears once,
and then it runs smoothly again. In Gnome Shell, you will probably not notice
the jerks when you first use it, but it's definitely there and is an annoyance
for someone who uses it a long time. And the stuttering animations are
definitely very noticeable on KDE in a default install with desktop effects.

This is all with no custom Xorg conf. With swbuffersWait 0 in Xorg conf, the
stuttering is even more noticeable as ever in Gnome, it seems to me.

This seems to be a driver bug (correct me if I'm wrong, I'm a relative newbie
to Linux.), so I'm posting this report here. But this is a major problem that
needs to be fixed soon. What user wants to use Linux when the major desktops
run with jerky effects.

--
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/20130419/a9e02cdb/attachment.html>

[Bug 63701] [HSW] intel VGA driver i915 doesn't support new haswell graphics [8086:0a2e] Core i5-4258U（5100, GT3）

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

--- Comment #2 from Ben Widawsky  ---
That PCI ID is new to me, and I cannot find details about the actual part so I
am hesitant to write a real patch. Paulo have you seen that one? 

Since very limited people have access to HSW hardware at this point, you should
be working through Intel or whatever vendor provided the HW to you for the
proper fix. Also, as far as I can tell, the Haswell model you specify doesn't
exist in any official Intel documentation. For that reason, I would again
recommend you through whichever vendor provided the hardware to you (and close
this bug)

With all that disclaimer above... If you'd like to fix it yourself, patches are
welcome. In drivers/gpu/drm/i915/i915_drv.c, copy one and modify with your PCI
ID.

INTEL_VGA_DEVICE(0x0D02, _haswell_d_info), /* CRW GT1 desktop */
INTEL_VGA_DEVICE(0x0D12, _haswell_d_info), /* CRW GT2 desktop */
INTEL_VGA_DEVICE(0x0D22, _haswell_d_info), /* CRW GT2 desktop */
INTEL_VGA_DEVICE(0x0D0A, _haswell_d_info), /* CRW GT1 server */
INTEL_VGA_DEVICE(0x0D1A, _haswell_d_info), /* CRW GT2 server */
INTEL_VGA_DEVICE(0x0D2A, _haswell_d_info), /* CRW GT2 server */
INTEL_VGA_DEVICE(0x0D06, _haswell_m_info), /* CRW GT1 mobile */
INTEL_VGA_DEVICE(0x0D16, _haswell_m_info), /* CRW GT2 mobile */
INTEL_VGA_DEVICE(0x0D26, _haswell_m_info), /* CRW GT2 mobile */


Keep in mind, just about every graphics component which needs PCI ids will have
the same 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/20130419/60af9d7e/attachment.html>

[Bug 63702] tiling2d in radeon trash vdpau UVD textures

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

Alex Deucher  changed:

   What|Removed |Added

  Attachment #78204|text/plain  |image/png
  mime type||

-- 
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/20130419/6bf83416/attachment.html>

[Bug 63701] [HSW] intel VGA driver i915 doesn't support new haswell graphics [8086:0a2e] Core i5-4258U（5100, GT3）

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

EvaWang  changed:

   What|Removed |Added

Summary|[HSW] intel VGA driver i915 |[HSW] intel VGA driver i915
   |doesn't support new haswell |doesn't support new haswell
   |graphics [8086:0a2e]|graphics [8086:0a2e] Core
   ||i5-4258U?5100, GT3?

--- Comment #1 from EvaWang  ---
Hardware is Core i5-4258U?5100, GT3?

-- 
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/20130419/8471cd3f/attachment-0001.html>

[Bug 63702] tiling2d in radeon trash vdpau UVD textures

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

--- Comment #2 from Rafael Castillo  ---
or this one st/mesa: optionally apply texture swizzle to border color v2

-- 
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/20130419/4e50f949/attachment.html>

[Bug 63702] tiling2d in radeon trash vdpau UVD textures

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

--- Comment #1 from Rafael Castillo  ---
could be this patch too radeonsi: add support for compressed texture v2

-- 
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/20130419/bd499ae8/attachment.html>

[Bug 63702] tiling2d in radeon trash vdpau UVD textures

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

Rafael Castillo  changed:

   What|Removed |Added

   Severity|critical|blocker
   Priority|medium  |highest

-- 
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/20130419/65cf84b6/attachment.html>

[Bug 63702] New: tiling2d in radeon trash vdpau UVD textures

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

  Priority: medium
Bug ID: 63702
  Assignee: dri-devel at lists.freedesktop.org
   Summary: tiling2d in radeon trash vdpau UVD textures
  Severity: critical
Classification: Unclassified
OS: other
  Reporter: jrch2k10 at gmail.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: git
 Component: Drivers/Gallium/radeonsi
   Product: Mesa

Created attachment 78204
  --> https://bugs.freedesktop.org/attachment.cgi?id=78204=edit
image of the corruption

after update today to enable 2dcolortling UVD show extreme corruption

OS: 
Gentoo

my PC:
GPU: 
01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Cape
Verde XT [Radeon HD 7770 GHz Edition]

Mesa:
Git llvm-compiler Opencl
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD CAPE VERDE
OpenGL version string: 2.1 Mesa 9.2.0 (git-d0e9aaa)
OpenGL shading language version string: 1.20

Dmesg:
clean of CS errors

VDPAU:
clean of CS or any errors on Mplayer2

LLVM:
3.3 svn same mesa day with r600 support

Kernel:
kernel a5gfd drm-next-3.10-wip

Fix: can't find any even disable colortiling and colortiling2D corruption
persist

Xorg:
Glamor Accel

if someone can direct me in how to debug VDPAU i could provide more helpful
information

Attached image showing corruption:

additionally not related to this issue but persistant since im testing:

Mpeg1 is corrupted always
divx present minimal corruption
h264 + VC1 black screen[maybe 10bit]
WMV.X hang gpu

-- 
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/20130419/58f3f6c5/attachment.html>

[Bug 63701] New: [HSW] intel VGA driver i915 doesn't support new haswell graphics [8086:0a2e]

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

  Priority: medium
Bug ID: 63701
  Assignee: dri-devel at lists.freedesktop.org
   Summary: [HSW] intel VGA driver i915 doesn't support new
haswell graphics [8086:0a2e]
  Severity: critical
Classification: Unclassified
OS: Linux (All)
  Reporter: evawang at linpus.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: unspecified
 Component: General
   Product: DRI

It can't enter to OS with latest kernel 3.9.0-rc7 on intel new haswell graphics
[8086:0a2e]
Where can we get the driver for this graphics card?
Thanks!!

-- 
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/20130419/9b9d503e/attachment.html>

[Bug 63698] Build error with libdrm in non standard prefix

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

Matt Turner  changed:

   What|Removed |Added

Summary|Build error with libdri in  |Build error with libdrm in
   |non standard prefix |non standard prefix

-- 
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/20130419/3368cccd/attachment.html>

[PULL] drm-intel fixes for 3.10

Hi Dave,

As promised a stash of (mostly) fixes. Two pieces of non-fixes included:
- A notch more gtt refactoring from Ben, beating to death with igt in our
  nightly testing.
- Support for display display-less server chips (again from Ben). New hw
  support which is only likely to break itself ;-)

Otherwise just tons of fixes:
- hpd irq storm mitigation from Egbert Eich. Your -next tree already has
  the infrastructure, this here just supplies the logic.
- sdvo hw state check fix from Egbert Eich
- fb cb tune settings for the pch pll clocks on cpt/ppt
- "Bring a bigger gun" coherence workaround for multi-threade, mulit-core
  & thrashing tiled gtt cpu access from Chris.
- Update haswell mPHY code.
- l3$ caching for context objects on ivb/hsw (Chris).
- dp aux refclock fix for haswell (Jani)
- moar overclocking fixes for snb/ivb (Ben)
- ecobits ppgtt pte caching control fixes from Ville
- fence stride check fixes and limit improvements (Ville)
- fix up crtc force restoring, potentially resulting in tons of hw state
  check WARNs
- OOPS fix for NULL derefencing of fb pointers when force-restoring a crtc
  when other crtcs are disabled and the force-restored crtc is _not_ the
  first one.
- Fix pfit disabling on gen2/3.
- Haswell ring freq scaling fixes (Chris).
- backlight init/teardown fix (failed eDP init killed the lvds backlight)
  from Jani
- cpt/ppt fdi polarity fixes from Paulo (should help a lot of the FDI link
  train failures).
- And a bunch of smaller things all over.

Cheers, Daniel

PS: Since I've already split out -next for 3.11, this pull is for the
-fixes branch.

The following changes since commit bae3699182027525d92b97d904578a533264b242:

  drm/i915: info level for simulated gpu hang dmesg notice (2013-04-06 16:07:21 
+0200)

are available in the git repository at:

  git://people.freedesktop.org/~danvet/drm-intel drm-intel-fixes

for you to fetch changes up to bd080ee57c2173cefdcadc39c7863a76c249d049:

  drm/i915: fix bpc vs. bpp confusion in intel_crtc_compute_config (2013-04-18 
09:43:33 +0200)


Ben Widawsky (20):
  drm/i915: Support PCH no display
  drm/i915: PCH_NOP
  drm/i915: Don't touch South Display when PCH_NOP
  drm/i915: Don't wait for PCH on reset
  drm/i915: Set PCH_NOP
  drm/i915: Add a pipeless ivybridge configuration
  drm/i915: generalize pte vs. register BAR allocation
  drm/i915: Call out GEN6 PTE specificity
  drm/i915: Map registers before GTT init
  drm/i915: random checkpatch fixes
  drm/i915/ppgtt: Set scratch page "globally"
  drm/i915: Conditionally carve out GGTT PDE
  drm/i915: Rework PPGTT init code
  drm/i915: Abstract PPGTT enabling
  drm/i915: NULL aliasing_ppgtt on cleanup
  drm/i915: Allow PPGTT enable to fail
  drm/i915: Better overclock support
  drm/i915: Don't default to overclock max
  drm/i915: Remove stale code
  drm/i915: VLV doesn't have LLC

Chris Wilson (3):
  drm/i915: Workaround incoherence between fences and LLC across multiple 
CPUs
  drm/i915: Use MLC (l3$) for context objects
  drm/i915: Scale ring, rather than ia, frequency on Haswell

Daniel Vetter (10):
  drm/i915: fix lost FP_CB_TUNE setting for pch plls
  drm/i915: fix FP CB tuning limits for lvds
  drm/i915: set CB tuning also for the reduce clock
  drm/i915: tune down Y tiling scanout warning
  drm/i915: update FDI mPHY setup code
  drm/i915: don't check inconsistent modeset state when force-restoring
  drm/i915: Fixup Oops in the pipe config computation
  drm/i915: Fixup pfit disabling for gen2/3
  drm/i915: move cpu_transcoder to the pipe configuration
  drm/i915: fix bpc vs. bpp confusion in intel_crtc_compute_config

Egbert Eich (6):
  drm/i915: Fix SDVO connector and encoder get_hw_state functions
  drm/i915: Add HPD IRQ storm detection (v5)
  drm/i915: (re)init HPD interrupt storm statistics
  drm/i915: Mask out the HPD irq bits before setting them individually.
  drm/i915: Disable HPD interrupt on pin when irq storm is detected (v3)
  drm/i915: Add Reenable Timer to turn Hotplug Detection back on (v4)

Jani Nikula (2):
  drm/i915: use lower aux clock divider on non-ULT HSW
  drm/i915: ensure single initialization and cleanup of backlight device

Mika Kuoppala (2):
  drm/i915: Return stored value from max freq sysfs entry
  drm/i915: shorten debugfs output simple attributes

Paulo Zanoni (7):
  drm/i915: add intel_using_power_well
  drm/i915: don't touch the PF regs if the power well is down
  drm/i915: remove comment about IVB link training from intel_pm.c
  drm/i915: don't intel_crt_init on any ULT machines
  drm/i915: WARN when LPT-LP is not paired with ULT CPU
  drm/i915: set CPT FDI RX polarity bits based on VBT
  drm/i915: preserve the PBC bits of TRANS_CHICKEN2

Ville Syrj?l? (6):
  drm/i915: Add

Re: [PATCH 2/3] drm/radeon: clean up audio dto programming

2013/4/18  alexdeuc...@gmail.com:
 -   switch (radeon_encoder-encoder_id) {
 -   case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_TMDS1:
 -   case ENCODER_OBJECT_ID_INTERNAL_LVTM1:
 -   WREG32_P(R600_AUDIO_TIMING, 0, ~0x301);
 -   break;
 -   case ENCODER_OBJECT_ID_INTERNAL_UNIPHY:
 -   case ENCODER_OBJECT_ID_INTERNAL_UNIPHY1:
 -   case ENCODER_OBJECT_ID_INTERNAL_UNIPHY2:
 -   case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_LVTMA:
 -   WREG32_P(R600_AUDIO_TIMING, 0x100, ~0x301);
 -   break;
 -   default:
 -   dev_err(rdev-dev, Unsupported encoder type 0x%02X\n,
 - radeon_encoder-encoder_id);
 -   return;
 -   }

Are you sure we can just drop that part?

I'd appreciate waiting with this patch until next week, I'll test it
over the weekend on my RV620.

-- 
Rafał
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] drm/radeon: clean up audio supported check

2013/4/18  alexdeuc...@gmail.com:
 From: Alex Deucher alexander.deuc...@amd.com

 Signed-off-by: Alex Deucher alexander.deuc...@amd.com
 ---
  drivers/gpu/drm/radeon/r600_audio.c |5 +
  1 files changed, 1 insertions(+), 4 deletions(-)

 diff --git a/drivers/gpu/drm/radeon/r600_audio.c 
 b/drivers/gpu/drm/radeon/r600_audio.c
 index cb03fe2..72561e4 100644
 --- a/drivers/gpu/drm/radeon/r600_audio.c
 +++ b/drivers/gpu/drm/radeon/r600_audio.c
 @@ -57,10 +57,7 @@ static bool radeon_dig_encoder(struct drm_encoder *encoder)
   */
  static int r600_audio_chipset_supported(struct radeon_device *rdev)
  {
 -   return (rdev-family = CHIP_R600  !ASIC_IS_DCE6(rdev))
 -   || rdev-family == CHIP_RS600
 -   || rdev-family == CHIP_RS690
 -   || rdev-family == CHIP_RS740;
 +   return ASIC_IS_DCE2(rdev)  !ASIC_IS_DCE6(rdev);
  }

  struct r600_audio r600_audio_status(struct radeon_device *rdev)

Looks fine :)

-- 
Rafał
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 63701] [HSW] intel VGA driver i915 doesn't support new haswell graphics [8086:0a2e] Core i5-4258U（5100, GT3）

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

--- Comment #2 from Ben Widawsky b...@bwidawsk.net ---
That PCI ID is new to me, and I cannot find details about the actual part so I
am hesitant to write a real patch. Paulo have you seen that one? 

Since very limited people have access to HSW hardware at this point, you should
be working through Intel or whatever vendor provided the HW to you for the
proper fix. Also, as far as I can tell, the Haswell model you specify doesn't
exist in any official Intel documentation. For that reason, I would again
recommend you through whichever vendor provided the hardware to you (and close
this bug)

With all that disclaimer above... If you'd like to fix it yourself, patches are
welcome. In drivers/gpu/drm/i915/i915_drv.c, copy one and modify with your PCI
ID.

INTEL_VGA_DEVICE(0x0D02, intel_haswell_d_info), /* CRW GT1 desktop */
INTEL_VGA_DEVICE(0x0D12, intel_haswell_d_info), /* CRW GT2 desktop */
INTEL_VGA_DEVICE(0x0D22, intel_haswell_d_info), /* CRW GT2 desktop */
INTEL_VGA_DEVICE(0x0D0A, intel_haswell_d_info), /* CRW GT1 server */
INTEL_VGA_DEVICE(0x0D1A, intel_haswell_d_info), /* CRW GT2 server */
INTEL_VGA_DEVICE(0x0D2A, intel_haswell_d_info), /* CRW GT2 server */
INTEL_VGA_DEVICE(0x0D06, intel_haswell_m_info), /* CRW GT1 mobile */
INTEL_VGA_DEVICE(0x0D16, intel_haswell_m_info), /* CRW GT2 mobile */
INTEL_VGA_DEVICE(0x0D26, intel_haswell_m_info), /* CRW GT2 mobile */


Keep in mind, just about every graphics component which needs PCI ids will have
the same problem.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[patch] drm: add a couple __user annotations

2013-04-19 Thread Dan Carpenter

list and request are already declared as __user pointers, it's just
this cast which is missing the annotation.

Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
---
Sparse doesn't complain about this because it hits the error: bad
integer constant expression and stops printing warnings.

diff --git a/drivers/gpu/drm/drm_ioc32.c b/drivers/gpu/drm/drm_ioc32.c
index 2f4c434..764794b 100644
--- a/drivers/gpu/drm/drm_ioc32.c
+++ b/drivers/gpu/drm/drm_ioc32.c
@@ -457,7 +457,7 @@ static int compat_drm_infobufs(struct file *file, unsigned 
int cmd,
request = compat_alloc_user_space(nbytes);
if (!access_ok(VERIFY_WRITE, request, nbytes))
return -EFAULT;
-   list = (struct drm_buf_desc *) (request + 1);
+   list = (struct drm_buf_desc __user *) (request + 1);
 
if (__put_user(count, request-count)
|| __put_user(list, request-list))
@@ -518,7 +518,7 @@ static int compat_drm_mapbufs(struct file *file, unsigned 
int cmd,
request = compat_alloc_user_space(nbytes);
if (!access_ok(VERIFY_WRITE, request, nbytes))
return -EFAULT;
-   list = (struct drm_buf_pub *) (request + 1);
+   list = (struct drm_buf_pub __user *) (request + 1);
 
if (__put_user(count, request-count)
|| __put_user(list, request-list))
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 63709] New: Desktop Effects on 3D desktop environments are jerky/stutter.

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

  Priority: medium
Bug ID: 63709
  Assignee: dri-devel@lists.freedesktop.org
   Summary: Desktop Effects on 3D desktop environments are
jerky/stutter.
  Severity: critical
Classification: Unclassified
OS: Linux (All)
  Reporter: equites.v...@gmail.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: unspecified
 Component: DRM/Radeon
   Product: DRI

Hardware: Gigabyte GA-880GM-d2h, Radeon HD4250 512 shared VRAM, 4GB RAM total,
Phenom x4 965BE (3.4Ghz quad). Everything at stock clock speed and voltages.
BIOS flashed to latest stable version FF from Gigabyte.

user@user-GA-880GM-D2H:~$ glxinfo | grep OpenGL
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD RS880
OpenGL version string: 3.0 Mesa 9.1.1
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
user@user-GA-880GM-D2H:~$ glxinfo | grep render
direct rendering: Yes
OpenGL renderer string: Gallium 0.4 on AMD RS880
GL_NV_conditional_render, GL_AMD_conservative_depth, 


In a default KDE install on Ubuntu: Default settings are Use OpenGL 2 shaders
enabled and VSync enabled. In Desktop effects such as translucent background
when dragging windows and Minimize Animation, dragging a window results in
stuttering movement in the former (the screen does not shift. but the window
stutters as if it stops for a second and catches up but it's fast so it looks
like a stutter [missing frames?]) and in Minimize animation the window stutters
also as the animation takes place. Disabling VSync and OpenGL 2 shaders
options, there is still stuttering animation. This seems to be OpenGL specific
as XRender compositing provides a smooth experience.

In a Gnome Shell 3.8 install: In previous versions of Gnome Shell, there were
jerky animations also. In 3.8, which is what is installed on my computer right
now in Ubuntu 13.04, the animations are not ALWAYS noticeably jerky, but
sometimes they do jerk when happening, it's noticeable in the animation when
switching to a new window from the overview and the window slides in front of
the desktop. It does not always jerk but often enough. In glxgears I get 58/59
fps normally, and with glxgears window maximized, it still gives the same frame
rate. But when switching between three or four windows, there's a jerk in the
animation and it shows up in glxgears as a drop in the fps and it goes down to
50-51 fps and is unable to keep up with the refresh rate. Also, in glxgears, I
have noticed that the gears move smoothly but after maximizing them, they run
smoothly for some seconds, and then I notice a jerk/stutter in the gears once,
and then it runs smoothly again. In Gnome Shell, you will probably not notice
the jerks when you first use it, but it's definitely there and is an annoyance
for someone who uses it a long time. And the stuttering animations are
definitely very noticeable on KDE in a default install with desktop effects.

This is all with no custom Xorg conf. With swbuffersWait 0 in Xorg conf, the
stuttering is even more noticeable as ever in Gnome, it seems to me.

This seems to be a driver bug (correct me if I'm wrong, I'm a relative newbie
to Linux.), so I'm posting this report here. But this is a major problem that
needs to be fixed soon. What user wants to use Linux when the major desktops
run with jerky effects.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/3] drm: Add drm_rect_equals()

2013-04-19 Thread ville . syrjala

From: Ville Syrjälä ville.syrj...@linux.intel.com

drm_rect_equals() tells whether two drm_rects are equal.

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
 include/drm/drm_rect.h | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/include/drm/drm_rect.h b/include/drm/drm_rect.h
index fe767b7..64fa265 100644
--- a/include/drm/drm_rect.h
+++ b/include/drm/drm_rect.h
@@ -124,6 +124,21 @@ static inline bool drm_rect_visible(const struct drm_rect 
*r)
return drm_rect_width(r)  0  drm_rect_height(r)  0;
 }
 
+/**
+ * drm_rect_equals - determine if two rectangles are equal
+ * @r1: first rectangle
+ * @r2: second rectangle
+ *
+ * RETURNS:
+ * %true if the rectangles are equal, %false otherwise.
+ */
+static inline bool drm_rect_equals(const struct drm_rect *r1,
+  const struct drm_rect *r2)
+{
+   return r1-x1 == r2-x1  r1-x2 == r2-x2 
+   r1-y1 == r2-y1  r1-y2 == r2-y2;
+}
+
 bool drm_rect_intersect(struct drm_rect *r, const struct drm_rect *clip);
 bool drm_rect_clip_scaled(struct drm_rect *src, struct drm_rect *dst,
  const struct drm_rect *clip,
-- 
1.8.1.5

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/3] drm/i915: Relax the sprite scaling limits checks

2013-04-19 Thread ville . syrjala

From: Ville Syrjälä ville.syrj...@linux.intel.com

Reduce the size of the the src/dst viewport to keep the scalign ratios
in check.

Also treat sprites below the minimum size as invisble.

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
 drivers/gpu/drm/i915/intel_sprite.c | 60 -
 1 file changed, 32 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index 93a6657..c3a5688 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -679,26 +679,19 @@ intel_update_plane(struct drm_plane *plane, struct 
drm_crtc *crtc,
return -EINVAL;
}
 
+   /*
+* FIXME the following code does a bunch of fuzzy adjustments to the
+* coordinates and sizes. We probably need some way to decide whether
+* more strict checking should be done instead.
+*/
max_scale = intel_plane-max_downscale  16;
min_scale = intel_plane-can_scale ? 1 : (1  16);
 
-   hscale = drm_rect_calc_hscale(src, dst, min_scale, max_scale);
-   if (hscale  0) {
-   DRM_DEBUG_KMS(Horizontal scaling factor out of limits\n);
-   drm_rect_debug_print(src, true);
-   drm_rect_debug_print(dst, false);
+   hscale = drm_rect_calc_hscale_relaxed(src, dst, min_scale, max_scale);
+   BUG_ON(hscale  0);
 
-   return hscale;
-   }
-
-   vscale = drm_rect_calc_vscale(src, dst, min_scale, max_scale);
-   if (vscale  0) {
-   DRM_DEBUG_KMS(Vertical scaling factor out of limits\n);
-   drm_rect_debug_print(src, true);
-   drm_rect_debug_print(dst, false);
-
-   return vscale;
-   }
+   vscale = drm_rect_calc_vscale_relaxed(src, dst, min_scale, max_scale);
+   BUG_ON(vscale  0);
 
visible = drm_rect_clip_scaled(src, dst, clip, hscale, vscale);
 
@@ -708,6 +701,25 @@ intel_update_plane(struct drm_plane *plane, struct 
drm_crtc *crtc,
crtc_h = drm_rect_height(dst);
 
if (visible) {
+   /* check again in case clipping clamped the results */
+   hscale = drm_rect_calc_hscale(src, dst, min_scale, max_scale);
+   if (hscale  0) {
+   DRM_DEBUG_KMS(Horizontal scaling factor out of 
limits\n);
+   drm_rect_debug_print(src, true);
+   drm_rect_debug_print(dst, false);
+
+   return hscale;
+   }
+
+   vscale = drm_rect_calc_vscale(src, dst, min_scale, max_scale);
+   if (vscale  0) {
+   DRM_DEBUG_KMS(Vertical scaling factor out of 
limits\n);
+   drm_rect_debug_print(src, true);
+   drm_rect_debug_print(dst, false);
+
+   return vscale;
+   }
+
/* Make the source viewport size an exact multiple of the 
scaling factors. */
drm_rect_adjust_size(src,
 drm_rect_width(dst) * hscale - 
drm_rect_width(src),
@@ -718,10 +730,6 @@ intel_update_plane(struct drm_plane *plane, struct 
drm_crtc *crtc,
 * Adjust to (macro)pixel boundary, but be careful not to
 * increase the source viewport size, because that could
 * push the downscaling factor out of bounds.
-*
-* FIXME Should we be really strict and reject the
-* config if it results in non (macro)pixel aligned
-* coords?
 */
src_x = src.x1  16;
src_w = drm_rect_width(src)  16;
@@ -752,15 +760,11 @@ intel_update_plane(struct drm_plane *plane, struct 
drm_crtc *crtc,
 
/* FIXME interlacing min height is 6 */
 
-   if (crtc_w  3 || crtc_h  3) {
-   DRM_DEBUG_KMS(Destination dimensions too small\n);
-   return -EINVAL;
-   }
+   if (crtc_w  3 || crtc_h  3)
+   visible = false;
 
-   if (src_w  3 || src_h  3) {
-   DRM_DEBUG_KMS(Source dimensions too small\n);
-   return -EINVAL;
-   }
+   if (src_w  3 || src_h  3)
+   visible = false;
 
width_bytes = ((src_x * pixel_size)  63) + src_w * pixel_size;
 
-- 
1.8.1.5

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 2/3] drm/i915: Implement proper clipping for video sprites

2013-04-19 Thread ville . syrjala

From: Ville Syrjälä ville.syrj...@linux.intel.com

Properly clip the source when the destination gets clipped
by the pipe dimensions.

Sadly the video sprite hardware is rather limited so it can't do proper
sub-pixel postitioning. Resort to truncating the source coordinates to
(macro)pixel boundary.

The scaling checks are done using the strict drm_region functions.
Which means that an error is returned when the min/max scaling
ratios are exceeded.

Also do some additional checking against various hardware limits.

v2: Truncate src coords instead of rounding to avoid increasing src
viewport size, and adapt to changes in drm_calc_{h,v}scale().
v3: Adapt to drm_region-drm_rect rename. Fix misaligned crtc_w for
packed YUV formats when scaling isn't supported.
v4: Use stricter scaling checks, use drm_rect_equals()

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
 drivers/gpu/drm/i915/intel_sprite.c | 202 ++--
 1 file changed, 150 insertions(+), 52 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index c7d25c5..93a6657 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -32,6 +32,7 @@
 #include drm/drmP.h
 #include drm/drm_crtc.h
 #include drm/drm_fourcc.h
+#include drm/drm_rect.h
 #include intel_drv.h
 #include drm/i915_drm.h
 #include i915_drv.h
@@ -583,6 +584,20 @@ ilk_get_colorkey(struct drm_plane *plane, struct 
drm_intel_sprite_colorkey *key)
key-flags = I915_SET_COLORKEY_NONE;
 }
 
+static bool
+format_is_yuv(uint32_t format)
+{
+   switch (format) {
+   case DRM_FORMAT_YUYV:
+   case DRM_FORMAT_UYVY:
+   case DRM_FORMAT_VYUY:
+   case DRM_FORMAT_YVYU:
+   return true;
+   default:
+   return false;
+   }
+}
+
 static int
 intel_update_plane(struct drm_plane *plane, struct drm_crtc *crtc,
   struct drm_framebuffer *fb, int crtc_x, int crtc_y,
@@ -600,9 +615,27 @@ intel_update_plane(struct drm_plane *plane, struct 
drm_crtc *crtc,
enum transcoder cpu_transcoder = intel_pipe_to_cpu_transcoder(dev_priv,
  pipe);
int ret = 0;
-   int x = src_x  16, y = src_y  16;
-   int primary_w = crtc-mode.hdisplay, primary_h = crtc-mode.vdisplay;
bool disable_primary = false;
+   bool visible;
+   int hscale, vscale;
+   int max_scale, min_scale;
+   int pixel_size = drm_format_plane_cpp(fb-pixel_format, 0);
+   struct drm_rect src = {
+   .x1 = src_x,
+   .x2 = src_x + src_w,
+   .y1 = src_y,
+   .y2 = src_y + src_h,
+   };
+   struct drm_rect dst = {
+   .x1 = crtc_x,
+   .x2 = crtc_x + crtc_w,
+   .y1 = crtc_y,
+   .y2 = crtc_y + crtc_h,
+   };
+   const struct drm_rect clip = {
+   .x2 = crtc-mode.hdisplay,
+   .y2 = crtc-mode.vdisplay,
+   };
 
intel_fb = to_intel_framebuffer(fb);
obj = intel_fb-obj;
@@ -618,19 +651,23 @@ intel_update_plane(struct drm_plane *plane, struct 
drm_crtc *crtc,
intel_plane-src_w = src_w;
intel_plane-src_h = src_h;
 
-   src_w = src_w  16;
-   src_h = src_h  16;
-
/* Pipe must be running... */
-   if (!(I915_READ(PIPECONF(cpu_transcoder))  PIPECONF_ENABLE))
-   return -EINVAL;
-
-   if (crtc_x = primary_w || crtc_y = primary_h)
+   if (!(I915_READ(PIPECONF(cpu_transcoder))  PIPECONF_ENABLE)) {
+   DRM_DEBUG_KMS(Pipe disabled\n);
return -EINVAL;
+   }
 
/* Don't modify another pipe's plane */
-   if (intel_plane-pipe != intel_crtc-pipe)
+   if (intel_plane-pipe != intel_crtc-pipe) {
+   DRM_DEBUG_KMS(Wrong plane - crtc mapping\n);
return -EINVAL;
+   }
+
+   /* FIXME check all gen limits */
+   if (fb-width  3 || fb-height  3 || fb-pitches[0]  16384) {
+   DRM_DEBUG_KMS(Unsuitable framebuffer for plane\n);
+   return -EINVAL;
+   }
 
/* Sprite planes can be linear or x-tiled surfaces */
switch (obj-tiling_mode) {
@@ -638,55 +675,113 @@ intel_update_plane(struct drm_plane *plane, struct 
drm_crtc *crtc,
case I915_TILING_X:
break;
default:
+   DRM_DEBUG_KMS(Unsupported tiling mode\n);
return -EINVAL;
}
 
-   /*
-* Clamp the width  height into the visible area.  Note we don't
-* try to scale the source if part of the visible region is offscreen.
-* The caller must handle that by adjusting source offset and size.
-*/
-   if ((crtc_x  0)  ((crtc_x + crtc_w)  0)) {
-   crtc_w += crtc_x;
-   crtc_x = 0;
+   max_scale =

[DVO][PATCH] drm/i915: Fall back to bit banging mode for DVO transmitter detection

2013-04-19 Thread David Müller (ELSOFT AG)

Hello

As discussed in this thread
http://lists.freedesktop.org/archives/dri-devel/2013-April/037411.html
GMBUS based DVO transmitter detection seems to be unreliable which could
result in an unusable DVO port.

The attached patch fixes this by falling back to bit banging mode for
the time DVO transmitter detection is in progress.

Signed-off-by: David Müller d.muel...@elsoft.ch
Tested-by: David Müller d.muel...@elsoft.ch

---
diff -dpurN a/drivers/gpu/drm/i915/intel_dvo.c 
b/drivers/gpu/drm/i915/intel_dvo.c
--- a/drivers/gpu/drm/i915/intel_dvo.c  2012-12-11 10:09:35.113446850 +0100
+++ b/drivers/gpu/drm/i915/intel_dvo.c  2013-04-19 07:21:54.054546365 +0200
@@ -449,6 +449,7 @@ void intel_dvo_init(struct drm_device *d
const struct intel_dvo_device *dvo = intel_dvo_devices[i];
struct i2c_adapter *i2c;
int gpio;
+   bool dvoinit;
 
/* Allow the I2C driver info to specify the GPIO to be used in
 * special cases, but otherwise default to what's defined
@@ -468,7 +469,17 @@ void intel_dvo_init(struct drm_device *d
i2c = intel_gmbus_get_adapter(dev_priv, gpio);
 
intel_dvo-dev = *dvo;
-   if (!dvo-dev_ops-init(intel_dvo-dev, i2c))
+
+   /* GMBUS NAK handling seems to be unstable, hence let the
+* transmitter detection run in bit banging mode for now.
+*/
+   intel_gmbus_force_bit(i2c, true);
+
+   dvoinit = dvo-dev_ops-init(intel_dvo-dev, i2c);
+
+   intel_gmbus_force_bit(i2c, false);
+
+   if (!dvoinit)
continue;
 
intel_encoder-type = INTEL_OUTPUT_DVO;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

UVD status on loongson 3a platform

2013-04-19 Thread Chen Jie

Hi all,

Recently, the uvd supporting is released, and we've tried it on
loongson 3a platform.
Brief introduction about loongson 3a, it's a MIPS III compatible, 4
cores processor.

More details about the platform [1]:
* The Board: RS780E + SB710 chipset, with an AMD radeon HD6570 video card
* The kernel is 64bits(n64 ABI), and the userland is 32bits(o32 ABI)
* OS: LOonux 3.3.6 [2] + LTP-uvd-installer-20130419.bin [3]
** kernel: 3.9 + uvd related patches
** mesa: git master version (d0e9aa)

We tried three video samples:
* big_buck_bunny_1080p_h264.mov
(http://mirrorblender.top-ix.org/peach/bigbuckbunny_movies/big_buck_bunny_1080p_h264.mov)
* Sintel.2010.2K.x264-VODO.mp4
(http://dev.lemote.com/files/upload/software/UVD-debug/Sintel.2010.2K.x264-VODO.mp4)
* test.avi (http://dev.lemote.com/files/upload/software/UVD-debug/test.avi)

For big_buck_bunny_1080p_h264.mov, the playback is not very fluent at
the beginning, and it has some video mosaic. We've recorded a video
for it, see http://dev.lemote.com/files/upload/software/UVD-debug/bbb-1080P.mp4
For video mosaic, what could it be caused by?

For Sintel.2010.2K.x264-VODO.mp4, it has a very long wait for the first frame.
We've also recorded a video for it, see
http://dev.lemote.com/files/upload/software/UVD-debug/sintel.2K.mp4
Any idea about the long wait for the first frame?

For test.avi(video: ITU H.264, 1920x1080), it's playing back
perfectly! Thanks for the effort on UVD!

In all of these tests, the CPU usage is around 50%, and all three
video samples play well on X86 platform with the same video card.

BTW, 785G also has UVD2.0, is it supported currently? Or will it be
supported in the near future?



Regards,

Chen Jie

[1] http://www.lemote.com/products/computer/fulong/348.html (zh_CN)
[2] http://dev.lemote.com/653.html (zh_CN)
[3] http://dev.lemote.com/663.html (zh_CN)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [DVO][PATCH] drm/i915: Fall back to bit banging mode for DVO transmitter detection

On Fri, Apr 19, 2013 at 10:41:50AM +0200, David Müller (ELSOFT AG) wrote:
 Hello
 
 As discussed in this thread
 http://lists.freedesktop.org/archives/dri-devel/2013-April/037411.html
 GMBUS based DVO transmitter detection seems to be unreliable which could
 result in an unusable DVO port.
 
 The attached patch fixes this by falling back to bit banging mode for
 the time DVO transmitter detection is in progress.
 

 Signed-off-by: David Müller d.muel...@elsoft.ch
 Tested-by: David Müller d.muel...@elsoft.ch
 
 ---
 diff -dpurN a/drivers/gpu/drm/i915/intel_dvo.c 
 b/drivers/gpu/drm/i915/intel_dvo.c
 --- a/drivers/gpu/drm/i915/intel_dvo.c2012-12-11 10:09:35.113446850 
 +0100
 +++ b/drivers/gpu/drm/i915/intel_dvo.c2013-04-19 07:21:54.054546365 
 +0200
 @@ -449,6 +449,7 @@ void intel_dvo_init(struct drm_device *d
   const struct intel_dvo_device *dvo = intel_dvo_devices[i];
   struct i2c_adapter *i2c;
   int gpio;
 + bool dvoinit;
  
   /* Allow the I2C driver info to specify the GPIO to be used in
* special cases, but otherwise default to what's defined
 @@ -468,7 +469,17 @@ void intel_dvo_init(struct drm_device *d
   i2c = intel_gmbus_get_adapter(dev_priv, gpio);
  
   intel_dvo-dev = *dvo;
 - if (!dvo-dev_ops-init(intel_dvo-dev, i2c))
 +
 + /* GMBUS NAK handling seems to be unstable, hence let the
 +  * transmitter detection run in bit banging mode for now.
 +  */
 + intel_gmbus_force_bit(i2c, true);
 +
 + dvoinit = dvo-dev_ops-init(intel_dvo-dev, i2c);
 +
 + intel_gmbus_force_bit(i2c, false);

Shouldn't we keep the dvo i2c line in bit-banging mode always, i.e.
restore gmbus mode only when dvo init failed?

I suspect that for fickle hw not just init will fail ...
-Daniel

 +
 + if (!dvoinit)
   continue;
  
   intel_encoder-type = INTEL_OUTPUT_DVO;


-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 61182] r600g causes KWin crashes with kernel 3.8

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

--- Comment #31 from Maxim Yegorushkin maxim.yegorush...@gmail.com ---
I observe the same issue on Fedora 18 with Radeon HD 5670:

[KCrash Handler]
#6  __memset_sse2 () at ../sysdeps/x86_64/memset.S:873
#7  0x7f59a39eaff2 in memset (__len=optimized out, __ch=204,
__dest=optimized out) at /usr/include/bits/string3.h:84
#8  r600_texture_create_object (screen=screen@entry=0x1f317a0,
base=base@entry=0x7fff57798810,
pitch_in_bytes_override=pitch_in_bytes_override@entry=0, buf=buf@entry=0x0,
surface=surface@entry=0x7fff57797b10) at r600_texture.c:509
#9  0x7f59a39eb2c7 in r600_texture_create (screen=0x1f317a0,
templ=0x7fff57798810) at r600_texture.c:601
#10 0x7f59a39fda25 in dri2_drawable_process_buffers (att_count=1,
atts=0x7fff577988f0, buffer_count=1, buffers=0x1e9fe80, drawable=0x1e9ff20) at
dri2.c:254
#11 dri2_allocate_textures (drawable=0x1e9ff20, statts=0x7fff577988f0,
statts_count=1) at dri2.c:404
#12 0x7f59a39fc595 in dri_st_framebuffer_validate (stfbi=optimized out,
statts=0x7fff577988f0, count=1, out=0x0) at dri_drawable.c:81
#13 0x7f59a39fc7ce in dri_drawable_validate_att
(statt=ST_ATTACHMENT_FRONT_LEFT, drawable=0x1e9ff20) at dri_drawable.c:206
#14 dri_set_tex_buffer2 (pDRICtx=optimized out, target=3553, format=8409,
dPriv=optimized out) at dri_drawable.c:220
#15 0x00304bacb3c3 in loadTexture (depth=24, size=..., pix=optimized out,
this=0x1ea0b70) at /usr/src/debug/kde-workspace-4.10.1/kwin/glxbackend.cpp:716
#16 KWin::GlxTexture::loadTexture (this=0x1ea0b70, pix=optimized out,
size=..., depth=24) at
/usr/src/debug/kde-workspace-4.10.1/kwin/glxbackend.cpp:658
#17 0x00304bac30d5 in KWin::SceneOpenGL::Window::bindTexture
(this=0x2184e10) at
/usr/src/debug/kde-workspace-4.10.1/kwin/scene_opengl.cpp:822
#18 0x00304bac9a8e in KWin::SceneOpenGL::Window::performPaint
(this=this@entry=0x2184e10, mask=mask@entry=1, region=..., data=...) at
/usr/src/debug/kde-workspace-4.10.1/kwin/scene_opengl.cpp:931
#19 0x00304bac249f in KWin::SceneOpenGL2::performPaintWindow
(this=this@entry=0x1fc3af0, w=w@entry=0x1ef75c0, mask=mask@entry=1, region=...,
data=...) at /usr/src/debug/kde-workspace-4.10.1/kwin/scene_opengl.cpp:566
#20 0x00304bac263d in KWin::SceneOpenGL2::finalDrawWindow (this=0x1fc3af0,
w=w@entry=0x1ef75c0, mask=mask@entry=1, region=..., data=...) at
/usr/src/debug/kde-workspace-4.10.1/kwin/scene_opengl.cpp:551
#21 0x00304bad63a5 in KWin::EffectsHandlerImpl::drawWindow (this=0x2170db0,
w=w@entry=0x1ef75c0, mask=mask@entry=1, region=..., data=...) at
/usr/src/debug/kde-workspace-4.10.1/kwin/effects.cpp:318
#22 0x00304bab585a in KWin::Scene::finalPaintWindow (this=optimized out,
w=0x1ef75c0, mask=1, region=..., data=...) at
/usr/src/debug/kde-workspace-4.10.1/kwin/scene.cpp:449
#23 0x00304bad6627 in KWin::EffectsHandlerImpl::paintWindow
(this=0x2170db0, w=0x1ef75c0, mask=mask@entry=1, region=..., data=...) at
/usr/src/debug/kde-workspace-4.10.1/kwin/effects.cpp:281
#24 0x00304bab841d in KWin::Scene::paintWindow (this=optimized out,
w=0x2184e10, mask=1, region=..., quads=...) at
/usr/src/debug/kde-workspace-4.10.1/kwin/scene.cpp:356
#25 0x00304bab774f in KWin::Scene::paintSimpleScreen
(this=this@entry=0x1fc3af0, orig_mask=orig_mask@entry=0, region=...) at
/usr/src/debug/kde-workspace-4.10.1/kwin/scene.cpp:342
#26 0x00304bab579e in KWin::Scene::finalPaintScreen (this=0x1fc3af0,
mask=0, region=..., data=...) at
/usr/src/debug/kde-workspace-4.10.1/kwin/scene.cpp:186
#27 0x00304bad67f0 in KWin::EffectsHandlerImpl::paintScreen
(this=0x2170db0, mask=0, region=..., data=...) at
/usr/src/debug/kde-workspace-4.10.1/kwin/effects.cpp:254
#28 0x00304bab6b38 in KWin::Scene::paintScreen (this=0x1fc3af0,
mask=0x7fff57799444, region=0x7fff577994f0) at
/usr/src/debug/kde-workspace-4.10.1/kwin/scene.cpp:140
#29 0x00304bac5f9e in KWin::SceneOpenGL::paint (this=0x1fc3af0, damage=...,
toplevels=...) at /usr/src/debug/kde-workspace-4.10.1/kwin/scene_opengl.cpp:308
#30 0x00304bab0f5c in KWin::Compositor::performCompositing
(this=this@entry=0x1e65b30) at
/usr/src/debug/kde-workspace-4.10.1/kwin/composite.cpp:610
#31 0x00304bab1a10 in KWin::Compositor::slotCompositingOptionsInitialized
(this=0x1e65b30) at /usr/src/debug/kde-workspace-4.10.1/kwin/composite.cpp:275
#32 0x00399df8ceef in QMetaObject::activate (sender=0x1edf240, m=optimized
out, local_signal_index=optimized out, argv=0x0) at kernel/qobject.cpp:3539
#33 0x00399de6c5d7 in QFutureWatcherBase::event (this=optimized out,
event=0x7f59a4001770) at concurrent/qfuturewatcher.cpp:344
#34 0x0030439ca5cc in QApplicationPrivate::notify_helper
(this=this@entry=0x1d38570, receiver=receiver@entry=0x1edf240,
e=e@entry=0x7f59a4001770) at kernel/qapplication.cpp:4562
#35 0x0030439cea4a in QApplication::notify (this=0x7fff5779a3f0,
receiver=0x1edf240, e=0x7f59a4001770) at kernel/qapplication.cpp:4423
#36 0x0030448473c6 in

3.9.0-rc7-next: i915: render error detected

2013-04-19 Thread Jiri Slaby

Hi, with today's -next I got this:

[drm] capturing error event; look for more information in
/sys/kernel/debug/dri/0/i915_error_state
i915: render error detected, EIR: 0x0010
i915: page table error
i915:   PGTBL_ER: 0x0002
[drm:i915_report_and_clear_eir] *ERROR* EIR stuck: 0x0010, masking
i915: render error detected, EIR: 0x0010
i915: page table error
i915:   PGTBL_ER: 0x0002


The error state is here:
http://www.fi.muni.cz/~xslaby/sklad/panics/i915_error_state

thanks,
-- 
js
suse labs
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 63714] New: UVD acceleration does not properly detect kernel support

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

  Priority: medium
Bug ID: 63714
  Assignee: dri-devel@lists.freedesktop.org
   Summary: UVD acceleration does not properly detect kernel
support
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: ryszardz...@yahoo.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: git
 Component: Drivers/Gallium/r600
   Product: Mesa

Created attachment 78220
  -- https://bugs.freedesktop.org/attachment.cgi?id=78220action=edit
udv_fix.patch

Hardware: AMD E-350
00:01.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI
Wrestler [Radeon HD 6310]

1)Kernel 3.9.0-rc7 + uvd v3 patches  (Gentoo self compiled)
2)Libdrm-2.4.44
3)Mesa master git: e87015f5089a2c4a99e0288e1adeeabb5a7ca7e3
4)Xorg-server-1.13.4
5)ddx: xf86-video-ati git: 6e74aacc5e5da3b51744153dad1645caa6ea4ce3

I have been able to use UVD acceleration when it first appeared using mesa v2
of UVD code, but from the time it has been introduced in the mesa mainline with
v5 it does not work anymore. I believe it has to do with mesa not properly
detecting kernel support [1.638460] [drm] UVD initialized successfully.
and reverting to the vdpau support in shaders. Could it be that it requires
some kernel option I am missing?

As I have been trying to find exact reason I revered some changes that has been
introduced in mesa after v2 and it works again. I am not sure if all of those
are needed or which change in particular by itself would be enough but any way
it gets it working again so it is in there somewhere

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: 3.9.0-rc7-next: i915: render error detected

2013-04-19 Thread Chris Wilson

On Fri, Apr 19, 2013 at 11:16:36AM +0200, Jiri Slaby wrote:
 Hi, with today's -next I got this:
 
 [drm] capturing error event; look for more information in
 /sys/kernel/debug/dri/0/i915_error_state
 i915: render error detected, EIR: 0x0010
 i915: page table error
 i915:   PGTBL_ER: 0x0002
 [drm:i915_report_and_clear_eir] *ERROR* EIR stuck: 0x0010, masking
 i915: render error detected, EIR: 0x0010
 i915: page table error
 i915:   PGTBL_ER: 0x0002

These feel like they are becoming more common, though we have had
reports of this style of error since the dawn of time. The error means
that the CPU accessed an invalid PTE - so the most likely a missing mb
or chipset flush.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [DVO][PATCH] drm/i915: Fall back to bit banging mode for DVO transmitter detection

2013-04-19 Thread David Müller (ELSOFT AG)

Daniel Vetter wrote:
 On Fri, Apr 19, 2013 at 10:41:50AM +0200, David Müller (ELSOFT AG) wrote:
 +/* GMBUS NAK handling seems to be unstable, hence let the
 + * transmitter detection run in bit banging mode for now.
 + */
 +intel_gmbus_force_bit(i2c, true);
 +
 +dvoinit = dvo-dev_ops-init(intel_dvo-dev, i2c);
 +
 +intel_gmbus_force_bit(i2c, false);
 
 Shouldn't we keep the dvo i2c line in bit-banging mode always, i.e.
 restore gmbus mode only when dvo init failed?
 
 I suspect that for fickle hw not just init will fail ...

As far as i can tell, the critical part is the NAK handling.

Dave

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 2/3] drm/exynos: Rework fimc clocks handling


Dear Sylwester Nawrocki

Thank you for your update. I have some question of your patch.
please give your information to me.

Thank's
BR
Eunchul Kim.

On 04/17/2013 06:53 PM, Sylwester Nawrocki wrote:

The clocks handling is refactored and a mux clock handling is
added to account for changes in the clocks driver. After switching
to the common clock framework the sclk_fimc clock is now split
into two clocks: a gate and a mux clock. In order to retain the
exisiting functionality two additional consumer clocks are passed
to the driver from device tree: mux and parent. Then the driver
sets parent clock as a parent clock of the mux clock. These two
additional clocks are optional, and should go away when there is a
standard way of setting up parent clocks on DT platforms.

Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
  drivers/gpu/drm/exynos/exynos_drm_fimc.c |  167 +-
  1 file changed, 97 insertions(+), 70 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index d812c57..bc8411a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -76,6 +76,27 @@ enum fimc_wb {
FIMC_WB_B,
  };

+enum {
+   FIMC_CLK_LCLK,
+   FIMC_CLK_GATE,
+   FIMC_CLK_WB_A,
+   FIMC_CLK_WB_B,
+   FIMC_CLK_MUX,
+   FIMC_CLK_PARENT,


- What is MUX, PARENT ?


+   FIMC_CLKS_MAX
+};
+
+static const char * fimc_clock_names[] = {
+   [FIMC_CLK_LCLK]   = sclk_fimc,
+   [FIMC_CLK_GATE]   = fimc,
+   [FIMC_CLK_WB_A]   = pxl_async0,
+   [FIMC_CLK_WB_B]   = pxl_async1,
+   [FIMC_CLK_MUX]= mux,
+   [FIMC_CLK_PARENT] = parent,



- How can I get mux, parent clock information ?
  Normally we are using mout_mpll in exynos4210, mout_mpll_user in 
 exynos 4412. I want to get this two kind of clock name information.




+};
+
+#define FIMC_DEFAULT_LCLK_FREQUENCY 13300UL



- When do I use this value in the patch ?
  If not use. please remove this macro. If you want to use this value.
  please use platform data instead of macro.



+
  /*
   * A structure of scaler.
   *
@@ -132,15 +153,12 @@ struct fimc_driverdata {
   *
   * @ippdrv: prepare initialization using ippdrv.
   * @regs_res: register resources.
+ * @dev: pointer to the fimc device structure.



- We already set the dev information in ippdrv structure.
  I think this value is duplicated value.



   * @regs: memory mapped io registers.
   * @lock: locking of operations.
- * @sclk_fimc_clk: fimc source clock.
- * @fimc_clk: fimc clock.
- * @wb_clk: writeback a clock.
- * @wb_b_clk: writeback b clock.
+ * @clocks: fimc clocks.
+ * @clk_frequency: LCLK clock frequency.
   * @sc: scaler infomations.
- * @odr: ordering of YUV.
- * @ver: fimc version.
   * @pol: porarity of writeback.
   * @id: fimc id.
   * @irq: irq number.
@@ -148,13 +166,12 @@ struct fimc_driverdata {
   */
  struct fimc_context {
struct exynos_drm_ippdrvippdrv;
+   struct device   *dev;


- please check this value about really need ?


struct resource *regs_res;
void __iomem*regs;
struct mutexlock;
-   struct clk  *sclk_fimc_clk;
-   struct clk  *fimc_clk;
-   struct clk  *wb_clk;
-   struct clk  *wb_b_clk;
+   struct clk  *clocks[FIMC_CLKS_MAX];
+   u32 clk_frequency;
struct fimc_scaler  sc;
struct fimc_driverdata  *ddata;
struct exynos_drm_ipp_pol   pol;
@@ -1301,14 +1318,12 @@ static int fimc_clk_ctrl(struct fimc_context *ctx, bool 
enable)
DRM_DEBUG_KMS(%s:enable[%d]\n, __func__, enable);

if (enable) {
-   clk_enable(ctx-sclk_fimc_clk);
-   clk_enable(ctx-fimc_clk);
-   clk_enable(ctx-wb_clk);
+   clk_prepare_enable(ctx-clocks[FIMC_CLK_GATE]);
+   clk_prepare_enable(ctx-clocks[FIMC_CLK_WB_A]);
ctx-suspended = false;
} else {
-   clk_disable(ctx-sclk_fimc_clk);
-   clk_disable(ctx-fimc_clk);
-   clk_disable(ctx-wb_clk);
+   clk_disable_unprepare(ctx-clocks[FIMC_CLK_GATE]);
+   clk_disable_unprepare(ctx-clocks[FIMC_CLK_WB_A]);
ctx-suspended = true;
}

@@ -1713,11 +1728,66 @@ static void fimc_ippdrv_stop(struct device *dev, enum 
drm_exynos_ipp_cmd cmd)
fimc_write(cfg, EXYNOS_CIGCTRL);
  }

+static void fimc_put_clocks(struct fimc_context *ctx)
+{
+   int i;
+
+   for (i = 0; i  FIMC_CLKS_MAX; i++) {
+   if (IS_ERR(ctx-clocks[i]))
+   continue;
+   clk_put(ctx-clocks[i]);
+   ctx-clocks[i] = ERR_PTR(-EINVAL);
+   }
+}
+
+static int fimc_setup_clocks(struct fimc_context *ctx)
+{
+   struct device *dev;
+   int ret, i;
+
+   for (i = 0; i  FIMC_CLKS_MAX;

Re: [PATCH 3/3] drm/exynos: Add device tree support for fimc ipp driver


Dear Sylwester Nawrocki.

Sorry. I didn't check your third patch. I understand the mux, parent 
meaning. please ignore my comment of mux, parent


and please check below comments.

Thank's
BR
Eunchul Kim.

On 04/17/2013 02:31 AM, Sylwester Nawrocki wrote:

This patch adds OF initialization support for the FIMC driver.
The binding documentation can be found at Documentation/devicetree/
bindings/media/samsung-fimc.txt.

The syscon regmap interface is used to serialize access to the
shared CAMBLK registers from within the V4L2 FIMC-IS and the DRM
FIMC drivers. The DRM driver uses this interface for setting up
the FIFO data link between FIMD and FIMC IP blocks, while the V4L2
one for setting up a data link between the camera ISP and FIMC for
camera capture. The CAMBLK registers are not accessed any more
through a statically mapped IO. Synchronized access to these
registers is required for simultaneous operation of the camera
ISP and the DRM IPP on Exynos4x12.

Exynos4 is going to be a dt-only platform since 3.10, thus the
driver data and driver_ids static data structures are removed.

Camera input signal polarities are not currently parsed from the
device tree.

Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
  drivers/gpu/drm/exynos/Kconfig   |2 +-
  drivers/gpu/drm/exynos/exynos_drm_fimc.c |  101 +++---
  drivers/gpu/drm/exynos/regs-fimc.h   |7 +--
  3 files changed, 53 insertions(+), 57 deletions(-)

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 406f32a..5c4be2a 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -56,7 +56,7 @@ config DRM_EXYNOS_IPP

  config DRM_EXYNOS_FIMC
bool Exynos DRM FIMC
-   depends on DRM_EXYNOS_IPP
+   depends on DRM_EXYNOS_IPP  MFD_SYSCON  OF
help
  Choose this option if you want to use Exynos FIMC for DRM.

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index 9bea585..f25801e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -12,11 +12,12 @@
   *
   */
  #include linux/kernel.h
+#include linux/mfd/syscon.h
  #include linux/module.h
  #include linux/platform_device.h
+#include linux/regmap.h
  #include linux/clk.h
  #include linux/pm_runtime.h
-#include plat/map-base.h

  #include drm/drmP.h
  #include drm/exynos_drm.h
@@ -140,15 +141,6 @@ struct fimc_capability {
  };

  /*
- * A structure of fimc driver data.
- *
- * @parent_clk: name of parent clock.
- */
-struct fimc_driverdata {
-   char*parent_clk;
-};
-
-/*
   * A structure of fimc context.
   *
   * @ippdrv: prepare initialization using ippdrv.
@@ -158,6 +150,7 @@ struct fimc_driverdata {
   * @lock: locking of operations.
   * @clocks: fimc clocks.
   * @clk_frequency: LCLK clock frequency.
+ * @sysreg: handle to SYSREG block regmap.
   * @sc: scaler infomations.
   * @pol: porarity of writeback.
   * @id: fimc id.
@@ -172,8 +165,8 @@ struct fimc_context {
struct mutexlock;
struct clk  *clocks[FIMC_CLKS_MAX];
u32 clk_frequency;
+   struct regmap   *sysreg;
struct fimc_scaler  sc;
-   struct fimc_driverdata  *ddata;
struct exynos_drm_ipp_pol   pol;
int id;
int irq;
@@ -217,17 +210,13 @@ static void fimc_sw_reset(struct fimc_context *ctx)
fimc_write(0x0, EXYNOS_CIFCNTSEQ);
  }

-static void fimc_set_camblk_fimd0_wb(struct fimc_context *ctx)
+static int fimc_set_camblk_fimd0_wb(struct fimc_context *ctx)
  {
-   u32 camblk_cfg;
-
DRM_DEBUG_KMS(%s\n, __func__);

-   camblk_cfg = readl(SYSREG_CAMERA_BLK);
-   camblk_cfg = ~(SYSREG_FIMD0WB_DEST_MASK);
-   camblk_cfg |= ctx-id  (SYSREG_FIMD0WB_DEST_SHIFT);
-
-   writel(camblk_cfg, SYSREG_CAMERA_BLK);
+   return regmap_update_bits(ctx-sysreg, SYSREG_CAMERA_BLK,
+ SYSREG_FIMD0WB_DEST_MASK,
+ ctx-id  SYSREG_FIMD0WB_DEST_SHIFT);
  }

  static void fimc_set_type_ctrl(struct fimc_context *ctx, enum fimc_wb wb)
@@ -1628,7 +1617,9 @@ static int fimc_ippdrv_start(struct device *dev, enum 
drm_exynos_ipp_cmd cmd)
fimc_handle_lastend(ctx, true);

/* setup FIMD */
-   fimc_set_camblk_fimd0_wb(ctx);
+   ret = fimc_set_camblk_fimd0_wb(ctx);
+   if (ret  0)


- please adds error log information for indicating error.


+   return ret;

set_wb.enable = 1;
set_wb.refresh = property-refresh_rate;
@@ -1784,26 +1775,50 @@ e_clk_free:
return ret;
  }

+static int fimc_parse_dt(struct fimc_context *ctx)
+{
+   struct device_node *node = ctx-dev-of_node;
+
+   if (!of_property_read_bool(node, samsung,lcd-wb))


- It also need error log ?


+

Re: UVD status on loongson 3a platform

2013-04-19 Thread Huacai Chen

Due to platform limitation, Loongson-3a use 16KB page, and X86 use 4KB
page, maybe this has some relationship with the video mosaic?


On Fri, Apr 19, 2013 at 4:51 PM, Chen Jie ch...@lemote.com wrote:

 Hi all,

 Recently, the uvd supporting is released, and we've tried it on
 loongson 3a platform.
 Brief introduction about loongson 3a, it's a MIPS III compatible, 4
 cores processor.

 More details about the platform [1]:
 * The Board: RS780E + SB710 chipset, with an AMD radeon HD6570 video card
 * The kernel is 64bits(n64 ABI), and the userland is 32bits(o32 ABI)
 * OS: LOonux 3.3.6 [2] + LTP-uvd-installer-20130419.bin [3]
 ** kernel: 3.9 + uvd related patches
 ** mesa: git master version (d0e9aa)

 We tried three video samples:
 * big_buck_bunny_1080p_h264.mov
 (
 http://mirrorblender.top-ix.org/peach/bigbuckbunny_movies/big_buck_bunny_1080p_h264.mov
 )
 * Sintel.2010.2K.x264-VODO.mp4
 (
 http://dev.lemote.com/files/upload/software/UVD-debug/Sintel.2010.2K.x264-VODO.mp4
 )
 * test.avi (http://dev.lemote.com/files/upload/software/UVD-debug/test.avi
 )

 For big_buck_bunny_1080p_h264.mov, the playback is not very fluent at
 the beginning, and it has some video mosaic. We've recorded a video
 for it, see
 http://dev.lemote.com/files/upload/software/UVD-debug/bbb-1080P.mp4
 For video mosaic, what could it be caused by?

 For Sintel.2010.2K.x264-VODO.mp4, it has a very long wait for the first
 frame.
 We've also recorded a video for it, see
 http://dev.lemote.com/files/upload/software/UVD-debug/sintel.2K.mp4
 Any idea about the long wait for the first frame?

 For test.avi(video: ITU H.264, 1920x1080), it's playing back
 perfectly! Thanks for the effort on UVD!

 In all of these tests, the CPU usage is around 50%, and all three
 video samples play well on X86 platform with the same video card.

 BTW, 785G also has UVD2.0, is it supported currently? Or will it be
 supported in the near future?



 Regards,

 Chen Jie
 
 [1] http://www.lemote.com/products/computer/fulong/348.html (zh_CN)
 [2] http://dev.lemote.com/653.html (zh_CN)
 [3] http://dev.lemote.com/663.html (zh_CN)
 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: UVD status on loongson 3a platform

On Fri, Apr 19, 2013 at 4:51 AM, Chen Jie ch...@lemote.com wrote:
 Hi all,

 Recently, the uvd supporting is released, and we've tried it on
 loongson 3a platform.
 Brief introduction about loongson 3a, it's a MIPS III compatible, 4
 cores processor.

 More details about the platform [1]:
 * The Board: RS780E + SB710 chipset, with an AMD radeon HD6570 video card
 * The kernel is 64bits(n64 ABI), and the userland is 32bits(o32 ABI)
 * OS: LOonux 3.3.6 [2] + LTP-uvd-installer-20130419.bin [3]
 ** kernel: 3.9 + uvd related patches
 ** mesa: git master version (d0e9aa)

 We tried three video samples:
 * big_buck_bunny_1080p_h264.mov
 (http://mirrorblender.top-ix.org/peach/bigbuckbunny_movies/big_buck_bunny_1080p_h264.mov)
 * Sintel.2010.2K.x264-VODO.mp4
 (http://dev.lemote.com/files/upload/software/UVD-debug/Sintel.2010.2K.x264-VODO.mp4)
 * test.avi (http://dev.lemote.com/files/upload/software/UVD-debug/test.avi)

 For big_buck_bunny_1080p_h264.mov, the playback is not very fluent at
 the beginning, and it has some video mosaic. We've recorded a video
 for it, see 
 http://dev.lemote.com/files/upload/software/UVD-debug/bbb-1080P.mp4
 For video mosaic, what could it be caused by?

 For Sintel.2010.2K.x264-VODO.mp4, it has a very long wait for the first frame.
 We've also recorded a video for it, see
 http://dev.lemote.com/files/upload/software/UVD-debug/sintel.2K.mp4
 Any idea about the long wait for the first frame?

 For test.avi(video: ITU H.264, 1920x1080), it's playing back
 perfectly! Thanks for the effort on UVD!

 In all of these tests, the CPU usage is around 50%, and all three
 video samples play well on X86 platform with the same video card.

 BTW, 785G also has UVD2.0, is it supported currently? Or will it be
 supported in the near future?

Early UVD 2 chips like RS780/880 and RV770 are not yet supported due
to differences in the UVD hardware compared to later generations.  We
are currently looking into supporting UVD on those chips in open
source, but nothing is available yet.

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

[Bug 63714] UVD acceleration does not properly detect kernel support

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

--- Comment #1 from Alex Deucher ag...@yahoo.com ---
You are probably using an old set of kernel patches.  There were several
revisions.  The mesa code checks to see if the kernel is new enough and the
latest kernel patch revision bumps the kernel driver version.  You can get
everything you need from my kernel tree:
http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.10

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 63709] Desktop Effects on 3D desktop environments are jerky/stutter.

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

--- Comment #1 from Alex Deucher ag...@yahoo.com ---
please attach your xorg log and config and dmesg output.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 63730] New: UVD broken on HD5470 by drm/radeon: raise UVD clocks only on demand

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

  Priority: medium
Bug ID: 63730
  Assignee: dri-devel@lists.freedesktop.org
   Summary: UVD broken on HD5470 by drm/radeon: raise UVD clocks
only on demand
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: johannes.hi...@fem.tu-ilmenau.de
  Hardware: Other
Status: NEW
   Version: DRI CVS
 Component: DRM/Radeon
   Product: DRI

commit 6b1932bd23b6f3b3d46a2e23b2fdad4f58142b55 breaks UVD on my HD5470. The
dmesg output with this commit:

Apr 19 15:32:10 localhost kernel: Linux agpgart interface v0.103
Apr 19 15:32:10 localhost kernel: [drm] Initialized drm 1.1.0 20060810
Apr 19 15:32:10 localhost kernel: [drm] radeon kernel modesetting enabled.
Apr 19 15:32:10 localhost kernel: [drm] initializing kernel modesetting (CEDAR
0x1002:0x68E0 0x1025:0x0489).
Apr 19 15:32:10 localhost kernel: [drm] register mmio base: 0xF210
Apr 19 15:32:10 localhost kernel: [drm] register mmio size: 131072
Apr 19 15:32:10 localhost kernel: ATOM BIOS: Acer
Apr 19 15:32:10 localhost kernel: radeon :01:00.0: VRAM: 512M
0x - 0x1FFF (512M used)
Apr 19 15:32:10 localhost kernel: radeon :01:00.0: GTT: 512M
0x2000 - 0x3FFF
Apr 19 15:32:10 localhost kernel: [drm] Detected VRAM RAM=512M, BAR=256M
Apr 19 15:32:10 localhost kernel: [drm] RAM width 64bits DDR
Apr 19 15:32:10 localhost kernel: [TTM] Zone  kernel: Available graphics
memory: 2022516 kiB
Apr 19 15:32:10 localhost kernel: [TTM] Initializing pool allocator
Apr 19 15:32:10 localhost kernel: [TTM] Initializing DMA pool allocator
Apr 19 15:32:10 localhost kernel: [drm] radeon: 512M of VRAM memory ready
Apr 19 15:32:10 localhost kernel: [drm] radeon: 512M of GTT memory ready.
Apr 19 15:32:10 localhost kernel: [drm] Supports vblank timestamp caching Rev 1
(10.10.2010).
Apr 19 15:32:10 localhost kernel: [drm] Driver supports precise vblank
timestamp query.
Apr 19 15:32:10 localhost kernel: radeon :01:00.0: irq 43 for MSI/MSI-X
Apr 19 15:32:10 localhost kernel: radeon :01:00.0: radeon: using MSI.
Apr 19 15:32:10 localhost kernel: [drm] radeon: irq initialized.
Apr 19 15:32:10 localhost kernel: [drm] GART: num cpu pages 131072, num gpu
pages 131072
Apr 19 15:32:10 localhost kernel: [drm] probing gen 2 caps for device 1022:9603
= 300d02/0
Apr 19 15:32:10 localhost kernel: [drm] enabling PCIE gen 2 link speeds,
disable with radeon.pcie_gen2=0
Apr 19 15:32:10 localhost kernel: [drm] Loading CEDAR Microcode
Apr 19 15:32:10 localhost kernel: [drm] PCIE GART of 512M enabled (table at
0x0025D000).
Apr 19 15:32:10 localhost kernel: radeon :01:00.0: WB enabled
Apr 19 15:32:10 localhost kernel: radeon :01:00.0: fence driver on ring 0
use gpu addr 0x2c00 and cpu addr 0x88011a16bc00
Apr 19 15:32:10 localhost kernel: radeon :01:00.0: fence driver on ring 3
use gpu addr 0x2c0c and cpu addr 0x88011a16bc0c
Apr 19 15:32:10 localhost kernel: radeon :01:00.0: fence driver on ring 5
use gpu addr 0x0005c418 and cpu addr 0xc90001e9c418
Apr 19 15:32:10 localhost kernel: [drm] ring test on 0 succeeded in 1 usecs
Apr 19 15:32:10 localhost kernel: [drm] ring test on 3 succeeded in 1 usecs
Apr 19 15:32:10 localhost kernel: ACPI: Deprecated procfs I/F for battery is
loaded, please retry with CONFIG_ACPI_PROCFS_POWER cleared
Apr 19 15:32:10 localhost kernel: ACPI: Battery Slot [BAT1] (battery present)
Apr 19 15:32:10 localhost kernel: [drm:r600_uvd_init] *ERROR* UVD not
responding, trying to reset the VCPU!!!
Apr 19 15:32:10 localhost kernel: [drm:r600_uvd_init] *ERROR* UVD not
responding, trying to reset the VCPU!!!
Apr 19 15:32:10 localhost kernel: [drm:r600_uvd_init] *ERROR* UVD not
responding, trying to reset the VCPU!!!
Apr 19 15:32:10 localhost kernel: [drm:r600_uvd_init] *ERROR* UVD not
responding, trying to reset the VCPU!!!
Apr 19 15:32:10 localhost kernel: [drm:r600_uvd_init] *ERROR* UVD not
responding, trying to reset the VCPU!!!
Apr 19 15:32:10 localhost kernel: [drm:r600_uvd_init] *ERROR* UVD not
responding, trying to reset the VCPU!!!
Apr 19 15:32:10 localhost kernel: [drm:r600_uvd_init] *ERROR* UVD not
responding, trying to reset the VCPU!!!
Apr 19 15:32:10 localhost kernel: [drm:r600_uvd_init] *ERROR* UVD not
responding, trying to reset the VCPU!!!
Apr 19 15:32:10 localhost kernel: [drm:r600_uvd_init] *ERROR* UVD not
responding, trying to reset the VCPU!!!
Apr 19 15:32:10 localhost kernel: [drm:r600_uvd_init] *ERROR* UVD not
responding, trying to reset the VCPU!!!
Apr 19 15:32:10 localhost kernel: [drm:r600_uvd_init] *ERROR* UVD not
responding, giving up!!!
Apr 19 15:32:10 localhost kernel: [drm:evergreen_startup] *ERROR* radeon: error
initializing UVD (-1).
Apr 19 15:32:10 localhost kernel: [drm] Enabling audio support
Apr 19 15:32:10 localhost kernel: [drm] ib

Re: [PATCH 2/3] drm/radeon: clean up audio dto programming

On Fri, Apr 19, 2013 at 2:10 AM, Rafał Miłecki zaj...@gmail.com wrote:
 2013/4/18  alexdeuc...@gmail.com:
 -   switch (radeon_encoder-encoder_id) {
 -   case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_TMDS1:
 -   case ENCODER_OBJECT_ID_INTERNAL_LVTM1:
 -   WREG32_P(R600_AUDIO_TIMING, 0, ~0x301);
 -   break;
 -   case ENCODER_OBJECT_ID_INTERNAL_UNIPHY:
 -   case ENCODER_OBJECT_ID_INTERNAL_UNIPHY1:
 -   case ENCODER_OBJECT_ID_INTERNAL_UNIPHY2:
 -   case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_LVTMA:
 -   WREG32_P(R600_AUDIO_TIMING, 0x100, ~0x301);
 -   break;
 -   default:
 -   dev_err(rdev-dev, Unsupported encoder type 0x%02X\n,
 - radeon_encoder-encoder_id);
 -   return;
 -   }

 Are you sure we can just drop that part?

Yes we should be able to drop that part.  The only relevant bits are
9:8 which allows you to force which DTO is used by the audio block.  0
= auto, 1 = force dto0, 2 = force dto1.  Additionally, that register
doesn't exist on evergreen and newer.  On evergreen and newer there is
a DIG PHY register at the same offset which may explain the display
problems some people are experiencing.


 I'd appreciate waiting with this patch until next week, I'll test it
 over the weekend on my RV620.

Sounds good.

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

[Bug 63709] Desktop Effects on 3D desktop environments are jerky/stutter.

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

--- Comment #2 from equites.v...@gmail.com ---
Created attachment 78239
  -- https://bugs.freedesktop.org/attachment.cgi?id=78239action=edit
Xorg log file

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 63709] Desktop Effects on 3D desktop environments are jerky/stutter.

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

--- Comment #3 from equites.v...@gmail.com ---
Created attachment 78240
  -- https://bugs.freedesktop.org/attachment.cgi?id=78240action=edit
dmesg output

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 63709] Desktop Effects on 3D desktop environments are jerky/stutter.

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

--- Comment #4 from equites.v...@gmail.com ---
Created attachment 78241
  -- https://bugs.freedesktop.org/attachment.cgi?id=78241action=edit
xorg.conf that was tried

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 63714] UVD acceleration does not properly detect kernel support

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

Christian König deathsim...@vodafone.de changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |NOTABUG

--- Comment #2 from Christian König deathsim...@vodafone.de ---
That indeed just sounds like you're kernel is outdated.

The kernel interface changed while merging the patches and the patches in mesa
uses the end result in drm-next-3.10, so it is highly likely that you just have
a outdated kernel.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 63702] tiling2d in radeon trash vdpau UVD textures

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

Christian König deathsim...@vodafone.de changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #3 from Christian König deathsim...@vodafone.de ---
That just looks like incorrect tilling parameters, what did you do to trigger
that?

Did you update anything? Different parameters?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 63730] UVD broken on HD5470 by drm/radeon: raise UVD clocks only on demand

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

--- Comment #1 from Christian König deathsim...@vodafone.de ---
Created attachment 78243
  -- https://bugs.freedesktop.org/attachment.cgi?id=78243action=edit
Possible fix

Does this patch fixes the issue?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [DVO][PATCH] drm/i915: Fall back to bit banging mode for DVO transmitter detection

On Fri, Apr 19, 2013 at 12:54:00PM +0200, David Müller (ELSOFT AG) wrote:
 Daniel Vetter wrote:
  On Fri, Apr 19, 2013 at 10:41:50AM +0200, David Müller (ELSOFT AG) wrote:
  +  /* GMBUS NAK handling seems to be unstable, hence let the
  +   * transmitter detection run in bit banging mode for now.
  +   */
  +  intel_gmbus_force_bit(i2c, true);
  +
  +  dvoinit = dvo-dev_ops-init(intel_dvo-dev, i2c);
  +
  +  intel_gmbus_force_bit(i2c, false);
  
  Shouldn't we keep the dvo i2c line in bit-banging mode always, i.e.
  restore gmbus mode only when dvo init failed?
  
  I suspect that for fickle hw not just init will fail ...
 
 As far as i can tell, the critical part is the NAK handling.

Ok, I've merged the patch for 3.10 with cc: stable.

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 63702] tiling2d in radeon trash vdpau UVD textures

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

--- Comment #4 from Rafael Castillo jrch2...@gmail.com ---
i just emerged mesa/drm/llvm git i did not modify the source code

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: UVD status on loongson 3a platform