24 Apr, 2014

1 commit

  • If the inherited BIOS framebuffer is smaller than the mode selected for
    fbdev, then if we continue to use it then we cause display corruption as
    we do not setup the panel fitter to upscale.

    Regression from commit d978ef14456a38034f6c0e94a794129501f89200
    Author: Jesse Barnes
    Date: Fri Mar 7 08:57:51 2014 -0800

    drm/i915: Wrap the preallocated BIOS framebuffer and preserve for KMS fbcon v12

    v2: Add a debug message to track the discard of the BIOS fb.
    v3: Ville pointed out the difference between ref/unref

    Reported-by: Knut Petersen
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77767
    Signed-off-by: Chris Wilson
    Cc: Jesse Barnes
    Reviewed-by: Daniel Vetter
    Reviewed-by: Ville Syrjälä
    Signed-off-by: Jani Nikula

    Chris Wilson
     

05 Apr, 2014

1 commit

  • Merge window -fixes pull request as usual. Well, I did sneak in Jani's
    drm_i915_private_t typedef removal, need to have fun with a big sed job
    too ;-)

    Otherwise:
    - hdmi interlaced fixes (Jesse&Ville)
    - pipe error/underrun/crc tracking fixes, regression in late 3.14-rc (but
    not cc: stable since only really relevant for igt runs)
    - large cursor wm fixes (Chris)
    - fix gpu turbo boost/throttle again, was getting stuck due to vlv rps
    patches (Chris+Imre)
    - fix runtime pm fallout (Paulo)
    - bios framebuffer inherit fix (Chris)
    - a few smaller things

    * tag 'drm-intel-fixes-2014-04-04' of git://anongit.freedesktop.org/drm-intel: (196 commits)
    Skip intel_crt_init for Dell XPS 8700
    drm/i915: vlv: fix RPS interrupt mask setting
    Revert "drm/i915/vlv: fixup DDR freq detection per Punit spec"
    drm/i915: move power domain init earlier during system resume
    drm/i915: Fix the computation of required fb size for pipe
    drm/i915: don't get/put runtime PM at the debugfs forcewake file
    drm/i915: fix WARNs when reading DDI state while suspended
    drm/i915: don't read cursor registers on powered down pipes
    drm/i915: get runtime PM at i915_display_info
    drm/i915: don't read pp_ctrl_reg if we're suspended
    drm/i915: get runtime PM at i915_reg_read_ioctl
    drm/i915: don't schedule force_wake_timer at gen6_read
    drm/i915: vlv: reserve the GT power context only once during driver init
    drm/i915: prefer struct drm_i915_private to drm_i915_private_t
    drm/i915/overlay: prefer struct drm_i915_private to drm_i915_private_t
    drm/i915/ringbuffer: prefer struct drm_i915_private to drm_i915_private_t
    drm/i915/display: prefer struct drm_i915_private to drm_i915_private_t
    drm/i915/irq: prefer struct drm_i915_private to drm_i915_private_t
    drm/i915/gem: prefer struct drm_i915_private to drm_i915_private_t
    drm/i915/dma: prefer struct drm_i915_private to drm_i915_private_t
    ...

    Dave Airlie
     

03 Apr, 2014

1 commit

  • - Inherit/reuse firmwar framebuffers (for real this time) from Jesse, less
    flicker for fastbooting.
    - More flexible cloning for hdmi (Ville).
    - Some PPGTT fixes from Ben.
    - Ring init fixes from Naresh Kumar.
    - set_cache_level regression fixes for the vma conversion from Ville&Chris.
    - Conversion to the new dp aux helpers (Jani).
    - Unification of runtime pm with pc8 support from Paulo, prep work for runtime
    pm on other platforms than HSW.
    - Larger cursor sizes (Sagar Kamble).
    - Piles of improvements and fixes all over, as usual.

    * tag 'drm-intel-next-2014-03-21' of git://anongit.freedesktop.org/drm-intel: (75 commits)
    drm/i915: Include a note about the dangers of I915_READ64/I915_WRITE64
    drm/i915/sdvo: fix questionable return value check
    drm/i915: Fix unsafe loop iteration over vma whilst unbinding them
    drm/i915: Enabling 128x128 and 256x256 ARGB Cursor Support
    drm/i915: Print how many objects are shared in per-process stats
    drm/i915: Per-process stats work better when evaluated per-process
    drm/i915: remove rps local variables
    drm/i915: Remove extraneous MMIO for RPS
    drm/i915: Rename and comment all the RPS *stuff*
    drm/i915: Store the HW min frequency as min_freq
    drm/i915: Fix coding style for RPS
    drm/i915: Reorganize the overclock code
    drm/i915: init pm.suspended earlier
    drm/i915: update the PC8 and runtime PM documentation
    drm/i915: rename __hsw_do_{en, dis}able_pc8
    drm/i915: kill struct i915_package_c8
    drm/i915: move pc8.irqs_disabled to pm.irqs_disabled
    drm/i915: remove dev_priv->pc8.enabled
    drm/i915: don't get/put PC8 when getting/putting power wells
    drm/i915: make intel_aux_display_runtime_get get runtime PM, not PC8
    ...

    Conflicts:
    drivers/gpu/drm/i915/intel_display.c
    drivers/gpu/drm/i915/intel_dp.c

    Dave Airlie
     

02 Apr, 2014

1 commit

  • The computation of required framebuffer size in

    commit d978ef14456a38034f6c0e94a794129501f89200
    Author: Jesse Barnes
    Date: Fri Mar 7 08:57:51 2014 -0800

    drm/i915: Wrap the preallocated BIOS framebuffer and preserve for KMS fbcon v12

    is too optimistic, and would rely on the invariant fb being
    reconstructed to exactly fit each pipe (and probably ignore hardware
    limits). Instead, we want to compute the upper bound on what the display
    engine will access and ensure that is within the inherited framebuffer.

    Signed-off-by: Chris Wilson
    Cc: Jesse Barnes
    Signed-off-by: Daniel Vetter

    Chris Wilson
     

08 Mar, 2014

2 commits

  • By stuffing the fb allocation into the crtc, we get mode set lifetime
    refcounting for free, but have to handle the initial pin & fence
    slightly differently. It also means we can move the shared fb handling
    into the core rather than leaving it out in the fbdev code.

    v2: null out crtc->fb on error (Daniel)
    take fbdev fb ref and remove unused error path (Daniel)

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

    Jesse Barnes
     
  • Retrieve current framebuffer config info from the regs and create an fb
    object for the buffer the BIOS or boot loader left us. This should
    allow for smooth transitions to userspace apps once we finish the
    initial configuration construction.

    v2: check for non-native modes and adjust (Jesse)
    fixup aperture and cmap frees (Imre)
    use unlocked unref if init_bios fails (Jesse)
    fix curly brace around DSPADDR check (Imre)
    comment failure path for pin_and_fence (Imre)
    v3: fixup fixup of aperture frees (Chris)
    v4: update to current bits (locking & pin_and_fence hack) (Jesse)
    v5: move fb config fetch to display code (Jesse)
    re-order hw state readout on initial load to suit fb inherit (Jesse)
    re-add pin_and_fence in fbdev code to make sure we refcount properly (Je
    v6: rename to plane_config (Daniel)
    check for valid object when initializing BIOS fb (Jesse)
    split from plane_config readout and other display changes (Jesse)
    drop use_bios_fb option (Chris)
    update comments (Jesse)
    rework fbdev_init_bios for clarity (Jesse)
    drop fb obj ref under lock (Chris)
    v7: use fb object from plane_config instead (Ville)
    take ref on fb object (Jesse)
    v8: put under i915_fastboot option (Jesse)
    fix fb ptr checking (Jesse)
    inform drm_fb_helper if we fail to enable a connector (Jesse)
    drop unnecessary enabled[] modifications in failure cases (Chris)
    split from BIOS connector config readout (Daniel)
    don't memset the fb buffer if preallocated (Chris)
    alloc ifbdev up front and pass to init_bios (Chris)
    check for bad ifbdev in restore_mode too (Chris)
    v9: fix up !fastboot bpp setting (Jesse)
    fix up !fastboot helper alloc (Jesse)
    make sure BIOS fb is sufficient for biggest active pipe (Jesse)
    v10:fix up size calculation for proposed fbs (Chris)
    go back to two pass pipe fb assignment (Chris)
    add warning for active pipes w/o fbs (Chris)
    clean up num_pipes checks in fbdev_init and fbdev_restore_mode (Chris)
    move i915.fastboot into fbdev_init (Chris)
    v11:make BIOS connector config usage unconditional (Daniel)
    v12:fix up fb vs pipe size checking (Chris)

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

    Jesse Barnes
     

06 Mar, 2014

3 commits

  • Both Ville and QA rather immediately complained that with the new
    initial_config logic from Jesse not all outputs get enabled. Since the
    fbdev emulation pretty much tries to always enable as many outputs as
    possible (it even has hotplug handling and all that) fall back if more
    outputs could have been enabled.

    v2: Fix up my confusion about what enabled means - it's passed from
    the fbdev helper, we need to check for a non-zero connector->encoder
    link. Spotted by Ville.

    v3: Add some debug output as requested by Jesse for debugging fallback
    issues.

    Cc: Jesse Barnes
    Cc: Ville Syrjälä
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75552
    Tested-by: Ville Syrjälä
    Reviewed-by: Jesse Barnes
    Signed-off-by: Daniel Vetter

    Daniel Vetter
     
  • It started as a simple check whether anything is lit up, but now is't
    used to driver the general fallback logic to the default output
    configuration selector in the helper library. So rename it for more
    clarity.

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

    Daniel Vetter
     
  • In the move over to use BIOS connector configs, we lost the ability to
    force a specific set of connectors on or off. Try to remedy that by
    dropping back to the old behavior if we detect a hard coded connector
    config.

    v2: don't deref connector state for disabled connectors (Jesse)

    Reported-by: Ville Syrjälä
    Signed-off-by: Jesse Barnes
    Signed-off-by: Daniel Vetter

    Jesse Barnes
     

13 Feb, 2014

6 commits

  • It can be corrected later and may be what was actually desired, but
    generally isn't, so if we find nothing is enabled, let the core DRM fb
    helper figure something out.

    v2: free the array too (Jesse)

    Note that this also undoes any changes in case we bail out due to hw
    cloning.

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

    Jesse Barnes
     
  • The BIOS or boot loader will generally create an initial display
    configuration for us that includes some set of active pipes and
    displays. This routine tries to figure out which pipes and connectors
    are active and stuffs them into the crtcs and modes array given to us by
    the drm_fb_helper code.

    The overall sequence is:
    intel_fbdev_init - from driver load
    intel_fbdev_init_bios - initialize the intel_fbdev using BIOS data
    drm_fb_helper_init - build fb helper structs
    drm_fb_helper_single_add_all_connectors - more fb helper structs
    intel_fbdev_initial_config - apply the config
    drm_fb_helper_initial_config - call ->probe then register_framebuffer()
    drm_setup_crtcs - build crtc config for fbdev
    intel_fb_initial_config - find active connectors etc
    drm_fb_helper_single_fb_probe - set up fbdev
    intelfb_create - re-use or alloc fb, build out fbdev structs

    v2: use BIOS connector config unconditionally if possible (Daniel)
    check for crtc cloning and reject (Daniel)
    fix up comments (Daniel)
    v3: use command line args and preferred modes first (Ville)

    Signed-off-by: Jesse Barnes
    Tested-by: Ville Syrjälä
    [danvet: Re-add the WARN_ON for a missing encoder crtc - the state
    sanitizer should take care of this. And spell-ocd the comments.]
    Signed-off-by: Daniel Vetter

    Jesse Barnes
     
  • So far during driver unload we called drm_framebuffer_cleanup() for the
    fbdev fb, which only removes the fb from the drm fb list regardless of
    its reference count, but leaves the fb bound on an active crtc. Since
    the fb's backing storage was freed this could mean we scan some random
    memory content out afterwards. It's not a big issue since the fb is
    allocated from stolen memory and afaik there is no other user for that
    than i915. It's still cleaner to properly unbind the fb and disable the
    crtc, which is what drm_framebuffer_remove() does.

    Note that after

    commit 88891eb1e9eca0ba619518bed31580f91e9cf84d
    Author: Daniel Vetter
    Date: Mon Feb 10 18:00:38 2014 +0100

    we call drm_framebuffer_cleanup() only after dropping the last reference
    on the fb, but that won't happen since we don't unbind the fb. This
    results in a drm core warn about a leaked fb.

    Signed-off-by: Imre Deak
    Signed-off-by: Daniel Vetter

    Imre Deak
     
  • In Jesse's patch to switch the fbdev framebuffer from an embedded
    struct to a pointer the kfree in case of an error was missed. Fix this
    up by using our own internal fb allocation helper directly instead of
    reinventing that wheel.

    We need a to_intel_framebuffer cast unfortunately since all the other
    callers of _create still look better whith using a drm_framebuffer as
    return pointer.

    v2: Add an unlocked __intel_framebuffer_create function since our
    dev->struct_mutex locking is too much a mess. With ppgtt we even need
    it to take a look at the global gtt offset of pinned objects, since
    the vma list might chance from underneath us. At least with the
    current global gtt lookup functions. Reported by Mika.

    Cc: Mika Kuoppala
    Cc: Jesse Barnes
    Reviewed-by: Jesse Barnes
    Signed-off-by: Daniel Vetter

    Daniel Vetter
     
  • Now that it's a normally kmalloce buffer we can use the usual cleanup
    paths. The upside here is that if we get the refcounting wrong will be
    able to catch it, since the drm core will complain about leftover
    framebuffers and kref about underflows.

    v2: Kill intel_framebuffer_fini - no longer needed now that we
    refcount all fbs properly and only confusing.

    v3: We actually still need to call unregister_private to remove the fb
    from the idr and drop the idr reference - the final unref doesn't do
    that. So much for remembering my own fb liftime rules. Reported by
    Imre Deak.

    Cc: Jesse Barnes
    Reviewed-by: Jesse Barnes (v2)
    Signed-off-by: Daniel Vetter

    Daniel Vetter
     
  • Allocate this struct instead, so we can re-use another allocated
    elsewhere if needed.

    Signed-off-by: Jesse Barnes
    [danvet: WARN_ON if there's no backing storage attached to an fb,
    that's a bug.]
    Signed-off-by: Daniel Vetter

    Jesse Barnes
     

26 Jan, 2014

1 commit


07 Jan, 2014

1 commit


18 Dec, 2013

1 commit


28 Nov, 2013

1 commit


27 Nov, 2013

1 commit


21 Oct, 2013

1 commit


12 Oct, 2013

1 commit

  • This file is all about the legacy fbdev support. If we want to extract
    framebuffer functions, we better put those into a separate file.

    Also rename functions accordingly, only two have used the intel_fb_
    prefix anyway.

    Reviewed-by: Chon Ming Lee
    Signed-off-by: Daniel Vetter

    Daniel Vetter