[Bug 50657] [Evergreen,GIT,Tiling?] Occasional invalid command stream and subsequent performance increase

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

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

--- Comment #5 from Thomas Lindroth  2012-06-09 
14:01:11 PDT ---
I tested the patch against 3.5 but it didn't help.

I should also mention that I'm experiencing memory/filesystem corruption but
only when or directly after I've used some opengl app. After filesystem
restoration and reboot everything works fine until the next time I use an
opengl app. I can't say for sure it's graphics related yet but I've ruled out
hardware error in the disk and ram.

I think it was airlied who on irc told me to try a patch in the 3.5 kernel
related to GART but I got the same corruption with 3.5.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] drm/radeon: fix tiling and command stream checking on evergreen v3

[Boszormenyi Zoltan]

2012-06-09 16:57 keltez?ssel, j.glisse at gmail.com ?rta:
> From: Jerome Glisse
>
> Fix regresson since the introduction of command stream checking on
> evergreen (thread referenced below). Issue is cause by ddx allocating
> bo with formula width*height*bpp while programming the GPU command
> stream with ALIGN(height, 8). In some case (where page alignment does
> not hide the extra size bo should be according to height alignment)
> the kernel will reject the command stream.
>
> This patch reprogram the command stream to slice - 1 (slice is
> a derivative value from height) which avoid rejecting the command
> stream while keeping the value of command stream checking from a
> security point of view.
>
> This patch also fix wrong computation of layer size for 2D tiled
> surface. Which should fix issue when 2D color tiling is enabled.
> This dump the radeon KMS_DRIVER_MINOR so userspace can know if
> they are on a fixed kernel or not.
>
> https://lkml.org/lkml/2012/6/3/80
> https://bugs.freedesktop.org/show_bug.cgi?id=50892
> https://bugs.freedesktop.org/show_bug.cgi?id=50857
>
> !!! STABLE need a custom version of this patch for 3.4 !!!
>
> v2: actually bump the minor version and add comment about stable
> v3: do compute the height the ddx was trying to use
>
> Signed-off-by: Jerome Glisse
> ---
>   drivers/gpu/drm/radeon/evergreen_cs.c |   50 
> ++---
>   drivers/gpu/drm/radeon/radeon_drv.c   |3 +-
>   2 files changed, 48 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c 
> b/drivers/gpu/drm/radeon/evergreen_cs.c
> index 4e7dd2b..29c43c6 100644
> --- a/drivers/gpu/drm/radeon/evergreen_cs.c
> +++ b/drivers/gpu/drm/radeon/evergreen_cs.c
> @@ -52,6 +52,7 @@ struct evergreen_cs_track {
>   u32 cb_color_view[12];
>   u32 cb_color_pitch[12];
>   u32 cb_color_slice[12];
> + u32 cb_color_slice_idx[12];
>   u32 cb_color_attrib[12];
>   u32 cb_color_cmask_slice[8];/* unused */
>   u32 cb_color_fmask_slice[8];/* unused */
> @@ -127,12 +128,14 @@ static void evergreen_cs_track_init(struct 
> evergreen_cs_track *track)
>   track->cb_color_info[i] = 0;
>   track->cb_color_view[i] = 0x;
>   track->cb_color_pitch[i] = 0;
> - track->cb_color_slice[i] = 0;
> + track->cb_color_slice[i] = 0xfff;
> + track->cb_color_slice_idx[i] = 0;
>   }
>   track->cb_target_mask = 0x;
>   track->cb_shader_mask = 0x;
>   track->cb_dirty = true;
>
> + track->db_depth_slice = 0x;
>   track->db_depth_view = 0xC000;
>   track->db_depth_size = 0x;
>   track->db_depth_control = 0x;
> @@ -250,10 +253,9 @@ static int evergreen_surface_check_2d(struct 
> radeon_cs_parser *p,
>   {
>   struct evergreen_cs_track *track = p->track;
>   unsigned palign, halign, tileb, slice_pt;
> + unsigned mtile_pr, mtile_ps, mtileb;
>
>   tileb = 64 * surf->bpe * surf->nsamples;
> - palign = track->group_size / (8 * surf->bpe * surf->nsamples);
> - palign = MAX(8, palign);
>   slice_pt = 1;
>   if (tileb>  surf->tsplit) {
>   slice_pt = tileb / surf->tsplit;
> @@ -262,7 +264,10 @@ static int evergreen_surface_check_2d(struct 
> radeon_cs_parser *p,
>   /* macro tile width&  height */
>   palign = (8 * surf->bankw * track->npipes) * surf->mtilea;
>   halign = (8 * surf->bankh * surf->nbanks) / surf->mtilea;
> - surf->layer_size = surf->nbx * surf->nby * surf->bpe * slice_pt;
> + mtileb = (palign / 8) * (halign / 8) * tileb;;
> + mtile_pr = surf->nbx / palign;
> + mtile_ps = (mtile_pr * surf->nby) / halign;
> + surf->layer_size = mtile_ps * mtileb * slice_pt;
>   surf->base_align = (palign / 8) * (halign / 8) * tileb;
>   surf->palign = palign;
>   surf->halign = halign;
> @@ -434,6 +439,39 @@ static int evergreen_cs_track_validate_cb(struct 
> radeon_cs_parser *p, unsigned i
>
>   offset += surf.layer_size * mslice;
>   if (offset>  radeon_bo_size(track->cb_color_bo[id])) {
> + /* old ddx are broken they allocate bo with w*h*bpp but
> +  * program slice with ALIGN(h, 8), catch this and patch
> +  * command stream.
> +  */
> + if (!surf.mode) {
> + volatile u32 *ib = p->ib.ptr;
> + unsigned long tmp, nby, bsize, size, min = 0;
> +
> + /* find the height the ddx wants */
> + if (surf.nby>  8) {
> + min = surf.nby - 8;
> + }
> + bsize = radeon_bo_size(track->cb_color_bo[id]);
> + tmp = track->cb_color_bo_offset[id]<<  8;
> + for (nby = surf.nby; 

[Linaro-mm-sig] [RFC] Synchronizing access to buffers shared with dma-buf between drivers/devices

[Daniel Vetter]

On Sat, Jun 9, 2012 at 12:22 AM, Erik Gilling  wrote:
> The current linux graphics stack does not allow synchronization
> between the GPU and a camera/video decoder. ?When we've seen people
> try to support this behind the scenes, they get it wrong and introduce
> bugs that can take weeks to track down. ?As stated in the previous
> email, one of our goals is to centrally manage synchronization so that
> it's easer for people bringing up a platform to get it right.

I agree that letting everyone reinvent the wheel isn't the best idea
for cross-device sync - people will just get it wrong way too often.
I'm not convinced yet that doing it with explicit sync points/fences
and in userspace is the best solution. dri2/gem all use implicit sync
points managed by the kernel in a transparent fashion, so I'm leaning
towards such a sulotion for cross-device sync, too. Imo the big upside
of such an implicitly sync'ed approach is that it massively simplifies
cross-process protocols (i.e. for the display server).

So to foster understanding of the various requirements and use-cases,
could you elaborate on the pros and cons a bit and explain why you
think explicit sync points managed by the userspace display server is
the best approach for android?

Yours, Daniel
-- 
Daniel Vetter
daniel.vetter at ffwll.ch - +41 (0) 79 364 57 48 - http://blog.ffwll.ch

[Bug 50857] Invalid command stream with CAICOS when ColorTiling2D enabled

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

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

--- Comment #15 from Chris Rankin  2012-06-09 
09:37:40 PDT ---
(In reply to comment #14)
> Updated v3 same url, please test v3 version thx

Yes, this patch (plus compile-fix from #50892) fixes ColorTiling2D support,
thanks.

[3.416710] [drm] Initialized radeon 2.16.0 20080528 for :01:00.0 on minor 0

But it is also spamming my dmesg log with messages like:

[  507.899565] [drm] evergreen_cs_track_validate_depth 688 surface nbx,y (1280
1024) mode 4 format 26 surf.tsplit 64 banks (2 1 1) tilea 1
[  507.974505] [drm] evergreen_cs_track_validate_depth 688 surface nbx,y (1280
1024) mode 4 format 26 surf.tsplit 64 banks (2 1 1) tilea 1
[  508.135274] [drm] evergreen_cs_track_validate_depth 688 surface nbx,y (1280
1024) mode 4 format 26 surf.tsplit 64 banks (2 1 1) tilea 1
[  508.152312] [drm] evergreen_cs_track_validate_depth 688 surface nbx,y (1280
1024) mode 4 format 26 surf.tsplit 64 banks (2 1 1) tilea 1
[  508.169122] [drm] evergreen_cs_track_validate_depth 688 surface nbx,y (1280
1024) mode 4 format 26 surf.tsplit 64 banks (2 1 1) tilea 1

I'm guessing that this from is the extra DRM_INFO() statement, which I shall be
removing immediately...

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 46713] HDMI audio played back at a wrong rate

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

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

--- Comment #29 from Christian K?nig  2012-06-09 
08:33:50 PDT ---
Yeah, the audio rate is controlled by the last output changed.

We should switch to another output if the output driving the audio signal is
turned off.

It's on the todo list.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] drm/radeon: fix tiling and command stream checking on evergreen v3

[Jerome Glisse]

On Sat, Jun 9, 2012 at 12:15 PM, Boszormenyi Zoltan  wrote:
> 2012-06-09 16:57 keltez?ssel, j.glisse at gmail.com ?rta:
>>
>> From: Jerome Glisse
>>
>> Fix regresson since the introduction of command stream checking on
>> evergreen (thread referenced below). Issue is cause by ddx allocating
>> bo with formula width*height*bpp while programming the GPU command
>> stream with ALIGN(height, 8). In some case (where page alignment does
>> not hide the extra size bo should be according to height alignment)
>> the kernel will reject the command stream.
>>
>> This patch reprogram the command stream to slice - 1 (slice is
>> a derivative value from height) which avoid rejecting the command
>> stream while keeping the value of command stream checking from a
>> security point of view.
>>
>> This patch also fix wrong computation of layer size for 2D tiled
>> surface. Which should fix issue when 2D color tiling is enabled.
>> This dump the radeon KMS_DRIVER_MINOR so userspace can know if
>> they are on a fixed kernel or not.
>>
>> https://lkml.org/lkml/2012/6/3/80
>> https://bugs.freedesktop.org/show_bug.cgi?id=50892
>> https://bugs.freedesktop.org/show_bug.cgi?id=50857
>>
>> !!! STABLE need a custom version of this patch for 3.4 !!!
>>
>> v2: actually bump the minor version and add comment about stable
>> v3: do compute the height the ddx was trying to use
>>
>> Signed-off-by: Jerome Glisse
>> ---
>> ?drivers/gpu/drm/radeon/evergreen_cs.c | ? 50
>> ++---
>> ?drivers/gpu/drm/radeon/radeon_drv.c ? | ? ?3 +-
>> ?2 files changed, 48 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c
>> b/drivers/gpu/drm/radeon/evergreen_cs.c
>> index 4e7dd2b..29c43c6 100644
>> --- a/drivers/gpu/drm/radeon/evergreen_cs.c
>> +++ b/drivers/gpu/drm/radeon/evergreen_cs.c
>> @@ -52,6 +52,7 @@ struct evergreen_cs_track {
>> ? ? ? ?u32 ? ? ? ? ? ? ? ? ? ? cb_color_view[12];
>> ? ? ? ?u32 ? ? ? ? ? ? ? ? ? ? cb_color_pitch[12];
>> ? ? ? ?u32 ? ? ? ? ? ? ? ? ? ? cb_color_slice[12];
>> + ? ? ? u32 ? ? ? ? ? ? ? ? ? ? cb_color_slice_idx[12];
>> ? ? ? ?u32 ? ? ? ? ? ? ? ? ? ? cb_color_attrib[12];
>> ? ? ? ?u32 ? ? ? ? ? ? ? ? ? ? cb_color_cmask_slice[8];/* unused */
>> ? ? ? ?u32 ? ? ? ? ? ? ? ? ? ? cb_color_fmask_slice[8];/* unused */
>> @@ -127,12 +128,14 @@ static void evergreen_cs_track_init(struct
>> evergreen_cs_track *track)
>> ? ? ? ? ? ? ? ?track->cb_color_info[i] = 0;
>> ? ? ? ? ? ? ? ?track->cb_color_view[i] = 0x;
>> ? ? ? ? ? ? ? ?track->cb_color_pitch[i] = 0;
>> - ? ? ? ? ? ? ? track->cb_color_slice[i] = 0;
>> + ? ? ? ? ? ? ? track->cb_color_slice[i] = 0xfff;
>> + ? ? ? ? ? ? ? track->cb_color_slice_idx[i] = 0;
>> ? ? ? ?}
>> ? ? ? ?track->cb_target_mask = 0x;
>> ? ? ? ?track->cb_shader_mask = 0x;
>> ? ? ? ?track->cb_dirty = true;
>>
>> + ? ? ? track->db_depth_slice = 0x;
>> ? ? ? ?track->db_depth_view = 0xC000;
>> ? ? ? ?track->db_depth_size = 0x;
>> ? ? ? ?track->db_depth_control = 0x;
>> @@ -250,10 +253,9 @@ static int evergreen_surface_check_2d(struct
>> radeon_cs_parser *p,
>> ?{
>> ? ? ? ?struct evergreen_cs_track *track = p->track;
>> ? ? ? ?unsigned palign, halign, tileb, slice_pt;
>> + ? ? ? unsigned mtile_pr, mtile_ps, mtileb;
>>
>> ? ? ? ?tileb = 64 * surf->bpe * surf->nsamples;
>> - ? ? ? palign = track->group_size / (8 * surf->bpe * surf->nsamples);
>> - ? ? ? palign = MAX(8, palign);
>> ? ? ? ?slice_pt = 1;
>> ? ? ? ?if (tileb> ?surf->tsplit) {
>> ? ? ? ? ? ? ? ?slice_pt = tileb / surf->tsplit;
>> @@ -262,7 +264,10 @@ static int evergreen_surface_check_2d(struct
>> radeon_cs_parser *p,
>> ? ? ? ?/* macro tile width& ?height */
>>
>> ? ? ? ?palign = (8 * surf->bankw * track->npipes) * surf->mtilea;
>> ? ? ? ?halign = (8 * surf->bankh * surf->nbanks) / surf->mtilea;
>> - ? ? ? surf->layer_size = surf->nbx * surf->nby * surf->bpe * slice_pt;
>> + ? ? ? mtileb = (palign / 8) * (halign / 8) * tileb;;
>> + ? ? ? mtile_pr = surf->nbx / palign;
>> + ? ? ? mtile_ps = (mtile_pr * surf->nby) / halign;
>> + ? ? ? surf->layer_size = mtile_ps * mtileb * slice_pt;
>> ? ? ? ?surf->base_align = (palign / 8) * (halign / 8) * tileb;
>> ? ? ? ?surf->palign = palign;
>> ? ? ? ?surf->halign = halign;
>> @@ -434,6 +439,39 @@ static int evergreen_cs_track_validate_cb(struct
>> radeon_cs_parser *p, unsigned i
>>
>> ? ? ? ?offset += surf.layer_size * mslice;
>> ? ? ? ?if (offset> ?radeon_bo_size(track->cb_color_bo[id])) {
>> + ? ? ? ? ? ? ? /* old ddx are broken they allocate bo with w*h*bpp but
>> + ? ? ? ? ? ? ? ?* program slice with ALIGN(h, 8), catch this and patch
>> + ? ? ? ? ? ? ? ?* command stream.
>> + ? ? ? ? ? ? ? ?*/
>> + ? ? ? ? ? ? ? if (!surf.mode) {
>> + ? ? ? ? ? ? ? ? ? ? ? volatile u32 *ib = p->ib.ptr;
>> + ? ? ? ? ? ? ? ? ? ? ? unsigned long tmp, nby, bsize, size, min = 0;
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? /* find the height the ddx wants */
>> + ? ? ? ? ? ? ? ? ? ? ? if (surf.nby> ?8) {
>> + ? ? ? ? ? ? ? ? ? ? ? 

[Bug 46713] HDMI audio played back at a wrong rate

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

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

--- Comment #28 from Vincenzov  2012-06-09 08:11:05 
PDT ---
kernel 3.5.0-rc2 audio workgood.
i have 2 monitor hdmi, after I changed the initial resolution of the monitor
works fine 2.
example

1 monitor 1920 x 1080 works
2 monitor 1920 x 1080 works.

after i turn off monitor 1, audio monitor 2 slow.
configure monitor 2 and after all audio works good 1 & 2.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 50657] [Evergreen,GIT,Tiling?] Occasional invalid command stream and subsequent performance increase

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

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

--- Comment #4 from Jerome Glisse  2012-06-09 
07:36:43 PDT ---
Does kernel patch: (apply against 3.5 but need a small diff for 3.4) helps

http://people.freedesktop.org/~glisse/0001-drm-radeon-fix-tiling-and-command-stream-checking-on.patch

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] RFC drm: Do not leak connector_status_unknown to userspace

[Daniel Vetter]

On Sat, Jun 09, 2012 at 12:24:49AM +0100, Chris Wilson wrote:
> A detect() probe may return 'unknown' to indicate that it was not able
> to successfully determine the connector status. However, exposing this
> to userspace just results in lots of confusion as it is uncertain
> whether or not that is a valid connection. The usual result is for X to
> create a mode that encompasses the unknown connector causing an abnormal
> setup on the known good outputs.
> 
> This patch initialises the connector status to disconnected and
> thereafter ignores indeterminate results from detect(), leaving the
> status as the old value. This prevents the status from being set to
> unknown, and so leaked to userspace, and so leaves the connector as
> disconnected until we have a valid connection and also prevents that
> valid connection being dropped due to a failed probe.
> 
> The alternative to this is to never return unknown from the drivers, but
> return connector->status instead so that the value never changes on a
> failed probe (and also to initialise the connector to disconnected in
> the driver).

Hm, this is a bit at odds with how I've re-defined unknown in my hpd
rework. There it essentially means that that the kernel truely has no idea
what the status is because the world changed (i.e. resume or fresh boot)
and detect hasn't been run yet. So imo we should initialize the connector
state to unknown (and reset it to unknown after resume).

I agree with the 'not leaking unknown' to userspace, although I'm unsure
about the implications. I guess we just have to try and see what happens.

Yours, Daniel
> ---
>  drivers/gpu/drm/drm_crtc.c|1 +
>  drivers/gpu/drm/drm_crtc_helper.c |   20 +---
>  2 files changed, 14 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 08a7aa7..22f58b9 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -495,6 +495,7 @@ int drm_connector_init(struct drm_device *dev,
>   INIT_LIST_HEAD(>probed_modes);
>   INIT_LIST_HEAD(>modes);
>   connector->edid_blob_ptr = NULL;
> + connector->status = connector_status_disconnected;
>  
>   list_add_tail(>head, >mode_config.connector_list);
>   dev->mode_config.num_connector++;
> diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
> b/drivers/gpu/drm/drm_crtc_helper.c
> index 3252e70..143d6d5 100644
> --- a/drivers/gpu/drm/drm_crtc_helper.c
> +++ b/drivers/gpu/drm/drm_crtc_helper.c
> @@ -108,7 +108,11 @@ int drm_helper_probe_single_connector_modes(struct 
> drm_connector *connector,
>   if (connector->funcs->force)
>   connector->funcs->force(connector);
>   } else {
> - connector->status = connector->funcs->detect(connector, true);
> + enum drm_connector_status status;
> +
> + status = connector->funcs->detect(connector, true);
> + if (status)
> + connector->status = status;
>   drm_kms_helper_poll_enable(dev);
>   }
>  
> @@ -949,13 +953,15 @@ static void output_poll_execute(struct work_struct 
> *work)
>   !(connector->polled & DRM_CONNECTOR_POLL_HPD))
>   continue;
>  
> - connector->status = connector->funcs->detect(connector, false);
> - DRM_DEBUG_KMS("[CONNECTOR:%d:%s] status updated from %d to 
> %d\n",
> -   connector->base.id,
> -   drm_get_connector_name(connector),
> -   old_status, connector->status);
> - if (old_status != connector->status)
> + new_status = connector->funcs->detect(connector, false);
> + if (new_status && old_status != new_status) {
> + DRM_DEBUG_KMS("[CONNECTOR:%d:%s] status updated from %d 
> to %d\n",
> +   connector->base.id,
> +   drm_get_connector_name(connector),
> +   old_status, new_status);
> + connector->status = new_status;
>   changed = true;
> + }
>   }
>  
>   mutex_unlock(>mode_config.mutex);
> -- 
> 1.7.10
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[Bug 50696] HDMI Audio is Choppy on RS880M / 4200

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

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

--- Comment #2 from Rafa? Mi?ecki  2012-06-09 06:47:32 PDT 
---
Mike: have you tried applying referenced patch?
It is included in kernel 3.5-rc2 so you can just try updating as well.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[alsa-devel] [PATCH 0/2] HD-audio HDMI regression fixes with VGA-switcheroo

[Takashi Iwai]

At Sat, 9 Jun 2012 08:57:20 +0100,
Dave Airlie wrote:
> 
> > Good to hear.
> > Dave, is it OK to apply the patch below through sound tree?
> 
> ack below,
> >
> >
> > thanks,
> >
> > Takashi
> >
> > ---
> > From: Takashi Iwai 
> > Subject: [PATCH] vga_switcheroo: Enable/disable audio clients at the right 
> > time
> >
> > The audio clients have to be disabled before disabling the VGA and
> > switching. ?Similarly, enabling the audio client should be done at
> > last. ?Otherwise the audio-side operation stalls, eventually leading
> > to Oops or lockups.
> >
> > Tested-by: J?rg-Volker Peetz 
> 
> Acked-by: Dave Airlie 

Thanks!


Takashi

[Bug 50892] Invalid command stream with TURKS running Cinnamon

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

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

--- Comment #12 from Zolt?n B?sz?rm?nyi  2012-06-09 04:06:07 
PDT ---
Created attachment 62845
  --> https://bugs.freedesktop.org/attachment.cgi?id=62845
Xorg.0.log on my notebook with kernel 3.4.1 + radeon tiling fix v3 + one liner
patch

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 50892] Invalid command stream with TURKS running Cinnamon

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

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

--- Comment #11 from Zolt?n B?sz?rm?nyi  2012-06-09 04:05:34 
PDT ---
Created attachment 62844
  --> https://bugs.freedesktop.org/attachment.cgi?id=62844
dmesg from my notebook with 3.4.1 + tiling fix v3 + the one liner patch

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] drm/radeon: fix tiling and command stream checking on evergreen v3

[j.gli...@gmail.com]

From: Jerome Glisse 

Fix regresson since the introduction of command stream checking on
evergreen (thread referenced below). Issue is cause by ddx allocating
bo with formula width*height*bpp while programming the GPU command
stream with ALIGN(height, 8). In some case (where page alignment does
not hide the extra size bo should be according to height alignment)
the kernel will reject the command stream.

This patch reprogram the command stream to slice - 1 (slice is
a derivative value from height) which avoid rejecting the command
stream while keeping the value of command stream checking from a
security point of view.

This patch also fix wrong computation of layer size for 2D tiled
surface. Which should fix issue when 2D color tiling is enabled.
This dump the radeon KMS_DRIVER_MINOR so userspace can know if
they are on a fixed kernel or not.

https://lkml.org/lkml/2012/6/3/80
https://bugs.freedesktop.org/show_bug.cgi?id=50892
https://bugs.freedesktop.org/show_bug.cgi?id=50857

!!! STABLE need a custom version of this patch for 3.4 !!!

v2: actually bump the minor version and add comment about stable
v3: do compute the height the ddx was trying to use

Signed-off-by: Jerome Glisse 
---
 drivers/gpu/drm/radeon/evergreen_cs.c |   50 ++---
 drivers/gpu/drm/radeon/radeon_drv.c   |3 +-
 2 files changed, 48 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c 
b/drivers/gpu/drm/radeon/evergreen_cs.c
index 4e7dd2b..29c43c6 100644
--- a/drivers/gpu/drm/radeon/evergreen_cs.c
+++ b/drivers/gpu/drm/radeon/evergreen_cs.c
@@ -52,6 +52,7 @@ struct evergreen_cs_track {
u32 cb_color_view[12];
u32 cb_color_pitch[12];
u32 cb_color_slice[12];
+   u32 cb_color_slice_idx[12];
u32 cb_color_attrib[12];
u32 cb_color_cmask_slice[8];/* unused */
u32 cb_color_fmask_slice[8];/* unused */
@@ -127,12 +128,14 @@ static void evergreen_cs_track_init(struct 
evergreen_cs_track *track)
track->cb_color_info[i] = 0;
track->cb_color_view[i] = 0x;
track->cb_color_pitch[i] = 0;
-   track->cb_color_slice[i] = 0;
+   track->cb_color_slice[i] = 0xfff;
+   track->cb_color_slice_idx[i] = 0;
}
track->cb_target_mask = 0x;
track->cb_shader_mask = 0x;
track->cb_dirty = true;

+   track->db_depth_slice = 0x;
track->db_depth_view = 0xC000;
track->db_depth_size = 0x;
track->db_depth_control = 0x;
@@ -250,10 +253,9 @@ static int evergreen_surface_check_2d(struct 
radeon_cs_parser *p,
 {
struct evergreen_cs_track *track = p->track;
unsigned palign, halign, tileb, slice_pt;
+   unsigned mtile_pr, mtile_ps, mtileb;

tileb = 64 * surf->bpe * surf->nsamples;
-   palign = track->group_size / (8 * surf->bpe * surf->nsamples);
-   palign = MAX(8, palign);
slice_pt = 1;
if (tileb > surf->tsplit) {
slice_pt = tileb / surf->tsplit;
@@ -262,7 +264,10 @@ static int evergreen_surface_check_2d(struct 
radeon_cs_parser *p,
/* macro tile width & height */
palign = (8 * surf->bankw * track->npipes) * surf->mtilea;
halign = (8 * surf->bankh * surf->nbanks) / surf->mtilea;
-   surf->layer_size = surf->nbx * surf->nby * surf->bpe * slice_pt;
+   mtileb = (palign / 8) * (halign / 8) * tileb;;
+   mtile_pr = surf->nbx / palign;
+   mtile_ps = (mtile_pr * surf->nby) / halign;
+   surf->layer_size = mtile_ps * mtileb * slice_pt;
surf->base_align = (palign / 8) * (halign / 8) * tileb;
surf->palign = palign;
surf->halign = halign;
@@ -434,6 +439,39 @@ static int evergreen_cs_track_validate_cb(struct 
radeon_cs_parser *p, unsigned i

offset += surf.layer_size * mslice;
if (offset > radeon_bo_size(track->cb_color_bo[id])) {
+   /* old ddx are broken they allocate bo with w*h*bpp but
+* program slice with ALIGN(h, 8), catch this and patch
+* command stream.
+*/
+   if (!surf.mode) {
+   volatile u32 *ib = p->ib.ptr;
+   unsigned long tmp, nby, bsize, size, min = 0;
+
+   /* find the height the ddx wants */
+   if (surf.nby > 8) {
+   min = surf.nby - 8;
+   }
+   bsize = radeon_bo_size(track->cb_color_bo[id]);
+   tmp = track->cb_color_bo_offset[id] << 8;
+   for (nby = surf.nby; nby > min; nby--) {
+   size = nby * surf.nbx * surf.bpe * 
surf.nsamples;
+   if 

[Bug 50892] Invalid command stream with TURKS running Cinnamon

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

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

--- Comment #9 from Zolt?n B?sz?rm?nyi  2012-06-09 03:46:57 
PDT ---
Created attachment 62843
  --> https://bugs.freedesktop.org/attachment.cgi?id=62843
Xorg.0.log on my deskop with kernel 3.4.1 + radeon tiling fix v3 + one liner
patch

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 50892] Invalid command stream with TURKS running Cinnamon

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

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

--- Comment #8 from Zolt?n B?sz?rm?nyi  2012-06-09 03:46:04 
PDT ---
Created attachment 62842
  --> https://bugs.freedesktop.org/attachment.cgi?id=62842
dmesg from my desktop machine with 3.4.1 + tiling fix v3 + the one liner patch

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 50892] Invalid command stream with TURKS running Cinnamon

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

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

--- Comment #7 from Zolt?n B?sz?rm?nyi  2012-06-09 03:43:39 
PDT ---
It seems this patch fixed the "invalid command stream error". Thanks very much.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[alsa-devel] [PATCH 0/2] HD-audio HDMI regression fixes with VGA-switcheroo

[Dave Airlie]

> Good to hear.
> Dave, is it OK to apply the patch below through sound tree?

ack below,
>
>
> thanks,
>
> Takashi
>
> ---
> From: Takashi Iwai 
> Subject: [PATCH] vga_switcheroo: Enable/disable audio clients at the right 
> time
>
> The audio clients have to be disabled before disabling the VGA and
> switching. ?Similarly, enabling the audio client should be done at
> last. ?Otherwise the audio-side operation stalls, eventually leading
> to Oops or lockups.
>
> Tested-by: J?rg-Volker Peetz 

Acked-by: Dave Airlie 

> Signed-off-by: Takashi Iwai 
> ---
> ?drivers/gpu/vga/vga_switcheroo.c | ? 14 --
> ?1 file changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/vga/vga_switcheroo.c 
> b/drivers/gpu/vga/vga_switcheroo.c
> index 38f9534..e24ad99 100644
> --- a/drivers/gpu/vga/vga_switcheroo.c
> +++ b/drivers/gpu/vga/vga_switcheroo.c
> @@ -291,8 +291,6 @@ static int vga_switchto_stage1(struct 
> vga_switcheroo_client *new_client)
> ? ? ? ? ? ? ? ?vga_switchon(new_client);
>
> ? ? ? ?vga_set_default_device(new_client->pdev);
> - ? ? ? set_audio_state(new_client->id, VGA_SWITCHEROO_ON);
> -
> ? ? ? ?return 0;
> ?}
>
> @@ -308,6 +306,8 @@ static int vga_switchto_stage2(struct 
> vga_switcheroo_client *new_client)
>
> ? ? ? ?active->active = false;
>
> + ? ? ? set_audio_state(active->id, VGA_SWITCHEROO_OFF);
> +
> ? ? ? ?if (new_client->fb_info) {
> ? ? ? ? ? ? ? ?struct fb_event event;
> ? ? ? ? ? ? ? ?event.info = new_client->fb_info;
> @@ -321,11 +321,11 @@ static int vga_switchto_stage2(struct 
> vga_switcheroo_client *new_client)
> ? ? ? ?if (new_client->ops->reprobe)
> ? ? ? ? ? ? ? ?new_client->ops->reprobe(new_client->pdev);
>
> - ? ? ? set_audio_state(active->id, VGA_SWITCHEROO_OFF);
> -
> ? ? ? ?if (active->pwr_state == VGA_SWITCHEROO_ON)
> ? ? ? ? ? ? ? ?vga_switchoff(active);
>
> + ? ? ? set_audio_state(new_client->id, VGA_SWITCHEROO_ON);
> +
> ? ? ? ?new_client->active = true;
> ? ? ? ?return 0;
> ?}
> @@ -371,8 +371,9 @@ vga_switcheroo_debugfs_write(struct file *filp, const 
> char __user *ubuf,
> ? ? ? ?/* pwr off the device not in use */
> ? ? ? ?if (strncmp(usercmd, "OFF", 3) == 0) {
> ? ? ? ? ? ? ? ?list_for_each_entry(client, _priv.clients, list) {
> - ? ? ? ? ? ? ? ? ? ? ? if (client->active)
> + ? ? ? ? ? ? ? ? ? ? ? if (client->active || client_is_audio(client))
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?continue;
> + ? ? ? ? ? ? ? ? ? ? ? set_audio_state(client->id, VGA_SWITCHEROO_OFF);
> ? ? ? ? ? ? ? ? ? ? ? ?if (client->pwr_state == VGA_SWITCHEROO_ON)
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?vga_switchoff(client);
> ? ? ? ? ? ? ? ?}
> @@ -381,10 +382,11 @@ vga_switcheroo_debugfs_write(struct file *filp, const 
> char __user *ubuf,
> ? ? ? ?/* pwr on the device not in use */
> ? ? ? ?if (strncmp(usercmd, "ON", 2) == 0) {
> ? ? ? ? ? ? ? ?list_for_each_entry(client, _priv.clients, list) {
> - ? ? ? ? ? ? ? ? ? ? ? if (client->active)
> + ? ? ? ? ? ? ? ? ? ? ? if (client->active || client_is_audio(client))
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?continue;
> ? ? ? ? ? ? ? ? ? ? ? ?if (client->pwr_state == VGA_SWITCHEROO_OFF)
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?vga_switchon(client);
> + ? ? ? ? ? ? ? ? ? ? ? set_audio_state(client->id, VGA_SWITCHEROO_ON);
> ? ? ? ? ? ? ? ?}
> ? ? ? ? ? ? ? ?goto out;
> ? ? ? ?}
> --
> 1.7.10.4
>
> ___
> Alsa-devel mailing list
> Alsa-devel at alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

[PATCH 0/2] HD-audio HDMI regression fixes with VGA-switcheroo

[Takashi Iwai]

At Fri, 08 Jun 2012 22:17:29 +0200,
J?rg-Volker Peetz wrote:
> 
> Takashi Iwai wrote, on 06/08/12 17:52:
> > At Fri, 08 Jun 2012 17:45:17 +0200,
> > J?rg-Volker Peetz wrote:
> >>
> >> Hello Takashi,
> >>
> >> Takashi Iwai wrote, on 06/08/12 15:03:
> >>> At Fri, 08 Jun 2012 13:26:57 +0200,
> >>> J?rg-Volker Peetz wrote:
> 
>  Takashi Iwai wrote, on 06/07/12 12:15:
> > Hi,
> >
> > this is a series of patches to fix the regressions of HD-audio HDMI
> > on D-GPUs in 3.5-rc1 due to the support of VGA-switcheroo audio clients.
> >
> > The first patch adds a new helper function to vga-switcheroo and the
> > second just uses that instead of an open code.
> >
> > Dave, if the first patch is OK, I'm going to apply it though sound tree.
> > Let me know if any problem is found.
> >
> > Joerg, could you check whether this doesn't break your setup, too?
> >
> >
> > thanks,
> >
> > Takashi
> 
>  Hello Takashi,
> 
>  I applied both your patches on 3.5-rc1. With this kernel I made three 
>  tests.
>  1) After booting I switched off the discrete GPU via vga_switcheroo.
> Then ca. 210 times the message
> 
>   hda-intel: spurious response 0x0:0x0, last cmd=0x170503
> 
> appears on the console and in the logs.
> Starting X and using the built-in USB web-cam work, as well as sound 
>  with
> mplayer2 works.
> 
>  2) After booting I switched to the discrete GPU via
> 
>   echo -n DDIS > /sys/kernel/debugfs/vgaswitcheroo/switch
> 
> Then I started X via startx. The desktop screen appears but the system
> freezes. No reaction on keyboard or touchpad input. The computer is 
>  not
> reachable via ethernet wire.
> >>>
> >>> Hm, these issues aren't seen on 3.5-rc1 before my patches?
> >>> If so, we need to fix now.
> >>>
> >> No, these issues aren't seen on 3.5-rc1 without your patches. I'm able to 
> >> start
> >> X with the discrete GPU in use, direct rendering and the built-in USB 
> >> camera work.
> > 
> > OK, it means that the switching from the audio-ON to audio-OFF doesn't
> > work.  Could you try the patch below in additon?
> > 
> 
> Applying all your three patches on 3.5-rc1 makes the discrete GPU work on my
> system: after mounting debugfs and switching to "DDIS", I can start X and 
> direct
> rendering, sound and built-in USB camera work.

Good to hear.
Dave, is it OK to apply the patch below through sound tree?


thanks,

Takashi

---
From: Takashi Iwai 
Subject: [PATCH] vga_switcheroo: Enable/disable audio clients at the right time

The audio clients have to be disabled before disabling the VGA and
switching.  Similarly, enabling the audio client should be done at
last.  Otherwise the audio-side operation stalls, eventually leading
to Oops or lockups.

Tested-by: J?rg-Volker Peetz 
Signed-off-by: Takashi Iwai 
---
 drivers/gpu/vga/vga_switcheroo.c |   14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga/vga_switcheroo.c
index 38f9534..e24ad99 100644
--- a/drivers/gpu/vga/vga_switcheroo.c
+++ b/drivers/gpu/vga/vga_switcheroo.c
@@ -291,8 +291,6 @@ static int vga_switchto_stage1(struct vga_switcheroo_client 
*new_client)
vga_switchon(new_client);

vga_set_default_device(new_client->pdev);
-   set_audio_state(new_client->id, VGA_SWITCHEROO_ON);
-
return 0;
 }

@@ -308,6 +306,8 @@ static int vga_switchto_stage2(struct vga_switcheroo_client 
*new_client)

active->active = false;

+   set_audio_state(active->id, VGA_SWITCHEROO_OFF);
+
if (new_client->fb_info) {
struct fb_event event;
event.info = new_client->fb_info;
@@ -321,11 +321,11 @@ static int vga_switchto_stage2(struct 
vga_switcheroo_client *new_client)
if (new_client->ops->reprobe)
new_client->ops->reprobe(new_client->pdev);

-   set_audio_state(active->id, VGA_SWITCHEROO_OFF);
-
if (active->pwr_state == VGA_SWITCHEROO_ON)
vga_switchoff(active);

+   set_audio_state(new_client->id, VGA_SWITCHEROO_ON);
+
new_client->active = true;
return 0;
 }
@@ -371,8 +371,9 @@ vga_switcheroo_debugfs_write(struct file *filp, const char 
__user *ubuf,
/* pwr off the device not in use */
if (strncmp(usercmd, "OFF", 3) == 0) {
list_for_each_entry(client, _priv.clients, list) {
-   if (client->active)
+   if (client->active || client_is_audio(client))
continue;
+   set_audio_state(client->id, VGA_SWITCHEROO_OFF);
if (client->pwr_state == VGA_SWITCHEROO_ON)
vga_switchoff(client);
}
@@ -381,10 +382,11 @@ vga_switcheroo_debugfs_write(struct file 

[Bug 50892] Invalid command stream with TURKS running Cinnamon

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

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

--- Comment #6 from Zolt?n B?sz?rm?nyi  2012-06-09 01:44:38 
PDT ---
Tried to compile v3 on vanilla 3.4.1 but it failed:

  CC [M]  drivers/gpu/drm/radeon/evergreen_cs.o
drivers/gpu/drm/radeon/evergreen_cs.c: In function
?evergreen_cs_track_validate_cb?:
drivers/gpu/drm/radeon/evergreen_cs.c:447:28: error: request for member ?ptr?
in something not a structure or union
make[4]: *** [drivers/gpu/drm/radeon/evergreen_cs.o] Error 1
make[3]: *** [drivers/gpu/drm/radeon] Error 2
make[2]: *** [drivers/gpu/drm] Error 2
make[1]: *** [drivers/gpu] Error 2
make: *** [drivers] Error 2

This one-liner over your patch fixes the compilation:

--- drivers/gpu/drm/radeon/evergreen_cs.c~2012-06-09 08:51:34.0
+0200
+++ drivers/gpu/drm/radeon/evergreen_cs.c2012-06-09 10:42:29.054351410
+0200
@@ -444,7 +444,7 @@
  * command stream.
  */
 if (!surf.mode) {
-volatile u32 *ib = p->ib.ptr;
+volatile u32 *ib = p->ib->ptr;
 unsigned long tmp, nby, bsize, size, min = 0;

 /* find the height the ddx wants */

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 46713] HDMI audio played back at a wrong rate

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

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

--- Comment #30 from Vincenzov  2012-06-09 08:38:39 
UTC ---
thanks Christian K?nig and Rafa? Mi?ecki for this work.
Sorry my english is bad, i speak only italian :-).

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Linaro-mm-sig] [RFC] Synchronizing access to buffers shared with dma-buf between drivers/devices

[Clark, Rob]

On Fri, Jun 8, 2012 at 3:56 PM, Erik Gilling  wrote:
>> I guess my other thought is that implicit vs explicit is not
>> mutually exclusive, though I'd guess there'd be interesting
>> deadlocks to have to debug if both were in use _at the same
>> time_. :-)
>
> I think this is an approach worth investigating. ?I'd like a way to
> either opt out of implicit sync or have a way to check if a dma-buf
> has an attached fence and detach it. ?Actually, that could work really
> well. Consider:
>
> * Each dma_buf has a single fence "slot"
> * on submission
> ? * the driver will extract the fence from the dma_buf and queue a wait on it.
> ? * the driver will replace that fence with it's own complettion
> fence before the job submission ioctl returns.
> * dma_buf will have two userspace ioctls:
> ? * DETACH: will return the fence as an FD to userspace and clear the
> fence slot in the dma_buf
> ? * ATTACH: takes a fence FD from userspace and attaches it to the
> dma_buf fence slot. ?Returns an error if the fence slot is non-empty.
>
> In the android case, we can do a detach after every submission and an
> attach right before.

btw, I like this idea for implicit and explicit sync to coexist

BR,
-R

[Bug 50657] [Evergreen,GIT,Tiling?] Occasional invalid command stream and subsequent performance increase

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

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

--- Comment #3 from Thomas Lindroth  2012-06-09 
01:34:49 PDT ---
Disregard the previous comment. I forgot Psychonauts is 32bit and therefor
don't use my git drivers automatically. There is nothing wrong with it but the
first comment still apply.

Turning off ColorTiling2D or using a blank xorg.conf makes no difference. The
problem is the same on kernel 3.3 except there is no error in dmesg. It just
fails to render anything.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 50892] Invalid command stream with TURKS running Cinnamon

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

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

--- Comment #10 from Zolt?n B?sz?rm?nyi  2012-06-09 04:02:11 
UTC ---
Fixed on the notebook with A4-3300 CPU too. Thanks very very much.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] RFC drm: Do not leak connector_status_unknown to userspace

[Chris Wilson]

A detect() probe may return 'unknown' to indicate that it was not able
to successfully determine the connector status. However, exposing this
to userspace just results in lots of confusion as it is uncertain
whether or not that is a valid connection. The usual result is for X to
create a mode that encompasses the unknown connector causing an abnormal
setup on the known good outputs.

This patch initialises the connector status to disconnected and
thereafter ignores indeterminate results from detect(), leaving the
status as the old value. This prevents the status from being set to
unknown, and so leaked to userspace, and so leaves the connector as
disconnected until we have a valid connection and also prevents that
valid connection being dropped due to a failed probe.

The alternative to this is to never return unknown from the drivers, but
return connector->status instead so that the value never changes on a
failed probe (and also to initialise the connector to disconnected in
the driver).
---
 drivers/gpu/drm/drm_crtc.c|1 +
 drivers/gpu/drm/drm_crtc_helper.c |   20 +---
 2 files changed, 14 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 08a7aa7..22f58b9 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -495,6 +495,7 @@ int drm_connector_init(struct drm_device *dev,
INIT_LIST_HEAD(>probed_modes);
INIT_LIST_HEAD(>modes);
connector->edid_blob_ptr = NULL;
+   connector->status = connector_status_disconnected;

list_add_tail(>head, >mode_config.connector_list);
dev->mode_config.num_connector++;
diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
b/drivers/gpu/drm/drm_crtc_helper.c
index 3252e70..143d6d5 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -108,7 +108,11 @@ int drm_helper_probe_single_connector_modes(struct 
drm_connector *connector,
if (connector->funcs->force)
connector->funcs->force(connector);
} else {
-   connector->status = connector->funcs->detect(connector, true);
+   enum drm_connector_status status;
+
+   status = connector->funcs->detect(connector, true);
+   if (status)
+   connector->status = status;
drm_kms_helper_poll_enable(dev);
}

@@ -949,13 +953,15 @@ static void output_poll_execute(struct work_struct *work)
!(connector->polled & DRM_CONNECTOR_POLL_HPD))
continue;

-   connector->status = connector->funcs->detect(connector, false);
-   DRM_DEBUG_KMS("[CONNECTOR:%d:%s] status updated from %d to 
%d\n",
- connector->base.id,
- drm_get_connector_name(connector),
- old_status, connector->status);
-   if (old_status != connector->status)
+   new_status = connector->funcs->detect(connector, false);
+   if (new_status && old_status != new_status) {
+   DRM_DEBUG_KMS("[CONNECTOR:%d:%s] status updated from %d 
to %d\n",
+ connector->base.id,
+ drm_get_connector_name(connector),
+ old_status, new_status);
+   connector->status = new_status;
changed = true;
+   }
}

mutex_unlock(>mode_config.mutex);
-- 
1.7.10

[git pull] drm intel + exynos fixes

[Daniel Vetter]

On Fri, Jun 8, 2012 at 11:57 PM, Linus Torvalds
 wrote:
> This breaks things for me. Bisect says:
>
> 9e612a008fa7fe493a473454def56aa321479495 is the first bad commit
> commit 9e612a008fa7fe493a473454def56aa321479495
> Author: Chris Wilson 
> Date: ? Thu May 31 13:08:53 2012 +0100
>
> ? ?drm/i915/crt: Do not rely upon the HPD presence pin
>
> ? ?Whilst most monitors do wire up the HPD presence pin, it seems quite a
> ? ?few KVM do not. Therefore if we simply rely on the HPD pin being
> ? ?asserted to indicate a connected monitor we fail miserable, so fall back
> ? ?to performing a DCC query for the EDID.
>
> ? ?Reported-and-tested-by: Matthieu LAVIE 
> ? ?Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50501
> ? ?Signed-off-by: Chris Wilson 
> ? ?Signed-off-by: Daniel Vetter 
>
> And the symptoms are that it boots in what appears to be the correct
> mode for my monitor (1920x1200), but when X starts it changes to
> 1024x768 mode.
>
> Which is not good, and not useful.
>
> The bad kernel has this in Xorg.0.log:
>
> ?[ ? ?12.796] (II) intel(0): EDID for output VGA1
> ?[ ? ?12.796] (II) intel(0): Printing probed modes for output VGA1
> ?[ ? ?12.796] (II) intel(0): Modeline "1024x768"x60.0 ? 65.00 ?1024
> 1048 1184 1344 ?768 771 777 806 -hsync -vsync (48.4 kHz e)
> ?[ ? ?12.796] (II) intel(0): Modeline "800x600"x60.3 ? 40.00 ?800 840
> 968 1056 ?600 601 605 628 +hsync +vsync (37.9 kHz e)
> ?[ ? ?12.796] (II) intel(0): Modeline "800x600"x56.2 ? 36.00 ?800 824
> 896 1024 ?600 601 603 625 +hsync +vsync (35.2 kHz e)
> ?[ ? ?12.796] (II) intel(0): Modeline "848x480"x60.0 ? 33.75 ?848 864
> 976 1088 ?480 486 494 517 +hsync +vsync (31.0 kHz e)
> ?[ ? ?12.796] (II) intel(0): Modeline "640x480"x59.9 ? 25.18 ?640 656
> 752 800 ?480 489 492 525 -hsync -vsync (31.5 kHz e)
>
> which is pure and utter garbage. I think it's the "default modes" for
> the non-EDID case, and has nothing to do with actual hardware.
>
> The good kernel doesn't have those incorrect and bogus probed modes,
> and just has the correct HDMI1 (that the bad kernel *also* has, of
> course).
>
> I have reverted that commit as obviously broken, since I'm not going
> to release an -rc2 that doesn't even work for me (and since it *is*
> obviously broken).

I've looked again through the code and with this patch we can fall
through to the gen2/3 load detect code, which likely results totally
bogus results for anything never (where we've previously relied
exclusively on the hotplug pins). Sorry for not catching this when
I've reviewed this patch for -fixes. Hence for the revert:

Acked-by: Daniel Vetter 

-Daniel
-- 
Daniel Vetter
daniel.vetter at ffwll.ch - +41 (0) 79 365 57 48 - http://blog.ffwll.ch

[git pull] drm intel + exynos fixes

[Chris Wilson]

On Fri, 8 Jun 2012 15:23:15 -0700, Linus Torvalds  wrote:
> On Fri, Jun 8, 2012 at 3:12 PM, Chris Wilson  
> wrote:
> >
> >   So it falls back to
> > load-detection, which in your case it cannot do since all the available
> > pipes are assigned and so it just reports the VGA connection as unknown.
> 
> Btw, it's a singularly stupid decision to say "Ok, I *know* I have a
> monitor on output X, and I have no clue what-so-ever what I have on
> output Y, and no indication there is anything even there, so let me
> just degrade the output on output Y just in case".

And that was my point. You were blaming the patch for making you aware
of existing behaviour that results in utter confusion, for as Alex
points out there is no sane way for userspace to handle the unknown
connection status from the detection routine. As such it is probably
better if that was handled internally as "result indeterminate; do not
update current detection status" which is the behaviour of some of the
drm helpers but uniformly. If that were true, then userspace would
continue to be told that the connection status was disconnected until
a monitor was plugged in.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[Linaro-mm-sig] [RFC] Synchronizing access to buffers shared with dma-buf between drivers/devices

[Daniel Vetter]

On Fri, Jun 08, 2012 at 01:56:05PM -0700, Erik Gilling wrote:
> On Thu, Jun 7, 2012 at 4:35 AM, Tom Cooksey  wrote:
> > The alternate is to not associate sync objects with buffers and
> > have them be distinct entities, exposed to userspace. This gives
> > userpsace more power and flexibility and might allow for use-cases
> > which an implicit synchronization mechanism can't satisfy - I'd
> > be curious to know any specifics here.
> 
> Time and time again we've had problems with implicit synchronization
> resulting in bugs where different drivers play by slightly different
> implicit rules.  We're convinced the best way to attack this problem
> is to move as much of the command and control of synchronization as
> possible into a single piece of code (the compositor in our case.)  To
> facilitate this we're going to be mandating this explicit approach in
> the K release of Android.
> 
> > However, every driver which
> > needs to participate in the synchronization mechanism will need
> > to have its interface with userspace modified to allow the sync
> > objects to be passed to the drivers. This seemed like a lot of
> > work to me, which is why I prefer the implicit approach. However
> > I don't actually know what work is needed and think it should be
> > explored. I.e. How much work is it to add explicit sync object
> > support to the DRM & v4l2 interfaces?
> >
> > E.g. I believe DRM/GEM's job dispatch API is "in-order"
> > in which case it might be easy to just add "wait for this fence"
> > and "signal this fence" ioctls. Seems like vmwgfx already has
> > something similar to this already? Could this work over having
> > to specify a list of sync objects to wait on and another list
> > of sync objects to signal for every operation (exec buf/page
> > flip)? What about for v4l2?
> 
> If I understand you right a job submission with explicit sync would
> become 3 submission:
> 1) submit wait for pre-req fence job
> 2) submit render job
> 3) submit signal ready fence job
> 
> Does DRM provide a way to ensure these 3 jobs are submitted
> atomically?  I also expect GPU vendor would like to get clever about
> GPU to GPU fence dependancies.  That could probably be handled
> entirely in the userspace GL driver.

Well, drm doesn't provide any way to submit a job. These are all done in
driver-private ioctls. And I guess with your proposal below we can do
exactly what you want.

> > I guess my other thought is that implicit vs explicit is not
> > mutually exclusive, though I'd guess there'd be interesting
> > deadlocks to have to debug if both were in use _at the same
> > time_. :-)
> 
> I think this is an approach worth investigating.  I'd like a way to
> either opt out of implicit sync or have a way to check if a dma-buf
> has an attached fence and detach it.  Actually, that could work really
> well. Consider:
> 
> * Each dma_buf has a single fence "slot"
> * on submission
>* the driver will extract the fence from the dma_buf and queue a wait on 
> it.
>* the driver will replace that fence with it's own complettion
> fence before the job submission ioctl returns.

This is pretty much what I've had in mind with the extension that we
probably need both a read and a write fence - in a lot of cases multiple
people want to use a buffer for reads (e.g. when decoding video streams
the decode needs it as a reference frame wheras later stages use it
read-only, too).

> * dma_buf will have two userspace ioctls:
>* DETACH: will return the fence as an FD to userspace and clear the
> fence slot in the dma_buf
>* ATTACH: takes a fence FD from userspace and attaches it to the
> dma_buf fence slot.  Returns an error if the fence slot is non-empty.

I am not yet sold on explicit fences, especially for cross-device sync. I
do see uses for explicit fences that can be accessed from userspace for
individual drivers - otherwise tricks like suballocation are a bit hard to
pull off. But for cross-device buffer sharing I don't quite see the point,
especially since the current Linux userspace graphics stack manages to do
so without (e.g. DRI2 is all implicit sync'ed).

btw, I'll try to stitch together a more elaborate discussion over the w/e,
I have a few more pet-peeves with your actual implementation ;-)

Yours, Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[PATCH] drm: do not expose vblank data before drm_vblank_init completes

[Marcin Slusarz]

On Sun, May 27, 2012 at 10:25:21PM +0200, Marcin Slusarz wrote:
> On Thu, May 24, 2012 at 08:09:41PM +0200, Bruno Pr?mont wrote:
> > I can easily trigger a crash in nouveau interrupt handler by unbinding
> > and rebinding the GPU.
> > 
> > The command used:
> >   echo $pci_device > nouveau/unbind && \
> > sleep 5 && \
> > echo $pci_device > nouveau/bind
> > 
> > 
> > Kernel is 3.4.0 with modular drm/nouveau.
> > GPU is NVidia nForce IGP (NV11)
> > 
> > 
> > Unbinding seems to work fine, display switching back to VGA text mode.
> > Rebinding the GPU slightly later causes the below trace:
> > 
> > (...)
> 
> It crashed because Nouveau failed to disable vblank interrupt on unbind
> and this interrupt triggered while drm was initializing vblank data.
> 
> Nouveau side was fixed by "drm/nv04/disp: disable vblank interrupts when
> disabling display" by Ben Skeggs (3.5 merge window), drm side can be fixed
> by this:
> 
> ---
> From: Marcin Slusarz 
> Subject: [PATCH] drm: do not expose vblank data before drm_vblank_init 
> completes
> 
> It fixes oops in drm_handle_vblank when vblank interrupt triggers before
> drm_vblank_init completes. Driver side should not let this happen, but let's
> be on the safe side and handle this case.
> 
> Reported-by: Bruno Pr?mont 
> Tested-by: Bruno Pr?mont 
> Signed-off-by: Marcin Slusarz 
> ---
>  drivers/gpu/drm/drm_irq.c |   21 +
>  1 files changed, 13 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index c869436..7dda18c 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -183,12 +183,8 @@ static void vblank_disable_fn(unsigned long arg)
>   }
>  }
>  
> -void drm_vblank_cleanup(struct drm_device *dev)
> +static void __drm_vblank_cleanup(struct drm_device *dev)
>  {
> - /* Bail if the driver didn't call drm_vblank_init() */
> - if (dev->num_crtcs == 0)
> - return;
> -
>   del_timer(>vblank_disable_timer);
>  
>   vblank_disable_fn((unsigned long)dev);
> @@ -201,6 +197,15 @@ void drm_vblank_cleanup(struct drm_device *dev)
>   kfree(dev->last_vblank_wait);
>   kfree(dev->vblank_inmodeset);
>   kfree(dev->_vblank_time);
> +}
> +
> +void drm_vblank_cleanup(struct drm_device *dev)
> +{
> + /* Bail if the driver didn't call drm_vblank_init() */
> + if (dev->num_crtcs == 0)
> + return;
> +
> + __drm_vblank_cleanup(dev);
>  
>   dev->num_crtcs = 0;
>  }
> @@ -215,8 +220,6 @@ int drm_vblank_init(struct drm_device *dev, int num_crtcs)
>   spin_lock_init(>vbl_lock);
>   spin_lock_init(>vblank_time_lock);
>  
> - dev->num_crtcs = num_crtcs;
> -
>   dev->vbl_queue = kmalloc(sizeof(wait_queue_head_t) * num_crtcs,
>GFP_KERNEL);
>   if (!dev->vbl_queue)
> @@ -268,10 +271,12 @@ int drm_vblank_init(struct drm_device *dev, int 
> num_crtcs)
>   }
>  
>   dev->vblank_disable_allowed = 0;
> + dev->num_crtcs = num_crtcs;
> +
>   return 0;
>  
>  err:
> - drm_vblank_cleanup(dev);
> + __drm_vblank_cleanup(dev);
>   return ret;
>  }
>  EXPORT_SYMBOL(drm_vblank_init);
> -- 

Dave?

[git pull] drm intel + exynos fixes

[Chris Wilson]

On Fri, 8 Jun 2012 14:57:31 -0700, Linus Torvalds  wrote:
> This breaks things for me. Bisect says:
> 
> 9e612a008fa7fe493a473454def56aa321479495 is the first bad commit
> commit 9e612a008fa7fe493a473454def56aa321479495
> Author: Chris Wilson 
> Date:   Thu May 31 13:08:53 2012 +0100
> 
> drm/i915/crt: Do not rely upon the HPD presence pin
> 
> Whilst most monitors do wire up the HPD presence pin, it seems quite a
> few KVM do not. Therefore if we simply rely on the HPD pin being
> asserted to indicate a connected monitor we fail miserable, so fall back
> to performing a DCC query for the EDID.
> 
> Reported-and-tested-by: Matthieu LAVIE 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50501
> Signed-off-by: Chris Wilson 
> Signed-off-by: Daniel Vetter 
> 
> And the symptoms are that it boots in what appears to be the correct
> mode for my monitor (1920x1200), but when X starts it changes to
> 1024x768 mode.
> 
> Which is not good, and not useful.
> 
> The bad kernel has this in Xorg.0.log:
> 
>  [12.796] (II) intel(0): EDID for output VGA1
>  [12.796] (II) intel(0): Printing probed modes for output VGA1
>  [12.796] (II) intel(0): Modeline "1024x768"x60.0   65.00  1024
> 1048 1184 1344  768 771 777 806 -hsync -vsync (48.4 kHz e)
>  [12.796] (II) intel(0): Modeline "800x600"x60.3   40.00  800 840
> 968 1056  600 601 605 628 +hsync +vsync (37.9 kHz e)
>  [12.796] (II) intel(0): Modeline "800x600"x56.2   36.00  800 824
> 896 1024  600 601 603 625 +hsync +vsync (35.2 kHz e)
>  [12.796] (II) intel(0): Modeline "848x480"x60.0   33.75  848 864
> 976 1088  480 486 494 517 +hsync +vsync (31.0 kHz e)
>  [12.796] (II) intel(0): Modeline "640x480"x59.9   25.18  640 656
> 752 800  480 489 492 525 -hsync -vsync (31.5 kHz e)
> 
> which is pure and utter garbage. I think it's the "default modes" for
> the non-EDID case, and has nothing to do with actual hardware.
> 
> The good kernel doesn't have those incorrect and bogus probed modes,
> and just has the correct HDMI1 (that the bad kernel *also* has, of
> course).
> 
> I have reverted that commit as obviously broken, since I'm not going
> to release an -rc2 that doesn't even work for me (and since it *is*
> obviously broken).

Shock, horror, that's how it is meant to work when we cannot determine
whether or not there is actually an output attached to the VGA. The hw
autodetect falsely declares some VGA connections, notably through KVM
switches, as disconnected and so we need to do a manual probe to confirm
the flaky hw. The first phase of that probe is to request the EDID from
the monitor, not all monitors supply one and less through a KVM switch,
so we cannot rely on a negative result from that test. (Absence of
evidence is not evidence of absence and all that.) So it falls back to
load-detection, which in your case it cannot do since all the available
pipes are assigned and so it just reports the VGA connection as unknown.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: [alsa-devel] [PATCH 0/2] HD-audio HDMI regression fixes with VGA-switcheroo

[Dave Airlie]

 Good to hear.
 Dave, is it OK to apply the patch below through sound tree?

ack below,


 thanks,

 Takashi

 ---
 From: Takashi Iwai ti...@suse.de
 Subject: [PATCH] vga_switcheroo: Enable/disable audio clients at the right 
 time

 The audio clients have to be disabled before disabling the VGA and
 switching.  Similarly, enabling the audio client should be done at
 last.  Otherwise the audio-side operation stalls, eventually leading
 to Oops or lockups.

 Tested-by: Jörg-Volker Peetz jvpe...@web.de

Acked-by: Dave Airlie airl...@redhat.com

 Signed-off-by: Takashi Iwai ti...@suse.de
 ---
  drivers/gpu/vga/vga_switcheroo.c |   14 --
  1 file changed, 8 insertions(+), 6 deletions(-)

 diff --git a/drivers/gpu/vga/vga_switcheroo.c 
 b/drivers/gpu/vga/vga_switcheroo.c
 index 38f9534..e24ad99 100644
 --- a/drivers/gpu/vga/vga_switcheroo.c
 +++ b/drivers/gpu/vga/vga_switcheroo.c
 @@ -291,8 +291,6 @@ static int vga_switchto_stage1(struct 
 vga_switcheroo_client *new_client)
                vga_switchon(new_client);

        vga_set_default_device(new_client-pdev);
 -       set_audio_state(new_client-id, VGA_SWITCHEROO_ON);
 -
        return 0;
  }

 @@ -308,6 +306,8 @@ static int vga_switchto_stage2(struct 
 vga_switcheroo_client *new_client)

        active-active = false;

 +       set_audio_state(active-id, VGA_SWITCHEROO_OFF);
 +
        if (new_client-fb_info) {
                struct fb_event event;
                event.info = new_client-fb_info;
 @@ -321,11 +321,11 @@ static int vga_switchto_stage2(struct 
 vga_switcheroo_client *new_client)
        if (new_client-ops-reprobe)
                new_client-ops-reprobe(new_client-pdev);

 -       set_audio_state(active-id, VGA_SWITCHEROO_OFF);
 -
        if (active-pwr_state == VGA_SWITCHEROO_ON)
                vga_switchoff(active);

 +       set_audio_state(new_client-id, VGA_SWITCHEROO_ON);
 +
        new_client-active = true;
        return 0;
  }
 @@ -371,8 +371,9 @@ vga_switcheroo_debugfs_write(struct file *filp, const 
 char __user *ubuf,
        /* pwr off the device not in use */
        if (strncmp(usercmd, OFF, 3) == 0) {
                list_for_each_entry(client, vgasr_priv.clients, list) {
 -                       if (client-active)
 +                       if (client-active || client_is_audio(client))
                                continue;
 +                       set_audio_state(client-id, VGA_SWITCHEROO_OFF);
                        if (client-pwr_state == VGA_SWITCHEROO_ON)
                                vga_switchoff(client);
                }
 @@ -381,10 +382,11 @@ vga_switcheroo_debugfs_write(struct file *filp, const 
 char __user *ubuf,
        /* pwr on the device not in use */
        if (strncmp(usercmd, ON, 2) == 0) {
                list_for_each_entry(client, vgasr_priv.clients, list) {
 -                       if (client-active)
 +                       if (client-active || client_is_audio(client))
                                continue;
                        if (client-pwr_state == VGA_SWITCHEROO_OFF)
                                vga_switchon(client);
 +                       set_audio_state(client-id, VGA_SWITCHEROO_ON);
                }
                goto out;
        }
 --
 1.7.10.4

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

[Bug 50657] [Evergreen,GIT,Tiling?] Occasional invalid command stream and subsequent performance increase

[bugzilla-daemon]

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

--- Comment #3 from Thomas Lindroth thomas.lindr...@gmail.com 2012-06-09 
01:34:49 PDT ---
Disregard the previous comment. I forgot Psychonauts is 32bit and therefor
don't use my git drivers automatically. There is nothing wrong with it but the
first comment still apply.

Turning off ColorTiling2D or using a blank xorg.conf makes no difference. The
problem is the same on kernel 3.3 except there is no error in dmesg. It just
fails to render anything.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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 50892] Invalid command stream with TURKS running Cinnamon

[bugzilla-daemon]

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

--- Comment #6 from Zoltán Böszörményi zbos...@pr.hu 2012-06-09 01:44:38 PDT 
---
Tried to compile v3 on vanilla 3.4.1 but it failed:

  CC [M]  drivers/gpu/drm/radeon/evergreen_cs.o
drivers/gpu/drm/radeon/evergreen_cs.c: In function
‘evergreen_cs_track_validate_cb’:
drivers/gpu/drm/radeon/evergreen_cs.c:447:28: error: request for member ‘ptr’
in something not a structure or union
make[4]: *** [drivers/gpu/drm/radeon/evergreen_cs.o] Error 1
make[3]: *** [drivers/gpu/drm/radeon] Error 2
make[2]: *** [drivers/gpu/drm] Error 2
make[1]: *** [drivers/gpu] Error 2
make: *** [drivers] Error 2

This one-liner over your patch fixes the compilation:

--- drivers/gpu/drm/radeon/evergreen_cs.c~2012-06-09 08:51:34.0
+0200
+++ drivers/gpu/drm/radeon/evergreen_cs.c2012-06-09 10:42:29.054351410
+0200
@@ -444,7 +444,7 @@
  * command stream.
  */
 if (!surf.mode) {
-volatile u32 *ib = p-ib.ptr;
+volatile u32 *ib = p-ib-ptr;
 unsigned long tmp, nby, bsize, size, min = 0;

 /* find the height the ddx wants */

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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: [alsa-devel] [PATCH 0/2] HD-audio HDMI regression fixes with VGA-switcheroo

[Takashi Iwai]

At Sat, 9 Jun 2012 08:57:20 +0100,
Dave Airlie wrote:
 
  Good to hear.
  Dave, is it OK to apply the patch below through sound tree?
 
 ack below,
 
 
  thanks,
 
  Takashi
 
  ---
  From: Takashi Iwai ti...@suse.de
  Subject: [PATCH] vga_switcheroo: Enable/disable audio clients at the right 
  time
 
  The audio clients have to be disabled before disabling the VGA and
  switching.  Similarly, enabling the audio client should be done at
  last.  Otherwise the audio-side operation stalls, eventually leading
  to Oops or lockups.
 
  Tested-by: Jörg-Volker Peetz jvpe...@web.de
 
 Acked-by: Dave Airlie airl...@redhat.com

Thanks!


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

[Bug 50892] Invalid command stream with TURKS running Cinnamon

[bugzilla-daemon]

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

--- Comment #7 from Zoltán Böszörményi zbos...@pr.hu 2012-06-09 03:43:39 PDT 
---
It seems this patch fixed the invalid command stream error. Thanks very much.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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 50892] Invalid command stream with TURKS running Cinnamon

[bugzilla-daemon]

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

--- Comment #8 from Zoltán Böszörményi zbos...@pr.hu 2012-06-09 03:46:04 PDT 
---
Created attachment 62842
  -- https://bugs.freedesktop.org/attachment.cgi?id=62842
dmesg from my desktop machine with 3.4.1 + tiling fix v3 + the one liner patch

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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 50892] Invalid command stream with TURKS running Cinnamon

[bugzilla-daemon]

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

--- Comment #9 from Zoltán Böszörményi zbos...@pr.hu 2012-06-09 03:46:57 PDT 
---
Created attachment 62843
  -- https://bugs.freedesktop.org/attachment.cgi?id=62843
Xorg.0.log on my deskop with kernel 3.4.1 + radeon tiling fix v3 + one liner
patch

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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 50892] Invalid command stream with TURKS running Cinnamon

[bugzilla-daemon]

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

--- Comment #10 from Zoltán Böszörményi zbos...@pr.hu 2012-06-09 04:02:11 UTC 
---
Fixed on the notebook with A4-3300 CPU too. Thanks very very much.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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 50892] Invalid command stream with TURKS running Cinnamon

[bugzilla-daemon]

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

--- Comment #11 from Zoltán Böszörményi zbos...@pr.hu 2012-06-09 04:05:34 PDT 
---
Created attachment 62844
  -- https://bugs.freedesktop.org/attachment.cgi?id=62844
dmesg from my notebook with 3.4.1 + tiling fix v3 + the one liner patch

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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 50892] Invalid command stream with TURKS running Cinnamon

[bugzilla-daemon]

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

--- Comment #12 from Zoltán Böszörményi zbos...@pr.hu 2012-06-09 04:06:07 PDT 
---
Created attachment 62845
  -- https://bugs.freedesktop.org/attachment.cgi?id=62845
Xorg.0.log on my notebook with kernel 3.4.1 + radeon tiling fix v3 + one liner
patch

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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] RFC drm: Do not leak connector_status_unknown to userspace

[Daniel Vetter]

On Sat, Jun 09, 2012 at 12:24:49AM +0100, Chris Wilson wrote:
 A detect() probe may return 'unknown' to indicate that it was not able
 to successfully determine the connector status. However, exposing this
 to userspace just results in lots of confusion as it is uncertain
 whether or not that is a valid connection. The usual result is for X to
 create a mode that encompasses the unknown connector causing an abnormal
 setup on the known good outputs.
 
 This patch initialises the connector status to disconnected and
 thereafter ignores indeterminate results from detect(), leaving the
 status as the old value. This prevents the status from being set to
 unknown, and so leaked to userspace, and so leaves the connector as
 disconnected until we have a valid connection and also prevents that
 valid connection being dropped due to a failed probe.
 
 The alternative to this is to never return unknown from the drivers, but
 return connector-status instead so that the value never changes on a
 failed probe (and also to initialise the connector to disconnected in
 the driver).

Hm, this is a bit at odds with how I've re-defined unknown in my hpd
rework. There it essentially means that that the kernel truely has no idea
what the status is because the world changed (i.e. resume or fresh boot)
and detect hasn't been run yet. So imo we should initialize the connector
state to unknown (and reset it to unknown after resume).

I agree with the 'not leaking unknown' to userspace, although I'm unsure
about the implications. I guess we just have to try and see what happens.

Yours, Daniel
 ---
  drivers/gpu/drm/drm_crtc.c|1 +
  drivers/gpu/drm/drm_crtc_helper.c |   20 +---
  2 files changed, 14 insertions(+), 7 deletions(-)
 
 diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
 index 08a7aa7..22f58b9 100644
 --- a/drivers/gpu/drm/drm_crtc.c
 +++ b/drivers/gpu/drm/drm_crtc.c
 @@ -495,6 +495,7 @@ int drm_connector_init(struct drm_device *dev,
   INIT_LIST_HEAD(connector-probed_modes);
   INIT_LIST_HEAD(connector-modes);
   connector-edid_blob_ptr = NULL;
 + connector-status = connector_status_disconnected;
  
   list_add_tail(connector-head, dev-mode_config.connector_list);
   dev-mode_config.num_connector++;
 diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
 b/drivers/gpu/drm/drm_crtc_helper.c
 index 3252e70..143d6d5 100644
 --- a/drivers/gpu/drm/drm_crtc_helper.c
 +++ b/drivers/gpu/drm/drm_crtc_helper.c
 @@ -108,7 +108,11 @@ int drm_helper_probe_single_connector_modes(struct 
 drm_connector *connector,
   if (connector-funcs-force)
   connector-funcs-force(connector);
   } else {
 - connector-status = connector-funcs-detect(connector, true);
 + enum drm_connector_status status;
 +
 + status = connector-funcs-detect(connector, true);
 + if (status)
 + connector-status = status;
   drm_kms_helper_poll_enable(dev);
   }
  
 @@ -949,13 +953,15 @@ static void output_poll_execute(struct work_struct 
 *work)
   !(connector-polled  DRM_CONNECTOR_POLL_HPD))
   continue;
  
 - connector-status = connector-funcs-detect(connector, false);
 - DRM_DEBUG_KMS([CONNECTOR:%d:%s] status updated from %d to 
 %d\n,
 -   connector-base.id,
 -   drm_get_connector_name(connector),
 -   old_status, connector-status);
 - if (old_status != connector-status)
 + new_status = connector-funcs-detect(connector, false);
 + if (new_status  old_status != new_status) {
 + DRM_DEBUG_KMS([CONNECTOR:%d:%s] status updated from %d 
 to %d\n,
 +   connector-base.id,
 +   drm_get_connector_name(connector),
 +   old_status, new_status);
 + connector-status = new_status;
   changed = true;
 + }
   }
  
   mutex_unlock(dev-mode_config.mutex);
 -- 
 1.7.10
 
 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 50696] HDMI Audio is Choppy on RS880M / 4200

[bugzilla-daemon]

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

--- Comment #2 from Rafał Miłecki zaj...@gmail.com 2012-06-09 06:47:32 PDT ---
Mike: have you tried applying referenced patch?
It is included in kernel 3.5-rc2 so you can just try updating as well.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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 50657] [Evergreen,GIT,Tiling?] Occasional invalid command stream and subsequent performance increase

[bugzilla-daemon]

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

--- Comment #4 from Jerome Glisse gli...@freedesktop.org 2012-06-09 07:36:43 
PDT ---
Does kernel patch: (apply against 3.5 but need a small diff for 3.4) helps

http://people.freedesktop.org/~glisse/0001-drm-radeon-fix-tiling-and-command-stream-checking-on.patch

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

[PATCH] drm/radeon: fix tiling and command stream checking on evergreen v3

[j . glisse]

From: Jerome Glisse jgli...@redhat.com

Fix regresson since the introduction of command stream checking on
evergreen (thread referenced below). Issue is cause by ddx allocating
bo with formula width*height*bpp while programming the GPU command
stream with ALIGN(height, 8). In some case (where page alignment does
not hide the extra size bo should be according to height alignment)
the kernel will reject the command stream.

This patch reprogram the command stream to slice - 1 (slice is
a derivative value from height) which avoid rejecting the command
stream while keeping the value of command stream checking from a
security point of view.

This patch also fix wrong computation of layer size for 2D tiled
surface. Which should fix issue when 2D color tiling is enabled.
This dump the radeon KMS_DRIVER_MINOR so userspace can know if
they are on a fixed kernel or not.

https://lkml.org/lkml/2012/6/3/80
https://bugs.freedesktop.org/show_bug.cgi?id=50892
https://bugs.freedesktop.org/show_bug.cgi?id=50857

!!! STABLE need a custom version of this patch for 3.4 !!!

v2: actually bump the minor version and add comment about stable
v3: do compute the height the ddx was trying to use

Signed-off-by: Jerome Glisse jgli...@redhat.com
---
 drivers/gpu/drm/radeon/evergreen_cs.c |   50 ++---
 drivers/gpu/drm/radeon/radeon_drv.c   |3 +-
 2 files changed, 48 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c 
b/drivers/gpu/drm/radeon/evergreen_cs.c
index 4e7dd2b..29c43c6 100644
--- a/drivers/gpu/drm/radeon/evergreen_cs.c
+++ b/drivers/gpu/drm/radeon/evergreen_cs.c
@@ -52,6 +52,7 @@ struct evergreen_cs_track {
u32 cb_color_view[12];
u32 cb_color_pitch[12];
u32 cb_color_slice[12];
+   u32 cb_color_slice_idx[12];
u32 cb_color_attrib[12];
u32 cb_color_cmask_slice[8];/* unused */
u32 cb_color_fmask_slice[8];/* unused */
@@ -127,12 +128,14 @@ static void evergreen_cs_track_init(struct 
evergreen_cs_track *track)
track-cb_color_info[i] = 0;
track-cb_color_view[i] = 0x;
track-cb_color_pitch[i] = 0;
-   track-cb_color_slice[i] = 0;
+   track-cb_color_slice[i] = 0xfff;
+   track-cb_color_slice_idx[i] = 0;
}
track-cb_target_mask = 0x;
track-cb_shader_mask = 0x;
track-cb_dirty = true;
 
+   track-db_depth_slice = 0x;
track-db_depth_view = 0xC000;
track-db_depth_size = 0x;
track-db_depth_control = 0x;
@@ -250,10 +253,9 @@ static int evergreen_surface_check_2d(struct 
radeon_cs_parser *p,
 {
struct evergreen_cs_track *track = p-track;
unsigned palign, halign, tileb, slice_pt;
+   unsigned mtile_pr, mtile_ps, mtileb;
 
tileb = 64 * surf-bpe * surf-nsamples;
-   palign = track-group_size / (8 * surf-bpe * surf-nsamples);
-   palign = MAX(8, palign);
slice_pt = 1;
if (tileb  surf-tsplit) {
slice_pt = tileb / surf-tsplit;
@@ -262,7 +264,10 @@ static int evergreen_surface_check_2d(struct 
radeon_cs_parser *p,
/* macro tile width  height */
palign = (8 * surf-bankw * track-npipes) * surf-mtilea;
halign = (8 * surf-bankh * surf-nbanks) / surf-mtilea;
-   surf-layer_size = surf-nbx * surf-nby * surf-bpe * slice_pt;
+   mtileb = (palign / 8) * (halign / 8) * tileb;;
+   mtile_pr = surf-nbx / palign;
+   mtile_ps = (mtile_pr * surf-nby) / halign;
+   surf-layer_size = mtile_ps * mtileb * slice_pt;
surf-base_align = (palign / 8) * (halign / 8) * tileb;
surf-palign = palign;
surf-halign = halign;
@@ -434,6 +439,39 @@ static int evergreen_cs_track_validate_cb(struct 
radeon_cs_parser *p, unsigned i
 
offset += surf.layer_size * mslice;
if (offset  radeon_bo_size(track-cb_color_bo[id])) {
+   /* old ddx are broken they allocate bo with w*h*bpp but
+* program slice with ALIGN(h, 8), catch this and patch
+* command stream.
+*/
+   if (!surf.mode) {
+   volatile u32 *ib = p-ib.ptr;
+   unsigned long tmp, nby, bsize, size, min = 0;
+
+   /* find the height the ddx wants */
+   if (surf.nby  8) {
+   min = surf.nby - 8;
+   }
+   bsize = radeon_bo_size(track-cb_color_bo[id]);
+   tmp = track-cb_color_bo_offset[id]  8;
+   for (nby = surf.nby; nby  min; nby--) {
+   size = nby * surf.nbx * surf.bpe * 
surf.nsamples;
+   if ((tmp + size * mslice) = bsize) 

[Bug 46713] HDMI audio played back at a wrong rate

[bugzilla-daemon]

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

--- Comment #28 from Vincenzov vincenzo...@hotmail.com 2012-06-09 08:11:05 
PDT ---
kernel 3.5.0-rc2 audio workgood.
i have 2 monitor hdmi, after I changed the initial resolution of the monitor
works fine 2.
example

1 monitor 1920 x 1080 works
2 monitor 1920 x 1080 works.

after i turn off monitor 1, audio monitor 2 slow.
configure monitor 2 and after all audio works good 1  2.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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 46713] HDMI audio played back at a wrong rate

[bugzilla-daemon]

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

--- Comment #29 from Christian König deathsim...@vodafone.de 2012-06-09 
08:33:50 PDT ---
Yeah, the audio rate is controlled by the last output changed.

We should switch to another output if the output driving the audio signal is
turned off.

It's on the todo list.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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: [Linaro-mm-sig] [RFC] Synchronizing access to buffers shared with dma-buf between drivers/devices

[Daniel Vetter]

On Sat, Jun 9, 2012 at 12:22 AM, Erik Gilling konk...@android.com wrote:
 The current linux graphics stack does not allow synchronization
 between the GPU and a camera/video decoder.  When we've seen people
 try to support this behind the scenes, they get it wrong and introduce
 bugs that can take weeks to track down.  As stated in the previous
 email, one of our goals is to centrally manage synchronization so that
 it's easer for people bringing up a platform to get it right.

I agree that letting everyone reinvent the wheel isn't the best idea
for cross-device sync - people will just get it wrong way too often.
I'm not convinced yet that doing it with explicit sync points/fences
and in userspace is the best solution. dri2/gem all use implicit sync
points managed by the kernel in a transparent fashion, so I'm leaning
towards such a sulotion for cross-device sync, too. Imo the big upside
of such an implicitly sync'ed approach is that it massively simplifies
cross-process protocols (i.e. for the display server).

So to foster understanding of the various requirements and use-cases,
could you elaborate on the pros and cons a bit and explain why you
think explicit sync points managed by the userspace display server is
the best approach for android?

Yours, Daniel
-- 
Daniel Vetter
daniel.vet...@ffwll.ch - +41 (0) 79 364 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 50857] Invalid command stream with CAICOS when ColorTiling2D enabled

[bugzilla-daemon]

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

--- Comment #15 from Chris Rankin ranki...@googlemail.com 2012-06-09 09:37:40 
PDT ---
(In reply to comment #14)
 Updated v3 same url, please test v3 version thx

Yes, this patch (plus compile-fix from #50892) fixes ColorTiling2D support,
thanks.

[3.416710] [drm] Initialized radeon 2.16.0 20080528 for :01:00.0 on minor 0

But it is also spamming my dmesg log with messages like:

[  507.899565] [drm] evergreen_cs_track_validate_depth 688 surface nbx,y (1280
1024) mode 4 format 26 surf.tsplit 64 banks (2 1 1) tilea 1
[  507.974505] [drm] evergreen_cs_track_validate_depth 688 surface nbx,y (1280
1024) mode 4 format 26 surf.tsplit 64 banks (2 1 1) tilea 1
[  508.135274] [drm] evergreen_cs_track_validate_depth 688 surface nbx,y (1280
1024) mode 4 format 26 surf.tsplit 64 banks (2 1 1) tilea 1
[  508.152312] [drm] evergreen_cs_track_validate_depth 688 surface nbx,y (1280
1024) mode 4 format 26 surf.tsplit 64 banks (2 1 1) tilea 1
[  508.169122] [drm] evergreen_cs_track_validate_depth 688 surface nbx,y (1280
1024) mode 4 format 26 surf.tsplit 64 banks (2 1 1) tilea 1

I'm guessing that this from is the extra DRM_INFO() statement, which I shall be
removing immediately...

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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] drm/radeon: fix tiling and command stream checking on evergreen v3

[Boszormenyi Zoltan]

2012-06-09 16:57 keltezéssel, j.gli...@gmail.com írta:

From: Jerome Glissejgli...@redhat.com

Fix regresson since the introduction of command stream checking on
evergreen (thread referenced below). Issue is cause by ddx allocating
bo with formula width*height*bpp while programming the GPU command
stream with ALIGN(height, 8). In some case (where page alignment does
not hide the extra size bo should be according to height alignment)
the kernel will reject the command stream.

This patch reprogram the command stream to slice - 1 (slice is
a derivative value from height) which avoid rejecting the command
stream while keeping the value of command stream checking from a
security point of view.

This patch also fix wrong computation of layer size for 2D tiled
surface. Which should fix issue when 2D color tiling is enabled.
This dump the radeon KMS_DRIVER_MINOR so userspace can know if
they are on a fixed kernel or not.

https://lkml.org/lkml/2012/6/3/80
https://bugs.freedesktop.org/show_bug.cgi?id=50892
https://bugs.freedesktop.org/show_bug.cgi?id=50857

!!! STABLE need a custom version of this patch for 3.4 !!!

v2: actually bump the minor version and add comment about stable
v3: do compute the height the ddx was trying to use

Signed-off-by: Jerome Glissejgli...@redhat.com
---
  drivers/gpu/drm/radeon/evergreen_cs.c |   50 ++---
  drivers/gpu/drm/radeon/radeon_drv.c   |3 +-
  2 files changed, 48 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c 
b/drivers/gpu/drm/radeon/evergreen_cs.c
index 4e7dd2b..29c43c6 100644
--- a/drivers/gpu/drm/radeon/evergreen_cs.c
+++ b/drivers/gpu/drm/radeon/evergreen_cs.c
@@ -52,6 +52,7 @@ struct evergreen_cs_track {
u32 cb_color_view[12];
u32 cb_color_pitch[12];
u32 cb_color_slice[12];
+   u32 cb_color_slice_idx[12];
u32 cb_color_attrib[12];
u32 cb_color_cmask_slice[8];/* unused */
u32 cb_color_fmask_slice[8];/* unused */
@@ -127,12 +128,14 @@ static void evergreen_cs_track_init(struct 
evergreen_cs_track *track)
track-cb_color_info[i] = 0;
track-cb_color_view[i] = 0x;
track-cb_color_pitch[i] = 0;
-   track-cb_color_slice[i] = 0;
+   track-cb_color_slice[i] = 0xfff;
+   track-cb_color_slice_idx[i] = 0;
}
track-cb_target_mask = 0x;
track-cb_shader_mask = 0x;
track-cb_dirty = true;

+   track-db_depth_slice = 0x;
track-db_depth_view = 0xC000;
track-db_depth_size = 0x;
track-db_depth_control = 0x;
@@ -250,10 +253,9 @@ static int evergreen_surface_check_2d(struct 
radeon_cs_parser *p,
  {
struct evergreen_cs_track *track = p-track;
unsigned palign, halign, tileb, slice_pt;
+   unsigned mtile_pr, mtile_ps, mtileb;

tileb = 64 * surf-bpe * surf-nsamples;
-   palign = track-group_size / (8 * surf-bpe * surf-nsamples);
-   palign = MAX(8, palign);
slice_pt = 1;
if (tileb  surf-tsplit) {
slice_pt = tileb / surf-tsplit;
@@ -262,7 +264,10 @@ static int evergreen_surface_check_2d(struct 
radeon_cs_parser *p,
/* macro tile width  height */
palign = (8 * surf-bankw * track-npipes) * surf-mtilea;
halign = (8 * surf-bankh * surf-nbanks) / surf-mtilea;
-   surf-layer_size = surf-nbx * surf-nby * surf-bpe * slice_pt;
+   mtileb = (palign / 8) * (halign / 8) * tileb;;
+   mtile_pr = surf-nbx / palign;
+   mtile_ps = (mtile_pr * surf-nby) / halign;
+   surf-layer_size = mtile_ps * mtileb * slice_pt;
surf-base_align = (palign / 8) * (halign / 8) * tileb;
surf-palign = palign;
surf-halign = halign;
@@ -434,6 +439,39 @@ static int evergreen_cs_track_validate_cb(struct 
radeon_cs_parser *p, unsigned i

offset += surf.layer_size * mslice;
if (offset  radeon_bo_size(track-cb_color_bo[id])) {
+   /* old ddx are broken they allocate bo with w*h*bpp but
+* program slice with ALIGN(h, 8), catch this and patch
+* command stream.
+*/
+   if (!surf.mode) {
+   volatile u32 *ib = p-ib.ptr;
+   unsigned long tmp, nby, bsize, size, min = 0;
+
+   /* find the height the ddx wants */
+   if (surf.nby  8) {
+   min = surf.nby - 8;
+   }
+   bsize = radeon_bo_size(track-cb_color_bo[id]);
+   tmp = track-cb_color_bo_offset[id]  8;
+   for (nby = surf.nby; nby  min; nby--) {
+   size = nby * surf.nbx * surf.bpe * 
surf.nsamples;
+   

Re: [PATCH] drm/radeon: fix tiling and command stream checking on evergreen v3

[Jerome Glisse]

On Sat, Jun 9, 2012 at 12:15 PM, Boszormenyi Zoltan zbos...@pr.hu wrote:
 2012-06-09 16:57 keltezéssel, j.gli...@gmail.com írta:

 From: Jerome Glissejgli...@redhat.com

 Fix regresson since the introduction of command stream checking on
 evergreen (thread referenced below). Issue is cause by ddx allocating
 bo with formula width*height*bpp while programming the GPU command
 stream with ALIGN(height, 8). In some case (where page alignment does
 not hide the extra size bo should be according to height alignment)
 the kernel will reject the command stream.

 This patch reprogram the command stream to slice - 1 (slice is
 a derivative value from height) which avoid rejecting the command
 stream while keeping the value of command stream checking from a
 security point of view.

 This patch also fix wrong computation of layer size for 2D tiled
 surface. Which should fix issue when 2D color tiling is enabled.
 This dump the radeon KMS_DRIVER_MINOR so userspace can know if
 they are on a fixed kernel or not.

 https://lkml.org/lkml/2012/6/3/80
 https://bugs.freedesktop.org/show_bug.cgi?id=50892
 https://bugs.freedesktop.org/show_bug.cgi?id=50857

 !!! STABLE need a custom version of this patch for 3.4 !!!

 v2: actually bump the minor version and add comment about stable
 v3: do compute the height the ddx was trying to use

 Signed-off-by: Jerome Glissejgli...@redhat.com
 ---
  drivers/gpu/drm/radeon/evergreen_cs.c |   50
 ++---
  drivers/gpu/drm/radeon/radeon_drv.c   |    3 +-
  2 files changed, 48 insertions(+), 5 deletions(-)

 diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c
 b/drivers/gpu/drm/radeon/evergreen_cs.c
 index 4e7dd2b..29c43c6 100644
 --- a/drivers/gpu/drm/radeon/evergreen_cs.c
 +++ b/drivers/gpu/drm/radeon/evergreen_cs.c
 @@ -52,6 +52,7 @@ struct evergreen_cs_track {
        u32                     cb_color_view[12];
        u32                     cb_color_pitch[12];
        u32                     cb_color_slice[12];
 +       u32                     cb_color_slice_idx[12];
        u32                     cb_color_attrib[12];
        u32                     cb_color_cmask_slice[8];/* unused */
        u32                     cb_color_fmask_slice[8];/* unused */
 @@ -127,12 +128,14 @@ static void evergreen_cs_track_init(struct
 evergreen_cs_track *track)
                track-cb_color_info[i] = 0;
                track-cb_color_view[i] = 0x;
                track-cb_color_pitch[i] = 0;
 -               track-cb_color_slice[i] = 0;
 +               track-cb_color_slice[i] = 0xfff;
 +               track-cb_color_slice_idx[i] = 0;
        }
        track-cb_target_mask = 0x;
        track-cb_shader_mask = 0x;
        track-cb_dirty = true;

 +       track-db_depth_slice = 0x;
        track-db_depth_view = 0xC000;
        track-db_depth_size = 0x;
        track-db_depth_control = 0x;
 @@ -250,10 +253,9 @@ static int evergreen_surface_check_2d(struct
 radeon_cs_parser *p,
  {
        struct evergreen_cs_track *track = p-track;
        unsigned palign, halign, tileb, slice_pt;
 +       unsigned mtile_pr, mtile_ps, mtileb;

        tileb = 64 * surf-bpe * surf-nsamples;
 -       palign = track-group_size / (8 * surf-bpe * surf-nsamples);
 -       palign = MAX(8, palign);
        slice_pt = 1;
        if (tileb  surf-tsplit) {
                slice_pt = tileb / surf-tsplit;
 @@ -262,7 +264,10 @@ static int evergreen_surface_check_2d(struct
 radeon_cs_parser *p,
        /* macro tile width  height */

        palign = (8 * surf-bankw * track-npipes) * surf-mtilea;
        halign = (8 * surf-bankh * surf-nbanks) / surf-mtilea;
 -       surf-layer_size = surf-nbx * surf-nby * surf-bpe * slice_pt;
 +       mtileb = (palign / 8) * (halign / 8) * tileb;;
 +       mtile_pr = surf-nbx / palign;
 +       mtile_ps = (mtile_pr * surf-nby) / halign;
 +       surf-layer_size = mtile_ps * mtileb * slice_pt;
        surf-base_align = (palign / 8) * (halign / 8) * tileb;
        surf-palign = palign;
        surf-halign = halign;
 @@ -434,6 +439,39 @@ static int evergreen_cs_track_validate_cb(struct
 radeon_cs_parser *p, unsigned i

        offset += surf.layer_size * mslice;
        if (offset  radeon_bo_size(track-cb_color_bo[id])) {
 +               /* old ddx are broken they allocate bo with w*h*bpp but
 +                * program slice with ALIGN(h, 8), catch this and patch
 +                * command stream.
 +                */
 +               if (!surf.mode) {
 +                       volatile u32 *ib = p-ib.ptr;
 +                       unsigned long tmp, nby, bsize, size, min = 0;
 +
 +                       /* find the height the ddx wants */
 +                       if (surf.nby  8) {
 +                               min = surf.nby - 8;
 +                       }
 +                       bsize = radeon_bo_size(track-cb_color_bo[id]);
 +                       tmp = track-cb_color_bo_offset[id]  8;
 +                       

[Bug 50657] [Evergreen,GIT,Tiling?] Occasional invalid command stream and subsequent performance increase

[bugzilla-daemon]

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

--- Comment #5 from Thomas Lindroth thomas.lindr...@gmail.com 2012-06-09 
14:01:11 PDT ---
I tested the patch against 3.5 but it didn't help.

I should also mention that I'm experiencing memory/filesystem corruption but
only when or directly after I've used some opengl app. After filesystem
restoration and reboot everything works fine until the next time I use an
opengl app. I can't say for sure it's graphics related yet but I've ruled out
hardware error in the disk and ram.

I think it was airlied who on irc told me to try a patch in the 3.5 kernel
related to GART but I got the same corruption with 3.5.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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