Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 05 6月, 2020 1 次提交
  3. 04 6月, 2020 1 次提交
  5. 01 6月, 2020 1 次提交
  7. 20 5月, 2020 1 次提交
  9. 19 5月, 2020 2 次提交
    • V
      drm/i915: Read out hrawclk on all gen3+ platforms · 488e0179
      由 Ville Syrjälä 提交于 
      I've checked a bunch of gen3/4 machines and all seem to have
consistent FSB frequency information in the CLKCFG register.
So let's read out hrawclk on all gen3+ machines. Although
apart from g4x/pnv aux/pps dividers we only really need this
for for i965g/gm cs timestamp increment.

The CLKCFG memory clock values seem less consistent but we
don't care about those here.

For posterity here's a list of CLKCFG vs. FSB dumps from
a bunch of machines (only missing lpt for a full set):
machine CLKCFG     FSB
alv1    0x00001411 533
alv2    0x00000420 400 (Chris)
gdg1    0x20000022 800
gdg2    0x20000022 800
cst     0x00010043 666
blb     0x00002034 1333
pnv1    0x00000423 666
pnv2    0x00000433 666
965gm   0x00004342 800
946gz   0x00000022 800
965g    0x00000422 800
g35     0x00000430 1066
        0x00000434 1333
ctg1    0x00644056 1066
ctg2    0x00644066 1066
elk1    0x00012420 1066
        0x00012424 1333
        0x00012436 1600
        0x00012422 800
elk2    0x00012040 1066

For the mobile parts the chipset docs generally have these
documented to some degree (alv being the exception).

The two settings w/o any evidence are 0x5=400MHz on desktop
and 0x7=1333MHz on mobile. Though the mobile 1333MHz case
probably doesn't even exist since ctg is only documented
to go up to 1066MHz.

v2: Fix 400mhz readout for Chris's alv/celeron machine
    Do a clean mobile vs. dekstop split since that's really
    what seems to be going on

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200514123838.3017-3-ville.syrjala@linux.intel.comAcked-by: NChris Wilson <chris@chris-wilson.co.uk>
      488e0179
    • V
      drm/i915: Fix 400 MHz FSB readout on elk · 6f62bda1
      由 Ville Syrjälä 提交于 
      Looks like elk redefines some of the CLKCFG FSB values to
make room for 400 MHz FSB. The setting overlaps with one of
the 266MHz settings (which is even documented in the ctg docs,
and cofirmed to be correct on my ctg). So we limit the special
case to elk only.

Though it might also be that we have some kind of desktop vs.
mobile difference going on here as eg. both g35 and elk
use 0x0 for the 266 MHz setting, vs. 0x6 used by ctg). The
g35 doesn't let me select 400MHz for the FSB strap so can't
confirm which way it would go here. But anyways as it seems
only elk has the 400MHz option we shouldn't lose anything
by limiting the special case to it alone.

My earlier experiments on this appear to have been nonsense as
the comment I added claims that FSB strap of 400MHz results in
a value of 0x4, but I've now retested it and I definitely get a
value of 0x6 instead. So let's remove that bogus comment.

v2: s/_ELK/_ALT/ in the define in anticipation of a full
    mobile vs. desktop CLKCFG split
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200514123838.3017-1-ville.syrjala@linux.intel.comAcked-by: NChris Wilson <chris@chris-wilson.co.uk>
      6f62bda1
  11. 08 5月, 2020 1 次提交
  13. 07 5月, 2020 1 次提交
  15. 06 5月, 2020 1 次提交
  17. 05 5月, 2020 1 次提交
  19. 30 4月, 2020 1 次提交
  21. 26 4月, 2020 1 次提交
  23. 25 4月, 2020 1 次提交
  25. 21 4月, 2020 1 次提交
  27. 20 4月, 2020 1 次提交
  29. 18 4月, 2020 2 次提交
    • J
      drm/i915/tc/tgl: Implement TC cold sequences · 3c02934b
      由 José Roberto de Souza 提交于 
      TC ports can enter in TCCOLD to save power and is required to request
to PCODE to exit this state before use or read to TC registers.

For TGL there is a new MBOX command to do that with a parameter to ask
PCODE to exit and block TCCOLD entry or unblock TCCOLD entry.

So adding a new power domain to reuse the refcount and only allow
TC cold when all TC ports are not in use.

v2:
- fixed missing case in intel_display_power_domain_str()
- moved tgl_tc_cold_request to intel_display_power.c
- renamed TGL_TC_COLD_OFF to TGL_TC_COLD_OFF_POWER_DOMAINS
- added all TC and TBT aux power domains to
TGL_TC_COLD_OFF_POWER_DOMAINS

v3:
- added one msec sleep when PCODE returns -EAGAIN
- added timeout of 5msec to not loop forever if
sandybridge_pcode_write_timeout() keeps returning -EAGAIN

v4:
- Made failure to block or unblock TC cold a error
- removed 5msec timeout, instead giving PCODE 1msec by up 3 times to
recover from the internal error

v5:
- only sleeping 1msec when ret is -EAGAIN

BSpec: 49294
Cc: Imre Deak <imre.deak@intel.com>
Cc: Cooper Chiou <cooper.chiou@intel.com>
Cc: Kai-Heng Feng <kai.heng.feng@canonical.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200414194956.164323-6-jose.souza@intel.com
      3c02934b
    • J
      drm/i915/tc/icl: Implement TC cold sequences · feb7e0ef
      由 José Roberto de Souza 提交于 
      This is required for legacy/static TC ports as IOM is not aware of
the connection and will not trigger the TC cold exit.

Just request PCODE to exit TCCOLD is not enough as it could enter
again before driver makes use of the port, to prevent it BSpec states
that aux powerwell should be held.

So here embedding the TC cold exit sequence into ICL aux enable,
it will enable aux and then request TC cold to exit.

The TC cold block(exit and aux hold) and unblock was added to some
exported TC functions for the others and to access PHY registers,
callers should enable and keep aux powerwell enabled during access.

Also adding TC cold check and warnig in tc_port_load_fia_params() as
at this point of the driver initialization we can't request power
wells, if we get this warning we will need to figure out how to handle
it.

v2:
- moved ICL TC cold exit function to intel_display_power
- using dig_port->tc_legacy_port to only execute sequences for legacy
ports, hopefully VBTs will have this right
- fixed check to call _hsw_power_well_continue_enable()
- calling _hsw_power_well_continue_enable() unconditionally in
icl_tc_phy_aux_power_well_enable(), if needed we will surpress timeout
warnings of TC legacy ports
- only blocking TC cold around fia access

v3:
- added timeout of 5msec to not loop forever if
sandybridge_pcode_write_timeout() keeps returning -EAGAIN
returning -EAGAIN in in icl_tc_cold_exit()
- removed leftover tc_cold_wakeref
- added one msec sleep when PCODE returns -EAGAIN

v4:
- removed 5msec timeout, instead giving 1msec to whoever is using
PCODE to finish it up to 3 times
- added a comment about turn TC cold exit failure as a error in future

BSpec: 21750
Closes: https://gitlab.freedesktop.org/drm/intel/issues/1296
Cc: Imre Deak <imre.deak@intel.com>
Cc: Cooper Chiou <cooper.chiou@intel.com>
Cc: Kai-Heng Feng <kai.heng.feng@canonical.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200414194956.164323-4-jose.souza@intel.com
      feb7e0ef
  31. 17 4月, 2020 1 次提交
  33. 16 4月, 2020 1 次提交
  35. 08 4月, 2020 1 次提交
  37. 07 4月, 2020 1 次提交
    • C
      drm/i915/gt: Yield the timeslice if caught waiting on a user semaphore · c4e8ba73
      由 Chris Wilson 提交于 
      If we find ourselves waiting on a MI_SEMAPHORE_WAIT, either within the
user batch or in our own preamble, the engine raises a
GT_WAIT_ON_SEMAPHORE interrupt. We can unmask that interrupt and so
respond to a semaphore wait by yielding the timeslice, if we have
another context to yield to!

The only real complication is that the interrupt is only generated for
the start of the semaphore wait, and is asynchronous to our
process_csb() -- that is, we may not have registered the timeslice before
we see the interrupt. To ensure we don't miss a potential semaphore
blocking forward progress (e.g. selftests/live_timeslice_preempt) we mark
the interrupt and apply it to the next timeslice regardless of whether it
was active at the time.

v2: We use semaphores in preempt-to-busy, within the timeslicing
implementation itself! Ergo, when we do insert a preemption due to an
expired timeslice, the new context may start with the missed semaphore
flagged by the retired context and be yielded, ad infinitum. To avoid
this, read the context id at the time of the semaphore interrupt and
only yield if that context is still active.

Fixes: 8ee36e04 ("drm/i915/execlists: Minimalistic timeslicing")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200407130811.17321-1-chris@chris-wilson.co.uk
      c4e8ba73
  39. 04 4月, 2020 1 次提交
  41. 28 3月, 2020 2 次提交
  43. 20 3月, 2020 1 次提交
  45. 18 3月, 2020 2 次提交
  47. 14 3月, 2020 2 次提交
  49. 12 3月, 2020 1 次提交
  51. 10 3月, 2020 1 次提交
  53. 03 3月, 2020 2 次提交
  55. 02 3月, 2020 1 次提交
  57. 28 2月, 2020 2 次提交
  59. 22 2月, 2020 1 次提交
  61. 21 2月, 2020 2 次提交
  63. 08 2月, 2020 1 次提交