[Bug 58042] New: Garbled UI in Team Fortress 2 Beta

[bugzilla-daemon]

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

  Priority: medium
Bug ID: 58042
  Assignee: dri-devel@lists.freedesktop.org
   Summary: Garbled UI in Team Fortress 2 Beta
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: d...@stuffit.at
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: git
 Component: Drivers/Gallium/r600
   Product: Mesa

Created attachment 71229
  --> https://bugs.freedesktop.org/attachment.cgi?id=71229&action=edit
Screenshot of UI Problem

With 3.0 Mesa 9.1-devel (git-122dfc5) i get the attached garbled screen output
when starting Linux native Team Fortress 2 Beta client. I tried all of the
visual settings under advanced options but the problem persists. If you need
more input feel free to ask.

-- 
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 58042] Garbled UI in Team Fortress 2 Beta

[bugzilla-daemon]

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

d...@stuffit.at changed:

   What|Removed |Added

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

-- 
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 58042] Garbled UI in Team Fortress 2 Beta

[bugzilla-daemon]

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

--- Comment #1 from d...@stuffit.at ---
Created attachment 71230
  --> https://bugs.freedesktop.org/attachment.cgi?id=71230&action=edit
32bit glxinfo

-- 
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 51381] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting, when disabled via vgaswitcheroo

[bugzilla-daemon]

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





--- Comment #5 from a...@anrd.net  2012-12-09 13:55:11 ---
I now ran the same 3.6.6 kernel as I did before, but now it didn't work there
either, so something else must be wrong. I will do some more testing, but it
seems the kernel is not to blame after all.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 57875] Second Life viewer bad rendering with git-ec83535

[bugzilla-daemon]

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

--- Comment #15 from Stefan Dösinger  ---
Created attachment 71244
  --> https://bugs.freedesktop.org/attachment.cgi?id=71244&action=edit
proposed MESA_clip_disable extension

I've written an extension proposal for a new mesa extension that exposes the
CLIP_DISABLE bit. The proposal is attached, please review and comment. There
are some TODOs I'm not quite sure how to deal with, see the list in "Status".

We can move the extension discussion elsewhere if this bug report isn't the
proper place for it.

-- 
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 58033] [r300g] Black gap artifacts when playing WoW

[bugzilla-daemon]

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

--- Comment #3 from Chris Rankin  ---
(In reply to comment #2)
> Also try reverting the commit e866bd1adea2c3b4971ad68e69c6.

I've tried this, and have also tried RADEON_DEBUG=nohiz,nozmask,nocbzb.
However, I'm still seeing the problem. Interestingly, the problem does not
happen with Fedora's "stock" Mesa drivers mesa-dri-drivers-8.0.4-1.fc17.i686.

-- 
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 22576] [KMS] mesa demo spectex broken on rv280

[bugzilla-daemon]

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

--- Comment #18 from smoki  ---

 I think i've found source of these lighting problems on r200 in this and other
bugs. It is just a typo it seems in r200_state_init.c lit_emit()

 OUT_VEC(atom->cmd[LIT_CMD_1], atom->cmd+LIT_CMD_1+1);

 instead of OUT_VEC it needs to be OUT_SCL:

 OUT_SCL(atom->cmd[LIT_CMD_1], atom->cmd+LIT_CMD_1+1);

 And that fixed tcl lighting emit complitely for me on 9250 card, but of course
that introduce 2 more dwords which atom complain about:

 CS section size missmatch start at (r200_state_init.c,lit_emit,361) 41 vs 39
 CS section end at (r200_state_init.c,lit_emit,364)

 I've turned off check and it stops :), but don't know how to or where to stop
it properly...

 So maybe someone who read this can do that :)?

-- 
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 44499] r280 and xbmc - choppy menu and video playback

[bugzilla-daemon]

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

--- Comment #11 from smoki  ---

 I see Blender is fixed now as in
https://bugs.freedesktop.org/show_bug.cgi?id=47375 , thanks :).

 According to these checks for fog i've also excluded it (ctx->Fog.Enabled)
also for _mesa_meta_Bitmap to test fog test (fog is test from
mesa-demos/tests/fog.c) and then it showed up on screen instantly - otherwise
it needs some 15 seconds to show.

-- 
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: [PATCH -next] drm/exynos/iommu: fix return value check in drm_create_iommu_mapping()

[Inki Dae]

Applied.

Thanks,
Inki Dae

2012/12/7 Wei Yongjun 

> From: Wei Yongjun 
>
> In case of error, function arm_iommu_create_mapping() returns
> ERR_PTR() and never returns NULL. The NULL test in the return
> value check should be replaced with IS_ERR().
>
> Signed-off-by: Wei Yongjun 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_iommu.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_iommu.c
> b/drivers/gpu/drm/exynos/exynos_drm_iommu.c
> index 09db198..3b3d3a6 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_iommu.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_iommu.c
> @@ -56,7 +56,7 @@ int drm_create_iommu_mapping(struct drm_device *drm_dev)
> mapping = arm_iommu_create_mapping(&platform_bus_type,
> priv->da_start,
> priv->da_space_size,
> priv->da_space_order);
> -   if (!mapping)
> +   if (IS_ERR(mapping))
> return -ENOMEM;
>
> dev->dma_parms = devm_kzalloc(dev, sizeof(*dev->dma_parms),
>
>
> ___
> 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

[PATCH v2] drm/exynos: use DMA_ATTR_NO_KERNEL_MAPPING attribute

[Inki Dae]

Changelog v2:
fix argument to dma_mmap_attr function.
- use pages instead of kvaddr because kvaddr is 0 with
  DMA_ATTR_NO_KERNEL_MAPPING.

Changelog v1:
When gem allocation is requested, kernel space mapping isn't needed.
But if need, such as console framebuffer, the physical pages would be
mapped with kernel space though vmap function.

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_buf.c   |   28 ++--
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |   18 +-
 drivers/gpu/drm/exynos/exynos_drm_gem.c   |2 +-
 drivers/gpu/drm/exynos/exynos_drm_gem.h   |2 ++
 4 files changed, 30 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_buf.c 
b/drivers/gpu/drm/exynos/exynos_drm_buf.c
index 72bf97b..2774e9b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_buf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_buf.c
@@ -35,6 +35,7 @@ static int lowlevel_buffer_allocate(struct drm_device *dev,
 {
int ret = 0;
enum dma_attr attr = DMA_ATTR_FORCE_CONTIGUOUS;
+   unsigned int nr_pages;
 
DRM_DEBUG_KMS("%s\n", __FILE__);
 
@@ -49,40 +50,31 @@ static int lowlevel_buffer_allocate(struct drm_device *dev,
attr = DMA_ATTR_WRITE_COMBINE;
 
dma_set_attr(attr, &buf->dma_attrs);
+   dma_set_attr(DMA_ATTR_NO_KERNEL_MAPPING, &buf->dma_attrs);
 
-   buf->kvaddr = dma_alloc_attrs(dev->dev, buf->size,
+   buf->pages = dma_alloc_attrs(dev->dev, buf->size,
&buf->dma_addr, GFP_KERNEL, &buf->dma_attrs);
-   if (!buf->kvaddr) {
+   if (!buf->pages) {
DRM_ERROR("failed to allocate buffer.\n");
return -ENOMEM;
}
 
-   buf->sgt = kzalloc(sizeof(struct sg_table), GFP_KERNEL);
+   nr_pages = buf->size >> PAGE_SHIFT;
+   buf->sgt = drm_prime_pages_to_sg(buf->pages, nr_pages);
if (!buf->sgt) {
-   DRM_ERROR("failed to allocate sg table.\n");
+   DRM_ERROR("failed to get sg table.\n");
ret = -ENOMEM;
goto err_free_attrs;
}
 
-   ret = dma_get_sgtable(dev->dev, buf->sgt, buf->kvaddr, buf->dma_addr,
-   buf->size);
-   if (ret < 0) {
-   DRM_ERROR("failed to get sgtable.\n");
-   goto err_free_sgt;
-   }
-
-   DRM_DEBUG_KMS("vaddr(0x%lx), dma_addr(0x%lx), size(0x%lx)\n",
-   (unsigned long)buf->kvaddr,
+   DRM_DEBUG_KMS("dma_addr(0x%lx), size(0x%lx)\n",
(unsigned long)buf->dma_addr,
buf->size);
 
return ret;
 
-err_free_sgt:
-   kfree(buf->sgt);
-   buf->sgt = NULL;
 err_free_attrs:
-   dma_free_attrs(dev->dev, buf->size, buf->kvaddr,
+   dma_free_attrs(dev->dev, buf->size, buf->pages,
(dma_addr_t)buf->dma_addr, &buf->dma_attrs);
buf->dma_addr = (dma_addr_t)NULL;
 
@@ -109,7 +101,7 @@ static void lowlevel_buffer_deallocate(struct drm_device 
*dev,
kfree(buf->sgt);
buf->sgt = NULL;
 
-   dma_free_attrs(dev->dev, buf->size, buf->kvaddr,
+   dma_free_attrs(dev->dev, buf->size, buf->pages,
(dma_addr_t)buf->dma_addr, &buf->dma_attrs);
buf->dma_addr = (dma_addr_t)NULL;
 }
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index 885ef23..f433eb7 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -65,7 +65,7 @@ static int exynos_drm_fb_mmap(struct fb_info *info,
if (vm_size > buffer->size)
return -EINVAL;
 
-   ret = dma_mmap_attrs(helper->dev->dev, vma, buffer->kvaddr,
+   ret = dma_mmap_attrs(helper->dev->dev, vma, buffer->pages,
buffer->dma_addr, buffer->size, &buffer->dma_attrs);
if (ret < 0) {
DRM_ERROR("failed to mmap.\n");
@@ -109,6 +109,17 @@ static int exynos_drm_fbdev_update(struct drm_fb_helper 
*helper,
return -EFAULT;
}
 
+   /* map pages with kernel virtual space. */
+   if (!buffer->kvaddr) {
+   unsigned int nr_pages = buffer->size >> PAGE_SHIFT;
+   buffer->kvaddr = vmap(buffer->pages, nr_pages, VM_MAP,
+   pgprot_writecombine(PAGE_KERNEL));
+   if (!buffer->kvaddr) {
+   DRM_ERROR("failed to map pages to kernel space.\n");
+   return -EIO;
+   }
+   }
+
/* buffer count to framebuffer always is 1 at booting time. */
exynos_drm_fb_set_buf_cnt(fb, 1);
 
@@ -305,8 +316,13 @@ err_init:
 static void exynos_drm_fbdev_destroy(struct drm_device *dev,
  struct drm_fb_helper *fb_helper)
 {
+   struct exynos_drm_fbdev *exynos_fbd = to_exynos_fbdev(fb_helper);
+   struct exynos_drm_gem_obj *exyno

Re: [PATCH v2] drm/exynos: use prime helpers

[Inki Dae]

2012/12/8 Aaron Plattner 

> On 12/06/2012 10:36 PM, Inki Dae wrote:
>
>>
>> Hi,
>>
>> CCing media guys.
>>
>> I agree with you but we should consider one issue released to v4l2.
>>
>> As you may know, V4L2-based driver uses vb2 as buffer manager and the
>> vb2 includes dmabuf feature>(import and export) And v4l2 uses streaming
>> concept>(qbuf and dqbuf)
>> With dmabuf and iommu, generally qbuf imports a fd into its own buffer
>> and maps it with its own iommu table calling dma_buf_map_attachment().
>> And dqbuf calls dma_buf_unmap_attachment() to unmap that buffer from its
>> own iommu table.
>> But now vb2's unmap_dma_buf callback is nothing to do. I think that the
>> reason is the below issue,
>>
>> If qbuf maps buffer with iomm table and dqbuf unmaps it from iommu table
>> then it has performance deterioration because qbuf and dqbuf are called
>> repeatedly.
>> And this means map/unmap are repeated also. So I think media guys moved
>> dma_unmap_sg call from its own unmap_dma_buf callback to detach callback
>> instead.
>> For this, you can refer to vb2_dc_dmabuf_ops_unmap and
>> vb2_dc_dmabuf_ops_detach function.
>>
>> So I added the below patch to avoid that performance deterioration and
>> am testing it now.(this patch is derived from videobuf2-dma-contig.c)
>> http://git.kernel.org/?p=**linux/kernel/git/daeinki/drm-**
>> exynos.git;a=commit;h=**576b1c3de8b90cf1570b8418b60afd**1edaae4e30
>>
>> Thus, I'm not sure that your common set could cover all the cases
>> including other frameworks. Please give me any opinions.
>>
>
> It seems like this adjustment would make perfect sense to add to the
> helper layer I suggested.  E.g., instead of having an exynos_attach
> structure that caches the sgt, there'd be a struct drm_gem_prime_attach
> that would do the same thing, and save the sgt it gets from
> driver->gem_prime_get_sg.  Then it would benefit nouveau and radeon, too.
>

If this change is applied to common helper and also that could be accepted
by other maintainers then I think it's better to use this common helper
instead of specific one.


>
> Alternatively, patch #4 could be dropped and Exynos can continue to
> reimplement all of this core functionality, since the helpers are optional,
> but I don't see anything about this change that should make it
> Exynos-specific,


I agree with you. I also think this change isn't specific to Exynos. But
you need to check if this is a reasonable change for other drivers also.

Thanks,
Inki Dae


> unless I'm missing something.
>
>
--
> Aaron
>
> __**_
> 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

[Bug 50655] ATI RV670 [Radeon HD 3870] Ioquake games causes GPU lockup (waiting for 0x00003039 last fence id 0x00003030)

[bugzilla-daemon]

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

Bryan Quigley  changed:

   What|Removed |Added

  Attachment #62475|application/octet-stream|text/plain
  mime type||

-- 
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 50655] ATI RV670 [Radeon HD 3870] Ioquake games causes GPU lockup (waiting for 0x00003039 last fence id 0x00003030)

[bugzilla-daemon]

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

Bryan Quigley  changed:

   What|Removed |Added

  Attachment #62689|application/octet-stream|text/plain
  mime type||

-- 
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 50655] ATI RV670 [Radeon HD 3870] Ioquake games causes GPU lockup (waiting for 0x00003039 last fence id 0x00003030)

[bugzilla-daemon]

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

Bryan Quigley  changed:

   What|Removed |Added

  Attachment #66047|application/octet-stream|text/plain
  mime type||

-- 
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 50655] ATI RV670 [Radeon HD 3870] Ioquake games causes GPU lockup (waiting for 0x00003039 last fence id 0x00003030)

[bugzilla-daemon]

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

Bryan Quigley  changed:

   What|Removed |Added

  Attachment #62474|application/octet-stream|text/plain
  mime type||

-- 
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 50655] ATI RV670 [Radeon HD 3870] Ioquake games causes GPU lockup (waiting for 0x00003039 last fence id 0x00003030)

[bugzilla-daemon]

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

--- Comment #19 from Bryan Quigley  ---
Would any other output help debug this?  Register dumps using avivotool?

-- 
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: [PATCH -next] drm/exynos/iommu: fix return value check in drm_create_iommu_mapping()

[김승우]

On 2012년 12월 07일 21:50, Wei Yongjun wrote:
> From: Wei Yongjun 
> 
> In case of error, function arm_iommu_create_mapping() returns
> ERR_PTR() and never returns NULL. The NULL test in the return
> value check should be replaced with IS_ERR().
> 
> Signed-off-by: Wei Yongjun 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_iommu.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_iommu.c 
> b/drivers/gpu/drm/exynos/exynos_drm_iommu.c
> index 09db198..3b3d3a6 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_iommu.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_iommu.c
> @@ -56,7 +56,7 @@ int drm_create_iommu_mapping(struct drm_device *drm_dev)
>   mapping = arm_iommu_create_mapping(&platform_bus_type, priv->da_start,
>   priv->da_space_size,
>   priv->da_space_order);
> - if (!mapping)
> + if (IS_ERR(mapping))
>   return -ENOMEM;

One more fix is needed here.
-   return -ENOMEM;
+   return PTR_ERR(mapping);

>  
>   dev->dma_parms = devm_kzalloc(dev, sizeof(*dev->dma_parms),
> 
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
> 

-- 
Seung-Woo Kim
Samsung Software R&D Center
--

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

Re: [PATCH 0/3] add mie driver for exynos

[Inki Dae]

2012/12/6 R. Chandrasekar 

> From: "R. Chandrasekar" 
>
> this patch set adds the driver support for the dithering functionality of
> the
> mobile image enhancement (mie) module.
>
> device tree support is added for mie.
>
> fimd adds the mie module as plugin and calls the dithering function.
> dithere is
> required when the panels bpp is less then fimd output.
>
> though mie mie has other functionalities, current system uses only
> dithereing.
>
>
Please, move mie module into drivers/video/exynos. The mie is a interface
between fimd and lcd panel(or mipi-dsi, eDP) to enhance image to be
displayed. And it seems like that this doesn't need drm framework-relevant
interfaces, such as gem.

And also, please refer to the below link, Common Display Framework, for
more generic way.

http://lists.freedesktop.org/archives/dri-devel/2012-November/030888.html

Thanks,
Inki Dae


> R. Chandrasekar (3):
>   DTS: exynos: add device tree support for exynos mie
>   drm: fimd: add mie plugin support for dithering
>   drm: mie: add mie driver for exynos
>
>  arch/arm/boot/dts/exynos5250.dtsi   |7 +-
>  drivers/gpu/drm/exynos/Kconfig  |7 +
>  drivers/gpu/drm/exynos/Makefile |1 +
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c|   58 +-
>  drivers/gpu/drm/exynos/exynos_drm_fimd_common.h |   20 ++
>  drivers/gpu/drm/exynos/exynos_drm_mie.c |  250
> +++
>  drivers/gpu/drm/exynos/exynos_drm_mie.h |   50 +
>  drivers/gpu/drm/exynos/exynos_regs-mie.h|   75 +++
>  8 files changed, 465 insertions(+), 3 deletions(-)
>  create mode 100644 drivers/gpu/drm/exynos/exynos_drm_fimd_common.h
>  create mode 100644 drivers/gpu/drm/exynos/exynos_drm_mie.c
>  create mode 100644 drivers/gpu/drm/exynos/exynos_drm_mie.h
>  create mode 100644 drivers/gpu/drm/exynos/exynos_regs-mie.h
>
> --
> 1.7.9.5
>
> ___
> 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: [PATCH -next] drm/exynos/iommu: fix return value check in drm_create_iommu_mapping()

[Inki Dae]

> -Original Message-
> From: 김승우 [mailto:sw0312@samsung.com]
> Sent: Monday, December 10, 2012 3:14 PM
> To: Wei Yongjun
> Cc: inki@samsung.com; jy0922.s...@samsung.com;
> kyungmin.p...@samsung.com; airl...@linux.ie; yongjun_...@trendmicro.com.cn;
> linux-ker...@vger.kernel.org; dri-devel@lists.freedesktop.org;
> sw0312@samsung.com
> Subject: Re: [PATCH -next] drm/exynos/iommu: fix return value check in
> drm_create_iommu_mapping()
> 
> 
> 
> On 2012년 12월 07일 21:50, Wei Yongjun wrote:
> > From: Wei Yongjun 
> >
> > In case of error, function arm_iommu_create_mapping() returns
> > ERR_PTR() and never returns NULL. The NULL test in the return
> > value check should be replaced with IS_ERR().
> >
> > Signed-off-by: Wei Yongjun 
> > ---
> >  drivers/gpu/drm/exynos/exynos_drm_iommu.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_iommu.c
> b/drivers/gpu/drm/exynos/exynos_drm_iommu.c
> > index 09db198..3b3d3a6 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_iommu.c
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_iommu.c
> > @@ -56,7 +56,7 @@ int drm_create_iommu_mapping(struct drm_device
> *drm_dev)
> > mapping = arm_iommu_create_mapping(&platform_bus_type, priv-
> >da_start,
> > priv->da_space_size,
> > priv->da_space_order);
> > -   if (!mapping)
> > +   if (IS_ERR(mapping))
> > return -ENOMEM;
> 
> One more fix is needed here.
> - return -ENOMEM;
> + return PTR_ERR(mapping);

Oh, good point, I missed. Please re-send it.

Thanks,
Inki Dae

> 
> >
> > dev->dma_parms = devm_kzalloc(dev, sizeof(*dev->dma_parms),
> >
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
> 
> --
> Seung-Woo Kim
> Samsung Software R&D Center
> --

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

[PATCH v3] drm/exynos: use DMA_ATTR_NO_KERNEL_MAPPING attribute

[Inki Dae]

Changelog v3:
just code cleanup.

Changelog v2:
fix argument to dma_mmap_attr function.
- use pages instead of kvaddr because kvaddr is 0 with
  DMA_ATTR_NO_KERNEL_MAPPING.

Changelog v1:
When gem allocation is requested, kernel space mapping isn't needed.
But if need, such as console framebuffer, the physical pages would be
mapped with kernel space though vmap function.

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_buf.c   |   31 ++--
 drivers/gpu/drm/exynos/exynos_drm_fb.c|4 +--
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |   18 +++-
 drivers/gpu/drm/exynos/exynos_drm_gem.c   |2 +-
 drivers/gpu/drm/exynos/exynos_drm_gem.h   |2 +
 5 files changed, 32 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_buf.c 
b/drivers/gpu/drm/exynos/exynos_drm_buf.c
index 72bf97b..9732043 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_buf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_buf.c
@@ -35,6 +35,7 @@ static int lowlevel_buffer_allocate(struct drm_device *dev,
 {
int ret = 0;
enum dma_attr attr = DMA_ATTR_FORCE_CONTIGUOUS;
+   unsigned int nr_pages;
 
DRM_DEBUG_KMS("%s\n", __FILE__);
 
@@ -49,40 +50,31 @@ static int lowlevel_buffer_allocate(struct drm_device *dev,
attr = DMA_ATTR_WRITE_COMBINE;
 
dma_set_attr(attr, &buf->dma_attrs);
+   dma_set_attr(DMA_ATTR_NO_KERNEL_MAPPING, &buf->dma_attrs);
 
-   buf->kvaddr = dma_alloc_attrs(dev->dev, buf->size,
+   buf->pages = dma_alloc_attrs(dev->dev, buf->size,
&buf->dma_addr, GFP_KERNEL, &buf->dma_attrs);
-   if (!buf->kvaddr) {
+   if (!buf->pages) {
DRM_ERROR("failed to allocate buffer.\n");
return -ENOMEM;
}
 
-   buf->sgt = kzalloc(sizeof(struct sg_table), GFP_KERNEL);
+   nr_pages = buf->size >> PAGE_SHIFT;
+   buf->sgt = drm_prime_pages_to_sg(buf->pages, nr_pages);
if (!buf->sgt) {
-   DRM_ERROR("failed to allocate sg table.\n");
+   DRM_ERROR("failed to get sg table.\n");
ret = -ENOMEM;
goto err_free_attrs;
}
 
-   ret = dma_get_sgtable(dev->dev, buf->sgt, buf->kvaddr, buf->dma_addr,
-   buf->size);
-   if (ret < 0) {
-   DRM_ERROR("failed to get sgtable.\n");
-   goto err_free_sgt;
-   }
-
-   DRM_DEBUG_KMS("vaddr(0x%lx), dma_addr(0x%lx), size(0x%lx)\n",
-   (unsigned long)buf->kvaddr,
+   DRM_DEBUG_KMS("dma_addr(0x%lx), size(0x%lx)\n",
(unsigned long)buf->dma_addr,
buf->size);
 
return ret;
 
-err_free_sgt:
-   kfree(buf->sgt);
-   buf->sgt = NULL;
 err_free_attrs:
-   dma_free_attrs(dev->dev, buf->size, buf->kvaddr,
+   dma_free_attrs(dev->dev, buf->size, buf->pages,
(dma_addr_t)buf->dma_addr, &buf->dma_attrs);
buf->dma_addr = (dma_addr_t)NULL;
 
@@ -99,8 +91,7 @@ static void lowlevel_buffer_deallocate(struct drm_device *dev,
return;
}
 
-   DRM_DEBUG_KMS("vaddr(0x%lx), dma_addr(0x%lx), size(0x%lx)\n",
-   (unsigned long)buf->kvaddr,
+   DRM_DEBUG_KMS("dma_addr(0x%lx), size(0x%lx)\n",
(unsigned long)buf->dma_addr,
buf->size);
 
@@ -109,7 +100,7 @@ static void lowlevel_buffer_deallocate(struct drm_device 
*dev,
kfree(buf->sgt);
buf->sgt = NULL;
 
-   dma_free_attrs(dev->dev, buf->size, buf->kvaddr,
+   dma_free_attrs(dev->dev, buf->size, buf->pages,
(dma_addr_t)buf->dma_addr, &buf->dma_attrs);
buf->dma_addr = (dma_addr_t)NULL;
 }
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c 
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index 7413f4b..764571c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -297,9 +297,7 @@ struct exynos_drm_gem_buf *exynos_drm_fb_buffer(struct 
drm_framebuffer *fb,
if (!buffer)
return NULL;
 
-   DRM_DEBUG_KMS("vaddr = 0x%lx, dma_addr = 0x%lx\n",
-   (unsigned long)buffer->kvaddr,
-   (unsigned long)buffer->dma_addr);
+   DRM_DEBUG_KMS("dma_addr = 0x%lx\n", (unsigned long)buffer->dma_addr);
 
return buffer;
 }
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index 885ef23..f433eb7 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -65,7 +65,7 @@ static int exynos_drm_fb_mmap(struct fb_info *info,
if (vm_size > buffer->size)
return -EINVAL;
 
-   ret = dma_mmap_attrs(helper->dev->dev, vma, buffer->kvaddr,
+   ret = dma_mmap_attrs(helper->dev->dev, vma, buffer->pages,
buffer->dma_addr,

[PATCH] drm/exynos: remove unused vaddr member

[Inki Dae]

From: YoungJun Cho 

This patch removes vaddr member from exynos_drm_overlay structure
and also relevant codes for code cleanup.

Signed-off-by: YoungJun Cho 
Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |2 --
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  |6 +-
 drivers/gpu/drm/exynos/exynos_drm_plane.c |6 ++
 drivers/gpu/drm/exynos/exynos_drm_vidi.c  |6 +-
 drivers/gpu/drm/exynos/exynos_mixer.c |4 
 5 files changed, 4 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 5a8c1f2..e4ea74d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -107,7 +107,6 @@ struct exynos_drm_overlay_ops {
  * @pixel_format: fourcc pixel format of this overlay
  * @dma_addr: array of bus(accessed by dma) address to the memory region
  *   allocated for a overlay.
- * @vaddr: array of virtual memory addresss to this overlay.
  * @zpos: order of overlay layer(z position).
  * @default_win: a window to be enabled.
  * @color_key: color key on or off.
@@ -139,7 +138,6 @@ struct exynos_drm_overlay {
unsigned int pitch;
uint32_t pixel_format;
dma_addr_t dma_addr[MAX_FB_BUFFER];
-   void __iomem *vaddr[MAX_FB_BUFFER];
int zpos;
 
bool default_win;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 7e66032..90ca4b2 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -79,7 +79,6 @@ struct fimd_win_data {
unsigned intfb_height;
unsigned intbpp;
dma_addr_t  dma_addr;
-   void __iomem*vaddr;
unsigned intbuf_offsize;
unsigned intline_size;  /* bytes */
boolenabled;
@@ -375,7 +374,6 @@ static void fimd_win_mode_set(struct device *dev,
win_data->fb_width = overlay->fb_width;
win_data->fb_height = overlay->fb_height;
win_data->dma_addr = overlay->dma_addr[0] + offset;
-   win_data->vaddr = overlay->vaddr[0] + offset;
win_data->bpp = overlay->bpp;
win_data->buf_offsize = (overlay->fb_width - overlay->crtc_width) *
(overlay->bpp >> 3);
@@ -385,9 +383,7 @@ static void fimd_win_mode_set(struct device *dev,
win_data->offset_x, win_data->offset_y);
DRM_DEBUG_KMS("ovl_width = %d, ovl_height = %d\n",
win_data->ovl_width, win_data->ovl_height);
-   DRM_DEBUG_KMS("paddr = 0x%lx, vaddr = 0x%lx\n",
-   (unsigned long)win_data->dma_addr,
-   (unsigned long)win_data->vaddr);
+   DRM_DEBUG_KMS("paddr = 0x%lx\n", (unsigned long)win_data->dma_addr);
DRM_DEBUG_KMS("fb_width = %d, crtc_width = %d\n",
overlay->fb_width, overlay->crtc_width);
 }
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c 
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index 862ca1e..399b026 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -93,11 +93,9 @@ int exynos_plane_mode_set(struct drm_plane *plane, struct 
drm_crtc *crtc,
}
 
overlay->dma_addr[i] = buffer->dma_addr;
-   overlay->vaddr[i] = buffer->kvaddr;
 
-   DRM_DEBUG_KMS("buffer: %d, vaddr = 0x%lx, dma_addr = 0x%lx\n",
-   i, (unsigned long)overlay->vaddr[i],
-   (unsigned long)overlay->dma_addr[i]);
+   DRM_DEBUG_KMS("buffer: %d, dma_addr = 0x%lx\n",
+   i, (unsigned long)overlay->dma_addr[i]);
}
 
actual_w = exynos_plane_get_size(crtc_x, crtc_w, crtc->mode.hdisplay);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c 
b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index 4b0c16b..99bfc38 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -39,7 +39,6 @@ struct vidi_win_data {
unsigned intfb_height;
unsigned intbpp;
dma_addr_t  dma_addr;
-   void __iomem*vaddr;
unsigned intbuf_offsize;
unsigned intline_size;  /* bytes */
boolenabled;
@@ -294,7 +293,6 @@ static void vidi_win_mode_set(struct device *dev,
win_data->fb_width = overlay->fb_width;
win_data->fb_height = overlay->fb_height;
win_data->dma_addr = overlay->dma_addr[0] + offset;
-   win_data->vaddr = overlay->vaddr[0] + offset;
win_data->bpp = overlay->bpp;
win_data->buf_offsize = (overlay->fb_width - overlay->crtc_width) *
(overlay->bpp >> 3);
@@ -309,9

Re: [PATCH v2 linux-next] i915: intel_set_mode: Reduce stack allocation from 500 bytes to 2 pointers

[Jani Nikula]

On Fri, 07 Dec 2012, Tim Gardner  wrote:
> smatch warning:
>
> drivers/gpu/drm/i915/intel_display.c:7019 intel_set_mode() warn: function puts
> 500 bytes on stack
>
> Refactor so that saved_mode and saved_hwmode are dynamically allocated as 
> opposed
> to being automatic variables. 500 bytes seems like it could run the potential 
> for blowing
> the kernel stack.

Reviewed-by: Jani Nikula 


>
> Cc: Daniel Vetter 
> Cc: David Airlie 
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Tim Gardner 
> ---
>
> V2 - spaces around '*', use kmalloc instead of kzalloc(). Missed
> error return that would have orphaned memory.
>
>  drivers/gpu/drm/i915/intel_display.c |   22 --
>  1 file changed, 16 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index de51489..c15b21b 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -7739,11 +7739,18 @@ bool intel_set_mode(struct drm_crtc *crtc,
>  {
>   struct drm_device *dev = crtc->dev;
>   drm_i915_private_t *dev_priv = dev->dev_private;
> - struct drm_display_mode *adjusted_mode, saved_mode, saved_hwmode;
> + struct drm_display_mode *adjusted_mode, *saved_mode, *saved_hwmode;
>   struct intel_crtc *intel_crtc;
>   unsigned disable_pipes, prepare_pipes, modeset_pipes;
>   bool ret = true;
>  
> + saved_mode = kmalloc(2 * sizeof(*saved_mode), GFP_KERNEL);
> + if (!saved_mode) {
> + DRM_ERROR("i915: Could not allocate saved display mode.\n");
> + return false;
> + }
> + saved_hwmode = saved_mode + 1;
> +
>   intel_modeset_affected_pipes(crtc, &modeset_pipes,
>&prepare_pipes, &disable_pipes);
>  
> @@ -7753,8 +7760,8 @@ bool intel_set_mode(struct drm_crtc *crtc,
>   for_each_intel_crtc_masked(dev, disable_pipes, intel_crtc)
>   intel_crtc_disable(&intel_crtc->base);
>  
> - saved_hwmode = crtc->hwmode;
> - saved_mode = crtc->mode;
> + *saved_hwmode = crtc->hwmode;
> + *saved_mode = crtc->mode;
>  
>   /* Hack: Because we don't (yet) support global modeset on multiple
>* crtcs, we don't keep track of the new mode for more than one crtc.
> @@ -7765,7 +7772,8 @@ bool intel_set_mode(struct drm_crtc *crtc,
>   if (modeset_pipes) {
>   adjusted_mode = intel_modeset_adjusted_mode(crtc, mode);
>   if (IS_ERR(adjusted_mode)) {
> - return false;
> + ret = false;
> + goto out;
>   }
>   }
>  
> @@ -7817,12 +7825,14 @@ bool intel_set_mode(struct drm_crtc *crtc,
>  done:
>   drm_mode_destroy(dev, adjusted_mode);
>   if (!ret && crtc->enabled) {
> - crtc->hwmode = saved_hwmode;
> - crtc->mode = saved_mode;
> + crtc->hwmode = *saved_hwmode;
> + crtc->mode = *saved_mode;
>   } else {
>   intel_modeset_check_state(dev);
>   }
>  
> +out:
> + kfree(saved_mode);
>   return ret;
>  }
>  
> -- 
> 1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/3] add mie driver for exynos

[Stéphane Marchesin]

On Sun, Dec 9, 2012 at 10:26 PM, Inki Dae  wrote:
>
>
> 2012/12/6 R. Chandrasekar 
>
>> From: "R. Chandrasekar" 
>>
>> this patch set adds the driver support for the dithering functionality of
>> the
>> mobile image enhancement (mie) module.
>>
>> device tree support is added for mie.
>>
>> fimd adds the mie module as plugin and calls the dithering function.
>> dithere is
>> required when the panels bpp is less then fimd output.
>>
>> though mie mie has other functionalities, current system uses only
>> dithereing.
>>
>
> Please, move mie module into drivers/video/exynos. The mie is a interface
> between fimd and lcd panel(or mipi-dsi, eDP) to enhance image to be
> displayed. And it seems like that this doesn't need drm framework-relevant
> interfaces, such as gem.

Well, if you want to support it from the DRM, it should live in
drivers/gpu/drm, and I don't think you should add another platform
driver in the first place. The profusion of platform drivers in exynos
makes it really difficult to support suspend/resume and initialization
properly as many devices which operate separately need to sync through
global variables.

Stéphane


>
> And also, please refer to the below link, Common Display Framework, for more
> generic way.
>
> http://lists.freedesktop.org/archives/dri-devel/2012-November/030888.html
>
> Thanks,
> Inki Dae
>
>>
>> R. Chandrasekar (3):
>>   DTS: exynos: add device tree support for exynos mie
>>   drm: fimd: add mie plugin support for dithering
>>   drm: mie: add mie driver for exynos
>>
>>  arch/arm/boot/dts/exynos5250.dtsi   |7 +-
>>  drivers/gpu/drm/exynos/Kconfig  |7 +
>>  drivers/gpu/drm/exynos/Makefile |1 +
>>  drivers/gpu/drm/exynos/exynos_drm_fimd.c|   58 +-
>>  drivers/gpu/drm/exynos/exynos_drm_fimd_common.h |   20 ++
>>  drivers/gpu/drm/exynos/exynos_drm_mie.c |  250
>> +++
>>  drivers/gpu/drm/exynos/exynos_drm_mie.h |   50 +
>>  drivers/gpu/drm/exynos/exynos_regs-mie.h|   75 +++
>>  8 files changed, 465 insertions(+), 3 deletions(-)
>>  create mode 100644 drivers/gpu/drm/exynos/exynos_drm_fimd_common.h
>>  create mode 100644 drivers/gpu/drm/exynos/exynos_drm_mie.c
>>  create mode 100644 drivers/gpu/drm/exynos/exynos_drm_mie.h
>>  create mode 100644 drivers/gpu/drm/exynos/exynos_regs-mie.h
>>
>> --
>> 1.7.9.5
>>
>> ___
>> 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
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/1] drm/i915: Remove duplicate inclusion of drm/drm_edid.h

[Jani Nikula]

On Fri, 07 Dec 2012, Sachin Kamat  wrote:
> drm/drm_edid.h was included twice.

Reviewed-by: Jani Nikula 

>
> Signed-off-by: Sachin Kamat 
> ---
>  drivers/gpu/drm/i915/intel_modes.c |1 -
>  1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_modes.c 
> b/drivers/gpu/drm/i915/intel_modes.c
> index b00f1c8..49249bb 100644
> --- a/drivers/gpu/drm/i915/intel_modes.c
> +++ b/drivers/gpu/drm/i915/intel_modes.c
> @@ -28,7 +28,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include "intel_drv.h"
>  #include "i915_drv.h"
>  
> -- 
> 1.7.4.1
>
> ___
> 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

[Bug 58042] New: Garbled UI in Team Fortress 2 Beta

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

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

  Priority: medium
Bug ID: 58042
  Assignee: dri-devel at lists.freedesktop.org
   Summary: Garbled UI in Team Fortress 2 Beta
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: dev at stuffit.at
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: git
 Component: Drivers/Gallium/r600
   Product: Mesa

Created attachment 71229
  --> https://bugs.freedesktop.org/attachment.cgi?id=71229&action=edit
Screenshot of UI Problem

With 3.0 Mesa 9.1-devel (git-122dfc5) i get the attached garbled screen output
when starting Linux native Team Fortress 2 Beta client. I tried all of the
visual settings under advanced options but the problem persists. If you need
more input feel free to ask.

-- 
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/20121209/5c18ca60/attachment.html>

[Bug 58042] Garbled UI in Team Fortress 2 Beta

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

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

dev at stuffit.at changed:

   What|Removed |Added

  Attachment #71229|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/20121209/bb1e0901/attachment.html>

[Bug 58042] Garbled UI in Team Fortress 2 Beta

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

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

--- Comment #1 from dev at stuffit.at ---
Created attachment 71230
  --> https://bugs.freedesktop.org/attachment.cgi?id=71230&action=edit
32bit glxinfo

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121209/366a186c/attachment.html>

[Bug 51381] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting, when disabled via vgaswitcheroo

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

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





--- Comment #5 from a at anrd.net  2012-12-09 13:55:11 ---
I now ran the same 3.6.6 kernel as I did before, but now it didn't work there
either, so something else must be wrong. I will do some more testing, but it
seems the kernel is not to blame after all.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 57875] Second Life viewer bad rendering with git-ec83535

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

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

--- Comment #15 from Stefan D?singer  ---
Created attachment 71244
  --> https://bugs.freedesktop.org/attachment.cgi?id=71244&action=edit
proposed MESA_clip_disable extension

I've written an extension proposal for a new mesa extension that exposes the
CLIP_DISABLE bit. The proposal is attached, please review and comment. There
are some TODOs I'm not quite sure how to deal with, see the list in "Status".

We can move the extension discussion elsewhere if this bug report isn't the
proper place for it.

-- 
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/20121209/d1ff2827/attachment.html>

[Bug 58033] [r300g] Black gap artifacts when playing WoW

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

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

--- Comment #3 from Chris Rankin  ---
(In reply to comment #2)
> Also try reverting the commit e866bd1adea2c3b4971ad68e69c6.

I've tried this, and have also tried RADEON_DEBUG=nohiz,nozmask,nocbzb.
However, I'm still seeing the problem. Interestingly, the problem does not
happen with Fedora's "stock" Mesa drivers mesa-dri-drivers-8.0.4-1.fc17.i686.

-- 
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/20121209/39276021/attachment.html>

[Bug 22576] [KMS] mesa demo spectex broken on rv280

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

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

--- Comment #18 from smoki  ---

 I think i've found source of these lighting problems on r200 in this and other
bugs. It is just a typo it seems in r200_state_init.c lit_emit()

 OUT_VEC(atom->cmd[LIT_CMD_1], atom->cmd+LIT_CMD_1+1);

 instead of OUT_VEC it needs to be OUT_SCL:

 OUT_SCL(atom->cmd[LIT_CMD_1], atom->cmd+LIT_CMD_1+1);

 And that fixed tcl lighting emit complitely for me on 9250 card, but of course
that introduce 2 more dwords which atom complain about:

 CS section size missmatch start at (r200_state_init.c,lit_emit,361) 41 vs 39
 CS section end at (r200_state_init.c,lit_emit,364)

 I've turned off check and it stops :), but don't know how to or where to stop
it properly...

 So maybe someone who read this can do that :)?

-- 
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/20121209/9d70c055/attachment.html>

[Bug 44499] r280 and xbmc - choppy menu and video playback

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

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

--- Comment #11 from smoki  ---

 I see Blender is fixed now as in
https://bugs.freedesktop.org/show_bug.cgi?id=47375 , thanks :).

 According to these checks for fog i've also excluded it (ctx->Fog.Enabled)
also for _mesa_meta_Bitmap to test fog test (fog is test from
mesa-demos/tests/fog.c) and then it showed up on screen instantly - otherwise
it needs some 15 seconds to show.

-- 
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/20121209/ceafa2e1/attachment.html>

[PATCH 0/3] add mie driver for exynos

[Stéphane Marchesin]

On Sun, Dec 9, 2012 at 10:26 PM, Inki Dae  wrote:
>
>
> 2012/12/6 R. Chandrasekar 
>
>> From: "R. Chandrasekar" 
>>
>> this patch set adds the driver support for the dithering functionality of
>> the
>> mobile image enhancement (mie) module.
>>
>> device tree support is added for mie.
>>
>> fimd adds the mie module as plugin and calls the dithering function.
>> dithere is
>> required when the panels bpp is less then fimd output.
>>
>> though mie mie has other functionalities, current system uses only
>> dithereing.
>>
>
> Please, move mie module into drivers/video/exynos. The mie is a interface
> between fimd and lcd panel(or mipi-dsi, eDP) to enhance image to be
> displayed. And it seems like that this doesn't need drm framework-relevant
> interfaces, such as gem.

Well, if you want to support it from the DRM, it should live in
drivers/gpu/drm, and I don't think you should add another platform
driver in the first place. The profusion of platform drivers in exynos
makes it really difficult to support suspend/resume and initialization
properly as many devices which operate separately need to sync through
global variables.

St?phane


>
> And also, please refer to the below link, Common Display Framework, for more
> generic way.
>
> http://lists.freedesktop.org/archives/dri-devel/2012-November/030888.html
>
> Thanks,
> Inki Dae
>
>>
>> R. Chandrasekar (3):
>>   DTS: exynos: add device tree support for exynos mie
>>   drm: fimd: add mie plugin support for dithering
>>   drm: mie: add mie driver for exynos
>>
>>  arch/arm/boot/dts/exynos5250.dtsi   |7 +-
>>  drivers/gpu/drm/exynos/Kconfig  |7 +
>>  drivers/gpu/drm/exynos/Makefile |1 +
>>  drivers/gpu/drm/exynos/exynos_drm_fimd.c|   58 +-
>>  drivers/gpu/drm/exynos/exynos_drm_fimd_common.h |   20 ++
>>  drivers/gpu/drm/exynos/exynos_drm_mie.c |  250
>> +++
>>  drivers/gpu/drm/exynos/exynos_drm_mie.h |   50 +
>>  drivers/gpu/drm/exynos/exynos_regs-mie.h|   75 +++
>>  8 files changed, 465 insertions(+), 3 deletions(-)
>>  create mode 100644 drivers/gpu/drm/exynos/exynos_drm_fimd_common.h
>>  create mode 100644 drivers/gpu/drm/exynos/exynos_drm_mie.c
>>  create mode 100644 drivers/gpu/drm/exynos/exynos_drm_mie.h
>>  create mode 100644 drivers/gpu/drm/exynos/exynos_regs-mie.h
>>
>> --
>> 1.7.9.5
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

[BUG]: Random kernel crashes when using Xorg with radeon module

[Carla Sella]

Summary of the problem:
Random kernel crashes when using Xorg with radeon module

Description:
Kernel crash at ubuntu user logon or "startx".
There are also a lot of red spots and signs on the monitor, see bug on 
launchpad.
https://bugs.launchpad.net/bugs/1085187


Keywords: radeon HD 6770, kms, drm, kernel-oops, crash, hw-specific, 
ATI,

Kernel version: Linux version 3.7.0-rc8-custom+ (root at duex) (gcc version 
4.7.2 (Ubuntu/Linaro 4.7.2-12ubuntu2) ) #1 SMP Sat Dec 8 18:00:39 CET 2012

See attached kernel log (crlog1.txt and crlog2.txt) output taken via 
kdump mechanism

Environment: Ubuntu Raring Ringtail (development branch) - Release: 13.04

Software: See attached si_ver_linux.txt for the output of ver_linux script

Processor information: See attached si_cpuinfo.txt for /proc/cpuinfo

Module information: See attached si_proc_modules.txt for /proc/modules

Loaded driver and hardware information: See attached si_proc_ioports.txt 
for /proc/ioports - See attached si_proc_iomem.txt for /proc/iomem

PCI information: See attached si_lspci.txt for lspci -vvv

SCSI information: See attached si_proc_scsi_scsi.txt for /proc/scsi/scsi

See attached si_ls_proc.txt for the output of "ls /proc"

Workaround:
Problems disappear when one of the following is applied
a) Using fglrx instead of radeon
b) Using "radeon.nomodeset=0" command line
c) Setting Option "NoAccel" "True" in xorg.conf


-- 
Carla Sella
email:carla.sella at gmail.com
https://launchpad.net/~carla-sella
http://qa.ubuntu.com/

-- next part --
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 3.7.0-rc8-custom+ (root at duex) (gcc version 
4.7.2 (Ubuntu/Linaro 4.7.2-12ubuntu2) ) #1 SMP Sat Dec 8 18:00:39 CET 2012
[0.00] Command line: BOOT_IMAGE=/@/boot/vmlinuz-3.7.0-rc8-custom+ 
root=UUID=4db1a443-6404-4584-8c5e-ca9025977f34 ro rootflags=subvol=@ 
crashkernel=384M-2G:64M,2G-:256M quiet splash vt.handoff=7
[0.00] KERNEL supported cpus:
[0.00]   Intel GenuineIntel
[0.00]   AMD AuthenticAMD
[0.00]   Centaur CentaurHauls
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009d7ff] usable
[0.00] BIOS-e820: [mem 0x0009d800-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000e-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0xde783fff] usable
[0.00] BIOS-e820: [mem 0xde784000-0xdecfbfff] reserved
[0.00] BIOS-e820: [mem 0xdecfc000-0xdef7bfff] ACPI NVS
[0.00] BIOS-e820: [mem 0xdef7c000-0xdef80fff] ACPI data
[0.00] BIOS-e820: [mem 0xdef81000-0xdefc3fff] ACPI NVS
[0.00] BIOS-e820: [mem 0xdefc4000-0xdf5c8fff] usable
[0.00] BIOS-e820: [mem 0xdf5c9000-0xdf7f1fff] reserved
[0.00] BIOS-e820: [mem 0xdf7f2000-0xdf7f] usable
[0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
[0.00] BIOS-e820: [mem 0xfed0-0xfed03fff] reserved
[0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
[0.00] BIOS-e820: [mem 0xff00-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00041eff] usable
[0.00] NX (Execute Disable) protection: active
[0.00] DMI 2.7 present.
[0.00] DMI: To Be Filled By O.E.M. To Be Filled By O.E.M./H61M-ITX, 
BIOS P1.70 05/16/2012
[0.00] e820: update [mem 0x-0x] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] No AGP bridge found
[0.00] e820: last_pfn = 0x41f000 max_arch_pfn = 0x4
[0.00] MTRR default type: uncachable
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-B uncachable
[0.00]   C-C write-protect
[0.00]   D-EBFFF uncachable
[0.00]   EC000-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00]   0 base 0 mask C write-back
[0.00]   1 base 4 mask FF000 write-back
[0.00]   2 base 41000 mask FF800 write-back
[0.00]   3 base 41800 mask FFC00 write-back
[0.00]   4 base 41C00 mask FFE00 write-back
[0.00]   5 base 41E00 mask FFF00 write-back
[0.00]   6 base 0E000 mask FE000 uncachable
[0.00]   7 disabled
[0.00]   8 disabled
[0.00]   9 disabled
[0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, n