[PATCH v2] drm/i915: bounds check execbuffer relocation count

[Chris Wilson]

On Mon, Mar 11, 2013 at 03:25:59PM -0700, Kees Cook wrote:
> On Mon, Mar 11, 2013 at 3:00 PM, Chris Wilson  
> wrote:
> > On Mon, Mar 11, 2013 at 02:23:29PM -0700, Kees Cook wrote:
> >> It is possible to wrap the counter used to allocate the buffer for
> >> relocation copies. This could lead to heap writing overflows.
> >
> > I'd keep the return value as EINVAL so that we can continue to
> > distinguish between the user passing garbage and hitting an oom. And
> > total_relocs is preferrable to total, which also leads us to think more
> > carefully about the error condition. I think the check should be against
> > INT_MAX / sizeof(struct reloc_entry) for consistency with our other
> > guard against overflows whilst allocating.
> 
> I've ended up with this:
> 
> int max_alloc = INT_MAX / sizeof(struct 
> drm_i915_gem_relocation_entry);
> ...
> /* First check for malicious input causing overflow */
> if (exec[i].relocation_count > max_alloc)
> return -EINVAL;
> if (exec[i].relocation_count > max_alloc - total_relocs)
> return -EINVAL;
> total_relocs += exec[i].relocation_count;
> 
> And looking at that, I wonder if we should just eliminate the first if 
> entirely?

Aye, seems reasonable. So perhaps,

/* First check for malicious input causing overflow in the worst case
 * where we need to allocate the entire relocation tree as a single
 * array.
 */
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

linux-next: build failure after merge of the final tree (drm-intel tree related)

[Kees Cook]

On Mon, Mar 11, 2013 at 9:22 PM, Stephen Rothwell  
wrote:
> Hi all,
>
> After merging the final tree, today's linux-next build (i386 defconfig)
> failed like this:
>
> drivers/built-in.o: In function `i915_min_freq_set':
> i915_debugfs.c:(.text+0xb1adc): undefined reference to `__udivdi3'
> drivers/built-in.o: In function `i915_max_freq_set':
> i915_debugfs.c:(.text+0xb1bac): undefined reference to `__udivdi3'
>
> Caused by commit 2389cc500686 ("drm/i915: use simple attribute in debugfs
> routines") from the drm-intel tree.
>
> I have reverted that commit for today.

Ah-ha, thanks. I've sent a follow-up patch to fix this.

-Kees

-- 
Kees Cook
Chrome OS Security

[PATCH] drm/i915: use do_div() as needed in debugfs code

[Kees Cook]

This replaces the open-coded divisions in the debugfs code by calls
to do_div().

Signed-off-by: Kees Cook 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_debugfs.c |   12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index d86c304..6f3cbf8 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1814,9 +1814,9 @@ i915_max_freq_set(void *data, u64 val)
/*
 * Turbo will still be enabled, but won't go above the set value.
 */
-   dev_priv->rps.max_delay = val / GT_FREQUENCY_MULTIPLIER;
-
-   gen6_set_rps(dev, val / GT_FREQUENCY_MULTIPLIER);
+   do_div(val, GT_FREQUENCY_MULTIPLIER);
+   dev_priv->rps.max_delay = val;
+   gen6_set_rps(dev, val);
mutex_unlock(_priv->rps.hw_lock);

return 0;
@@ -1865,9 +1865,9 @@ i915_min_freq_set(void *data, u64 val)
/*
 * Turbo will still be enabled, but won't go below the set value.
 */
-   dev_priv->rps.min_delay = val / GT_FREQUENCY_MULTIPLIER;
-
-   gen6_set_rps(dev, val / GT_FREQUENCY_MULTIPLIER);
+   do_div(val, GT_FREQUENCY_MULTIPLIER);
+   dev_priv->rps.min_delay = val;
+   gen6_set_rps(dev, val);
mutex_unlock(_priv->rps.hw_lock);

return 0;
-- 
1.7.9.5


-- 
Kees Cook
Chrome OS Security

[PATCH] drivers: gpu: drm: i915: Replaced calls to kmalloc & memcpy with kmemdup

[Alexandru Gheorghiu]

Replaced calls to kmalloc followed by memcpy with a single call to kmemdup.
Also removed a now redundant if statement.

Signed-off-by: Alexandru Gheorghiu 
---
 drivers/gpu/drm/i915/intel_dp.c |5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index f61cb79..3cf8aed 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2335,11 +2335,8 @@ intel_dp_get_edid(struct drm_connector *connector, 
struct i2c_adapter *adapter)
return NULL;

size = (intel_connector->edid->extensions + 1) * EDID_LENGTH;
-   edid = kmalloc(size, GFP_KERNEL);
-   if (!edid)
-   return NULL;
+   edid = kmemdup(intel_connector->edid, size, GFP_KERNEL);

-   memcpy(edid, intel_connector->edid, size);
return edid;
}

-- 
1.7.9.5

[PATCH V3] get_maintainer: use filename-only regex match for Tegra

[Marcin Ślusarz]

11 mar 2013 21:19, "Stephen Warren"  napisa?(a):
>
> From: Stephen Warren 
>
> Create a new N: entry type in MAINTAINERS which performs a regex match
> against filenames; either those extracted from patch +++ or --- lines,
> or those specified on the command-line using the -f option.
>
> This provides the same benefits as using a K: regex option to match a
> set of filenames (see commit eb90d08 "get_maintainer: allow keywords to
> match filenames"), but without the disadvantage that "random" file
> content, such as comments, will ever match the regex. Hence, revert most
> of that commit.
>
> Switch the Tegra entry from using K: to N:
>
> Reported-by: Marcin Slusarz 
> Suggested-by: Joe Perches 
> Signed-off-by: Stephen Warren 
> ---
> v2: Corrected typo in MAINTAINERS documentation
> v3: Squash 3 patches into one.
> ---
>  MAINTAINERS   |   14 --
>  scripts/get_maintainer.pl |2 +-
>  2 files changed, 9 insertions(+), 7 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 9561658..e68a07a 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -90,6 +90,9 @@ Descriptions of section entries:
>F:   drivers/net/*   all files in drivers/net, but not below
>F:   */net/* all files in "any top level directory"/net
>One pattern per line.  Multiple F: lines acceptable.
> +   N: Files and directories with regex patterns.
> +  N:   [^a-z]tegra all files whose patch contains the word
tegra

s/patch/path/ ?

> +  One pattern per line.  Multiple N: lines acceptable.
> X: Files and directories that are NOT maintained, same rules as F:
>Files exclusions are tested before file matches.
>Can be useful for excluding a specific subdirectory, for
instance:
> @@ -97,13 +100,12 @@ Descriptions of section entries:
>X:   net/ipv6/
>matches all files in and below net excluding net/ipv6/
> K: Keyword perl extended regex pattern to match content in a
> -  patch or file, or an affected filename.  For instance:
> +  patch or file.  For instance:
>K: of_get_profile
> - matches patch or file content, or filenames, that contain
> - "of_get_profile"
> + matches patches or files that contain "of_get_profile"
>K: \b(printk|pr_(info|err))\b
> - matches patch or file content, or filenames, that contain
one or
> - more of the words printk, pr_info or pr_err
> + matches patches or files that contain one or more of the
words
> + printk, pr_info or pr_err
>One regex pattern per line.  Multiple K: lines acceptable.
>
>  Note: For the hard of thinking, this list is meant to remain in
alphabetical
> @@ -7848,7 +7850,7 @@ L:linux-tegra at vger.kernel.org
>  Q: http://patchwork.ozlabs.org/project/linux-tegra/list/
>  T: git git://
git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git
>  S: Supported
> -K: (?i)[^a-z]tegra
> +N: [^a-z]tegra
>
>  TEHUTI ETHERNET DRIVER
>  M: Andy Gospodarek 
> diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
> index ce4cc83..5e4fb14 100755
> --- a/scripts/get_maintainer.pl
> +++ b/scripts/get_maintainer.pl
> @@ -611,7 +611,7 @@ sub get_maintainers {
> $hash{$tvi} = $value_pd;
> }
> }
> -   } elsif ($type eq 'K') {
> +   } elsif ($type eq 'N') {
> if ($file =~ m/$value/x) {
> $hash{$tvi} = 0;
> }
> --
> 1.7.10.4
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130311/552449a3/attachment-0001.html>

[PATCH] drivers: gpu: drm: i915: Replaced calls to kmalloc & memcpy with kmemdup

[Andru Gheorghiu]

You are right. I shall resend :)

Thanks!

On Mon, Mar 11, 2013 at 10:25 PM, Josh Triplett wrote:

> On Mon, Mar 11, 2013 at 09:30:40PM +0200, Alexandru Gheorghiu wrote:
> > Replaced calls to kmalloc followed by memcpy with a single call to
> kmemdup.
> > This patch was found using coccinelle.
> >
> > Signed-off-by: Alexandru Gheorghiu 
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c |3 +--
> >  1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> b/drivers/gpu/drm/i915/intel_dp.c
> > index f61cb79..a3fdd65 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -2335,11 +2335,10 @@ intel_dp_get_edid(struct drm_connector
> *connector, struct i2c_adapter *adapter)
> >   return NULL;
> >
> >   size = (intel_connector->edid->extensions + 1) *
> EDID_LENGTH;
> > - edid = kmalloc(size, GFP_KERNEL);
> > + edid = kmemdup(intel_connector->edid, size, GFP_KERNEL);
> >   if (!edid)
> >   return NULL;
> >
> > - memcpy(edid, intel_connector->edid, size);
> >   return edid;
> >   }
>
> With this change, the conditional no longer makes sense; this should
> just "return kmemdup(...);".
>
> That suggests an obvious further cleanup that coccinelle could easily
> handle:
>
> if (!foo)
> return NULL;
> return foo;
>
> should become just "return foo;".  And you might then want to check for
> variables used *only* to capture a return value and immediately
> returned, and eliminate them.
>
> - Josh Triplett
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130311/c7c8a1a0/attachment.html>

[PATCH] drivers: gpu: drm: gma500: Replaced calls kzalloc & memcpy with kmemdup

[Patrik Jakobsson]

On Mon, Mar 11, 2013 at 8:46 PM, Alexandru Gheorghiu
 wrote:
> Replaced calls kzalloc followed by memcpy with call to kmemdup.
> Patch found using coccinelle.
>
> Signed-off-by: Alexandru Gheorghiu 
> ---
>  drivers/gpu/drm/gma500/intel_bios.c |3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/gma500/intel_bios.c 
> b/drivers/gpu/drm/gma500/intel_bios.c
> index 403fffb..d349734 100644
> --- a/drivers/gpu/drm/gma500/intel_bios.c
> +++ b/drivers/gpu/drm/gma500/intel_bios.c
> @@ -218,12 +218,11 @@ static void parse_backlight_data(struct drm_psb_private 
> *dev_priv,
> bl_start = find_section(bdb, BDB_LVDS_BACKLIGHT);
> vbt_lvds_bl = (struct bdb_lvds_backlight *)(bl_start + 1) + p_type;
>
> -   lvds_bl = kzalloc(sizeof(*vbt_lvds_bl), GFP_KERNEL);
> +   lvds_bl = kmemdup(vbt_lvds_bl, sizeof(*vbt_lvds_bl), GFP_KERNEL);
> if (!lvds_bl) {
> dev_err(dev_priv->dev->dev, "out of memory for backlight 
> data\n");
> return;
> }
> -   memcpy(lvds_bl, vbt_lvds_bl, sizeof(*vbt_lvds_bl));
> dev_priv->lvds_bl = lvds_bl;
>  }
>
> --
> 1.7.9.5

Reviewed-by: Patrik Jakobsson 

[PATCH v2] drm/i915: bounds check execbuffer relocation count

[Chris Wilson]

On Mon, Mar 11, 2013 at 02:23:29PM -0700, Kees Cook wrote:
> It is possible to wrap the counter used to allocate the buffer for
> relocation copies. This could lead to heap writing overflows.

I'd keep the return value as EINVAL so that we can continue to
distinguish between the user passing garbage and hitting an oom. And
total_relocs is preferrable to total, which also leads us to think more
carefully about the error condition. I think the check should be against
INT_MAX / sizeof(struct reloc_entry) for consistency with our other
guard against overflows whilst allocating.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[Bug 60439] Suspend/resume broken for cayman with 90a51a329258e3c868f6

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

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

--- Comment #14 from Alexandre Demers  ---
(In reply to comment #13)
> Created attachment 76349 [details] [review]
> possible fix
> 
> This patch should fix the issue.

It does over here.

-- 
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/20130311/8549f06b/attachment.html>

[PATCH] drivers: gpu: drm: gma500: Replaced calls kzalloc & memcpy with kmemdup

[Alexandru Gheorghiu]

Replaced calls kzalloc followed by memcpy with call to kmemdup.
Patch found using coccinelle.

Signed-off-by: Alexandru Gheorghiu 
---
 drivers/gpu/drm/gma500/intel_bios.c |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/gma500/intel_bios.c 
b/drivers/gpu/drm/gma500/intel_bios.c
index 403fffb..d349734 100644
--- a/drivers/gpu/drm/gma500/intel_bios.c
+++ b/drivers/gpu/drm/gma500/intel_bios.c
@@ -218,12 +218,11 @@ static void parse_backlight_data(struct drm_psb_private 
*dev_priv,
bl_start = find_section(bdb, BDB_LVDS_BACKLIGHT);
vbt_lvds_bl = (struct bdb_lvds_backlight *)(bl_start + 1) + p_type;

-   lvds_bl = kzalloc(sizeof(*vbt_lvds_bl), GFP_KERNEL);
+   lvds_bl = kmemdup(vbt_lvds_bl, sizeof(*vbt_lvds_bl), GFP_KERNEL);
if (!lvds_bl) {
dev_err(dev_priv->dev->dev, "out of memory for backlight 
data\n");
return;
}
-   memcpy(lvds_bl, vbt_lvds_bl, sizeof(*vbt_lvds_bl));
dev_priv->lvds_bl = lvds_bl;
 }

-- 
1.7.9.5

[PATCH] drivers: gpu: drm: Replaced ERR_PTR & PTR_ERR with ERR_CAST

[Alexandru Gheorghiu]

Replaced ERR_PTR and PTR_ERR calls with ERR_CAST.
Patch found using coccinelle.

Signed-off-by: Alexandru Gheorghiu 
---
 drivers/gpu/drm/drm_prime.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 366910d..4c8adda 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -275,7 +275,7 @@ struct drm_gem_object *drm_gem_prime_import(struct 
drm_device *dev,

attach = dma_buf_attach(dma_buf, dev->dev);
if (IS_ERR(attach))
-   return ERR_PTR(PTR_ERR(attach));
+   return ERR_CAST(attach);

sgt = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL);
if (IS_ERR_OR_NULL(sgt)) {
-- 
1.7.9.5

[PATCH] drivers: gpu: drm: i915: Replaced calls to kmalloc & memcpy with kmemdup

[Alexandru Gheorghiu]

Replaced calls to kmalloc followed by memcpy with a single call to kmemdup.
This patch was found using coccinelle.

Signed-off-by: Alexandru Gheorghiu 
---
 drivers/gpu/drm/i915/intel_dp.c |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index f61cb79..a3fdd65 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2335,11 +2335,10 @@ intel_dp_get_edid(struct drm_connector *connector, 
struct i2c_adapter *adapter)
return NULL;

size = (intel_connector->edid->extensions + 1) * EDID_LENGTH;
-   edid = kmalloc(size, GFP_KERNEL);
+   edid = kmemdup(intel_connector->edid, size, GFP_KERNEL);
if (!edid)
return NULL;

-   memcpy(edid, intel_connector->edid, size);
return edid;
}

-- 
1.7.9.5

[PATCH] drivers: gpu: drm: exynos: Replaced kzalloc & memcpy with kmemdup

[Alexandru Gheorghiu]

Replaced calls to kzalloc followed by memcpy with call to kmemdup.
Patch found using coccinelle.

Signed-off-by: Alexandru Gheorghiu 
---
 drivers/gpu/drm/exynos/exynos_drm_vidi.c |6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c 
b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index 13ccbd4..9504b0c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -117,13 +117,12 @@ static struct edid *vidi_get_edid(struct device *dev,
}

edid_len = (1 + ctx->raw_edid->extensions) * EDID_LENGTH;
-   edid = kzalloc(edid_len, GFP_KERNEL);
+   edid = kmemdup(ctx->raw_edid, edid_len, GFP_KERNEL);
if (!edid) {
DRM_DEBUG_KMS("failed to allocate edid\n");
return ERR_PTR(-ENOMEM);
}

-   memcpy(edid, ctx->raw_edid, edid_len);
return edid;
 }

@@ -563,12 +562,11 @@ int vidi_connection_ioctl(struct drm_device *drm_dev, 
void *data,
return -EINVAL;
}
edid_len = (1 + raw_edid->extensions) * EDID_LENGTH;
-   ctx->raw_edid = kzalloc(edid_len, GFP_KERNEL);
+   ctx->raw_edid = kmemdup(raw_edid, edid_len, GFP_KERNEL);
if (!ctx->raw_edid) {
DRM_DEBUG_KMS("failed to allocate raw_edid.\n");
return -ENOMEM;
}
-   memcpy(ctx->raw_edid, raw_edid, edid_len);
} else {
/*
 * with connection = 0, free raw_edid
-- 
1.7.9.5

[PATCH] drm/i915: clarify reasoning for the access_ok call

[Chris Wilson]

On Mon, Mar 11, 2013 at 02:04:51PM -0700, Kees Cook wrote:
> Probably not. It just seemed like the existing comment was
> insufficient after the removal of the redundant VERIFY_READ check that
> happened recently.

That's certainly true, the remaining comment is a little cryptic.
Something more like:

/* We need to check that we can read the entire relocation array, but
 * as we may need to update the presumed_offsets upon execution, we
 * need to check now for full write access.
 */
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH] drm/i915: bounds check execbuffer relocations

[Chris Wilson]

On Mon, Mar 11, 2013 at 12:27:16PM -0700, Kees Cook wrote:
> It is possible to wrap the counter used to allocate the buffer for
> relocation copies. This could lead to heap writing overflows.

Seems a sensible check, just in the wrong location. You need to do the
checking upfront in validate_exec_list() so that the error condition is
always hit and that the limits are applied consistently to all
execbuffers.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH] drm/i915: clarify reasoning for the access_ok call

[Chris Wilson]

On Mon, Mar 11, 2013 at 12:26:30PM -0700, Kees Cook wrote:
> This clarifies the comment above the access_ok check so a missing
> VERIFY_READ doesn't alarm anyone.

Do we really need to copy the interface documentation?

/**
 * access_ok: - Checks if a user space pointer is valid
 * @type: Type of access: %VERIFY_READ or %VERIFY_WRITE.  Note that
 *%VERIFY_WRITE is a superset of %VERIFY_READ - if it is safe
 *to write to a block, it is always safe to read from it.
 * @addr: User space pointer to start of block to check
 * @size: Size of block to check
 */
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[Bug 57919] Visual glitches in unity with Radeon HD 7600M

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

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

--- Comment #5 from Thilo Cestonaro  ---
Created attachment 76350
  --> https://bugs.freedesktop.org/attachment.cgi?id=76350=edit
LiveCD GlxInfo 03/11/13

another LIBGL_DEBUG=verbose glxinfo output. This time generated by binaries
from the livecd of 03/11/13 of ubuntu raring ringtail.

-- 
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/20130311/2882f9ab/attachment.html>

[Bug 57919] Visual glitches in unity with Radeon HD 7600M

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

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

--- Comment #4 from Thilo Cestonaro  ---
Tried with cdimage:
http://cdimages.ubuntu.com/daily-live/20130311/raring-desktop-amd64.iso

Still very ugly glitches!

Please, if I can provide any more details or something, tell me!

I added a glxinfo output again of the version of the used libgl stuff.
Anyway, as it was the livecd boot, I can reproduce it very easily.

Greetings
Thilo

-- 
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/20130311/3ab49b4b/attachment.html>

[Bug 60439] Suspend/resume broken for cayman with 90a51a329258e3c868f6

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

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

--- Comment #13 from Alex Deucher  ---
Created attachment 76349
  --> https://bugs.freedesktop.org/attachment.cgi?id=76349=edit
possible fix

This patch should fix the issue.

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

[PATCH] drm/radeon: fix backend map setup on 1 RB trinity boards

[alexdeuc...@gmail.com]

From: Alex Deucher 

Need to adjust the backend map depending on which RB is
enabled.  This is the trinity equivalent of:
f7eb97300832f4fe5fe916c5d84cd2e25169330e

Signed-off-by: Alex Deucher 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/radeon/ni.c |   21 -
 1 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index 367b7a1..b3521c4e 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -625,11 +625,22 @@ static void cayman_gpu_init(struct radeon_device *rdev)
WREG32(DMA_TILING_CONFIG + DMA0_REGISTER_OFFSET, gb_addr_config);
WREG32(DMA_TILING_CONFIG + DMA1_REGISTER_OFFSET, gb_addr_config);

-   tmp = gb_addr_config & NUM_PIPES_MASK;
-   tmp = r6xx_remap_render_backend(rdev, tmp,
-   rdev->config.cayman.max_backends_per_se 
*
-   rdev->config.cayman.max_shader_engines,
-   CAYMAN_MAX_BACKENDS, disabled_rb_mask);
+   if ((rdev->config.cayman.max_backends_per_se == 1) &&
+   (rdev->flags & RADEON_IS_IGP)) {
+   if ((disabled_rb_mask & 3) == 1) {
+   /* RB0 disabled, RB1 enabled */
+   tmp = 0x;
+   } else {
+   /* RB1 disabled, RB0 enabled */
+   tmp = 0x;
+   }
+   } else {
+   tmp = gb_addr_config & NUM_PIPES_MASK;
+   tmp = r6xx_remap_render_backend(rdev, tmp,
+   
rdev->config.cayman.max_backends_per_se *
+   
rdev->config.cayman.max_shader_engines,
+   CAYMAN_MAX_BACKENDS, 
disabled_rb_mask);
+   }
WREG32(GB_BACKEND_MAP, tmp);

cgts_tcc_disable = 0x;
-- 
1.7.7.5

[PATCH 01/14] x86, ACPI, mm: Kill max_low_pfn_mapped

[H. Peter Anvin]

The problem is that the code will be broken, and so it makes no sense.  The #if 
0 is really confusing.

Daniel Vetter  wrote:

>On Thu, Mar 07, 2013 at 10:09:26PM -0800, H. Peter Anvin wrote:
>> On 03/07/2013 09:28 PM, Tejun Heo wrote:
>> > On Thu, Mar 7, 2013 at 9:27 PM, Yinghai Lu 
>wrote:
>> >> They are not using memblock_find_in_range(), so 1ULL<< will not
>help.
>> >>
>> >> Really hope i915 drm guys could clean that hacks.
>> > 
>> > The code isn't being used.  Just leave it alone.  Maybe add a
>comment.
>> >  The change is just making things more confusing.
>> > 
>> 
>> Indeed, but...
>> 
>> Daniel: can you guys clean this up or can we just remove the #if 0
>clause?
>
>I guess we could just put this into a comment explaining where stolen
>memory for the gfx devices is at on gen2. But tbh I don't mind if we
>just
>keep the #if 0 code around. For all newer platforms we can get at that
>offset through mch bar registers, so I don't really care.
>-Daniel

-- 
Sent from my mobile phone. Please excuse brevity and lack of formatting.

[Bug 62170] [bisected] R600 LLVM build broken

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

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

maxijac at free.fr changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from maxijac at free.fr ---
resolved in master

-- 
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/20130311/ea26ec50/attachment.html>

[PATCH v3] drm/i915: bounds check execbuffer relocation count

[Kees Cook]

It is possible to wrap the counter used to allocate the buffer for
relocation copies. This could lead to heap writing overflows.

CVE-2013-0913

v3: collapse test, improve comment
v2: move check into validate_exec_list

Signed-off-by: Kees Cook 
Reported-by: Pinkie Pie
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |   11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index b3a40ee..094ba41 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -732,6 +732,8 @@ validate_exec_list(struct drm_i915_gem_exec_object2 *exec,
   int count)
 {
int i;
+   int relocs_total = 0;
+   int relocs_max = INT_MAX / sizeof(struct drm_i915_gem_relocation_entry);

for (i = 0; i < count; i++) {
char __user *ptr = (char __user *)(uintptr_t)exec[i].relocs_ptr;
@@ -740,10 +742,13 @@ validate_exec_list(struct drm_i915_gem_exec_object2 *exec,
if (exec[i].flags & __EXEC_OBJECT_UNKNOWN_FLAGS)
return -EINVAL;

-   /* First check for malicious input causing overflow */
-   if (exec[i].relocation_count >
-   INT_MAX / sizeof(struct drm_i915_gem_relocation_entry))
+   /* First check for malicious input causing overflow in
+* the worst case where we need to allocate the entire
+* relocation tree as a single array.
+*/
+   if (exec[i].relocation_count > relocs_max - relocs_total)
return -EINVAL;
+   relocs_total += exec[i].relocation_count;

length = exec[i].relocation_count *
sizeof(struct drm_i915_gem_relocation_entry);
-- 
1.7.9.5


-- 
Kees Cook
Chrome OS Security

[PATCH] drm/i915: use simple attribute in debugfs routines

[Kees Cook]

On Mon, Mar 11, 2013 at 4:03 PM, Daniel Vetter  wrote:
> On Sun, Mar 10, 2013 at 02:10:06PM -0700, Kees Cook wrote:
>> This replaces the manual read/write routines in debugfs with the common
>> simple attribute helpers. Doing this gets rid of repeated copy/pasting
>> of copy_from_user and value formatting code.
>>
>> Signed-off-by: Kees Cook 
>> Cc: Daniel Vetter 
>
> Queued for -next, thanks for the patch. When sending drm/i915 patches,
> please also cc intel-gfx at lists.freedesktop.org (it's open for
> non-subscribers non without nagging "you're mail is in the moderation
> queue" replies).

Ah-ha, sure.

Should MAINTAINERS be updated to reflect this? It got skipped as a
destination due to the "subscribers-only" suffix.

-Kees

-- 
Kees Cook
Chrome OS Security

[PATCH 2/2] drm/radeon: tear down the IB pool on suspend

[alexdeuc...@gmail.com]

From: Alex Deucher 

Otherwise we may end up with stale MC addresses
after resume.

Signed-off-by: Alex Deucher 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/radeon/evergreen.c |1 +
 drivers/gpu/drm/radeon/ni.c|1 +
 drivers/gpu/drm/radeon/r100.c  |1 +
 drivers/gpu/drm/radeon/r300.c  |1 +
 drivers/gpu/drm/radeon/r420.c  |1 +
 drivers/gpu/drm/radeon/r600.c  |1 +
 drivers/gpu/drm/radeon/rs400.c |1 +
 drivers/gpu/drm/radeon/rs600.c |1 +
 drivers/gpu/drm/radeon/rs690.c |1 +
 drivers/gpu/drm/radeon/rv515.c |1 +
 drivers/gpu/drm/radeon/rv770.c |1 +
 drivers/gpu/drm/radeon/si.c|1 +
 12 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index 305a657..f0e64a4 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -3720,6 +3720,7 @@ int evergreen_suspend(struct radeon_device *rdev)
r600_dma_stop(rdev);
evergreen_irq_suspend(rdev);
radeon_wb_disable(rdev);
+   radeon_ib_pool_fini(rdev);
evergreen_pcie_gart_disable(rdev);

return 0;
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index e6f3989..367b7a1 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -1785,6 +1785,7 @@ int cayman_suspend(struct radeon_device *rdev)
cayman_dma_stop(rdev);
evergreen_irq_suspend(rdev);
radeon_wb_disable(rdev);
+   radeon_ib_pool_fini(rdev);
cayman_pcie_gart_disable(rdev);
return 0;
 }
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 9db5853..691dc93 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -3892,6 +3892,7 @@ int r100_suspend(struct radeon_device *rdev)
 {
r100_cp_disable(rdev);
radeon_wb_disable(rdev);
+   radeon_ib_pool_fini(rdev);
r100_irq_disable(rdev);
if (rdev->flags & RADEON_IS_PCI)
r100_pci_gart_disable(rdev);
diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
index c60350e..28ff068 100644
--- a/drivers/gpu/drm/radeon/r300.c
+++ b/drivers/gpu/drm/radeon/r300.c
@@ -1436,6 +1436,7 @@ int r300_suspend(struct radeon_device *rdev)
 {
r100_cp_disable(rdev);
radeon_wb_disable(rdev);
+   radeon_ib_pool_fini(rdev);
r100_irq_disable(rdev);
if (rdev->flags & RADEON_IS_PCIE)
rv370_pcie_gart_disable(rdev);
diff --git a/drivers/gpu/drm/radeon/r420.c b/drivers/gpu/drm/radeon/r420.c
index 6fce2eb..6edecc8 100644
--- a/drivers/gpu/drm/radeon/r420.c
+++ b/drivers/gpu/drm/radeon/r420.c
@@ -325,6 +325,7 @@ int r420_suspend(struct radeon_device *rdev)
r420_cp_errata_fini(rdev);
r100_cp_disable(rdev);
radeon_wb_disable(rdev);
+   radeon_ib_pool_fini(rdev);
r100_irq_disable(rdev);
if (rdev->flags & RADEON_IS_PCIE)
rv370_pcie_gart_disable(rdev);
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 0740db3..6166c7e 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -3031,6 +3031,7 @@ int r600_suspend(struct radeon_device *rdev)
r600_dma_stop(rdev);
r600_irq_suspend(rdev);
radeon_wb_disable(rdev);
+   radeon_ib_pool_fini(rdev);
r600_pcie_gart_disable(rdev);

return 0;
diff --git a/drivers/gpu/drm/radeon/rs400.c b/drivers/gpu/drm/radeon/rs400.c
index 73051ce..5eaf41f 100644
--- a/drivers/gpu/drm/radeon/rs400.c
+++ b/drivers/gpu/drm/radeon/rs400.c
@@ -470,6 +470,7 @@ int rs400_suspend(struct radeon_device *rdev)
 {
r100_cp_disable(rdev);
radeon_wb_disable(rdev);
+   radeon_ib_pool_fini(rdev);
r100_irq_disable(rdev);
rs400_gart_disable(rdev);
return 0;
diff --git a/drivers/gpu/drm/radeon/rs600.c b/drivers/gpu/drm/radeon/rs600.c
index 5a0fc74..8f70d78 100644
--- a/drivers/gpu/drm/radeon/rs600.c
+++ b/drivers/gpu/drm/radeon/rs600.c
@@ -945,6 +945,7 @@ int rs600_suspend(struct radeon_device *rdev)
r600_audio_fini(rdev);
r100_cp_disable(rdev);
radeon_wb_disable(rdev);
+   radeon_ib_pool_fini(rdev);
rs600_irq_disable(rdev);
rs600_gart_disable(rdev);
return 0;
diff --git a/drivers/gpu/drm/radeon/rs690.c b/drivers/gpu/drm/radeon/rs690.c
index 5706d2a..a9e7890 100644
--- a/drivers/gpu/drm/radeon/rs690.c
+++ b/drivers/gpu/drm/radeon/rs690.c
@@ -686,6 +686,7 @@ int rs690_suspend(struct radeon_device *rdev)
r600_audio_fini(rdev);
r100_cp_disable(rdev);
radeon_wb_disable(rdev);
+   radeon_ib_pool_fini(rdev);
rs600_irq_disable(rdev);
rs400_gart_disable(rdev);
return 0;
diff --git a/drivers/gpu/drm/radeon/rv515.c b/drivers/gpu/drm/radeon/rv515.c
index 435ed35..73ce8a3 100644
--- 

[PATCH 1/2] drm/radeon: fix S/R on VM systems (cayman/TN/SI)

[alexdeuc...@gmail.com]

From: Alex Deucher 

We weren't properly tearing down the VM sub-alloctor
on suspend leading to bogus VM PTs on resume.

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

Tested-by: Dmitry Cherkasov 
Signed-off-by: Alex Deucher 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/radeon/ni.c |1 +
 drivers/gpu/drm/radeon/si.c |1 +
 2 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index 3d81ca7..e6f3989 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -1780,6 +1780,7 @@ int cayman_resume(struct radeon_device *rdev)
 int cayman_suspend(struct radeon_device *rdev)
 {
r600_audio_fini(rdev);
+   radeon_vm_manager_fini(rdev);
cayman_cp_enable(rdev, false);
cayman_dma_stop(rdev);
evergreen_irq_suspend(rdev);
diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
index 9128120..bafbe32 100644
--- a/drivers/gpu/drm/radeon/si.c
+++ b/drivers/gpu/drm/radeon/si.c
@@ -4469,6 +4469,7 @@ int si_resume(struct radeon_device *rdev)

 int si_suspend(struct radeon_device *rdev)
 {
+   radeon_vm_manager_fini(rdev);
si_cp_enable(rdev, false);
cayman_dma_stop(rdev);
si_irq_suspend(rdev);
-- 
1.7.7.5

[PATCH 0/2] Properly suspend/resume sub-allocator

[alexdeuc...@gmail.com]

From: Alex Deucher 

This patch set is a bit of a heavy hammer, but I'm
not sure it's worth the effort to create separate
suspend functions for all sub-allocator
users that basically just calls radeon_sa_bo_manager_suspend()
and fix up all the sub allocator init functions to
call radeon_sa_bo_manager_start() since all we are really
avoiding is the allocation of sub-allocator bo.  Additionally
in the VM case, we have to tear down all the VMs on suspend
since the physical addresses of various buffers may have changed
on resume.

The first patch fixes suspend and resume on cards with VM in use.

The second patches doesn't fix any bugs that I know of, but
the current code seems wrong to me unless I'm missing something.

Alex Deucher (2):
  drm/radeon: fix S/R on VM systems (cayman/TN/SI)
  drm/radeon: tear down the IB pool on suspend

 drivers/gpu/drm/radeon/evergreen.c |1 +
 drivers/gpu/drm/radeon/ni.c|2 ++
 drivers/gpu/drm/radeon/r100.c  |1 +
 drivers/gpu/drm/radeon/r300.c  |1 +
 drivers/gpu/drm/radeon/r420.c  |1 +
 drivers/gpu/drm/radeon/r600.c  |1 +
 drivers/gpu/drm/radeon/rs400.c |1 +
 drivers/gpu/drm/radeon/rs600.c |1 +
 drivers/gpu/drm/radeon/rs690.c |1 +
 drivers/gpu/drm/radeon/rv515.c |1 +
 drivers/gpu/drm/radeon/rv770.c |1 +
 drivers/gpu/drm/radeon/si.c|2 ++
 12 files changed, 14 insertions(+), 0 deletions(-)

-- 
1.7.7.5

[PATCH REPOST] drm: tegra: don't depend on OF

[Stephen Warren]

From: Stephen Warren 

ARCH_TEGRA always enabled OF, so there's no need for any driver to
depend on it.

Signed-off-by: Stephen Warren 
---
 drivers/gpu/drm/tegra/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tegra/Kconfig b/drivers/gpu/drm/tegra/Kconfig
index c92955d..965c48c 100644
--- a/drivers/gpu/drm/tegra/Kconfig
+++ b/drivers/gpu/drm/tegra/Kconfig
@@ -1,6 +1,6 @@
 config DRM_TEGRA
tristate "NVIDIA Tegra DRM"
-   depends on DRM && OF && ARCH_TEGRA
+   depends on DRM && ARCH_TEGRA
select DRM_KMS_HELPER
select DRM_GEM_CMA_HELPER
select DRM_KMS_CMA_HELPER
-- 
1.7.10.4

[PATCH V3] get_maintainer: use filename-only regex match for Tegra

[Stephen Warren]

On 03/11/2013 03:36 PM, Marcin ?lusarz wrote:
> 
> 11 mar 2013 21:19, "Stephen Warren"  > napisa?(a):
>> Create a new N: entry type in MAINTAINERS which performs a regex match
>> against filenames; either those extracted from patch +++ or --- lines,
>> or those specified on the command-line using the -f option.

>> diff --git a/MAINTAINERS b/MAINTAINERS

>> +   N: Files and directories with regex patterns.
>> +  N:   [^a-z]tegra all files whose patch contains the word tegra
> 
> s/patch/path/ ?

It looks like Andrew has fixed this up himself. Thanks very much!

[Bug 58372] [KMS][Cayman] Garbled screen and gpu crash with 6950 with drm-next

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

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

Serkan Hosca  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #13 from Serkan Hosca  ---
This is fixed with 3.8 release and mesa git master

-- 
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/20130311/b1ade6c8/attachment.html>

[PATCH 1/4] drm/tilcdc: Fix an incorrect condition

[Sachin Kamat]

Hi Rob,

On 2 March 2013 20:40, Rob Clark  wrote:
> On Sat, Mar 2, 2013 at 5:23 AM, Sachin Kamat  
> wrote:
>> Instead of checking if num_encoders is zero, it is being assigned 0.
>> Convert the assignment to a check.
>>
>> Signed-off-by: Sachin Kamat 
>
> Signed-off-by: Rob Clark 

Just curious. Which tree would these patches be applied to (I mean
your tree or Dave's)?


-- 
With warm regards,
Sachin

[PATCH v2] drm/i915: bounds check execbuffer relocation count

[Kees Cook]

On Mon, Mar 11, 2013 at 3:00 PM, Chris Wilson  
wrote:
> On Mon, Mar 11, 2013 at 02:23:29PM -0700, Kees Cook wrote:
>> It is possible to wrap the counter used to allocate the buffer for
>> relocation copies. This could lead to heap writing overflows.
>
> I'd keep the return value as EINVAL so that we can continue to
> distinguish between the user passing garbage and hitting an oom. And
> total_relocs is preferrable to total, which also leads us to think more
> carefully about the error condition. I think the check should be against
> INT_MAX / sizeof(struct reloc_entry) for consistency with our other
> guard against overflows whilst allocating.

I've ended up with this:

int max_alloc = INT_MAX / sizeof(struct drm_i915_gem_relocation_entry);
...
/* First check for malicious input causing overflow */
if (exec[i].relocation_count > max_alloc)
return -EINVAL;
if (exec[i].relocation_count > max_alloc - total_relocs)
return -EINVAL;
total_relocs += exec[i].relocation_count;

And looking at that, I wonder if we should just eliminate the first if entirely?

-Kees

--
Kees Cook
Chrome OS Security

nouveau lockdep splat

[Arend van Spriel]

On 03/07/13 12:20, Arend van Spriel wrote:
> On 03/04/13 22:16, Borislav Petkov wrote:
>> New -rc1, so let the stabilization games begin.
>>
>> I see the following on rc1, let me know if you need more info.
>>
>>
>> [ 0.633617] =
>> [ 0.633618] [ INFO: possible recursive locking detected ]
>> [ 0.633618] 3.9.0-rc1 #2 Not tainted
>> [ 0.633619] -
>> [ 0.633619] swapper/0/1 is trying to acquire lock:
>> [ 0.633623] (>lock){+.+...}, at: []
>> evo_wait+0x43/0xf0
>> [ 0.633624]
>> [ 0.633624] but task is already holding lock:
>> [ 0.633626] (>lock){+.+...}, at: []
>> evo_wait+0x43/0xf0
>> [ 0.633626]
>> [ 0.633626] other info that might help us debug this:
>> [ 0.633626] Possible unsafe locking scenario:
>> [ 0.633626]
>> [ 0.633626] CPU0
>> [ 0.633627] 
>> [ 0.633627] lock(>lock);
>> [ 0.633628] lock(>lock);
>
> I am getting the same on my Dell Latitude e6410 and as a bonus I get
> abundant amount of nouveau error messages. These are not all as my
> system hangs after this.
>
> Ubuntu 12.04.2 LTS (GNU/Linux
> 3.9.0-rc1-wl-testing-lockdep-2-gc181dcd i686)
>
> 01:00.0 VGA compatible controller: NVIDIA Corporation GT218 [NVS 3100M]
> (rev a2)
>
> Gr. AvS
>
> c$ dmesg
> [ 753.201712] nouveau E[ PGRAPH][:01:00.0] ch -1 [0x001fb34000
> unknown] subc 5 class 0x mthd 0x0f04 data 0x0480
> [ 753.215281] nouveau E[ PGRAPH][:01:00.0] ILLEGAL_MTHD ILLEGAL_CLASS
> [ 753.224605] nouveau E[ PGRAPH][:01:00.0] ch -1 [0x001fb34000
> unknown] subc 5 class 0x mthd 0x0f04 data 0x00010360
> [ 753.238198] nouveau E[ PGRAPH][:01:00.0] ILLEGAL_MTHD ILLEGAL_CLASS

The stuff seem to start after logging in from lightdm. It fails to start 
the windows manager and after a while I am kick back to lightdm.

I was able to capture the first messages this time. Hope it helps.

Mar 11 09:37:47 arend-lp-dev kernel: [  143.520051] nouveau E[ 
PFIFO][:0100.0] CACHE_ERROR - ch 1 [DRM] subc 0 mthd 0x0060 data 
0x8002
Mar 11 09:37:47 arend-lp-dev kernel: [  143.529648] nouveau E[ 
PFB][:0100.0] trapped write at 0x0020014104 on channel 0x0001fca0 
[unknown] PFIFO/PFIFOREAD/SEMAPHORE reason: NULL_DMAOBJ
Mar 11 09:38:00 arend-lp-dev kernel: [  156.700076] nouveau 
E[Xorg[1360]] faile to idle channel 0x [Xorg[1360]]
Mar 11 09:38:00 arend-lp-dev kernel: [  156.708020] nouveau E[ 
PFB][:0100.0] trapped read at 0x002001a040 on channel 0x0001fb34 
[unknown] SEMAPHORE_BGPFIFO_READ/00 reason: PAGE_NOT_PRESENT
Mar 11 09:38:03 arend-lp-dev kernel: [  159.724632] nouveau 
E[compiz[2102]] faied to idle channel 0x [compiz[2102]]
Mar 11 09:38:03 arend-lp-dev kernel: [  159.732519] nouveau E[ 
PFB][:0100.0] trapped read at 0x0020014110 on channel 0x0001f96c 
[unknown] SEMAPHORE_BGPFIFO_READ/00 reason: PAGE_NOT_PRESENT
Mar 11 09:38:03 arend-lp-dev kernel: [  159.746819] nouveau E[ 
PGRAPH][:0100.0] TRAP_DISPATCH (unknown 0x0004)
Mar 11 09:38:03 arend-lp-dev kernel: [  159.754213] nouveau E[ 
PDISP][:0100.0] chid 2 mthd 0x0080 data 0x 0x000b5080
Mar 11 09:38:03 arend-lp-dev kernel: [  159.762560] nouveau E[ 
PFB][:0100.0] trapped read at 0x0020015210 on channel 0x0001f96c 
[unknown] SEMAPHORE_BGPFIFO_READ/00 reason: PAGE_NOT_PRESENT
Mar 11 09:38:03 arend-lp-dev kernel: [  159.776840] nouveau E[ 
PGRAPH][:0100.0]  ILLEGAL_MTHD ILLEGAL_CLASS
Mar 11 09:38:03 arend-lp-dev kernel: [  159.783664] nouveau E[ 
PGRAPH][:0100.0] ch -1 [0x001f96c000 unknown] subc 5 class 0x 
mthd 0x1640 data 0x3f8
Mar 11 09:38:03 arend-lp-dev kernel: [  159.794764] nouveau E[ 
PGRAPH][:0100.0]  ILLEGAL_MTHD ILLEGAL_CLASS
Mar 11 09:38:03 arend-lp-dev kernel: [  159.801584] nouveau E[ 
PGRAPH][:0100.0] ch -1 [0x001f96c000 unknown] subc 5 class 0x 
mthd 0x1640 data 0x426c000
Mar 11 09:38:03 arend-lp-dev kernel: [  159.812683] nouveau E[ 
PGRAPH][:0100.0]  ILLEGAL_MTHD ILLEGAL_CLASS

> [ 753.247167] nouveau E[ PGRAPH][:01:00.0] ch -1 [0x001fb34000
> unknown] subc 5 class 0x mthd 0x0f04 data 0x0300
> [ 753.260757] nouveau E[ PGRAPH][:01:00.0] ILLEGAL_MTHD ILLEGAL_CLASS
> [ 753.269919] nouveau E[ PGRAPH][:01:00.0] ch -1 [0x001fb34000
> unknown] subc 5 class 0x mthd 0x0f04 data 0x
> [ 753.283456] nouveau E[ PGRAPH][:01:00.0] ILLEGAL_MTHD ILLEGAL_CLASS
> [ 753.292705] nouveau E[ PGRAPH][:01:00.0] ch -1 [0x001fb34000
> unknown] subc 5 class 0x mthd 0x155c data 0x
> [ 753.306231] nouveau E[ PGRAPH][:01:00.0] ILLEGAL_MTHD ILLEGAL_CLASS
> [ 753.315505] nouveau E[ PGRAPH][:01:00.0] ch -1 [0x001fb34000
> unknown] subc 5 class 0x mthd 0x1560 data 0x20034000
> [ 753.329049] nouveau E[ PGRAPH][:01:00.0] ILLEGAL_MTHD ILLEGAL_CLASS
> [ 753.338221] nouveau E[ PGRAPH][:01:00.0] ch -1 [0x001fb34000
> unknown] subc 5 class 0x mthd 0x1564 data 0x
> [ 753.351752] nouveau E[ PGRAPH][:01:00.0] ILLEGAL_MTHD ILLEGAL_CLASS
> [ 

[Bug 60439] Suspend/resume broken for cayman with 90a51a329258e3c868f6

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

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

--- Comment #12 from Alexandre Demers  ---
(In reply to comment #11)
> Hi.
> 
> I can't reproduce this bug on cayman with 3.8-rc3 (using pm-suspend).
> Resuming works.
> 
> What software do you use? 
> I've used xmonad launched via legacy startx while testing that.
> 
> Can you fire up a simple twm session without compiz, etc stuff and see how
> it goes?
> Is it possible to get dmesg output (via serial cable or smth)?

See bug 56139, comments 51 and 52. Suspending/resuming from console or XFCE
don't trigger the bug. However, doing the same under KDE or Gnome-Shell does
exhibit 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/20130311/f39861c1/attachment.html>

[Bug 60439] Suspend/resume broken for cayman with 90a51a329258e3c868f6

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

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

--- Comment #11 from Dmitry Cherkassov  ---
Hi.

I can't reproduce this bug on cayman with 3.8-rc3 (using pm-suspend).
Resuming works.

What software do you use? 
I've used xmonad launched via legacy startx while testing that.

Can you fire up a simple twm session without compiz, etc stuff and see how it
goes?
Is it possible to get dmesg output (via serial cable or smth)?

-- 
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/20130311/9b6c5335/attachment.html>

[Bug 62170] [bisected] R600 LLVM build broken

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

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

--- Comment #1 from maxijac at free.fr ---
Oh, I'm using llvm from SVN at revision 176687 (fairly recent)

-- 
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/20130311/f1b3d572/attachment.html>

[Bug 60553] [trine2] wrong colors when executed fullscreen

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

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

--- Comment #3 from letharion at gmail.com ---
I can confirm I have the same issue. Works in windowed, colors wrong in
fullscreen, and some objects fail to render completely during gameplay.

Radeon HD 6550D
Mesa 9.1
xf86-video-ati 7.1.0

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

[Bug 62170] New: [bisected] R600 LLVM build broken

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

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

  Priority: medium
Bug ID: 62170
  Assignee: dri-devel at lists.freedesktop.org
   Summary: [bisected] R600 LLVM build broken
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: maxijac at free.fr
  Hardware: Other
Status: NEW
   Version: git
 Component: Drivers/Gallium/r600
   Product: Mesa

Hi,

Here's the error :
r600_shader.c: In function 'r600_shader_from_tgsi':
r600_shader.c:1256:18: error: invalid type argument of '->' (have 'struct
r600_shader_ctx')

4bf0ebdd4fc8dbcab9333ff8805af35a91e6848b is the first bad commit
commit 4bf0ebdd4fc8dbcab9333ff8805af35a91e6848b
Author: Marek Ol??k 
Date:   Fri Mar 1 16:31:49 2013 +0100

r600g: use a single env var R600_DEBUG, disable bytecode dumping

Only the disassembler is used to dump shaders. Here's a few examples
how to use R600_DEBUG.

Log compute info:
  R600_DEBUG=compute

Dump all shaders:
  R600_DEBUG=fs,vs,gs,ps,cs

Dump pixel shaders only:
  R600_DEBUG=ps

Disable Hyper-Z:
  R600_DEBUG=nohyperz

Disable the LLVM backend:
  R600_DEBUG=nollvm

Or use any combination of the above, or print all options:
  R600_DEBUG=help

Reviewed-by: Tom Stellard 

:04 04 faa01df772d30f39d03f80e43b1c588acb8b7060
8e6b4555de797c1736a872780b66ca53d80a736c M  src

-- 
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/20130311/22be693b/attachment.html>

[PATCH v2] drm/i915: clarify reasoning for the access_ok call

[Kees Cook]

This clarifies the comment above the access_ok check so a missing
VERIFY_READ doesn't alarm anyone.

Signed-off-by: Kees Cook 
Cc: Daniel Vetter 
---
v2:
 - rewrote comment, thanks to Chris Wilson
---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index bf7ceca..89c4039 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -751,7 +751,11 @@ validate_exec_list(struct drm_i915_gem_exec_object2 *exec,

length = exec[i].relocation_count *
sizeof(struct drm_i915_gem_relocation_entry);
-   /* we may also need to update the presumed offsets */
+   /*
+* We must check that the entire relocation array is safe
+* to read, but since we may need to update the presumed
+* offsets during execution, check for full write access.
+*/
if (!access_ok(VERIFY_WRITE, ptr, length))
return -EFAULT;

-- 
1.7.9.5


-- 
Kees Cook
Chrome OS Security

[PATCH 4/4] omapdss: features: fixed supported outputs for OMAP4

[Tomi Valkeinen]

On 2013-03-05 16:17, Archit Taneja wrote:
> The support outputs struct for overlay managers is incorrect for OMAP4. Make
> these changes:
> 
> - DPI isn't supported via the LCD1 overlay manager, remove DPI as a supported
>   output.
> - the TV manager can suppport DPI, but the omapdss driver doesn't support that
>   yet, we require some muxing at the DSS level, and we also need to configure
>   the hdmi pll in the DPI driver so that the TV manager has a pixel clock. We
>   don't support that yet.
> 
> Signed-off-by: Archit Taneja 
> ---
>  drivers/video/omap2/dss/dss_features.c |6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/video/omap2/dss/dss_features.c 
> b/drivers/video/omap2/dss/dss_features.c
> index d7d66ef..7f791ae 100644
> --- a/drivers/video/omap2/dss/dss_features.c
> +++ b/drivers/video/omap2/dss/dss_features.c
> @@ -202,12 +202,10 @@ static const enum omap_dss_output_id 
> omap3630_dss_supported_outputs[] = {
>  
>  static const enum omap_dss_output_id omap4_dss_supported_outputs[] = {
>   /* OMAP_DSS_CHANNEL_LCD */
> - OMAP_DSS_OUTPUT_DPI | OMAP_DSS_OUTPUT_DBI |
> - OMAP_DSS_OUTPUT_DSI1,
> + OMAP_DSS_OUTPUT_DBI | OMAP_DSS_OUTPUT_DSI1,
>  
>   /* OMAP_DSS_CHANNEL_DIGIT */
> - OMAP_DSS_OUTPUT_VENC | OMAP_DSS_OUTPUT_HDMI |
> - OMAP_DSS_OUTPUT_DPI,
> + OMAP_DSS_OUTPUT_VENC | OMAP_DSS_OUTPUT_HDMI,
>  
>   /* OMAP_DSS_CHANNEL_LCD2 */
>   OMAP_DSS_OUTPUT_DPI | OMAP_DSS_OUTPUT_DBI |
> 

Thanks, I'll apply this to omapdss fixes branch.

 Tomi


-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130311/4a9ea618/attachment-0001.pgp>

[PATCH v2] drm/i915: bounds check execbuffer relocation count

[Kees Cook]

It is possible to wrap the counter used to allocate the buffer for
relocation copies. This could lead to heap writing overflows.

Signed-off-by: Kees Cook 
Reported-by: Pinkie Pie
Cc: stable at vger.kernel.org
---
v2:
 - move check into validate_exec_list
---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 752e399..72d7841 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -732,6 +732,7 @@ validate_exec_list(struct drm_i915_gem_exec_object2 *exec,
   int count)
 {
int i;
+   int total = 0;

for (i = 0; i < count; i++) {
char __user *ptr = (char __user *)(uintptr_t)exec[i].relocs_ptr;
@@ -744,6 +745,9 @@ validate_exec_list(struct drm_i915_gem_exec_object2 *exec,
if (exec[i].relocation_count >
INT_MAX / sizeof(struct drm_i915_gem_relocation_entry))
return -EINVAL;
+   if (exec[i].relocation_count > INT_MAX - total)
+   return -ENOMEM;
+   total += exec[i].relocation_count;

length = exec[i].relocation_count *
sizeof(struct drm_i915_gem_relocation_entry);
-- 
1.7.9.5


-- 
Kees Cook
Chrome OS Security

[PATCH] drivers: gpu: drm: i915: Replaced calls to kmalloc & memcpy with kmemdup

[Joe Perches]

On Mon, 2013-03-11 at 22:39 +0200, Alexandru Gheorghiu wrote:
> Replaced calls to kmalloc followed by memcpy with a single call to kmemdup.
> Also removed a now redundant if statement.
[]
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
[]
> @@ -2335,11 +2335,8 @@ intel_dp_get_edid(struct drm_connector *connector, 
> struct i2c_adapter *adapter)
>   return NULL;
>  
>   size = (intel_connector->edid->extensions + 1) * EDID_LENGTH;
> - edid = kmalloc(size, GFP_KERNEL);
> - if (!edid)
> - return NULL;
> + edid = kmemdup(intel_connector->edid, size, GFP_KERNEL);
>  
> - memcpy(edid, intel_connector->edid, size);
>   return edid;
>   }
>  

Might as well get rid of the stack variable edid altogether.
Maybe get rid of size too and use:

if (intel_connector->edid) {
/* invalid edid */
if (IS_ERR(intel_connector->edid))
return NULL;

return kmemdup(intel_connector->edid,
   (intel_connector->edid->extensions + 1) * 
EDID_LENGTH,
   GFP_KERNEL);
}

[PATCH V3] get_maintainer: use filename-only regex match for Tegra

[Stephen Warren]

From: Stephen Warren 

Create a new N: entry type in MAINTAINERS which performs a regex match
against filenames; either those extracted from patch +++ or --- lines,
or those specified on the command-line using the -f option.

This provides the same benefits as using a K: regex option to match a
set of filenames (see commit eb90d08 "get_maintainer: allow keywords to
match filenames"), but without the disadvantage that "random" file
content, such as comments, will ever match the regex. Hence, revert most
of that commit.

Switch the Tegra entry from using K: to N:

Reported-by: Marcin Slusarz 
Suggested-by: Joe Perches 
Signed-off-by: Stephen Warren 
---
v2: Corrected typo in MAINTAINERS documentation
v3: Squash 3 patches into one.
---
 MAINTAINERS   |   14 --
 scripts/get_maintainer.pl |2 +-
 2 files changed, 9 insertions(+), 7 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 9561658..e68a07a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -90,6 +90,9 @@ Descriptions of section entries:
   F:   drivers/net/*   all files in drivers/net, but not below
   F:   */net/* all files in "any top level directory"/net
   One pattern per line.  Multiple F: lines acceptable.
+   N: Files and directories with regex patterns.
+  N:   [^a-z]tegra all files whose patch contains the word tegra
+  One pattern per line.  Multiple N: lines acceptable.
X: Files and directories that are NOT maintained, same rules as F:
   Files exclusions are tested before file matches.
   Can be useful for excluding a specific subdirectory, for instance:
@@ -97,13 +100,12 @@ Descriptions of section entries:
   X:   net/ipv6/
   matches all files in and below net excluding net/ipv6/
K: Keyword perl extended regex pattern to match content in a
-  patch or file, or an affected filename.  For instance:
+  patch or file.  For instance:
   K: of_get_profile
- matches patch or file content, or filenames, that contain
- "of_get_profile"
+ matches patches or files that contain "of_get_profile"
   K: \b(printk|pr_(info|err))\b
- matches patch or file content, or filenames, that contain one or
- more of the words printk, pr_info or pr_err
+ matches patches or files that contain one or more of the words
+ printk, pr_info or pr_err
   One regex pattern per line.  Multiple K: lines acceptable.

 Note: For the hard of thinking, this list is meant to remain in alphabetical
@@ -7848,7 +7850,7 @@ L:linux-tegra at vger.kernel.org
 Q: http://patchwork.ozlabs.org/project/linux-tegra/list/
 T: git 
git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git
 S: Supported
-K: (?i)[^a-z]tegra
+N: [^a-z]tegra

 TEHUTI ETHERNET DRIVER
 M: Andy Gospodarek 
diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
index ce4cc83..5e4fb14 100755
--- a/scripts/get_maintainer.pl
+++ b/scripts/get_maintainer.pl
@@ -611,7 +611,7 @@ sub get_maintainers {
$hash{$tvi} = $value_pd;
}
}
-   } elsif ($type eq 'K') {
+   } elsif ($type eq 'N') {
if ($file =~ m/$value/x) {
$hash{$tvi} = 0;
}
-- 
1.7.10.4

[Bug 60439] Suspend/resume broken for cayman with 90a51a329258e3c868f6

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

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

Christian K?nig  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #10 from Christian K?nig  ---
Going to look into it as soon as I have time. We are probably just missing to
reset something after resume.

Christian.

-- 
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/20130311/dd35aa79/attachment-0001.html>

[PATCH] drm/i915: bounds check execbuffer relocations

[Kees Cook]

On Mon, Mar 11, 2013 at 1:52 PM, Chris Wilson  
wrote:
> On Mon, Mar 11, 2013 at 12:27:16PM -0700, Kees Cook wrote:
>> It is possible to wrap the counter used to allocate the buffer for
>> relocation copies. This could lead to heap writing overflows.
>
> Seems a sensible check, just in the wrong location. You need to do the
> checking upfront in validate_exec_list() so that the error condition is
> always hit and that the limits are applied consistently to all
> execbuffers.

I opted for it here because it kept it out of the fast path which
didn't need this check (it uses a list rather than an array). I will
move it to validate_exec_list().

Thanks!

-Kees

--
Kees Cook
Chrome OS Security

[PATCH] drm/i915: clarify reasoning for the access_ok call

[Kees Cook]

On Mon, Mar 11, 2013 at 1:51 PM, Chris Wilson  
wrote:
> On Mon, Mar 11, 2013 at 12:26:30PM -0700, Kees Cook wrote:
>> This clarifies the comment above the access_ok check so a missing
>> VERIFY_READ doesn't alarm anyone.
>
> Do we really need to copy the interface documentation?
>
> /**
>  * access_ok: - Checks if a user space pointer is valid
>  * @type: Type of access: %VERIFY_READ or %VERIFY_WRITE.  Note that
>  *%VERIFY_WRITE is a superset of %VERIFY_READ - if it is safe
>  *to write to a block, it is always safe to read from it.
>  * @addr: User space pointer to start of block to check
>  * @size: Size of block to check
>  */
> -Chris

Probably not. It just seemed like the existing comment was
insufficient after the removal of the redundant VERIFY_READ check that
happened recently.

-Kees

-- 
Kees Cook
Chrome OS Security

drm/nouveau: port all engines to new engine module format

[Dan Carpenter]

Hello Ben Skeggs,

The patch ebb945a94bba: "drm/nouveau: port all engines to new engine 
module format" from Jul 20, 2012, leads to the following warning:
"drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c:570 
nvc0_graph_ctor()
 error: buffer overflow 'priv->tpc_nr' 4 <= 30"

drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c
   566  
   567  priv->rop_nr = (nv_rd32(priv, 0x409604) & 0x001f) >> 16;
   568  priv->gpc_nr =  nv_rd32(priv, 0x409604) & 0x001f;

setting this to something between 0 and 0x1f.

   569  for (i = 0; i < priv->gpc_nr; i++) {
   570  priv->tpc_nr[i]  = nv_rd32(priv, GPC_UNIT(i, 0x2608));
^^^
If ->gpc_nr is more than 4 we are writing past the end of the array.

   571  priv->tpc_total += priv->tpc_nr[i];
   572  }
   573  

regards,
dan carpenter

[Bug 60439] Suspend/resume broken for cayman with 90a51a329258e3c868f6

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

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

--- Comment #9 from Alex Deucher  ---
Does switching to another VT before suspending help?

-- 
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/20130311/84e85bd5/attachment.html>

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (boot/grub2 and suspend/resume) (CAYMAN)

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

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

Alex Deucher  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #53 from Alex Deucher  ---
(In reply to comment #52)
> Also, nice to know: a suspend/resume cycle under Gnome-Shell or KDE will end
> up hung. However, a suspend/resume cycle under XFCE will work correctly.
> 
> In other words, the problem seems not to be with the memory controller, but
> with something that as to do with how the OpenGL/3D/else state is being
> restored.

Both use the 3D engine.  The 3D driver uses VM however, so it's probably a
duplicate of bug 60439.

*** This bug has been marked as a duplicate of bug 60439 ***

-- 
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/20130311/dfd87ec3/attachment.html>

[Bug 60439] Suspend/resume broken for cayman with 90a51a329258e3c868f6

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

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

Alex Deucher  changed:

   What|Removed |Added

 CC||alexandre.f.demers at gmail.co
   ||m

--- Comment #8 from Alex Deucher  ---
*** Bug 56139 has been marked as a duplicate of this 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/20130311/23be5337/attachment.html>

[PATCH V3] get_maintainer: use filename-only regex match for Tegra

[Joe Perches]

On Mon, 2013-03-11 at 14:19 -0600, Stephen Warren wrote:
> Create a new N: entry type in MAINTAINERS which performs a regex match
> against filenames; either those extracted from patch +++ or --- lines,
> or those specified on the command-line using the -f option.
[]
> Switch the Tegra entry from using K: to N:

Acked-by: Joe Perches 

[PATCH] drivers: gpu: drm: i915: Replaced calls to kmalloc & memcpy with kmemdup

[Josh Triplett]

On Mon, Mar 11, 2013 at 09:30:40PM +0200, Alexandru Gheorghiu wrote:
> Replaced calls to kmalloc followed by memcpy with a single call to kmemdup.
> This patch was found using coccinelle.
> 
> Signed-off-by: Alexandru Gheorghiu 
> ---
>  drivers/gpu/drm/i915/intel_dp.c |3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index f61cb79..a3fdd65 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -2335,11 +2335,10 @@ intel_dp_get_edid(struct drm_connector *connector, 
> struct i2c_adapter *adapter)
>   return NULL;
>  
>   size = (intel_connector->edid->extensions + 1) * EDID_LENGTH;
> - edid = kmalloc(size, GFP_KERNEL);
> + edid = kmemdup(intel_connector->edid, size, GFP_KERNEL);
>   if (!edid)
>   return NULL;
>  
> - memcpy(edid, intel_connector->edid, size);
>   return edid;
>   }

With this change, the conditional no longer makes sense; this should
just "return kmemdup(...);".

That suggests an obvious further cleanup that coccinelle could easily
handle:

if (!foo)
return NULL;
return foo;

should become just "return foo;".  And you might then want to check for
variables used *only* to capture a return value and immediately
returned, and eliminate them.

- Josh Triplett

[PATCH] drm/i915: bounds check execbuffer relocations

[Kees Cook]

It is possible to wrap the counter used to allocate the buffer for
relocation copies. This could lead to heap writing overflows.

Signed-off-by: Kees Cook 
Reported-by: Pinkie Pie
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |   10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 752e399..62eaa99 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -585,7 +585,8 @@ i915_gem_execbuffer_relocate_slow(struct drm_device *dev,
struct drm_i915_gem_object *obj;
bool need_relocs;
int *reloc_offset;
-   int i, total, ret;
+   int ret;
+   unsigned int i, total;
int count = args->buffer_count;

/* We may process another execbuffer during the unlock... */
@@ -600,8 +601,13 @@ i915_gem_execbuffer_relocate_slow(struct drm_device *dev,
mutex_unlock(>struct_mutex);

total = 0;
-   for (i = 0; i < count; i++)
+   for (i = 0; i < count; i++) {
+   if (exec[i].relocation_count > UINT_MAX - total) {
+   mutex_lock(>struct_mutex);
+   return -ENOMEM;
+   }
total += exec[i].relocation_count;
+   }

reloc_offset = drm_malloc_ab(count, sizeof(*reloc_offset));
reloc = drm_malloc_ab(total, sizeof(*reloc));
-- 
1.7.9.5


-- 
Kees Cook
Chrome OS Security

[PATCH] drm/i915: clarify reasoning for the access_ok call

[Kees Cook]

This clarifies the comment above the access_ok check so a missing
VERIFY_READ doesn't alarm anyone.

Signed-off-by: Kees Cook 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 2f2daeb..752e399 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -747,7 +747,11 @@ validate_exec_list(struct drm_i915_gem_exec_object2 *exec,

length = exec[i].relocation_count *
sizeof(struct drm_i915_gem_relocation_entry);
-   /* we may also need to update the presumed offsets */
+   /*
+* Validate memory range. Since we may need to update the
+* presumed offsets, use VERIFY_WRITE. (Writable implies
+* readable.)
+*/
if (!access_ok(VERIFY_WRITE, ptr, length))
return -EFAULT;

-- 
1.7.9.5


-- 
Kees Cook
Chrome OS Security

[PATCH] drm/radeon: check incoming cliprects pointer

[Kees Cook]

The "boxes" parameter points into userspace memory. It should be verified
like any other operation against user memory.

Signed-off-by: Kees Cook 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/radeon/r300_cmdbuf.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/r300_cmdbuf.c 
b/drivers/gpu/drm/radeon/r300_cmdbuf.c
index 865e2c9..60170ea 100644
--- a/drivers/gpu/drm/radeon/r300_cmdbuf.c
+++ b/drivers/gpu/drm/radeon/r300_cmdbuf.c
@@ -75,7 +75,7 @@ static int r300_emit_cliprects(drm_radeon_private_t *dev_priv,
OUT_RING(CP_PACKET0(R300_RE_CLIPRECT_TL_0, nr * 2 - 1));

for (i = 0; i < nr; ++i) {
-   if (DRM_COPY_FROM_USER_UNCHECKED
+   if (DRM_COPY_FROM_USER
(, >boxes[n + i], sizeof(box))) {
DRM_ERROR("copy cliprect faulted\n");
return -EFAULT;
-- 
1.7.9.5


-- 
Kees Cook
Chrome OS Security

[PATCH] drm/i915: restrict kernel address leak in debugfs

[Kees Cook]

Masks kernel address info-leak in object dumps with the %pK suffix,
so they cannot be used to target kernel memory corruption attacks if
the kptr_restrict sysctl is set.

Signed-off-by: Kees Cook 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/i915/i915_debugfs.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index aae3148..7299ea4 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -103,7 +103,7 @@ static const char *cache_level_str(int type)
 static void
 describe_obj(struct seq_file *m, struct drm_i915_gem_object *obj)
 {
-   seq_printf(m, "%p: %s%s %8zdKiB %02x %02x %d %d %d%s%s%s",
+   seq_printf(m, "%pK: %s%s %8zdKiB %02x %02x %d %d %d%s%s%s",
   >base,
   get_pin_flag(obj),
   get_tiling_flag(obj),
-- 
1.7.9.5


-- 
Kees Cook
Chrome OS Security

[PATCHv5,RESEND 3/8] gpu: host1x: Add channel support

[Terje Bergström]

On 11.03.2013 09:18, Thierry Reding wrote:
> This sound a bit over-engineered at this point in time. DRM is currently
> the only user. Is anybody working on any non-DRM drivers that would use
> this?

Well, this contains beginning of that:

http://nv-tegra.nvidia.com/gitweb/?p=linux-2.6.git;a=blob;f=drivers/media/video/tegra_v4l2_camera.c;h=644d0be5380367aca4c826c49724c03aad08387c;hb=l4t/l4t-r16-r2

I don't want to give these guys any excuse not to port it over to host1x
code base. :-)

> Even that aside, I don't think host1x_mem_handle is a good choice of
> name here. The objects are much more than handles. They are in fact
> buffer objects, which can optionally be attached to a handle. I also
> think that using a void * to store the handle specific data isn't such a
> good idea.

Naming if not an issue for me - we can easily agree on using _bo.

> So how about the following proposal, which I think might satisfy both of
> us:
> 
>   struct host1x_bo;
> 
>   struct host1x_bo_ops {
>   struct host1x_bo *(*get)(struct host1x_bo *bo);
>   void (*put)(struct host1x_bo *bo);
>   dma_addr_t (*pin)(struct host1x_bo *bo, struct sg_table **sgt);
>   ...
>   };
> 
>   struct host1x_bo *host1x_bo_get(struct host1x_bo *bo);
>   void host1x_bo_put(struct host1x_bo *bo);
>   dma_addr_t host1x_bo_pin(struct host1x_bo *bo, struct sg_table **sgt);
>   ...
> 
>   struct host1x_bo {
>   const struct host1x_bo_ops *ops;
>   ...
>   };
> 
>   struct tegra_drm_bo {
>   struct host1x_bo base;
>   ...
>   };
> 
> That way you can get rid of the host1x_memmgr_create_handle() helper and
> instead embed host1x_bo into driver-/framework-specific structures with
> the necessary initialization.

This would make sense. We'll get back when we have enough of
implementation done to understand it all. One consequence is that we
cannot use drm_gem_cma_create() anymore. We'll have to introduce a
function that does the same as drm_gem_cma_create(), but it takes a
pre-allocated drm_gem_cma_object pointer. That way we can allocate the
struct, and use DRM CMA just to initialize the drm_gem_cma_object.

Other way would be just taking a copy of DRM CMA helper, but I'd like to
defer that to the next step when we implement IOMMU aware allocator.

> It also allows you to interact directly with the objects instead of
> having to go through the memmgr API. The memory manager doesn't really
> exist anymore so keeping the name in the API is only confusing. Your
> current proposal deals with memory handles directly already so it's
> really just making the naming more consistent.

The memmgr APIs are currently just a shortcut wrapper to the ops, so in
that sense the memmgr does not really exist. I think it might still make
sense to keep static inline wrappers for calling the ops within, but we
could rename them to host1x_bo_somethingandother. Then it'd follow the
pattern we are using for the hw ops in the latest set.

Terje

[PATCHv5,RESEND 3/8] gpu: host1x: Add channel support

[Thierry Reding]

On Mon, Mar 11, 2013 at 11:21:05AM +0200, Terje Bergstr?m wrote:
> On 11.03.2013 09:18, Thierry Reding wrote:
> > This sound a bit over-engineered at this point in time. DRM is currently
> > the only user. Is anybody working on any non-DRM drivers that would use
> > this?
> 
> Well, this contains beginning of that:
> 
> http://nv-tegra.nvidia.com/gitweb/?p=linux-2.6.git;a=blob;f=drivers/media/video/tegra_v4l2_camera.c;h=644d0be5380367aca4c826c49724c03aad08387c;hb=l4t/l4t-r16-r2
> 
> I don't want to give these guys any excuse not to port it over to host1x
> code base. :-)

I was aware of that driver but I didn't realize it had been available
publicly. It's great to see this, though, and one more argument in
favour of not binding the host1x_bo too tightly to DRM/GEM.

> > So how about the following proposal, which I think might satisfy both of
> > us:
> > 
> > struct host1x_bo;
> > 
> > struct host1x_bo_ops {
> > struct host1x_bo *(*get)(struct host1x_bo *bo);
> > void (*put)(struct host1x_bo *bo);
> > dma_addr_t (*pin)(struct host1x_bo *bo, struct sg_table **sgt);
> > ...
> > };
> > 
> > struct host1x_bo *host1x_bo_get(struct host1x_bo *bo);
> > void host1x_bo_put(struct host1x_bo *bo);
> > dma_addr_t host1x_bo_pin(struct host1x_bo *bo, struct sg_table **sgt);
> > ...
> > 
> > struct host1x_bo {
> > const struct host1x_bo_ops *ops;
> > ...
> > };
> > 
> > struct tegra_drm_bo {
> > struct host1x_bo base;
> > ...
> > };
> > 
> > That way you can get rid of the host1x_memmgr_create_handle() helper and
> > instead embed host1x_bo into driver-/framework-specific structures with
> > the necessary initialization.
> 
> This would make sense. We'll get back when we have enough of
> implementation done to understand it all. One consequence is that we
> cannot use drm_gem_cma_create() anymore. We'll have to introduce a
> function that does the same as drm_gem_cma_create(), but it takes a
> pre-allocated drm_gem_cma_object pointer. That way we can allocate the
> struct, and use DRM CMA just to initialize the drm_gem_cma_object.

I certainly think that introducing a drm_gem_cma_object_init() function
shouldn't pose a problem. If you do, make sure to update the existing
drm_gem_cma_create() to use it. Having both lets users have the choice
to use drm_gem_cma_create() if they don't need to embed it, or
drm_gem_cma_object_init() otherwise.

> Other way would be just taking a copy of DRM CMA helper, but I'd like to
> defer that to the next step when we implement IOMMU aware allocator.

I'm not sure I understand what you're saying, but if you add a function
as discussed above this shouldn't be necessary.

> > It also allows you to interact directly with the objects instead of
> > having to go through the memmgr API. The memory manager doesn't really
> > exist anymore so keeping the name in the API is only confusing. Your
> > current proposal deals with memory handles directly already so it's
> > really just making the naming more consistent.
> 
> The memmgr APIs are currently just a shortcut wrapper to the ops, so in
> that sense the memmgr does not really exist. I think it might still make
> sense to keep static inline wrappers for calling the ops within, but we
> could rename them to host1x_bo_somethingandother. Then it'd follow the
> pattern we are using for the hw ops in the latest set.

Yes, that's exactly what I had in mind in the above proposal. They could
be inline, but it's probably also okay if they're not. They aren't meant
to be used very frequently so the extra function call shouldn't matter
much. It might be easier to do add some additional checks if they aren't
inlined. I'm fine either way.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130311/a9615687/attachment.pgp>

[PATCH] drivers/gpu/drm/tilcdc: Makefile, only -Werror when no -W* in EXTRA_CFLAGS

[Rob Clark]

On Sun, Mar 10, 2013 at 12:04 AM, Chen Gang  wrote:
>
>   When make with EXTRA_CFLAGS=-W, it will report error.
>   so give a check in Makefile.
>
> Signed-off-by: Chen Gang 
> Signed-off-by: Vladimir Kondratiev 

Signed-off-by: Rob Clark 

> ---
>  drivers/gpu/drm/tilcdc/Makefile |5 -
>  1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/gpu/drm/tilcdc/Makefile b/drivers/gpu/drm/tilcdc/Makefile
> index deda656..562733a 100644
> --- a/drivers/gpu/drm/tilcdc/Makefile
> +++ b/drivers/gpu/drm/tilcdc/Makefile
> @@ -1,4 +1,7 @@
> -ccflags-y := -Iinclude/drm -Werror
> +ccflags-y := -Iinclude/drm
> +ifeq (, $(findstring -W,$(EXTRA_CFLAGS)))
> +   ccflags-y += -Werror
> +endif
>
>  tilcdc-y := \
> tilcdc_crtc.o \
> --
> 1.7.7.6

[PATCH] drivers/gpu/drm/omapdrm: Makefile, only -Werror when no -W* in EXTRA_CFLAGS

[Rob Clark]

On Sat, Mar 9, 2013 at 11:21 PM, Chen Gang  wrote:
>
>   When make with EXTRA_CFLAGS=-W, it will report error.
>   so give a check in Makefile.
>
> Signed-off-by: Chen Gang 
> Signed-off-by: Vladimir Kondratiev 

Signed-off-by: Rob Clark 

> ---
>  drivers/gpu/drm/omapdrm/Makefile |5 -
>  1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/Makefile 
> b/drivers/gpu/drm/omapdrm/Makefile
> index d85e058..8beaf05 100644
> --- a/drivers/gpu/drm/omapdrm/Makefile
> +++ b/drivers/gpu/drm/omapdrm/Makefile
> @@ -3,7 +3,10 @@
>  # Direct Rendering Infrastructure (DRI)
>  #
>
> -ccflags-y := -Iinclude/drm -Werror
> +ccflags-y := -Iinclude/drm
> +ifeq (, $(findstring -W,$(EXTRA_CFLAGS)))
> +   ccflags-y += -Werror
> +endif
>  omapdrm-y := omap_drv.o \
> omap_irq.o \
> omap_debugfs.o \
> --
> 1.7.7.6

nouveau shuts the machine down with v3.9-rc1 (temperature (72 C) hit the 'shutdown' threshold).

[Konrad Rzeszutek Wilk]

> With that I am still getting the issues (even with an insance delay of 100 
> seconds).
> Here is the serial log with various runs.

Any thoughts?
> [   13.523878] initcall init_sg+0x0/0x1000 [sg] returned 0 after 5355 usecs
> ^G^G[   13.621376] nouveau  [  PTHERM][:00:0d.0] programmed thresholds [ 
> 90(2), 95(3), 145(2), 135(5) ]
> [   13.630487] nouveau 39079] nouveau  [  PTHERM][:00:0d.0] Thermal 
> management: automatic
> [   13.646028] nouveau  [  PTHERM][:00:0d.0] temperature (218 C) hit the 
> 'downclock' threshold
> [   13.654702] nouveau  [  PTHERM][:00:0d.0] temperature (218 C) hit the 
> 'critical' threshold
> [   13.663296] nouveau  [  PTHERM][:00:0d.0] temperature (218 C) hit the 
> 'shutdown' threshold
> [   13.671992] [TTM] Zone  kernel: Available graphics memory: 1963774 kiB

Perhaps I've some insanely stupid BIOS?

[PATCHv5,RESEND 3/8] gpu: host1x: Add channel support

[Terje Bergström]

On 08.03.2013 22:43, Thierry Reding wrote:
> A bo is just a buffer object, so I don't see why the name shouldn't
> be used. The name is in no way specific to DRM or GEM. But the point
> that I was trying to make was that there is nothing to suggest that
> we couldn't use drm_gem_object as the underlying scaffold to base all
> host1x buffer objects on.
> 
> Furthermore I don't understand why you've chosen this approach. It
> is completely different from what other drivers do and therefore
> makes it more difficult to comprehend. That alone I could live with
> if there were any advantages to that approach, but as far as I can
> tell there are none.

I was following the plan we agreed on earlier in email discussion with
you and Lucas:

On 29.11.2012 11:09, Lucas Stach wrote:
> We should aim for a clean split here. GEM handles are something which
> is really specific to how DRM works and as such should be constructed
> by tegradrm. nvhost should really just manage allocations/virtual
> address space and provide something that is able to back all the GEM
> handle operations.
> 
> nvhost has really no reason at all to even know about GEM handles.
> If you back a GEM object by a nvhost object you can just peel out
> the nvhost handles from the GEM wrapper in the tegradrm submit ioctl
> handler and queue the job to nvhost using it's native handles.
> 
> This way you would also be able to construct different handles (like
> GEM obj or V4L2 buffers) from the same backing nvhost object. Note
> that I'm not sure how useful this would be, but it seems like a
> reasonable design to me being able to do so.

With this structure, we are already prepared for non-DRM APIs. Tt's a
matter of familiarity of code versus future expansion. Code paths for
both are as simple/complex, so neither has a direct technical
superiority in performance.

I know other DRM drivers have opted to hard code GEM dependency
throughout the code. Then again, host1x hardware is managing much more
than graphics, so we need to think outside the DRM box, too.

Terje

[PATCHv5,RESEND 3/8] gpu: host1x: Add channel support

[Thierry Reding]

On Mon, Mar 11, 2013 at 08:29:59AM +0200, Terje Bergstr?m wrote:
> On 08.03.2013 22:43, Thierry Reding wrote:
> > A bo is just a buffer object, so I don't see why the name shouldn't
> > be used. The name is in no way specific to DRM or GEM. But the point
> > that I was trying to make was that there is nothing to suggest that
> > we couldn't use drm_gem_object as the underlying scaffold to base all
> > host1x buffer objects on.
> > 
> > Furthermore I don't understand why you've chosen this approach. It
> > is completely different from what other drivers do and therefore
> > makes it more difficult to comprehend. That alone I could live with
> > if there were any advantages to that approach, but as far as I can
> > tell there are none.
> 
> I was following the plan we agreed on earlier in email discussion with
> you and Lucas:
> 
> On 29.11.2012 11:09, Lucas Stach wrote:
> > We should aim for a clean split here. GEM handles are something which
> > is really specific to how DRM works and as such should be constructed
> > by tegradrm. nvhost should really just manage allocations/virtual
> > address space and provide something that is able to back all the GEM
> > handle operations.
> > 
> > nvhost has really no reason at all to even know about GEM handles.
> > If you back a GEM object by a nvhost object you can just peel out
> > the nvhost handles from the GEM wrapper in the tegradrm submit ioctl
> > handler and queue the job to nvhost using it's native handles.
> > 
> > This way you would also be able to construct different handles (like
> > GEM obj or V4L2 buffers) from the same backing nvhost object. Note
> > that I'm not sure how useful this would be, but it seems like a
> > reasonable design to me being able to do so.
> 
> With this structure, we are already prepared for non-DRM APIs. Tt's a
> matter of familiarity of code versus future expansion. Code paths for
> both are as simple/complex, so neither has a direct technical
> superiority in performance.
> 
> I know other DRM drivers have opted to hard code GEM dependency
> throughout the code. Then again, host1x hardware is managing much more
> than graphics, so we need to think outside the DRM box, too.

This sound a bit over-engineered at this point in time. DRM is currently
the only user. Is anybody working on any non-DRM drivers that would use
this?

Even that aside, I don't think host1x_mem_handle is a good choice of
name here. The objects are much more than handles. They are in fact
buffer objects, which can optionally be attached to a handle. I also
think that using a void * to store the handle specific data isn't such a
good idea.

So how about the following proposal, which I think might satisfy both of
us:

struct host1x_bo;

struct host1x_bo_ops {
struct host1x_bo *(*get)(struct host1x_bo *bo);
void (*put)(struct host1x_bo *bo);
dma_addr_t (*pin)(struct host1x_bo *bo, struct sg_table **sgt);
...
};

struct host1x_bo *host1x_bo_get(struct host1x_bo *bo);
void host1x_bo_put(struct host1x_bo *bo);
dma_addr_t host1x_bo_pin(struct host1x_bo *bo, struct sg_table **sgt);
...

struct host1x_bo {
const struct host1x_bo_ops *ops;
...
};

struct tegra_drm_bo {
struct host1x_bo base;
...
};

That way you can get rid of the host1x_memmgr_create_handle() helper and
instead embed host1x_bo into driver-/framework-specific structures with
the necessary initialization.

It also allows you to interact directly with the objects instead of
having to go through the memmgr API. The memory manager doesn't really
exist anymore so keeping the name in the API is only confusing. Your
current proposal deals with memory handles directly already so it's
really just making the naming more consistent.

Thierry
-- next part ------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130311/b61add17/attachment.pgp>

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (boot/grub2 and suspend/resume) (CAYMAN)

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

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

--- Comment #52 from Alexandre Demers  ---
Also, nice to know: a suspend/resume cycle under Gnome-Shell or KDE will end up
hung. However, a suspend/resume cycle under XFCE will work correctly.

In other words, the problem seems not to be with the memory controller, but
with something that as to do with how the OpenGL/3D/else state is being
restored.

-- 
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/20130311/e65a0d79/attachment.html>

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (boot/grub2 and suspend/resume) (CAYMAN)

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

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

--- Comment #51 from Alexandre Demers  ---
(In reply to comment #50)
> (In reply to comment #49)
> > What if the problem is not from this code, but underneath? I'll try to
> > suspend and resume without having Xorg running. Would that help in any way?
> 
> If the commit you bisected is actually the culprit, this is an issue with
> the memory controller and the displays on the GPU.  When we reprogram the
> memory controller we need to stop all the GPU memory clients.  We used to
> disable the display controllers but this caused additional flicker on boot
> up and caused hangs on some cards.  So we switched to the current method
> which was recommended by the hardware team.  This avoids the flicker by just
> stopping the MC interface in the displays but leaving them enabled and also
> fixes hangs related to this on a number of chips.  Unfortunately, it seems
> to cause other problems in certain causes.

Since I had just installed kernel 3.9.0-rc2, I tried a suspend and resume
cycle. As expected, it end up frozen (I saw some text from the console,
Xorg/Gnome tried to display something, couldn't, reset, couldn't, reset and
froze). I then rebooted and limited the runlevel to 2 (no Xorg in the way).
>From the command line, I launched a pm-suspend. Once I woke up my computer,
everything was responsive as expected. Does it help in anyway?

-- 
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/20130311/b3f04470/attachment.html>

[Bug 60802] Corruption with DMA ring on cayman

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

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

--- Comment #43 from Alexandre Demers  ---
Still getting this rendering problem with kernel 3.9.0-rc2 and today's mesa
code.

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

Re: [Linaro-mm-sig] [PATCH v2 1/3] arch: make __mutex_fastpath_lock_retval return whether fastpath succeeded or not.

[Francesco Lavra]

On 02/28/2013 11:24 AM, Maarten Lankhorst wrote:
 This will allow me to call functions that have multiple arguments if fastpath 
 fails.
 This is required to support ticket mutexes, because they need to be able to 
 pass an
 extra argument to the fail function.
 
 Originally I duplicated the functions, by adding 
 __mutex_fastpath_lock_retval_arg.
 This ended up being just a duplication of the existing function, so a way to 
 test
 if fastpath was called ended up being better.
 
 This also cleaned up the reservation mutex patch some by being able to call an
 atomic_set instead of atomic_xchg, and making it easier to detect if the wrong
 unlock function was previously used.
 
 Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
 ---
  arch/ia64/include/asm/mutex.h|   10 --
  arch/powerpc/include/asm/mutex.h |   10 --
  arch/sh/include/asm/mutex-llsc.h |4 ++--
  arch/x86/include/asm/mutex_32.h  |   11 ---
  arch/x86/include/asm/mutex_64.h  |   11 ---
  include/asm-generic/mutex-dec.h  |   10 --
  include/asm-generic/mutex-null.h |2 +-
  include/asm-generic/mutex-xchg.h |   10 --
  kernel/mutex.c   |   32 ++--
  9 files changed, 41 insertions(+), 59 deletions(-)
[...]
 diff --git a/arch/x86/include/asm/mutex_32.h b/arch/x86/include/asm/mutex_32.h
 index 03f90c8..b7f6b34 100644
 --- a/arch/x86/include/asm/mutex_32.h
 +++ b/arch/x86/include/asm/mutex_32.h
 @@ -42,17 +42,14 @@ do {  
 \
   *  __mutex_fastpath_lock_retval - try to take the lock by moving the count
   * from 1 to a 0 value
   *  @count: pointer of type atomic_t
 - *  @fail_fn: function to call if the original value was not 1
   *
 - * Change the count from 1 to a value lower than 1, and call fail_fn if it
 - * wasn't 1 originally. This function returns 0 if the fastpath succeeds,
 - * or anything the slow path function returns
 + * Change the count from 1 to a value lower than 1. This function returns 0
 + * if the fastpath succeeds, or 1 otherwise.

The minus sign is missing, the return value should be -1.

[...]
 diff --git a/include/asm-generic/mutex-null.h 
 b/include/asm-generic/mutex-null.h
 index e1bbbc7..efd6206 100644
 --- a/include/asm-generic/mutex-null.h
 +++ b/include/asm-generic/mutex-null.h
 @@ -11,7 +11,7 @@
  #define _ASM_GENERIC_MUTEX_NULL_H
  
  #define __mutex_fastpath_lock(count, fail_fn)fail_fn(count)
 -#define __mutex_fastpath_lock_retval(count, fail_fn) fail_fn(count)
 +#define __mutex_fastpath_lock_retval(count, fail_fn) (-1)

The fail_fn parameter should be dropped here as well.

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

[PATCH] drivers/gpu/drm/omapdrm: Makefile, only -Werror when no -W* in EXTRA_CFLAGS

[Chen Gang]

  When make with EXTRA_CFLAGS=-W, it will report error.
  so give a check in Makefile.

Signed-off-by: Chen Gang gang.c...@asianux.com
Signed-off-by: Vladimir Kondratiev qca_vkond...@qca.qualcomm.com
---
 drivers/gpu/drm/omapdrm/Makefile |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/Makefile b/drivers/gpu/drm/omapdrm/Makefile
index d85e058..8beaf05 100644
--- a/drivers/gpu/drm/omapdrm/Makefile
+++ b/drivers/gpu/drm/omapdrm/Makefile
@@ -3,7 +3,10 @@
 # Direct Rendering Infrastructure (DRI)
 #
 
-ccflags-y := -Iinclude/drm -Werror
+ccflags-y := -Iinclude/drm 
+ifeq (, $(findstring -W,$(EXTRA_CFLAGS)))
+   ccflags-y += -Werror
+endif
 omapdrm-y := omap_drv.o \
omap_irq.o \
omap_debugfs.o \
-- 
1.7.7.6
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Suggestion] drivers/gpu/drm/tilcdc: link failed

[Chen Gang]

Hello David Airlie:

  link fail:
drivers/gpu/drm/tilcdc/tilcdc_slave.o:(.data+0x54): multiple definition of 
`__mod_of_device_table'
drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54)：first defined here
drivers/gpu/drm/tilcdc/tilcdc_panel.o:(.data+0x54): multiple definition of 
`__mod_of_device_table'
drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54)：first defined here
drivers/gpu/drm/tilcdc/tilcdc_drv.o:(.data+0x184): multiple definition of 
`__mod_of_device_table'
drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54)：first defined here


  make command:
for next-20130307 tree:
  make ARCH=arm EXTRA_CFLAGS=-W allmodconfig
  make ARCH=arm EXTRA_CFLAGS=-W

  solving ways:
please reference the mails and patch which provided by David Miller for 
sparc64
I think they are the same root cause (although different issues).
  ref link: http://permalink.gmane.org/gmane.linux.ports.sparc/17155
  ref commit: 226f7cea949303a3e1911999a9a2c71b0a708e73


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

linux 3.9-rc1: nouveau crash on PPC

[Aaro Koskinen]

Hi,

There's nouveau crash during boot with 3.9-rc1 on iMac G5 (nVidia GeForce
FX 5200 Ultra). This happens also with current mainline kernel HEAD
(0aefda3e8188ad71168bd32152d41b3d72f04087).

git bisect tells the first bad commit is
1d7c71a3e2f77336df536855b0efd2dc5bdeb41b (drm/nouveau/disp: port vblank
handling to event interface).

The crash is (manually copied from screen):

[...]

Unable to handle kernel paging request for data at address 0x1

call trace:
nouveau_event_trigger
nv04_disp_intr
nouveau_mc_intr
nouveau_irq_handler

[...]

I also tried to capture it with netconsole, and got this much:

[   23.114208] nouveau  [  DEVICE][:f0:10.0] BOOT0  : 0x034900b1
[   23.114257] nouveau  [  DEVICE][:f0:10.0] Chipset: NV34 (NV34)
[   23.114266] nouveau  [  DEVICE][:f0:10.0] Family : NV30
[   23.114672] nouveau  [   VBIOS][:f0:10.0] checking OpenFirmware for 
image...
[   23.114712] nouveau  [   VBIOS][:f0:10.0] ... checksum invalid
[   23.114720] nouveau  [   VBIOS][:f0:10.0] checking PRAMIN for image...
[   23.114754] nouveau  [   VBIOS][:f0:10.0] ... signature not found
[   23.114761] nouveau  [   VBIOS][:f0:10.0] checking PROM for image...
[   23.114845] nouveau  [   VBIOS][:f0:10.0] ... signature not found
[   23.114853] nouveau  [   VBIOS][:f0:10.0] checking ACPI for image...
[   23.114862] nouveau  [   VBIOS][:f0:10.0] ... signature not found
[   23.114881] nouveau  [   VBIOS][:f0:10.0] checking PCIROM for image...
[   23.114930] nouveau :f0:10.0: Invalid ROM contents
[   23.114946] nouveau  [   VBIOS][:f0:10.0] ... signature not found
[   23.114976] nouveau  [   VBIOS][:f0:10.0] using image from OpenFirmware
[   23.114987] nouveau  [   VBIOS][:f0:10.0] BMP version 5.26
[   23.115035] nouveau  [   VBIOS][:f0:10.0] version 04.34.20.18.00
[   23.134608] nouveau W[   VBIOS][:f0:10.0] unknown i2c type 3
[   23.134637] nouveau W[   VBIOS][:f0:10.0] unknown i2c type 3
[   23.136488] nouveau W[  PTIMER][:f0:10.0] unknown input clock freq
[   23.136536] nouveau  [ PFB][:f0:10.0] RAM type: DDR1
[   23.136544] nouveau  [ PFB][:f0:10.0] RAM size: 32 MiB
[   23.136552] nouveau  [ PFB][:f0:10.0]ZCOMP: 0 tags
[   23.150773] [TTM] Zone  kernel: Available graphics memory: 744988 kiB
[   23.150800] [TTM] Initializing pool allocator
[   23.150882] nouveau  [ DRM] VRAM: 31 MiB
[   23.150890] nouveau  [ DRM] GART: 128 MiB
[   23.150927] nouveau  [ DRM] BMP version 5.38
[   23.150937] nouveau  [ DRM] DCB version 2.2
[   23.150971] nouveau  [ DRM] DCB outp 00: 01000122 0004
[   23.150981] nouveau  [ DRM] DCB outp 01: 02010200 11b088b8
[   23.150988] nouveau  [ DRM] DCB outp 02: 02010201 11b00703
[   23.151040] nouveau  [ DRM] Loading NV17 power sequencing microcode
[   23.170180] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[   23.170212] [drm] No driver support for vblank timestamp query.
[   23.170277] nouveau E[ DRM] Pixel clock comparison table not found
[   23.171010] nouveau  [ DRM] 0 available performance level(s)
[   23.171028] nouveau  [ DRM] c: core 241MHz memory 475MHz
[   23.177822] nouveau  [ DRM] MM: using M2MF for buffer copies
[   23.177917] nouveau  [ DRM] Setting dpms mode 3 on TV encoder (output 2)
[   23.285783] nouveau  [ DRM] allocated 1680x1050 fb: 0x9000, bo 
c00056d52c00
[   23.306569] nouveau E[ DRM] Pixel clock comparison table not found
[   23.317565] Console: switching to colour frame buffer device 210x65
[   23.321370] nouveau :f0:10.0: fb0: nouveaufb frame buffer device
[   23.321386] nouveau :f0:10.0: registered panic notifier
[   23.321444] [drm] Initialized nouveau 1.1.0 20120801 for :f0:10.0 on 
minor 0
[   23.329860] Unable to handle kernel paging request for data at address 
0x1
[   23.329918] Faulting instruction address: 0xd0801394
[   23.329939] Oops: Kernel access of bad area, sig: 11 [#1]
[   23.329953] PREEMPT PowerMac
[   23.329982] Modules linked in: nouveau ttm drm_kms_helper
[   23.330035] NIP: d0801394 LR: d08013a8 CTR: c00178e0
[   23.330052] REGS: cfff78b0 TRAP: 0300   Not tainted  
(3.9.0-rc1-imac-00277-g0aefda3-dirty)
[   23.330065] MSR: 90009032 SF,HV,EE,ME,IR,DR,RI  CR: 2884  XER: 

[   23.330174] SOFTE: 0
[   23.330187] DAR: 0001, DSISR: 4000
[   23.330202] TASK = c0805aa0[0] 'swapper' THREAD: c0894000
GPR00: d08013a8 cfff7b30 d09272c0 c00056de5458 
GPR04:   0002  
GPR08: [   24.321933] Kernel panic - not syncing: Fatal exception in interrupt
[   24.321951] drm_kms_helper: panic occurred, switching back to text console
[   24.322013] [ cut here ]
[   24.322029] WARNING: at drivers/gpu/drm/drm_crtc.c:82
[   24.322041] Modules linked in: nouveau ttm 

[PATCH] drivers/gpu/drm/tilcdc: Makefile, only -Werror when no -W* in EXTRA_CFLAGS

[Chen Gang]

  When make with EXTRA_CFLAGS=-W, it will report error.
  so give a check in Makefile.

Signed-off-by: Chen Gang gang.c...@asianux.com
Signed-off-by: Vladimir Kondratiev qca_vkond...@qca.qualcomm.com
---
 drivers/gpu/drm/tilcdc/Makefile |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/tilcdc/Makefile b/drivers/gpu/drm/tilcdc/Makefile
index deda656..562733a 100644
--- a/drivers/gpu/drm/tilcdc/Makefile
+++ b/drivers/gpu/drm/tilcdc/Makefile
@@ -1,4 +1,7 @@
-ccflags-y := -Iinclude/drm -Werror
+ccflags-y := -Iinclude/drm
+ifeq (, $(findstring -W,$(EXTRA_CFLAGS)))
+   ccflags-y += -Werror
+endif
 
 tilcdc-y := \
tilcdc_crtc.o \
-- 
1.7.7.6
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Suggestion] drivers/gpu/drm/tilcdc: link failed

[Chen Gang]

  oh, it has been mentioned by Russell King.
  please reference: https://lkml.org/lkml/2013/3/4/114

  this mail can be obsoleted.

gchen.

于 2013年03月10日 12:56, Chen Gang 写道:
 Hello David Airlie:
 
   link fail:
 drivers/gpu/drm/tilcdc/tilcdc_slave.o:(.data+0x54): multiple definition 
 of `__mod_of_device_table'
 drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54)：first defined here
 drivers/gpu/drm/tilcdc/tilcdc_panel.o:(.data+0x54): multiple definition 
 of `__mod_of_device_table'
 drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54)：first defined here
 drivers/gpu/drm/tilcdc/tilcdc_drv.o:(.data+0x184): multiple definition of 
 `__mod_of_device_table'
 drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54)：first defined here
 
 
   make command:
 for next-20130307 tree:
   make ARCH=arm EXTRA_CFLAGS=-W allmodconfig
   make ARCH=arm EXTRA_CFLAGS=-W
 
   solving ways:
 please reference the mails and patch which provided by David Miller for 
 sparc64
 I think they are the same root cause (although different issues).
   ref link: http://permalink.gmane.org/gmane.linux.ports.sparc/17155
   ref commit: 226f7cea949303a3e1911999a9a2c71b0a708e73
 
 
   thanks.
 


-- 
Chen Gang

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

[PATCH] gpu: don't cast kzalloc() return value

[Mihnea Dobrescu-Balaur]

Signed-off-by: Mihnea Dobrescu-Balaur mihne...@gmail.com
---
 drivers/gpu/drm/i915/intel_sdvo.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_sdvo.c 
b/drivers/gpu/drm/i915/intel_sdvo.c
index df08e81..5300526 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -451,7 +451,7 @@ static bool intel_sdvo_write_cmd(struct intel_sdvo 
*intel_sdvo, u8 cmd,
int i, ret = true;
 
 /* Would be simpler to allocate both in one go ? */
-   buf = (u8 *)kzalloc(args_len * 2 + 2, GFP_KERNEL);
+   buf = kzalloc(args_len * 2 + 2, GFP_KERNEL);
if (!buf)
return false;
 
-- 
1.7.10.4

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

[PATCH] gpu: make 'vmw_event_fence_action_create' static

[Ghennadi Procopciuc]

This fixes the following checkpatch warning :
drivers/gpu/drm/vmwgfx/vmwgfx_fence.c:996:5: warning: symbol
'vmw_event_fence_action_create' was not declared. Should it be static?

Signed-off-by: Ghennadi Procopciuc unix...@gmail.com
---
 drivers/gpu/drm/vmwgfx/vmwgfx_fence.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
index c62d20e..e0846e6 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
@@ -952,7 +952,7 @@ void vmw_fence_obj_add_action(struct vmw_fence_obj *fence,
  * an error code, the caller needs to free that object.
  */
 
-int vmw_event_fence_action_queue(struct drm_file *file_priv,
+static int vmw_event_fence_action_queue(struct drm_file *file_priv,
 struct vmw_fence_obj *fence,
 struct drm_pending_event *event,
 uint32_t *tv_sec,
-- 
1.7.10.4

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

[PATCH] make 'vmw_fences_perform_actions' static

[Ghennadi Procopciuc]

This fixes the following checkpatch warning :
drivers/gpu/drm/vmwgfx/vmwgfx_fence.c:274:6: warning: symbol
'vmw_fences_perform_actions' was not declared. Should it be static?

Signed-off-by: Ghennadi Procopciuc ghennadi.procopci...@gmail.com
---
 drivers/gpu/drm/vmwgfx/vmwgfx_fence.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
index e0846e6..2762fe3 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
@@ -271,7 +271,7 @@ void vmw_fence_obj_unreference(struct vmw_fence_obj 
**fence_p)
spin_unlock_irq(fman-lock);
 }
 
-void vmw_fences_perform_actions(struct vmw_fence_manager *fman,
+static void vmw_fences_perform_actions(struct vmw_fence_manager *fman,
struct list_head *list)
 {
struct vmw_fence_action *action, *next_action;
-- 
1.7.10.4

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

[PATCH] make 'vmw_fence_obj_add_action' static

[Ghennadi Procopciuc]

This fixes the following checkpatch warning :
drivers/gpu/drm/vmwgfx/vmwgfx_fence.c:274:6: warning: symbol
'vmw_fences_perform_actions' was not declared. Should it be static?

Signed-off-by: Ghennadi Procopciuc ghennadi.procopci...@gmail.com
---
 drivers/gpu/drm/vmwgfx/vmwgfx_fence.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
index 2762fe3..07a463f 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
@@ -897,7 +897,7 @@ static void vmw_event_fence_action_cleanup(struct 
vmw_fence_action *action)
  * Note that the action callbacks may be executed before this function
  * returns.
  */
-void vmw_fence_obj_add_action(struct vmw_fence_obj *fence,
+static void vmw_fence_obj_add_action(struct vmw_fence_obj *fence,
  struct vmw_fence_action *action)
 {
struct vmw_fence_manager *fman = fence-fman;
-- 
1.7.10.4

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

[PATCH] drm/i915: use simple attribute in debugfs routines

[Kees Cook]

This replaces the manual read/write routines in debugfs with the common
simple attribute helpers. Doing this gets rid of repeated copy/pasting
of copy_from_user and value formatting code.

Signed-off-by: Kees Cook keesc...@chromium.org
Cc: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/i915/i915_debugfs.c |  394 +--
 1 file changed, 98 insertions(+), 296 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index aae3148..d86c304 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -849,76 +849,42 @@ static const struct file_operations i915_error_state_fops 
= {
.release = i915_error_state_release,
 };
 
-static ssize_t
-i915_next_seqno_read(struct file *filp,
-char __user *ubuf,
-size_t max,
-loff_t *ppos)
+static int
+i915_next_seqno_get(void *data, u64 *val)
 {
-   struct drm_device *dev = filp-private_data;
+   struct drm_device *dev = data;
drm_i915_private_t *dev_priv = dev-dev_private;
-   char buf[80];
-   int len;
int ret;
 
ret = mutex_lock_interruptible(dev-struct_mutex);
if (ret)
return ret;
 
-   len = snprintf(buf, sizeof(buf),
-  next_seqno :  0x%x\n,
-  dev_priv-next_seqno);
-
+   *val = dev_priv-next_seqno;
mutex_unlock(dev-struct_mutex);
 
-   if (len  sizeof(buf))
-   len = sizeof(buf);
-
-   return simple_read_from_buffer(ubuf, max, ppos, buf, len);
+   return 0;
 }
 
-static ssize_t
-i915_next_seqno_write(struct file *filp,
- const char __user *ubuf,
- size_t cnt,
- loff_t *ppos)
-{
-   struct drm_device *dev = filp-private_data;
-   char buf[20];
-   u32 val = 1;
+static int
+i915_next_seqno_set(void *data, u64 val)
+{
+   struct drm_device *dev = data;
int ret;
 
-   if (cnt  0) {
-   if (cnt  sizeof(buf) - 1)
-   return -EINVAL;
-
-   if (copy_from_user(buf, ubuf, cnt))
-   return -EFAULT;
-   buf[cnt] = 0;
-
-   ret = kstrtouint(buf, 0, val);
-   if (ret  0)
-   return ret;
-   }
-
ret = mutex_lock_interruptible(dev-struct_mutex);
if (ret)
return ret;
 
ret = i915_gem_set_seqno(dev, val);
-
mutex_unlock(dev-struct_mutex);
 
-   return ret ?: cnt;
+   return ret;
 }
 
-static const struct file_operations i915_next_seqno_fops = {
-   .owner = THIS_MODULE,
-   .open = simple_open,
-   .read = i915_next_seqno_read,
-   .write = i915_next_seqno_write,
-   .llseek = default_llseek,
-};
+DEFINE_SIMPLE_ATTRIBUTE(i915_next_seqno_fops,
+   i915_next_seqno_get, i915_next_seqno_set,
+   next_seqno :  0x%llx\n);
 
 static int i915_rstdby_delays(struct seq_file *m, void *unused)
 {
@@ -1680,105 +1646,51 @@ static int i915_dpio_info(struct seq_file *m, void 
*data)
return 0;
 }
 
-static ssize_t
-i915_wedged_read(struct file *filp,
-char __user *ubuf,
-size_t max,
-loff_t *ppos)
+static int
+i915_wedged_get(void *data, u64 *val)
 {
-   struct drm_device *dev = filp-private_data;
+   struct drm_device *dev = data;
drm_i915_private_t *dev_priv = dev-dev_private;
-   char buf[80];
-   int len;
 
-   len = snprintf(buf, sizeof(buf),
-  wedged :  %d\n,
-  atomic_read(dev_priv-gpu_error.reset_counter));
+   *val = atomic_read(dev_priv-gpu_error.reset_counter);
 
-   if (len  sizeof(buf))
-   len = sizeof(buf);
-
-   return simple_read_from_buffer(ubuf, max, ppos, buf, len);
+   return 0;
 }
 
-static ssize_t
-i915_wedged_write(struct file *filp,
- const char __user *ubuf,
- size_t cnt,
- loff_t *ppos)
+static int
+i915_wedged_set(void *data, u64 val)
 {
-   struct drm_device *dev = filp-private_data;
-   char buf[20];
-   int val = 1;
-
-   if (cnt  0) {
-   if (cnt  sizeof(buf) - 1)
-   return -EINVAL;
+   struct drm_device *dev = data;
 
-   if (copy_from_user(buf, ubuf, cnt))
-   return -EFAULT;
-   buf[cnt] = 0;
-
-   val = simple_strtoul(buf, NULL, 0);
-   }
-
-   DRM_INFO(Manually setting wedged to %d\n, val);
+   DRM_INFO(Manually setting wedged to %llu\n, val);
i915_handle_error(dev, val);
 
-   return cnt;
+   return 0;
 }
 
-static const struct file_operations i915_wedged_fops = {
-   .owner = THIS_MODULE,
-   .open = simple_open,
-   .read = i915_wedged_read,
-   .write = i915_wedged_write,
-   

Re: [PATCHv5,RESEND 3/8] gpu: host1x: Add channel support

[Terje Bergström]

On 08.03.2013 22:43, Thierry Reding wrote:
 A bo is just a buffer object, so I don't see why the name shouldn't
 be used. The name is in no way specific to DRM or GEM. But the point
 that I was trying to make was that there is nothing to suggest that
 we couldn't use drm_gem_object as the underlying scaffold to base all
 host1x buffer objects on.
 
 Furthermore I don't understand why you've chosen this approach. It
 is completely different from what other drivers do and therefore
 makes it more difficult to comprehend. That alone I could live with
 if there were any advantages to that approach, but as far as I can
 tell there are none.

I was following the plan we agreed on earlier in email discussion with
you and Lucas:

On 29.11.2012 11:09, Lucas Stach wrote:
 We should aim for a clean split here. GEM handles are something which
 is really specific to how DRM works and as such should be constructed
 by tegradrm. nvhost should really just manage allocations/virtual
 address space and provide something that is able to back all the GEM
 handle operations.
 
 nvhost has really no reason at all to even know about GEM handles.
 If you back a GEM object by a nvhost object you can just peel out
 the nvhost handles from the GEM wrapper in the tegradrm submit ioctl
 handler and queue the job to nvhost using it's native handles.
 
 This way you would also be able to construct different handles (like
 GEM obj or V4L2 buffers) from the same backing nvhost object. Note
 that I'm not sure how useful this would be, but it seems like a
 reasonable design to me being able to do so.

With this structure, we are already prepared for non-DRM APIs. Tt's a
matter of familiarity of code versus future expansion. Code paths for
both are as simple/complex, so neither has a direct technical
superiority in performance.

I know other DRM drivers have opted to hard code GEM dependency
throughout the code. Then again, host1x hardware is managing much more
than graphics, so we need to think outside the DRM box, too.

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

Re: [PATCHv5,RESEND 3/8] gpu: host1x: Add channel support

[Thierry Reding]

On Mon, Mar 11, 2013 at 08:29:59AM +0200, Terje Bergström wrote:
 On 08.03.2013 22:43, Thierry Reding wrote:
  A bo is just a buffer object, so I don't see why the name shouldn't
  be used. The name is in no way specific to DRM or GEM. But the point
  that I was trying to make was that there is nothing to suggest that
  we couldn't use drm_gem_object as the underlying scaffold to base all
  host1x buffer objects on.
  
  Furthermore I don't understand why you've chosen this approach. It
  is completely different from what other drivers do and therefore
  makes it more difficult to comprehend. That alone I could live with
  if there were any advantages to that approach, but as far as I can
  tell there are none.
 
 I was following the plan we agreed on earlier in email discussion with
 you and Lucas:
 
 On 29.11.2012 11:09, Lucas Stach wrote:
  We should aim for a clean split here. GEM handles are something which
  is really specific to how DRM works and as such should be constructed
  by tegradrm. nvhost should really just manage allocations/virtual
  address space and provide something that is able to back all the GEM
  handle operations.
  
  nvhost has really no reason at all to even know about GEM handles.
  If you back a GEM object by a nvhost object you can just peel out
  the nvhost handles from the GEM wrapper in the tegradrm submit ioctl
  handler and queue the job to nvhost using it's native handles.
  
  This way you would also be able to construct different handles (like
  GEM obj or V4L2 buffers) from the same backing nvhost object. Note
  that I'm not sure how useful this would be, but it seems like a
  reasonable design to me being able to do so.
 
 With this structure, we are already prepared for non-DRM APIs. Tt's a
 matter of familiarity of code versus future expansion. Code paths for
 both are as simple/complex, so neither has a direct technical
 superiority in performance.
 
 I know other DRM drivers have opted to hard code GEM dependency
 throughout the code. Then again, host1x hardware is managing much more
 than graphics, so we need to think outside the DRM box, too.

This sound a bit over-engineered at this point in time. DRM is currently
the only user. Is anybody working on any non-DRM drivers that would use
this?

Even that aside, I don't think host1x_mem_handle is a good choice of
name here. The objects are much more than handles. They are in fact
buffer objects, which can optionally be attached to a handle. I also
think that using a void * to store the handle specific data isn't such a
good idea.

So how about the following proposal, which I think might satisfy both of
us:

struct host1x_bo;

struct host1x_bo_ops {
struct host1x_bo *(*get)(struct host1x_bo *bo);
void (*put)(struct host1x_bo *bo);
dma_addr_t (*pin)(struct host1x_bo *bo, struct sg_table **sgt);
...
};

struct host1x_bo *host1x_bo_get(struct host1x_bo *bo);
void host1x_bo_put(struct host1x_bo *bo);
dma_addr_t host1x_bo_pin(struct host1x_bo *bo, struct sg_table **sgt);
...

struct host1x_bo {
const struct host1x_bo_ops *ops;
...
};

struct tegra_drm_bo {
struct host1x_bo base;
...
};

That way you can get rid of the host1x_memmgr_create_handle() helper and
instead embed host1x_bo into driver-/framework-specific structures with
the necessary initialization.

It also allows you to interact directly with the objects instead of
having to go through the memmgr API. The memory manager doesn't really
exist anymore so keeping the name in the API is only confusing. Your
current proposal deals with memory handles directly already so it's
really just making the naming more consistent.

Thierry


pgpAZ7oCR9wg0.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCHv5,RESEND 3/8] gpu: host1x: Add channel support

[Terje Bergström]

On 11.03.2013 09:18, Thierry Reding wrote:
 This sound a bit over-engineered at this point in time. DRM is currently
 the only user. Is anybody working on any non-DRM drivers that would use
 this?

Well, this contains beginning of that:

http://nv-tegra.nvidia.com/gitweb/?p=linux-2.6.git;a=blob;f=drivers/media/video/tegra_v4l2_camera.c;h=644d0be5380367aca4c826c49724c03aad08387c;hb=l4t/l4t-r16-r2

I don't want to give these guys any excuse not to port it over to host1x
code base. :-)

 Even that aside, I don't think host1x_mem_handle is a good choice of
 name here. The objects are much more than handles. They are in fact
 buffer objects, which can optionally be attached to a handle. I also
 think that using a void * to store the handle specific data isn't such a
 good idea.

Naming if not an issue for me - we can easily agree on using _bo.

 So how about the following proposal, which I think might satisfy both of
 us:
 
   struct host1x_bo;
 
   struct host1x_bo_ops {
   struct host1x_bo *(*get)(struct host1x_bo *bo);
   void (*put)(struct host1x_bo *bo);
   dma_addr_t (*pin)(struct host1x_bo *bo, struct sg_table **sgt);
   ...
   };
 
   struct host1x_bo *host1x_bo_get(struct host1x_bo *bo);
   void host1x_bo_put(struct host1x_bo *bo);
   dma_addr_t host1x_bo_pin(struct host1x_bo *bo, struct sg_table **sgt);
   ...
 
   struct host1x_bo {
   const struct host1x_bo_ops *ops;
   ...
   };
 
   struct tegra_drm_bo {
   struct host1x_bo base;
   ...
   };
 
 That way you can get rid of the host1x_memmgr_create_handle() helper and
 instead embed host1x_bo into driver-/framework-specific structures with
 the necessary initialization.

This would make sense. We'll get back when we have enough of
implementation done to understand it all. One consequence is that we
cannot use drm_gem_cma_create() anymore. We'll have to introduce a
function that does the same as drm_gem_cma_create(), but it takes a
pre-allocated drm_gem_cma_object pointer. That way we can allocate the
struct, and use DRM CMA just to initialize the drm_gem_cma_object.

Other way would be just taking a copy of DRM CMA helper, but I'd like to
defer that to the next step when we implement IOMMU aware allocator.

 It also allows you to interact directly with the objects instead of
 having to go through the memmgr API. The memory manager doesn't really
 exist anymore so keeping the name in the API is only confusing. Your
 current proposal deals with memory handles directly already so it's
 really just making the naming more consistent.

The memmgr APIs are currently just a shortcut wrapper to the ops, so in
that sense the memmgr does not really exist. I think it might still make
sense to keep static inline wrappers for calling the ops within, but we
could rename them to host1x_bo_somethingandother. Then it'd follow the
pattern we are using for the hw ops in the latest set.

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

Re: [PATCHv5,RESEND 3/8] gpu: host1x: Add channel support

[Thierry Reding]

On Mon, Mar 11, 2013 at 11:21:05AM +0200, Terje Bergström wrote:
 On 11.03.2013 09:18, Thierry Reding wrote:
  This sound a bit over-engineered at this point in time. DRM is currently
  the only user. Is anybody working on any non-DRM drivers that would use
  this?
 
 Well, this contains beginning of that:
 
 http://nv-tegra.nvidia.com/gitweb/?p=linux-2.6.git;a=blob;f=drivers/media/video/tegra_v4l2_camera.c;h=644d0be5380367aca4c826c49724c03aad08387c;hb=l4t/l4t-r16-r2
 
 I don't want to give these guys any excuse not to port it over to host1x
 code base. :-)

I was aware of that driver but I didn't realize it had been available
publicly. It's great to see this, though, and one more argument in
favour of not binding the host1x_bo too tightly to DRM/GEM.

  So how about the following proposal, which I think might satisfy both of
  us:
  
  struct host1x_bo;
  
  struct host1x_bo_ops {
  struct host1x_bo *(*get)(struct host1x_bo *bo);
  void (*put)(struct host1x_bo *bo);
  dma_addr_t (*pin)(struct host1x_bo *bo, struct sg_table **sgt);
  ...
  };
  
  struct host1x_bo *host1x_bo_get(struct host1x_bo *bo);
  void host1x_bo_put(struct host1x_bo *bo);
  dma_addr_t host1x_bo_pin(struct host1x_bo *bo, struct sg_table **sgt);
  ...
  
  struct host1x_bo {
  const struct host1x_bo_ops *ops;
  ...
  };
  
  struct tegra_drm_bo {
  struct host1x_bo base;
  ...
  };
  
  That way you can get rid of the host1x_memmgr_create_handle() helper and
  instead embed host1x_bo into driver-/framework-specific structures with
  the necessary initialization.
 
 This would make sense. We'll get back when we have enough of
 implementation done to understand it all. One consequence is that we
 cannot use drm_gem_cma_create() anymore. We'll have to introduce a
 function that does the same as drm_gem_cma_create(), but it takes a
 pre-allocated drm_gem_cma_object pointer. That way we can allocate the
 struct, and use DRM CMA just to initialize the drm_gem_cma_object.

I certainly think that introducing a drm_gem_cma_object_init() function
shouldn't pose a problem. If you do, make sure to update the existing
drm_gem_cma_create() to use it. Having both lets users have the choice
to use drm_gem_cma_create() if they don't need to embed it, or
drm_gem_cma_object_init() otherwise.

 Other way would be just taking a copy of DRM CMA helper, but I'd like to
 defer that to the next step when we implement IOMMU aware allocator.

I'm not sure I understand what you're saying, but if you add a function
as discussed above this shouldn't be necessary.

  It also allows you to interact directly with the objects instead of
  having to go through the memmgr API. The memory manager doesn't really
  exist anymore so keeping the name in the API is only confusing. Your
  current proposal deals with memory handles directly already so it's
  really just making the naming more consistent.
 
 The memmgr APIs are currently just a shortcut wrapper to the ops, so in
 that sense the memmgr does not really exist. I think it might still make
 sense to keep static inline wrappers for calling the ops within, but we
 could rename them to host1x_bo_somethingandother. Then it'd follow the
 pattern we are using for the hw ops in the latest set.

Yes, that's exactly what I had in mind in the above proposal. They could
be inline, but it's probably also okay if they're not. They aren't meant
to be used very frequently so the extra function call shouldn't matter
much. It might be easier to do add some additional checks if they aren't
inlined. I'm fine either way.

Thierry


pgp7Ra4rYMFfZ.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

re: drm/nouveau: port all engines to new engine module format

[Dan Carpenter]

Hello Ben Skeggs,

The patch ebb945a94bba: drm/nouveau: port all engines to new engine 
module format from Jul 20, 2012, leads to the following warning:
drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c:570 
nvc0_graph_ctor()
 error: buffer overflow 'priv-tpc_nr' 4 = 30

drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c
   566  
   567  priv-rop_nr = (nv_rd32(priv, 0x409604)  0x001f)  16;
   568  priv-gpc_nr =  nv_rd32(priv, 0x409604)  0x001f;

setting this to something between 0 and 0x1f.

   569  for (i = 0; i  priv-gpc_nr; i++) {
   570  priv-tpc_nr[i]  = nv_rd32(priv, GPC_UNIT(i, 0x2608));
^^^
If -gpc_nr is more than 4 we are writing past the end of the array.

   571  priv-tpc_total += priv-tpc_nr[i];
   572  }
   573  

regards,
dan carpenter

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

Re: nouveau shuts the machine down with v3.9-rc1 (temperature (72 C) hit the 'shutdown' threshold).

[Konrad Rzeszutek Wilk]

 With that I am still getting the issues (even with an insance delay of 100 
 seconds).
 Here is the serial log with various runs.

Any thoughts?
 [   13.523878] initcall init_sg+0x0/0x1000 [sg] returned 0 after 5355 usecs
 ^G^G[   13.621376] nouveau  [  PTHERM][:00:0d.0] programmed thresholds [ 
 90(2), 95(3), 145(2), 135(5) ]
 [   13.630487] nouveau 39079] nouveau  [  PTHERM][:00:0d.0] Thermal 
 management: automatic
 [   13.646028] nouveau  [  PTHERM][:00:0d.0] temperature (218 C) hit the 
 'downclock' threshold
 [   13.654702] nouveau  [  PTHERM][:00:0d.0] temperature (218 C) hit the 
 'critical' threshold
 [   13.663296] nouveau  [  PTHERM][:00:0d.0] temperature (218 C) hit the 
 'shutdown' threshold
 [   13.671992] [TTM] Zone  kernel: Available graphics memory: 1963774 kiB

Perhaps I've some insanely stupid BIOS?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (boot/grub2 and suspend/resume) (CAYMAN)

[bugzilla-daemon]

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

Alex Deucher ag...@yahoo.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #53 from Alex Deucher ag...@yahoo.com ---
(In reply to comment #52)
 Also, nice to know: a suspend/resume cycle under Gnome-Shell or KDE will end
 up hung. However, a suspend/resume cycle under XFCE will work correctly.
 
 In other words, the problem seems not to be with the memory controller, but
 with something that as to do with how the OpenGL/3D/else state is being
 restored.

Both use the 3D engine.  The 3D driver uses VM however, so it's probably a
duplicate of bug 60439.

*** This bug has been marked as a duplicate of bug 60439 ***

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

[Bug 60439] Suspend/resume broken for cayman with 90a51a329258e3c868f6

[bugzilla-daemon]

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

Alex Deucher ag...@yahoo.com changed:

   What|Removed |Added

 CC||alexandre.f.dem...@gmail.co
   ||m

--- Comment #8 from Alex Deucher ag...@yahoo.com ---
*** Bug 56139 has been marked as a duplicate of this bug. ***

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

[Bug 60439] Suspend/resume broken for cayman with 90a51a329258e3c868f6

[bugzilla-daemon]

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

--- Comment #9 from Alex Deucher ag...@yahoo.com ---
Does switching to another VT before suspending help?

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

Re: [PATCH] drivers/gpu/drm/tilcdc: Makefile, only -Werror when no -W* in EXTRA_CFLAGS

[Rob Clark]

On Sun, Mar 10, 2013 at 12:04 AM, Chen Gang gang.c...@asianux.com wrote:

   When make with EXTRA_CFLAGS=-W, it will report error.
   so give a check in Makefile.

 Signed-off-by: Chen Gang gang.c...@asianux.com
 Signed-off-by: Vladimir Kondratiev qca_vkond...@qca.qualcomm.com

Signed-off-by: Rob Clark robdcl...@gmail.com

 ---
  drivers/gpu/drm/tilcdc/Makefile |5 -
  1 files changed, 4 insertions(+), 1 deletions(-)

 diff --git a/drivers/gpu/drm/tilcdc/Makefile b/drivers/gpu/drm/tilcdc/Makefile
 index deda656..562733a 100644
 --- a/drivers/gpu/drm/tilcdc/Makefile
 +++ b/drivers/gpu/drm/tilcdc/Makefile
 @@ -1,4 +1,7 @@
 -ccflags-y := -Iinclude/drm -Werror
 +ccflags-y := -Iinclude/drm
 +ifeq (, $(findstring -W,$(EXTRA_CFLAGS)))
 +   ccflags-y += -Werror
 +endif

  tilcdc-y := \
 tilcdc_crtc.o \
 --
 1.7.7.6
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 62170] New: [bisected] R600 LLVM build broken

[bugzilla-daemon]

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

  Priority: medium
Bug ID: 62170
  Assignee: dri-devel@lists.freedesktop.org
   Summary: [bisected] R600 LLVM build broken
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: maxi...@free.fr
  Hardware: Other
Status: NEW
   Version: git
 Component: Drivers/Gallium/r600
   Product: Mesa

Hi,

Here's the error :
r600_shader.c: In function 'r600_shader_from_tgsi':
r600_shader.c:1256:18: error: invalid type argument of '-' (have 'struct
r600_shader_ctx')

4bf0ebdd4fc8dbcab9333ff8805af35a91e6848b is the first bad commit
commit 4bf0ebdd4fc8dbcab9333ff8805af35a91e6848b
Author: Marek Olšák mar...@gmail.com
Date:   Fri Mar 1 16:31:49 2013 +0100

r600g: use a single env var R600_DEBUG, disable bytecode dumping

Only the disassembler is used to dump shaders. Here's a few examples
how to use R600_DEBUG.

Log compute info:
  R600_DEBUG=compute

Dump all shaders:
  R600_DEBUG=fs,vs,gs,ps,cs

Dump pixel shaders only:
  R600_DEBUG=ps

Disable Hyper-Z:
  R600_DEBUG=nohyperz

Disable the LLVM backend:
  R600_DEBUG=nollvm

Or use any combination of the above, or print all options:
  R600_DEBUG=help

Reviewed-by: Tom Stellard thomas.stell...@amd.com

:04 04 faa01df772d30f39d03f80e43b1c588acb8b7060
8e6b4555de797c1736a872780b66ca53d80a736c M  src

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

[Bug 60553] [trine2] wrong colors when executed fullscreen

[bugzilla-daemon]

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

--- Comment #3 from lethar...@gmail.com ---
I can confirm I have the same issue. Works in windowed, colors wrong in
fullscreen, and some objects fail to render completely during gameplay.

Radeon HD 6550D
Mesa 9.1
xf86-video-ati 7.1.0

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

[Bug 62170] [bisected] R600 LLVM build broken

[bugzilla-daemon]

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

--- Comment #1 from maxi...@free.fr ---
Oh, I'm using llvm from SVN at revision 176687 (fairly recent)

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

[Bug 60439] Suspend/resume broken for cayman with 90a51a329258e3c868f6

[bugzilla-daemon]

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

--- Comment #11 from Dmitry Cherkassov dcherkas...@gmail.com ---
Hi.

I can't reproduce this bug on cayman with 3.8-rc3 (using pm-suspend).
Resuming works.

What software do you use? 
I've used xmonad launched via legacy startx while testing that.

Can you fire up a simple twm session without compiz, etc stuff and see how it
goes?
Is it possible to get dmesg output (via serial cable or smth)?

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

[Bug 60439] Suspend/resume broken for cayman with 90a51a329258e3c868f6

[bugzilla-daemon]

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

--- Comment #12 from Alexandre Demers alexandre.f.dem...@gmail.com ---
(In reply to comment #11)
 Hi.
 
 I can't reproduce this bug on cayman with 3.8-rc3 (using pm-suspend).
 Resuming works.
 
 What software do you use? 
 I've used xmonad launched via legacy startx while testing that.
 
 Can you fire up a simple twm session without compiz, etc stuff and see how
 it goes?
 Is it possible to get dmesg output (via serial cable or smth)?

See bug 56139, comments 51 and 52. Suspending/resuming from console or XFCE
don't trigger the bug. However, doing the same under KDE or Gnome-Shell does
exhibit it.

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

[Bug 58372] [KMS][Cayman] Garbled screen and gpu crash with 6950 with drm-next

[bugzilla-daemon]

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

Serkan Hosca ser...@hosca.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #13 from Serkan Hosca ser...@hosca.com ---
This is fixed with 3.8 release and mesa git master

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

Re: [PATCH 1/4] drm/tilcdc: Fix an incorrect condition

[Sachin Kamat]

Hi Rob,

On 2 March 2013 20:40, Rob Clark robdcl...@gmail.com wrote:
 On Sat, Mar 2, 2013 at 5:23 AM, Sachin Kamat sachin.ka...@linaro.org wrote:
 Instead of checking if num_encoders is zero, it is being assigned 0.
 Convert the assignment to a check.

 Signed-off-by: Sachin Kamat sachin.ka...@linaro.org

 Signed-off-by: Rob Clark robdcl...@gmail.com

Just curious. Which tree would these patches be applied to (I mean
your tree or Dave's)?


-- 
With warm regards,
Sachin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4/4] omapdss: features: fixed supported outputs for OMAP4

[Tomi Valkeinen]

On 2013-03-05 16:17, Archit Taneja wrote:
 The support outputs struct for overlay managers is incorrect for OMAP4. Make
 these changes:
 
 - DPI isn't supported via the LCD1 overlay manager, remove DPI as a supported
   output.
 - the TV manager can suppport DPI, but the omapdss driver doesn't support that
   yet, we require some muxing at the DSS level, and we also need to configure
   the hdmi pll in the DPI driver so that the TV manager has a pixel clock. We
   don't support that yet.
 
 Signed-off-by: Archit Taneja arc...@ti.com
 ---
  drivers/video/omap2/dss/dss_features.c |6 ++
  1 file changed, 2 insertions(+), 4 deletions(-)
 
 diff --git a/drivers/video/omap2/dss/dss_features.c 
 b/drivers/video/omap2/dss/dss_features.c
 index d7d66ef..7f791ae 100644
 --- a/drivers/video/omap2/dss/dss_features.c
 +++ b/drivers/video/omap2/dss/dss_features.c
 @@ -202,12 +202,10 @@ static const enum omap_dss_output_id 
 omap3630_dss_supported_outputs[] = {
  
  static const enum omap_dss_output_id omap4_dss_supported_outputs[] = {
   /* OMAP_DSS_CHANNEL_LCD */
 - OMAP_DSS_OUTPUT_DPI | OMAP_DSS_OUTPUT_DBI |
 - OMAP_DSS_OUTPUT_DSI1,
 + OMAP_DSS_OUTPUT_DBI | OMAP_DSS_OUTPUT_DSI1,
  
   /* OMAP_DSS_CHANNEL_DIGIT */
 - OMAP_DSS_OUTPUT_VENC | OMAP_DSS_OUTPUT_HDMI |
 - OMAP_DSS_OUTPUT_DPI,
 + OMAP_DSS_OUTPUT_VENC | OMAP_DSS_OUTPUT_HDMI,
  
   /* OMAP_DSS_CHANNEL_LCD2 */
   OMAP_DSS_OUTPUT_DPI | OMAP_DSS_OUTPUT_DBI |
 

Thanks, I'll apply this to omapdss fixes branch.

 Tomi




signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 62170] [bisected] R600 LLVM build broken

[bugzilla-daemon]

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

maxi...@free.fr changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from maxi...@free.fr ---
resolved in master

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

[Bug 60439] Suspend/resume broken for cayman with 90a51a329258e3c868f6

[bugzilla-daemon]

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

--- Comment #13 from Alex Deucher ag...@yahoo.com ---
Created attachment 76349
  -- https://bugs.freedesktop.org/attachment.cgi?id=76349action=edit
possible fix

This patch should fix the issue.

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

[Bug 57919] Visual glitches in unity with Radeon HD 7600M

[bugzilla-daemon]

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

--- Comment #4 from Thilo Cestonaro th...@cestona.ro ---
Tried with cdimage:
http://cdimages.ubuntu.com/daily-live/20130311/raring-desktop-amd64.iso

Still very ugly glitches!

Please, if I can provide any more details or something, tell me!

I added a glxinfo output again of the version of the used libgl stuff.
Anyway, as it was the livecd boot, I can reproduce it very easily.

Greetings
Thilo

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

[Bug 57919] Visual glitches in unity with Radeon HD 7600M

[bugzilla-daemon]

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

--- Comment #5 from Thilo Cestonaro th...@cestona.ro ---
Created attachment 76350
  -- https://bugs.freedesktop.org/attachment.cgi?id=76350action=edit
LiveCD GlxInfo 03/11/13

another LIBGL_DEBUG=verbose glxinfo output. This time generated by binaries
from the livecd of 03/11/13 of ubuntu raring ringtail.

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

[PATCH V3] get_maintainer: use filename-only regex match for Tegra

[Stephen Warren]

From: Stephen Warren swar...@nvidia.com

Create a new N: entry type in MAINTAINERS which performs a regex match
against filenames; either those extracted from patch +++ or --- lines,
or those specified on the command-line using the -f option.

This provides the same benefits as using a K: regex option to match a
set of filenames (see commit eb90d08 get_maintainer: allow keywords to
match filenames), but without the disadvantage that random file
content, such as comments, will ever match the regex. Hence, revert most
of that commit.

Switch the Tegra entry from using K: to N:

Reported-by: Marcin Slusarz marcin.slus...@gmail.com
Suggested-by: Joe Perches j...@perches.com
Signed-off-by: Stephen Warren swar...@nvidia.com
---
v2: Corrected typo in MAINTAINERS documentation
v3: Squash 3 patches into one.
---
 MAINTAINERS   |   14 --
 scripts/get_maintainer.pl |2 +-
 2 files changed, 9 insertions(+), 7 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 9561658..e68a07a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -90,6 +90,9 @@ Descriptions of section entries:
   F:   drivers/net/*   all files in drivers/net, but not below
   F:   */net/* all files in any top level directory/net
   One pattern per line.  Multiple F: lines acceptable.
+   N: Files and directories with regex patterns.
+  N:   [^a-z]tegra all files whose patch contains the word tegra
+  One pattern per line.  Multiple N: lines acceptable.
X: Files and directories that are NOT maintained, same rules as F:
   Files exclusions are tested before file matches.
   Can be useful for excluding a specific subdirectory, for instance:
@@ -97,13 +100,12 @@ Descriptions of section entries:
   X:   net/ipv6/
   matches all files in and below net excluding net/ipv6/
K: Keyword perl extended regex pattern to match content in a
-  patch or file, or an affected filename.  For instance:
+  patch or file.  For instance:
   K: of_get_profile
- matches patch or file content, or filenames, that contain
- of_get_profile
+ matches patches or files that contain of_get_profile
   K: \b(printk|pr_(info|err))\b
- matches patch or file content, or filenames, that contain one or
- more of the words printk, pr_info or pr_err
+ matches patches or files that contain one or more of the words
+ printk, pr_info or pr_err
   One regex pattern per line.  Multiple K: lines acceptable.
 
 Note: For the hard of thinking, this list is meant to remain in alphabetical
@@ -7848,7 +7850,7 @@ L:linux-te...@vger.kernel.org
 Q: http://patchwork.ozlabs.org/project/linux-tegra/list/
 T: git 
git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git
 S: Supported
-K: (?i)[^a-z]tegra
+N: [^a-z]tegra
 
 TEHUTI ETHERNET DRIVER
 M: Andy Gospodarek a...@greyhouse.net
diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
index ce4cc83..5e4fb14 100755
--- a/scripts/get_maintainer.pl
+++ b/scripts/get_maintainer.pl
@@ -611,7 +611,7 @@ sub get_maintainers {
$hash{$tvi} = $value_pd;
}
}
-   } elsif ($type eq 'K') {
+   } elsif ($type eq 'N') {
if ($file =~ m/$value/x) {
$hash{$tvi} = 0;
}
-- 
1.7.10.4

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