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
[git pull] drm intel + exynos fixes
On Fri, Jun 8, 2012 at 11:57 PM, Linus Torvalds wrote: > This breaks things for me. Bisect says: > > 9e612a008fa7fe493a473454def56aa321479495 is the first bad commit > commit 9e612a008fa7fe493a473454def56aa321479495 > Author: Chris Wilson > Date: ? Thu May 31 13:08:53 2012 +0100 > > ? ?drm/i915/crt: Do not rely upon the HPD presence pin > > ? ?Whilst most monitors do wire up the HPD presence pin, it seems quite a > ? ?few KVM do not. Therefore if we simply rely on the HPD pin being > ? ?asserted to indicate a connected monitor we fail miserable, so fall back > ? ?to performing a DCC query for the EDID. > > ? ?Reported-and-tested-by: Matthieu LAVIE > ? ?Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50501 > ? ?Signed-off-by: Chris Wilson > ? ?Signed-off-by: Daniel Vetter > > And the symptoms are that it boots in what appears to be the correct > mode for my monitor (1920x1200), but when X starts it changes to > 1024x768 mode. > > Which is not good, and not useful. > > The bad kernel has this in Xorg.0.log: > > ?[ ? ?12.796] (II) intel(0): EDID for output VGA1 > ?[ ? ?12.796] (II) intel(0): Printing probed modes for output VGA1 > ?[ ? ?12.796] (II) intel(0): Modeline "1024x768"x60.0 ? 65.00 ?1024 > 1048 1184 1344 ?768 771 777 806 -hsync -vsync (48.4 kHz e) > ?[ ? ?12.796] (II) intel(0): Modeline "800x600"x60.3 ? 40.00 ?800 840 > 968 1056 ?600 601 605 628 +hsync +vsync (37.9 kHz e) > ?[ ? ?12.796] (II) intel(0): Modeline "800x600"x56.2 ? 36.00 ?800 824 > 896 1024 ?600 601 603 625 +hsync +vsync (35.2 kHz e) > ?[ ? ?12.796] (II) intel(0): Modeline "848x480"x60.0 ? 33.75 ?848 864 > 976 1088 ?480 486 494 517 +hsync +vsync (31.0 kHz e) > ?[ ? ?12.796] (II) intel(0): Modeline "640x480"x59.9 ? 25.18 ?640 656 > 752 800 ?480 489 492 525 -hsync -vsync (31.5 kHz e) > > which is pure and utter garbage. I think it's the "default modes" for > the non-EDID case, and has nothing to do with actual hardware. > > The good kernel doesn't have those incorrect and bogus probed modes, > and just has the correct HDMI1 (that the bad kernel *also* has, of > course). > > I have reverted that commit as obviously broken, since I'm not going > to release an -rc2 that doesn't even work for me (and since it *is* > obviously broken). I've looked again through the code and with this patch we can fall through to the gen2/3 load detect code, which likely results totally bogus results for anything never (where we've previously relied exclusively on the hotplug pins). Sorry for not catching this when I've reviewed this patch for -fixes. Hence for the revert: Acked-by: Daniel Vetter -Daniel -- Daniel Vetter daniel.vetter at ffwll.ch - +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH] RFC drm: Do not leak connector_status_unknown to userspace
A detect() probe may return 'unknown' to indicate that it was not able
to successfully determine the connector status. However, exposing this
to userspace just results in lots of confusion as it is uncertain
whether or not that is a valid connection. The usual result is for X to
create a mode that encompasses the unknown connector causing an abnormal
setup on the known good outputs.
This patch initialises the connector status to disconnected and
thereafter ignores indeterminate results from detect(), leaving the
status as the old value. This prevents the status from being set to
unknown, and so leaked to userspace, and so leaves the connector as
disconnected until we have a valid connection and also prevents that
valid connection being dropped due to a failed probe.
The alternative to this is to never return unknown from the drivers, but
return connector->status instead so that the value never changes on a
failed probe (and also to initialise the connector to disconnected in
the driver).
---
drivers/gpu/drm/drm_crtc.c|1 +
drivers/gpu/drm/drm_crtc_helper.c | 20 +---
2 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 08a7aa7..22f58b9 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -495,6 +495,7 @@ int drm_connector_init(struct drm_device *dev,
INIT_LIST_HEAD(&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
[PATCH 0/2] HD-audio HDMI regression fixes with VGA-switcheroo
At Fri, 08 Jun 2012 22:17:29 +0200,
J?rg-Volker Peetz wrote:
>
> Takashi Iwai wrote, on 06/08/12 17:52:
> > At Fri, 08 Jun 2012 17:45:17 +0200,
> > J?rg-Volker Peetz wrote:
> >>
> >> Hello Takashi,
> >>
> >> Takashi Iwai wrote, on 06/08/12 15:03:
> >>> At Fri, 08 Jun 2012 13:26:57 +0200,
> >>> J?rg-Volker Peetz wrote:
>
> Takashi Iwai wrote, on 06/07/12 12:15:
> > Hi,
> >
> > this is a series of patches to fix the regressions of HD-audio HDMI
> > on D-GPUs in 3.5-rc1 due to the support of VGA-switcheroo audio clients.
> >
> > The first patch adds a new helper function to vga-switcheroo and the
> > second just uses that instead of an open code.
> >
> > Dave, if the first patch is OK, I'm going to apply it though sound tree.
> > Let me know if any problem is found.
> >
> > Joerg, could you check whether this doesn't break your setup, too?
> >
> >
> > thanks,
> >
> > Takashi
>
> Hello Takashi,
>
> I applied both your patches on 3.5-rc1. With this kernel I made three
> tests.
> 1) After booting I switched off the discrete GPU via vga_switcheroo.
> Then ca. 210 times the message
>
> hda-intel: spurious response 0x0:0x0, last cmd=0x170503
>
> appears on the console and in the logs.
> Starting X and using the built-in USB web-cam work, as well as sound
> with
> mplayer2 works.
>
> 2) After booting I switched to the discrete GPU via
>
> echo -n DDIS > /sys/kernel/debugfs/vgaswitcheroo/switch
>
> Then I started X via startx. The desktop screen appears but the system
> freezes. No reaction on keyboard or touchpad input. The computer is
> not
> reachable via ethernet wire.
> >>>
> >>> Hm, these issues aren't seen on 3.5-rc1 before my patches?
> >>> If so, we need to fix now.
> >>>
> >> No, these issues aren't seen on 3.5-rc1 without your patches. I'm able to
> >> start
> >> X with the discrete GPU in use, direct rendering and the built-in USB
> >> camera work.
> >
> > OK, it means that the switching from the audio-ON to audio-OFF doesn't
> > work. Could you try the patch below in additon?
> >
>
> Applying all your three patches on 3.5-rc1 makes the discrete GPU work on my
> system: after mounting debugfs and switching to "DDIS", I can start X and
> direct
> rendering, sound and built-in USB camera work.
Good to hear.
Dave, is it OK to apply the patch below through sound tree?
thanks,
Takashi
---
From: Takashi Iwai
Subject: [PATCH] vga_switcheroo: Enable/disable audio clients at the right time
The audio clients have to be disabled before disabling the VGA and
switching. Similarly, enabling the audio client should be done at
last. Otherwise the audio-side operation stalls, eventually leading
to Oops or lockups.
Tested-by: J?rg-Volker Peetz
Signed-off-by: Takashi Iwai
---
drivers/gpu/vga/vga_switcheroo.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga/vga_switcheroo.c
index 38f9534..e24ad99 100644
--- a/drivers/gpu/vga/vga_switcheroo.c
+++ b/drivers/gpu/vga/vga_switcheroo.c
@@ -291,8 +291,6 @@ static int vga_switchto_stage1(struct vga_switcheroo_client
*new_client)
vga_switchon(new_client);
vga_set_default_device(new_client->pdev);
- set_audio_state(new_client->id, VGA_SWITCHEROO_ON);
-
return 0;
}
@@ -308,6 +306,8 @@ static int vga_switchto_stage2(struct vga_switcheroo_client
*new_client)
active->active = false;
+ set_audio_state(active->id, VGA_SWITCHEROO_OFF);
+
if (new_client->fb_info) {
struct fb_event event;
event.info = new_client->fb_info;
@@ -321,11 +321,11 @@ static int vga_switchto_stage2(struct
vga_switcheroo_client *new_client)
if (new_client->ops->reprobe)
new_client->ops->reprobe(new_client->pdev);
- set_audio_state(active->id, VGA_SWITCHEROO_OFF);
-
if (active->pwr_state == VGA_SWITCHEROO_ON)
vga_switchoff(active);
+ set_audio_state(new_client->id, VGA_SWITCHEROO_ON);
+
new_client->active = true;
return 0;
}
@@ -371,8 +371,9 @@ vga_switcheroo_debugfs_write(struct file *filp, const char
__user *ubuf,
/* pwr off the device not in use */
if (strncmp(usercmd, "OFF", 3) == 0) {
list_for_each_entry(client, &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
[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-devel at alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-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.
[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.
[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
[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.
[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.
[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.
[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.
[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.
[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.
[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 at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48
[Bug 50696] HDMI Audio is Choppy on RS880M / 4200
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.
[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.
[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.
[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.
[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.
[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.vetter at ffwll.ch - +41 (0) 79 364 57 48 - http://blog.ffwll.ch
[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.
[PATCH] drm/radeon: fix tiling and command stream checking on evergreen v3
2012-06-09 16:57 keltez?ssel, j.glisse at gmail.com ?rta:
> From: Jerome Glisse
>
> Fix regresson since the introduction of command stream checking on
> evergreen (thread referenced below). Issue is cause by ddx allocating
> bo with formula width*height*bpp while programming the GPU command
> stream with ALIGN(height, 8). In some case (where page alignment does
> not hide the extra size bo should be according to height alignment)
> the kernel will reject the command stream.
>
> This patch reprogram the command stream to slice - 1 (slice is
> a derivative value from height) which avoid rejecting the command
> stream while keeping the value of command stream checking from a
> security point of view.
>
> This patch also fix wrong computation of layer size for 2D tiled
> surface. Which should fix issue when 2D color tiling is enabled.
> This dump the radeon KMS_DRIVER_MINOR so userspace can know if
> they are on a fixed kernel or not.
>
> https://lkml.org/lkml/2012/6/3/80
> https://bugs.freedesktop.org/show_bug.cgi?id=50892
> https://bugs.freedesktop.org/show_bug.cgi?id=50857
>
> !!! STABLE need a custom version of this patch for 3.4 !!!
>
> v2: actually bump the minor version and add comment about stable
> v3: do compute the height the ddx was trying to use
>
> Signed-off-by: Jerome Glisse
> ---
> drivers/gpu/drm/radeon/evergreen_cs.c | 50
> ++---
> drivers/gpu/drm/radeon/radeon_drv.c |3 +-
> 2 files changed, 48 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c
> b/drivers/gpu/drm/radeon/evergreen_cs.c
> index 4e7dd2b..29c43c6 100644
> --- a/drivers/gpu/drm/radeon/evergreen_cs.c
> +++ b/drivers/gpu/drm/radeon/evergreen_cs.c
> @@ -52,6 +52,7 @@ struct evergreen_cs_track {
> u32 cb_color_view[12];
> u32 cb_color_pitch[12];
> u32 cb_color_slice[12];
> + u32 cb_color_slice_idx[12];
> u32 cb_color_attrib[12];
> u32 cb_color_cmask_slice[8];/* unused */
> u32 cb_color_fmask_slice[8];/* unused */
> @@ -127,12 +128,14 @@ static void evergreen_cs_track_init(struct
> evergreen_cs_track *track)
> track->cb_color_info[i] = 0;
> track->cb_color_view[i] = 0x;
> track->cb_color_pitch[i] = 0;
> - track->cb_color_slice[i] = 0;
> + track->cb_color_slice[i] = 0xfff;
> + track->cb_color_slice_idx[i] = 0;
> }
> track->cb_target_mask = 0x;
> track->cb_shader_mask = 0x;
> track->cb_dirty = true;
>
> + track->db_depth_slice = 0x;
> track->db_depth_view = 0xC000;
> track->db_depth_size = 0x;
> track->db_depth_control = 0x;
> @@ -250,10 +253,9 @@ static int evergreen_surface_check_2d(struct
> radeon_cs_parser *p,
> {
> struct evergreen_cs_track *track = p->track;
> unsigned palign, halign, tileb, slice_pt;
> + unsigned mtile_pr, mtile_ps, mtileb;
>
> tileb = 64 * surf->bpe * surf->nsamples;
> - palign = track->group_size / (8 * surf->bpe * surf->nsamples);
> - palign = MAX(8, palign);
> slice_pt = 1;
> if (tileb> surf->tsplit) {
> slice_pt = tileb / surf->tsplit;
> @@ -262,7 +264,10 @@ static int evergreen_surface_check_2d(struct
> radeon_cs_parser *p,
> /* macro tile width& height */
> palign = (8 * surf->bankw * track->npipes) * surf->mtilea;
> halign = (8 * surf->bankh * surf->nbanks) / surf->mtilea;
> - surf->layer_size = surf->nbx * surf->nby * surf->bpe * slice_pt;
> + mtileb = (palign / 8) * (halign / 8) * tileb;;
> + mtile_pr = surf->nbx / palign;
> + mtile_ps = (mtile_pr * surf->nby) / halign;
> + surf->layer_size = mtile_ps * mtileb * slice_pt;
> surf->base_align = (palign / 8) * (halign / 8) * tileb;
> surf->palign = palign;
> surf->halign = halign;
> @@ -434,6 +439,39 @@ static int evergreen_cs_track_validate_cb(struct
> radeon_cs_parser *p, unsigned i
>
> offset += surf.layer_size * mslice;
> if (offset> radeon_bo_size(track->cb_color_bo[id])) {
> + /* old ddx are broken they allocate bo with w*h*bpp but
> + * program slice with ALIGN(h, 8), catch this and patch
> + * command stream.
> + */
> + if (!surf.mode) {
> + volatile u32 *ib = p->ib.ptr;
> + unsigned long tmp, nby, bsize, size, min = 0;
> +
> + /* find the height the ddx wants */
> + if (surf.nby> 8) {
> + min = surf.nby - 8;
> + }
> + bsize = radeon_bo_size(track->cb_color_bo[id]);
> + tmp = track->cb_color_bo_offset[id]<< 8;
> + for (nby = surf.nby; nby>
[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.glisse at gmail.com ?rta:
>>
>> From: Jerome Glisse
>>
>> Fix regresson since the introduction of command stream checking on
>> evergreen (thread referenced below). Issue is cause by ddx allocating
>> bo with formula width*height*bpp while programming the GPU command
>> stream with ALIGN(height, 8). In some case (where page alignment does
>> not hide the extra size bo should be according to height alignment)
>> the kernel will reject the command stream.
>>
>> This patch reprogram the command stream to slice - 1 (slice is
>> a derivative value from height) which avoid rejecting the command
>> stream while keeping the value of command stream checking from a
>> security point of view.
>>
>> This patch also fix wrong computation of layer size for 2D tiled
>> surface. Which should fix issue when 2D color tiling is enabled.
>> This dump the radeon KMS_DRIVER_MINOR so userspace can know if
>> they are on a fixed kernel or not.
>>
>> https://lkml.org/lkml/2012/6/3/80
>> https://bugs.freedesktop.org/show_bug.cgi?id=50892
>> https://bugs.freedesktop.org/show_bug.cgi?id=50857
>>
>> !!! STABLE need a custom version of this patch for 3.4 !!!
>>
>> v2: actually bump the minor version and add comment about stable
>> v3: do compute the height the ddx was trying to use
>>
>> Signed-off-by: Jerome Glisse
>> ---
>> ?drivers/gpu/drm/radeon/evergreen_cs.c | ? 50
>> ++---
>> ?drivers/gpu/drm/radeon/radeon_drv.c ? | ? ?3 +-
>> ?2 files changed, 48 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c
>> b/drivers/gpu/drm/radeon/evergreen_cs.c
>> index 4e7dd2b..29c43c6 100644
>> --- a/drivers/gpu/drm/radeon/evergreen_cs.c
>> +++ b/drivers/gpu/drm/radeon/evergreen_cs.c
>> @@ -52,6 +52,7 @@ struct evergreen_cs_track {
>> ? ? ? ?u32 ? ? ? ? ? ? ? ? ? ? cb_color_view[12];
>> ? ? ? ?u32 ? ? ? ? ? ? ? ? ? ? cb_color_pitch[12];
>> ? ? ? ?u32 ? ? ? ? ? ? ? ? ? ? cb_color_slice[12];
>> + ? ? ? u32 ? ? ? ? ? ? ? ? ? ? cb_color_slice_idx[12];
>> ? ? ? ?u32 ? ? ? ? ? ? ? ? ? ? cb_color_attrib[12];
>> ? ? ? ?u32 ? ? ? ? ? ? ? ? ? ? cb_color_cmask_slice[8];/* unused */
>> ? ? ? ?u32 ? ? ? ? ? ? ? ? ? ? cb_color_fmask_slice[8];/* unused */
>> @@ -127,12 +128,14 @@ static void evergreen_cs_track_init(struct
>> evergreen_cs_track *track)
>> ? ? ? ? ? ? ? ?track->cb_color_info[i] = 0;
>> ? ? ? ? ? ? ? ?track->cb_color_view[i] = 0x;
>> ? ? ? ? ? ? ? ?track->cb_color_pitch[i] = 0;
>> - ? ? ? ? ? ? ? track->cb_color_slice[i] = 0;
>> + ? ? ? ? ? ? ? track->cb_color_slice[i] = 0xfff;
>> + ? ? ? ? ? ? ? track->cb_color_slice_idx[i] = 0;
>> ? ? ? ?}
>> ? ? ? ?track->cb_target_mask = 0x;
>> ? ? ? ?track->cb_shader_mask = 0x;
>> ? ? ? ?track->cb_dirty = true;
>>
>> + ? ? ? track->db_depth_slice = 0x;
>> ? ? ? ?track->db_depth_view = 0xC000;
>> ? ? ? ?track->db_depth_size = 0x;
>> ? ? ? ?track->db_depth_control = 0x;
>> @@ -250,10 +253,9 @@ static int evergreen_surface_check_2d(struct
>> radeon_cs_parser *p,
>> ?{
>> ? ? ? ?struct evergreen_cs_track *track = p->track;
>> ? ? ? ?unsigned palign, halign, tileb, slice_pt;
>> + ? ? ? unsigned mtile_pr, mtile_ps, mtileb;
>>
>> ? ? ? ?tileb = 64 * surf->bpe * surf->nsamples;
>> - ? ? ? palign = track->group_size / (8 * surf->bpe * surf->nsamples);
>> - ? ? ? palign = MAX(8, palign);
>> ? ? ? ?slice_pt = 1;
>> ? ? ? ?if (tileb> ?surf->tsplit) {
>> ? ? ? ? ? ? ? ?slice_pt = tileb / surf->tsplit;
>> @@ -262,7 +264,10 @@ static int evergreen_surface_check_2d(struct
>> radeon_cs_parser *p,
>> ? ? ? ?/* macro tile width& ?height */
>>
>> ? ? ? ?palign = (8 * surf->bankw * track->npipes) * surf->mtilea;
>> ? ? ? ?halign = (8 * surf->bankh * surf->nbanks) / surf->mtilea;
>> - ? ? ? surf->layer_size = surf->nbx * surf->nby * surf->bpe * slice_pt;
>> + ? ? ? mtileb = (palign / 8) * (halign / 8) * tileb;;
>> + ? ? ? mtile_pr = surf->nbx / palign;
>> + ? ? ? mtile_ps = (mtile_pr * surf->nby) / halign;
>> + ? ? ? surf->layer_size = mtile_ps * mtileb * slice_pt;
>> ? ? ? ?surf->base_align = (palign / 8) * (halign / 8) * tileb;
>> ? ? ? ?surf->palign = palign;
>> ? ? ? ?surf->halign = halign;
>> @@ -434,6 +439,39 @@ static int evergreen_cs_track_validate_cb(struct
>> radeon_cs_parser *p, unsigned i
>>
>> ? ? ? ?offset += surf.layer_size * mslice;
>> ? ? ? ?if (offset> ?radeon_bo_size(track->cb_color_bo[id])) {
>> + ? ? ? ? ? ? ? /* old ddx are broken they allocate bo with w*h*bpp but
>> + ? ? ? ? ? ? ? ?* program slice with ALIGN(h, 8), catch this and patch
>> + ? ? ? ? ? ? ? ?* command stream.
>> + ? ? ? ? ? ? ? ?*/
>> + ? ? ? ? ? ? ? if (!surf.mode) {
>> + ? ? ? ? ? ? ? ? ? ? ? volatile u32 *ib = p->ib.ptr;
>> + ? ? ? ? ? ? ? ? ? ? ? unsigned long tmp, nby, bsize, size, min = 0;
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? /* find the height the ddx wants */
>> + ? ? ? ? ? ? ? ? ? ? ? if (surf.nby> ?8) {
>> + ? ? ? ? ? ? ? ? ? ? ?
[Bug 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.
[Linaro-mm-sig] [RFC] Synchronizing access to buffers shared with dma-buf between drivers/devices
On Fri, Jun 8, 2012 at 3:56 PM, Erik Gilling wrote: >> I guess my other thought is that implicit vs explicit is not >> mutually exclusive, though I'd guess there'd be interesting >> deadlocks to have to debug if both were in use _at the same >> time_. :-) > > I think this is an approach worth investigating. ?I'd like a way to > either opt out of implicit sync or have a way to check if a dma-buf > has an attached fence and detach it. ?Actually, that could work really > well. Consider: > > * Each dma_buf has a single fence "slot" > * on submission > ? * the driver will extract the fence from the dma_buf and queue a wait on it. > ? * the driver will replace that fence with it's own complettion > fence before the job submission ioctl returns. > * dma_buf will have two userspace ioctls: > ? * DETACH: will return the fence as an FD to userspace and clear the > fence slot in the dma_buf > ? * ATTACH: takes a fence FD from userspace and attaches it to the > dma_buf fence slot. ?Returns an error if the fence slot is non-empty. > > In the android case, we can do a detach after every submission and an > attach right before. btw, I like this idea for implicit and explicit sync to coexist BR, -R
