04 Jan, 2012

7 commits

  • 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
     
  • 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
     
  • 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
     
  • 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
     

03 Jan, 2012

1 commit


20 Dec, 2011

3 commits


17 Dec, 2011

1 commit


24 Nov, 2011

2 commits

  • The Ivybridge eDP control register looks like a cross between a
    Cougarpoint PCH DP control register and a Sandybridge eDP control
    register.

    Where things trivially match, share the code. Where there are any
    tricky bits, just split things out into two obviously separate code paths.

    Signed-off-by: Keith Packard
    Tested-by: Fang Xun
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41991

    Keith Packard
     
  • On IVB C0+ with newer BIOSes, the forcewake handshake has changed. There's
    now a bitfield for different driver components to keep the GT powered
    on. On Linux, we centralize forcewake handling in one place, so we
    still just need a single bit, but we need to use the new registers if MT
    forcewake is enabled.

    This needs testing on affected machines. Please reply with your
    tested-by if you had problems after a BIOS upgrade and this patch fixes
    them.

    v2: force MT mode. shift by 16
    v3: set MT force wake bits then check ECOBUS

    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42923
    Tested-by: Manoj Iyer
    Tested-by: Robert Hooker
    Tested-by: Keith Packard
    Signed-off-by: Jesse Barnes
    Signed-off-by: Keith Packard

    Keith Packard
     

17 Nov, 2011

1 commit

  • The panel power sequencing hardware tracks the stages of panel power
    sequencing and signals when the panel is completely on or off. Instead
    of blindly assuming the panel timings will work, poll the panel power
    status register until it shows the correct values.

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

    Keith Packard
     

08 Nov, 2011

2 commits


21 Oct, 2011

8 commits


06 Oct, 2011

1 commit

  • Store the panel power sequencing delays in the dp private structure,
    rather than the global device structure. Who knows, maybe we'll get
    more than one eDP device in the future.

    From the eDP spec, we need the following numbers:

    T1 + T3 Power on to Aux Channel operation (panel_power_up_delay)

    This marks how long it takes the panel to boot up and
    get ready to receive aux channel communications.

    T8 Video signal to backlight on (backlight_on_delay)

    Once a valid video signal is being sent to the device,
    it can take a while before the panel is actuall
    showing useful data. This delay allows the panel
    to get something reasonable up before the backlight
    is turned on.

    T9 Backlight off to video off (backlight_off_delay)

    Turning the backlight off can take a moment, so
    this delay makes sure there is still valid video
    data on the screen.

    T10 Video off to power off (panel_power_down_delay)

    Presumably this delay allows the panel to perform
    an orderly shutdown of the display.

    T11 + T12 Power off to power on (panel_power_cycle_delay)

    So, once you turn the panel off, you have to wait a
    while before you can turn it back on. This delay is
    usually the longest in the entire sequence.

    Neither the VBIOS source code nor the hardware documentation has a
    clear mapping between the delay values they provide and those required
    by the eDP spec. The VBIOS code actually uses two different labels for
    the delay values in the five words of the relevant VBT table.

    **** MORE LATER ***

    Look at both the current hardware register settings and the VBT
    specified panel power sequencing timings. Use the maximum of the two
    delays, to make sure things work reliably. If there is no VBT data,
    then those values will be initialized to zero, so we'll just use the
    values as programmed in the hardware. Note that the BIOS just fetches
    delays from the VBT table to place in the hardware registers, so we
    should get the same values from both places, except for rounding.

    VBT doesn't provide any values for T1 or T2, so we'll always just use
    the hardware value for that.

    The panel power up delay is thus T1 + T2 + T3, which should be
    sufficient in all cases.

    The panel power down delay is T1 + T2 + T12, using T1+T2 as a proxy
    for T11, which isn't available anywhere.

    For the backlight delays, the eDP spec says T6 + T8 is the delay from the
    end of link training to backlight on and T9 is the delay from
    backlight off until video off. The hardware provides a 'backlight on'
    delay, which I'm taking to be T6 + T8 while the VBT provides something
    called 'T7', which I'm assuming is s

    On the macbook air I'm testing with, this yields a power-up delay of
    over 200ms and a power-down delay of over 600ms. It all works now, but
    we're frobbing these power controls several times during mode setting,
    making the whole process take an awfully long time.

    Signed-off-by: Keith Packard

    Keith Packard
     

01 Oct, 2011

2 commits


22 Sep, 2011

2 commits

  • While I think the previous code is correct, it was hard to follow and
    hard to debug. Since we already have a ring abstraction, might as well
    use it to handle the semaphore updates and compares.

    I don't expect this code to make semaphores better or worse, but you
    never know...

    v2:
    Remove magic per Keith's suggestions.
    Ran Daniel's gem_ring_sync_loop test on this.

    v3:
    Ignored one of Keith's suggestions.

    v4:
    Removed some bloat per Daniel's recommendation.

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

    Ben Widawsky
     
  • Add ELD support for Intel Eaglelake, IbexPeak/Ironlake,
    SandyBridge/CougarPoint and IvyBridge/PantherPoint chips.

    ELD (EDID-Like Data) describes to the HDMI/DP audio driver the audio
    capabilities of the plugged monitor. It's built and passed to audio
    driver in 2 steps:

    (1) at get_modes time, parse EDID and save ELD to drm_connector.eld[]

    (2) at mode_set time, write drm_connector.eld[] to the Transcoder's hw
    ELD buffer and set the ELD_valid bit to inform HDMI/DP audio driver

    This patch is tested OK on G45/HDMI, IbexPeak/HDMI and IvyBridge/HDMI+DP.
    Test scheme: plug in the HDMI/DP monitor, and run

    cat /proc/asound/card0/eld*

    to check if the monitor name, HDMI/DP type, etc. show up correctly.

    Minor imperfection: the GEN5_AUD_CNTL_ST/DIP_Port_Select field always
    reads 0 (reserved). Without knowing the port number, I worked it around
    by setting the ELD_valid bit for ALL the three ports. It's tested to not
    be a problem, because the audio driver will find invalid ELD data and
    hence rightfully abort, even when it sees the ELD_valid indicator.

    Thanks to Zhenyu and Pierre-Louis for a lot of valuable help and testing.

    CC: Zhao Yakui
    CC: Wang Zhenyu
    CC: Jeremy Bush
    CC: Christopher White
    CC: Pierre-Louis Bossart
    CC: Paul Menzel
    Signed-off-by: Wu Fengguang
    Signed-off-by: Keith Packard

    Wu Fengguang
     

20 Sep, 2011

1 commit


20 Aug, 2011

1 commit

  • Prior to Ivybridge, the GFX_MODE would default to 0x800, meaning that
    MI_FLUSH would flush the TLBs in addition to the rest of the caches
    indicated in the MI_FLUSH command. However starting with Ivybridge, the
    register defaults to 0x2800 out of reset, meaning that to invalidate the
    TLB we need to use PIPE_CONTROL. Since we're not doing that yet, go
    back to the old default so things work.

    v2: don't forget to actually *clear* the new bit

    Reviewed-by: Eric Anholt
    Reviewed-by: Chris Wilson
    Tested-by: Kenneth Graunke
    Signed-off-by: Jesse Barnes

    Jesse Barnes
     

09 Aug, 2011

1 commit

  • CPT pipe select is different from previous generations (using two bits
    instead of one). All of the paths from intel_disable_pch_ports were
    not making this distinction.

    Mode setting with pipe A turned off would then also force all outputs
    on pipe B to get turned off as the disable code would mistakenly
    decide that all of these outputs were on pipe A and turn them off.

    This is an extension of the CPT DP disable fix (why didn't I fix this then?)

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

    Keith Packard
     

04 Aug, 2011

2 commits


30 Jul, 2011

3 commits


29 Jul, 2011

2 commits