Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 03 12月, 2014 3 次提交
  3. 20 11月, 2014 2 次提交
    • D
      drm/i915: Pin tiled objects for L-shaped configs · 656bfa3a
      由 Daniel Vetter 提交于 
      Let's just throw in the towel on this one and take the cheap way out.

Based on a patch from Chris Wilson, but checking for a different bit.
Chris' patch checked for even bank layout, this one here for a magic
bit. Given the evidence we've gathered (not much) both work I think,
but checking for the magic bit might be more accurate.

Anyway, works on my gm45 here.

For paranoi restrict to gen4 (and mobile), since we've only ever seen
this on gm45 and i965gm.

Also add some debugfs output so that we can skip the tiled swapping
tests properly in these cases.

v2: Clean up the quirk'ed pin count in free_object to avoid upsetting
the WARN_ON. Spotted by Chris.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=28813
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45092Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      656bfa3a
    • T
      drm/i915: Use efficient frequency for HSW/BDW · 93ee2920
      由 Tom O'Rourke 提交于 
      Added gen6_init_rps_frequencies() to initialize
the rps frequency values.  This function replaces
parse_rp_state_cap().  In addition to reading RPn,
RP0, and RP1 from RP_STATE_CAP register, the new
function reads efficient frequency (aka RPe) from
pcode for Haswell and Broadwell and sets the turbo
softlimits.  The turbo minimum frequency softlimit
is set to RPe for Haswell and Broadwell and to RPn
otherwise.

For RPe, the efficiency is based on the frequency/power
ratio (MHz/W); this is considering GT power and not
package power.  The efficent frequency is the highest
frequency for which the frequency/power ratio is within
some threshold of the highest frequency/power ratio.
A fixed decrease in frequency results in smaller
decrease in power at frequencies less than RPe than
at frequencies above RPe.

v2: Following suggestions from Chris Wilson and
Daniel Vetter to extend and rename parse_rp_state_cap
and to open-code a poorly named function.
Signed-off-by: NTom O'Rourke <Tom.O'Rourke@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
[danvet: Remove unused variables.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      93ee2920
  5. 18 11月, 2014 1 次提交
    • V
      drm/i915: Drop the HSW special case from __gen6_gt_wait_for_thread_c0() · eb88bd1b
      由 Ville Syrjälä 提交于 
      Bits [18:16] of GEN6_GT_THREAD_STATUS_REG have always had the same
meaning since SNB. So treating them as something special for HSW doesn't
make sense to me.

Also the bits *seem* to work exactly the same way on IVB, HSW GT2 and
HSW GT3. At least intel_reg_read gives the identical results on all
platforms with and without forcewake.

Also the HSW PM guide rev 0.99 (ww05 2013) doesn't say anything about
those bits. It just says to poll for bits [2:0]. As does the more recent
BDW PM guide.

So just drop the HSW special case and treat all platforms the same way.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Deepak S<deepak.s@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      eb88bd1b
  7. 17 11月, 2014 1 次提交
  9. 14 11月, 2014 8 次提交
  11. 08 11月, 2014 6 次提交
  13. 05 11月, 2014 2 次提交
    • V
      drm/i915: Add support for CHV pipe B sprite CSC · 6ca2aeb2
      由 Ville Syrjälä 提交于 
      CHV has a programmable CSC unit on the pipe B sprites. Program the unit
appropriately for BT.601 limited range YCbCr to full range RGB color
conversion. This matches the programming we currently do for sprites
on the other pipes and on other platforms.

It seems the CSC only works when the input data is YCbCr. For RGB
pixel formats it doesn't matter what we program into the CSC registers.
Doesn't make much sense to me especially since the register names give
the impression that RGB input data would also work. But that's how
it behaves here.

In the review discussions there's been some nice math to explain the
values obtained here. First about the YCbCr->RGB matrix:

"I had the RGB->YCbCr matrix, inverted it and the values came out. But they
should match the wikipedia article. Also keep in mind that the coefficients
are in .12 in fixed point format, hence we need a 1<<12 factor. So let's
try it:

Kb=.114
Kr=.299
(1<<12) * 255/219 ~= 4769
-(1<<12) * 255/112*(1-Kb)*Kb/(1-Kb-Kr) ~= -1605
-(1<<12) * 255/112*(1-Kr)*Kr/(1-Kb-Kr) ~= -3330
(1<<12) * 255/112*(1-Kr) ~= 6537
(1<<12) * 255/112*(1-Kb) ~= 8263

"Looks like the same values to me."

And then about the limits used for clamping:

"> where did you get these min/max?

"The hardware apparently deals in 10bit values, so we need to multiply everything
by 4 when we start with the 8bit min/max values.

Y = [16:235] * 4 = [64:940]
CbCr = ([16:240] - 128) * 4 = [-112:112] * 4 = [-448:448]

"The -128 being the -0.5 bias that the hardware already applied before
the data entered the CSC unit."

Raw data is also supplied in 10bpc in the registers.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by Rodrigo Vivi <rodrigo.vivi@intel.com>
[danvet: Copypaste explanations&math from the review discussion.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      6ca2aeb2
    • V
      drm/i915: Initialize new chv primary plane and pipe blender registers · c14b0485
      由 Ville Syrjälä 提交于 
      CHV adds a bunch of new registers for primary plane size/position and
pipe blender setup. Initialize all those registers to avoid nasty
surprises. PRIMSIZE is especially important as without programming it
the outout will be garbled whenever the primary plane size would not
match what the BIOS set up.

Also program the sprite constant alpha register to disable the constant
alpha blending factor. This applies to vlv as well as chv.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      c14b0485
  15. 24 10月, 2014 4 次提交
  17. 21 10月, 2014 1 次提交
  19. 03 10月, 2014 2 次提交
  21. 02 10月, 2014 1 次提交
  23. 01 10月, 2014 1 次提交
    • C
      drm/i915: Enable pixel replicated modes on BDW and HSW. · ebb69c95
      由 Clint Taylor 提交于 
      Haswell and later silicon has added a new pixel replication register
to the pipe timings for each transcoder. Now in addition to the
DPLL_A_MD register for the pixel clock double, we also need to write
to the TRANS_MULT_n (0x6002c) register to double the pixel data. Writing
to the DPLL only double the pixel clock.

ver2: Macro name change from MULTIPLY to PIPE_MULTI. (Daniel)
ver3: Do not set pixel multiplier if transcoder is eDP (Ville)
ver4: Macro name change to PIPE_MULT and default else pixel_multiplier

Cc: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: NClint Taylor <clinton.a.taylor@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Appease checkpatch and move one hunk back into the right
place that git am misplace!?]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      ebb69c95
  25. 30 9月, 2014 1 次提交
  27. 29 9月, 2014 1 次提交
  29. 24 9月, 2014 5 次提交
  31. 19 9月, 2014 1 次提交