Re: [alsa-devel] [PATCH 0/2] HD-audio HDMI regression fixes with VGA-switcheroo
> 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, &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
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. ___ 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
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.
___
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
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 ___ 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
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. ___ 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
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. ___ 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
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. ___ 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
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. ___ 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
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. ___ 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
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. ___ 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
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
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. ___ 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
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. ___ 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
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 ((tmp + size * mslice
[Bug 46713] HDMI audio played back at a wrong rate
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. ___ 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
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. ___ 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
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. ___ 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
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.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
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. ___ 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
2012-06-09 16:57 keltezéssel, j.gli...@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; nby> min; nby--) {
+ size = nby * surf.nbx * surf.bpe *
surf.nsamples;
Re: [PATCH] drm/radeon: fix tiling and command stream checking on evergreen v3
On Sat, Jun 9, 2012 at 12:15 PM, Boszormenyi Zoltan wrote:
> 2012-06-09 16:57 keltezéssel, j.gli...@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 50657] [Evergreen,GIT,Tiling?] Occasional invalid command stream and subsequent performance increase
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. ___ 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
> 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, &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
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. ___ 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
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.
___
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
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 ___ 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
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. ___ 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
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. ___ 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
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. ___ 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
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. ___ 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
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. ___ 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
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. ___ 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
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
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. ___ 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
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. ___ 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
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 ((tmp + size * mslice
[Bug 46713] HDMI audio played back at a wrong rate
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. ___ 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
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. ___ 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
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. ___ 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
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.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
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. ___ 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
2012-06-09 16:57 keltezéssel, j.gli...@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; nby> min; nby--) {
+ size = nby * surf.nbx * surf.bpe *
surf.nsamples;
Re: [PATCH] drm/radeon: fix tiling and command stream checking on evergreen v3
On Sat, Jun 9, 2012 at 12:15 PM, Boszormenyi Zoltan wrote:
> 2012-06-09 16:57 keltezéssel, j.gli...@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 50657] [Evergreen,GIT,Tiling?] Occasional invalid command stream and subsequent performance increase
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. ___ 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
> 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, &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
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. ___ 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
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.
___
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
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 ___ 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
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. ___ 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
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. ___ 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
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. ___ 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
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. ___ 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
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. ___ 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
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. ___ 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
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
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. ___ 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
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. ___ 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
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 ((tmp + size * mslice
[Bug 46713] HDMI audio played back at a wrong rate
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. ___ 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
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. ___ 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
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. ___ 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
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.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
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. ___ 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
2012-06-09 16:57 keltezéssel, j.gli...@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; nby> min; nby--) {
+ size = nby * surf.nbx * surf.bpe *
surf.nsamples;
Re: [PATCH] drm/radeon: fix tiling and command stream checking on evergreen v3
On Sat, Jun 9, 2012 at 12:15 PM, Boszormenyi Zoltan wrote:
> 2012-06-09 16:57 keltezéssel, j.gli...@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 50657] [Evergreen,GIT,Tiling?] Occasional invalid command stream and subsequent performance increase
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. ___ 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
> 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, &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
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. ___ 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
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.
___
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
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 ___ 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
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. ___ 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
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. ___ 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
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. ___ 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
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. ___ 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
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. ___ 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
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. ___ 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
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
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. ___ 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
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. ___ 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
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 ((tmp + size * mslice
[Bug 46713] HDMI audio played back at a wrong rate
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. ___ 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
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. ___ 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
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. ___ 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
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.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
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. ___ 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
2012-06-09 16:57 keltezéssel, j.gli...@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; nby> min; nby--) {
+ size = nby * surf.nbx * surf.bpe *
surf.nsamples;
Re: [PATCH] drm/radeon: fix tiling and command stream checking on evergreen v3
On Sat, Jun 9, 2012 at 12:15 PM, Boszormenyi Zoltan wrote:
> 2012-06-09 16:57 keltezéssel, j.gli...@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 50657] [Evergreen,GIT,Tiling?] Occasional invalid command stream and subsequent performance increase
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. ___ 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
> 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, &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
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. ___ 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
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.
___
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
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 ___ 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
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. ___ 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
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. ___ 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
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. ___ 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
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. ___ 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
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. ___ 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
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. ___ 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
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
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. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
