1. 20 Jan, 2013 6 commits
    • Daniel Vetter's avatar
      drm/nouveau: protect evo_wait/evo_kick sections with a channel mutex · 59ad1465
      Daniel Vetter authored
      With per-crtc locks modeset operations can run in parallel, and the
      cursor code uses the device-global evo master channel for hw frobbing.
      But the pageflip code can also sync with the master under some
      circumstances. Hence just wrap things up in a mutex to ensure that
      pushbuf access doesn't intermingle.
      
      The approach here is a bit overkill since the per-crtc channels used
      to schedule the pageflips could probably be used without this pushbuf
      locking, but I'm not familiar enough with the nouveau codebase to be
      sure of that.
      
      v2: Add missing mutex_init to avoid angering lockdep.
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      59ad1465
    • Daniel Vetter's avatar
      drm/gma500: move fbcon restore to lastclose · 7147573a
      Daniel Vetter authored
      Doing this within the fb->destroy callback leads to a locking
      nightmare. And all other drm drivers that restore the fbcon do
      it in lastclose, too.
      
      With this adjustments all fb->destroy callbacks optionally drop
      references to any gem objects used as backing storage, call
      drm_framebuffer_cleanup and then kfree the struct. Which nicely
      simplifies the locking for framebuffer unreferencing and freeing,
      since this doesn't require that we hold the mode_config lock. A
      slight exception is the vmwgfx surface backed framebuffer, it also
      calls drm_master_put and removes the object from a device-private
      framebuffer list. Both seem to have solid locking in place already.
      
      Conclusion is that now it is no longer required to hold the
      mode_config lock while freeing a framebuffer.
      
      v2: Drop the corresponding mutex_lock WARN check from
      drm_framebuffer_unreference.
      
      v3: Use just the mode_config lock not modeset_lock_all, due to patch
      reordering.
      Acked-by: default avatarAlan Cox <alan@lxorguk.ukuu.org.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      7147573a
    • Daniel Vetter's avatar
      drm/vmwgfx: reorder framebuffer init sequence · 80f0b5af
      Daniel Vetter authored
      vmwgfx has an oddity, when failing to reference the surface it'll
      return 0, since that's what the successfull drm_framebuffer_init will
      leave behind in ret. Fix this up by returning -EINVAL.
      
      Split out from all the other driver updates due to the above tiny
      semantic change. Shouldn't matter though since the reference grabbing
      seemingly can't fail.
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      80f0b5af
    • Daniel Vetter's avatar
      drm/<drivers>: reorder framebuffer init sequence · c7d73f6a
      Daniel Vetter authored
      With more fine-grained locking we can no longer rely on the big
      mode_config lock to prevent concurrent access to mode resources
      like framebuffers. Instead a framebuffer becomes accessible to
      other threads as soon as it is added to the relevant lookup
      structures. Hence it needs to be fully set up by the time drivers
      call drm_framebuffer_init.
      
      This patch here is the drivers part of that reorg. Nothing really fancy
      going on safe for three special cases.
      
      - exynos needs to be careful to properly unref all handles.
      - nouveau gets a resource leak fixed for free: one of the error
        cases didn't cleanup the framebuffer, which is now moot since
        the framebuffer is only registered once it is fully set up.
      - vmwgfx requires a slight reordering of operations, I'm hoping I didn't
        break anything (but it's refcount management only, so should be safe).
      
      v2: Split out exynos, since it's a bit more hairy than expected.
      
      v3: Drop bogus cirrus hunk noticed by Richard Wilbur.
      
      v4: Split out vmwgfx since there's a small change in return values.
      
      Reviewed-by: Rob Clark <rob@ti.com> (core + omapdrm)
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      c7d73f6a
    • Daniel Vetter's avatar
      drm/doc: integrate drm_crtc.c kerneldoc · 065a50ed
      Daniel Vetter authored
      And do a quick pass to adjust them to the last few (years?) of changes
      ...
      
      This time actually compile-tested ;-)
      Reviewed-by: default avatarRob Clark <rob@ti.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      065a50ed
    • Daniel Vetter's avatar
      drm: review locking rules in drm_crtc.c · 8faf6b18
      Daniel Vetter authored
      - config_cleanup was confused: It claimed that callers need to hold
        the modeset lock, but the connector|encoder_cleanup helpers grabbed
        that themselves (note that crtc_cleanup did _not_ grab the modeset
        lock). Which resulted in all drivers _not_ hodling the lock. Since
        this is for single-threaded cleanup code, drop the requirement from
        docs and also drop the lock_grabbing from all _cleanup functions.
      
      - Kill the LOCKING section in the doctype, since clearly we're not
        good enough to keep them up-to-date. And misleading locking
        documentation is worse than useless (see e.g. the comment in the
        vmgfx driver about the cleanup mess). And since for most functions
        the very first line either grabs the lock or has a WARN_ON(!locked)
        the documentation doesn't really add anything.
      
      - Instead put in some effort into explaining the only two special
        cases a bit better: config_init and config_cleanup are both called
        from single-threaded setup/teardown code, so don't do any locking.
        It's the driver's job though to enforce this.
      
      - Where lacking, add a WARN_ON(!is_locked). Not many places though,
        since locking around fbdev setup/teardown is through-roughly screwed
        up, and so will break almost every single WARN annotation I've tried
        to add.
      
      - Add a drm_modeset_is_locked helper - the Grate Modset Locking Rework
        will use the compiler to assist in the big reorg by renaming the
        mode lock, so start encapsulating things. Unfortunately this ended
        up in the "wrong" header file since it needs the definition of
        struct drm_device.
      
      v2: Drop most WARNS again - we hit them all over the place, mostly in
      the setup and teardown sequences. And trying to fix it up leads to
      nice deadlocks, since the locking in the setup code is really
      inconsistent.
      Reviewed-by: default avatarRob Clark <rob@ti.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      8faf6b18
  2. 18 Jan, 2013 1 commit
  3. 17 Jan, 2013 2 commits
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux · 72ffaa48
      Linus Torvalds authored
      Pull more s390 patches from Martin Schwidefsky:
       "A couple of bug fixes: one of the transparent huge page primitives is
        broken, the sched_clock function overflows after 417 days, the XFS
        module has grown too large for -fpic and the new pci code has broken
        normal channel subsystem notifications."
      
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
        s390/chsc: fix SEI usage
        s390/time: fix sched_clock() overflow
        s390: use -fPIC for module compile
        s390/mm: fix pmd_pfn() for thp
      72ffaa48
    • Linus Torvalds's avatar
      Merge tag 'for-linus-v3.8-rc4' of git://oss.sgi.com/xfs/xfs · dfdebc24
      Linus Torvalds authored
      Pull xfs bugfixes from Ben Myers:
      
       - fix(es) for compound buffers
      
       - fix for dquot soft timer asserts due to overflow of d_blk_softlimit
      
       - fix for regression in dir v2 code introduced in commit 20f7e9f3
         ("xfs: factor dir2 block read operations")
      
      * tag 'for-linus-v3.8-rc4' of git://oss.sgi.com/xfs/xfs:
        xfs: recalculate leaf entry pointer after compacting a dir2 block
        xfs: remove int casts from debug dquot soft limit timer asserts
        xfs: fix the multi-segment log buffer format
        xfs: fix segment in xfs_buf_item_format_segment
        xfs: rename bli_format to avoid confusion with bli_formats
        xfs: use b_maps[] for discontiguous buffers
      dfdebc24
  4. 16 Jan, 2013 24 commits
  5. 15 Jan, 2013 7 commits
    • Will Deacon's avatar
      arm64: compat: add syscall table entries for new syscalls · 72d0ac04
      Will Deacon authored
      There have been a number of new syscalls introduced to arch/arm/ since
      the compat layer was implemented for arm64, so add pointers to the
      relevant functions to the compat syscall table.
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      72d0ac04
    • Takashi Iwai's avatar
      ALSA: hda/hdmi - Work around "alsactl restore" errors · 6f54c361
      Takashi Iwai authored
      When "alsactl restore" is performed on HDMI codecs, it tries to
      restore the channel map value since the channel map controls are
      writable.  But hdmi_chmap_ctl_put() returns -EBADFD when no PCM stream
      is assigned yet, and this results in an error message from alsactl.
      Although the error is harmless, it's certainly ugly and can be
      regarded as a regression.
      
      As a workaround, this patch changes the return code in such a case to
      be zero for making others happy.  (A slight excuse is: when the chmap
      is changed through the proper alsa-lib API, the PCM status is checked
      there anyway, so we don't have to be too strict in the kernel side.)
      
      Cc: <stable@vger.kernel.org> [v3.7+]
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      6f54c361
    • Daniel Lezcano's avatar
      cpuidle: remove the power_specified field in the driver · 8aef33a7
      Daniel Lezcano authored
      We realized that the power usage field is never filled and when it
      is filled for tegra, the power_specified flag is not set causing all
      of these values to be reset when the driver is initialized with
      set_power_state().
      
      However, the power_specified flag can be simply removed under the
      assumption that the states are always backward sorted, which is the
      case with the current code.
      
      This change allows the menu governor select function and the
      cpuidle_play_dead() to be simplified.  Moreover, the
      set_power_states() function can removed as it does not make sense
      any more.
      
      Drop the power_specified flag from struct cpuidle_driver and make
      the related changes as described above.
      
      As a consequence, this also fixes the bug where on the dynamic
      C-states system, the power fields are not initialized.
      
      [rjw: Changelog]
      References: https://bugzilla.kernel.org/show_bug.cgi?id=42870
      References: https://bugzilla.kernel.org/show_bug.cgi?id=43349
      References: https://lkml.org/lkml/2012/10/16/518Signed-off-by: default avatarDaniel Lezcano <daniel.lezcano@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      8aef33a7
    • Takashi Iwai's avatar
      Merge tag 'asoc-atmel-pinctrl' of... · 2e4c4dbe
      Takashi Iwai authored
      Merge tag 'asoc-atmel-pinctrl' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
      
      ASoC: atmel: Fixes for pinctrl
      
      Due to a series of problems with the handling of Atmel, a combination of
      making changes that make other branches instantly buggy and a general
      failure to deal with the resulting issues effectively, v3.8 Atmel audio
      currently won't work at all for DT boards without adding pinctrl
      definitions and a request for those.
      2e4c4dbe
    • Linus Torvalds's avatar
      Merge tag 'trace-3.8-rc3-regression-fix' of... · 406089d0
      Linus Torvalds authored
      Merge tag 'trace-3.8-rc3-regression-fix' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
      
      Pull tracing regression fixes from Steven Rostedt:
       "The clean up patch commit 0fb9656d "tracing: Make tracing_enabled
        be equal to tracing_on" caused two regressions.
      
         1) The irqs off latency tracer no longer starts if tracing_on is off
            when the tracer is set, and then tracing_on is enabled.  The
            tracing_on file needs the hook that tracing_enabled had to enable
            tracers if they request it (call the tracer's start() method).
      
         2) That commit had a separate change that really should have been a
            separate patch, but it must have been added accidently with the -a
            option of git commit.  But as the change is still related to the
            commit it wasn't noticed in review.  That change, changed the way
            blocking is done by the trace_pipe file with respect to the
            tracing_on settings.  I've been told that this change breaks
            current userspace, and this specific change is being reverted."
      
      * tag 'trace-3.8-rc3-regression-fix' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
        tracing: Fix regression of trace_pipe
        tracing: Fix regression with irqsoff tracer and tracing_on file
      406089d0
    • Linus Torvalds's avatar
      Merge tag 'regmap-debugfs-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap · 7dea1ff3
      Linus Torvalds authored
      Pull regmap debugfs optimisation fixes from Mark Brown:
       "The debugfs optimisations merged in v3.8 weren't my finest hour, there
        were a number of cases that the more complex algorithm made worse
        especially around the error handling.  This patch series should
        address those issues."
      
      * tag 'regmap-debugfs-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap:
        regmap: debugfs: Make sure we store the last entry in the offset cache
        regmap: debugfs: Ensure a correct return value for empty caches
        regmap: debugfs: Discard the cache if we fail to allocate an entry
        regmap: debugfs: Fix check for block start in cached seeks
        regmap: debugfs: Fix attempts to read nonexistant register blocks
      7dea1ff3
    • Linus Torvalds's avatar
      Merge tag 'regulator-3.8-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator · 2ac1e664
      Linus Torvalds authored
      Pull regulator fixes from Mark Brown:
       "A few fixes for the regulator subsystems, a few driver specific things
        plus a fix for the interaction between regultor_can_change_voltage()
        and continuous voltage ranges both of which were added for this
        release."
      
      * tag 'regulator-3.8-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
        regulator: max8998: Ensure enough delay time for max8998_set_voltage_buck_time_sel
        regulator: max8998: Use uV in voltage_map_desc
        regulator: max8997: Use uV in voltage_map_desc
        regulator: core: Fix comment for regulator_register()
        regulator: core: Fix continuous_voltage_range case in regulator_can_change_voltage
        regulator: s5m8767: Fix probe failure due to stack corruption
      2ac1e664