1. 05 May, 2015 2 commits
  2. 04 May, 2015 5 commits
    • Daniel Vetter's avatar
      drm/atomic-helper: Really recover pre-atomic plane/cursor behavior · 3671c580
      Daniel Vetter authored
      I've fumbled this in
      
      commit f02ad907
      Author: Daniel Vetter <daniel.vetter@ffwll.ch>
      Date:   Thu Jan 22 16:36:23 2015 +0100
      
          drm/atomic-helpers: Recover full cursor plane behaviour
      
      and accidentally put the assignment for legacy_cursor_upate after the
      atomic commit, where it is pretty useless.
      Reported-by: default avatarMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
      3671c580
    • Mario Kleiner's avatar
      drm/qxl: Fix qxl_noop_get_vblank_counter() · 337eb43c
      Mario Kleiner authored
      This breaks under the vblank timestamp cleanup patch
      by Daniel Vetter. Also it is pointless to return anything
      but zero (or any other constant) if the function doesn't
      actually query a hw vblank counter. The bogus return of
      the current drm vblank counter via direct readout or via
      drm_vblank_count() is found in many of the new kms drivers,
      but it does exactly nothing different from returning any
      arbitrary constant - it's a no operation.
      
      Let's simply return 0 - Easy and fast.
      Signed-off-by: default avatarMario Kleiner <mario.kleiner.de@gmail.com>
      Cc: Dave Airlie <airlied@redhat.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      337eb43c
    • Mario Kleiner's avatar
      drm: Zero out invalid vblank timestamp in drm_update_vblank_count. (v2) · d66a1e38
      Mario Kleiner authored
      Since commit 844b03f2 we make
      sure that after vblank irq off, we return the last valid
      (vblank count, vblank timestamp) pair to clients, e.g., during
      modesets, which is good.
      
      An overlooked side effect of that commit for kms drivers without
      support for precise vblank timestamping is that at vblank irq
      enable, when we update the vblank counter from the hw counter, we
      can't update the corresponding vblank timestamp, so now we have a
      totally mismatched timestamp for the new count to confuse clients.
      
      Restore old client visible behaviour from before Linux 3.18, but
      zero out the timestamp at vblank counter update (instead of disable
      as in original implementation) if we can't generate a meaningful
      timestamp immediately for the new vblank counter. This will fix
      this regression, so callers know they need to retry again later
      if they need a valid timestamp, but at the same time preserves
      the improvements made in the commit mentioned above.
      
      v2: Rebased on top of Daniel Vetter's fixup and documentation
          patch for timestamp updates. Drop request for stable kernel
          backport as this would be more difficult, unless the original
          patch would get applied to stable kernels.
      Signed-off-by: default avatarMario Kleiner <mario.kleiner.de@gmail.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Daniel Vetter <daniel@ffwll.ch>
      Cc: Dave Airlie <airlied@redhat.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      d66a1e38
    • Mario Kleiner's avatar
      drm: Prevent invalid use of vblank_disable_immediate. (v2) · 5a8b21b2
      Mario Kleiner authored
      For a kms driver to support immediate disable of vblank
      irq's reliably without introducing off by one errors or
      other mayhem for clients, it must not only support a
      hardware vblank counter query, but also high precision
      vblank timestamping, so vblank count and timestamp can be
      instantaneously reinitialzed to valid values. Additionally
      the exposed hardware counter must behave as if it is
      incrementing at leading edge of vblank to avoid off by
      one errors during reinitialization of the counter while
      the display happens to be inside or close to vblank.
      
      Check during drm_vblank_init that a driver which claims to
      be capable of vblank_disable_immediate at least supports
      high precision timestamping and prevent use of instant
      disable if that isn't present as a minimum requirement.
      
      v2: Changed from DRM_ERROR to DRM_INFO and made message
          more clear, as suggested by Michel Dänzer.
      Signed-off-by: default avatarMario Kleiner <mario.kleiner.de@gmail.com>
      Reviewed-by: default avatarMichel Dänzer <michel.daenzer@amd.com>
      Cc: Dave Airlie <airlied@redhat.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      5a8b21b2
    • Daniel Vetter's avatar
      drm/vblank: Fixup and document timestamp update/read barriers · 99264a61
      Daniel Vetter authored
      This was a bit too much cargo-culted, so lets make it solid:
      - vblank->count doesn't need to be an atomic, writes are always done
        under the protection of dev->vblank_time_lock. Switch to an unsigned
        long instead and update comments. Note that atomic_read is just a
        normal read of a volatile variable, so no need to audit all the
        read-side access specifically.
      
      - The barriers for the vblank counter seqlock weren't complete: The
        read-side was missing the first barrier between the counter read and
        the timestamp read, it only had a barrier between the ts and the
        counter read. We need both.
      
      - Barriers weren't properly documented. Since barriers only work if
        you have them on boths sides of the transaction it's prudent to
        reference where the other side is. To avoid duplicating the
        write-side comment 3 times extract a little store_vblank() helper.
        In that helper also assert that we do indeed hold
        dev->vblank_time_lock, since in some cases the lock is acquired a
        few functions up in the callchain.
      
      Spotted while reviewing a patch from Chris Wilson to add a fastpath to
      the vblank_wait ioctl.
      
      v2: Add comment to better explain how store_vblank works, suggested by
      Chris.
      
      v3: Peter noticed that as-is the 2nd smp_wmb is redundant with the
      implicit barrier in the spin_unlock. But that can only be proven by
      auditing all callers and my point in extracting this little helper was
      to localize all the locking into just one place. Hence I think that
      additional optimization is too risky.
      
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Mario Kleiner <mario.kleiner.de@gmail.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Michel Dänzer <michel@daenzer.net>
      Cc: Peter Hurley <peter@hurleysoftware.com>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-and-tested-by: default avatarMario Kleiner <mario.kleiner.de@gmail.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
      99264a61
  3. 20 Apr, 2015 2 commits
    • Josef Holzmayr's avatar
      DRM: Don't re-poll connector for disconnect · a3c6d686
      Josef Holzmayr authored
      DRM probe should not repoll a connector if it is already
      connected and the DRM_CONNECTOR_POLL_DISCONNECT flag is not set.
      Signed-off-by: default avatarJosef Holzmayr <holzmayr@rsi-elektrotechnik.de>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      a3c6d686
    • Todd Previte's avatar
      drm: Fix for DP CTS test 4.2.2.5 - I2C DEFER handling · 396aa445
      Todd Previte authored
      For test 4.2.2.5 to pass per the Link CTS Core 1.2 rev1.1 spec, the source
      device must attempt at least 7 times to read the EDID when it receives an
      I2C defer. The normal DRM code makes only 7 retries, regardless of whether
      or not the response is a native defer or an I2C defer. Test 4.2.2.5 fails
      since there are native defers interspersed with the I2C defers which
      results in less than 7 EDID read attempts.
      
      The solution is to add the numer of defers to the retry counter when an I2C
      DEFER is returned such that another read attempt will be made. This situation
      should normally only occur in compliance testing, however, as a worse case
      real-world scenario, it would result in 13 attempts ( 6 native defers, 7 I2C
      defers) for a single transaction to complete. The net result is a slightly
      slower response to an EDID read that shouldn't significantly impact overall
      performance.
      
      V2:
      - Added a check on the number of I2C Defers to limit the number
        of times that the retries variable will be decremented. This
        is to address review feedback regarding possible infinite loops
        from misbehaving sink devices.
      V3:
      - Fixed the limit value to 7 instead of 8 to get the correct retry
        count.
      - Combined the increment of the defer count into the if-statement
      V4:
      - Removed i915 tag from subject as the patch is not i915-specific
      V5:
      - Updated the for-loop to add the number of i2c defers to the retry
        counter such that the correct number of retry attempts will be
        made
      Signed-off-by: default avatarTodd Previte <tprevite@gmail.com>
      Cc: dri-devel@lists.freedesktop.org
      Reviewed-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      396aa445
  4. 16 Apr, 2015 2 commits
  5. 14 Apr, 2015 2 commits
    • John Hunter's avatar
      drm: fix trivial typo mistake · 2b1193d5
      John Hunter authored
      Signed-off-by: default avatarJohn Hunter <zhjwpku@gmail.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      2b1193d5
    • Matt Roper's avatar
      drm: Make integer overflow checking cover universal cursor updates (v2) · 3968be94
      Matt Roper authored
      Our legacy SetPlane updates perform integer overflow checking on a
      plane's destination rectangle in drm_mode_setplane(), and atomic updates
      handled as part of a drm_atomic_state transaction do the same checking
      in drm_atomic_plane_check().  However legacy cursor updates that get
      routed through universal plane interfaces may bypass this overflow
      checking if the driver's .update_plane is serviced by the transitional
      plane helpers rather than the full atomic plane helpers.
      
      Move the check for destination rectangle integer overflow from the
      drm_mode_setplane() to __setplane_internal() so that it also covers
      cursor operations.
      
      This fixes an issue first noticed with i915 commit:
      
              commit ff42e093
              Author: Daniel Vetter <daniel.vetter@ffwll.ch>
              Date:   Mon Mar 2 16:35:20 2015 +0100
      
                  Revert "drm/i915: Switch planes from transitional helpers to full
                  atomic helpers"
      
      The above revert switched us from full atomic helpers back to the
      transitional helpers, and in doing so we lost the overflow checking here
      for universal cursor updates.  Even though such extreme cursor positions
      are unlikely to actually happen in the wild, we still don't want there
      to be a change of behavior when drivers switch from transitional helpers
      to full helpers.
      
      v2: Move check from setplane ioctl to setplane_internal rather than
          adding an additional copy of the checks to the transitional plane
          helpers.  (Daniel)
      
      Cc: Daniel Vetter <daniel@ffwll.ch>
      Testcase: igt/kms_cursor_crc
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84269Signed-off-by: default avatarMatt Roper <matthew.d.roper@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      3968be94
  6. 13 Apr, 2015 4 commits
  7. 11 Apr, 2015 1 commit
  8. 07 Apr, 2015 9 commits
  9. 01 Apr, 2015 1 commit
  10. 31 Mar, 2015 6 commits
  11. 30 Mar, 2015 3 commits
  12. 29 Mar, 2015 3 commits
    • Linus Torvalds's avatar
      Linux 4.0-rc6 · e42391cd
      Linus Torvalds authored
      e42391cd
    • Linus Torvalds's avatar
      Merge tag 'armsoc-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc · 08f41f7c
      Linus Torvalds authored
      Pull ARM SoC fixes from Olof Johansson:
       "The latest and greatest fixes for ARM platform code.  Worth pointing
        out are:
      
         - Lines-wise, largest is a PXA fix for dealing with interrupts on DT
           that was quite broken.  It's still newish code so while we could
           have held this off, it seemed appropriate to include now
      
         - Some GPIO fixes for OMAP platforms added a few lines.  This was
           also fixes for code recently added (this release).
      
         - Small OMAP timer fix to behave better with partially upstreamed
           platforms, which is quite welcome.
      
         - Allwinner fixes about operating point control, reducing
           overclocking in some cases for better stability.
      
        plus a handful of other smaller fixes across the map"
      
      * tag 'armsoc-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
        arm64: juno: Fix misleading name of UART reference clock
        ARM: dts: sunxi: Remove overclocked/overvoltaged OPP
        ARM: dts: sun4i: a10-lime: Override and remove 1008MHz OPP setting
        ARM: socfpga: dts: fix spi1 interrupt
        ARM: dts: Fix gpio interrupts for dm816x
        ARM: dts: dra7: remove ti,hwmod property from pcie phy
        ARM: OMAP: dmtimer: disable pm runtime on remove
        ARM: OMAP: dmtimer: check for pm_runtime_get_sync() failure
        ARM: OMAP2+: Fix socbus family info for AM33xx devices
        ARM: dts: omap3: Add missing dmas for crypto
        ARM: dts: rockchip: disable gmac by default in rk3288.dtsi
        MAINTAINERS: add rockchip regexp to the ARM/Rockchip entry
        ARM: pxa: fix pxa interrupts handling in DT
        ARM: pxa: Fix typo in zeus.c
        ARM: sunxi: Have ARCH_SUNXI select RESET_CONTROLLER for clock driver usage
      08f41f7c
    • Olof Johansson's avatar
      Merge tag 'sunxi-fixes-for-4.0' of... · 4550bdb0
      Olof Johansson authored
      Merge tag 'sunxi-fixes-for-4.0' of https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux into fixes
      
      Allwinner fixes for 4.0
      
      There's a few fixes to merge for 4.0, one to add a select in the machine
      Kconfig option to fix a potential build failure, and two fixing cpufreq related
      issues.
      
      * tag 'sunxi-fixes-for-4.0' of https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux:
        ARM: dts: sunxi: Remove overclocked/overvoltaged OPP
        ARM: dts: sun4i: a10-lime: Override and remove 1008MHz OPP setting
        ARM: sunxi: Have ARCH_SUNXI select RESET_CONTROLLER for clock driver usage
      Signed-off-by: default avatarOlof Johansson <olof@lixom.net>
      4550bdb0