[PULL] vmwgfx-next-3.13
Hi, Dave! A resource eviction fix, and a fix for compilation / sparse problems from the previous pull. The following changes since commit d92d985177c495aab53c7167f310a7efb1853918: drm/vmwgfx: Use the linux DMA api to get valid device addresses of pages (2013-11-06 03:57:16 -0800) are available in the git repository at: git://people.freedesktop.org/~thomash/linux vmwgfx-next-3.13 for you to fetch changes up to e14cd9536bd11b174a849da91c7a26bbc980330d: drm/vmwgfx: Fix a couple of compile / sparse warnings and errors (2013-11-12 23:47:32 -0800) Thomas Hellstrom (2): drm/vmwgfx: Resource evict fixes drm/vmwgfx: Fix a couple of compile / sparse warnings and errors drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |9 ++- drivers/gpu/drm/vmwgfx/vmwgfx_gmr.c |7 +++-- drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 42 +- 3 files changed, 49 insertions(+), 9 deletions(-)
[PATCH] gpu: host1x: Silence a few warnings with LPAE=y
When building with LPAE=y (64-bit dma_addr_t), the following warnings are seen: drivers/gpu/host1x/hw/cdma_hw.c:57:3: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t' drivers/gpu/host1x/hw/debug_hw.c:167:10: warning: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'dma_addr_t' The agreed-to solution for this is upcast to u64 and using %llx. Signed-off-by: Olof Johansson --- drivers/gpu/host1x/hw/cdma_hw.c |4 ++-- drivers/gpu/host1x/hw/debug_hw.c |4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/host1x/hw/cdma_hw.c b/drivers/gpu/host1x/hw/cdma_hw.c index 37e2a63..6b09b71 100644 --- a/drivers/gpu/host1x/hw/cdma_hw.c +++ b/drivers/gpu/host1x/hw/cdma_hw.c @@ -54,8 +54,8 @@ static void cdma_timeout_cpu_incr(struct host1x_cdma *cdma, u32 getptr, u32 *p = (u32 *)((u32)pb->mapped + getptr); *(p++) = HOST1X_OPCODE_NOP; *(p++) = HOST1X_OPCODE_NOP; - dev_dbg(host1x->dev, "%s: NOP at 0x%x\n", __func__, - pb->phys + getptr); + dev_dbg(host1x->dev, "%s: NOP at %#llx\n", __func__, + (u64)pb->phys + getptr); getptr = (getptr + 8) & (pb->size_bytes - 1); } wmb(); diff --git a/drivers/gpu/host1x/hw/debug_hw.c b/drivers/gpu/host1x/hw/debug_hw.c index 640c75c..f72c873 100644 --- a/drivers/gpu/host1x/hw/debug_hw.c +++ b/drivers/gpu/host1x/hw/debug_hw.c @@ -163,8 +163,8 @@ static void show_channel_gathers(struct output *o, struct host1x_cdma *cdma) continue; } - host1x_debug_output(o, "GATHER at %08x+%04x, %d words\n", - g->base, g->offset, g->words); + host1x_debug_output(o, "GATHER at %#llx+%04x, %d words\n", + (u64)g->base, g->offset, g->words); show_gather(o, g->base + g->offset, g->words, cdma, g->base, mapped); -- 1.7.10.4
[PATCH 1/2] intel: Add accessor to get HW context ID from a drm_intel_context
On Mon, Nov 11, 2013 at 11:58:59AM -0800, Eric Anholt wrote: > Ian Romanick writes: > > > From: Ian Romanick > > > > The drm_intel_context structure is, wisely, opaque. However, libdrm > > users may want to know the hardware context ID associated with the > > structure. > > We've had a bunch of our other structures be partially transparent. The > context id to be passed to the kernel could easily be public just like > the gem handle in a BO is public. I would lean slightly toward that. > > But I don't feel strongly either way, so these two are: > > Reviewed-by: Eric Anholt I think my preference would be to add a "context" argument to a libdrm get_hangstats function, but if you feel this way is better, it is fine with me. My only [slight, unjustified] concern is that once you make the id transparent, we can't play any games. Since the DDX doesn't use libdrm however, I think it is fairly moot. Acked-by: Ben Widawsky -- Ben Widawsky, Intel Open Source Technology Center
[RFC PATCH] drm/ttm: get rid of ttm bo refcounting
On 11/12/2013 07:26 PM, Maarten Lankhorst wrote:
> Most drivers have refcounting done in gem, so lets get rid of another
> refcounting layer. ;)
> It has been confusing to keep track of 2 refcounts, so lets just let the
> driver worry about
> refcounting, and keep it hidden from ttm entirely. The core doesn't need to
> know about the
> refcounting anywhere.
>
> Vmwgfx has 1 bo that doesn't use vmw_dma_buffer, but instead ttm_bo_create.
> Converting this call
> makes every bo use vmw_dma_buffer as base, which means I can simply add
> refcount to vmw_dma_buffer.
>
> Mostly meant as a RFC, so I only took effort into converting vmwgfx, radeon,
> nouveau. Thoughts?
Hmm. I don't really see the purpose of this?
First the ttm bo reference is used by the vm system, so you need to
duplicate a lot of vm stuff across all drivers, which is
bad because if something needs to change here, we need to change it in
all drivers. Seems you've forgotten qxl, cirrus,
mgag200 and ast mmap() here?
Second, the vmwgfx driver relies so much on ttm refcounting that you
needed to re-add it for this driver, and actually will rely even more
on bare ttm objects in our upcoming hardware revision where they are
used as page table bos.
Finally, it looks to me like the gain in the gem drivers can be
accomplished by just implementing ttm_bo_release() on top of
ttm_bo_unref(), and leave the vm system alone. Sure, you'll add an extra
atomic operation on object destruction, but that's not a high price to
pay...
Thanks,
/Thomas
> I've only done some very basic smoke testing btw, I know nouveau and radeon
> boot. No idea about vmwgfx.
> ---
> diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c
> index af0b868a9dfd..9fcf38a7923a 100644
> --- a/drivers/gpu/drm/ast/ast_main.c
> +++ b/drivers/gpu/drm/ast/ast_main.c
> @@ -449,26 +449,13 @@ int ast_dumb_create(struct drm_file *file,
> return 0;
> }
>
> -void ast_bo_unref(struct ast_bo **bo)
> -{
> - struct ttm_buffer_object *tbo;
> -
> - if ((*bo) == NULL)
> - return;
> -
> - tbo = &((*bo)->bo);
> - ttm_bo_unref(&tbo);
> - if (tbo == NULL)
> - *bo = NULL;
> -
> -}
> void ast_gem_free_object(struct drm_gem_object *obj)
> {
> struct ast_bo *ast_bo = gem_to_ast_bo(obj);
>
> if (!ast_bo)
> return;
> - ast_bo_unref(&ast_bo);
> + ttm_bo_release(&ast_bo->bo);
> }
>
>
> diff --git a/drivers/gpu/drm/cirrus/cirrus_main.c
> b/drivers/gpu/drm/cirrus/cirrus_main.c
> index 78e76f24343d..f4d3fd5be1e7 100644
> --- a/drivers/gpu/drm/cirrus/cirrus_main.c
> +++ b/drivers/gpu/drm/cirrus/cirrus_main.c
> @@ -255,27 +255,13 @@ int cirrus_dumb_create(struct drm_file *file,
> return 0;
> }
>
> -void cirrus_bo_unref(struct cirrus_bo **bo)
> -{
> - struct ttm_buffer_object *tbo;
> -
> - if ((*bo) == NULL)
> - return;
> -
> - tbo = &((*bo)->bo);
> - ttm_bo_unref(&tbo);
> - if (tbo == NULL)
> - *bo = NULL;
> -
> -}
> -
> void cirrus_gem_free_object(struct drm_gem_object *obj)
> {
> struct cirrus_bo *cirrus_bo = gem_to_cirrus_bo(obj);
>
> if (!cirrus_bo)
> return;
> - cirrus_bo_unref(&cirrus_bo);
> + ttm_bo_release(&cirrus_bo->bo);
> }
>
>
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index 4761adedad2a..511b4e97a093 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -848,9 +848,14 @@ int drm_gem_mmap(struct file *filp, struct
> vm_area_struct *vma)
> if (!node) {
> mutex_unlock(&dev->struct_mutex);
> return drm_mmap(filp, vma);
> - } else if (!drm_vma_node_is_allowed(node, filp)) {
> - mutex_unlock(&dev->struct_mutex);
> - return -EACCES;
> + } else {
> + read_lock(&node->vm_lock);
> + ret = drm_vma_node_verify_access(node, filp);
> + read_unlock(&node->vm_lock);
> + if (ret) {
> + mutex_unlock(&dev->struct_mutex);
> + return ret;
> + }
> }
>
> obj = container_of(node, struct drm_gem_object, vma_node);
> diff --git a/drivers/gpu/drm/drm_vma_manager.c
> b/drivers/gpu/drm/drm_vma_manager.c
> index 63b471205072..482b9c996217 100644
> --- a/drivers/gpu/drm/drm_vma_manager.c
> +++ b/drivers/gpu/drm/drm_vma_manager.c
> @@ -405,7 +405,7 @@ EXPORT_SYMBOL(drm_vma_node_revoke);
>* Search the list in @node whether @filp is currently on the list of
> allowed
>* open-files (see drm_vma_node_allow()).
>*
> - * This is locked against concurrent access internally.
> + * This call requires the vm_lock to be held.
>*
>* RETURNS:
>* true iff @filp is on the list
> @@ -416,8 +416,6 @@ bool drm_vma_node_is_allowed(struct drm_vma_offset_node
> *node,
> struct drm_vma_offset_file *entry;
> struct rb_node *iter;
>
> - read_lock(&n
[PATCH v3 12/32] drm/exynos: Split manager/display/subdrv
On Tuesday 12 of November 2013 12:51:11 Sean Paul wrote: > On Sun, Nov 10, 2013 at 4:09 PM, Tomasz Figa wrote: > > Hi Sean, > > > > On Tuesday 29 of October 2013 12:12:58 Sean Paul wrote: > >> This patch splits display and manager from subdrv. The result is that > >> crtc functions can directly call into manager callbacks and encoder > >> functions can directly call into display callbacks. This will allow > >> us to remove the exynos_drm_hdmi shim and support mixer/hdmi & fimd/dp > >> with common code. > >> > >> Signed-off-by: Sean Paul > >> --- > >> > >> Changes in v2: > >> - Pass display into display_ops instead of context > >> Changes in v3: > >> - Changed vidi args to exynos_drm_display instead of void > >> - Moved exynos_drm_hdmi.c removal into next patch > >> > >> drivers/gpu/drm/exynos/exynos_drm_connector.c | 50 ++--- > >> drivers/gpu/drm/exynos/exynos_drm_core.c | 181 +- > >> drivers/gpu/drm/exynos/exynos_drm_crtc.c | 115 +--- > >> drivers/gpu/drm/exynos/exynos_drm_crtc.h | 20 +- > >> drivers/gpu/drm/exynos/exynos_drm_drv.c | 29 +-- > >> drivers/gpu/drm/exynos/exynos_drm_drv.h | 106 +++ > >> drivers/gpu/drm/exynos/exynos_drm_encoder.c | 258 > >> -- > >> drivers/gpu/drm/exynos/exynos_drm_encoder.h | 18 +- > >> drivers/gpu/drm/exynos/exynos_drm_fb.c| 4 +- > >> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 161 > >> drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 211 + > >> drivers/gpu/drm/exynos/exynos_drm_hdmi.h | 2 + > >> drivers/gpu/drm/exynos/exynos_drm_plane.c | 15 +- > >> drivers/gpu/drm/exynos/exynos_drm_vidi.c | 129 ++--- > >> 14 files changed, 615 insertions(+), 684 deletions(-) > > > > This patch is really heavy, making it very hard to review. I wonder if it > > couldn't really be split into several smaller patches... > > > > I've distilled it down as much as possible. Unfortunately the > encoder/crtc were fused pretty tightly and the effects of that are > far-reaching. I was afraid of this. Well, I guess nothing can be done about it then. > > > Anyway, please see my comments below, for the points I haven't overlooked > > due to the complexity of this patch. > > > >> diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c > >> b/drivers/gpu/drm/exynos/exynos_drm_core.c > >> index 08ca4f9..e76098d 100644 > >> --- a/drivers/gpu/drm/exynos/exynos_drm_core.c > >> +++ b/drivers/gpu/drm/exynos/exynos_drm_core.c > >> @@ -16,11 +16,14 @@ > >> #include > >> #include > > > > Huh? Including a specific bridge chip inside a generic Exynos DRM core? > > I know this is not a part of this patch, but... this is _broken_. > > > > You may want to support multiple bridge chips in Exynos DRM core and you > > may also want to support PTN3460 in other DRM cores. It can't be done this > > way. > > > > This series is very nice, but the whole effect is destroyed by basing it > > on top of such insanity... Please rebase it on top of something more > > reasonable (preferably Inki's next branch directly). > > > > Well, that was blunt. Unfortunately, I don't know how else to do this > other than this broken, unreasonable and insane way. Sorry, this might have been a bit too harsh, but just imagine myself doing my regular patch review round, hoping (as usual) to see only code that is not less than great, while suddenly stumbling upon a line of code that I would expect at most in some vendor tree or maybe several years ago in sources of a 2.4 kernel. > > This has already been discussed at length in a few other places. > Without some help from the drm layer, I don't see any other way to do > this than to enumerate the possible bridges in each drm driver. > > I based the current set off the "Add some missing bits for > exynos5250-snow" series I sent up a little while ago. This set was > sent to the relevant dt people, acked by Olof, and there are no > outstanding review comments. Since it's required for me to test on > Real Hardware, I assumed this was an appropriate base. > > If you think this is _broken_, unreasonable, and insane, I'd love to > hear an alternative. Well, I should say that Laurent would probably have something to say about this, but I understand that the really good solution need to take some time to be developed, so... What about at least creating a minimal, temporary abstraction layer that would provide all you originally needed from drm/bridge/ptn3460.h, but in a bridge chip agnostic way? I believe we already have established Device Tree bindings for video interfaces (used currently by V4L) and you can safely use them to bind your video devices together. Based on this assumption, you can implement a local parser for a subset of those bindings that is enough to achieve everything you need - bind a bridge to a video output of the SoC. As for your explicit need to include headers of particula
[RFC PATCH] drm/ttm: get rid of ttm bo refcounting
Most drivers have refcounting done in gem, so lets get rid of another
refcounting layer. ;)
It has been confusing to keep track of 2 refcounts, so lets just let the driver
worry about
refcounting, and keep it hidden from ttm entirely. The core doesn't need to
know about the
refcounting anywhere.
Vmwgfx has 1 bo that doesn't use vmw_dma_buffer, but instead ttm_bo_create.
Converting this call
makes every bo use vmw_dma_buffer as base, which means I can simply add
refcount to vmw_dma_buffer.
Mostly meant as a RFC, so I only took effort into converting vmwgfx, radeon,
nouveau. Thoughts?
I've only done some very basic smoke testing btw, I know nouveau and radeon
boot. No idea about vmwgfx.
---
diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c
index af0b868a9dfd..9fcf38a7923a 100644
--- a/drivers/gpu/drm/ast/ast_main.c
+++ b/drivers/gpu/drm/ast/ast_main.c
@@ -449,26 +449,13 @@ int ast_dumb_create(struct drm_file *file,
return 0;
}
-void ast_bo_unref(struct ast_bo **bo)
-{
- struct ttm_buffer_object *tbo;
-
- if ((*bo) == NULL)
- return;
-
- tbo = &((*bo)->bo);
- ttm_bo_unref(&tbo);
- if (tbo == NULL)
- *bo = NULL;
-
-}
void ast_gem_free_object(struct drm_gem_object *obj)
{
struct ast_bo *ast_bo = gem_to_ast_bo(obj);
if (!ast_bo)
return;
- ast_bo_unref(&ast_bo);
+ ttm_bo_release(&ast_bo->bo);
}
diff --git a/drivers/gpu/drm/cirrus/cirrus_main.c
b/drivers/gpu/drm/cirrus/cirrus_main.c
index 78e76f24343d..f4d3fd5be1e7 100644
--- a/drivers/gpu/drm/cirrus/cirrus_main.c
+++ b/drivers/gpu/drm/cirrus/cirrus_main.c
@@ -255,27 +255,13 @@ int cirrus_dumb_create(struct drm_file *file,
return 0;
}
-void cirrus_bo_unref(struct cirrus_bo **bo)
-{
- struct ttm_buffer_object *tbo;
-
- if ((*bo) == NULL)
- return;
-
- tbo = &((*bo)->bo);
- ttm_bo_unref(&tbo);
- if (tbo == NULL)
- *bo = NULL;
-
-}
-
void cirrus_gem_free_object(struct drm_gem_object *obj)
{
struct cirrus_bo *cirrus_bo = gem_to_cirrus_bo(obj);
if (!cirrus_bo)
return;
- cirrus_bo_unref(&cirrus_bo);
+ ttm_bo_release(&cirrus_bo->bo);
}
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 4761adedad2a..511b4e97a093 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -848,9 +848,14 @@ int drm_gem_mmap(struct file *filp, struct vm_area_struct
*vma)
if (!node) {
mutex_unlock(&dev->struct_mutex);
return drm_mmap(filp, vma);
- } else if (!drm_vma_node_is_allowed(node, filp)) {
- mutex_unlock(&dev->struct_mutex);
- return -EACCES;
+ } else {
+ read_lock(&node->vm_lock);
+ ret = drm_vma_node_verify_access(node, filp);
+ read_unlock(&node->vm_lock);
+ if (ret) {
+ mutex_unlock(&dev->struct_mutex);
+ return ret;
+ }
}
obj = container_of(node, struct drm_gem_object, vma_node);
diff --git a/drivers/gpu/drm/drm_vma_manager.c
b/drivers/gpu/drm/drm_vma_manager.c
index 63b471205072..482b9c996217 100644
--- a/drivers/gpu/drm/drm_vma_manager.c
+++ b/drivers/gpu/drm/drm_vma_manager.c
@@ -405,7 +405,7 @@ EXPORT_SYMBOL(drm_vma_node_revoke);
* Search the list in @node whether @filp is currently on the list of allowed
* open-files (see drm_vma_node_allow()).
*
- * This is locked against concurrent access internally.
+ * This call requires the vm_lock to be held.
*
* RETURNS:
* true iff @filp is on the list
@@ -416,8 +416,6 @@ bool drm_vma_node_is_allowed(struct drm_vma_offset_node
*node,
struct drm_vma_offset_file *entry;
struct rb_node *iter;
- read_lock(&node->vm_lock);
-
iter = node->vm_files.rb_node;
while (likely(iter)) {
entry = rb_entry(iter, struct drm_vma_offset_file, vm_rb);
@@ -429,8 +427,6 @@ bool drm_vma_node_is_allowed(struct drm_vma_offset_node
*node,
iter = iter->rb_left;
}
- read_unlock(&node->vm_lock);
-
return iter;
}
EXPORT_SYMBOL(drm_vma_node_is_allowed);
diff --git a/drivers/gpu/drm/mgag200/mgag200_main.c
b/drivers/gpu/drm/mgag200/mgag200_main.c
index b1120cb1db6d..ca8367505742 100644
--- a/drivers/gpu/drm/mgag200/mgag200_main.c
+++ b/drivers/gpu/drm/mgag200/mgag200_main.c
@@ -310,27 +310,13 @@ int mgag200_dumb_create(struct drm_file *file,
return 0;
}
-void mgag200_bo_unref(struct mgag200_bo **bo)
-{
- struct ttm_buffer_object *tbo;
-
- if ((*bo) == NULL)
- return;
-
- tbo = &((*bo)->bo);
- ttm_bo_unref(&tbo);
- if (tbo == NULL)
- *bo = NULL;
-
-}
-
void mgag200_gem_free_object(struct drm_gem_object *obj)
{
struct mgag200_bo *mgag200_bo = gem_to_mga_bo(obj);
[Bug 63101] Hard lockup whel launching games like TF2 on kernels 3.11.5 and 3.12 rc4 and above if radeon.dpm=1 is used
https://bugzilla.kernel.org/show_bug.cgi?id=63101 --- Comment #18 from Kertesz Laszlo --- Tested with 3.12.0-next-2013, started the computer and launched Steam and TF2 right away. Activating enable_nbps_policy to enable_gfx_clock_gating worked well. The enable_mg_clock_gating, enable_gfx_dynamic_mgpg, override_dynamic_mgpg options gave gpu lockups and softresets (same as the above attachment), mostly after i entered the map, but sometimes after the reset the game was resumed and could play without issues. Combining them with uvd_dpm seems to be the killer factor though. This is what seems to work well so far (uvd_dpm seems to not create problems if the mgpg and mg options are disabled: pi->enable_bapm = false; pi->enable_nbps_policy = true; /*mychange*/ pi->enable_sclk_ds = true; pi->enable_gfx_power_gating = true; pi->enable_gfx_clock_gating = true; pi->enable_mg_clock_gating = false; pi->enable_gfx_dynamic_mgpg = false; /* ??? */ pi->override_dynamic_mgpg = false; pi->enable_auto_thermal_throttling = true; pi->voltage_drop_in_dce = false; /* need to restructure dpm/modeset interaction */ pi->uvd_dpm = true; /* ??? */ -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 71543] New: [r600] Source-based games segfault
https://bugs.freedesktop.org/show_bug.cgi?id=71543 Priority: medium Bug ID: 71543 Assignee: dri-devel at lists.freedesktop.org Summary: [r600] Source-based games segfault Severity: normal Classification: Unclassified OS: All Reporter: nikoamia at gmail.com Hardware: Other Status: NEW Version: unspecified Component: Drivers/DRI/R600 Product: Mesa Source games (Garry's Mod, Portal) segfault, with last good commit being 4e84f39 and last known bad ab2da98 (5442c0e is bad, too, mesa = libGL*, without radeon_dri) I don't have enough time at this week, so I can't bisect this now. Message: [ 1591.415826] gameoverlayui[15840]: segfault at 0 ip f6ff0fd9 sp ffbda850 error 4 in gameoverlayui.so[f6e6e000+712000] 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Madison [Mobility Radeon HD 5650/5750 / 6530M/6550M] (prog-if 00 [VGA controller]) -- 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/20131112/1d4d8f04/attachment.html>
[PATCHv3 4/8] staging: imx-drm: Add RGB666 support for parallel display.
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Stephen Warren
Cc: Ian Campbell
Cc: devicetree at vger.kernel.org
Cc: Greg Kroah-Hartman
Cc: driverdev-devel at linuxdriverproject.org
Cc: David Airlie
Cc: dri-devel at lists.freedesktop.org
Cc: Mauro Carvalho Chehab
Cc: Laurent Pinchart
Cc: linux-media at vger.kernel.org
Cc: Sascha Hauer
Cc: Shawn Guo
Cc: linux-arm-kernel at lists.infradead.org
Cc: Eric B?nard
Signed-off-by: Denis Carikli
---
ChangeLog v2->v3:
- Added some interested people in the Cc list.
- Removed the commit message long desciption that was just a copy of the short
description.
- Rebased the patch.
- Fixed a copy-paste error in the ipu_dc_map_clear parameter.
---
.../bindings/staging/imx-drm/fsl-imx-drm.txt |2 +-
drivers/staging/imx-drm/ipu-v3/ipu-dc.c|9 +
drivers/staging/imx-drm/parallel-display.c |2 ++
3 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
b/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
index b876d49..2d24425 100644
--- a/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
+++ b/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
@@ -29,7 +29,7 @@ Required properties:
- crtc: the crtc this display is connected to, see below
Optional properties:
- interface_pix_fmt: How this display is connected to the
- crtc. Currently supported types: "rgb24", "rgb565", "bgr666"
+ crtc. Currently supported types: "rgb24", "rgb565", "bgr666", "rgb666"
- edid: verbatim EDID data block describing attached display.
- ddc: phandle describing the i2c bus handling the display data
channel
diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
b/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
index d0e3bc3..bcc7680 100644
--- a/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
+++ b/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
@@ -92,6 +92,7 @@ enum ipu_dc_map {
IPU_DC_MAP_GBR24, /* TVEv2 */
IPU_DC_MAP_BGR666,
IPU_DC_MAP_BGR24,
+ IPU_DC_MAP_RGB666,
};
struct ipu_dc {
@@ -155,6 +156,8 @@ static int ipu_pixfmt_to_map(u32 fmt)
return IPU_DC_MAP_BGR666;
case V4L2_PIX_FMT_BGR24:
return IPU_DC_MAP_BGR24;
+ case V4L2_PIX_FMT_RGB666:
+ return IPU_DC_MAP_RGB666;
default:
return -EINVAL;
}
@@ -404,6 +407,12 @@ int ipu_dc_init(struct ipu_soc *ipu, struct device *dev,
ipu_dc_map_config(priv, IPU_DC_MAP_BGR24, 1, 15, 0xff); /* green */
ipu_dc_map_config(priv, IPU_DC_MAP_BGR24, 0, 23, 0xff); /* blue */
+ /* rgb666 */
+ ipu_dc_map_clear(priv, IPU_DC_MAP_RGB666);
+ ipu_dc_map_config(priv, IPU_DC_MAP_RGB666, 2, 17, 0xfc); /* red */
+ ipu_dc_map_config(priv, IPU_DC_MAP_RGB666, 1, 11, 0xfc); /* green */
+ ipu_dc_map_config(priv, IPU_DC_MAP_RGB666, 0, 5, 0xfc); /* blue */
+
return 0;
}
diff --git a/drivers/staging/imx-drm/parallel-display.c
b/drivers/staging/imx-drm/parallel-display.c
index 24aa9be..bb71d6d 100644
--- a/drivers/staging/imx-drm/parallel-display.c
+++ b/drivers/staging/imx-drm/parallel-display.c
@@ -222,6 +222,8 @@ static int imx_pd_probe(struct platform_device *pdev)
imxpd->interface_pix_fmt = V4L2_PIX_FMT_RGB565;
else if (!strcmp(fmt, "bgr666"))
imxpd->interface_pix_fmt = V4L2_PIX_FMT_BGR666;
+ else if (!strcmp(fmt, "rgb666"))
+ imxpd->interface_pix_fmt = V4L2_PIX_FMT_RGB666;
}
imxpd->dev = &pdev->dev;
--
1.7.9.5
[PATCHv3 3/8] staging: imx-drm: ipuv3-crtc: don't harcode some mode flags.
This change is needed for making the eukrea-cpuimx51 QVGA display work. Greg Kroah-Hartman Cc: driverdev-devel at linuxdriverproject.org Cc: Philipp Zabel Cc: Sascha Hauer Cc: Shawn Guo Cc: linux-arm-kernel at lists.infradead.org Cc: David Airlie Cc: dri-devel at lists.freedesktop.org Cc: Eric B?nard Signed-off-by: Denis Carikli --- drivers/staging/imx-drm/ipuv3-crtc.c |6 -- 1 file changed, 4 insertions(+), 2 deletions(-) ChangeLog v2->v3: - Added some interested people in the Cc list. - Ajusted the flags to match the changes in "drm: Add the lacking DRM_MODE_FLAG_* for matching the DISPLAY_FLAGS_*" --- diff --git a/drivers/staging/imx-drm/ipuv3-crtc.c b/drivers/staging/imx-drm/ipuv3-crtc.c index 670a56a..917818c 100644 --- a/drivers/staging/imx-drm/ipuv3-crtc.c +++ b/drivers/staging/imx-drm/ipuv3-crtc.c @@ -155,9 +155,11 @@ static int ipu_crtc_mode_set(struct drm_crtc *crtc, sig_cfg.Hsync_pol = 1; if (mode->flags & DRM_MODE_FLAG_PVSYNC) sig_cfg.Vsync_pol = 1; + if (mode->flags & DRM_MODE_FLAG_DE_HIGH) + sig_cfg.enable_pol = 1; + if (mode->flags & DRM_MODE_FLAG_PIXDATA_POSEDGE) + sig_cfg.clk_pol = 1; - sig_cfg.enable_pol = 1; - sig_cfg.clk_pol = 1; sig_cfg.width = mode->hdisplay; sig_cfg.height = mode->vdisplay; sig_cfg.pixel_fmt = out_pixel_fmt; -- 1.7.9.5
[PATCHv3 2/8] [media] v4l2: add new V4L2_PIX_FMT_RGB666 pixel format.
That new macro is needed by the imx_drm staging driver
for supporting the QVGA display of the eukrea-cpuimx51 board.
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Stephen Warren
Cc: Ian Campbell
Cc: devicetree at vger.kernel.org
Cc: Greg Kroah-Hartman
Cc: driverdev-devel at linuxdriverproject.org
Cc: David Airlie
Cc: dri-devel at lists.freedesktop.org
Cc: Mauro Carvalho Chehab
Cc: Laurent Pinchart
Cc: linux-media at vger.kernel.org
Cc: Sascha Hauer
Cc: Shawn Guo
Cc: linux-arm-kernel at lists.infradead.org
Cc: Eric B?nard
Signed-off-by: Denis Carikli
Acked-by: Mauro Carvalho Chehab
---
ChangeLog v2->v3:
- Added some interested people in the Cc list.
- Added Mauro Carvalho Chehab's Ack.
- Added documentation.
---
.../DocBook/media/v4l/pixfmt-packed-rgb.xml| 78
include/uapi/linux/videodev2.h |1 +
2 files changed, 79 insertions(+)
diff --git a/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml
b/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml
index 166c8d6..f6a3e84 100644
--- a/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml
+++ b/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml
@@ -279,6 +279,45 @@ colorspace
V4L2_COLORSPACE_SRGB.
+
+ V4L2_PIX_FMT_RGB666
+ 'RGBH'
+
+ r5
+ r4
+ r3
+ r2
+ r1
+ r0
+ g5
+ g4
+
+ g3
+ g2
+ g1
+ g0
+ b5
+ b4
+ b3
+ b2
+
+ b1
+ b0
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
V4L2_PIX_FMT_BGR24
'BGR3'
@@ -781,6 +820,45 @@ defined in error. Drivers may interpret them as in
+
+ V4L2_PIX_FMT_RGB666
+ 'RGBH'
+
+ r5
+ r4
+ r3
+ r2
+ r1
+ r0
+ g5
+ g4
+
+ g3
+ g2
+ g1
+ g0
+ b5
+ b4
+ b3
+ b2
+
+ b1
+ b0
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
V4L2_PIX_FMT_BGR24
'BGR3'
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 437f1b0..e8ff410 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -294,6 +294,7 @@ struct v4l2_pix_format {
#define V4L2_PIX_FMT_RGB555X v4l2_fourcc('R', 'G', 'B', 'Q') /* 16 RGB-5-5-5
BE */
#define V4L2_PIX_FMT_RGB565X v4l2_fourcc('R', 'G', 'B', 'R') /* 16 RGB-5-6-5
BE */
#define V4L2_PIX_FMT_BGR666 v4l2_fourcc('B', 'G', 'R', 'H') /* 18 BGR-6-6-6
*/
+#define V4L2_PIX_FMT_RGB666 v4l2_fourcc('R', 'G', 'B', 'H') /* 18 RGB-6-6-6
*/
#define V4L2_PIX_FMT_BGR24 v4l2_fourcc('B', 'G', 'R', '3') /* 24 BGR-8-8-8
*/
#define V4L2_PIX_FMT_RGB24 v4l2_fourcc('R', 'G', 'B', '3') /* 24 RGB-8-8-8
*/
#define V4L2_PIX_FMT_BGR32 v4l2_fourcc('B', 'G', 'R', '4') /* 32
BGR-8-8-8-8 */
--
1.7.9.5
[PATCHv3 1/8] drm: Add the lacking DRM_MODE_FLAG_* for matching the DISPLAY_FLAGS_*
Without that fix, drivers using the drm_display_mode_from_videomode function will not be able to get certain information because some DISPLAY_FLAGS_* have no corresponding DRM_MODE_FLAG_*. Cc: Greg Kroah-Hartman Cc: driverdev-devel at linuxdriverproject.org Cc: Matt Sealey Cc: David Airlie Cc: Ville Syrjala Cc: dri-devel at lists.freedesktop.org Cc: Fabio Estevam Cc: Sascha Hauer Cc: Shawn Guo Cc: linux-arm-kernel at lists.infradead.org Cc: Eric B?nard Signed-off-by: Denis Carikli --- ChangeLog v2->v3: - Added some interested people in the Cc list. - Removed a duplicated Cc. - Changed the flags names to match the one in DISPLAY_FLAGS. - Moved the flags out of the userspace headers. - Updated the rest of the code accordingly. --- drivers/gpu/drm/drm_modes.c |9 + include/drm/drm_mode.h | 34 ++ include/uapi/drm/drm_mode.h |4 ++-- 3 files changed, 45 insertions(+), 2 deletions(-) create mode 100644 include/drm/drm_mode.h diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c index fc2adb6..586c12f 100644 --- a/drivers/gpu/drm/drm_modes.c +++ b/drivers/gpu/drm/drm_modes.c @@ -537,6 +537,15 @@ int drm_display_mode_from_videomode(const struct videomode *vm, dmode->flags |= DRM_MODE_FLAG_DBLSCAN; if (vm->flags & DISPLAY_FLAGS_DOUBLECLK) dmode->flags |= DRM_MODE_FLAG_DBLCLK; + if (vm->flags & DISPLAY_FLAGS_DE_LOW) + dmode->flags |= DRM_MODE_FLAG_DE_LOW; + if (vm->flags & DISPLAY_FLAGS_DE_HIGH) + dmode->flags |= DRM_MODE_FLAG_DE_HIGH; + if (vm->flags & DISPLAY_FLAGS_PIXDATA_POSEDGE) + dmode->flags |= DRM_MODE_FLAG_PIXDATA_POSEDGE; + if (vm->flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE) + dmode->flags |= DRM_MODE_FLAG_PIXDATA_NEGEDGE; + drm_mode_set_name(dmode); return 0; diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h new file mode 100644 index 000..07e5259 --- /dev/null +++ b/include/drm/drm_mode.h @@ -0,0 +1,34 @@ +/* + * Copyright 2013 Eukr?a Electromatique + * + * Permission is hereby granted, free of charge, to any person obtaining a + * copy of this software and associated documentation files (the "Software"), + * to deal in the Software without restriction, including without limitation + * the rights to use, copy, modify, merge, publish, distribute, sublicense, + * and/or sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS + * IN THE SOFTWARE. + */ + +#ifndef _DRM_MODE_H +#define _DRM_MODE_H + +#include + +/* DISPLAY_FLAGS DRM counterpart */ +#define DRM_MODE_FLAG_DE_HIGH (1<<22) +#define DRM_MODE_FLAG_DE_LOW (1<<23) +#define DRM_MODE_FLAG_PIXDATA_POSEDGE (1<<24) +#define DRM_MODE_FLAG_PIXDATA_NEGEDGE (1<<25) + +#endif diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h index 28acbaf..5681897 100644 --- a/include/uapi/drm/drm_mode.h +++ b/include/uapi/drm/drm_mode.h @@ -24,8 +24,8 @@ * IN THE SOFTWARE. */ -#ifndef _DRM_MODE_H -#define _DRM_MODE_H +#ifndef _UAPI_DRM_MODE_H +#define _UAPI_DRM_MODE_H #include -- 1.7.9.5
atombios powerplay cac table
On Thu, Nov 07, 2013 at 04:57:21AM +0100, Sylvain BERTRAND wrote: > Which GPU generations/families do use the "new" powerplay CAC > table, defined when the atombios platform capabilities have the > ATOM_PP_PLATFORM_CAP_NEW_CAC_VOLTAGE flag? I reply myself, since that was discussed on IRC, for archive. agd5f said he does not know. Just care about the flag whatever the generation/family is. -- Sylvain
[Bug 71540] New: Radeon HD 7420G artefacts
https://bugs.freedesktop.org/show_bug.cgi?id=71540 Priority: medium Bug ID: 71540 Assignee: dri-devel at lists.freedesktop.org Summary: Radeon HD 7420G artefacts Severity: normal Classification: Unclassified OS: All Reporter: vova7890 at mail.ru Hardware: Other Status: NEW Version: 9.2 Component: Drivers/Gallium/r600 Product: Mesa On my Radeon HD 7420G give artefacts on 3d scenes. Don`t kwon how explain what I see. In xonotic game gives random lines at screen. linux: 3.11(on 3.12 similar) mesa: 9.2.2 xf86-video-ati: 1:7.2.0 os: ArchLinux -- 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/20131112/51106f43/attachment.html>
[PATCHv3 1/8] drm: Add the lacking DRM_MODE_FLAG_* for matching the DISPLAY_FLAGS_*
On Tue, Nov 12, 2013 at 05:49:18PM +0100, Denis Carikli wrote: > diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c > index fc2adb6..586c12f 100644 > --- a/drivers/gpu/drm/drm_modes.c > +++ b/drivers/gpu/drm/drm_modes.c > @@ -537,6 +537,15 @@ int drm_display_mode_from_videomode(const struct > videomode *vm, > dmode->flags |= DRM_MODE_FLAG_DBLSCAN; > if (vm->flags & DISPLAY_FLAGS_DOUBLECLK) > dmode->flags |= DRM_MODE_FLAG_DBLCLK; > + if (vm->flags & DISPLAY_FLAGS_DE_LOW) > + dmode->flags |= DRM_MODE_FLAG_DE_LOW; > + if (vm->flags & DISPLAY_FLAGS_DE_HIGH) > + dmode->flags |= DRM_MODE_FLAG_DE_HIGH; > + if (vm->flags & DISPLAY_FLAGS_PIXDATA_POSEDGE) > + dmode->flags |= DRM_MODE_FLAG_PIXDATA_POSEDGE; > + if (vm->flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE) > + dmode->flags |= DRM_MODE_FLAG_PIXDATA_NEGEDGE; > + I'm still not convinced that these should be exposed in *any* way to userspace - I'm with Ville Syrj?l? on this point. Yes, you've moved their definition out of a uapi header file, but they're still leaking out of kernel space via calls (and with Xorg, they'll leak into the DisplayMode structures within the X server.) Now, here's the thing... The polarity of the display enable signal. That's a property of the connected device right? It doesn't change with respect to the displayed mode unlike the hsync/vsync signals. If that's true, it should not be here. Same goes for the pixel clock edge. If it's a property of the connected device and doesn't have a dependence on the displayed mode, then it should not be in the DRM mode structure.
drm/nouveau/pwr: initial implementation
- Original Message -
> From: "Dan Carpenter"
> To: bskeggs at redhat.com
> Cc: dri-devel at lists.freedesktop.org
> Sent: Tuesday, 12 November, 2013 7:54:33 PM
> Subject: re: drm/nouveau/pwr: initial implementation
>
> Hello Ben Skeggs,
Hey,
>
> The patch ff4b42c7532e: "drm/nouveau/pwr: initial implementation"
> from Oct 15, 2013, leads to the following Smatch warning:
> "drivers/gpu/drm/nouveau/core/subdev/pwr/base.c:48 nouveau_pwr_send()
>warn: 'mutex:&subdev->mutex' is sometimes locked here and sometimes
>unlocked."
>
> drivers/gpu/drm/nouveau/core/subdev/pwr/base.c
> 35 /* we currently only support a single process at a time
> waiting
> 36 * on a synchronous reply, take the PPWR mutex and tell the
> 37 * receive handler what we're waiting for
> 38 */
> 39 if (reply) {
> 40 mutex_lock(&subdev->mutex);
> 41 ppwr->recv.message = message;
> 42 ppwr->recv.process = process;
> 43 }
> 44
> 45 /* wait for a free slot in the fifo */
> 46 addr = nv_rd32(ppwr, 0x10a4a0);
> 47 if (!nv_wait_ne(ppwr, 0x10a4b0, 0x, addr ^ 8))
> 48 return -EBUSY;
>
> Should we have an if (reply) mutex_unlock(&subdev->mutex) before the
> return?
Yes, we should. It's been reported, no fix pushed to Linus' tree yet as the
path that can hit it has been hardcoded as disabled for this release.
Thanks,
Ben.
>
> 49
>
> regards,
> dan carpenter
>
>
[Bug 64661] udl causes blank screen
https://bugzilla.kernel.org/show_bug.cgi?id=64661 Alan changed: What|Removed |Added Status|NEW |NEEDINFO -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 64661] udl causes blank screen
https://bugzilla.kernel.org/show_bug.cgi?id=64661 Alan changed: What|Removed |Added CC||alan at lxorguk.ukuu.org.uk --- Comment #4 from Alan --- 4.306110] nvidia: module license 'NVIDIA' taints kernel. [4.306112] Disabling lock debugging due to kernel taint [4.312028] nvidia :01:00.0: enabling device (0006 -> 0007) [4.312079] vgaarb: device changed decodes: PCI::01:00.0,olddecodes=io+mem,decodes=none:owns=none [4.312522] [drm] Initialized nvidia-drm 0.0.0 20130102 for :01:00.0 on minor 1 [4.312529] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 331.20 Wed Oct 30 17:43:35 PDT 2013 Please reproduce the bug from a boot without ever loading the Nvidia driver. If you can still reoproduce it then can you update the bug and confirm the adapter in use and what it is connected to (eg is this a panel with USB connector or an adapter to a monitor ?) -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH v3 1/7] drm: Add DSI bus infrastructure
Hi Thierry, I have already sent patch with DSI bus implementation [1]. It was posted as the first step of CDF implementation attempt, but in fact it do not depend on CDF. [1] http://www.mail-archive.com/dri-devel at lists.freedesktop.org/msg45252.html One comment below. On 11/11/2013 01:00 PM, Thierry Reding wrote: > In order to support DSI peripherals, add a DSI bus type that devices and > drivers can be registered with. > > Signed-off-by: Thierry Reding > --- [snip] > + > +/* > + * DSI packet data types > + */ > + > +/* processor-sourced packets */ > +#define DSI_CMD_VSYNC_START 0x01 > +#define DSI_CMD_VSYNC_END 0x11 > +#define DSI_CMD_HSYNC_START 0x21 > +#define DSI_CMD_HSYNC_END 0x31 > +#define DSI_CMD_EOT 0x08 > +#define DSI_CMD_COLOR_MODE_OFF 0x02 > +#define DSI_CMD_COLOR_MODE_ON 0x12 > +#define DSI_CMD_SHUT_DOWN 0x22 > +#define DSI_CMD_TURN_ON 0x32 > +#define DSI_CMD_GEN_SHORT_WRITE_0 0x03 > +#define DSI_CMD_GEN_SHORT_WRITE_1 0x13 > +#define DSI_CMD_GEN_SHORT_WRITE_2 0x23 > +#define DSI_CMD_GEN_SHORT_READ_0 0x04 > +#define DSI_CMD_GEN_SHORT_READ_1 0x14 > +#define DSI_CMD_GEN_SHORT_READ_2 0x24 > +#define DSI_CMD_DCS_SHORT_WRITE_0 0x05 > +#define DSI_CMD_DCS_SHORT_WRITE_1 0x15 > +#define DSI_CMD_DCS_SHORT_READ 0x06 > +#define DSI_CMD_SET_MAX_RETURN_PACKET_SIZE 0x37 > +#define DSI_CMD_NULL 0x09 > +#define DSI_CMD_BLANK 0x19 > +#define DSI_CMD_GEN_LONG_WRITE 0x29 > +#define DSI_CMD_DCS_LONG_WRITE 0x39 > +#define DSI_CMD_YCbCr422_20 0x0c > +#define DSI_CMD_YCbCr422_24 0x1c > +#define DSI_CMD_YCbCr422_16 0x2c > +#define DSI_CMD_RGB30 0x0d > +#define DSI_CMD_RGB36 0x1d > +#define DSI_CMD_YCbCr420 0x3d > +#define DSI_CMD_RGB16 0x0e > +#define DSI_CMD_RGB18 0x1e > +#define DSI_CMD_RGB18NP 0x2e > +#define DSI_CMD_RGB24 0x3e > + > +/* peripheral-sourced */ > +#define DSI_RSP_ACK_ERR 0x02 > +#define DSI_RSP_EOT 0x08 > +#define DSI_RSP_GEN_SHORT_READ_1 0x11 > +#define DSI_RSP_GEN_SHORT_READ_2 0x12 > +#define DSI_RSP_GEN_LONG_READ 0x1a > +#define DSI_RSP_DCS_LONG_READ 0x1c > +#define DSI_RSP_DCS_SHORT_READ_1 0x21 > +#define DSI_RSP_DCS_SHORT_READ_2 0x22 > + Those macros are already defined in include/video/mipi_display.h Regards Andrzej
[Bug 58671] Nvidia drivers fail compile
https://bugzilla.kernel.org/show_bug.cgi?id=58671 Alan changed: What|Removed |Added Status|RESOLVED|CLOSED -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 58671] Nvidia drivers fail compile
https://bugzilla.kernel.org/show_bug.cgi?id=58671 Alan changed: What|Removed |Added Status|NEW |RESOLVED CC||alan at lxorguk.ukuu.org.uk Resolution|--- |INVALID -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 60031] NVidia 520MX video card isn't recognized
https://bugzilla.kernel.org/show_bug.cgi?id=60031 Alan changed: What|Removed |Added CC||alan at lxorguk.ukuu.org.uk Component|Platform|Video(DRI - non Intel) Assignee|drivers_platform at kernel-bug |drivers_video-dri at kernel-bu |s.osdl.org |gs.osdl.org -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 69689] FBO with GL_RGBA16F texture format silent drawing corruption
https://bugs.freedesktop.org/show_bug.cgi?id=69689 --- Comment #6 from Grigori Goronzy --- This works for me. Can you provide a test case? -- 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/20131112/d36d26c8/attachment.html>
[Bug 60568] nv49_ram_create kernel panic
https://bugzilla.kernel.org/show_bug.cgi?id=60568 Alan changed: What|Removed |Added CC||alan at lxorguk.ukuu.org.uk Component|Video(Other)|Video(DRI - non Intel) Assignee|drivers_video-other at kernel- |drivers_video-dri at kernel-bu |bugs.osdl.org |gs.osdl.org -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 69689] FBO with GL_RGBA16F texture format silent drawing corruption
https://bugs.freedesktop.org/show_bug.cgi?id=69689 --- Comment #5 from Johannes Jordan --- Is there any chance this bug gets fixed? -- 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/20131112/120b1434/attachment.html>
[Bug 60844] Kernel 3.11 - Xorg hangs immediately after invocation
https://bugzilla.kernel.org/show_bug.cgi?id=60844 Alan changed: What|Removed |Added CC||alan at lxorguk.ukuu.org.uk Component|Video(Other)|Video(DRI - non Intel) Assignee|drivers_video-other at kernel- |drivers_video-dri at kernel-bu |bugs.osdl.org |gs.osdl.org -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 60871] Possibly bug on Nouveau or IRQ
https://bugzilla.kernel.org/show_bug.cgi?id=60871 Alan changed: What|Removed |Added CC||alan at lxorguk.ukuu.org.uk Component|Console/Framebuffers|Video(DRI - non Intel) Assignee|jsimmons at infradead.org |drivers_video-dri at kernel-bu ||gs.osdl.org -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 63161] Linux mint 15 cinnamon crashes after install 3.11.5
https://bugzilla.kernel.org/show_bug.cgi?id=63161 Alan changed: What|Removed |Added CC||alan at lxorguk.ukuu.org.uk Component|Video(AGP) |Video(DRI - non Intel) Assignee|airlied at linux.ie|drivers_video-dri at kernel-bu ||gs.osdl.org -- You are receiving this mail because: You are watching the assignee of the bug.
[PULL] drm-intel-fixes
Hi Dave, Just one patch to fix compile fail for CONFIG_ACPI=n. Figured I better send this out quickly to minimize the broken build span. Otherwise no bugfixes (besides some bdw stuff) anywhere in sight. Cheers, Daniel The following changes since commit 07bf139b906013ecef0c5e0441564d1ae10e974a: drm/i915/vlv: use per-pipe backlight controls v2 (2013-11-06 18:26:31 +0100) are available in the git repository at: git://people.freedesktop.org/~danvet/drm-intel tags/drm-intel-fixes-2013-11-12 for you to fetch changes up to 1dca220b2b6ba605bff07c4d019dd2cd2d70036c: drm/i915/opregion: fix build error on CONFIG_ACPI=n (2013-11-08 19:32:52 +0100) Jani Nikula (1): drm/i915/opregion: fix build error on CONFIG_ACPI=n drivers/gpu/drm/i915/intel_opregion.c | 2 ++ 1 file changed, 2 insertions(+) -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Bug 60775] Installing NVIDIA proprietary drivers on kernel 3.10.7-100.fc18.x86_64 errors out . . . can't find kernel source files
https://bugzilla.kernel.org/show_bug.cgi?id=60775 Alan changed: What|Removed |Added Status|RESOLVED|CLOSED -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 60775] Installing NVIDIA proprietary drivers on kernel 3.10.7-100.fc18.x86_64 errors out . . . can't find kernel source files
https://bugzilla.kernel.org/show_bug.cgi?id=60775 Alan changed: What|Removed |Added Status|NEW |RESOLVED CC||alan at lxorguk.ukuu.org.uk Resolution|--- |INVALID --- Comment #2 from Alan --- Nvidia proprietary bugs need to go to Nvidia -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 71516] RV350 Radeon 9550 - no Unity 3D hardware support in Ubuntu 13.10, extremely slow
https://bugs.freedesktop.org/show_bug.cgi?id=71516 --- Comment #4 from Elven Decker --- I posted the output, it looks like some things are missing. Tonight I'll try to get them installed. Thanks. +-} On Nov 11, 2013, at 9:55 PM, bugzilla-daemon at freedesktop.org wrote: > Comment # 1 on bug 71516 from Michel D?nzer > Please attach the output of > > LIBGL_DEBUG=verbose glxinfo 2>&1 >/dev/null > You are receiving this mail because: > You reported the bug. -- 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/20131112/93e35d3a/attachment.html>
[PATCH 7/7] drm/nouveau: use a single vma for display
From: Maarten Lankhorst
No need to map the same vma multiple times.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/nouveau/nouveau_fence.h | 4 ++--
drivers/gpu/drm/nouveau/nv50_display.c | 13 ++---
drivers/gpu/drm/nouveau/nv50_display.h | 2 +-
drivers/gpu/drm/nouveau/nv50_fence.c| 24 +---
drivers/gpu/drm/nouveau/nv84_fence.c| 21 +
5 files changed, 31 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.h
b/drivers/gpu/drm/nouveau/nouveau_fence.h
index c57bb61..60ae4e7 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fence.h
+++ b/drivers/gpu/drm/nouveau/nouveau_fence.h
@@ -82,7 +82,7 @@ struct nv84_fence_chan {
struct nouveau_fence_chan base;
struct nouveau_vma vma;
struct nouveau_vma vma_gart;
- struct nouveau_vma dispc_vma[4];
+ struct nouveau_vma dispc_vma;
};
struct nv84_fence_priv {
@@ -92,7 +92,7 @@ struct nv84_fence_priv {
u32 *suspend;
};
-u64 nv84_fence_crtc(struct nouveau_channel *, int);
+u64 nv84_fence_crtc(struct nouveau_channel *);
int nv84_fence_context_new(struct nouveau_channel *);
#endif
diff --git a/drivers/gpu/drm/nouveau/nv50_display.c
b/drivers/gpu/drm/nouveau/nv50_display.c
index f8e66c0..4153c8a 100644
--- a/drivers/gpu/drm/nouveau/nv50_display.c
+++ b/drivers/gpu/drm/nouveau/nv50_display.c
@@ -433,7 +433,7 @@ evo_kick(u32 *push, void *evoc)
static bool
evo_sync_wait(void *data)
{
- if (nouveau_bo_rd32(data, EVO_MAST_NTFY) != 0x)
+ if (nouveau_bo_rd32(data, EVO_MAST_NTFY / 4) != 0x)
return true;
usleep_range(1, 2);
return false;
@@ -447,7 +447,7 @@ evo_sync(struct drm_device *dev)
struct nv50_mast *mast = nv50_mast(dev);
u32 *push = evo_wait(mast, 8);
if (push) {
- nouveau_bo_wr32(disp->sync, EVO_MAST_NTFY, 0x);
+ nouveau_bo_wr32(disp->sync, EVO_MAST_NTFY / 4, 0x);
evo_mthd(push, 0x0084, 1);
evo_data(push, 0x8000 | EVO_MAST_NTFY);
evo_mthd(push, 0x0080, 2);
@@ -465,7 +465,7 @@ evo_sync(struct drm_device *dev)
* Page flipping channel
*/
struct nouveau_bo *
-nv50_display_crtc_sema(struct drm_device *dev, int crtc)
+nv50_display_crtc_sema(struct drm_device *dev)
{
return nv50_disp(dev)->sync;
}
@@ -517,7 +517,6 @@ nv50_display_flip_next(struct drm_crtc *crtc, struct
drm_framebuffer *fb,
struct nouveau_channel *chan, u32 swap_interval)
{
struct nouveau_framebuffer *nv_fb = nouveau_framebuffer(fb);
- struct nouveau_crtc *nv_crtc = nouveau_crtc(crtc);
struct nv50_head *head = nv50_head(crtc);
struct nv50_sync *sync = nv50_sync(crtc);
u32 *push;
@@ -539,7 +538,7 @@ nv50_display_flip_next(struct drm_crtc *crtc, struct
drm_framebuffer *fb,
return ret;
BEGIN_NV04(chan, 0, NV11_SUBCHAN_DMA_SEMAPHORE, 2);
- OUT_RING (chan, NvEvoSema0 + nv_crtc->index);
+ OUT_RING (chan, NvEvoSema0);
OUT_RING (chan, sync->addr ^ 0x10);
BEGIN_NV04(chan, 0, NV11_SUBCHAN_SEMAPHORE_RELEASE, 1);
OUT_RING (chan, sync->data + 1);
@@ -548,7 +547,7 @@ nv50_display_flip_next(struct drm_crtc *crtc, struct
drm_framebuffer *fb,
OUT_RING (chan, sync->data);
} else
if (chan && nv_mclass(chan->object) < NVC0_CHANNEL_IND_CLASS) {
- u64 addr = nv84_fence_crtc(chan, nv_crtc->index) + sync->addr;
+ u64 addr = nv84_fence_crtc(chan) + sync->addr;
ret = RING_SPACE(chan, 12);
if (ret)
return ret;
@@ -567,7 +566,7 @@ nv50_display_flip_next(struct drm_crtc *crtc, struct
drm_framebuffer *fb,
OUT_RING (chan, NV84_SUBCHAN_SEMAPHORE_TRIGGER_ACQUIRE_EQUAL);
} else
if (chan) {
- u64 addr = nv84_fence_crtc(chan, nv_crtc->index) + sync->addr;
+ u64 addr = nv84_fence_crtc(chan) + sync->addr;
ret = RING_SPACE(chan, 10);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/nouveau/nv50_display.h
b/drivers/gpu/drm/nouveau/nv50_display.h
index 70da347..ea681be 100644
--- a/drivers/gpu/drm/nouveau/nv50_display.h
+++ b/drivers/gpu/drm/nouveau/nv50_display.h
@@ -40,6 +40,6 @@ void nv50_display_flip_stop(struct drm_crtc *);
int nv50_display_flip_next(struct drm_crtc *, struct drm_framebuffer *,
struct nouveau_channel *, u32 swap_interval);
-struct nouveau_bo *nv50_display_crtc_sema(struct drm_device *, int head);
+struct nouveau_bo *nv50_display_crtc_sema(struct drm_device *);
#endif /* __NV50_DISPLAY_H__ */
diff --git a/drivers/gpu/drm/nouveau/nv50_fence.c
b/drivers/gpu/drm/nouveau/nv
[PATCH 6/7] drm/nouveau: more paranoia in nouveau_bo_fixup_align
From: Maarten Lankhorst
Make sure that buffers are always aligned.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 40 +++-
1 file changed, 21 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index bb3734d..635a192 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -160,24 +160,20 @@ nouveau_bo_fixup_align(struct nouveau_bo *nvbo, u32 flags,
struct nouveau_drm *drm = nouveau_bdev(nvbo->bo.bdev);
struct nouveau_device *device = nv_device(drm->device);
- if (device->card_type < NV_50) {
- if (nvbo->tile_mode) {
- if (device->chipset >= 0x40) {
- *align = 65536;
- *size = roundup(*size, 64 * nvbo->tile_mode);
-
- } else if (device->chipset >= 0x30) {
- *align = 32768;
- *size = roundup(*size, 64 * nvbo->tile_mode);
-
- } else if (device->chipset >= 0x20) {
- *align = 16384;
- *size = roundup(*size, 64 * nvbo->tile_mode);
-
- } else if (device->chipset >= 0x10) {
- *align = 16384;
- *size = roundup(*size, 32 * nvbo->tile_mode);
- }
+ if (device->chipset >= 0x10 && device->card_type < NV_50 &&
+ nvbo->tile_mode) {
+ if (device->chipset >= 0x40) {
+ *align = 65536;
+ *size = roundup(*size, 64 * nvbo->tile_mode);
+ } else if (device->chipset >= 0x30) {
+ *align = 32768;
+ *size = roundup(*size, 64 * nvbo->tile_mode);
+ } else if (device->chipset >= 0x20) {
+ *align = 16384;
+ *size = roundup(*size, 64 * nvbo->tile_mode);
+ } else {
+ *align = 16384;
+ *size = roundup(*size, 32 * nvbo->tile_mode);
}
} else {
*size = roundup(*size, (1 << nvbo->page_shift));
@@ -228,8 +224,14 @@ nouveau_bo_new(struct drm_device *dev, int size, int align,
if (!(flags & TTM_PL_FLAG_TT) && size > 256 * 1024)
nvbo->page_shift = drm->client.base.vm->vmm->lpg_shift;
}
-
nouveau_bo_fixup_align(nvbo, flags, &align, &size);
+ if (size <= 0) {
+ nv_warn(drm, "invalid size %x after setting alignment %x\n",
+ size, align);
+ kfree(nvbo);
+ return -EINVAL;
+ }
+
nvbo->bo.mem.num_pages = size >> PAGE_SHIFT;
nouveau_bo_placement_set(nvbo, flags, 0);
--
1.8.4
[PATCH 5/7] drm/nouveau: do not map evicted vram buffers in nouveau_bo_vma_add
From: Maarten Lankhorst
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 9ecb874..bb3734d 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1549,7 +1549,8 @@ nouveau_bo_vma_add(struct nouveau_bo *nvbo, struct
nouveau_vm *vm,
if (nvbo->bo.mem.mem_type == TTM_PL_VRAM)
nouveau_vm_map(vma, nvbo->bo.mem.mm_node);
- else if (nvbo->bo.mem.mem_type == TTM_PL_TT) {
+ else if (nvbo->bo.mem.mem_type == TTM_PL_TT &&
+nvbo->page_shift == vma->vm->vmm->spg_shift) {
if (node->sg)
nouveau_vm_map_sg_table(vma, 0, size, node);
else
--
1.8.4
[PATCH 4/7] drm/nvc0-/gr: shift wrapping bug in nvc0_grctx_generate_r406800
From: Dan Carpenter We care about the upper 32 bits here so we have to use 1ULL instead of 1 to avoid a shift wrapping bug. Signed-off-by: Dan Carpenter Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/nouveau/core/engine/graph/ctxnvc0.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/core/engine/graph/ctxnvc0.c b/drivers/gpu/drm/nouveau/core/engine/graph/ctxnvc0.c index 64dca26..fe67415 100644 --- a/drivers/gpu/drm/nouveau/core/engine/graph/ctxnvc0.c +++ b/drivers/gpu/drm/nouveau/core/engine/graph/ctxnvc0.c @@ -1039,7 +1039,7 @@ nvc0_grctx_generate_r406800(struct nvc0_graph_priv *priv) } while (!tpcnr[gpc]); tpc = priv->tpc_nr[gpc] - tpcnr[gpc]--; - tpc_set |= 1 << ((gpc * 8) + tpc); + tpc_set |= 1ULL << ((gpc * 8) + tpc); } nv_wr32(priv, 0x406800 + (i * 0x20), lower_32_bits(tpc_set)); -- 1.8.4
[PATCH 3/7] drm/nouveau: fixup locking inversion between mmap_sem and reservations
From: Maarten Lankhorst
Allocate and copy all kernel memory before doing reservations. This prevents a
locking
inversion between mmap_sem and reservation_class, and allows us to drop the
trylocking
in ttm_bo_vm_fault without upsetting lockdep.
Relocations are handled by trying with __copy_from_user_inatomic first. If that
fails
all validation will be undone, memory copied from userspace and all validations
retried.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/nouveau/nouveau_gem.c | 188 +-
1 file changed, 119 insertions(+), 69 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index f32b712..41a4bf6 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -464,8 +464,6 @@ validate_list(struct nouveau_channel *chan, struct
nouveau_cli *cli,
uint64_t user_pbbo_ptr)
{
struct nouveau_drm *drm = chan->drm;
- struct drm_nouveau_gem_pushbuf_bo __user *upbbo =
- (void __force __user *)(uintptr_t)user_pbbo_ptr;
struct nouveau_bo *nvbo;
int ret, relocs = 0;
@@ -499,7 +497,7 @@ validate_list(struct nouveau_channel *chan, struct
nouveau_cli *cli,
return ret;
}
- if (nv_device(drm->device)->card_type < NV_50) {
+ if (nv_device(drm->device)->card_type < NV_50 && !relocs) {
if (nvbo->bo.offset == b->presumed.offset &&
((nvbo->bo.mem.mem_type == TTM_PL_VRAM &&
b->presumed.domain & NOUVEAU_GEM_DOMAIN_VRAM) ||
@@ -507,32 +505,53 @@ validate_list(struct nouveau_channel *chan, struct
nouveau_cli *cli,
b->presumed.domain & NOUVEAU_GEM_DOMAIN_GART)))
continue;
- if (nvbo->bo.mem.mem_type == TTM_PL_TT)
- b->presumed.domain = NOUVEAU_GEM_DOMAIN_GART;
- else
- b->presumed.domain = NOUVEAU_GEM_DOMAIN_VRAM;
- b->presumed.offset = nvbo->bo.offset;
- b->presumed.valid = 0;
- relocs++;
-
- if (DRM_COPY_TO_USER(&upbbo[nvbo->pbbo_index].presumed,
-&b->presumed, sizeof(b->presumed)))
- return -EFAULT;
+ relocs = 1;
}
}
return relocs;
}
+static inline void *
+u_memcpya(uint64_t user, unsigned nmemb, unsigned size, unsigned inatomic)
+{
+ void *mem;
+ void __user *userptr = (void __force __user *)(uintptr_t)user;
+
+ mem = drm_malloc_ab(size, nmemb);
+ if (!mem)
+ return ERR_PTR(-ENOMEM);
+ size *= nmemb;
+
+ if (inatomic && (!access_ok(VERIFY_READ, userptr, size) ||
+ __copy_from_user_inatomic(mem, userptr, size))) {
+ drm_free_large(mem);
+ return ERR_PTR(-EFAULT);
+ } else if (!inatomic && copy_from_user(mem, userptr, size)) {
+ drm_free_large(mem);
+ return ERR_PTR(-EFAULT);
+ }
+
+ return mem;
+}
+
+static int
+nouveau_gem_pushbuf_reloc_apply(struct nouveau_cli *cli,
+ struct drm_nouveau_gem_pushbuf *req,
+ struct drm_nouveau_gem_pushbuf_bo *bo,
+ struct drm_nouveau_gem_pushbuf_reloc *reloc);
+
static int
nouveau_gem_pushbuf_validate(struct nouveau_channel *chan,
struct drm_file *file_priv,
struct drm_nouveau_gem_pushbuf_bo *pbbo,
+struct drm_nouveau_gem_pushbuf *req,
uint64_t user_buffers, int nr_buffers,
-struct validate_op *op, int *apply_relocs)
+struct validate_op *op, int *do_reloc)
{
struct nouveau_cli *cli = nouveau_cli(file_priv);
int ret, relocs = 0;
+ struct drm_nouveau_gem_pushbuf_reloc *reloc = NULL;
INIT_LIST_HEAD(&op->vram_list);
INIT_LIST_HEAD(&op->gart_list);
@@ -541,19 +560,19 @@ nouveau_gem_pushbuf_validate(struct nouveau_channel *chan,
if (nr_buffers == 0)
return 0;
+restart:
ret = validate_init(chan, file_priv, pbbo, nr_buffers, op);
if (unlikely(ret)) {
if (ret != -ERESTARTSYS)
NV_ERROR(cli, "validate_init\n");
- return ret;
+ goto err;
}
ret = validate_list(chan, cli, &op->vram_list, pbbo, user_buffers);
if (unlikely(ret < 0)) {
if (ret != -ERESTARTSYS)
NV_ERROR(cli, "validate vram_list\n");
- validate_fini(op, NULL);
- return ret;
+
[PATCH 2/7] drm/nv50-: untile mmap'd bo's
From: Maarten Lankhorst
Map the GART to the bar and use that mapping, to hide all the tiling details
from users.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/nouveau/core/subdev/bar/nv50.c | 5 -
drivers/gpu/drm/nouveau/core/subdev/bar/nvc0.c | 5 -
drivers/gpu/drm/nouveau/nouveau_bo.c | 20 +---
3 files changed, 25 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/core/subdev/bar/nv50.c
b/drivers/gpu/drm/nouveau/core/subdev/bar/nv50.c
index 160d27f..9907a25 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/bar/nv50.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/bar/nv50.c
@@ -67,7 +67,10 @@ nv50_bar_umap(struct nouveau_bar *bar, struct nouveau_mem
*mem,
if (ret)
return ret;
- nouveau_vm_map(vma, mem);
+ if (mem->pages)
+ nouveau_vm_map_sg(vma, 0, mem->size << 12, mem);
+ else
+ nouveau_vm_map(vma, mem);
return 0;
}
diff --git a/drivers/gpu/drm/nouveau/core/subdev/bar/nvc0.c
b/drivers/gpu/drm/nouveau/core/subdev/bar/nvc0.c
index b2ec741..badd835 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/bar/nvc0.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/bar/nvc0.c
@@ -66,7 +66,10 @@ nvc0_bar_umap(struct nouveau_bar *bar, struct nouveau_mem
*mem,
if (ret)
return ret;
- nouveau_vm_map(vma, mem);
+ if (mem->pages)
+ nouveau_vm_map_sg(vma, 0, mem->size << 12, mem);
+ else
+ nouveau_vm_map(vma, mem);
return 0;
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 639d7cd..9ecb874 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1259,6 +1259,7 @@ nouveau_ttm_io_mem_reserve(struct ttm_bo_device *bdev,
struct ttm_mem_reg *mem)
{
struct ttm_mem_type_manager *man = &bdev->man[mem->mem_type];
struct nouveau_drm *drm = nouveau_bdev(bdev);
+ struct nouveau_mem *node = mem->mm_node;
struct drm_device *dev = drm->dev;
int ret;
@@ -1281,14 +1282,16 @@ nouveau_ttm_io_mem_reserve(struct ttm_bo_device *bdev,
struct ttm_mem_reg *mem)
mem->bus.is_iomem = !dev->agp->cant_use_aperture;
}
#endif
- break;
+ if (!node->memtype)
+ /* untiled */
+ break;
+ /* fallthrough, tiled memory */
case TTM_PL_VRAM:
mem->bus.offset = mem->start << PAGE_SHIFT;
mem->bus.base = pci_resource_start(dev->pdev, 1);
mem->bus.is_iomem = true;
if (nv_device(drm->device)->card_type >= NV_50) {
struct nouveau_bar *bar = nouveau_bar(drm->device);
- struct nouveau_mem *node = mem->mm_node;
ret = bar->umap(bar, node, NV_MEM_ACCESS_RW,
&node->bar_vma);
@@ -1324,6 +1327,7 @@ nouveau_ttm_fault_reserve_notify(struct ttm_buffer_object
*bo)
struct nouveau_bo *nvbo = nouveau_bo(bo);
struct nouveau_device *device = nv_device(drm->device);
u32 mappable = pci_resource_len(device->pdev, 1) >> PAGE_SHIFT;
+ int ret;
/* as long as the bo isn't in vram, and isn't tiled, we've got
* nothing to do here.
@@ -1332,10 +1336,20 @@ nouveau_ttm_fault_reserve_notify(struct
ttm_buffer_object *bo)
if (nv_device(drm->device)->card_type < NV_50 ||
!nouveau_bo_tile_layout(nvbo))
return 0;
+
+ if (bo->mem.mem_type == TTM_PL_SYSTEM) {
+ nouveau_bo_placement_set(nvbo, TTM_PL_TT, 0);
+
+ ret = nouveau_bo_validate(nvbo, false, false);
+ if (ret)
+ return ret;
+ }
+ return 0;
}
/* make sure bo is in mappable vram */
- if (bo->mem.start + bo->mem.num_pages < mappable)
+ if (nv_device(drm->device)->card_type >= NV_50 ||
+ bo->mem.start + bo->mem.num_pages < mappable)
return 0;
--
1.8.4
[PATCH 1/7] drm/nouveau: fix m2mf copy to tiled gart
From: Maarten Lankhorst
Commit de7b7d59d54852c introduced tiled GART, but a linear copy is
still performed. This may result in errors on eviction, fix it by
checking tiling from memtype.
Signed-off-by: Maarten Lankhorst
Cc: stable at vger.kernel.org #3.10+
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 33 -
1 file changed, 8 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index f5b0201..639d7cd 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -803,25 +803,25 @@ nv50_bo_move_m2mf(struct nouveau_channel *chan, struct
ttm_buffer_object *bo,
struct ttm_mem_reg *old_mem, struct ttm_mem_reg *new_mem)
{
struct nouveau_mem *node = old_mem->mm_node;
- struct nouveau_bo *nvbo = nouveau_bo(bo);
u64 length = (new_mem->num_pages << PAGE_SHIFT);
u64 src_offset = node->vma[0].offset;
u64 dst_offset = node->vma[1].offset;
+ int src_tiled = !!node->memtype;
+ int dst_tiled = !!((struct nouveau_mem *)new_mem->mm_node)->memtype;
int ret;
while (length) {
u32 amount, stride, height;
+ ret = RING_SPACE(chan, 18 + 6 * (src_tiled + dst_tiled));
+ if (ret)
+ return ret;
+
amount = min(length, (u64)(4 * 1024 * 1024));
stride = 16 * 4;
height = amount / stride;
- if (old_mem->mem_type == TTM_PL_VRAM &&
- nouveau_bo_tile_layout(nvbo)) {
- ret = RING_SPACE(chan, 8);
- if (ret)
- return ret;
-
+ if (src_tiled) {
BEGIN_NV04(chan, NvSubCopy, 0x0200, 7);
OUT_RING (chan, 0);
OUT_RING (chan, 0);
@@ -831,19 +831,10 @@ nv50_bo_move_m2mf(struct nouveau_channel *chan, struct
ttm_buffer_object *bo,
OUT_RING (chan, 0);
OUT_RING (chan, 0);
} else {
- ret = RING_SPACE(chan, 2);
- if (ret)
- return ret;
-
BEGIN_NV04(chan, NvSubCopy, 0x0200, 1);
OUT_RING (chan, 1);
}
- if (new_mem->mem_type == TTM_PL_VRAM &&
- nouveau_bo_tile_layout(nvbo)) {
- ret = RING_SPACE(chan, 8);
- if (ret)
- return ret;
-
+ if (dst_tiled) {
BEGIN_NV04(chan, NvSubCopy, 0x021c, 7);
OUT_RING (chan, 0);
OUT_RING (chan, 0);
@@ -853,18 +844,10 @@ nv50_bo_move_m2mf(struct nouveau_channel *chan, struct
ttm_buffer_object *bo,
OUT_RING (chan, 0);
OUT_RING (chan, 0);
} else {
- ret = RING_SPACE(chan, 2);
- if (ret)
- return ret;
-
BEGIN_NV04(chan, NvSubCopy, 0x021c, 1);
OUT_RING (chan, 1);
}
- ret = RING_SPACE(chan, 14);
- if (ret)
- return ret;
-
BEGIN_NV04(chan, NvSubCopy, 0x0238, 2);
OUT_RING (chan, upper_32_bits(src_offset));
OUT_RING (chan, upper_32_bits(dst_offset));
--
1.8.4
[patch v2] drm/tegra: fix small leak on error in tegra_fb_alloc()
If we don't have enough memory for ->planes then we leak "fb".
Signed-off-by: Dan Carpenter
---
v2: tiny style changes
diff --git a/drivers/gpu/drm/tegra/fb.c b/drivers/gpu/drm/tegra/fb.c
index 490f771..f9d2de6 100644
--- a/drivers/gpu/drm/tegra/fb.c
+++ b/drivers/gpu/drm/tegra/fb.c
@@ -98,8 +98,10 @@ static struct tegra_fb *tegra_fb_alloc(struct drm_device
*drm,
return ERR_PTR(-ENOMEM);
fb->planes = kzalloc(num_planes * sizeof(*planes), GFP_KERNEL);
- if (!fb->planes)
+ if (!fb->planes) {
+ kfree(fb);
return ERR_PTR(-ENOMEM);
+ }
fb->num_planes = num_planes;
[Bug 71516] RV350 Radeon 9550 - no Unity 3D hardware support in Ubuntu 13.10, extremely slow
https://bugs.freedesktop.org/show_bug.cgi?id=71516 --- Comment #3 from Elven Decker --- Looks like some thinhgs are definitely not there. I'll work tonight to get them in place. 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/20131112/5da12c65/attachment.html>
[Bug 71516] RV350 Radeon 9550 - no Unity 3D hardware support in Ubuntu 13.10, extremely slow
https://bugs.freedesktop.org/show_bug.cgi?id=71516 --- Comment #2 from Elven Decker --- LIBGL_DEBUG=verbose glxinfo 2>&1 > /dev/null libGL: OpenDriver: trying /usr/lib/i386-linux-gnu/dri/tls/swrast_dri.so libGL: OpenDriver: trying /usr/lib/i386-linux-gnu/dri/swrast_dri.so libGL: Can't open configuration file /home/xx/.drirc: No such file or directory. libGL: Can't open configuration file /home/xx/.drirc: No such file or directory. libGL: Can't open configuration file /home/xx/.drirc: No such file or directory. libGL: Can't open configuration file /home/xx/.drirc: No such file or directory. libGL: Can't open configuration file /home/xx/.drirc: No such file or directory. libGL: Can't open configuration file /home/xx/.drirc: No such file or directory. libGL: Can't open configuration file /home/xx/.drirc: No such file or directory. libGL: Can't open configuration file /home/xx/.drirc: No such file or directory. libGL: Can't open configuration file /home/xx/.drirc: No such file or directory. -- 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/20131112/d1b3be2c/attachment.html>
[PATCH 3/3] drm/radeon: disable CIK CP semaphores for now
From: Christian K?nig
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/cik.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index 811fc1b..c169897 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -3561,6 +3561,8 @@ bool cik_semaphore_ring_emit(struct radeon_device *rdev,
struct radeon_semaphore *semaphore,
bool emit_wait)
{
+/* TODO: figure out why semaphore cause lockups */
+#if 0
uint64_t addr = semaphore->gpu_addr;
unsigned sel = emit_wait ? PACKET3_SEM_SEL_WAIT :
PACKET3_SEM_SEL_SIGNAL;
@@ -3569,6 +3571,9 @@ bool cik_semaphore_ring_emit(struct radeon_device *rdev,
radeon_ring_write(ring, (upper_32_bits(addr) & 0x) | sel);
return true;
+#else
+ return false;
+#endif
}
/**
--
1.8.1.2
[PATCH 2/3] drm/radeon: allow semaphore emission to fail
From: Christian K?nig
To workaround bugs and/or certain limits it's sometimes
useful to fall back to waiting on fences.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/cik.c | 13 ++-
drivers/gpu/drm/radeon/cik_sdma.c | 13 ++-
drivers/gpu/drm/radeon/evergreen_dma.c| 9 +--
drivers/gpu/drm/radeon/r100.c | 3 +-
drivers/gpu/drm/radeon/r600.c | 13 ++-
drivers/gpu/drm/radeon/r600_dma.c | 13 ++-
drivers/gpu/drm/radeon/radeon.h | 14 ++--
drivers/gpu/drm/radeon/radeon_asic.h | 18 ++---
drivers/gpu/drm/radeon/radeon_cs.c| 9 ++-
drivers/gpu/drm/radeon/radeon_fence.c | 30 +++
drivers/gpu/drm/radeon/radeon_gart.c | 4 +-
drivers/gpu/drm/radeon/radeon_ring.c | 46 +++
drivers/gpu/drm/radeon/radeon_semaphore.c | 127 ++
drivers/gpu/drm/radeon/rv770_dma.c| 9 +--
drivers/gpu/drm/radeon/si_dma.c | 9 +--
drivers/gpu/drm/radeon/uvd_v1_0.c | 4 +-
drivers/gpu/drm/radeon/uvd_v3_1.c | 4 +-
17 files changed, 191 insertions(+), 147 deletions(-)
diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index ae92aa0..811fc1b 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -3556,7 +3556,7 @@ void cik_fence_compute_ring_emit(struct radeon_device
*rdev,
radeon_ring_write(ring, 0);
}
-void cik_semaphore_ring_emit(struct radeon_device *rdev,
+bool cik_semaphore_ring_emit(struct radeon_device *rdev,
struct radeon_ring *ring,
struct radeon_semaphore *semaphore,
bool emit_wait)
@@ -3567,6 +3567,8 @@ void cik_semaphore_ring_emit(struct radeon_device *rdev,
radeon_ring_write(ring, PACKET3(PACKET3_MEM_SEMAPHORE, 1));
radeon_ring_write(ring, addr & 0x);
radeon_ring_write(ring, (upper_32_bits(addr) & 0x) | sel);
+
+ return true;
}
/**
@@ -3609,13 +3611,8 @@ int cik_copy_cpdma(struct radeon_device *rdev,
return r;
}
- if (radeon_fence_need_sync(*fence, ring->idx)) {
- radeon_semaphore_sync_rings(rdev, sem, (*fence)->ring,
- ring->idx);
- radeon_fence_note_sync(*fence, ring->idx);
- } else {
- radeon_semaphore_free(rdev, &sem, NULL);
- }
+ radeon_semaphore_sync_to(sem, *fence);
+ radeon_semaphore_sync_rings(rdev, sem, ring->idx);
for (i = 0; i < num_loops; i++) {
cur_size_in_bytes = size_in_bytes;
diff --git a/drivers/gpu/drm/radeon/cik_sdma.c
b/drivers/gpu/drm/radeon/cik_sdma.c
index 9c9529d..0300727 100644
--- a/drivers/gpu/drm/radeon/cik_sdma.c
+++ b/drivers/gpu/drm/radeon/cik_sdma.c
@@ -130,7 +130,7 @@ void cik_sdma_fence_ring_emit(struct radeon_device *rdev,
* Add a DMA semaphore packet to the ring wait on or signal
* other rings (CIK).
*/
-void cik_sdma_semaphore_ring_emit(struct radeon_device *rdev,
+bool cik_sdma_semaphore_ring_emit(struct radeon_device *rdev,
struct radeon_ring *ring,
struct radeon_semaphore *semaphore,
bool emit_wait)
@@ -141,6 +141,8 @@ void cik_sdma_semaphore_ring_emit(struct radeon_device
*rdev,
radeon_ring_write(ring, SDMA_PACKET(SDMA_OPCODE_SEMAPHORE, 0,
extra_bits));
radeon_ring_write(ring, addr & 0xfff8);
radeon_ring_write(ring, upper_32_bits(addr) & 0x);
+
+ return true;
}
/**
@@ -443,13 +445,8 @@ int cik_copy_dma(struct radeon_device *rdev,
return r;
}
- if (radeon_fence_need_sync(*fence, ring->idx)) {
- radeon_semaphore_sync_rings(rdev, sem, (*fence)->ring,
- ring->idx);
- radeon_fence_note_sync(*fence, ring->idx);
- } else {
- radeon_semaphore_free(rdev, &sem, NULL);
- }
+ radeon_semaphore_sync_to(sem, *fence);
+ radeon_semaphore_sync_rings(rdev, sem, ring->idx);
for (i = 0; i < num_loops; i++) {
cur_size_in_bytes = size_in_bytes;
diff --git a/drivers/gpu/drm/radeon/evergreen_dma.c
b/drivers/gpu/drm/radeon/evergreen_dma.c
index 6a0656d..a37b544 100644
--- a/drivers/gpu/drm/radeon/evergreen_dma.c
+++ b/drivers/gpu/drm/radeon/evergreen_dma.c
@@ -131,13 +131,8 @@ int evergreen_copy_dma(struct radeon_device *rdev,
return r;
}
- if (radeon_fence_need_sync(*fence, ring->idx)) {
- radeon_semaphore_sync_rings(rdev, sem, (*fence)->ring,
- ring->idx);
- radeon_fence_note_sync(*fence, ring->idx);
- } else {
- radeon_semaphore_free(rdev, &sem, NULL);
- }
+ radeon_semaphore_sync_to(sem, *fence);
+ radeon_sem
[PATCH 1/3] drm/radeon: add semaphore trace point
From: Christian K?nig
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_semaphore.c | 6 +-
drivers/gpu/drm/radeon/radeon_trace.h | 36 +++
2 files changed, 41 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_semaphore.c
b/drivers/gpu/drm/radeon/radeon_semaphore.c
index 8dcc20f..97d73bf 100644
--- a/drivers/gpu/drm/radeon/radeon_semaphore.c
+++ b/drivers/gpu/drm/radeon/radeon_semaphore.c
@@ -29,7 +29,7 @@
*/
#include
#include "radeon.h"
-
+#include "radeon_trace.h"
int radeon_semaphore_create(struct radeon_device *rdev,
struct radeon_semaphore **semaphore)
@@ -56,6 +56,8 @@ int radeon_semaphore_create(struct radeon_device *rdev,
void radeon_semaphore_emit_signal(struct radeon_device *rdev, int ring,
struct radeon_semaphore *semaphore)
{
+ trace_radeon_semaphore_signale(ring, semaphore);
+
--semaphore->waiters;
radeon_semaphore_ring_emit(rdev, ring, &rdev->ring[ring], semaphore,
false);
}
@@ -63,6 +65,8 @@ void radeon_semaphore_emit_signal(struct radeon_device *rdev,
int ring,
void radeon_semaphore_emit_wait(struct radeon_device *rdev, int ring,
struct radeon_semaphore *semaphore)
{
+ trace_radeon_semaphore_wait(ring, semaphore);
+
++semaphore->waiters;
radeon_semaphore_ring_emit(rdev, ring, &rdev->ring[ring], semaphore,
true);
}
diff --git a/drivers/gpu/drm/radeon/radeon_trace.h
b/drivers/gpu/drm/radeon/radeon_trace.h
index 811bca6..9f0e181 100644
--- a/drivers/gpu/drm/radeon/radeon_trace.h
+++ b/drivers/gpu/drm/radeon/radeon_trace.h
@@ -111,6 +111,42 @@ DEFINE_EVENT(radeon_fence_request, radeon_fence_wait_end,
TP_ARGS(dev, seqno)
);
+DECLARE_EVENT_CLASS(radeon_semaphore_request,
+
+ TP_PROTO(int ring, struct radeon_semaphore *sem),
+
+ TP_ARGS(ring, sem),
+
+ TP_STRUCT__entry(
+__field(int, ring)
+__field(signed, waiters)
+__field(uint64_t, gpu_addr)
+),
+
+ TP_fast_assign(
+ __entry->ring = ring;
+ __entry->waiters = sem->waiters;
+ __entry->gpu_addr = sem->gpu_addr;
+ ),
+
+ TP_printk("ring=%u, waiters=%d, addr=%010Lx", __entry->ring,
+ __entry->waiters, __entry->gpu_addr)
+);
+
+DEFINE_EVENT(radeon_semaphore_request, radeon_semaphore_signale,
+
+ TP_PROTO(int ring, struct radeon_semaphore *sem),
+
+ TP_ARGS(ring, sem)
+);
+
+DEFINE_EVENT(radeon_semaphore_request, radeon_semaphore_wait,
+
+ TP_PROTO(int ring, struct radeon_semaphore *sem),
+
+ TP_ARGS(ring, sem)
+);
+
#endif
/* This part must be outside protection */
--
1.8.1.2
drm/nouveau/pwr: initial implementation
Hello Ben Skeggs,
The patch ff4b42c7532e: "drm/nouveau/pwr: initial implementation"
from Oct 15, 2013, leads to the following Smatch warning:
"drivers/gpu/drm/nouveau/core/subdev/pwr/base.c:48 nouveau_pwr_send()
warn: 'mutex:&subdev->mutex' is sometimes locked here and sometimes
unlocked."
drivers/gpu/drm/nouveau/core/subdev/pwr/base.c
35 /* we currently only support a single process at a time waiting
36 * on a synchronous reply, take the PPWR mutex and tell the
37 * receive handler what we're waiting for
38 */
39 if (reply) {
40 mutex_lock(&subdev->mutex);
41 ppwr->recv.message = message;
42 ppwr->recv.process = process;
43 }
44
45 /* wait for a free slot in the fifo */
46 addr = nv_rd32(ppwr, 0x10a4a0);
47 if (!nv_wait_ne(ppwr, 0x10a4b0, 0x, addr ^ 8))
48 return -EBUSY;
Should we have an if (reply) mutex_unlock(&subdev->mutex) before the
return?
49
regards,
dan carpenter
[PATCH v3 12/32] drm/exynos: Split manager/display/subdrv
On Sun, Nov 10, 2013 at 4:09 PM, Tomasz Figa wrote: > Hi Sean, > > On Tuesday 29 of October 2013 12:12:58 Sean Paul wrote: >> This patch splits display and manager from subdrv. The result is that >> crtc functions can directly call into manager callbacks and encoder >> functions can directly call into display callbacks. This will allow >> us to remove the exynos_drm_hdmi shim and support mixer/hdmi & fimd/dp >> with common code. >> >> Signed-off-by: Sean Paul >> --- >> >> Changes in v2: >> - Pass display into display_ops instead of context >> Changes in v3: >> - Changed vidi args to exynos_drm_display instead of void >> - Moved exynos_drm_hdmi.c removal into next patch >> >> drivers/gpu/drm/exynos/exynos_drm_connector.c | 50 ++--- >> drivers/gpu/drm/exynos/exynos_drm_core.c | 181 +- >> drivers/gpu/drm/exynos/exynos_drm_crtc.c | 115 +--- >> drivers/gpu/drm/exynos/exynos_drm_crtc.h | 20 +- >> drivers/gpu/drm/exynos/exynos_drm_drv.c | 29 +-- >> drivers/gpu/drm/exynos/exynos_drm_drv.h | 106 +++ >> drivers/gpu/drm/exynos/exynos_drm_encoder.c | 258 >> -- >> drivers/gpu/drm/exynos/exynos_drm_encoder.h | 18 +- >> drivers/gpu/drm/exynos/exynos_drm_fb.c| 4 +- >> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 161 >> drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 211 + >> drivers/gpu/drm/exynos/exynos_drm_hdmi.h | 2 + >> drivers/gpu/drm/exynos/exynos_drm_plane.c | 15 +- >> drivers/gpu/drm/exynos/exynos_drm_vidi.c | 129 ++--- >> 14 files changed, 615 insertions(+), 684 deletions(-) > > This patch is really heavy, making it very hard to review. I wonder if it > couldn't really be split into several smaller patches... > I've distilled it down as much as possible. Unfortunately the encoder/crtc were fused pretty tightly and the effects of that are far-reaching. > Anyway, please see my comments below, for the points I haven't overlooked > due to the complexity of this patch. > >> diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c >> b/drivers/gpu/drm/exynos/exynos_drm_core.c >> index 08ca4f9..e76098d 100644 >> --- a/drivers/gpu/drm/exynos/exynos_drm_core.c >> +++ b/drivers/gpu/drm/exynos/exynos_drm_core.c >> @@ -16,11 +16,14 @@ >> #include >> #include > > Huh? Including a specific bridge chip inside a generic Exynos DRM core? > I know this is not a part of this patch, but... this is _broken_. > > You may want to support multiple bridge chips in Exynos DRM core and you > may also want to support PTN3460 in other DRM cores. It can't be done this > way. > > This series is very nice, but the whole effect is destroyed by basing it > on top of such insanity... Please rebase it on top of something more > reasonable (preferably Inki's next branch directly). > Well, that was blunt. Unfortunately, I don't know how else to do this other than this broken, unreasonable and insane way. This has already been discussed at length in a few other places. Without some help from the drm layer, I don't see any other way to do this than to enumerate the possible bridges in each drm driver. I based the current set off the "Add some missing bits for exynos5250-snow" series I sent up a little while ago. This set was sent to the relevant dt people, acked by Olof, and there are no outstanding review comments. Since it's required for me to test on Real Hardware, I assumed this was an appropriate base. If you think this is _broken_, unreasonable, and insane, I'd love to hear an alternative. Sean > Otherwise, this patch seems reasonable (except its size). > > Best regards, > Tomasz >
[PATCH 2/2] drm/vmwgfx: Resource evict fixes
Fix an error message that was incorrectly blaming device resource id
shortage.
Also make sure we correctly catch resource eviction errors, that
could otherwise lead to evictable resources temporarily not being on the
LRU list.
Signed-off-by: Thomas Hellstrom
Reviewed-by: Jakob Bornecrantz
---
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 42 +-
1 file changed, 36 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
index 3f43a44..07175bf 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
@@ -33,6 +33,8 @@
#include "vmwgfx_resource_priv.h"
#include "vmwgfx_prime.h"
+#define VMW_RES_EVICT_ERR_COUNT 10
+
struct vmw_user_dma_buffer {
struct vmw_prime_object prime;
struct vmw_dma_buffer dma;
@@ -1097,8 +1099,9 @@ vmw_resource_backoff_reservation(struct ww_acquire_ctx
*ticket,
* to a backup buffer.
*
* @res:The resource to evict.
+ * @interruptible: Whether to wait interruptible.
*/
-int vmw_resource_do_evict(struct vmw_resource *res)
+int vmw_resource_do_evict(struct vmw_resource *res, bool interruptible)
{
struct ttm_validate_buffer val_buf;
const struct vmw_res_func *func = res->func;
@@ -1108,7 +,8 @@ int vmw_resource_do_evict(struct vmw_resource *res)
BUG_ON(!func->may_evict);
val_buf.bo = NULL;
- ret = vmw_resource_check_buffer(res, &ticket, true, &val_buf);
+ ret = vmw_resource_check_buffer(res, &ticket, interruptible,
+ &val_buf);
if (unlikely(ret != 0))
return ret;
@@ -1147,6 +1151,7 @@ int vmw_resource_validate(struct vmw_resource *res)
struct vmw_private *dev_priv = res->dev_priv;
struct list_head *lru_list = &dev_priv->res_lru[res->func->res_type];
struct ttm_validate_buffer val_buf;
+ unsigned err_count = 0;
if (likely(!res->func->may_evict))
return 0;
@@ -1161,7 +1166,7 @@ int vmw_resource_validate(struct vmw_resource *res)
write_lock(&dev_priv->resource_lock);
if (list_empty(lru_list) || !res->func->may_evict) {
- DRM_ERROR("Out of device device id entries "
+ DRM_ERROR("Out of device device resources "
"for %s.\n", res->func->type_name);
ret = -EBUSY;
write_unlock(&dev_priv->resource_lock);
@@ -1174,7 +1179,19 @@ int vmw_resource_validate(struct vmw_resource *res)
list_del_init(&evict_res->lru_head);
write_unlock(&dev_priv->resource_lock);
- vmw_resource_do_evict(evict_res);
+
+ ret = vmw_resource_do_evict(evict_res, true);
+ if (unlikely(ret != 0)) {
+ write_lock(&dev_priv->resource_lock);
+ list_add_tail(&evict_res->lru_head, lru_list);
+ write_unlock(&dev_priv->resource_lock);
+ if (ret == -ERESTARTSYS ||
+ ++err_count > VMW_RES_EVICT_ERR_COUNT) {
+ vmw_resource_unreference(&evict_res);
+ goto out_no_validate;
+ }
+ }
+
vmw_resource_unreference(&evict_res);
} while (1);
@@ -1259,13 +1276,15 @@ bool vmw_resource_needs_backup(const struct
vmw_resource *res)
* @type: The resource type to evict
*
* To avoid thrashing starvation or as part of the hibernation sequence,
- * evict all evictable resources of a specific type.
+ * try to evict all evictable resources of a specific type.
*/
static void vmw_resource_evict_type(struct vmw_private *dev_priv,
enum vmw_res_type type)
{
struct list_head *lru_list = &dev_priv->res_lru[type];
struct vmw_resource *evict_res;
+ unsigned err_count = 0;
+ int ret;
do {
write_lock(&dev_priv->resource_lock);
@@ -1278,7 +1297,18 @@ static void vmw_resource_evict_type(struct vmw_private
*dev_priv,
lru_head));
list_del_init(&evict_res->lru_head);
write_unlock(&dev_priv->resource_lock);
- vmw_resource_do_evict(evict_res);
+
+ ret = vmw_resource_do_evict(evict_res, false);
+ if (unlikely(ret != 0)) {
+ write_lock(&dev_priv->resource_lock);
+ list_add_tail(&evict_res->lru_head, lru_list);
+ write_unlock(&dev_priv->resource_lock);
+ if (++err_count > VMW_RES_EVICT_ERR_COUNT) {
+ vmw_resource_unreference(&evict_res);
+ return;
+ }
+
[PATCH 1/2] drm/vmwgfx: Fix a couple of compile / sparse warnings and errors
Fixes
*) an implicit function declaration on mips,
*) a defined but not used label on !CONFIG_INTEL_IOMMU
*) Hopefully a couple of sparse warnings where we implicitly typecast
integer to __le32 and vice versa.
Signed-off-by: Thomas Hellstrom
Reviewed-by: Brian Paul
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |9 -
drivers/gpu/drm/vmwgfx/vmwgfx_gmr.c |7 +--
2 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 0b5c781..a278581 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -453,12 +453,13 @@ static void vmw_get_initial_size(struct vmw_private
*dev_priv)
*/
static int vmw_dma_select_mode(struct vmw_private *dev_priv)
{
- const struct dma_map_ops *dma_ops = get_dma_ops(dev_priv->dev->dev);
static const char *names[vmw_dma_map_max] = {
[vmw_dma_phys] = "Using physical TTM page addresses.",
[vmw_dma_alloc_coherent] = "Using coherent TTM pages.",
[vmw_dma_map_populate] = "Keeping DMA mappings.",
[vmw_dma_map_bind] = "Giving up DMA mappings early."};
+#ifdef CONFIG_X86
+ const struct dma_map_ops *dma_ops = get_dma_ops(dev_priv->dev->dev);
#ifdef CONFIG_INTEL_IOMMU
if (intel_iommu_enabled) {
@@ -482,7 +483,9 @@ static int vmw_dma_select_mode(struct vmw_private *dev_priv)
dev_priv->map_mode = vmw_dma_map_populate;
#endif
+#ifdef CONFIG_INTEL_IOMMU
out_fixup:
+#endif
if (dev_priv->map_mode == vmw_dma_map_populate &&
vmw_restrict_iommu)
dev_priv->map_mode = vmw_dma_map_bind;
@@ -498,6 +501,10 @@ out_fixup:
return -EINVAL;
#endif
+#else /* CONFIG_X86 */
+ dev_priv->map_mode = vmw_dma_map_populate;
+#endif /* CONFIG_X86 */
+
DRM_INFO("DMA map mode: %s\n", names[dev_priv->map_mode]);
return 0;
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_gmr.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_gmr.c
index 6d09523..6ef0b03 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_gmr.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_gmr.c
@@ -145,7 +145,9 @@ static void vmw_gmr_free_descriptors(struct device *dev,
dma_addr_t desc_dma,
}
page_virtual = kmap_atomic(page);
- desc_dma = page_virtual[desc_per_page].ppn << PAGE_SHIFT;
+ desc_dma = (dma_addr_t)
+ le32_to_cpu(page_virtual[desc_per_page].ppn) <<
+ PAGE_SHIFT;
kunmap_atomic(page_virtual);
__free_page(page);
@@ -217,7 +219,8 @@ static int vmw_gmr_build_descriptors(struct device *dev,
desc_dma = 0;
list_for_each_entry_reverse(page, desc_pages, lru) {
page_virtual = kmap_atomic(page);
- page_virtual[desc_per_page].ppn = desc_dma >> PAGE_SHIFT;
+ page_virtual[desc_per_page].ppn = cpu_to_le32
+ (desc_dma >> PAGE_SHIFT);
kunmap_atomic(page_virtual);
desc_dma = dma_map_page(dev, page, 0, PAGE_SIZE,
DMA_TO_DEVICE);
--
1.7.10.4
[Bug 64471] Radeon HD6570 lockup in Brütal Legend with HyperZ
https://bugs.freedesktop.org/show_bug.cgi?id=64471 --- Comment #12 from Andre Heider --- I tried this game again and the issue is still present. Tested with 3.12 and recent mesa (head: f0f202e6b764be803470e27cba9102f14361ae22). However, with a current apitrace it's now possible to trace and replay it on r600g to provoke the GPU reset. Using past apitraces makes the game work without traces/glitches. I'm using apitrace head 0227203a229e85f98a491c6b9480c0bc210f1dbb, I didn't test if a replay with older versions yields the hang. I've uploaded a trace here (~260MiB): http://static.hackmii.com/dhewg/brutalz.trace.xz Replaying that without R600_HYPERZ reliably reproduces GPU hangs on my BARTS card. Replaying it with R600_HYPERZ=0 makes the hangs go away, but you'll see glitches on the hero's face (effects like described above). Note: Trace is 1920x1200 fullscreen. Windowed mode or different resolutions didn't always lockup. I tried to trim the trace down, but apitrace choked on 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/20131112/c02d21b5/attachment.html>
[Bug 71488] RadeonSI :Regression: Massive Desktop corruption observed on starting the X server
https://bugs.freedesktop.org/show_bug.cgi?id=71488 --- Comment #5 from samit vats --- Upgraded to libdrm 2.4.47 and the issue is still reproduced. The issue is not observed with Option "ColorTiling2D" "off", however it reduces the driver performance i.e. for game Openarena the FPS is reduced by approx 30% with Color Tiling disabled. -- 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/20131112/a153c1b4/attachment.html>
[Bug 71212] [RadeonSI]: Unigine Heaven fails to launch with X error
https://bugs.freedesktop.org/show_bug.cgi?id=71212 --- Comment #5 from samit vats --- Running heaven with MESA_GL_VERSION_OVERRIDE=3.2 MESA_GLSL_VERSION_OVERRIDE=150 hard hangs the system after few minutes of launch -- 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/20131112/f4167ea8/attachment.html>
[PATCH] radeon: workaround pining failure on low ram gpu
From: Jerome Glisse
GPU with low amount of ram can fails at pining new framebuffer before
unpining old one. On such failure, retry with unping old one before
pining new one allowing to work around the issue. This is somewhat
ugly but only affect those old GPU we care about.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon_legacy_crtc.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
index 0c7b8c6..0b158f9 100644
--- a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
+++ b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
@@ -422,6 +422,7 @@ int radeon_crtc_do_set_base(struct drm_crtc *crtc,
/* Pin framebuffer & get tilling informations */
obj = radeon_fb->obj;
rbo = gem_to_radeon_bo(obj);
+retry:
r = radeon_bo_reserve(rbo, false);
if (unlikely(r != 0))
return r;
@@ -430,6 +431,33 @@ int radeon_crtc_do_set_base(struct drm_crtc *crtc,
&base);
if (unlikely(r != 0)) {
radeon_bo_unreserve(rbo);
+
+ /* On old GPU like RN50 with little vram pining can fails
because
+* current fb is taking all space needed. So instead of unpining
+* the old buffer after pining the new one, first unpin old one
+* and then retry pining new one.
+*
+* As only master can set mode only master can pin and it is
+* unlikely the master client will race with itself especialy
+* on those old gpu with single crtc.
+*
+* We don't shutdown the display controller because new buffer
+* will end up in same spot.
+*/
+ if (!atomic && fb && fb != crtc->fb) {
+ struct radeon_bo *old_rbo;
+ unsigned long nsize, osize;
+
+ old_rbo =
gem_to_radeon_bo(to_radeon_framebuffer(fb)->obj);
+ osize = radeon_bo_size(old_rbo);
+ nsize = radeon_bo_size(rbo);
+ if (nsize <= osize && !radeon_bo_reserve(old_rbo,
false)) {
+ radeon_bo_unpin(old_rbo);
+ radeon_bo_unreserve(old_rbo);
+ fb = NULL;
+ goto retry;
+ }
+ }
return -EINVAL;
}
radeon_bo_get_tiling_flags(rbo, &tiling_flags, NULL);
--
1.8.3.1
[Bug 71488] RadeonSI :Regression: Massive Desktop corruption observed on starting the X server
https://bugs.freedesktop.org/show_bug.cgi?id=71488 --- Comment #4 from Michel D?nzer --- If the new libdrm doesn't help, does Option "ColorTiling2D" "off" or Option "ColorTiling" "off" work around the 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/20131112/e3ddb2a3/attachment-0001.html>
[Bug 71134] AMD Radeon 7790 (BONAIRE Sea Islands) rendering, stability, performance issues
https://bugs.freedesktop.org/show_bug.cgi?id=71134 --- Comment #7 from Michel D?nzer --- (In reply to comment #6) > > pixel offset on diagonal (which appears to be in opengl apps too): > http://youtu.be/jTnI446eD-Q If you mean the diagonal tearing visible on the stairs while moving, there's currently no way to avoid that with glamor other than running in fullscreen with page flipping enabled. -- 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/20131112/c390cbc9/attachment.html>
[Bug 71516] RV350 Radeon 9550 - no Unity 3D hardware support in Ubuntu 13.10, extremely slow
https://bugs.freedesktop.org/show_bug.cgi?id=71516 --- Comment #1 from Michel D?nzer --- Please attach the output of LIBGL_DEBUG=verbose glxinfo 2>&1 >/dev/null -- 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/20131112/80b745cb/attachment.html>
[Bug 71516] New: RV350 Radeon 9550 - no Unity 3D hardware support in Ubuntu 13.10, extremely slow
https://bugs.freedesktop.org/show_bug.cgi?id=71516 Priority: medium Bug ID: 71516 Assignee: dri-devel at lists.freedesktop.org Summary: RV350 Radeon 9550 - no Unity 3D hardware support in Ubuntu 13.10, extremely slow Severity: major Classification: Unclassified OS: Linux (All) Reporter: sailing at together.net Hardware: x86 (IA32) Status: NEW Version: 9.2 Component: Drivers/Gallium/r300 Product: Mesa Created attachment 89062 --> https://bugs.freedesktop.org/attachment.cgi?id=89062&action=edit Xorg.0.log lspci -nn | grep VGA 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] RV350 [Radeon 9550] [1002:4153] /usr/lib/nux/unity_support_test -p OpenGL vendor string: VMware, Inc. OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.3, 128 bits) OpenGL version string: 2.1 Mesa 9.2.1 Not software rendered:no Not blacklisted: yes GLX fbconfig: yes GLX texture from pixmap: yes GL npot or rect textures: yes GL vertex program:yes GL fragment program: yes GL vertex buffer object: yes GL framebuffer object:yes GL version is 1.4+: yes Unity 3D supported: no >From Xorg.0.log (--) RADEON(0): Chipset: "ATI Radeon 9600 AS (AGP)" (ChipID = 0x4153) RV350 listed as fully supported by Ubuntu at https://help.ubuntu.com/community/RadeonDriver (August 2013) but is not found in Xorg.0.log I also tried using MESA 10.* but no change. What am I missing? Thank you -- 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/20131112/c5628c27/attachment.html>
[Bug 71134] AMD Radeon 7790 (BONAIRE Sea Islands) rendering, stability, performance issues
https://bugs.freedesktop.org/show_bug.cgi?id=71134 --- Comment #6 from Tom --- Update After updating packages to the latest versions (kernel to 3.12.0-next-2013) gpu lockups and dramatic slow downs seem to be resolved. I've uploaded 2 videos which describe existing problems. pixel offset on diagonal (which appears to be in opengl apps too): http://youtu.be/jTnI446eD-Q dpm issue: http://youtu.be/52ZlliTfqYI -- 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/20131112/5b67269b/attachment.html>
[PATCH 1/2] drm/radeon/audio: write audio/video latency info for DCE4/5
11.11.2013 17:55, Alex Deucher kirjoitti: > On Fri, Nov 8, 2013 at 6:24 AM, Anssi Hannula wrote: >> 18.10.2013 23:41, Alex Deucher kirjoitti: >>> Needed by the hda driver to properly set up synchronization >>> on the audio side. >>> >>> Signed-off-by: Alex Deucher >>> --- >>> drivers/gpu/drm/radeon/evergreen_hdmi.c | 37 >>> >>> drivers/gpu/drm/radeon/evergreend.h | 38 >>> + >>> 2 files changed, 75 insertions(+) >>> >>> diff --git a/drivers/gpu/drm/radeon/evergreen_hdmi.c >>> b/drivers/gpu/drm/radeon/evergreen_hdmi.c >>> index 5fbe486..abdc893 100644 >>> --- a/drivers/gpu/drm/radeon/evergreen_hdmi.c >>> +++ b/drivers/gpu/drm/radeon/evergreen_hdmi.c >> [...] >>> + if (connector->latency_present[0]) >>> + tmp = VIDEO_LIPSYNC(connector->video_latency[0]) | >>> + AUDIO_LIPSYNC(connector->audio_latency[0]); >>> + else >>> + tmp = VIDEO_LIPSYNC(255) | AUDIO_LIPSYNC(255); >>> + } >>> + WREG32(AZ_F0_CODEC_PIN0_CONTROL_RESPONSE_LIPSYNC, tmp); >> [...] >>> +#define AZ_F0_CODEC_PIN0_CONTROL_RESPONSE_LIPSYNC 0x5fe8 >>> +# define VIDEO_LIPSYNC(x) (((x) & 0xff) << >>> 0) >>> +# define AUDIO_LIPSYNC(x) (((x) & 0xff) << >>> 8) >>> +/* VIDEO_LIPSYNC, AUDIO_LIPSYNC >>> + * 0 = invalid >>> + * x = legal delay value >>> + * 255 = sync not supported >>> + */ >> >> Hmm, AMD_HDA_verbs_v2.pdf says that: >> 0 = unknown latency >> >> HDMI spec 1.4 says that: >> 0 = not valid or unknown latency >> 1..251 = valid delay value >> 255= video not supported / audio not supported >> >> Are you sure you shouldn't use 0 instead for unknown (no latency_present)? > > I'm not sure. The comment in the code above is what the register spec > says which seems to match the HDMI spec. I can dig around a bit more > internally. OK, though don't waste too much time on that, ALSA has to handle 0 and 255 the same in any case (a patch has just been pushed to sound git to handle 255). :) -- Anssi Hannula
