1. 28 4月, 2011 5 次提交
    • J
      drm: Verify debug message arguments · bbb0aef5
      Joe Perches 提交于
      Add __attribute__((format (printf, 4, 5))) to drm_ut_debug_printk
      and fix fallout.
      Signed-off-by: NJoe Perches <joe@perches.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      bbb0aef5
    • J
      drm: Create and use drm_err · 5ad3d883
      Joe Perches 提交于
      Reduce drm text size ~1% by using drm_err and
      printf extension %pV to emit error messages.
      
      Remove unused macro DRM_MEM_ERROR.
      
      $ size drivers/gpu/drm/built-in.o*
         text	   data	    bss	    dec	    hex	filename
       361159	   9663	    256	 371078	  5a986	drivers/gpu/drm/built-in.o.new
       365416	   9663	    256	 375335	  5ba27	drivers/gpu/drm/built-in.o.old
      Signed-off-by: NJoe Perches <joe@perches.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      5ad3d883
    • C
      drm: Take lock around probes for drm_fb_helper_hotplug_event · 7394371d
      Chris Wilson 提交于
      We need to hold the dev->mode_config.mutex whilst detecting the output
      status. But we also need to drop it for the call into
      drm_fb_helper_single_fb_probe(), which indirectly acquires the lock when
      attaching the fbcon.
      
      Failure to do so exposes a race with normal output probing. Detected by
      adding some warnings that the mutex is held to the backend detect routines:
      
      [   17.772456] WARNING: at drivers/gpu/drm/i915/intel_crt.c:471 intel_crt_detect+0x3e/0x373 [i915]()
      [   17.772458] Hardware name: Latitude E6400
      [   17.772460] Modules linked in: ....
      [   17.772582] Pid: 11, comm: kworker/0:1 Tainted: G        W 2.6.38.4-custom.2 #8
      [   17.772584] Call Trace:
      [   17.772591]  [<ffffffff81046af5>] ? warn_slowpath_common+0x78/0x8c
      [   17.772603]  [<ffffffffa03f3e5c>] ? intel_crt_detect+0x3e/0x373 [i915]
      [   17.772612]  [<ffffffffa0355d49>] ?  drm_helper_probe_single_connector_modes+0xbf/0x2af [drm_kms_helper]
      [   17.772619]  [<ffffffffa03534d5>] ?  drm_fb_helper_probe_connector_modes+0x39/0x4d [drm_kms_helper]
      [   17.772625]  [<ffffffffa0354760>] ?  drm_fb_helper_hotplug_event+0xa5/0xc3 [drm_kms_helper]
      [   17.772633]  [<ffffffffa035577f>] ? output_poll_execute+0x146/0x17c [drm_kms_helper]
      [   17.772638]  [<ffffffff81193c01>] ? cfq_init_queue+0x247/0x345
      [   17.772644]  [<ffffffffa0355639>] ? output_poll_execute+0x0/0x17c [drm_kms_helper]
      [   17.772648]  [<ffffffff8105b540>] ? process_one_work+0x193/0x28e
      [   17.772652]  [<ffffffff8105c6bc>] ? worker_thread+0xef/0x172
      [   17.772655]  [<ffffffff8105c5cd>] ? worker_thread+0x0/0x172
      [   17.772658]  [<ffffffff8105c5cd>] ? worker_thread+0x0/0x172
      [   17.772663]  [<ffffffff8105f767>] ? kthread+0x7a/0x82
      [   17.772668]  [<ffffffff8100a724>] ? kernel_thread_helper+0x4/0x10
      [   17.772671]  [<ffffffff8105f6ed>] ? kthread+0x0/0x82
      [   17.772674]  [<ffffffff8100a720>] ? kernel_thread_helper+0x0/0x10
      Reported-by: NFrederik Himpe <fhimpe@telenet.be>
      References: https://bugs.freedesktop.org/show_bug.cgi?id=36394Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      7394371d
    • J
      drm: parse color format support for digital displays · da05a5a7
      Jesse Barnes 提交于
      EDID 1.4 digital displays report the color spaces they support in the
      features block.  Add support for grabbing this data and stuffing it into
      the display_info struct for driver use.
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      Reviewed-by: NAlex Deucher <alexdeucher@gmail.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      da05a5a7
    • J
      drm: add bit depth parsing · 3b11228b
      Jesse Barnes 提交于
      EDID 1.4 digital monitors report the bit depth supported in the input
      field.  Add support for parsing this out and storing the info in the
      display_info structure for use by drivers.
      
      [airlied: tweaked to fix inter-patch dependency]
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      Reviewed-by: NAdam Jackson <ajax@redhat.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      3b11228b
  2. 27 4月, 2011 2 次提交
  3. 26 4月, 2011 2 次提交
  4. 24 4月, 2011 3 次提交
    • T
      libata: Implement ATA_FLAG_NO_DIPM and apply it to mcp65 · ae01b249
      Tejun Heo 提交于
      NVIDIA mcp65 familiy of controllers cause command timeouts when DIPM
      is used.  Implement ATA_FLAG_NO_DIPM and apply it.
      
      This problem was reported by Stefan Bader in the following thread.
      
       http://thread.gmane.org/gmane.linux.ide/48841
      
      stable: applicable to 2.6.37 and 38.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Reported-by: NStefan Bader <stefan.bader@canonical.com>
      Cc: stable@kernel.org
      Signed-off-by: NJeff Garzik <jgarzik@pobox.com>
      ae01b249
    • T
      libata: Kill unused ATA_DFLAG_{H|D}IPM flags · 3f7ac1d6
      Tejun Heo 提交于
      ATA_DFLAG_{H|D}IPM flags are no longer used.  Kill them.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Signed-off-by: NJeff Garzik <jgarzik@pobox.com>
      3f7ac1d6
    • L
      vfs: get rid of insane dentry hashing rules · dea3667b
      Linus Torvalds 提交于
      The dentry hashing rules have been really quite complicated for a long
      while, in odd ways.  That made functions like __d_drop() very fragile
      and non-obvious.
      
      In particular, whether a dentry was hashed or not was indicated with an
      explicit DCACHE_UNHASHED bit.  That's despite the fact that the hash
      abstraction that the dentries use actually have a 'is this entry hashed
      or not' model (which is a simple test of the 'pprev' pointer).
      
      The reason that was done is because we used the normal 'is this entry
      unhashed' model to mark whether the dentry had _ever_ been hashed in the
      dentry hash tables, and that logic goes back many years (commit
      b3423415: "dcache: avoid RCU for never-hashed dentries").
      
      That, in turn, meant that __d_drop had totally different unhashing logic
      for the dentry hash table case and for the anonymous dcache case,
      because in order to use the "is this dentry hashed" logic as a flag for
      whether it had ever been on the RCU hash table, we had to unhash such a
      dentry differently so that we'd never think that it wasn't 'unhashed'
      and wouldn't be free'd correctly.
      
      That's just insane.  It made the logic really hard to follow, when there
      were two different kinds of "unhashed" states, and one of them (the one
      that used "list_bl_unhashed()") really had nothing at all to do with
      being unhashed per se, but with a very subtle lifetime rule instead.
      
      So turn all of it around, and make it logical.
      
      Instead of having a DENTRY_UNHASHED bit in d_flags to indicate whether
      the dentry is on the hash chains or not, use the hash chain unhashed
      logic for that.  Suddenly "d_unhashed()" just uses "list_bl_unhashed()",
      and everything makes sense.
      
      And for the lifetime rule, just use an explicit DENTRY_RCUACCEES bit.
      If we ever insert the dentry into the dentry hash table so that it is
      visible to RCU lookup, we mark it DENTRY_RCUACCESS to show that it now
      needs the RCU lifetime rules.  Now suddently that test at dentry free
      time makes sense too.
      
      And because unhashing now is sane and doesn't depend on where the dentry
      got unhashed from (because the dentry hash chain details doesn't have
      some subtle side effects), we can re-unify the __d_drop() logic and use
      common code for the unhashing.
      
      Also fix one more open-coded hash chain bit_spin_lock() that I missed in
      the previous chain locking cleanup commit.
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      dea3667b
  5. 23 4月, 2011 1 次提交
  6. 19 4月, 2011 3 次提交
    • J
      block: get rid of QUEUE_FLAG_REENTER · c21e6beb
      Jens Axboe 提交于
      We are currently using this flag to check whether it's safe
      to call into ->request_fn(). If it is set, we punt to kblockd.
      But we get a lot of false positives and excessive punts to
      kblockd, which hurts performance.
      
      The only real abuser of this infrastructure is SCSI. So export
      the async queue run and convert SCSI over to use that. There's
      room for improvement in that SCSI need not always use the async
      call, but this fixes our performance issue and they can fix that
      up in due time.
      Signed-off-by: NJens Axboe <jaxboe@fusionio.com>
      c21e6beb
    • L
      next_pidmap: fix overflow condition · c78193e9
      Linus Torvalds 提交于
      next_pidmap() just quietly accepted whatever 'last' pid that was passed
      in, which is not all that safe when one of the users is /proc.
      
      Admittedly the proc code should do some sanity checking on the range
      (and that will be the next commit), but that doesn't mean that the
      helper functions should just do that pidmap pointer arithmetic without
      checking the range of its arguments.
      
      So clamp 'last' to PID_MAX_LIMIT.  The fact that we then do "last+1"
      doesn't really matter, the for-loop does check against the end of the
      pidmap array properly (it's only the actual pointer arithmetic overflow
      case we need to worry about, and going one bit beyond isn't going to
      overflow).
      
      [ Use PID_MAX_LIMIT rather than pid_max as per Eric Biederman ]
      Reported-by: NTavis Ormandy <taviso@cmpxchg8b.com>
      Analyzed-by: NRobert Święcki <robert@swiecki.net>
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      Cc: Pavel Emelyanov <xemul@openvz.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c78193e9
    • J
      Input: estimate number of events per packet · 80b4895a
      Jeff Brown 提交于
      Calculate a default based on the number of ABS axes, REL axes,
      and MT slots for the device during input device registration.
      Signed-off-by: NJeff Brown <jeffbrown@android.com>
      Reviewed-by: NHenrik Rydberg <rydberg@euromail.se>
      Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
      80b4895a
  7. 18 4月, 2011 5 次提交
  8. 16 4月, 2011 4 次提交
  9. 15 4月, 2011 7 次提交
  10. 14 4月, 2011 1 次提交
  11. 13 4月, 2011 4 次提交
    • J
      Input: evdev - indicate buffer overrun with SYN_DROPPED · 9fb0f14e
      Jeff Brown 提交于
      Add a new EV_SYN code, SYN_DROPPED, to inform the client when input
      events have been dropped from the evdev input buffer due to a
      buffer overrun.  The client should use this event as a hint to
      reset its state or ignore all following events until the next
      packet begins.
      Signed-off-by: NJeff Brown <jeffbrown@android.com>
      [dtor@mail.ru: Implement Henrik's suggestion and drop old events in
       case of overflow.]
      Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
      9fb0f14e
    • J
      Input: add KEY_IMAGES specifically for AL Image Browser · ba6a078b
      Jarod Wilson 提交于
      Many media center remotes have buttons intended for jumping straight to
      one type of media browser or another -- commonly, images/photos/pictures,
      audio/music, television, and movies. At present, remotes with an images
      or photos or pictures button use any number of different keycodes which
      sort of maybe fit. I've seen at least KEY_MEDIA, KEY_CAMERA,
      KEY_GRAPHICSEDITOR and KEY_PRESENTATION. None of those seem quite right.
      In my mind, KEY_MEDIA should be something more like a media center
      application launcher (and I'd like to standardize on that for things
      like the windows media center button on the mce remotes). KEY_CAMERA is
      used in a lot of webcams, and typically means "take a picture now".
      KEY_GRAPHICSEDITOR implies an editor, not a browser. KEY_PRESENTATION
      might be the closest fit here, if you think "photo slide show", but it
      may well be more intended for "run application in full-screen
      presentation mode" or to launch something like magicpoint, I dunno.
      And thus, I'd like to have a KEY_IMAGES, which matches the HID Usage AL
      Image Browser, the meaning of which I think is crystal-clear. I believe
      AL Audio Browser is already covered by KEY_AUDIO, and AL Movie Browser
      by KEY_VIDEO, so I'm also adding appropriate comments next to those
      keys.
      Signed-off-by: NJarod Wilson <jarod@redhat.com>
      Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
      ba6a078b
    • L
      vfs: Re-introduce s_uuid in the superblock · 0bba0169
      Linus Torvalds 提交于
      Gaah.  When commit be85bcca reverted the export of file system uuid
      via /proc/<pid>/mountinfo, it also unintentionally removed the s_uuid
      field in struct super_block.
      
      I didn't mean to do that, since filesystems have been taught to fill it
      in (and we want to keep it for future re-introduction in the mountinfo
      file).
      
      Stupid of me. This adds it back in.
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      0bba0169
    • L
      Revert "vfs: Export file system uuid via /proc/<pid>/mountinfo" · be85bcca
      Linus Torvalds 提交于
      This reverts commit 93f1c20b.
      
      It turns out that libmount misparses it because it adds a '-' character
      in the uuid string, which libmount then incorrectly confuses with the
      separator string (" - ") at the end of all the optional arguments.
      
      Upstream libmount (in the util-linux tree) has been fixed, but until
      that fix actually percolates up to users, we'd better not expose this
      change in the kernel.
      
      Let's revisit this later (possibly by exposing the UUID without any '-'
      characters in it, avoiding the user-space bug).
      Reported-by: NDave Jones <davej@redhat.com>
      Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Karel Zak <kzak@redhat.com>
      Cc: Ram Pai <linuxram@us.ibm.com>
      Cc: Miklos Szeredi <mszeredi@suse.cz>
      Cc: Eric Sandeen <sandeen@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      be85bcca
  12. 12 4月, 2011 3 次提交