16 Dec, 2014

1 commit

  • Pull drm updates from Dave Airlie:
    "Highlights:

    - AMD KFD driver merge

    This is the AMD HSA interface for exposing a lowlevel interface for
    GPGPU use. They have an open source userspace built on top of this
    interface, and the code looks as good as it was going to get out of
    tree.

    - Initial atomic modesetting work

    The need for an atomic modesetting interface to allow userspace to
    try and send a complete set of modesetting state to the driver has
    arisen, and been suffering from neglect this past year. No more,
    the start of the common code and changes for msm driver to use it
    are in this tree. Ongoing work to get the userspace ioctl finished
    and the code clean will probably wait until next kernel.

    - DisplayID 1.3 and tiled monitor exposed to userspace.

    Tiled monitor property is now exposed for userspace to make use of.

    - Rockchip drm driver merged.

    - imx gpu driver moved out of staging

    Other stuff:

    - core:
    panel - MIPI DSI + new panels.
    expose suggested x/y properties for virtual GPUs

    - i915:
    Initial Skylake (SKL) support
    gen3/4 reset work
    start of dri1/ums removal
    infoframe tracking
    fixes for lots of things.

    - nouveau:
    tegra k1 voltage support
    GM204 modesetting support
    GT21x memory reclocking work

    - radeon:
    CI dpm fixes
    GPUVM improvements
    Initial DPM fan control

    - rcar-du:
    HDMI support added
    removed some support for old boards
    slave encoder driver for Analog Devices adv7511

    - exynos:
    Exynos4415 SoC support

    - msm:
    a4xx gpu support
    atomic helper conversion

    - tegra:
    iommu support
    universal plane support
    ganged-mode DSI support

    - sti:
    HDMI i2c improvements

    - vmwgfx:
    some late fixes.

    - qxl:
    use suggested x/y properties"

    * 'drm-next' of git://people.freedesktop.org/~airlied/linux: (969 commits)
    drm: sti: fix module compilation issue
    drm/i915: save/restore GMBUS freq across suspend/resume on gen4
    drm: sti: correctly cleanup CRTC and planes
    drm: sti: add HQVDP plane
    drm: sti: add cursor plane
    drm: sti: enable auxiliary CRTC
    drm: sti: fix delay in VTG programming
    drm: sti: prepare sti_tvout to support auxiliary crtc
    drm: sti: use drm_crtc_vblank_{on/off} instead of drm_vblank_{on/off}
    drm: sti: fix hdmi avi infoframe
    drm: sti: remove event lock while disabling vblank
    drm: sti: simplify gdp code
    drm: sti: clear all mixer control
    drm: sti: remove gpio for HDMI hot plug detection
    drm: sti: allow to change hdmi ddc i2c adapter
    drm/doc: Document drm_add_modes_noedid() usage
    drm/i915: Remove '& 0xffff' from the mask given to WA_REG()
    drm/i915: Invert the mask and val arguments in wa_add() and WA_REG()
    drm: Zero out DRM object memory upon cleanup
    drm/i915/bdw: Fix the write setting up the WIZ hashing mode
    ...

    Linus Torvalds
     

05 Dec, 2014

1 commit

  • We've lost the +1 required for correct timeouts in

    commit 5ed0bdf21a85d78e04f89f15ccf227562177cbd9
    Author: Thomas Gleixner
    Date: Wed Jul 16 21:05:06 2014 +0000

    drm: i915: Use nsec based interfaces

    Use ktime_get_raw_ns() and get rid of the back and forth timespec
    conversions.

    Signed-off-by: Thomas Gleixner
    Acked-by: Daniel Vetter
    Signed-off-by: John Stultz

    So fix this up by reinstating our handrolled _timeout function. While
    at it bother with handling MAX_JIFFIES.

    v2: Convert to usecs (we don't care about the accuracy anyway) first
    to avoid overflow issues Dave Gordon spotted.

    v3: Drop the explicit MAX_JIFFY_OFFSET check, usecs_to_jiffies should
    take care of that already. It might be a bit too enthusiastic about it
    though.

    v4: Chris has a much nicer color, so use his implementation.

    This requires to export nsec_to_jiffies from time.c.

    Cc: Chris Wilson
    Cc: Dave Gordon
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82749
    Cc: Thomas Gleixner
    Cc: John Stultz
    Signed-off-by: Daniel Vetter
    Acked-by: John Stultz
    Signed-off-by: Jani Nikula

    Daniel Vetter
     

22 Nov, 2014

1 commit

  • As part of addressing "y2038 problem" for in-kernel uses, this
    patch adds safe mktime64() using time64_t.

    After this patch, mktime() is deprecated and all its call sites
    will be fixed using mktime64(), after that it can be removed.

    Signed-off-by: pang.xunlei
    Signed-off-by: John Stultz

    pang.xunlei
     

13 Sep, 2014

1 commit

  • timeval_to_jiffies tried to round a timeval up to an integral number
    of jiffies, but the logic for doing so was incorrect: intervals
    corresponding to exactly N jiffies would become N+1. This manifested
    itself particularly repeatedly stopping/starting an itimer:

    setitimer(ITIMER_PROF, &val, NULL);
    setitimer(ITIMER_PROF, NULL, &val);

    would add a full tick to val, _even if it was exactly representable in
    terms of jiffies_ (say, the result of a previous rounding.) Doing
    this repeatedly would cause unbounded growth in val. So fix the math.

    Here's what was wrong with the conversion: we essentially computed
    (eliding seconds)

    jiffies = usec * (NSEC_PER_USEC/TICK_NSEC)

    by using scaling arithmetic, which took the best approximation of
    NSEC_PER_USEC/TICK_NSEC with denominator of 2^USEC_JIFFIE_SC =
    x/(2^USEC_JIFFIE_SC), and computed:

    jiffies = (usec * x) >> USEC_JIFFIE_SC

    and rounded this calculation up in the intermediate form (since we
    can't necessarily exactly represent TICK_NSEC in usec.) But the
    scaling arithmetic is a (very slight) *over*approximation of the true
    value; that is, instead of dividing by (1 usec/ 1 jiffie), we
    effectively divided by (1 usec/1 jiffie)-epsilon (rounding
    down). This would normally be fine, but we want to round timeouts up,
    and we did so by adding 2^USEC_JIFFIE_SC - 1 before the shift; this
    would be fine if our division was exact, but dividing this by the
    slightly smaller factor was equivalent to adding just _over_ 1 to the
    final result (instead of just _under_ 1, as desired.)

    In particular, with HZ=1000, we consistently computed that 10000 usec
    was 11 jiffies; the same was true for any exact multiple of
    TICK_NSEC.

    We could possibly still round in the intermediate form, adding
    something less than 2^USEC_JIFFIE_SC - 1, but easier still is to
    convert usec->nsec, round in nanoseconds, and then convert using
    time*spec*_to_jiffies. This adds one constant multiplication, and is
    not observably slower in microbenchmarks on recent x86 hardware.

    Tested: the following program:

    int main() {
    struct itimerval zero = {{0, 0}, {0, 0}};
    /* Initially set to 10 ms. */
    struct itimerval initial = zero;
    initial.it_interval.tv_usec = 10000;
    setitimer(ITIMER_PROF, &initial, NULL);
    /* Save and restore several times. */
    for (size_t i = 0; i < 10; ++i) {
    struct itimerval prev;
    setitimer(ITIMER_PROF, &zero, &prev);
    /* on old kernels, this goes up by TICK_USEC every iteration */
    printf("previous value: %ld %ld %ld %ld\n",
    prev.it_interval.tv_sec, prev.it_interval.tv_usec,
    prev.it_value.tv_sec, prev.it_value.tv_usec);
    setitimer(ITIMER_PROF, &prev, NULL);
    }
    return 0;
    }

    Cc: stable@vger.kernel.org
    Cc: Thomas Gleixner
    Cc: Ingo Molnar
    Cc: Paul Turner
    Cc: Richard Cochran
    Cc: Prarit Bhargava
    Reviewed-by: Paul Turner
    Reported-by: Aaron Jacobs
    Signed-off-by: Andrew Hunter
    [jstultz: Tweaked to apply to 3.17-rc]
    Signed-off-by: John Stultz

    Andrew Hunter
     

24 Jul, 2014

3 commits


23 Jun, 2014

1 commit