Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 13 6月, 2017 7 次提交
  3. 07 6月, 2017 3 次提交
  5. 03 6月, 2017 2 次提交
    • R
      drm/i915/cnp: add CNP gmbus support · 3d02352c
      由 Rodrigo Vivi 提交于 
      On CNP PCH based platforms the gmbus is on the south display that
is on PCH. The existing implementation for previous platforms
already covers the need for CNP expect for the pin pair configuration
that follows similar definitions that we had on BXT.

v2: Don't drop "_BXT" as the indicator of the first platform
    supporting this pin numbers. Suggested by Daniel.
v3: Add missing else and fix register table since CNP GPIO_CTL
    starts on 0xC5014.
v4: Fix pin number and map according to the current available VBT.
    Re-add pin 4 for port D. Lost during some rebase.
v5: Use table as spec. If VBT is wrong it should be ignored.

Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NAnusha Srivatsa <anusha.srivatsa@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1496434004-29812-5-git-send-email-rodrigo.vivi@intel.com
      3d02352c
    • R
      drm/i915/cnp: Get/set proper Raw clock frequency on CNP. · 9d81a997
      由 Rodrigo Vivi 提交于 
      RAWCLK_FREQ register has changed for platforms with CNP+.

[29:26] This field provides the denominator for the fractional
	part of the microsecond counter divider.  The numerator
	is fixed at 1. Program this field to the denominator of
	the fractional portion of reference frequency minus one.
	If the fraction is 0, program to 0.
	0100b = Fraction .2 MHz = Fraction 1/5.
	0000b = Fraction .0 MHz.

[25:16] This field provides the integer part of the microsecond
	counter divider. Program this field to the integer portion
	of the reference frequenct minus one.

Also this register tells us that proper raw clock should be read
from SFUSE_STRAP and programmed to this register. Up to this point
on other platforms we are reading instead of programming it so
probably relying on whatever BIOS had configured here.

Now on let's follow the spec and also program this register
fetching the right value from SFUSE_STRAP as Spec tells us to do.

v2: Read from SFUSE_STRAP and Program RAWCLK_FREQ instead of
    reading the value relying someone else will program that
    for us.
v3: Add missing else. (Jani)
v4: Addressing all Ville's catches:
    Use macro for shift bits instead of defining shift.
    Remove shift from the cleaning bits with mask that already
    has it.
    Add missing I915_WRITE to actually write the reg.
    Stop using useless DIV_ROUND_* on divider that is exact
    dividion and use DIV_ROUND_CLOSEST for the fraction part.
v5: Remove useless Read-Modify-Write on raclk_freq reg. (Ville).
v6: Change is per PCH instead of per platform.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1496434004-29812-3-git-send-email-rodrigo.vivi@intel.com
      9d81a997
  7. 30 5月, 2017 1 次提交
  9. 18 5月, 2017 1 次提交
  11. 15 5月, 2017 1 次提交
    • V
      drm/i915: Fix rawclk readout for g4x · 82f2b4ac
      由 Ville Syrjälä 提交于 
      Turns out our skills in decoding the CLKCFG register weren't good
enough. On this particular elk the answer we got was 400 MHz when
in reality the clock was running at 266 MHz, which then caused us
to program a bogus AUX clock divider that caused all AUX communication
to fail.

Sadly the docs are now in bit heaven, so the fix will have to be based
on empirical evidence. Using another elk machine I was able to frob
the FSB frequency from the BIOS and see how it affects the CLKCFG
register. The machine seesm to use a frequency of 266 MHz by default,
and fortunately it still boot even with the 50% CPU overclock that
we get when we bump the FSB up to 400 MHz.

It turns out the actual FSB frequency and the register have no real
link whatsoever. The register value is based on some straps or something,
but fortunately those too can be configured from the BIOS on this board,
although it doesn't seem to respect the settings 100%. In the end I was
able to derive the following relationship:

BIOS FSB / strap | CLKCFG
-------------------------
200              | 0x2
266              | 0x0
333              | 0x4
400              | 0x4

So only the 200 and 400 MHz cases actually match how we're currently
decoding that register. But as the comment next to some of the defines
says, we have been just guessing anyway.

So let's fix things up so that at least the 266 MHz case will work
correctly as that is actually the setting used by both the buggy
machine and my test machine.

The fact that 333 and 400 MHz BIOS settings result in the same register
value is a little disappointing, as that means we can't tell them apart.
However, according to the gmch datasheet for both elk and ctg 400 Mhz is
not even a supported FSB frequency, so I'm going to make the assumption
that we should decode it as 333 MHz instead.

Cc: stable@vger.kernel.org
Cc: Tomi Sarvela <tomi.p.sarvela@intel.com>
Reported-by: NTomi Sarvela <tomi.p.sarvela@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100926Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170504181530.6908-1-ville.syrjala@linux.intel.comAcked-by: NJani Nikula <jani.nikula@intel.com>
Tested-by: NTomi Sarvela <tomi.p.sarvela@intel.com>
(cherry picked from commit 6f38123e)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      82f2b4ac
  13. 11 5月, 2017 1 次提交
    • V
      drm/i915: Support variable cursor height on ivb+ · 024faac7
      由 Ville Syrjälä 提交于 
      IVB introduced the CUR_FBC_CTL register which allows reducing the cursor
height down to 8 lines from the otherwise square cursor dimensions.
Implement support for it. CUR_FBC_CTL can't be used when the cursor
is rotated.

Commandeer the otherwise unused cursor->cursor.size to track the
current value of CUR_FBC_CTL to optimize away redundant CUR_FBC_CTL
writes, and to notice when we need to arm the update via CURBASE if
just CUR_FBC_CTL changes.

v2: Reverse the gen check to make it sane
v3: Only enable CUR_FBC_CTL when cursor is enabled, adapt to
    earlier code changes which means we now actually turn off
    the cursor when we're supposed to unlike v2
v4: Add a comment about rotation vs. CUR_FBC_CTL,
    rebase due to 'dirty' (Chris)
v5: Rebase to the atomic world
    Handle 180 degree rotation
    Add HAS_CUR_FBC()
v6: Rebase
v7: Rebase due to I915_WRITE_FW/uncore.lock
    s/size/fbc_ctl/
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170327185546.2977-12-ville.syrjala@linux.intel.comReviewed-by: NImre Deak <imre.deak@intel.com>
      024faac7
  15. 10 5月, 2017 1 次提交
  17. 06 5月, 2017 1 次提交
    • V
      drm/i915: Fix rawclk readout for g4x · 6f38123e
      由 Ville Syrjälä 提交于 
      Turns out our skills in decoding the CLKCFG register weren't good
enough. On this particular elk the answer we got was 400 MHz when
in reality the clock was running at 266 MHz, which then caused us
to program a bogus AUX clock divider that caused all AUX communication
to fail.

Sadly the docs are now in bit heaven, so the fix will have to be based
on empirical evidence. Using another elk machine I was able to frob
the FSB frequency from the BIOS and see how it affects the CLKCFG
register. The machine seesm to use a frequency of 266 MHz by default,
and fortunately it still boot even with the 50% CPU overclock that
we get when we bump the FSB up to 400 MHz.

It turns out the actual FSB frequency and the register have no real
link whatsoever. The register value is based on some straps or something,
but fortunately those too can be configured from the BIOS on this board,
although it doesn't seem to respect the settings 100%. In the end I was
able to derive the following relationship:

BIOS FSB / strap | CLKCFG
-------------------------
200              | 0x2
266              | 0x0
333              | 0x4
400              | 0x4

So only the 200 and 400 MHz cases actually match how we're currently
decoding that register. But as the comment next to some of the defines
says, we have been just guessing anyway.

So let's fix things up so that at least the 266 MHz case will work
correctly as that is actually the setting used by both the buggy
machine and my test machine.

The fact that 333 and 400 MHz BIOS settings result in the same register
value is a little disappointing, as that means we can't tell them apart.
However, according to the gmch datasheet for both elk and ctg 400 Mhz is
not even a supported FSB frequency, so I'm going to make the assumption
that we should decode it as 333 MHz instead.

Cc: stable@vger.kernel.org
Cc: Tomi Sarvela <tomi.p.sarvela@intel.com>
Reported-by: NTomi Sarvela <tomi.p.sarvela@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100926Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170504181530.6908-1-ville.syrjala@linux.intel.comAcked-by: NJani Nikula <jani.nikula@intel.com>
Tested-by: NTomi Sarvela <tomi.p.sarvela@intel.com>
      6f38123e
  19. 28 4月, 2017 1 次提交
    • J
      drm/i915: Sanitize engine context sizes · 63ffbcda
      由 Joonas Lahtinen 提交于 
      Pre-calculate engine context size based on engine class and device
generation and store it in the engine instance.

v2:
- Squash and get rid of hw_context_size (Chris)

v3:
- Move after MMIO init for probing on Gen7 and 8 (Chris)
- Retained rounding (Tvrtko)
v4:
- Rebase for deferred legacy context allocation
Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Oscar Mateo <oscar.mateo@intel.com>
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Cc: intel-gvt-dev@lists.freedesktop.org
Acked-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      63ffbcda
  21. 11 4月, 2017 1 次提交
  23. 28 3月, 2017 1 次提交
    • S
      drm/i915: enable scrambling · 15953637
      由 Shashank Sharma 提交于 
      Geminilake platform sports a native HDMI 2.0 controller, and is
capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec
mendates scrambling for these higher clocks, for reduced RF footprint.

This patch checks if the monitor supports scrambling, and if required,
enables it during the modeset.

V2: Addressed review comments from Ville:
 - Do not track scrambling status in DRM layer, track somewhere in
   driver like in intel_crtc_state.
 - Don't talk to monitor at such a low layer, set monitor scrambling
   in intel_enable_ddi() before enabling the port.

V3: Addressed review comments from Jani
 - In comments, function names, use "sink" instead of "monitor",
   so that the implementation could be close to the language of
   HDMI spec.

V4: Addressed review comment from Maarten
 - scrambling -> hdmi_scrambling
 - high_tmds_clock_ratio -> hdmi_high_tmds_clock_ratio

V5: Addressed review comments from Ville and Ander
 - Do not modifiy the crtc_state after compute_config. Move all
   scrambling and tmds_clock_ratio calcutations to compute_config.
 - While setting scrambling for source/sink, do not check the
   conditions again, just go by the crtc_state flags. This will
   simplyfy the condition checks.

V6: Addressed review comments from Ville
 - Do not add IS_GLK check in disable/enable function, instead add it
   in compute_config, while setting state flags.
 - Remove unnecessary paranthesis.
 - Simplyfy handle_sink_scrambling function as suggested.
 - Add readout code for scrambling status in get_ddi_config and add a
   check for the same in pipe_config_compare.

V7: Addressed review comments from Ander/Ville
 - No separate function for source scrambling, make it inline
 - Align the last line of the macro TRANS_DDI_HDMI_SCRAMBLING_MASK
 - Do not add platform check while setting source scrambling
 - Use pipe_config instead of crtc->config to set sink scrambling
 - To readout scrambling status, Compare with SCRAMBLING_MASK
   not any of its bits
 - Remove platform check in intel_pipe_config_compare while checking
   scrambling status

V8: Fixed mege conflict, Addressed review comments from Ander
 - Remove the desciption/comment about scrambling fom the caller, move
   it to the function
 - Move the IS_GLK check into scrambling function
 - Fix alignment

V9: Fixed review comments from Ville, Ander
 - Pass the scrambling state variables as bool input to the sink_scrambling
   function and let the disable call be unconditional.
 - Fix alignments in function calls and debug messages.
 - Add kernel doc for function intel_hdmi_handle_sink_scrambling

V10: Rebase
Signed-off-by: NShashank Sharma <shashank.sharma@intel.com>
Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1489404244-16608-6-git-send-email-shashank.sharma@intel.com
      15953637
  25. 16 3月, 2017 1 次提交
    • M
      drm/i915: Use ktime to calculate rc0 residency · 679cb6c1
      由 Mika Kuoppala 提交于 
      We have used cz timestamp register to gain a reference time wrt
to residency calculations. The residency counts are in cz clk ticks
(333Mhz clock) but for some reason the cz timestamp register gives
100us units. Perhaps for some other usage, the base-ten based values
are easier, but in residency calculations raw units would have been
the easiest.

As there is not much advantage of using base-ten clock through
a more costly punit access, take our reference times directly from
kernel clock.

v2: use ktime (Chris, Ville)

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      679cb6c1
  27. 13 3月, 2017 1 次提交
  29. 09 3月, 2017 1 次提交
  31. 04 3月, 2017 1 次提交
  33. 01 3月, 2017 1 次提交
  35. 28 2月, 2017 3 次提交
  37. 27 2月, 2017 1 次提交
  39. 16 2月, 2017 1 次提交
  41. 10 2月, 2017 1 次提交
  43. 08 2月, 2017 2 次提交
  45. 03 2月, 2017 1 次提交
    • T
      drm/i915: Enable VLV audio chicken bit for LPE audio · 9db13e5f
      由 Takashi Iwai 提交于 
      The audio chicken bit (register offset 0x62f38) seems required to make
DP audio working on some machines.  At least, on Dell Wyse 3040, I
failed to get the audio unless this bit is set once.

Strangely, the bit seems necessary only once, and it persists after
that, even some power-off cycles.  The register is supposedly
write-only, so it's no evidence whether the bit keeps effect
persistently.  But, judging from the experiment, it looks enough to
set it up once at the device initialization.

The patch is basically a cut from the original patch by Pierre-Louis
Bossart.

v1->v2: drop read since it's a write-only reg.

Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      9db13e5f
  47. 01 2月, 2017 2 次提交
  49. 31 1月, 2017 1 次提交
  51. 30 1月, 2017 2 次提交