06 Jan, 2012

3 commits

  • We need to synchronize across rings when doing a bo move to make
    sure we the buffer is idle if it's in use by a different ring than
    the ring doing the move.

    v2: fix fence setup for bo moves

    v3: add missing ring lock/unlock

    Signed-off-by: Alex Deucher
    Signed-off-by: Dave Airlie

    Alex Deucher
     
  • Use semaphores to sync buffers across rings in the CS
    ioctl. Add a reloc flag to allow userspace to skip
    sync for buffers.

    agd5f: port to latest CS ioctl changes.

    v2: add ring lock/unlock to make sure changes hit the ring.

    Signed-off-by: Christian König
    Signed-off-by: Alex Deucher
    Signed-off-by: Dave Airlie

    Christian König
     
  • Virtual address space are per drm client (opener of /dev/drm).
    Client are in charge of virtual address space, they need to
    map bo into it by calling DRM_RADEON_GEM_VA ioctl.

    First 16M of virtual address space is reserved by the kernel.

    Once using 2 level page table we should be able to have a small
    vram memory footprint for each pt (there would be one pt for all
    gart, one for all vram and then one first level for each virtual
    address space).

    Plan include using the sub allocator for a common vm page table
    area and using memcpy to copy vm page table in & out. Or use
    a gart object and copy things in & out using dma.

    v2: agd5f fixes:
    - Add vram base offset for vram pages. The GPU physical address of a
    vram page is FB_OFFSET + page offset. FB_OFFSET is 0 on discrete
    cards and the physical bus address of the stolen memory on
    integrated chips.
    - VM_CONTEXT1_PROTECTION_FAULT_DEFAULT_ADDR covers all vmid's >= 1

    v3: agd5f:
    - integrate with the semaphore/multi-ring stuff

    v4:
    - rebase on top ttm dma & multi-ring stuff
    - userspace is now in charge of the address space
    - no more specific cs vm ioctl, instead cs ioctl has a new
    chunk

    v5:
    - properly handle mem == NULL case from move_notify callback
    - fix the vm cleanup path

    v6:
    - fix update of page table to only happen on valid mem placement

    v7:
    - add tlb flush for each vm context
    - add flags to define mapping property (readable, writeable, snooped)
    - make ring id implicit from ib->fence->ring, up to each asic callback
    to then do ring specific scheduling if vm ib scheduling function

    v8:
    - add query for ib limit and kernel reserved virtual space
    - rename vm->size to max_pfn (maximum number of page)
    - update gem_va ioctl to also allow unmap operation
    - bump kernel version to allow userspace to query for vm support

    v9:
    - rebuild page table only when bind and incrementaly depending
    on bo referenced by cs and that have been moved
    - allow virtual address space to grow
    - use sa allocator for vram page table
    - return invalid when querying vm limit on non cayman GPU
    - dump vm fault register on lockup

    v10: agd5f:
    - Move the vm schedule_ib callback to a standalone function, remove
    the callback and use the existing ib_execute callback for VM IBs.

    v11:
    - rebase on top of lastest Linus

    v12: agd5f:
    - remove spurious backslash
    - set IB vm_id to 0 in radeon_ib_get()

    v13: agd5f:
    - fix handling of RADEON_CHUNK_ID_FLAGS

    v14:
    - fix va destruction
    - fix suspend resume
    - forbid bo to have several different va in same vm

    v15:
    - rebase

    v16:
    - cleanup left over of vm init/fini

    v17: agd5f:
    - cs checker

    v18: agd5f:
    - reworks the CS ioctl to better support multiple rings and
    VM. Rather than adding a new chunk id for VM, just re-use the
    IB chunk id and add a new flags for VM mode. Also define additional
    dwords for the flags chunk id to define the what ring we want to use
    (gfx, compute, uvd, etc.) and the priority.

    v19:
    - fix cs fini in weird case of no ib
    - semi working flush fix for ni
    - rebase on top of sa allocator changes

    v20: agd5f:
    - further CS ioctl cleanups from Christian's comments

    v21: agd5f:
    - integrate CS checker improvements

    v22: agd5f:
    - final cleanups for release, only allow VM CS on cayman

    Signed-off-by: Jerome Glisse
    Signed-off-by: Alex Deucher
    Signed-off-by: Dave Airlie

    Jerome Glisse
     

05 Jan, 2012

9 commits

  • drm_getclient, drm_getstats and drm_getmap (with a few minor
    adjustments) do not need global mutex, so fix that and
    make the said ioctls DRM_UNLOCKED. Details:

    drm_getclient: the only thing that should be protected here
    is dev->filelist and that is already protected everywhere with
    dev->struct_mutex.

    drm_getstats: there is no need for any mutex here because the
    loop runs through quasi-static (set at load time only)
    data, and the actual count access is done with atomic_read()

    drm_getmap already uses dev->struct_mutex to protect
    dev->maplist, which also used to protect the same structure
    everywhere else except at three places:
    * drm_getsarea, which doesn't grab *any* mutex before
    touching dev->maplist (so no drm_global_mutex doesn't help
    here either; different issue for a different patch).
    However, drivers seem to call it only at
    initialization time so it probably doesn't matter
    * drm_master_destroy, which is called from drm_master_put,
    which in turn is protected with dev->struct_mutex
    everywhere else in drm module, so we are good here too.
    * drm_getsareactx, which releases the dev->struct_mutex
    too early, but this patch includes the fix for that.

    v2: * incorporate comments received from Daniel Vetter
    * include the (long) explanation above to make it clear what
    we are doing (and why), also at Daniel Vetter's request
    * tighten up mutex grab/release locations to only
    encompass real critical sections, rather than some
    random code around them

    Signed-off-by: Ilija Hadzic
    Reviewed-by: Daniel Vetter
    Signed-off-by: Dave Airlie

    Ilija Hadzic
     
  • drm_getcap and drm_version ioctls only reads static data,
    there is no need to protect them with drm_global_mutex,
    so make them DRM_UNLOCKED

    Signed-off-by: Ilija Hadzic
    Reviewed-by: Daniel Vetter
    Signed-off-by: Dave Airlie

    Ilija Hadzic
     
  • Sweep common_modes array should start with index 0.

    Signed-off-by: Chen Jie
    Reviewed-by: Ilija Hadzic
    Signed-off-by: Dave Airlie

    Chen Jie
     
  • We often end up missing fences on older asics with
    writeback enabled which leads to delays in the userspace
    accel code, so just disable it by default on those asics.

    Reported-by: Helge Deller
    Reported-by: Dave Airlie
    Signed-off-by: Alex Deucher
    Cc: stable@vger.kernel.org
    Signed-off-by: Dave Airlie

    Alex Deucher
     
  • This allow to share the ib pool with semaphore and avoid
    having more bo around.

    Signed-off-by: Jerome Glisse
    Signed-off-by: Alex Deucher
    Signed-off-by: Dave Airlie

    Jerome Glisse
     
  • This avoid to waste ib pool size and avoid a bunch of wait for
    previous ib to finish.

    Signed-off-by: Jerome Glisse
    Signed-off-by: Alex Deucher
    Signed-off-by: Dave Airlie

    Jerome Glisse
     
  • Signed-off-by: Alex Deucher
    Signed-off-by: Dave Airlie

    Alex Deucher
     
  • In cases where the scanout hw is sufficiently similar between "overlay"
    and traditional crtc layers, it might be convenient to allow the driver
    to create internal drm_plane helper objects used by the drm_crtc
    implementation, rather than duplicate code between the plane and crtc.
    A private plane is not exposed to userspace.

    Signed-off-by: Rob Clark
    Signed-off-by: Dave Airlie

    Rob Clark
     
  • Since plane->fb and plane->crtc are set in drm_mode_setplane()
    after update_plane(), They should be cleared after disable().

    Signed-off-by: Rob Clark
    Signed-off-by: Dave Airlie

    Rob Clark
     

04 Jan, 2012

17 commits

  • If it failed, leave it in the "off" state.

    Signed-off-by: Jesse Barnes
    Signed-off-by: Keith Packard

    Jesse Barnes
     
  • If a PCH pipe PLL is being used by transcoder C, don't disable it.

    Signed-off-by: Jesse Barnes
    Signed-off-by: Keith Packard

    Jesse Barnes
     
  • In the pre-gem days with non-existing hangcheck and gpu reset code,
    this timeout of 3 seconds was pretty important to avoid stuck
    processes.

    But now we have the hangcheck code in gem that goes to great length
    to ensure that the gpu is really dead before declaring it wedged.

    So there's no need for this timeout anymore. Actually it's even harmful
    because we can bail out too early (e.g. with xscreensaver slip)
    when running giant batchbuffers. And our code isn't robust enough
    to properly unroll any state-changes, we pretty much rely on the gpu
    reset code cleaning up the mess (like cache tracking, fencing state,
    active list/request tracking, ...).

    With this change intel_begin_ring can only fail when the gpu is
    wedged, and it will return -EAGAIN (like wait_request in case the
    gpu reset is still outstanding).

    v2: Chris Wilson noted that on resume timers aren't running and hence
    we won't ever get kicked out of this loop by the hangcheck code. Use
    an insanely large timeout instead for the HAS_GEM case to prevent
    resume bugs from totally hanging the machine.

    Signed-off-by: Daniel Vetter
    Reviewed-by: Chris Wilson
    Acked-by: Ben Widawsky
    Reviewed-by: Eugeni Dodonov
    Signed-off-by: Keith Packard

    Daniel Vetter
     
  • If our semaphore logic gets confused and we have a ring stuck waiting
    for one, there's a decent chance it'll just execute garbage when being
    kicked. Also, kicking the ring obscures the place where the error
    first occured, making error_state decoding much harder.

    So drop this an let gpu reset handle this mess in a clean fashion.

    In contrast, kicking rings stuck on MI_WAIT is rather harmless, at
    worst there'll be a bit of screen-flickering. There's also old
    broken userspace out there which needs this as a work-around.

    Signed-off-by: Daniel Vetter
    Reviewed-by: Chris Wilson
    Reviewed-by: Ben Widawsky
    Signed-off-by: Keith Packard

    Daniel Vetter
     
  • These registers are automatically incremented by the hardware during
    transform feedback to track where the next streamed vertex output
    should go. Unlike the previous generation, which had a packet for
    setting the corresponding registers to a defined value, gen7 only has
    MI_LOAD_REGISTER_IMM to do so. That's a secure packet (since it loads
    an arbitrary register), so we need to do it from the kernel, and it
    needs to be settable atomically with the batchbuffer execution so that
    two clients doing transform feedback don't stomp on each others'
    state.

    Instead of building a more complicated interface involcing setting the
    registers to a specific value, just set them to 0 when asked and
    userland can tweak its pointers accordingly.

    Signed-off-by: Eric Anholt
    Reviewed-by: Eugeni Dodonov
    Reviewed-by: Kenneth Graunke
    Signed-off-by: Keith Packard

    Eric Anholt
     
  • The waits we do here are generally so short that sleeping is a bad
    idea unless we have an IRQ to wake us up. Improves regression test
    performance from 18 minutes to 3.5 minutes on gen7, which is now
    consistent with the previous generation.

    Signed-off-by: Eric Anholt
    Tested-by: Eugeni Dodonov
    Reviewed-by: Eugeni Dodonov
    Acked-by: Kenneth Graunke
    Signed-off-by: Keith Packard

    Eric Anholt
     
  • Previous to this commit, testing easily reproduced a failure where the
    seqno would apparently arrive after the IRQ associated with it, with test programs as simple as:

    for (;;) {
    glCopyPixels(0, 0, 1, 1);
    glFinish();
    }

    Various workarounds we've seen for previous generations didn't work to
    fix this issue, so until new information comes in, replace the IRQ
    waits on the BLT ring with polling.

    Signed-off-by: Eric Anholt
    Tested-by: Eugeni Dodonov
    Reviewed-by: Eugeni Dodonov
    Acked-by: Kenneth Graunke
    Signed-off-by: Keith Packard

    Eric Anholt
     
  • As a workaround for IRQ synchronization issues in the gen7 BLT ring,
    we want to turn the two wait functions into polling loops.

    Signed-off-by: Eric Anholt
    Tested-by: Eugeni Dodonov
    Reviewed-by: Eugeni Dodonov
    Acked-by: Kenneth Graunke
    Signed-off-by: Keith Packard

    Eric Anholt
     
  • They don't fix our problems alone, but we're told to set them.

    Signed-off-by: Eric Anholt
    Signed-off-by: Keith Packard

    Eric Anholt
     
  • Add new ioctls for getting and setting the current destination color
    key. This allows for simple overlay display control by matching a color
    key value in the primary plane before blending the overlay on top.

    v2: remove unnecessary mutex acquire/release around reg accesses
    v3: add support for full color key management
    v4: fix copy & paste bug in snb_get_colorkey
    don't bother checking min/max values against docs as the docs are likely
    wrong (how could we handle 10bpc surface formats?)

    Reviewed-by: Daniel Vetter
    Signed-off-by: Jesse Barnes

    Jesse Barnes
     
  • To save power when the sprite is full screen, we can disable the primary
    plane on the same pipe. Track the sprite status and enable/disable the
    primary opportunistically.

    v2: remove primary plane enable/disable hooks; they're identical

    Reviewed-by: Daniel Vetter
    Signed-off-by: Jesse Barnes
    Signed-off-by: Keith Packard

    Jesse Barnes
     
  • The video sprites support various video surface formats natively and can
    handle scaling as well. So add support for them using the new DRM core
    sprite support functions.

    v2: use drm specific fourcc header and defines
    v3: address Daniel's comments:
    - don't take struct mutex around register access (only needed for
    regs in the GT power well)
    - don't hold struct mutex across vblank waits
    - fix up update_plane API (pass obj instead of GTT offset)
    - add interlaced defines for sprite regs
    - drop unnecessary 'reg' variables
    - comment double buffered reg flushing
    Also fix w/h confusion when writing the scaling reg.
    v4: more fixes, address more comments from Daniel, and include Hai's fix
    - prevent divide by zero in scaling calculation (Hai Lan)
    - update to Ville's new DRM_FORMAT_* types
    - fix sprite watermark handling (calc based on CRTC size, separate
    from normal display wm)
    - remove private refcounts now that the fb cleanups handles things
    v5: add linear surface support
    v6: remove color key clearing & setting from update_plane

    For this version, I tested DPMS since it came up in the last review;
    DPMS off/on works ok when a video player is working under X, but for
    power saving we'll probably want to do something smarter. I'll leave
    that for a separate patch on top. Likewise with the refcounting/fb
    layer handling, which are really separate cleanups.

    Reviewed-by: Daniel Vetter
    Signed-off-by: Jesse Barnes
    Signed-off-by: Keith Packard

    Jesse Barnes
     
  • We learned that the ECOBUS register was inside the GT power well, and
    so *did* need force wake to be read, so it gets removed from the list
    of 'doesn't need force wake' registers.

    That means the code reading ECOBUS after forcing the mt_force_wake
    function to be called needs to use I915_READ_NOTRACE; it doesn't need
    to do more force wake fun as it's already done it manually.

    This also adds a comment explaining why the MT forcewake testing code
    only needs to call mt_forcewake_get/put and not disable RC6 manually
    -- the ECOBUS read will return 0 if the device is in RC6 and isn't
    using MT forcewake, causing the test to work correctly.

    Signed-off-by: Keith Packard
    Cc: Jesse Barnes

    Keith Packard
     
  • Many of the old fields from Ironlake have gone away. Strip all those
    fields, and try to update to fields people care about. RC information
    isn't exactly ideal anymore. All we can guarantee when we read the
    register is that we're not using forcewake, ie. the software isn't
    forcing the hardware to stay awake. The downside is that in doing this
    we may wait a while and that causes an unnaturally idle state on the
    GPU.

    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42578
    Signed-off-by: Ben Widawsky
    Reviewed-by: Jesse Barnes
    Signed-off-by: Keith Packard

    Ben Widawsky
     
  • This matches the modern specs more accurately.

    This will be used by the following patch to fix the way we display RC
    status.

    Signed-off-by: Ben Widawsky
    Reviewed-by: Jesse Barnes
    Reviewed-by: Eugeni Dodonov
    Signed-off-by: Keith Packard

    Ben Widawsky
     
  • The docs say this is required for Gen7, and since the bit was added for
    Gen6, we are also setting it there pit pf paranoia. Particularly as
    Chris points out, if PIPE_CONTROL counts as a 3d state packet.

    This was found through doc inspection by Ken and applies to Gen6+;

    Reported-by: Kenneth Graunke
    Signed-off-by: Ben Widawsky
    Reviewed-by: Chris Wilson
    Reviewed-by: Daniel Vetter
    Reviewed-by: Eric Anholt
    Signed-off-by: Keith Packard

    Ben Widawsky
     
  • dev_priv keeps track of the current addressing mode that gets set at
    execbuffer time. Unfortunately the existing code was doing this before
    acquiring struct_mutex which leaves a race with another thread also
    doing an execbuffer. If that wasn't bad enough, relocate_slow drops
    struct_mutex which opens a much more likely error where another thread
    comes in and modifies the state while relocate_slow is being slow.

    The solution here is to just defer setting this state until we
    absolutely need it, and we know we'll have struct_mutex for the
    remainder of our code path.

    v2: Keith noticed a bug in the original patch.

    Signed-off-by: Ben Widawsky
    Reviewed-by: Daniel Vetter
    Signed-off-by: Keith Packard

    Ben Widawsky
     

03 Jan, 2012

9 commits

  • This merges the evergreen HDMI audio support.

    * 'drm-radeon-testing' of ../drm-radeon-next:
    drm/radeon/kms: define TMDS/LVTM HDMI enabling bits
    drm/radeon/kms: workaround invalid AVI infoframe checksum issue
    drm/radeon/kms: setup HDMI mode on Evergreen encoders
    drm/radeon/kms: support for audio on Evergreen
    drm/radeon/kms: minor HDMI audio cleanups
    drm/radeon/kms: do not force DVI mode on DCE4 if audio is on
    ridge

    Conflicts:
    drivers/gpu/drm/radeon/evergreen.c

    Dave Airlie
     
  • The names has been taken from free M76 specs.

    Signed-off-by: Rafał Miłecki
    Reviewed-by: Alex Deucher
    Signed-off-by: Dave Airlie

    Rafał Miłecki
     
  • This change was verified to fix both issues with no video I've
    investigated. I've also checked checksum calculation with fglrx on:
    RV620, HD54xx, HD5450, HD6310, HD6320.

    Cc: stable@vger.kernel.org
    Signed-off-by: Rafał Miłecki
    Signed-off-by: Dave Airlie

    Rafał Miłecki
     
  • Signed-off-by: Rafał Miłecki
    Signed-off-by: Dave Airlie

    Rafał Miłecki
     
  • * 'drm-intel-next' of git://people.freedesktop.org/~keithp/linux:
    drm/i915: check ACTHD of all rings
    drm/i915: DisplayPort hot remove notification to audio driver
    drm/i915: HDMI hot remove notification to audio driver
    drm/i915: dont trigger hotplug events on unchanged ELD
    drm/i915: rename audio ELD registers
    drm/i915: fix ELD writing for SandyBridge

    Dave Airlie
     
  • This doesn't work and isn't of any use. It was inherited from the older
    driver code and can go away. Kill it off before it becomes part of mainstream
    as we don't want to support it in future.

    Signed-off-by: Alan Cox
    Signed-off-by: Dave Airlie

    Alan Cox
     
  • And update to the actual product naming as the press release is now out.

    http://newsroom.intel.com/docs/DOC-2553#pressmaterials

    - Fixes the wrong ifdef check
    - Fixes the missing crtc count declaration

    Signed-off-by: Alan Cox
    Signed-off-by: Dave Airlie

    Alan Cox
     
  • Oaktrail Atom E620 has a different PCI identifier we need to cover

    Signed-off-by: Alan Cox
    Signed-off-by: Dave Airlie

    Alan Cox
     
  • …sung into drm-core-next

    these patch sets include the following features:
    - add Samsung SoC Exynos based HDMI support.
    - add pm feature for fimd driver.
    - add multi buffer plane pixel formats to drm/drm_fourcc.h.
    multi buffer plane pixel format has seperated memory spaces for each
    plane. for exampme, NV12M has Y plane and CbCr plane and these are in
    non-continuous memory region. compared with NV12, NV12M's memory shape
    is like following.
    NV12 : ______(Y)(CbCr)_______
    NV12M : __(Y)_ ..... _(CbCr)__
    - bug fix to vblank.
    - code clean to exynos gem framework.

    * 'exynos-drm-next' of git://git.infradead.org/users/kmpark/linux-samsung:
    drm/exynos: added hdmi display support
    drm/exynos: added mutex lock and code clean.
    drm/exynos: extend vblank off delay time.
    drm/exynos: change driver name.
    drm/exynos: Support multi buffers
    drm: Add multi buffer plane pixel formats
    drm/exynos: added pm support.
    drm/exynos: remove buffer creation of fbdev from drm framebuffer creation
    drm/exynos: Split creation of gem object and gem handle
    drm/exynos: Fix a fake mmap offset creation
    drm/exynos: gem code cleanup

    Dave Airlie
     

29 Dec, 2011

2 commits

  • This patch is hdmi display support for exynos drm driver.

    There is already v4l2 based exynos hdmi driver in drivers/media/video/s5p-tv
    and some low level code is already in s5p-tv and even headers for register
    define are almost same. but in this patch, we decide not to consider separated
    common code with s5p-tv.

    Exynos HDMI is composed of 5 blocks, mixer, vp, hdmi, hdmiphy and ddc.

    1. mixer. The piece of hardware responsible for mixing and blending multiple
    data inputs before passing it to an output device. The mixer is capable of
    handling up to three image layers. One is the output of VP. Other two are
    images in RGB format. The blending factor, and layers' priority are controlled
    by mixer's registers. The output is passed to HDMI.

    2. vp (video processor). It is used for processing of NV12/NV21 data. An image
    stored in RAM is accessed by DMA. The output in YCbCr444 format is send to
    mixer.

    3. hdmi. The piece of HW responsible for generation of HDMI packets. It takes
    pixel data from mixer and transforms it into data frames. The output is send
    to HDMIPHY interface.

    4. hdmiphy. Physical interface for HDMI. Its duties are sending HDMI packets to
    HDMI connector. Basically, it contains a PLL that produces source clock for
    mixer, vp and hdmi.

    5. ddc (display data channel). It is dedicated i2c channel to exchange display
    information as edid with display monitor.

    With plane support, exynos hdmi driver fully supports two mixer layes and vp
    layer. Also vp layer supports multi buffer plane pixel formats having non
    contigus memory spaces.

    In exynos drm driver, common drm_hdmi driver to interface with drm framework
    has opertion pointers for mixer and hdmi. this drm_hdmi driver is registered as
    sub driver of exynos_drm. hdmi has hdmiphy and ddc i2c clients and controls
    them. mixer controls all overlay layers in both mixer and vp.

    Vblank interrupts for hdmi are handled by mixer internally because drm
    framework cannot support multiple irq id. And pipe number is used to check
    which display device irq happens.

    History
    v2: this version
    - drm plane feature support to handle overlay layers.
    - multi buffer plane pixel format support for vp layer.
    - vp layer support

    RFCv1: original
    - at https://lkml.org/lkml/2011/11/4/164

    Signed-off-by: Seung-Woo Kim
    Signed-off-by: Inki Dae
    Signed-off-by: Joonyoung Shim
    Signed-off-by: Kyungmin Park

    Seung-Woo Kim
     
  • Signed-off-by: Inki Dae

    Inki Dae