[PATCH 3/3 v3] drm/i915: hot plug/unplug notification to HDMI audio driver

[Wu Fengguang]

On monitor hot plug/unplug, update ELD and set/clear SDVO_AUDIO_ENABLE
or DP_AUDIO_OUTPUT_ENABLE accordingly.  So that the audio driver will
receive hot plug events and take action to refresh its device state and
ELD contents.

A new callback ->hotplug() is added to struct drm_connector_funcs which
will be called immediately after ->detect() knowing that the monitor is
either plugged or unplugged.

It's noticed that X may not call ->mode_set() at monitor hot plug, so it's
necessary to call drm_edid_to_eld() earlier at ->detect() time rather than
in intel_ddc_get_modes(), so that intel_write_eld() can see the new ELD
in ->hotplug.

The call sequence on hot plug is
(the difference part lies in ->mode_set vs ->hotplug)

- KMS console
->detect
  drm_edid_to_eld
->mode_set
  intel_write_eld
  set SDVO_AUDIO_ENABLE/DP_AUDIO_OUTPUT_ENABLE
- X
->detect
  drm_edid_to_eld
->hotplug
  intel_write_eld
  set SDVO_AUDIO_ENABLE/DP_AUDIO_OUTPUT_ENABLE

On hot remove, the call sequence is

->hotplug
  clear SDVO_AUDIO_ENABLE/DP_AUDIO_OUTPUT_ENABLE

cc: Wang Zhenyu 
Signed-off-by: Wu Fengguang 
---
 drivers/gpu/drm/drm_crtc_helper.c  |6 +++
 drivers/gpu/drm/i915/intel_dp.c|   44 +--
 drivers/gpu/drm/i915/intel_hdmi.c  |   31 +++
 drivers/gpu/drm/i915/intel_modes.c |2 -
 include/drm/drm_crtc.h |1 
 5 files changed, 72 insertions(+), 12 deletions(-)

Changes since v2:

Fix "kernel NULL pointer dereference" due to calling NULL ->hotplug.

--- linux.orig/drivers/gpu/drm/i915/intel_dp.c  2011-11-21 11:26:09.0 
+0800
+++ linux/drivers/gpu/drm/i915/intel_dp.c   2011-11-21 14:12:21.0 
+0800
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "drmP.h"
 #include "drm.h"
 #include "drm_crtc.h"
@@ -1970,20 +1971,44 @@ intel_dp_detect(struct drm_connector *co
if (status != connector_status_connected)
return status;
 
-   if (intel_dp->force_audio) {
-   intel_dp->has_audio = intel_dp->force_audio > 0;
-   } else {
-   edid = intel_dp_get_edid(connector, &intel_dp->adapter);
-   if (edid) {
-   intel_dp->has_audio = drm_detect_monitor_audio(edid);
-   connector->display_info.raw_edid = NULL;
-   kfree(edid);
-   }
+   edid = intel_dp_get_edid(connector, &intel_dp->adapter);
+   if (edid) {
+   intel_dp->has_audio = drm_detect_monitor_audio(edid);
+   drm_edid_to_eld(connector, edid);
+   connector->display_info.raw_edid = NULL;
+   kfree(edid);
}
 
+   if (intel_dp->force_audio)
+   intel_dp->has_audio = intel_dp->force_audio > 0;
+
return connector_status_connected;
 }
 
+static void intel_dp_hotplug(struct drm_connector *connector)
+{
+   struct intel_dp *intel_dp = intel_attached_dp(connector);
+   struct drm_device *dev = intel_dp->base.base.dev;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct drm_crtc *crtc = intel_dp->base.base.crtc;
+
+   DRM_DEBUG_DRIVER("DisplayPort hotplug status %d crtc %p eld %#x\n",
+connector->status,
+crtc,
+(unsigned int)connector->eld[0]);
+
+   if (connector->status == connector_status_disconnected) {
+   intel_dp->DP &= ~DP_AUDIO_OUTPUT_ENABLE;
+   } else if (connector->status == connector_status_connected && crtc) {
+   intel_write_eld(&intel_dp->base.base, &crtc->mode);
+   intel_dp->DP |= DP_AUDIO_OUTPUT_ENABLE;
+   } else {
+   return;
+   }
+   I915_WRITE(intel_dp->output_reg, intel_dp->DP);
+   POSTING_READ(intel_dp->output_reg);
+}
+
 static int intel_dp_get_modes(struct drm_connector *connector)
 {
struct intel_dp *intel_dp = intel_attached_dp(connector);
@@ -2143,6 +2168,7 @@ static const struct drm_connector_funcs 
.detect = intel_dp_detect,
.fill_modes = drm_helper_probe_single_connector_modes,
.set_property = intel_dp_set_property,
+   .hotplug = intel_dp_hotplug,
.destroy = intel_dp_destroy,
 };
 
--- linux.orig/drivers/gpu/drm/i915/intel_hdmi.c2011-11-21 
11:26:09.0 +0800
+++ linux/drivers/gpu/drm/i915/intel_hdmi.c 2011-11-21 14:12:26.0 
+0800
@@ -337,6 +337,7 @@ intel_hdmi_detect(struct drm_connector *
status = connector_status_connected;
intel_hdmi->has_hdmi_sink = 
drm_detect_hdmi_monitor(edid);
intel_hdmi->has_audio = drm_detect_monitor_audio(edid);
+   drm_edid_to_eld(connector, edid);
}
connector->display_info.raw_edid = NULL;
kfree(edid);
@@ -350,6 +351,35 @@ intel_hdm

Re: [PATCH 3/3] drm/i915: hot removal notification to HDMI audio driver

[Takashi Iwai]

At Mon, 21 Nov 2011 09:58:09 +0800,
Wu Fengguang wrote:
> 
> On Sat, Nov 19, 2011 at 01:46:44AM +0800, Keith Packard wrote:
> > On Fri, 18 Nov 2011 17:37:40 +0800, Wu Fengguang  
> > wrote:
> > 
> > > However when in X, ->mode_set won't be called at all.  Only
> > > ->get_modes and ->detect are called...
> > 
> > The desktop software will call mode_set when it configures the
> > monitor. Otherwise, it's not being used (and so shouldn't have audio
> > routed to it by default).
> 
> Keith, I experimented playing HDMI audio in X, and during the time
> unplug and plug the monitor. The HDMI audio/graphics all continue to
> work when plugged in the monitor again. Here is the dmesg showed for
> the plug event, no ->mode_set is called at all...

Which desktop system are you using?  At hotplug/unplugging, the kernel
drm issues a udev event, X Intel driver receives it and updates
Xrandr.  Then it's supposed that a daemon like gnome-settings-daemon
receives Xrandr notification and changes the modes appropriately.
Without such a background task, there will be no mode change.


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

Re: [Intel-gfx] [PATCH 01/13] drm/i915: fall through pwrite_gtt_slow to the shmem slow path

[Chris Wilson]

On Sun, 20 Nov 2011 19:09:18 -0800, Ben Widawsky  wrote:
> On Sun,  6 Nov 2011 20:13:48 +0100
> Daniel Vetter  wrote:
> 
> > The gtt_pwrite slowpath grabs the userspace memory with
> > get_user_pages. This will not work for non-page backed memory, like a
> > gtt mmapped gem object. Hence fall throuh to the shmem paths if we hit
> > -EFAULT in the gtt paths.
> > 
> > Now the shmem paths have exactly the same problem, but this way we
> > only need to rearrange the code in one write path.
> > 
> > v2: v1 accidentaly falls back to shmem pwrite for phys objects. Fixed.
> > 
> > Signed-Off-by: Daniel Vetter 
> 
> It would be nice if there was some way to notify users that pwriting a
> gtt mmapped address can be really damn slow. That's also the one
> behavior change this patch introduces. It's possible that some SW was
> expecting to get a, "fast path" and would deal with the -EFAULT if it
> didn't get it.

The behaviour change is intentional. Before this patch we would
deadlock...
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/ttm: pass buffer object for bind/unbind callback

[Thomas Hellstrom]

On 11/20/2011 04:13 PM, Jerome Glisse wrote:

On Sun, Nov 20, 2011 at 4:30 AM, Thomas Hellstrom  wrote:
   

On 11/19/2011 11:54 PM, Jerome Glisse wrote:

As mentioned previously, and in the discussion with Ben, the page tables
would not need to be rebuilt on each CS. They would be rebuilt only on the
first CS following a move_notify that caused a page table invalidation.

move_notify:
if (is_incompatible(new_mem_type)) {
  bo->page_tables_invalid = true;
  invalidate_page_tables(bo);
}

command_submission:
if (bo->page_tables_invalid) {
   set_up_page_tables(bo);
   bo->page_tables_invalid = false;
}


Why is it different from updating page table in move notify ? I don't
see any bonus here, all the information we need are already available
in move_notify.



I've iterated the pros of this approach at least two times before, but for
completeness let's do it again:

8<

1) TTM doesn't need to care about the driver re-populating its GPU page
tables.
Since swapin is handled from the tt layer not the bo layer, this makes it a
bit easier on us.
2) Transition to page-faulted GPU virtual maps is straightforward and
consistent. A non-page-faulting driver sets up the maps at CS time, A
pagefaulting driver can set them up directly from an irq handler without
reserving, since the bo is properly fenced or pinned when the pagefault
happens.
3) A non-page-faulting driver knows at CS time exactly which
page-table-entries really do need populating, and can do this more
efficiently.

8<-

And some extra items like partially populated TTMs that were mentioned
elsewhere.
 

If done in move_notify i don't see why 1 would be different or 2.


Because to make the interface complete we need to support SYSTEM memory, 
and call move_notify from swapin, which I am not prepared to do.



  I
agree that in some case 3 is true. Given when move notify is call the
ttm_tt is always fully populated at that point (only exception is in
destroy path but it's a special on its own). If driver populate in
move_notify is doesn't change anything from ttm pov.
   


Then you put a restriction on TTM to *always* have populated TTMs which 
I am also not prepared to accept. It's been recently added as a 
performance optimization.


I won't spend any more time on this completely stupid argument. I've 
been asking you to make a minor change in order to get a complete and 
clean interface, and to get people to do the right thing in the future. 
You're obviously unwilling to do that.



/Thomas

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

Re: [PATCH 3/3] drm/i915: hot removal notification to HDMI audio driver

[Wu Fengguang]

On Mon, Nov 21, 2011 at 04:47:38PM +0800, Takashi Iwai wrote:
> At Mon, 21 Nov 2011 09:58:09 +0800,
> Wu Fengguang wrote:
> > 
> > On Sat, Nov 19, 2011 at 01:46:44AM +0800, Keith Packard wrote:
> > > On Fri, 18 Nov 2011 17:37:40 +0800, Wu Fengguang  
> > > wrote:
> > > 
> > > > However when in X, ->mode_set won't be called at all.  Only
> > > > ->get_modes and ->detect are called...
> > > 
> > > The desktop software will call mode_set when it configures the
> > > monitor. Otherwise, it's not being used (and so shouldn't have audio
> > > routed to it by default).
> > 
> > Keith, I experimented playing HDMI audio in X, and during the time
> > unplug and plug the monitor. The HDMI audio/graphics all continue to
> > work when plugged in the monitor again. Here is the dmesg showed for
> > the plug event, no ->mode_set is called at all...
> 
> Which desktop system are you using?  At hotplug/unplugging, the kernel
> drm issues a udev event, X Intel driver receives it and updates
> Xrandr.  Then it's supposed that a daemon like gnome-settings-daemon
> receives Xrandr notification and changes the modes appropriately.
> Without such a background task, there will be no mode change.

Ah I got it. I'm running debian+fluxbox w/o those fancy features...

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

[PATCH -fixes] ttm: Don't return the bo reserved on error path

[Thomas Hellstrom]

An unlikely race could case a bo to be returned reserved on an error path.

Signed-off-by: Thomas Hellstrom 
---
 drivers/gpu/drm/ttm/ttm_bo.c |8 +++-
 1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 617b646..0bb0f5f 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -574,10 +574,16 @@ retry:
return ret;
 
spin_lock(&glob->lru_lock);
+
+   if (unlikely(list_empty(&bo->ddestroy))) {
+   spin_unlock(&glob->lru_lock);
+   return 0;
+   }
+
ret = ttm_bo_reserve_locked(bo, interruptible,
no_wait_reserve, false, 0);
 
-   if (unlikely(ret != 0) || list_empty(&bo->ddestroy)) {
+   if (unlikely(ret != 0)) {
spin_unlock(&glob->lru_lock);
return ret;
}
-- 
1.7.4.4

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

[PATCH -fixes 0/3] Documentation updates

[Thomas Hellstrom]

A couple of updates to various interface docs

In-Reply-To: 

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

[PATCH 1/3] drm: Update the DRM_IOCTL_MODE_CURSOR documentation

[Thomas Hellstrom]

Document that DRM_IOCTL_MODE_CURSOR needs to be called in order to
guarantee that the cursor bo contents is updated to the screen.
This was agreed upon on the DRI mailing list.

Signed-off-by: Thomas Hellstrom 
---
 include/drm/drm_mode.h |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
index d30bedf..9006b93 100644
--- a/include/drm/drm_mode.h
+++ b/include/drm/drm_mode.h
@@ -291,6 +291,11 @@ struct drm_mode_mode_cmd {
  *crtc
  *x
  *y
+ *
+ * The DRM_IOCTL_MODE_CURSOR ioctl needs to be called with the CURSOR_BO flag
+ * in order to guarantee that the cursor image is updated. The implementation
+ * is free to either update the cursor image when the bo contents change, or
+ * when the DRM_IOCTL_MODE_CURSOR ioctl is called.
  */
 struct drm_mode_cursor {
__u32 flags;
-- 
1.7.4.4

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

[PATCH 2/3] drm: Update the pageflip ioctl documentation

[Thomas Hellstrom]

The pageflip semantics documentation was tailored to Intel hardware, where
pageflips are done by banging on registers. Many GPUs have the possibilities
to send pageflips down the command stream, and the driver command submission
mechanism does not have to block in order to order page-flip and command
execution. Also remove the sync-to-vblank requirement. Some hardware doesn't
support it, and it might not be desired in all situations either.
I think all this was brought up on the DRI-devel email list on the pageflip
ioctl design discussion.

Signed-off-by: Thomas Hellstrom 
---
 include/drm/drm_mode.h |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
index 9006b93..d88ef35 100644
--- a/include/drm/drm_mode.h
+++ b/include/drm/drm_mode.h
@@ -327,9 +327,9 @@ struct drm_mode_crtc_lut {
  * This ioctl will ask KMS to schedule a page flip for the specified
  * crtc.  Once any pending rendering targeting the specified fb (as of
  * ioctl time) has completed, the crtc will be reprogrammed to display
- * that fb after the next vertical refresh.  The ioctl returns
- * immediately, but subsequent rendering to the current fb will block
- * in the execbuffer ioctl until the page flip happens.  If a page
+ * that fb. The ioctl returns immediately, and subsequently queued rendering
+ * to any of the involved fbs will be ordered with the page flip so that it
+ * occurs after the page-flip is ececuted by the hardware. If a page
  * flip is already pending as the ioctl is called, EBUSY will be
  * returned.
  *
-- 
1.7.4.4

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

[PATCH 3/3] ttm: Update move_notify and swap_notify documentation.

[Thomas Hellstrom]

Update the documentation of these callbacks to reflect the TTM supported
way of setting up driver-private GPU maps, hoping to avoid the Radeon way
leaking into new drivers.

Signed-off-by: Thomas Hellstrom 
---
 include/drm/ttm/ttm_bo_driver.h |   14 --
 1 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index 94eb143..42c3e64 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -439,7 +439,15 @@ struct ttm_bo_driver {
void *(*sync_obj_ref) (void *sync_obj);
 
/* hook to notify driver about a driver move so it
-* can do tiling things */
+* can do tiling things. This hook can be used to tear
+* down driver private GPU mappings from the BO. It should not,
+* however be used to set up such mappings, since TTM will not
+* call this hook when SYSTEM placed bos are populated with pages.
+* It's recommended that populating driver private GPU maps is
+* done from the command-submission code, where the driver has
+* a more detailed knowledge of exactly what GPU maps need
+* populating.
+*/
void (*move_notify)(struct ttm_buffer_object *bo,
struct ttm_mem_reg *new_mem);
/* notify the driver we are taking a fault on this BO
@@ -447,7 +455,9 @@ struct ttm_bo_driver {
int (*fault_reserve_notify)(struct ttm_buffer_object *bo);
 
/**
-* notify the driver that we're about to swap out this bo
+* notify the driver that we're about to swap out this bo.
+* Any driver private GPU maps pointing to the bo should be
+* teared down at this point.
 */
void (*swap_notify) (struct ttm_buffer_object *bo);
 
-- 
1.7.4.4

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

Re: Bug#649448: udev loading radeon drivers garbles screen output

[Alex Deucher]

On Sun, Nov 20, 2011 at 10:12 PM, Ben Hutchings  wrote:
> On Sun, 2011-11-20 at 19:02 -0600, Jonathan Nieder wrote:
>> reassign 649448 src:linux-2.6 linux-2.6/3.0.0-3
>> severity 649448 important
>> retitle 649448 radeon (evergreen): random-looking pattern of pixels when 
>> firmware not installed
>> tags 649448 + upstream
>> quit
>>
>> Hi Martin,
>>
>> Martin von Gagern wrote:
>>
>> > Version: 3.0.0-3
>> [...]
>> > Just installed a wheezy setup using debootstrap, adding grub-pc and
>> > linux-image-amd64 after the chroot was created. The kernel boots, the
>> > initrd seems all right. When the main system boots up, udev gets launced
>> > pretty early. Soon after it is started, the screen turns into a pretty
>> > random-looking pattern of pixels, making the console pretty unusable.
>> > This also happens in "recovery" i.e. single-user mode.
>> [...]
>> > Possible workarounds seem to include:
>> [...]
>> > - Adding a line "blacklist radeon" to /etc/modprobe.d/blacklist.conf,
>> >   followed by running "depmod -a".
>> [...]
>> >> [  150.125768] r600_cp: Failed to load firmware "radeon/SUMO2_pfp.bin"
>> >> [  150.125818] [drm:evergreen_startup] *ERROR* Failed to load firmware!
>> >> [  150.125859] radeon :00:01.0: disabling GPU acceleration
>>
>> Yes, the radeon driver currently copes poorly when firmware is missing.
>> Compare [1], [2], [3].
>>
>> [...]
>> > Not having GPU accelleration due to lack of free firmware is acceptable.
>> > Not having a usable text console can be a real problem.
>>
>> Agreed.  The radeon driver should be bailing out when firmware is
>> missing for cards that need it, but that is not working for some
>> reason.
> [...]
>
> At the time I converted the radeon driver to load external firmware, it
> was apparently only required for 3D acceleration and both KMS and 2D
> acceleration of X worked without it, at least on those systems I tested
> (which were quite old, R100-R300 families).  Therefore failure to load
> firmware would only result in DRM (3D acceleration support) being
> disabled.
>
> However, it looks like driver support for the R600 family onward now
> absolutely requires the 'RLC' firmware blobs:
>
> commit d8f60cfc93452d0554f6a701aa8e3236cbee4636
> Author: Alex Deucher 
> Date:   Tue Dec 1 13:43:46 2009 -0500
>
>    drm/radeon/kms: Add support for interrupts on r6xx/r7xx chips (v3)
>
> And the 'Northern Islands' GPUs and 'Fusion' APUs appear to require the
> 'MC' firmware blobs:
>
> commit 0af62b0168043896a042b005ff88caa77dd94d04
> Author: Alex Deucher 
> Date:   Thu Jan 6 21:19:31 2011 -0500
>
>    drm/radeon/kms: add ucode loader for NI
>
> Therefore I think that at least r600_init(), rv770_init(),
> evergreen_init() and cayman_init() should be treating failure to load
> firmware as a fatal error.
>

R6xx, r7xx should work ok without the RLC ucode, you just won't get
acceleration.  With chips that require the MC ucode, the driver will
bail if the MC ucode is not available.

Alex

> Ben.
>
> --
> Ben Hutchings
> Teamwork is essential - it allows you to blame someone else.
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 02/13] drm/i915: rewrite shmem_pwrite_slow to use copy_from_user

[Daniel Vetter]

On Sun, Nov 20, 2011 at 09:56:32PM -0800, Ben Widawsky wrote:
[snip the patch]
> Bikeshed, but I would much prefer a #define for the swizzle
> bit/cacheline size.

I've looked at this stuff way too long, so I'm biased, but 64 = cacheline
= dram fetch size = 1 << 64 feels about as natural for me as 4096 =
PAGE_SIZE ...

[snip the patch]

> I must be missing something obvious here...
> Can you explain how this can possibly be considered safe without holding
> struct_mutex?

That's the reason why the commit msg goes through every case and explains
why I think it's safe. The large thing here is that we need to drop the
mutex when calling copy_*_user (at least in the non-atomic slow-paths)
because otherwise we might deadlock with our own pagefault handler.
-Daniel
-- 
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

Re: [PATCH] drm, i915: Fix memory leak in i915_gem_busy_ioctl().

[Daniel Vetter]

On Wed, Nov 16, 2011 at 12:49:28AM +0600, Rakib Mullick wrote:
> 
> A call to i915_add_request() has been made in function i915_gem_busy_ioctl(). 
> i915_add_request can fail,
> so in it's exit path previously allocated memory needs to be freed.
> 
> Signed-off-by: Rakib Mullick 

Indeed, nice catch (albeit totally unlikely to be hit, because the error
only happens when the gpu ceases to progress in the ring, so imo not
stable material). Keith, please pick this up for fixes, thanks.

Reviewed-by: Daniel Vetter 
-- 
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

Re: [PATCH 3/3 v2] drm/i915: hot plug/unplug notification to HDMI audio driver

[Keith Packard]

On Mon, 21 Nov 2011 14:37:49 +0800, Wu Fengguang  wrote:
> On monitor hot plug/unplug, update ELD and set/clear SDVO_AUDIO_ENABLE
> or DP_AUDIO_OUTPUT_ENABLE accordingly.  So that the audio driver will
> receive hot plug events and take action to refresh its device state and
> ELD contents.
> 
> A new callback ->hotplug() is added to struct drm_connector_funcs which
> will be called immediately after ->detect() knowing that the monitor is
> either plugged or unplugged.
> 
> It's noticed that X may not call ->mode_set() at monitor hot plug, so it's
> necessary to call drm_edid_to_eld() earlier at ->detect() time rather than
> in intel_ddc_get_modes(), so that intel_write_eld() can see the new ELD
> in ->hotplug.

The X environment will eventually call mode_set when the user
environment decides to use the monitor. Any audio bits can, and should,
await the user's choice of a video mode before choosing the audio format
to use. We should not be adding eld information until the monitor is in
use.

-- 
keith.pack...@intel.com


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

Re: [PATCH 3/3] drm/i915: hot removal notification to HDMI audio driver

[Keith Packard]

On Mon, 21 Nov 2011 19:05:38 +0800, Wu Fengguang  wrote:

> Ah I got it. I'm running debian+fluxbox w/o those fancy features...

Then you can manually run the 'xrandr' command to configure the new
monitor as desired, at which point the kernel mode_set function will be
called.

-- 
keith.pack...@intel.com


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

[PATCH] drm/radeon/kms: fix up gpio i2c mask bits for r4xx for real

[alexdeucher]

From: Alex Deucher 

Fixes i2c test failures when i2c_algo_bit.bit_test=1.

The hw doesn't actually require a mask, so just set it
to the default mask bits for r1xx-r4xx radeon ddc.

I missed this part the first time through.

Signed-off-by: Alex Deucher 
Cc: sta...@kernel.org
Cc: Jean Delvare 

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/radeon_atombios.c |   12 
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c 
b/drivers/gpu/drm/radeon/radeon_atombios.c
index fecd705..933a2cd 100644
--- a/drivers/gpu/drm/radeon/radeon_atombios.c
+++ b/drivers/gpu/drm/radeon/radeon_atombios.c
@@ -181,6 +181,18 @@ void radeon_atombios_i2c_init(struct radeon_device *rdev)
gpio = &i2c_info->asGPIO_Info[i];
i2c.valid = false;
 
+   /* r4xx mask is technically not used by the hw, so 
patch in the legacy mask bits */
+   if ((rdev->family == CHIP_R420) ||
+   (rdev->family == CHIP_R423) ||
+   (rdev->family == CHIP_RV410)) {
+   if ((le16_to_cpu(gpio->usClkMaskRegisterIndex) 
== 0x0018) ||
+   (le16_to_cpu(gpio->usClkMaskRegisterIndex) 
== 0x0019) ||
+   (le16_to_cpu(gpio->usClkMaskRegisterIndex) 
== 0x001a)) {
+   gpio->ucClkMaskShift = 0x19;
+   gpio->ucDataMaskShift = 0x18;
+   }
+   }
+
/* some evergreen boards have bad data for this entry */
if (ASIC_IS_DCE4(rdev)) {
if ((i == 7) &&
-- 
1.7.3.4

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

Re: [PATCH] drm, i915: Fix memory leak in i915_gem_busy_ioctl().

[Keith Packard]

On Mon, 21 Nov 2011 17:23:06 +0100, Daniel Vetter  wrote:

> Indeed, nice catch (albeit totally unlikely to be hit, because the error
> only happens when the gpu ceases to progress in the ring, so imo not
> stable material). Keith, please pick this up for fixes, thanks.

It's already there and queued for airlied :-)

-- 
keith.pack...@intel.com


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

[PATCH] drm/radeon/kms/atom: unify i2c gpio table handling

[alexdeucher]

From: Alex Deucher 

Split the quirks and i2c_rec assignment into separate
functions used by both radeon_lookup_i2c_gpio() and
radeon_atombios_i2c_init().  This avoids duplicating code
and cases where quirks were only added to one of the
functions.

Signed-off-by: Alex Deucher 
Cc: Jean Delvare 
---
 drivers/gpu/drm/radeon/radeon_atombios.c |  214 --
 1 files changed, 86 insertions(+), 128 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c 
b/drivers/gpu/drm/radeon/radeon_atombios.c
index 933a2cd..d24baf3 100644
--- a/drivers/gpu/drm/radeon/radeon_atombios.c
+++ b/drivers/gpu/drm/radeon/radeon_atombios.c
@@ -62,6 +62,87 @@ union atom_supported_devices {
struct _ATOM_SUPPORTED_DEVICES_INFO_2d1 info_2d1;
 };
 
+static void radeon_lookup_i2c_gpio_quirks(struct radeon_device *rdev,
+ ATOM_GPIO_I2C_ASSIGMENT *gpio,
+ u8 index)
+{
+   /* r4xx mask is technically not used by the hw, so patch in the legacy 
mask bits */
+   if ((rdev->family == CHIP_R420) ||
+   (rdev->family == CHIP_R423) ||
+   (rdev->family == CHIP_RV410)) {
+   if ((le16_to_cpu(gpio->usClkMaskRegisterIndex) == 0x0018) ||
+   (le16_to_cpu(gpio->usClkMaskRegisterIndex) == 0x0019) ||
+   (le16_to_cpu(gpio->usClkMaskRegisterIndex) == 0x001a)) {
+   gpio->ucClkMaskShift = 0x19;
+   gpio->ucDataMaskShift = 0x18;
+   }
+   }
+
+   /* some evergreen boards have bad data for this entry */
+   if (ASIC_IS_DCE4(rdev)) {
+   if ((index == 7) &&
+   (le16_to_cpu(gpio->usClkMaskRegisterIndex) == 0x1936) &&
+   (gpio->sucI2cId.ucAccess == 0)) {
+   gpio->sucI2cId.ucAccess = 0x97;
+   gpio->ucDataMaskShift = 8;
+   gpio->ucDataEnShift = 8;
+   gpio->ucDataY_Shift = 8;
+   gpio->ucDataA_Shift = 8;
+   }
+   }
+
+   /* some DCE3 boards have bad data for this entry */
+   if (ASIC_IS_DCE3(rdev)) {
+   if ((index == 4) &&
+   (le16_to_cpu(gpio->usClkMaskRegisterIndex) == 0x1fda) &&
+   (gpio->sucI2cId.ucAccess == 0x94))
+   gpio->sucI2cId.ucAccess = 0x14;
+   }
+}
+
+static struct radeon_i2c_bus_rec 
radeon_get_bus_rec_for_i2c_gpio(ATOM_GPIO_I2C_ASSIGMENT *gpio)
+{
+   struct radeon_i2c_bus_rec i2c;
+
+   memset(&i2c, 0, sizeof(struct radeon_i2c_bus_rec));
+
+   i2c.mask_clk_reg = le16_to_cpu(gpio->usClkMaskRegisterIndex) * 4;
+   i2c.mask_data_reg = le16_to_cpu(gpio->usDataMaskRegisterIndex) * 4;
+   i2c.en_clk_reg = le16_to_cpu(gpio->usClkEnRegisterIndex) * 4;
+   i2c.en_data_reg = le16_to_cpu(gpio->usDataEnRegisterIndex) * 4;
+   i2c.y_clk_reg = le16_to_cpu(gpio->usClkY_RegisterIndex) * 4;
+   i2c.y_data_reg = le16_to_cpu(gpio->usDataY_RegisterIndex) * 4;
+   i2c.a_clk_reg = le16_to_cpu(gpio->usClkA_RegisterIndex) * 4;
+   i2c.a_data_reg = le16_to_cpu(gpio->usDataA_RegisterIndex) * 4;
+   i2c.mask_clk_mask = (1 << gpio->ucClkMaskShift);
+   i2c.mask_data_mask = (1 << gpio->ucDataMaskShift);
+   i2c.en_clk_mask = (1 << gpio->ucClkEnShift);
+   i2c.en_data_mask = (1 << gpio->ucDataEnShift);
+   i2c.y_clk_mask = (1 << gpio->ucClkY_Shift);
+   i2c.y_data_mask = (1 << gpio->ucDataY_Shift);
+   i2c.a_clk_mask = (1 << gpio->ucClkA_Shift);
+   i2c.a_data_mask = (1 << gpio->ucDataA_Shift);
+
+   if (gpio->sucI2cId.sbfAccess.bfHW_Capable)
+   i2c.hw_capable = true;
+   else
+   i2c.hw_capable = false;
+
+   if (gpio->sucI2cId.ucAccess == 0xa0)
+   i2c.mm_i2c = true;
+   else
+   i2c.mm_i2c = false;
+
+   i2c.i2c_id = gpio->sucI2cId.ucAccess;
+
+   if (i2c.mask_clk_reg)
+   i2c.valid = true;
+   else
+   i2c.valid = false;
+
+   return i2c;
+}
+
 static struct radeon_i2c_bus_rec radeon_lookup_i2c_gpio(struct radeon_device 
*rdev,
   uint8_t id)
 {
@@ -85,71 +166,10 @@ static struct radeon_i2c_bus_rec 
radeon_lookup_i2c_gpio(struct radeon_device *rd
for (i = 0; i < num_indices; i++) {
gpio = &i2c_info->asGPIO_Info[i];
 
-   /* r4xx mask is technically not used by the hw, so 
patch in the legacy mask bits */
-   if ((rdev->family == CHIP_R420) ||
-   (rdev->family == CHIP_R423) ||
-   (rdev->family == CHIP_RV410)) {
-   if ((le16_to_cpu(gpio->usClkMaskRegisterIndex) 
== 0x0018) ||
-   (le16_to_cpu(gpio->usClkMaskRegisterIndex) 
== 0x0019) ||
-   

Re: [Intel-gfx] [PATCH 02/13] drm/i915: rewrite shmem_pwrite_slow to use copy_from_user

[Ben Widawsky]

On Mon, Nov 21, 2011 at 05:02:44PM +0100, Daniel Vetter wrote:
> On Sun, Nov 20, 2011 at 09:56:32PM -0800, Ben Widawsky wrote:
> [snip the patch]
> > Bikeshed, but I would much prefer a #define for the swizzle
> > bit/cacheline size.
> 
> I've looked at this stuff way too long, so I'm biased, but 64 = cacheline
> = dram fetch size = 1 << 64 feels about as natural for me as 4096 =
> PAGE_SIZE ...
> 
> [snip the patch]
> 
> > I must be missing something obvious here...
> > Can you explain how this can possibly be considered safe without holding
> > struct_mutex?
> 
> That's the reason why the commit msg goes through every case and explains
> why I think it's safe. The large thing here is that we need to drop the
> mutex when calling copy_*_user (at least in the non-atomic slow-paths)
> because otherwise we might deadlock with our own pagefault handler.
> -Daniel

The part about dropping struct_mutex is clear to me.

The bit that I'm missing, I just don't see how you guarantee the page
you're reading from (assuming it's a GTT mmapped page) doesn't get moved
from out under you. For instance if the page isn't there when you do the
initial __copy_from_user, it will get faulted in... cool - but what if
somewhere in that loop the object gets swapped out and something else is
put in it's place? How is that prevented?

Sorry if it's a stupid question, I just don't get it.
Ben
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 02/13] drm/i915: rewrite shmem_pwrite_slow to use copy_from_user

[Ben Widawsky]

On Mon, Nov 21, 2011 at 09:55:07AM -0800, Ben Widawsky wrote:
> On Mon, Nov 21, 2011 at 05:02:44PM +0100, Daniel Vetter wrote:
> > On Sun, Nov 20, 2011 at 09:56:32PM -0800, Ben Widawsky wrote:
> > [snip the patch]
> > > Bikeshed, but I would much prefer a #define for the swizzle
> > > bit/cacheline size.
> > 
> > I've looked at this stuff way too long, so I'm biased, but 64 = cacheline
> > = dram fetch size = 1 << 64 feels about as natural for me as 4096 =
> > PAGE_SIZE ...
> > 
> > [snip the patch]
> > 
> > > I must be missing something obvious here...
> > > Can you explain how this can possibly be considered safe without holding
> > > struct_mutex?
> > 
> > That's the reason why the commit msg goes through every case and explains
> > why I think it's safe. The large thing here is that we need to drop the
> > mutex when calling copy_*_user (at least in the non-atomic slow-paths)
> > because otherwise we might deadlock with our own pagefault handler.
> > -Daniel
> 
> The part about dropping struct_mutex is clear to me.
> 
> The bit that I'm missing, I just don't see how you guarantee the page
> you're reading from (assuming it's a GTT mmapped page) doesn't get moved
> from out under you. For instance if the page isn't there when you do the
> initial __copy_from_user, it will get faulted in... cool - but what if
> somewhere in that loop the object gets swapped out and something else is
> put in it's place? How is that prevented?
> 
> Sorry if it's a stupid question, I just don't get it.
> Ben

Okay, I got what I was missing from IRC. Anytime the object is unmapped
we shoot down the userspace mapping. I couldn't find it in the code, but
it turned out to be right in front of me.

Reviewed-by: Ben Widawsky 

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

Re: [Intel-gfx] [PATCH 06/13] drm: add helper to clflush a virtual address range

[Ben Widawsky]

On Sun, Nov 06, 2011 at 08:13:53PM +0100, Daniel Vetter wrote:
> Useful when the page is already mapped to copy date in/out.
> 
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_cache.c |   23 +++
>  include/drm/drmP.h  |1 +
>  2 files changed, 24 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c
> index 0e3bd5b..502771a 100644
> --- a/drivers/gpu/drm/drm_cache.c
> +++ b/drivers/gpu/drm/drm_cache.c
> @@ -97,3 +97,26 @@ drm_clflush_pages(struct page *pages[], unsigned long 
> num_pages)
>  #endif
>  }
>  EXPORT_SYMBOL(drm_clflush_pages);
> +
> +void
> +drm_clflush_virt_range(char *addr, unsigned long length)
> +{
> +#if defined(CONFIG_X86)
> + if (cpu_has_clflush) {
> + char *end = addr + length;
> + mb();
> + for (; addr < end; addr += boot_cpu_data.x86_clflush_size)
> + clflush(addr);
> + clflush(end - 1);
> + mb();
> + return;
> + }
> +
> + if (on_each_cpu(drm_clflush_ipi_handler, NULL, 1) != 0)
> + printk(KERN_ERR "Timed out waiting for cache flush.\n");
> +#else
> + printk(KERN_ERR "Architecture has no drm_cache.c support\n");
> + WARN_ON_ONCE(1);
> +#endif
> +}
> +EXPORT_SYMBOL(drm_clflush_virt_range);

I'd feel more comfortable with a BUG_ON(irqs_disabled()); before the
IPI... though I don't even know how many platforms that actually
pertains to (if any).
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [REGRESSION]: hibernate/sleep regression w/ bisection

[Tejun Heo]

On Fri, Nov 04, 2011 at 06:08:20PM -0500, Andrew Watts wrote:
> On Fri, Nov 04, 2011 at 01:35:53PM -0400, Jerome Glisse wrote:
> > 
> > I need full dmesg
> > 
> > Cheers,
> > Jerome
> 
> Hi. Just noticed I attached a gzip of my dmesg last time by mistake.
> 
> Here goes as text/plain.

Out of curiosity, did it get somewhere?

Thanks.

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

Re: [REGRESSION]: hibernate/sleep regression w/ bisection

[Jerome Glisse]

On Mon, Nov 21, 2011 at 4:09 PM, Tejun Heo  wrote:
> On Fri, Nov 04, 2011 at 06:08:20PM -0500, Andrew Watts wrote:
>> On Fri, Nov 04, 2011 at 01:35:53PM -0400, Jerome Glisse wrote:
>> >
>> > I need full dmesg
>> >
>> > Cheers,
>> > Jerome
>>
>> Hi. Just noticed I attached a gzip of my dmesg last time by mistake.
>>
>> Here goes as text/plain.
>
> Out of curiosity, did it get somewhere?
>
> Thanks.
>
> --
> tejun
>

Yeah i am pretty sure i know what's going wrong but there is no easy
fix, there is a deadlock in the kernel when gem wait ioctl is call on
scanout buffer and that a gpu reset happen

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

Re: 3.2-rc2+: Reported regressions from 3.0 and 3.1

[Linus Torvalds]

On Mon, Nov 21, 2011 at 1:49 PM, Rafael J. Wysocki  wrote:
>
> Subject    : Simultaneous cat and external keyboard input causing kernel panic
> Submitter  : Timo Jyrinki 
> Date       : 2011-11-03 12:14
> Message-ID : 
> CAJtFfxmovJHspHHKbvBVc4pw+u5mjGmUejCXEzdV+GqE=jv...@mail.gmail.com
> References : http://marc.info/?l=linux-kernel&m=132032253903074&w=2

So while funny, I doubt this is actually a bug. It's a feature, as
pointed out by Clemens Ladisch in that thread.

It's simply sysrq-c: "perform a system crash by a NULL pointer dereference".

Now, I'm perfectly willing to consider that feature to be a
mis-feature, and that this should be considered a bug to be fixed. But
it is not a regression.

Keeping it on the regression list just because it is amusing is
understandable, though ;)

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

[Bug 42514] [r300g] EVE online: some shaders are failing

[bugzilla-daemon]

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

--- Comment #4 from Pavel Ondračka  2011-11-21 
14:11:58 PST ---
I'm wondering if this should be reassigned to glsl-compiler since the error
messages come from src/glsl/ast_to_hir.cpp not the r300 driver? Tom, Marek, can
you comment on this?

-- 
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: 3.2-rc2+: Reported regressions from 3.0 and 3.1

[Linus Torvalds]

On Mon, Nov 21, 2011 at 1:49 PM, Rafael J. Wysocki  wrote:
>
> Subject    : [3.1 REGRESSION] Commit 5cec93c216db77c45f7ce970d46283bcb1933884 
> breaks the Chromium seccomp sandbox
> Submitter  : Nix 
> Date       : 2011-11-14 0:40
> Message-ID : 8762inleno@spindle.srvr.nix
> References : http://marc.info/?l=linux-kernel&m=132123396226377&w=2

So this should be fixed by commit 2b666859ec32 ("x86: Default to
vsyscall=native for now"), since we disabled the vsyscall emulation
because it broken UML too.

Of course, the chromium seccomp thing might re-surface with the
patches that enable the emulation (with better emulation), which Andy
is still working on, and that I was planning on merging for 3.3.

Andy, it migth be worth contacting Nix and having him test whether
your fixed emulation works for chromium too.

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

3.2-rc2+: Reported regressions from 3.0 and 3.1

[Rafael J. Wysocki]

This message contains a list of some regressions from 3.0 and 3.1
for which there are no fixes in the mainline known to the tracking team.
If any of them have been fixed already, please let us know.

If you know of any other unresolved regressions from 3.0 and 3.1, please let us
know either and we'll add them to the list.  Also, please let us know if any of
the entries below are invalid.

The entries below are simplified and the statistics are not present due to the
continuing Bugzilla outage.

Subject: iwlagn is getting very shaky
Submitter  : Norbert Preining 
Date   : 2011-10-19 6:01
Message-ID : 20111019060108.ga11...@gamma.logic.tuwien.ac.at
References : http://marc.info/?l=linux-kernel&m=131914553920614&w=2

Subject: Regression: "irqpoll" hasn't been working for me since March 16 IRQ
Submitter  : Edward Donovan 
Date   : 2011-10-19 22:09
Message-ID : CADdbW+HXdCPfJu2RTF6zz+ujCmiu_dmZwL2iScuF53p=aaz...@mail.gmail.com
References : http://marc.info/?l=linux-kernel&m=131914554220679&w=2

Subject: Regression in 3.1 causes Xen to use wrong idle routine
Submitter  : Stefan Bader 
Date   : 2011-10-26 10:24
Message-ID : 4ea7dfd1.9060...@canonical.com
References : http://marc.info/?l=linux-acpi&m=131962467924564&w=2

Subject: 3.1+ iwlwifi lockup
Submitter  : Dave Jones 
Date   : 2011-10-31 14:34
Message-ID : 20111031143408.ga17...@redhat.com
References : http://marc.info/?l=linux-kernel&m=132007169420160&w=2

Subject: hugetlb oops on 3.1.0-rc8-devel
Submitter  : Andy Lutomirski 
Date   : 2011-11-01 22:20
Message-ID : calcetrw1mpvcz2to5roaz1r6vnno+srhr-dha6_pkri2qic...@mail.gmail.com
References : http://marc.info/?l=linux-kernel&m=132018604426692&w=2

Subject: Simultaneous cat and external keyboard input causing kernel panic
Submitter  : Timo Jyrinki 
Date   : 2011-11-03 12:14
Message-ID : CAJtFfxmovJHspHHKbvBVc4pw+u5mjGmUejCXEzdV+GqE=jv...@mail.gmail.com
References : http://marc.info/?l=linux-kernel&m=132032253903074&w=2

Subject: Linus GIT - INFO: possible circular locking dependency detected
Submitter  : Miles Lane 
Date   : 2011-11-03 15:57
Message-ID : CAHFgRy8S0xLfhZxTUOEH5A0PL_Fb79-0-gmbQ=9h2d-xmqt...@mail.gmail.com
References : http://marc.info/?l=linux-kernel&m=132033587908426&w=2

Subject: lockdep warning after aa6afca5bcab: "proc: fix races against 
execve() of /proc/PID/fd**"
Submitter  : Ari Savolainen 
Date   : 2011-11-08 3:47
Message-ID : caebykaxyzefhtgwmm2afawq2saxyuo_yptnw+6avwscoysc...@mail.gmail.com
References : http://marc.info/?l=linux-kernel&m=132072413125099&w=2

Subject: DMA-API check_sync errors with 3.2
Submitter  : Josh Boyer 
Date   : 2011-11-08 17:31
Message-ID : 2008173153.ge14...@zod.bos.redhat.com
References : http://marc.info/?l=linux-kernel&m=132077357608797&w=2

Subject: [3.1-rc8 REGRESSION] sky2 hangs machine on turning off or 
suspending
Submitter  : Rafał Miłecki 
Date   : 2011-11-09 11:46
Message-ID : CACna6ryTdLcWVYgHu=_mrfga1sfivpe_dyzoy-hmmkggkwa...@mail.gmail.com
References : http://marc.info/?l=linux-netdev&m=13208398088&w=4

Subject: 3.2-rc1 doesn't boot on dual socket opteron without swap
Submitter  : Niklas Schnelle 
Date   : 2011-11-10 20:09
Message-ID : 1320955769.1718.8.camel@jupiter
References : http://marc.info/?l=linux-kernel&m=132095583501767&w=2

Subject: Sparc-32 doesn't work in 3.1.
Submitter  : Rob Landley 
Date   : 2011-11-12 11:22
Message-ID : 4ebeab5a.5020...@landley.net
References : http://www.spinics.net/lists/kernel/msg1260383.html

Subject: khugepaged blocks suspend2ram (3.2.0-rc1-00252-g8f042aa)
Submitter  : Sergei Trofimovich 
Date   : 2011-11-12 10:48
Message-ID : 2012104859.7744b...@sf.home
References : https://lkml.org/lkml/2011/11/12/11

Subject: WARNING: at fs/sysfs/sysfs.h:195 (during boot)
Submitter  : Markus Trippelsdorf 
Date   : 2011-11-13 19:24
Message-ID : 2013192417.ga1...@x4.trippels.de
References : http://marc.info/?l=linux-kernel&m=132121231921932&w=2

Subject: PROBLEM: Radeon display connector : No monitor connected or 
invalid EDID
Submitter  : Treeve Jelbert 
Date   : 2011-11-13 17:27
Message-ID : 2407026.akcTO2Ggic@gemini-64
References : http://marc.info/?l=linux-kernel&m=132120530920139&w=2

Subject: [3.1 REGRESSION] Commit 5cec93c216db77c45f7ce970d46283bcb1933884 
breaks the Chromium seccomp sandbox
Submitter  : Nix 
Date   : 2011-11-14 0:40
Message-ID : 8762inleno@spindle.srvr.nix
References : http://marc.info/?l=linux-kernel&m=132123396226377&w=2

Subject: max PWM is zero
Submitter  : Marcos Paulo de Souza 
Date   : 2011-11-15 15:14
Message-ID : alpine.lnx.2.00.151301410.2...@darkstar.example.net
References : http://marc.info/?l=linux-kernel&m=132137019330548&w=2

Subject: Oops on suspend with libertas SDIO (Linux 3.2-rc2)
Submitter  : Sven Neumann 
Date   : 2011-11-17 15:36
Message-ID : 1321544210.31090.6.camel@sven
References : http://marc.info/?l=linux-

Re: 3.2-rc2+: Reported regressions from 3.0 and 3.1

[Linus Torvalds]

On Mon, Nov 21, 2011 at 1:49 PM, Rafael J. Wysocki  wrote:
>
> Subject    : hugetlb oops on 3.1.0-rc8-devel
> Submitter  : Andy Lutomirski 
> Date       : 2011-11-01 22:20
> Message-ID : 
> calcetrw1mpvcz2to5roaz1r6vnno+srhr-dha6_pkri2qic...@mail.gmail.com
> References : http://marc.info/?l=linux-kernel&m=132018604426692&w=2

Despite the subject line, that's not an oops, it's a BUG_ON().

And it *should* be fixed by commit ea4039a34c4c ("hugetlb: release
pages in the error path of hugetlb_cow()") although I don't think Andy
ever confirmed that (since it was hard to trigger).

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

Re: 3.2-rc2+: Reported regressions from 3.0 and 3.1

[Linus Torvalds]

On Mon, Nov 21, 2011 at 1:49 PM, Rafael J. Wysocki  wrote:
>
> Subject    : lockdep warning after aa6afca5bcab: "proc: fix races against 
> execve() of /proc/PID/fd**"
> Submitter  : Ari Savolainen 
> Date       : 2011-11-08 3:47
> Message-ID : 
> caebykaxyzefhtgwmm2afawq2saxyuo_yptnw+6avwscoysc...@mail.gmail.com
> References : http://marc.info/?l=linux-kernel&m=132072413125099&w=2

Commit aa6afca5bcab was reverted by commit 5e442a493fc5, so this one
is presumably stale.

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

Re: 3.2-rc2+: Reported regressions from 3.0 and 3.1

[Linus Torvalds]

On Mon, Nov 21, 2011 at 1:49 PM, Rafael J. Wysocki  wrote:
>
> Subject    : [3.1-rc8 REGRESSION] sky2 hangs machine on turning off or 
> suspending
> Submitter  : Rafał Miłecki 
> Date       : 2011-11-09 11:46
> Message-ID : 
> CACna6ryTdLcWVYgHu=_mrfga1sfivpe_dyzoy-hmmkggkwa...@mail.gmail.com
> References : http://marc.info/?l=linux-netdev&m=13208398088&w=4

This should be fixed by commit 1401a8008a09 ("sky2: fix hang on
shutdown (and other irq issues)") in current -git.

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

Re: 3.2-rc2+: Reported regressions from 3.0 and 3.1

[Alex Deucher]

On Mon, Nov 21, 2011 at 4:49 PM, Rafael J. Wysocki  wrote:
> This message contains a list of some regressions from 3.0 and 3.1
> for which there are no fixes in the mainline known to the tracking team.
> If any of them have been fixed already, please let us know.
>
> If you know of any other unresolved regressions from 3.0 and 3.1, please let 
> us
> know either and we'll add them to the list.  Also, please let us know if any 
> of
> the entries below are invalid.
>
> The entries below are simplified and the statistics are not present due to the
> continuing Bugzilla outage.
>
> Subject    : iwlagn is getting very shaky
> Submitter  : Norbert Preining 
> Date       : 2011-10-19 6:01
> Message-ID : 20111019060108.ga11...@gamma.logic.tuwien.ac.at
> References : http://marc.info/?l=linux-kernel&m=131914553920614&w=2
>
> Subject    : Regression: "irqpoll" hasn't been working for me since March 16 
> IRQ
> Submitter  : Edward Donovan 
> Date       : 2011-10-19 22:09
> Message-ID : 
> CADdbW+HXdCPfJu2RTF6zz+ujCmiu_dmZwL2iScuF53p=aaz...@mail.gmail.com
> References : http://marc.info/?l=linux-kernel&m=131914554220679&w=2
>
> Subject    : Regression in 3.1 causes Xen to use wrong idle routine
> Submitter  : Stefan Bader 
> Date       : 2011-10-26 10:24
> Message-ID : 4ea7dfd1.9060...@canonical.com
> References : http://marc.info/?l=linux-acpi&m=131962467924564&w=2
>
> Subject    : 3.1+ iwlwifi lockup
> Submitter  : Dave Jones 
> Date       : 2011-10-31 14:34
> Message-ID : 20111031143408.ga17...@redhat.com
> References : http://marc.info/?l=linux-kernel&m=132007169420160&w=2
>
> Subject    : hugetlb oops on 3.1.0-rc8-devel
> Submitter  : Andy Lutomirski 
> Date       : 2011-11-01 22:20
> Message-ID : 
> calcetrw1mpvcz2to5roaz1r6vnno+srhr-dha6_pkri2qic...@mail.gmail.com
> References : http://marc.info/?l=linux-kernel&m=132018604426692&w=2
>
> Subject    : Simultaneous cat and external keyboard input causing kernel panic
> Submitter  : Timo Jyrinki 
> Date       : 2011-11-03 12:14
> Message-ID : 
> CAJtFfxmovJHspHHKbvBVc4pw+u5mjGmUejCXEzdV+GqE=jv...@mail.gmail.com
> References : http://marc.info/?l=linux-kernel&m=132032253903074&w=2
>
> Subject    : Linus GIT - INFO: possible circular locking dependency detected
> Submitter  : Miles Lane 
> Date       : 2011-11-03 15:57
> Message-ID : 
> CAHFgRy8S0xLfhZxTUOEH5A0PL_Fb79-0-gmbQ=9h2d-xmqt...@mail.gmail.com
> References : http://marc.info/?l=linux-kernel&m=132033587908426&w=2
>
> Subject    : lockdep warning after aa6afca5bcab: "proc: fix races against 
> execve() of /proc/PID/fd**"
> Submitter  : Ari Savolainen 
> Date       : 2011-11-08 3:47
> Message-ID : 
> caebykaxyzefhtgwmm2afawq2saxyuo_yptnw+6avwscoysc...@mail.gmail.com
> References : http://marc.info/?l=linux-kernel&m=132072413125099&w=2
>
> Subject    : DMA-API check_sync errors with 3.2
> Submitter  : Josh Boyer 
> Date       : 2011-11-08 17:31
> Message-ID : 2008173153.ge14...@zod.bos.redhat.com
> References : http://marc.info/?l=linux-kernel&m=132077357608797&w=2
>
> Subject    : [3.1-rc8 REGRESSION] sky2 hangs machine on turning off or 
> suspending
> Submitter  : Rafał Miłecki 
> Date       : 2011-11-09 11:46
> Message-ID : 
> CACna6ryTdLcWVYgHu=_mrfga1sfivpe_dyzoy-hmmkggkwa...@mail.gmail.com
> References : http://marc.info/?l=linux-netdev&m=13208398088&w=4
>
> Subject    : 3.2-rc1 doesn't boot on dual socket opteron without swap
> Submitter  : Niklas Schnelle 
> Date       : 2011-11-10 20:09
> Message-ID : 1320955769.1718.8.camel@jupiter
> References : http://marc.info/?l=linux-kernel&m=132095583501767&w=2
>
> Subject    : Sparc-32 doesn't work in 3.1.
> Submitter  : Rob Landley 
> Date       : 2011-11-12 11:22
> Message-ID : 4ebeab5a.5020...@landley.net
> References : http://www.spinics.net/lists/kernel/msg1260383.html
>
> Subject    : khugepaged blocks suspend2ram (3.2.0-rc1-00252-g8f042aa)
> Submitter  : Sergei Trofimovich 
> Date       : 2011-11-12 10:48
> Message-ID : 2012104859.7744b...@sf.home
> References : https://lkml.org/lkml/2011/11/12/11
>
> Subject    : WARNING: at fs/sysfs/sysfs.h:195 (during boot)
> Submitter  : Markus Trippelsdorf 
> Date       : 2011-11-13 19:24
> Message-ID : 2013192417.ga1...@x4.trippels.de
> References : http://marc.info/?l=linux-kernel&m=132121231921932&w=2
>
> Subject    : PROBLEM: Radeon display connector : No monitor connected or 
> invalid EDID
> Submitter  : Treeve Jelbert 
> Date       : 2011-11-13 17:27
> Message-ID : 2407026.akcTO2Ggic@gemini-64
> References : http://marc.info/?l=linux-kernel&m=132120530920139&w=2

Treeve replied to me directly saying the it was a problem with his
config file and everything is working fine now.

Alex

>
> Subject    : [3.1 REGRESSION] Commit 5cec93c216db77c45f7ce970d46283bcb1933884 
> breaks the Chromium seccomp sandbox
> Submitter  : Nix 
> Date       : 2011-11-14 0:40
> Message-ID : 8762inleno@spindle.srvr.nix
> References : http://marc.info/?l=linux-kernel&m=132123396226377&w=2
>
> Subject    : max PWM i

[Bug 42514] [r300g] EVE online: some shaders are failing

[bugzilla-daemon]

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

--- Comment #5 from Marek Olšák  2011-11-21 14:31:48 PST ---
Yes, the component should be glsl-compiler.

-- 
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 -fixes] ttm: Don't return the bo reserved on error path

[Jerome Glisse]

On Mon, Nov 21, 2011 at 01:05:02PM +0100, Thomas Hellstrom wrote:
> An unlikely race could case a bo to be returned reserved on an error path.
> 
> Signed-off-by: Thomas Hellstrom 
Reviewed-by: Jerome Glisse 
> ---
>  drivers/gpu/drm/ttm/ttm_bo.c |8 +++-
>  1 files changed, 7 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index 617b646..0bb0f5f 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -574,10 +574,16 @@ retry:
>   return ret;
>  
>   spin_lock(&glob->lru_lock);
> +
> + if (unlikely(list_empty(&bo->ddestroy))) {
> + spin_unlock(&glob->lru_lock);
> + return 0;
> + }
> +
>   ret = ttm_bo_reserve_locked(bo, interruptible,
>   no_wait_reserve, false, 0);
>  
> - if (unlikely(ret != 0) || list_empty(&bo->ddestroy)) {
> + if (unlikely(ret != 0)) {
>   spin_unlock(&glob->lru_lock);
>   return ret;
>   }
> -- 
> 1.7.4.4
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: max PWM is zero

[Keith Packard]

On Mon, 21 Nov 2011 22:48:21 + (Local time zone must be set--see zic manual 
page), Marcos Paulo de Souza  wrote:

> My max_brightness is 1, and my brightness is 0.

Right, we've prevented the internal backlight driver from exposing a max
value of 0 as that's just confusing.

> But, my acpi_video0 have a 
> max_brightness value = 9...

Right, sounds like your device is just using some other backlight
controller, which is perfectly reasonable.

> So, what can I do to silence this warning...? Change the driver of 
> backlight?

If your backlight keys work correctly, then things are fine and perhaps
we should just remove the warning from the driver, or disable the
internal driver when we discover this situation.

This is the first time I've heard of this warning appearing...

-- 
keith.pack...@intel.com


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

Re: 3.2-rc2+: Reported regressions from 3.0 and 3.1

[Ari Savolainen]

2011/11/22 Linus Torvalds :
> On Mon, Nov 21, 2011 at 1:49 PM, Rafael J. Wysocki  wrote:
>>
>> Subject    : lockdep warning after aa6afca5bcab: "proc: fix races against 
>> execve() of /proc/PID/fd**"
>> Submitter  : Ari Savolainen 
>> Date       : 2011-11-08 3:47
>> Message-ID : 
>> caebykaxyzefhtgwmm2afawq2saxyuo_yptnw+6avwscoysc...@mail.gmail.com
>> References : http://marc.info/?l=linux-kernel&m=132072413125099&w=2
>
> Commit aa6afca5bcab was reverted by commit 5e442a493fc5, so this one
> is presumably stale.
>
>                      Linus

Yes, this went away after the reversion.

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

Re: 3.2-rc2+: Reported regressions from 3.0 and 3.1

[Andrew Morton]

On Tue, 22 Nov 2011 11:19:24 +0530 "Srivatsa S. Bhat" 
 wrote:

> > Subject: khugepaged blocks suspend2ram (3.2.0-rc1-00252-g8f042aa)
> > Submitter  : Sergei Trofimovich 
> > Date   : 2011-11-12 10:48
> > Message-ID : 2012104859.7744b...@sf.home
> > References : https://lkml.org/lkml/2011/11/12/11
> > 
> 
> Andrea's patch already fixes this issue, which was reported first by
> Jiri Slaby. https://lkml.org/lkml/2011/11/11/93
> I remember Andrew Morton taking this patch in his -mm tree. But it is
> not in mainline yet. So can we consider this closed or not?

grr, nothing in that patch's changelog indicates that it fixed a
regression nor that it fixed an infinite blockage of suspend.

I moved it to my 3.2 queue, thanks.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/3 v2] drm/i915: hot plug/unplug notification to HDMI audio driver

[Wu Fengguang]

On Tue, Nov 22, 2011 at 12:55:43AM +0800, Keith Packard wrote:
> On Mon, 21 Nov 2011 14:37:49 +0800, Wu Fengguang  
> wrote:
> > On monitor hot plug/unplug, update ELD and set/clear SDVO_AUDIO_ENABLE
> > or DP_AUDIO_OUTPUT_ENABLE accordingly.  So that the audio driver will
> > receive hot plug events and take action to refresh its device state and
> > ELD contents.
> > 
> > A new callback ->hotplug() is added to struct drm_connector_funcs which
> > will be called immediately after ->detect() knowing that the monitor is
> > either plugged or unplugged.
> > 
> > It's noticed that X may not call ->mode_set() at monitor hot plug, so it's
> > necessary to call drm_edid_to_eld() earlier at ->detect() time rather than
> > in intel_ddc_get_modes(), so that intel_write_eld() can see the new ELD
> > in ->hotplug.
> 
> The X environment will eventually call mode_set when the user
> environment decides to use the monitor. Any audio bits can, and should,
> await the user's choice of a video mode before choosing the audio format
> to use. We should not be adding eld information until the monitor is in
> use.

Yeah. I just tested the full gnome desktop and find it behave like the
KMS console:

1) ->mode_set will be called
2) crtc is 0 in intel_hdmi_hotplug(), hence skipping the ELD code there

So the v3 patch will behave equally well on KMS console, gnome desktop
and bare X. Shall we just use it, or go back and use the original
->hot_remove patch?

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

[PATCH] xen/pm_idle: Make pm_idle be default_idle under Xen.

[Konrad Rzeszutek Wilk]

This patch:

commit d91ee5863b71e8c90eaf6035bff3078a85e2e7b5
Author: Len Brown 
Date:   Fri Apr 1 18:28:35 2011 -0400

cpuidle: replace xen access to x86 pm_idle and default_idle

..scribble on pm_idle and access default_idle,
   have it simply disable_cpuidle() so acpi_idle will not load and
   architecture default HLT will be used.

idea was to have one call - disable_cpuidle() which would make
pm_idle not be molested by other code. It disallows cpuidle_idle_call
and acpi_idle_call to not set pm_idle (which is excellent). But the
amd_e400_idle and mwait_idle can still setup pm_idle which we really
do not want. In case of mwait_idle we can hit some instances where:

Brought up 2 CPUs
invalid opcode:  [#1] SMP
CPU 1
Modules linked in:

Pid: 0, comm: swapper Not tainted 3.1.0-0.rc6.git0.3.fc16.x86_64 #1
RIP: e030:[]  [] mwait_idle+0x6f/0xb4
RSP: e02b:8801d28ddf10  EFLAGS: 00010082
RAX: 8801d28dc010 RBX: 8801d28ddfd8 RCX: 
RDX:  RSI: 0001 RDI: 0001
RBP: 8801d28ddf10 R08:  R09: 0001
R10: 0001 R11: 8801d28ddfd8 R12: 81b590d0
R13:  R14:  R15: 
FS:  () GS:8801dff81000() knlGS:
CS:  e033 DS: 002b ES: 002b CR0: 8005003b
CR2:  CR3: 01a05000 CR4: 2660
DR0:  DR1:  DR2: 
DR3:  DR6: 0ff0 DR7: 
Process swapper (pid: 0, threadinfo 8801d28dc000, task 8801d28cae60)
Stack:
 8801d28ddf40 8100e2ed 8801dff8e390 c136dfe72feab515
   8801d28ddf50 8149ee78
    
Call Trace:
 [] cpu_idle+0xae/0xe8
 [] cpu_bringup_and_idle+0xe/0x10
RIP  [] mwait_idle+0x6f/0xb4
 RSP 

RH BZ #739499 and Ubuntu #881076

In case of amd_e400_idle we don't get so spectacular crashes, but
we do end up making an MSR which is trapped in the hypervisor,
and then follow it up with a yield hypercall. Meaning we end up
going to hypervisor twice instead of just once.

Lets make pm_idle be default_idle to take care of that.

Reported-by: Stefan Bader 
Signed-off-by: Konrad Rzeszutek Wilk 
---
 arch/x86/include/asm/system.h |1 +
 arch/x86/kernel/process.c |8 
 arch/x86/xen/setup.c  |2 +-
 3 files changed, 10 insertions(+), 1 deletions(-)

diff --git a/arch/x86/include/asm/system.h b/arch/x86/include/asm/system.h
index c2ff2a1..2d2f01c 100644
--- a/arch/x86/include/asm/system.h
+++ b/arch/x86/include/asm/system.h
@@ -401,6 +401,7 @@ extern unsigned long arch_align_stack(unsigned long sp);
 extern void free_init_pages(char *what, unsigned long begin, unsigned long 
end);

 void default_idle(void);
+bool set_pm_idle_to_default(void);

 void stop_this_cpu(void *dummy);

diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index 1f7f8c8..336b299 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -404,6 +404,14 @@ void default_idle(void)
 EXPORT_SYMBOL(default_idle);
 #endif

+bool set_pm_idle_to_default()
+{
+   if (!pm_idle) {
+   pm_idle = default_idle;
+   return true;
+   }
+   return false;
+}
 void stop_this_cpu(void *dummy)
 {
local_irq_disable();
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 46d6d21..7506181 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -448,6 +448,6 @@ void __init xen_arch_setup(void)
 #endif
disable_cpuidle();
boot_option_idle_override = IDLE_HALT;
-
+   WARN_ON(!set_pm_idle_to_default());
fiddle_vdso();
 }
-- 
1.7.7.3

[PATCH] xen/pm_idle: Make pm_idle be default_idle under Xen.

[Konrad Rzeszutek Wilk]

This patch:

commit d91ee5863b71e8c90eaf6035bff3078a85e2e7b5
Author: Len Brown 
Date:   Fri Apr 1 18:28:35 2011 -0400

cpuidle: replace xen access to x86 pm_idle and default_idle

..scribble on pm_idle and access default_idle,
   have it simply disable_cpuidle() so acpi_idle will not load and
   architecture default HLT will be used.

idea was to have one call - disable_cpuidle() which would make
pm_idle not be molested by other code. It disallows cpuidle_idle_call
to be set to pm_idle (which is excellent). But in the select_idle_routine()
and idle_setup(), the pm_idle can still be set to either:
amd_e400_idle, mwait_idle or default_idle. This depends on some
CPU flags (MWAIT) and in AMD case on the type of CPU.

In case of mwait_idle we can hit some instances where the hypervisor
(Amazon EC2 specifically) sets the MWAIT and we get:

Brought up 2 CPUs
invalid opcode:  [#1] SMP
CPU 1
Modules linked in:

Pid: 0, comm: swapper Not tainted 3.1.0-0.rc6.git0.3.fc16.x86_64 #1
RIP: e030:[]  [] mwait_idle+0x6f/0xb4
RSP: e02b:8801d28ddf10  EFLAGS: 00010082
RAX: 8801d28dc010 RBX: 8801d28ddfd8 RCX: 
RDX:  RSI: 0001 RDI: 0001
RBP: 8801d28ddf10 R08:  R09: 0001
R10: 0001 R11: 8801d28ddfd8 R12: 81b590d0
R13:  R14:  R15: 
FS:  () GS:8801dff81000() knlGS:
CS:  e033 DS: 002b ES: 002b CR0: 8005003b
CR2:  CR3: 01a05000 CR4: 2660
DR0:  DR1:  DR2: 
DR3:  DR6: 0ff0 DR7: 
Process swapper (pid: 0, threadinfo 8801d28dc000, task 8801d28cae60)
Stack:
 8801d28ddf40 8100e2ed 8801dff8e390 c136dfe72feab515
   8801d28ddf50 8149ee78
    
Call Trace:
 [] cpu_idle+0xae/0xe8
 [] cpu_bringup_and_idle+0xe/0x10
RIP  [] mwait_idle+0x6f/0xb4
 RSP 

In case of amd_e400_idle we don't get so spectacular crashes, but
we do end up making an MSR which is trapped in the hypervisor,
and then follow it up with a yield hypercall. Meaning we end up
going to hypervisor twice instead of just once.

The previous behavior before v3.0 was that pm_idle was set
to default_idle irregardless of select_idle_routine/idle_setup.

We want to do that, but only for one specific case: Xen.
This patch does that.

Fixes RH BZ #739499 and Ubuntu #881076
Reported-by: Stefan Bader 
Signed-off-by: Konrad Rzeszutek Wilk 
---
 arch/x86/include/asm/system.h |1 +
 arch/x86/kernel/process.c |8 
 arch/x86/xen/setup.c  |2 +-
 3 files changed, 10 insertions(+), 1 deletions(-)

diff --git a/arch/x86/include/asm/system.h b/arch/x86/include/asm/system.h
index c2ff2a1..2d2f01c 100644
--- a/arch/x86/include/asm/system.h
+++ b/arch/x86/include/asm/system.h
@@ -401,6 +401,7 @@ extern unsigned long arch_align_stack(unsigned long sp);
 extern void free_init_pages(char *what, unsigned long begin, unsigned long 
end);

 void default_idle(void);
+bool set_pm_idle_to_default(void);

 void stop_this_cpu(void *dummy);

diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index 1f7f8c8..31f47ba 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -404,6 +404,14 @@ void default_idle(void)
 EXPORT_SYMBOL(default_idle);
 #endif

+bool set_pm_idle_to_default(void)
+{
+   bool ret = !!pm_idle;
+
+   pm_idle = default_idle;
+
+   return ret;
+}
 void stop_this_cpu(void *dummy)
 {
local_irq_disable();
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 46d6d21..79dfb57 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -448,6 +448,6 @@ void __init xen_arch_setup(void)
 #endif
disable_cpuidle();
boot_option_idle_override = IDLE_HALT;
-
+   WARN_ON(set_pm_idle_to_default());
fiddle_vdso();
 }
-- 
1.7.7.3

[PATCH 3/3] drm/i915: hot removal notification to HDMI audio driver

[Wu Fengguang]

On Sat, Nov 19, 2011 at 01:46:44AM +0800, Keith Packard wrote:
> On Fri, 18 Nov 2011 17:37:40 +0800, Wu Fengguang  
> wrote:
> 
> > However when in X, ->mode_set won't be called at all.  Only
> > ->get_modes and ->detect are called...
> 
> The desktop software will call mode_set when it configures the
> monitor. Otherwise, it's not being used (and so shouldn't have audio
> routed to it by default).

Keith, I experimented playing HDMI audio in X, and during the time
unplug and plug the monitor. The HDMI audio/graphics all continue to
work when plugged in the monitor again. Here is the dmesg showed for
the plug event, no ->mode_set is called at all...

[ 1296.469103] [drm:drm_mode_getconnector], [CONNECTOR:5:?]
[ 1296.475442] [drm:drm_helper_probe_single_connector_modes], 
[CONNECTOR:5:VGA-1]
[ 1296.483649] [drm:intel_ironlake_crt_detect_hotplug], ironlake hotplug 
adpa=0x83f4, result 1
[ 1296.493417] [drm:intel_crt_detect], CRT detected via hotplug
[ 1296.562579] [drm:drm_edid_to_eld], ELD: no CEA Extension found
[ 1296.564700] [drm:drm_helper_probe_single_connector_modes], 
[CONNECTOR:5:VGA-1] probed modes :
[ 1296.567609] [drm:drm_mode_debug_printmodeline], Modeline 24:"1024x768" 60 
65000 1024 1048 1184 1344 768 771 777 806 0x48 0xa
[ 1296.572112] [drm:drm_mode_debug_printmodeline], Modeline 23:"1024x768" 75 
78800 1024 1040 1136 1312 768 769 772 800 0x40 0x5
[ 1296.576561] [drm:drm_mode_debug_printmodeline], Modeline 25:"800x600" 75 
49500 800 816 896 1056 600 601 604 625 0x40 0x5
[ 1296.579109] [drm:drm_mode_debug_printmodeline], Modeline 19:"800x600" 60 
4 800 840 968 1056 600 601 605 628 0x40 0x5
[ 1296.581403] [drm:drm_mode_debug_printmodeline], Modeline 20:"640x480" 75 
31500 640 656 720 840 480 481 484 500 0x40 0xa
[ 1296.584027] [drm:drm_mode_debug_printmodeline], Modeline 21:"640x480" 60 
25200 640 656 752 800 480 490 492 525 0x40 0xa
[ 1296.587294] [drm:drm_mode_debug_printmodeline], Modeline 22:"720x400" 70 
28320 720 738 846 900 400 412 414 449 0x40 0x6
[ 1296.589849] [drm:drm_mode_getconnector], [CONNECTOR:5:?]
[ 1296.593635] [drm:drm_mode_getconnector], [CONNECTOR:8:?]
[ 1296.595157] [drm:drm_helper_probe_single_connector_modes], 
[CONNECTOR:8:HDMI-A-1]
[ 1296.608219] [drm:drm_helper_probe_single_connector_modes], 
[CONNECTOR:8:HDMI-A-1] disconnected
[ 1296.610732] [drm:drm_mode_getconnector], [CONNECTOR:8:?]
[ 1296.611939] [drm:drm_helper_probe_single_connector_modes], 
[CONNECTOR:8:HDMI-A-1]
[ 1296.624882] [drm:drm_helper_probe_single_connector_modes], 
[CONNECTOR:8:HDMI-A-1] disconnected
[ 1296.627445] [drm:drm_mode_getconnector], [CONNECTOR:12:?]
[ 1296.628814] [drm:drm_helper_probe_single_connector_modes], 
[CONNECTOR:12:HDMI-A-2]
[ 1296.750591] [drm:drm_detect_monitor_audio], Monitor has basic audio support
[ 1296.873062] [drm:drm_edid_to_eld], ELD monitor SONY TV
[ 1296.874819] HDMI: DVI dual 0, max TMDS clock 5, latency present 0 0, video 
latency 0 81, audio latency 114 208
[ 1296.877018] [drm:drm_edid_to_eld], ELD size 8, SAD count 1
[ 1296.878468] [drm:drm_mode_debug_printmodeline], Modeline 45:"1920x1080i" 0 
74250 1920 2448 2492 2640 1080 1084 1094 1125 0x40 0x15
[ 1296.880862] [drm:drm_mode_prune_invalid], Not using 1920x1080i mode 7
[ 1296.882454] [drm:drm_mode_debug_printmodeline], Modeline 44:"1920x1080i" 0 
74250 1920 2008 2052 2200 1080 1084 1094 1125 0x40 0x15
[ 1296.885996] [drm:drm_mode_prune_invalid], Not using 1920x1080i mode 7
[ 1296.887573] [drm:drm_helper_probe_single_connector_modes], 
[CONNECTOR:12:HDMI-A-2] probed modes :
[ 1296.889507] [drm:drm_mode_debug_printmodeline], Modeline 37:"1920x1080" 50 
148500 1920 2448 2492 2640 1080 1084 1089 1125 0x48 0x5
[ 1296.892084] [drm:drm_mode_debug_printmodeline], Modeline 43:"1280x720" 50 
74250 1280 1720 1760 1980 720 725 730 750 0x40 0x5
[ 1296.894657] [drm:drm_mode_debug_printmodeline], Modeline 41:"1280x720" 60 
74250 1280 1390 1430 1650 720 725 730 750 0x40 0x5
[ 1296.897053] [drm:drm_mode_debug_printmodeline], Modeline 32:"720x576" 50 
27000 720 732 796 864 576 581 586 625 0x40 0xa
[ 1296.899603] [drm:drm_mode_debug_printmodeline], Modeline 29:"720x480" 60 
27000 720 736 798 858 480 489 495 525 0x40 0xa
[ 1296.901979] [drm:drm_mode_getconnector], [CONNECTOR:12:?]
[ 1296.906084] [drm:drm_mode_getconnector], [CONNECTOR:13:?]
[ 1296.907545] [drm:drm_helper_probe_single_connector_modes], 
[CONNECTOR:13:DP-1]
[ 1296.909659] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x5145003e
[ 1296.913429] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x5145003e
[ 1296.917418] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x5145003e
[ 1296.920908] [drm:intel_dp_detect], DPCD: 
[ 1296.922663] [drm:drm_helper_probe_single_connector_modes], 
[CONNECTOR:13:DP-1] disconnected
[ 1296.924543] [drm:drm_mode_getconnector], [CONNECTOR:13:?]
[ 1296.925793] [drm:drm_helper_probe_single_connector_modes], 
[CONNECTOR:13:DP-1]
[ 1296.927920] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x5145003e
[ 1296.931393] [

Bug#649448: udev loading radeon drivers garbles screen output

[Ben Hutchings]

On Sun, 2011-11-20 at 19:02 -0600, Jonathan Nieder wrote:
> reassign 649448 src:linux-2.6 linux-2.6/3.0.0-3
> severity 649448 important
> retitle 649448 radeon (evergreen): random-looking pattern of pixels when 
> firmware not installed
> tags 649448 + upstream
> quit
> 
> Hi Martin,
> 
> Martin von Gagern wrote:
> 
> > Version: 3.0.0-3
> [...]
> > Just installed a wheezy setup using debootstrap, adding grub-pc and
> > linux-image-amd64 after the chroot was created. The kernel boots, the
> > initrd seems all right. When the main system boots up, udev gets launced
> > pretty early. Soon after it is started, the screen turns into a pretty
> > random-looking pattern of pixels, making the console pretty unusable.
> > This also happens in "recovery" i.e. single-user mode.
> [...]
> > Possible workarounds seem to include:
> [...]
> > - Adding a line "blacklist radeon" to /etc/modprobe.d/blacklist.conf,
> >   followed by running "depmod -a".
> [...]
> >> [  150.125768] r600_cp: Failed to load firmware "radeon/SUMO2_pfp.bin"
> >> [  150.125818] [drm:evergreen_startup] *ERROR* Failed to load firmware!
> >> [  150.125859] radeon :00:01.0: disabling GPU acceleration
> 
> Yes, the radeon driver currently copes poorly when firmware is missing.
> Compare [1], [2], [3].
>
> [...]
> > Not having GPU accelleration due to lack of free firmware is acceptable.
> > Not having a usable text console can be a real problem.
> 
> Agreed.  The radeon driver should be bailing out when firmware is
> missing for cards that need it, but that is not working for some
> reason.
[...]

At the time I converted the radeon driver to load external firmware, it
was apparently only required for 3D acceleration and both KMS and 2D
acceleration of X worked without it, at least on those systems I tested
(which were quite old, R100-R300 families).  Therefore failure to load
firmware would only result in DRM (3D acceleration support) being
disabled.

However, it looks like driver support for the R600 family onward now
absolutely requires the 'RLC' firmware blobs:

commit d8f60cfc93452d0554f6a701aa8e3236cbee4636
Author: Alex Deucher 
Date:   Tue Dec 1 13:43:46 2009 -0500

drm/radeon/kms: Add support for interrupts on r6xx/r7xx chips (v3)

And the 'Northern Islands' GPUs and 'Fusion' APUs appear to require the
'MC' firmware blobs:

commit 0af62b0168043896a042b005ff88caa77dd94d04
Author: Alex Deucher 
Date:   Thu Jan 6 21:19:31 2011 -0500

drm/radeon/kms: add ucode loader for NI

Therefore I think that at least r600_init(), rv770_init(),
evergreen_init() and cayman_init() should be treating failure to load
firmware as a fatal error.

Ben.

-- 
Ben Hutchings
Teamwork is essential - it allows you to blame someone else.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 828 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/2021/afd7a565/attachment.pgp>

[PATCH 3/3 v2] drm/i915: hot plug/unplug notification to HDMI audio driver

[Wu Fengguang]

On monitor hot plug/unplug, update ELD and set/clear SDVO_AUDIO_ENABLE
or DP_AUDIO_OUTPUT_ENABLE accordingly.  So that the audio driver will
receive hot plug events and take action to refresh its device state and
ELD contents.

A new callback ->hotplug() is added to struct drm_connector_funcs which
will be called immediately after ->detect() knowing that the monitor is
either plugged or unplugged.

It's noticed that X may not call ->mode_set() at monitor hot plug, so it's
necessary to call drm_edid_to_eld() earlier at ->detect() time rather than
in intel_ddc_get_modes(), so that intel_write_eld() can see the new ELD
in ->hotplug.

The call sequence on hot plug is
(the difference part lies in ->mode_set vs ->hotplug)

- KMS console
->detect
  drm_edid_to_eld
->mode_set
  intel_write_eld
  set SDVO_AUDIO_ENABLE/DP_AUDIO_OUTPUT_ENABLE
- X
->detect
  drm_edid_to_eld
->hotplug
  intel_write_eld
  set SDVO_AUDIO_ENABLE/DP_AUDIO_OUTPUT_ENABLE

On hot remove, the call sequence is

->hotplug
  clear SDVO_AUDIO_ENABLE/DP_AUDIO_OUTPUT_ENABLE

cc: Wang Zhenyu 
Signed-off-by: Wu Fengguang 
---
 drivers/gpu/drm/drm_crtc_helper.c  |5 ++-
 drivers/gpu/drm/i915/intel_dp.c|   44 +--
 drivers/gpu/drm/i915/intel_hdmi.c  |   31 +++
 drivers/gpu/drm/i915/intel_modes.c |2 -
 include/drm/drm_crtc.h |1 
 5 files changed, 71 insertions(+), 12 deletions(-)

--- linux.orig/drivers/gpu/drm/i915/intel_dp.c  2011-11-21 11:26:09.0 
+0800
+++ linux/drivers/gpu/drm/i915/intel_dp.c   2011-11-21 14:12:21.0 
+0800
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "drmP.h"
 #include "drm.h"
 #include "drm_crtc.h"
@@ -1970,20 +1971,44 @@ intel_dp_detect(struct drm_connector *co
if (status != connector_status_connected)
return status;

-   if (intel_dp->force_audio) {
-   intel_dp->has_audio = intel_dp->force_audio > 0;
-   } else {
-   edid = intel_dp_get_edid(connector, &intel_dp->adapter);
-   if (edid) {
-   intel_dp->has_audio = drm_detect_monitor_audio(edid);
-   connector->display_info.raw_edid = NULL;
-   kfree(edid);
-   }
+   edid = intel_dp_get_edid(connector, &intel_dp->adapter);
+   if (edid) {
+   intel_dp->has_audio = drm_detect_monitor_audio(edid);
+   drm_edid_to_eld(connector, edid);
+   connector->display_info.raw_edid = NULL;
+   kfree(edid);
}

+   if (intel_dp->force_audio)
+   intel_dp->has_audio = intel_dp->force_audio > 0;
+
return connector_status_connected;
 }

+static void intel_dp_hotplug(struct drm_connector *connector)
+{
+   struct intel_dp *intel_dp = intel_attached_dp(connector);
+   struct drm_device *dev = intel_dp->base.base.dev;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct drm_crtc *crtc = intel_dp->base.base.crtc;
+
+   DRM_DEBUG_DRIVER("DisplayPort hotplug status %d crtc %p eld %#x\n",
+connector->status,
+crtc,
+(unsigned int)connector->eld[0]);
+
+   if (connector->status == connector_status_disconnected) {
+   intel_dp->DP &= ~DP_AUDIO_OUTPUT_ENABLE;
+   } else if (connector->status == connector_status_connected && crtc) {
+   intel_write_eld(&intel_dp->base.base, &crtc->mode);
+   intel_dp->DP |= DP_AUDIO_OUTPUT_ENABLE;
+   } else {
+   return;
+   }
+   I915_WRITE(intel_dp->output_reg, intel_dp->DP);
+   POSTING_READ(intel_dp->output_reg);
+}
+
 static int intel_dp_get_modes(struct drm_connector *connector)
 {
struct intel_dp *intel_dp = intel_attached_dp(connector);
@@ -2143,6 +2168,7 @@ static const struct drm_connector_funcs 
.detect = intel_dp_detect,
.fill_modes = drm_helper_probe_single_connector_modes,
.set_property = intel_dp_set_property,
+   .hotplug = intel_dp_hotplug,
.destroy = intel_dp_destroy,
 };

--- linux.orig/drivers/gpu/drm/i915/intel_hdmi.c2011-11-21 
11:26:09.0 +0800
+++ linux/drivers/gpu/drm/i915/intel_hdmi.c 2011-11-21 14:12:26.0 
+0800
@@ -337,6 +337,7 @@ intel_hdmi_detect(struct drm_connector *
status = connector_status_connected;
intel_hdmi->has_hdmi_sink = 
drm_detect_hdmi_monitor(edid);
intel_hdmi->has_audio = drm_detect_monitor_audio(edid);
+   drm_edid_to_eld(connector, edid);
}
connector->display_info.raw_edid = NULL;
kfree(edid);
@@ -350,6 +351,35 @@ intel_hdmi_detect(struct drm_connector *
return status;
 }

+static void intel_hdmi_hotplug(st

[PATCH 3/3 v3] drm/i915: hot plug/unplug notification to HDMI audio driver

[Wu Fengguang]

On monitor hot plug/unplug, update ELD and set/clear SDVO_AUDIO_ENABLE
or DP_AUDIO_OUTPUT_ENABLE accordingly.  So that the audio driver will
receive hot plug events and take action to refresh its device state and
ELD contents.

A new callback ->hotplug() is added to struct drm_connector_funcs which
will be called immediately after ->detect() knowing that the monitor is
either plugged or unplugged.

It's noticed that X may not call ->mode_set() at monitor hot plug, so it's
necessary to call drm_edid_to_eld() earlier at ->detect() time rather than
in intel_ddc_get_modes(), so that intel_write_eld() can see the new ELD
in ->hotplug.

The call sequence on hot plug is
(the difference part lies in ->mode_set vs ->hotplug)

- KMS console
->detect
  drm_edid_to_eld
->mode_set
  intel_write_eld
  set SDVO_AUDIO_ENABLE/DP_AUDIO_OUTPUT_ENABLE
- X
->detect
  drm_edid_to_eld
->hotplug
  intel_write_eld
  set SDVO_AUDIO_ENABLE/DP_AUDIO_OUTPUT_ENABLE

On hot remove, the call sequence is

->hotplug
  clear SDVO_AUDIO_ENABLE/DP_AUDIO_OUTPUT_ENABLE

cc: Wang Zhenyu 
Signed-off-by: Wu Fengguang 
---
 drivers/gpu/drm/drm_crtc_helper.c  |6 +++
 drivers/gpu/drm/i915/intel_dp.c|   44 +--
 drivers/gpu/drm/i915/intel_hdmi.c  |   31 +++
 drivers/gpu/drm/i915/intel_modes.c |2 -
 include/drm/drm_crtc.h |1 
 5 files changed, 72 insertions(+), 12 deletions(-)

Changes since v2:

Fix "kernel NULL pointer dereference" due to calling NULL ->hotplug.

--- linux.orig/drivers/gpu/drm/i915/intel_dp.c  2011-11-21 11:26:09.0 
+0800
+++ linux/drivers/gpu/drm/i915/intel_dp.c   2011-11-21 14:12:21.0 
+0800
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "drmP.h"
 #include "drm.h"
 #include "drm_crtc.h"
@@ -1970,20 +1971,44 @@ intel_dp_detect(struct drm_connector *co
if (status != connector_status_connected)
return status;

-   if (intel_dp->force_audio) {
-   intel_dp->has_audio = intel_dp->force_audio > 0;
-   } else {
-   edid = intel_dp_get_edid(connector, &intel_dp->adapter);
-   if (edid) {
-   intel_dp->has_audio = drm_detect_monitor_audio(edid);
-   connector->display_info.raw_edid = NULL;
-   kfree(edid);
-   }
+   edid = intel_dp_get_edid(connector, &intel_dp->adapter);
+   if (edid) {
+   intel_dp->has_audio = drm_detect_monitor_audio(edid);
+   drm_edid_to_eld(connector, edid);
+   connector->display_info.raw_edid = NULL;
+   kfree(edid);
}

+   if (intel_dp->force_audio)
+   intel_dp->has_audio = intel_dp->force_audio > 0;
+
return connector_status_connected;
 }

+static void intel_dp_hotplug(struct drm_connector *connector)
+{
+   struct intel_dp *intel_dp = intel_attached_dp(connector);
+   struct drm_device *dev = intel_dp->base.base.dev;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct drm_crtc *crtc = intel_dp->base.base.crtc;
+
+   DRM_DEBUG_DRIVER("DisplayPort hotplug status %d crtc %p eld %#x\n",
+connector->status,
+crtc,
+(unsigned int)connector->eld[0]);
+
+   if (connector->status == connector_status_disconnected) {
+   intel_dp->DP &= ~DP_AUDIO_OUTPUT_ENABLE;
+   } else if (connector->status == connector_status_connected && crtc) {
+   intel_write_eld(&intel_dp->base.base, &crtc->mode);
+   intel_dp->DP |= DP_AUDIO_OUTPUT_ENABLE;
+   } else {
+   return;
+   }
+   I915_WRITE(intel_dp->output_reg, intel_dp->DP);
+   POSTING_READ(intel_dp->output_reg);
+}
+
 static int intel_dp_get_modes(struct drm_connector *connector)
 {
struct intel_dp *intel_dp = intel_attached_dp(connector);
@@ -2143,6 +2168,7 @@ static const struct drm_connector_funcs 
.detect = intel_dp_detect,
.fill_modes = drm_helper_probe_single_connector_modes,
.set_property = intel_dp_set_property,
+   .hotplug = intel_dp_hotplug,
.destroy = intel_dp_destroy,
 };

--- linux.orig/drivers/gpu/drm/i915/intel_hdmi.c2011-11-21 
11:26:09.0 +0800
+++ linux/drivers/gpu/drm/i915/intel_hdmi.c 2011-11-21 14:12:26.0 
+0800
@@ -337,6 +337,7 @@ intel_hdmi_detect(struct drm_connector *
status = connector_status_connected;
intel_hdmi->has_hdmi_sink = 
drm_detect_hdmi_monitor(edid);
intel_hdmi->has_audio = drm_detect_monitor_audio(edid);
+   drm_edid_to_eld(connector, edid);
}
connector->display_info.raw_edid = NULL;
kfree(edid);
@@ -350,6 +351,35 @@ intel_hdmi_de

[PATCH 3/3] drm/i915: hot removal notification to HDMI audio driver

[Takashi Iwai]

At Mon, 21 Nov 2011 09:58:09 +0800,
Wu Fengguang wrote:
> 
> On Sat, Nov 19, 2011 at 01:46:44AM +0800, Keith Packard wrote:
> > On Fri, 18 Nov 2011 17:37:40 +0800, Wu Fengguang  > intel.com> wrote:
> > 
> > > However when in X, ->mode_set won't be called at all.  Only
> > > ->get_modes and ->detect are called...
> > 
> > The desktop software will call mode_set when it configures the
> > monitor. Otherwise, it's not being used (and so shouldn't have audio
> > routed to it by default).
> 
> Keith, I experimented playing HDMI audio in X, and during the time
> unplug and plug the monitor. The HDMI audio/graphics all continue to
> work when plugged in the monitor again. Here is the dmesg showed for
> the plug event, no ->mode_set is called at all...

Which desktop system are you using?  At hotplug/unplugging, the kernel
drm issues a udev event, X Intel driver receives it and updates
Xrandr.  Then it's supposed that a daemon like gnome-settings-daemon
receives Xrandr notification and changes the modes appropriately.
Without such a background task, there will be no mode change.


Takashi

[Intel-gfx] [PATCH 01/13] drm/i915: fall through pwrite_gtt_slow to the shmem slow path

[Chris Wilson]

On Sun, 20 Nov 2011 19:09:18 -0800, Ben Widawsky  wrote:
> On Sun,  6 Nov 2011 20:13:48 +0100
> Daniel Vetter  wrote:
> 
> > The gtt_pwrite slowpath grabs the userspace memory with
> > get_user_pages. This will not work for non-page backed memory, like a
> > gtt mmapped gem object. Hence fall throuh to the shmem paths if we hit
> > -EFAULT in the gtt paths.
> > 
> > Now the shmem paths have exactly the same problem, but this way we
> > only need to rearrange the code in one write path.
> > 
> > v2: v1 accidentaly falls back to shmem pwrite for phys objects. Fixed.
> > 
> > Signed-Off-by: Daniel Vetter 
> 
> It would be nice if there was some way to notify users that pwriting a
> gtt mmapped address can be really damn slow. That's also the one
> behavior change this patch introduces. It's possible that some SW was
> expecting to get a, "fast path" and would deal with the -EFAULT if it
> didn't get it.

The behaviour change is intentional. Before this patch we would
deadlock...
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH] drm/ttm: pass buffer object for bind/unbind callback

[Thomas Hellstrom]

On 11/20/2011 04:13 PM, Jerome Glisse wrote:
> On Sun, Nov 20, 2011 at 4:30 AM, Thomas Hellstrom  
> wrote:
>
>> On 11/19/2011 11:54 PM, Jerome Glisse wrote:
>>
>> As mentioned previously, and in the discussion with Ben, the page tables
>> would not need to be rebuilt on each CS. They would be rebuilt only on the
>> first CS following a move_notify that caused a page table invalidation.
>>
>> move_notify:
>> if (is_incompatible(new_mem_type)) {
>>   bo->page_tables_invalid = true;
>>   invalidate_page_tables(bo);
>> }
>>
>> command_submission:
>> if (bo->page_tables_invalid) {
>>set_up_page_tables(bo);
>>bo->page_tables_invalid = false;
>> }
>>
>>
>> Why is it different from updating page table in move notify ? I don't
>> see any bonus here, all the information we need are already available
>> in move_notify.
>>
>>
>>
>> I've iterated the pros of this approach at least two times before, but for
>> completeness let's do it again:
>>
>> 8<
>>
>> 1) TTM doesn't need to care about the driver re-populating its GPU page
>> tables.
>> Since swapin is handled from the tt layer not the bo layer, this makes it a
>> bit easier on us.
>> 2) Transition to page-faulted GPU virtual maps is straightforward and
>> consistent. A non-page-faulting driver sets up the maps at CS time, A
>> pagefaulting driver can set them up directly from an irq handler without
>> reserving, since the bo is properly fenced or pinned when the pagefault
>> happens.
>> 3) A non-page-faulting driver knows at CS time exactly which
>> page-table-entries really do need populating, and can do this more
>> efficiently.
>>
>> 8<-
>>
>> And some extra items like partially populated TTMs that were mentioned
>> elsewhere.
>>  
> If done in move_notify i don't see why 1 would be different or 2.

Because to make the interface complete we need to support SYSTEM memory, 
and call move_notify from swapin, which I am not prepared to do.

>   I
> agree that in some case 3 is true. Given when move notify is call the
> ttm_tt is always fully populated at that point (only exception is in
> destroy path but it's a special on its own). If driver populate in
> move_notify is doesn't change anything from ttm pov.
>

Then you put a restriction on TTM to *always* have populated TTMs which 
I am also not prepared to accept. It's been recently added as a 
performance optimization.

I won't spend any more time on this completely stupid argument. I've 
been asking you to make a minor change in order to get a complete and 
clean interface, and to get people to do the right thing in the future. 
You're obviously unwilling to do that.


/Thomas

[PATCH 3/3] drm/i915: hot removal notification to HDMI audio driver

[Wu Fengguang]

On Mon, Nov 21, 2011 at 04:47:38PM +0800, Takashi Iwai wrote:
> At Mon, 21 Nov 2011 09:58:09 +0800,
> Wu Fengguang wrote:
> > 
> > On Sat, Nov 19, 2011 at 01:46:44AM +0800, Keith Packard wrote:
> > > On Fri, 18 Nov 2011 17:37:40 +0800, Wu Fengguang  > > intel.com> wrote:
> > > 
> > > > However when in X, ->mode_set won't be called at all.  Only
> > > > ->get_modes and ->detect are called...
> > > 
> > > The desktop software will call mode_set when it configures the
> > > monitor. Otherwise, it's not being used (and so shouldn't have audio
> > > routed to it by default).
> > 
> > Keith, I experimented playing HDMI audio in X, and during the time
> > unplug and plug the monitor. The HDMI audio/graphics all continue to
> > work when plugged in the monitor again. Here is the dmesg showed for
> > the plug event, no ->mode_set is called at all...
> 
> Which desktop system are you using?  At hotplug/unplugging, the kernel
> drm issues a udev event, X Intel driver receives it and updates
> Xrandr.  Then it's supposed that a daemon like gnome-settings-daemon
> receives Xrandr notification and changes the modes appropriately.
> Without such a background task, there will be no mode change.

Ah I got it. I'm running debian+fluxbox w/o those fancy features...

Thanks,
Fengguang

[PATCH -fixes] ttm: Don't return the bo reserved on error path

[Thomas Hellstrom]

An unlikely race could case a bo to be returned reserved on an error path.

Signed-off-by: Thomas Hellstrom 
---
 drivers/gpu/drm/ttm/ttm_bo.c |8 +++-
 1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 617b646..0bb0f5f 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -574,10 +574,16 @@ retry:
return ret;

spin_lock(&glob->lru_lock);
+
+   if (unlikely(list_empty(&bo->ddestroy))) {
+   spin_unlock(&glob->lru_lock);
+   return 0;
+   }
+
ret = ttm_bo_reserve_locked(bo, interruptible,
no_wait_reserve, false, 0);

-   if (unlikely(ret != 0) || list_empty(&bo->ddestroy)) {
+   if (unlikely(ret != 0)) {
spin_unlock(&glob->lru_lock);
return ret;
}
-- 
1.7.4.4

[PATCH -fixes 0/3] Documentation updates

[Thomas Hellstrom]

A couple of updates to various interface docs

In-Reply-To: 

[PATCH 1/3] drm: Update the DRM_IOCTL_MODE_CURSOR documentation

[Thomas Hellstrom]

Document that DRM_IOCTL_MODE_CURSOR needs to be called in order to
guarantee that the cursor bo contents is updated to the screen.
This was agreed upon on the DRI mailing list.

Signed-off-by: Thomas Hellstrom 
---
 include/drm/drm_mode.h |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
index d30bedf..9006b93 100644
--- a/include/drm/drm_mode.h
+++ b/include/drm/drm_mode.h
@@ -291,6 +291,11 @@ struct drm_mode_mode_cmd {
  *crtc
  *x
  *y
+ *
+ * The DRM_IOCTL_MODE_CURSOR ioctl needs to be called with the CURSOR_BO flag
+ * in order to guarantee that the cursor image is updated. The implementation
+ * is free to either update the cursor image when the bo contents change, or
+ * when the DRM_IOCTL_MODE_CURSOR ioctl is called.
  */
 struct drm_mode_cursor {
__u32 flags;
-- 
1.7.4.4

[PATCH 2/3] drm: Update the pageflip ioctl documentation

[Thomas Hellstrom]

The pageflip semantics documentation was tailored to Intel hardware, where
pageflips are done by banging on registers. Many GPUs have the possibilities
to send pageflips down the command stream, and the driver command submission
mechanism does not have to block in order to order page-flip and command
execution. Also remove the sync-to-vblank requirement. Some hardware doesn't
support it, and it might not be desired in all situations either.
I think all this was brought up on the DRI-devel email list on the pageflip
ioctl design discussion.

Signed-off-by: Thomas Hellstrom 
---
 include/drm/drm_mode.h |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
index 9006b93..d88ef35 100644
--- a/include/drm/drm_mode.h
+++ b/include/drm/drm_mode.h
@@ -327,9 +327,9 @@ struct drm_mode_crtc_lut {
  * This ioctl will ask KMS to schedule a page flip for the specified
  * crtc.  Once any pending rendering targeting the specified fb (as of
  * ioctl time) has completed, the crtc will be reprogrammed to display
- * that fb after the next vertical refresh.  The ioctl returns
- * immediately, but subsequent rendering to the current fb will block
- * in the execbuffer ioctl until the page flip happens.  If a page
+ * that fb. The ioctl returns immediately, and subsequently queued rendering
+ * to any of the involved fbs will be ordered with the page flip so that it
+ * occurs after the page-flip is ececuted by the hardware. If a page
  * flip is already pending as the ioctl is called, EBUSY will be
  * returned.
  *
-- 
1.7.4.4

[PATCH 3/3] ttm: Update move_notify and swap_notify documentation.

[Thomas Hellstrom]

Update the documentation of these callbacks to reflect the TTM supported
way of setting up driver-private GPU maps, hoping to avoid the Radeon way
leaking into new drivers.

Signed-off-by: Thomas Hellstrom 
---
 include/drm/ttm/ttm_bo_driver.h |   14 --
 1 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index 94eb143..42c3e64 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -439,7 +439,15 @@ struct ttm_bo_driver {
void *(*sync_obj_ref) (void *sync_obj);

/* hook to notify driver about a driver move so it
-* can do tiling things */
+* can do tiling things. This hook can be used to tear
+* down driver private GPU mappings from the BO. It should not,
+* however be used to set up such mappings, since TTM will not
+* call this hook when SYSTEM placed bos are populated with pages.
+* It's recommended that populating driver private GPU maps is
+* done from the command-submission code, where the driver has
+* a more detailed knowledge of exactly what GPU maps need
+* populating.
+*/
void (*move_notify)(struct ttm_buffer_object *bo,
struct ttm_mem_reg *new_mem);
/* notify the driver we are taking a fault on this BO
@@ -447,7 +455,9 @@ struct ttm_bo_driver {
int (*fault_reserve_notify)(struct ttm_buffer_object *bo);

/**
-* notify the driver that we're about to swap out this bo
+* notify the driver that we're about to swap out this bo.
+* Any driver private GPU maps pointing to the bo should be
+* teared down at this point.
 */
void (*swap_notify) (struct ttm_buffer_object *bo);

-- 
1.7.4.4

Bug#649448: udev loading radeon drivers garbles screen output

[Alex Deucher]

On Sun, Nov 20, 2011 at 10:12 PM, Ben Hutchings  wrote:
> On Sun, 2011-11-20 at 19:02 -0600, Jonathan Nieder wrote:
>> reassign 649448 src:linux-2.6 linux-2.6/3.0.0-3
>> severity 649448 important
>> retitle 649448 radeon (evergreen): random-looking pattern of pixels when 
>> firmware not installed
>> tags 649448 + upstream
>> quit
>>
>> Hi Martin,
>>
>> Martin von Gagern wrote:
>>
>> > Version: 3.0.0-3
>> [...]
>> > Just installed a wheezy setup using debootstrap, adding grub-pc and
>> > linux-image-amd64 after the chroot was created. The kernel boots, the
>> > initrd seems all right. When the main system boots up, udev gets launced
>> > pretty early. Soon after it is started, the screen turns into a pretty
>> > random-looking pattern of pixels, making the console pretty unusable.
>> > This also happens in "recovery" i.e. single-user mode.
>> [...]
>> > Possible workarounds seem to include:
>> [...]
>> > - Adding a line "blacklist radeon" to /etc/modprobe.d/blacklist.conf,
>> > ? followed by running "depmod -a".
>> [...]
>> >> [ ?150.125768] r600_cp: Failed to load firmware "radeon/SUMO2_pfp.bin"
>> >> [ ?150.125818] [drm:evergreen_startup] *ERROR* Failed to load firmware!
>> >> [ ?150.125859] radeon :00:01.0: disabling GPU acceleration
>>
>> Yes, the radeon driver currently copes poorly when firmware is missing.
>> Compare [1], [2], [3].
>>
>> [...]
>> > Not having GPU accelleration due to lack of free firmware is acceptable.
>> > Not having a usable text console can be a real problem.
>>
>> Agreed. ?The radeon driver should be bailing out when firmware is
>> missing for cards that need it, but that is not working for some
>> reason.
> [...]
>
> At the time I converted the radeon driver to load external firmware, it
> was apparently only required for 3D acceleration and both KMS and 2D
> acceleration of X worked without it, at least on those systems I tested
> (which were quite old, R100-R300 families). ?Therefore failure to load
> firmware would only result in DRM (3D acceleration support) being
> disabled.
>
> However, it looks like driver support for the R600 family onward now
> absolutely requires the 'RLC' firmware blobs:
>
> commit d8f60cfc93452d0554f6a701aa8e3236cbee4636
> Author: Alex Deucher 
> Date: ? Tue Dec 1 13:43:46 2009 -0500
>
> ? ?drm/radeon/kms: Add support for interrupts on r6xx/r7xx chips (v3)
>
> And the 'Northern Islands' GPUs and 'Fusion' APUs appear to require the
> 'MC' firmware blobs:
>
> commit 0af62b0168043896a042b005ff88caa77dd94d04
> Author: Alex Deucher 
> Date: ? Thu Jan 6 21:19:31 2011 -0500
>
> ? ?drm/radeon/kms: add ucode loader for NI
>
> Therefore I think that at least r600_init(), rv770_init(),
> evergreen_init() and cayman_init() should be treating failure to load
> firmware as a fatal error.
>

R6xx, r7xx should work ok without the RLC ucode, you just won't get
acceleration.  With chips that require the MC ucode, the driver will
bail if the MC ucode is not available.

Alex

> Ben.
>
> --
> Ben Hutchings
> Teamwork is essential - it allows you to blame someone else.
>

[Intel-gfx] [PATCH 02/13] drm/i915: rewrite shmem_pwrite_slow to use copy_from_user

[Daniel Vetter]

On Sun, Nov 20, 2011 at 09:56:32PM -0800, Ben Widawsky wrote:
[snip the patch]
> Bikeshed, but I would much prefer a #define for the swizzle
> bit/cacheline size.

I've looked at this stuff way too long, so I'm biased, but 64 = cacheline
= dram fetch size = 1 << 64 feels about as natural for me as 4096 =
PAGE_SIZE ...

[snip the patch]

> I must be missing something obvious here...
> Can you explain how this can possibly be considered safe without holding
> struct_mutex?

That's the reason why the commit msg goes through every case and explains
why I think it's safe. The large thing here is that we need to drop the
mutex when calling copy_*_user (at least in the non-atomic slow-paths)
because otherwise we might deadlock with our own pagefault handler.
-Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[PATCH] drm, i915: Fix memory leak in i915_gem_busy_ioctl().

[Daniel Vetter]

On Wed, Nov 16, 2011 at 12:49:28AM +0600, Rakib Mullick wrote:
> 
> A call to i915_add_request() has been made in function i915_gem_busy_ioctl(). 
> i915_add_request can fail,
> so in it's exit path previously allocated memory needs to be freed.
> 
> Signed-off-by: Rakib Mullick 

Indeed, nice catch (albeit totally unlikely to be hit, because the error
only happens when the gpu ceases to progress in the ring, so imo not
stable material). Keith, please pick this up for fixes, thanks.

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

[PATCH 3/3 v2] drm/i915: hot plug/unplug notification to HDMI audio driver

[Keith Packard]

On Mon, 21 Nov 2011 14:37:49 +0800, Wu Fengguang  
wrote:
> On monitor hot plug/unplug, update ELD and set/clear SDVO_AUDIO_ENABLE
> or DP_AUDIO_OUTPUT_ENABLE accordingly.  So that the audio driver will
> receive hot plug events and take action to refresh its device state and
> ELD contents.
> 
> A new callback ->hotplug() is added to struct drm_connector_funcs which
> will be called immediately after ->detect() knowing that the monitor is
> either plugged or unplugged.
> 
> It's noticed that X may not call ->mode_set() at monitor hot plug, so it's
> necessary to call drm_edid_to_eld() earlier at ->detect() time rather than
> in intel_ddc_get_modes(), so that intel_write_eld() can see the new ELD
> in ->hotplug.

The X environment will eventually call mode_set when the user
environment decides to use the monitor. Any audio bits can, and should,
await the user's choice of a video mode before choosing the audio format
to use. We should not be adding eld information until the monitor is in
use.

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/2021/458e646b/attachment.pgp>

[PATCH 3/3] drm/i915: hot removal notification to HDMI audio driver

[Keith Packard]

On Mon, 21 Nov 2011 19:05:38 +0800, Wu Fengguang  
wrote:

> Ah I got it. I'm running debian+fluxbox w/o those fancy features...

Then you can manually run the 'xrandr' command to configure the new
monitor as desired, at which point the kernel mode_set function will be
called.

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/2021/112666ad/attachment.pgp>

[PATCH] drm/radeon/kms: fix up gpio i2c mask bits for r4xx for real

[alexdeuc...@gmail.com]

From: Alex Deucher 

Fixes i2c test failures when i2c_algo_bit.bit_test=1.

The hw doesn't actually require a mask, so just set it
to the default mask bits for r1xx-r4xx radeon ddc.

I missed this part the first time through.

Signed-off-by: Alex Deucher 
Cc: stable at kernel.org
Cc: Jean Delvare 

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/radeon_atombios.c |   12 
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c 
b/drivers/gpu/drm/radeon/radeon_atombios.c
index fecd705..933a2cd 100644
--- a/drivers/gpu/drm/radeon/radeon_atombios.c
+++ b/drivers/gpu/drm/radeon/radeon_atombios.c
@@ -181,6 +181,18 @@ void radeon_atombios_i2c_init(struct radeon_device *rdev)
gpio = &i2c_info->asGPIO_Info[i];
i2c.valid = false;

+   /* r4xx mask is technically not used by the hw, so 
patch in the legacy mask bits */
+   if ((rdev->family == CHIP_R420) ||
+   (rdev->family == CHIP_R423) ||
+   (rdev->family == CHIP_RV410)) {
+   if ((le16_to_cpu(gpio->usClkMaskRegisterIndex) 
== 0x0018) ||
+   (le16_to_cpu(gpio->usClkMaskRegisterIndex) 
== 0x0019) ||
+   (le16_to_cpu(gpio->usClkMaskRegisterIndex) 
== 0x001a)) {
+   gpio->ucClkMaskShift = 0x19;
+   gpio->ucDataMaskShift = 0x18;
+   }
+   }
+
/* some evergreen boards have bad data for this entry */
if (ASIC_IS_DCE4(rdev)) {
if ((i == 7) &&
-- 
1.7.3.4

[PATCH] drm, i915: Fix memory leak in i915_gem_busy_ioctl().

[Keith Packard]

On Mon, 21 Nov 2011 17:23:06 +0100, Daniel Vetter  wrote:

> Indeed, nice catch (albeit totally unlikely to be hit, because the error
> only happens when the gpu ceases to progress in the ring, so imo not
> stable material). Keith, please pick this up for fixes, thanks.

It's already there and queued for airlied :-)

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/2021/9fc2994b/attachment.pgp>

[PATCH] drm/radeon/kms/atom: unify i2c gpio table handling

[alexdeuc...@gmail.com]

From: Alex Deucher 

Split the quirks and i2c_rec assignment into separate
functions used by both radeon_lookup_i2c_gpio() and
radeon_atombios_i2c_init().  This avoids duplicating code
and cases where quirks were only added to one of the
functions.

Signed-off-by: Alex Deucher 
Cc: Jean Delvare 
---
 drivers/gpu/drm/radeon/radeon_atombios.c |  214 --
 1 files changed, 86 insertions(+), 128 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c 
b/drivers/gpu/drm/radeon/radeon_atombios.c
index 933a2cd..d24baf3 100644
--- a/drivers/gpu/drm/radeon/radeon_atombios.c
+++ b/drivers/gpu/drm/radeon/radeon_atombios.c
@@ -62,6 +62,87 @@ union atom_supported_devices {
struct _ATOM_SUPPORTED_DEVICES_INFO_2d1 info_2d1;
 };

+static void radeon_lookup_i2c_gpio_quirks(struct radeon_device *rdev,
+ ATOM_GPIO_I2C_ASSIGMENT *gpio,
+ u8 index)
+{
+   /* r4xx mask is technically not used by the hw, so patch in the legacy 
mask bits */
+   if ((rdev->family == CHIP_R420) ||
+   (rdev->family == CHIP_R423) ||
+   (rdev->family == CHIP_RV410)) {
+   if ((le16_to_cpu(gpio->usClkMaskRegisterIndex) == 0x0018) ||
+   (le16_to_cpu(gpio->usClkMaskRegisterIndex) == 0x0019) ||
+   (le16_to_cpu(gpio->usClkMaskRegisterIndex) == 0x001a)) {
+   gpio->ucClkMaskShift = 0x19;
+   gpio->ucDataMaskShift = 0x18;
+   }
+   }
+
+   /* some evergreen boards have bad data for this entry */
+   if (ASIC_IS_DCE4(rdev)) {
+   if ((index == 7) &&
+   (le16_to_cpu(gpio->usClkMaskRegisterIndex) == 0x1936) &&
+   (gpio->sucI2cId.ucAccess == 0)) {
+   gpio->sucI2cId.ucAccess = 0x97;
+   gpio->ucDataMaskShift = 8;
+   gpio->ucDataEnShift = 8;
+   gpio->ucDataY_Shift = 8;
+   gpio->ucDataA_Shift = 8;
+   }
+   }
+
+   /* some DCE3 boards have bad data for this entry */
+   if (ASIC_IS_DCE3(rdev)) {
+   if ((index == 4) &&
+   (le16_to_cpu(gpio->usClkMaskRegisterIndex) == 0x1fda) &&
+   (gpio->sucI2cId.ucAccess == 0x94))
+   gpio->sucI2cId.ucAccess = 0x14;
+   }
+}
+
+static struct radeon_i2c_bus_rec 
radeon_get_bus_rec_for_i2c_gpio(ATOM_GPIO_I2C_ASSIGMENT *gpio)
+{
+   struct radeon_i2c_bus_rec i2c;
+
+   memset(&i2c, 0, sizeof(struct radeon_i2c_bus_rec));
+
+   i2c.mask_clk_reg = le16_to_cpu(gpio->usClkMaskRegisterIndex) * 4;
+   i2c.mask_data_reg = le16_to_cpu(gpio->usDataMaskRegisterIndex) * 4;
+   i2c.en_clk_reg = le16_to_cpu(gpio->usClkEnRegisterIndex) * 4;
+   i2c.en_data_reg = le16_to_cpu(gpio->usDataEnRegisterIndex) * 4;
+   i2c.y_clk_reg = le16_to_cpu(gpio->usClkY_RegisterIndex) * 4;
+   i2c.y_data_reg = le16_to_cpu(gpio->usDataY_RegisterIndex) * 4;
+   i2c.a_clk_reg = le16_to_cpu(gpio->usClkA_RegisterIndex) * 4;
+   i2c.a_data_reg = le16_to_cpu(gpio->usDataA_RegisterIndex) * 4;
+   i2c.mask_clk_mask = (1 << gpio->ucClkMaskShift);
+   i2c.mask_data_mask = (1 << gpio->ucDataMaskShift);
+   i2c.en_clk_mask = (1 << gpio->ucClkEnShift);
+   i2c.en_data_mask = (1 << gpio->ucDataEnShift);
+   i2c.y_clk_mask = (1 << gpio->ucClkY_Shift);
+   i2c.y_data_mask = (1 << gpio->ucDataY_Shift);
+   i2c.a_clk_mask = (1 << gpio->ucClkA_Shift);
+   i2c.a_data_mask = (1 << gpio->ucDataA_Shift);
+
+   if (gpio->sucI2cId.sbfAccess.bfHW_Capable)
+   i2c.hw_capable = true;
+   else
+   i2c.hw_capable = false;
+
+   if (gpio->sucI2cId.ucAccess == 0xa0)
+   i2c.mm_i2c = true;
+   else
+   i2c.mm_i2c = false;
+
+   i2c.i2c_id = gpio->sucI2cId.ucAccess;
+
+   if (i2c.mask_clk_reg)
+   i2c.valid = true;
+   else
+   i2c.valid = false;
+
+   return i2c;
+}
+
 static struct radeon_i2c_bus_rec radeon_lookup_i2c_gpio(struct radeon_device 
*rdev,
   uint8_t id)
 {
@@ -85,71 +166,10 @@ static struct radeon_i2c_bus_rec 
radeon_lookup_i2c_gpio(struct radeon_device *rd
for (i = 0; i < num_indices; i++) {
gpio = &i2c_info->asGPIO_Info[i];

-   /* r4xx mask is technically not used by the hw, so 
patch in the legacy mask bits */
-   if ((rdev->family == CHIP_R420) ||
-   (rdev->family == CHIP_R423) ||
-   (rdev->family == CHIP_RV410)) {
-   if ((le16_to_cpu(gpio->usClkMaskRegisterIndex) 
== 0x0018) ||
-   (le16_to_cpu(gpio->usClkMaskRegisterIndex) 
== 0x0019) ||
- 

[Intel-gfx] [PATCH 02/13] drm/i915: rewrite shmem_pwrite_slow to use copy_from_user

[Ben Widawsky]

On Mon, Nov 21, 2011 at 05:02:44PM +0100, Daniel Vetter wrote:
> On Sun, Nov 20, 2011 at 09:56:32PM -0800, Ben Widawsky wrote:
> [snip the patch]
> > Bikeshed, but I would much prefer a #define for the swizzle
> > bit/cacheline size.
> 
> I've looked at this stuff way too long, so I'm biased, but 64 = cacheline
> = dram fetch size = 1 << 64 feels about as natural for me as 4096 =
> PAGE_SIZE ...
> 
> [snip the patch]
> 
> > I must be missing something obvious here...
> > Can you explain how this can possibly be considered safe without holding
> > struct_mutex?
> 
> That's the reason why the commit msg goes through every case and explains
> why I think it's safe. The large thing here is that we need to drop the
> mutex when calling copy_*_user (at least in the non-atomic slow-paths)
> because otherwise we might deadlock with our own pagefault handler.
> -Daniel

The part about dropping struct_mutex is clear to me.

The bit that I'm missing, I just don't see how you guarantee the page
you're reading from (assuming it's a GTT mmapped page) doesn't get moved
from out under you. For instance if the page isn't there when you do the
initial __copy_from_user, it will get faulted in... cool - but what if
somewhere in that loop the object gets swapped out and something else is
put in it's place? How is that prevented?

Sorry if it's a stupid question, I just don't get it.
Ben

[Intel-gfx] [PATCH 02/13] drm/i915: rewrite shmem_pwrite_slow to use copy_from_user

[Ben Widawsky]

On Mon, Nov 21, 2011 at 09:55:07AM -0800, Ben Widawsky wrote:
> On Mon, Nov 21, 2011 at 05:02:44PM +0100, Daniel Vetter wrote:
> > On Sun, Nov 20, 2011 at 09:56:32PM -0800, Ben Widawsky wrote:
> > [snip the patch]
> > > Bikeshed, but I would much prefer a #define for the swizzle
> > > bit/cacheline size.
> > 
> > I've looked at this stuff way too long, so I'm biased, but 64 = cacheline
> > = dram fetch size = 1 << 64 feels about as natural for me as 4096 =
> > PAGE_SIZE ...
> > 
> > [snip the patch]
> > 
> > > I must be missing something obvious here...
> > > Can you explain how this can possibly be considered safe without holding
> > > struct_mutex?
> > 
> > That's the reason why the commit msg goes through every case and explains
> > why I think it's safe. The large thing here is that we need to drop the
> > mutex when calling copy_*_user (at least in the non-atomic slow-paths)
> > because otherwise we might deadlock with our own pagefault handler.
> > -Daniel
> 
> The part about dropping struct_mutex is clear to me.
> 
> The bit that I'm missing, I just don't see how you guarantee the page
> you're reading from (assuming it's a GTT mmapped page) doesn't get moved
> from out under you. For instance if the page isn't there when you do the
> initial __copy_from_user, it will get faulted in... cool - but what if
> somewhere in that loop the object gets swapped out and something else is
> put in it's place? How is that prevented?
> 
> Sorry if it's a stupid question, I just don't get it.
> Ben

Okay, I got what I was missing from IRC. Anytime the object is unmapped
we shoot down the userspace mapping. I couldn't find it in the code, but
it turned out to be right in front of me.

Reviewed-by: Ben Widawsky 

[Intel-gfx] [PATCH 06/13] drm: add helper to clflush a virtual address range

[Ben Widawsky]

On Sun, Nov 06, 2011 at 08:13:53PM +0100, Daniel Vetter wrote:
> Useful when the page is already mapped to copy date in/out.
> 
> Cc: dri-devel at lists.freedesktop.org
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_cache.c |   23 +++
>  include/drm/drmP.h  |1 +
>  2 files changed, 24 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c
> index 0e3bd5b..502771a 100644
> --- a/drivers/gpu/drm/drm_cache.c
> +++ b/drivers/gpu/drm/drm_cache.c
> @@ -97,3 +97,26 @@ drm_clflush_pages(struct page *pages[], unsigned long 
> num_pages)
>  #endif
>  }
>  EXPORT_SYMBOL(drm_clflush_pages);
> +
> +void
> +drm_clflush_virt_range(char *addr, unsigned long length)
> +{
> +#if defined(CONFIG_X86)
> + if (cpu_has_clflush) {
> + char *end = addr + length;
> + mb();
> + for (; addr < end; addr += boot_cpu_data.x86_clflush_size)
> + clflush(addr);
> + clflush(end - 1);
> + mb();
> + return;
> + }
> +
> + if (on_each_cpu(drm_clflush_ipi_handler, NULL, 1) != 0)
> + printk(KERN_ERR "Timed out waiting for cache flush.\n");
> +#else
> + printk(KERN_ERR "Architecture has no drm_cache.c support\n");
> + WARN_ON_ONCE(1);
> +#endif
> +}
> +EXPORT_SYMBOL(drm_clflush_virt_range);

I'd feel more comfortable with a BUG_ON(irqs_disabled()); before the
IPI... though I don't even know how many platforms that actually
pertains to (if any).

[REGRESSION]: hibernate/sleep regression w/ bisection

[Tejun Heo]

On Fri, Nov 04, 2011 at 06:08:20PM -0500, Andrew Watts wrote:
> On Fri, Nov 04, 2011 at 01:35:53PM -0400, Jerome Glisse wrote:
> > 
> > I need full dmesg
> > 
> > Cheers,
> > Jerome
> 
> Hi. Just noticed I attached a gzip of my dmesg last time by mistake.
> 
> Here goes as text/plain.

Out of curiosity, did it get somewhere?

Thanks.

-- 
tejun

[REGRESSION]: hibernate/sleep regression w/ bisection

[Jerome Glisse]

On Mon, Nov 21, 2011 at 4:09 PM, Tejun Heo  wrote:
> On Fri, Nov 04, 2011 at 06:08:20PM -0500, Andrew Watts wrote:
>> On Fri, Nov 04, 2011 at 01:35:53PM -0400, Jerome Glisse wrote:
>> >
>> > I need full dmesg
>> >
>> > Cheers,
>> > Jerome
>>
>> Hi. Just noticed I attached a gzip of my dmesg last time by mistake.
>>
>> Here goes as text/plain.
>
> Out of curiosity, did it get somewhere?
>
> Thanks.
>
> --
> tejun
>

Yeah i am pretty sure i know what's going wrong but there is no easy
fix, there is a deadlock in the kernel when gem wait ioctl is call on
scanout buffer and that a gpu reset happen

Cheers,
Jerome

3.2-rc2+: Reported regressions from 3.0 and 3.1

[Linus Torvalds]

On Mon, Nov 21, 2011 at 1:49 PM, Rafael J. Wysocki  wrote:
>
> Subject ? ?: Simultaneous cat and external keyboard input causing kernel panic
> Submitter ?: Timo Jyrinki 
> Date ? ? ? : 2011-11-03 12:14
> Message-ID : CAJtFfxmovJHspHHKbvBVc4pw+u5mjGmUejCXEzdV+GqE=jVSOQ at 
> mail.gmail.com
> References : http://marc.info/?l=linux-kernel&m=132032253903074&w=2

So while funny, I doubt this is actually a bug. It's a feature, as
pointed out by Clemens Ladisch in that thread.

It's simply sysrq-c: "perform a system crash by a NULL pointer dereference".

Now, I'm perfectly willing to consider that feature to be a
mis-feature, and that this should be considered a bug to be fixed. But
it is not a regression.

Keeping it on the regression list just because it is amusing is
understandable, though ;)

Linus

[Bug 42514] [r300g] EVE online: some shaders are failing

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

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

--- Comment #4 from Pavel Ondra?ka  2011-11-21 
14:11:58 PST ---
I'm wondering if this should be reassigned to glsl-compiler since the error
messages come from src/glsl/ast_to_hir.cpp not the r300 driver? Tom, Marek, can
you comment on this?

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

3.2-rc2+: Reported regressions from 3.0 and 3.1

[Linus Torvalds]

On Mon, Nov 21, 2011 at 1:49 PM, Rafael J. Wysocki  wrote:
>
> Subject ? ?: [3.1 REGRESSION] Commit 5cec93c216db77c45f7ce970d46283bcb1933884 
> breaks the Chromium seccomp sandbox
> Submitter ?: Nix 
> Date ? ? ? : 2011-11-14 0:40
> Message-ID : 8762inleno.fsf at spindle.srvr.nix
> References : http://marc.info/?l=linux-kernel&m=132123396226377&w=2

So this should be fixed by commit 2b666859ec32 ("x86: Default to
vsyscall=native for now"), since we disabled the vsyscall emulation
because it broken UML too.

Of course, the chromium seccomp thing might re-surface with the
patches that enable the emulation (with better emulation), which Andy
is still working on, and that I was planning on merging for 3.3.

Andy, it migth be worth contacting Nix and having him test whether
your fixed emulation works for chromium too.

  Linus

3.2-rc2+: Reported regressions from 3.0 and 3.1

[Rafael J. Wysocki]

This message contains a list of some regressions from 3.0 and 3.1
for which there are no fixes in the mainline known to the tracking team.
If any of them have been fixed already, please let us know.

If you know of any other unresolved regressions from 3.0 and 3.1, please let us
know either and we'll add them to the list.  Also, please let us know if any of
the entries below are invalid.

The entries below are simplified and the statistics are not present due to the
continuing Bugzilla outage.

Subject: iwlagn is getting very shaky
Submitter  : Norbert Preining 
Date   : 2011-10-19 6:01
Message-ID : 20111019060108.GA11588 at gamma.logic.tuwien.ac.at
References : http://marc.info/?l=linux-kernel&m=131914553920614&w=2

Subject: Regression: "irqpoll" hasn't been working for me since March 16 IRQ
Submitter  : Edward Donovan 
Date   : 2011-10-19 22:09
Message-ID : CADdbW+HXdCPfJu2RTF6zz+ujCmiu_dmZwL2iScuF53p=AaZ1Uw at 
mail.gmail.com
References : http://marc.info/?l=linux-kernel&m=131914554220679&w=2

Subject: Regression in 3.1 causes Xen to use wrong idle routine
Submitter  : Stefan Bader 
Date   : 2011-10-26 10:24
Message-ID : 4EA7DFD1.9060608 at canonical.com
References : http://marc.info/?l=linux-acpi&m=131962467924564&w=2

Subject: 3.1+ iwlwifi lockup
Submitter  : Dave Jones 
Date   : 2011-10-31 14:34
Message-ID : 20111031143408.GA17152 at redhat.com
References : http://marc.info/?l=linux-kernel&m=132007169420160&w=2

Subject: hugetlb oops on 3.1.0-rc8-devel
Submitter  : Andy Lutomirski 
Date   : 2011-11-01 22:20
Message-ID : CALCETrW1mpVCz2tO5roaz1r6vnno+srHR-dHA6_pkRi2qiCfdw at 
mail.gmail.com
References : http://marc.info/?l=linux-kernel&m=132018604426692&w=2

Subject: Simultaneous cat and external keyboard input causing kernel panic
Submitter  : Timo Jyrinki 
Date   : 2011-11-03 12:14
Message-ID : CAJtFfxmovJHspHHKbvBVc4pw+u5mjGmUejCXEzdV+GqE=jVSOQ at 
mail.gmail.com
References : http://marc.info/?l=linux-kernel&m=132032253903074&w=2

Subject: Linus GIT - INFO: possible circular locking dependency detected
Submitter  : Miles Lane 
Date   : 2011-11-03 15:57
Message-ID : CAHFgRy8S0xLfhZxTUOEH5A0PL_Fb79-0-gmbQ=9h2D-xMqt1hA at 
mail.gmail.com
References : http://marc.info/?l=linux-kernel&m=132033587908426&w=2

Subject: lockdep warning after aa6afca5bcab: "proc: fix races against 
execve() of /proc/PID/fd**"
Submitter  : Ari Savolainen 
Date   : 2011-11-08 3:47
Message-ID : CAEbykaXYZEFhTgWMm2AfaWQ2SaXYuO_ypTnw+6AVWScOYSCuuw at 
mail.gmail.com
References : http://marc.info/?l=linux-kernel&m=132072413125099&w=2

Subject: DMA-API check_sync errors with 3.2
Submitter  : Josh Boyer 
Date   : 2011-11-08 17:31
Message-ID : 2008173153.GE14216 at zod.bos.redhat.com
References : http://marc.info/?l=linux-kernel&m=132077357608797&w=2

Subject: [3.1-rc8 REGRESSION] sky2 hangs machine on turning off or 
suspending
Submitter  : Rafa? Mi?ecki 
Date   : 2011-11-09 11:46
Message-ID : CACna6ryTdLcWVYgHu=_mRFga1sFivpE_DyZOY-HMmKggkWAJAw at 
mail.gmail.com
References : http://marc.info/?l=linux-netdev&m=13208398088&w=4

Subject: 3.2-rc1 doesn't boot on dual socket opteron without swap
Submitter  : Niklas Schnelle 
Date   : 2011-11-10 20:09
Message-ID : 1320955769.1718.8.camel at jupiter
References : http://marc.info/?l=linux-kernel&m=132095583501767&w=2

Subject: Sparc-32 doesn't work in 3.1.
Submitter  : Rob Landley 
Date   : 2011-11-12 11:22
Message-ID : 4EBEAB5A.5020809 at landley.net
References : http://www.spinics.net/lists/kernel/msg1260383.html

Subject: khugepaged blocks suspend2ram (3.2.0-rc1-00252-g8f042aa)
Submitter  : Sergei Trofimovich 
Date   : 2011-11-12 10:48
Message-ID : 2012104859.7744b282 at sf.home
References : https://lkml.org/lkml/2011/11/12/11

Subject: WARNING: at fs/sysfs/sysfs.h:195 (during boot)
Submitter  : Markus Trippelsdorf 
Date   : 2011-11-13 19:24
Message-ID : 2013192417.GA1659 at x4.trippels.de
References : http://marc.info/?l=linux-kernel&m=132121231921932&w=2

Subject: PROBLEM: Radeon display connector : No monitor connected or 
invalid EDID
Submitter  : Treeve Jelbert 
Date   : 2011-11-13 17:27
Message-ID : 2407026.akcTO2Ggic at gemini-64
References : http://marc.info/?l=linux-kernel&m=132120530920139&w=2

Subject: [3.1 REGRESSION] Commit 5cec93c216db77c45f7ce970d46283bcb1933884 
breaks the Chromium seccomp sandbox
Submitter  : Nix 
Date   : 2011-11-14 0:40
Message-ID : 8762inleno.fsf at spindle.srvr.nix
References : http://marc.info/?l=linux-kernel&m=132123396226377&w=2

Subject: max PWM is zero
Submitter  : Marcos Paulo de Souza 
Date   : 2011-11-15 15:14
Message-ID : alpine.LNX.2.00.151301410.2693 at darkstar.example.net
References : http://marc.info/?l=linux-kernel&m=132137019330548&w=2

Subject: Oops on suspend with libertas SDIO (Linux 3.2-rc2)
Submitter  : Sven Neumann 
Date   : 2011-11-17 15:36
Message-ID : 1321544210.3

3.2-rc2+: Reported regressions from 3.0 and 3.1

[Linus Torvalds]

On Mon, Nov 21, 2011 at 1:49 PM, Rafael J. Wysocki  wrote:
>
> Subject ? ?: hugetlb oops on 3.1.0-rc8-devel
> Submitter ?: Andy Lutomirski 
> Date ? ? ? : 2011-11-01 22:20
> Message-ID : CALCETrW1mpVCz2tO5roaz1r6vnno+srHR-dHA6_pkRi2qiCfdw at 
> mail.gmail.com
> References : http://marc.info/?l=linux-kernel&m=132018604426692&w=2

Despite the subject line, that's not an oops, it's a BUG_ON().

And it *should* be fixed by commit ea4039a34c4c ("hugetlb: release
pages in the error path of hugetlb_cow()") although I don't think Andy
ever confirmed that (since it was hard to trigger).

 Linus

3.2-rc2+: Reported regressions from 3.0 and 3.1

[Linus Torvalds]

On Mon, Nov 21, 2011 at 1:49 PM, Rafael J. Wysocki  wrote:
>
> Subject ? ?: lockdep warning after aa6afca5bcab: "proc: fix races against 
> execve() of /proc/PID/fd**"
> Submitter ?: Ari Savolainen 
> Date ? ? ? : 2011-11-08 3:47
> Message-ID : CAEbykaXYZEFhTgWMm2AfaWQ2SaXYuO_ypTnw+6AVWScOYSCuuw at 
> mail.gmail.com
> References : http://marc.info/?l=linux-kernel&m=132072413125099&w=2

Commit aa6afca5bcab was reverted by commit 5e442a493fc5, so this one
is presumably stale.

  Linus

3.2-rc2+: Reported regressions from 3.0 and 3.1

[Linus Torvalds]

On Mon, Nov 21, 2011 at 1:49 PM, Rafael J. Wysocki  wrote:
>
> Subject ? ?: [3.1-rc8 REGRESSION] sky2 hangs machine on turning off or 
> suspending
> Submitter ?: Rafa? Mi?ecki 
> Date ? ? ? : 2011-11-09 11:46
> Message-ID : CACna6ryTdLcWVYgHu=_mRFga1sFivpE_DyZOY-HMmKggkWAJAw at 
> mail.gmail.com
> References : http://marc.info/?l=linux-netdev&m=13208398088&w=4

This should be fixed by commit 1401a8008a09 ("sky2: fix hang on
shutdown (and other irq issues)") in current -git.

   Linus

3.2-rc2+: Reported regressions from 3.0 and 3.1

[Alex Deucher]

On Mon, Nov 21, 2011 at 4:49 PM, Rafael J. Wysocki  wrote:
> This message contains a list of some regressions from 3.0 and 3.1
> for which there are no fixes in the mainline known to the tracking team.
> If any of them have been fixed already, please let us know.
>
> If you know of any other unresolved regressions from 3.0 and 3.1, please let 
> us
> know either and we'll add them to the list. ?Also, please let us know if any 
> of
> the entries below are invalid.
>
> The entries below are simplified and the statistics are not present due to the
> continuing Bugzilla outage.
>
> Subject ? ?: iwlagn is getting very shaky
> Submitter ?: Norbert Preining 
> Date ? ? ? : 2011-10-19 6:01
> Message-ID : 20111019060108.GA11588 at gamma.logic.tuwien.ac.at
> References : http://marc.info/?l=linux-kernel&m=131914553920614&w=2
>
> Subject ? ?: Regression: "irqpoll" hasn't been working for me since March 16 
> IRQ
> Submitter ?: Edward Donovan 
> Date ? ? ? : 2011-10-19 22:09
> Message-ID : CADdbW+HXdCPfJu2RTF6zz+ujCmiu_dmZwL2iScuF53p=AaZ1Uw at 
> mail.gmail.com
> References : http://marc.info/?l=linux-kernel&m=131914554220679&w=2
>
> Subject ? ?: Regression in 3.1 causes Xen to use wrong idle routine
> Submitter ?: Stefan Bader 
> Date ? ? ? : 2011-10-26 10:24
> Message-ID : 4EA7DFD1.9060608 at canonical.com
> References : http://marc.info/?l=linux-acpi&m=131962467924564&w=2
>
> Subject ? ?: 3.1+ iwlwifi lockup
> Submitter ?: Dave Jones 
> Date ? ? ? : 2011-10-31 14:34
> Message-ID : 20111031143408.GA17152 at redhat.com
> References : http://marc.info/?l=linux-kernel&m=132007169420160&w=2
>
> Subject ? ?: hugetlb oops on 3.1.0-rc8-devel
> Submitter ?: Andy Lutomirski 
> Date ? ? ? : 2011-11-01 22:20
> Message-ID : CALCETrW1mpVCz2tO5roaz1r6vnno+srHR-dHA6_pkRi2qiCfdw at 
> mail.gmail.com
> References : http://marc.info/?l=linux-kernel&m=132018604426692&w=2
>
> Subject ? ?: Simultaneous cat and external keyboard input causing kernel panic
> Submitter ?: Timo Jyrinki 
> Date ? ? ? : 2011-11-03 12:14
> Message-ID : CAJtFfxmovJHspHHKbvBVc4pw+u5mjGmUejCXEzdV+GqE=jVSOQ at 
> mail.gmail.com
> References : http://marc.info/?l=linux-kernel&m=132032253903074&w=2
>
> Subject ? ?: Linus GIT - INFO: possible circular locking dependency detected
> Submitter ?: Miles Lane 
> Date ? ? ? : 2011-11-03 15:57
> Message-ID : CAHFgRy8S0xLfhZxTUOEH5A0PL_Fb79-0-gmbQ=9h2D-xMqt1hA at 
> mail.gmail.com
> References : http://marc.info/?l=linux-kernel&m=132033587908426&w=2
>
> Subject ? ?: lockdep warning after aa6afca5bcab: "proc: fix races against 
> execve() of /proc/PID/fd**"
> Submitter ?: Ari Savolainen 
> Date ? ? ? : 2011-11-08 3:47
> Message-ID : CAEbykaXYZEFhTgWMm2AfaWQ2SaXYuO_ypTnw+6AVWScOYSCuuw at 
> mail.gmail.com
> References : http://marc.info/?l=linux-kernel&m=132072413125099&w=2
>
> Subject ? ?: DMA-API check_sync errors with 3.2
> Submitter ?: Josh Boyer 
> Date ? ? ? : 2011-11-08 17:31
> Message-ID : 2008173153.GE14216 at zod.bos.redhat.com
> References : http://marc.info/?l=linux-kernel&m=132077357608797&w=2
>
> Subject ? ?: [3.1-rc8 REGRESSION] sky2 hangs machine on turning off or 
> suspending
> Submitter ?: Rafa? Mi?ecki 
> Date ? ? ? : 2011-11-09 11:46
> Message-ID : CACna6ryTdLcWVYgHu=_mRFga1sFivpE_DyZOY-HMmKggkWAJAw at 
> mail.gmail.com
> References : http://marc.info/?l=linux-netdev&m=13208398088&w=4
>
> Subject ? ?: 3.2-rc1 doesn't boot on dual socket opteron without swap
> Submitter ?: Niklas Schnelle 
> Date ? ? ? : 2011-11-10 20:09
> Message-ID : 1320955769.1718.8.camel at jupiter
> References : http://marc.info/?l=linux-kernel&m=132095583501767&w=2
>
> Subject ? ?: Sparc-32 doesn't work in 3.1.
> Submitter ?: Rob Landley 
> Date ? ? ? : 2011-11-12 11:22
> Message-ID : 4EBEAB5A.5020809 at landley.net
> References : http://www.spinics.net/lists/kernel/msg1260383.html
>
> Subject ? ?: khugepaged blocks suspend2ram (3.2.0-rc1-00252-g8f042aa)
> Submitter ?: Sergei Trofimovich 
> Date ? ? ? : 2011-11-12 10:48
> Message-ID : 2012104859.7744b282 at sf.home
> References : https://lkml.org/lkml/2011/11/12/11
>
> Subject ? ?: WARNING: at fs/sysfs/sysfs.h:195 (during boot)
> Submitter ?: Markus Trippelsdorf 
> Date ? ? ? : 2011-11-13 19:24
> Message-ID : 2013192417.GA1659 at x4.trippels.de
> References : http://marc.info/?l=linux-kernel&m=132121231921932&w=2
>
> Subject ? ?: PROBLEM: Radeon display connector : No monitor connected or 
> invalid EDID
> Submitter ?: Treeve Jelbert 
> Date ? ? ? : 2011-11-13 17:27
> Message-ID : 2407026.akcTO2Ggic at gemini-64
> References : http://marc.info/?l=linux-kernel&m=132120530920139&w=2

Treeve replied to me directly saying the it was a problem with his
config file and everything is working fine now.

Alex

>
> Subject ? ?: [3.1 REGRESSION] Commit 5cec93c216db77c45f7ce970d46283bcb1933884 
> breaks the Chromium seccomp sandbox
> Submitter ?: Nix 
> Date ? ? ? : 2011-11-14 0:40
> Message-ID : 8762inleno.fsf at spindle.srvr.nix
> References : http://marc.info/?l=linux-kernel&

[Bug 42514] [r300g] EVE online: some shaders are failing

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

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

--- Comment #5 from Marek Ol??k  2011-11-21 14:31:48 PST 
---
Yes, the component should be glsl-compiler.

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

[PATCH -fixes] ttm: Don't return the bo reserved on error path

[Jerome Glisse]

On Mon, Nov 21, 2011 at 01:05:02PM +0100, Thomas Hellstrom wrote:
> An unlikely race could case a bo to be returned reserved on an error path.
> 
> Signed-off-by: Thomas Hellstrom 
Reviewed-by: Jerome Glisse 
> ---
>  drivers/gpu/drm/ttm/ttm_bo.c |8 +++-
>  1 files changed, 7 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index 617b646..0bb0f5f 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -574,10 +574,16 @@ retry:
>   return ret;
>  
>   spin_lock(&glob->lru_lock);
> +
> + if (unlikely(list_empty(&bo->ddestroy))) {
> + spin_unlock(&glob->lru_lock);
> + return 0;
> + }
> +
>   ret = ttm_bo_reserve_locked(bo, interruptible,
>   no_wait_reserve, false, 0);
>  
> - if (unlikely(ret != 0) || list_empty(&bo->ddestroy)) {
> + if (unlikely(ret != 0)) {
>   spin_unlock(&glob->lru_lock);
>   return ret;
>   }
> -- 
> 1.7.4.4
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

max PWM is zero

[Keith Packard]

On Mon, 21 Nov 2011 22:48:21 + (Local time zone must be set--see zic manual 
page), Marcos Paulo de Souza  wrote:

> My max_brightness is 1, and my brightness is 0.

Right, we've prevented the internal backlight driver from exposing a max
value of 0 as that's just confusing.

> But, my acpi_video0 have a 
> max_brightness value = 9...

Right, sounds like your device is just using some other backlight
controller, which is perfectly reasonable.

> So, what can I do to silence this warning...? Change the driver of 
> backlight?

If your backlight keys work correctly, then things are fine and perhaps
we should just remove the warning from the driver, or disable the
internal driver when we discover this situation.

This is the first time I've heard of this warning appearing...

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/2021/06e1bca3/attachment.pgp>

3.2-rc2+: Reported regressions from 3.0 and 3.1

[Andrew Morton]

On Tue, 22 Nov 2011 11:19:24 +0530 "Srivatsa S. Bhat"  wrote:

> > Subject: khugepaged blocks suspend2ram (3.2.0-rc1-00252-g8f042aa)
> > Submitter  : Sergei Trofimovich 
> > Date   : 2011-11-12 10:48
> > Message-ID : 2012104859.7744b282 at sf.home
> > References : https://lkml.org/lkml/2011/11/12/11
> > 
> 
> Andrea's patch already fixes this issue, which was reported first by
> Jiri Slaby. https://lkml.org/lkml/2011/11/11/93
> I remember Andrew Morton taking this patch in his -mm tree. But it is
> not in mainline yet. So can we consider this closed or not?

grr, nothing in that patch's changelog indicates that it fixed a
regression nor that it fixed an infinite blockage of suspend.

I moved it to my 3.2 queue, thanks.

max PWM is zero

[Marcos Paulo de Souza]

Hi Keith,

On Sat, 19 Nov 2011, Keith Packard wrote:

> On Sat, 19 Nov 2011 11:26:07 + (Local time zone must be set--see zic 
> manual page), Marcos Paulo de Souza  wrote:
>> So, anybody gets the same message?
>>
>> I'm trying the 3.2-rc2 and it gives the same message.
>>
>> Again, if you need someone to make tests, or test some patches, I'm
>> able to do this.
>
> Is your machine even using the intel backlight device? You can test this
> by:
>
> # cd /sys/class/backlight/intel_backlight
>
> Then look at 'max_brightness' and try echoing a range of numbers from 0
> to max_brightness into the brightness file and see if it changes the
> backlight.
My max_brightness is 1, and my brightness is 0. But, my acpi_video0 have a 
max_brightness value = 9...
> It's more than possible that your machine is simply using some other
> hardware to drive the backlight and that the integrated backlight
> controller is simply disabled.
So, what can I do to silence this warning...? Change the driver of 
backlight?
> -- 
> keith.packard at intel.com
>

3.2-rc2+: Reported regressions from 3.0 and 3.1

[Andy Lutomirski]

On Mon, Nov 21, 2011 at 2:18 PM, Linus Torvalds
 wrote:
> On Mon, Nov 21, 2011 at 1:49 PM, Rafael J. Wysocki  wrote:
>>
>> Subject ? ?: hugetlb oops on 3.1.0-rc8-devel
>> Submitter ?: Andy Lutomirski 
>> Date ? ? ? : 2011-11-01 22:20
>> Message-ID : CALCETrW1mpVCz2tO5roaz1r6vnno+srHR-dHA6_pkRi2qiCfdw at 
>> mail.gmail.com
>> References : http://marc.info/?l=linux-kernel&m=132018604426692&w=2
>
> Despite the subject line, that's not an oops, it's a BUG_ON().
>
> And it *should* be fixed by commit ea4039a34c4c ("hugetlb: release
> pages in the error path of hugetlb_cow()") although I don't think Andy
> ever confirmed that (since it was hard to trigger).

I haven't seen it again, but that probably doesn't mean anything.
I've also fixed a bug in some userspace software I was running, and
that fix means I'm probably not stressing that part of the kernel
anymore.  (Even without the fix, it took two weeks to hit this.)

3.2-rc2+: Reported regressions from 3.0 and 3.1

[Andy Lutomirski]

On Mon, Nov 21, 2011 at 2:11 PM, Linus Torvalds
 wrote:
> On Mon, Nov 21, 2011 at 1:49 PM, Rafael J. Wysocki  wrote:
>>
>> Subject ? ?: [3.1 REGRESSION] Commit 
>> 5cec93c216db77c45f7ce970d46283bcb1933884 breaks the Chromium seccomp sandbox
>> Submitter ?: Nix 
>> Date ? ? ? : 2011-11-14 0:40
>> Message-ID : 8762inleno.fsf at spindle.srvr.nix
>> References : http://marc.info/?l=linux-kernel&m=132123396226377&w=2
>
> So this should be fixed by commit 2b666859ec32 ("x86: Default to
> vsyscall=native for now"), since we disabled the vsyscall emulation
> because it broken UML too.

I don't think so.  I think the issue is that the chromium sandbox is
trying to use getcpu, time, or gettimeofday from seccomp mode and the
kernel is (IMO correctly) sending it SIGKILL.  Nix can trigger the bug
in vsyscall=native mode, so it's not the emulation.  (If it's
gettimeofday, then it's definitely not a regression.  vgettimeofday
would SIGKILL in seccomp mode with any timing source other than rdtsc
or hpet even on old kernels.)

I sent a patch to show which syscall is causing SIGKILL and haven't
heard back.  Meanwhile, I'm downloading the 1.1GB (!) tarball to see
if I can reproduce it here.  Fedora's build didn't trigger it for me,
probably because the sandbox was disabled.

To try to reduce the incidence of this stuff in the future, and to
make vsyscall=none and UML more useful, I filed this bug:

http://sourceware.org/bugzilla/show_bug.cgi?id=13425

--Andy

3.2-rc2+: Reported regressions from 3.0 and 3.1

[Andy Lutomirski]

On Mon, Nov 21, 2011 at 2:34 PM, Andy Lutomirski  wrote:
> On Mon, Nov 21, 2011 at 2:11 PM, Linus Torvalds
>  wrote:
>> On Mon, Nov 21, 2011 at 1:49 PM, Rafael J. Wysocki  wrote:
>>>
>>> Subject ? ?: [3.1 REGRESSION] Commit 
>>> 5cec93c216db77c45f7ce970d46283bcb1933884 breaks the Chromium seccomp sandbox
>>> Submitter ?: Nix 
>>> Date ? ? ? : 2011-11-14 0:40
>>> Message-ID : 8762inleno.fsf at spindle.srvr.nix
>>> References : http://marc.info/?l=linux-kernel&m=132123396226377&w=2
>>

This is apparently fixed in seccompsandbox.  See:

https://code.google.com/p/seccompsandbox/issues/detail?id=17
https://code.google.com/p/seccompsandbox/source/detail?r=178

Unless someone objects, I'll consider this to not be a kernel
regression worth fixing.

--Andy