Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 10 6月, 2017 1 次提交
  3. 09 6月, 2017 2 次提交
  5. 07 6月, 2017 4 次提交
  7. 30 5月, 2017 1 次提交
  9. 28 4月, 2017 1 次提交
    • J
      drm/i915: Eliminate HAS_HW_CONTEXTS · f2e4d76e
      由 Joonas Lahtinen 提交于 
      HAS_HW_CONTEXTS is misleading condition for GPU reset and CCID,
replace it with Gen specific (to be updated in next patches).

HAS_HW_CONTEXTS in i915_l3_write is bogus because each HAS_L3_DPF
match also has .has_hw_contexts = 1 set.

This leads to us being able to get rid of the property completely.

v2:
- Keep the checks at Gen6 for no functional change (Ville)
Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      f2e4d76e
  11. 29 3月, 2017 1 次提交
  13. 27 3月, 2017 1 次提交
  15. 14 2月, 2017 1 次提交
    • C
      drm/i915: Provide a hook for selftests · 953c7f82
      由 Chris Wilson 提交于 
      Some pieces of code are independent of hardware but are very tricky to
exercise through the normal userspace ABI or via debugfs hooks. Being
able to create mock unit tests and execute them through CI is vital.
Start by adding a central point where we can execute unit tests and
a parameter to enable them. This is disabled by default as the
expectation is that these tests will occasionally explode.

To facilitate integration with igt, any parameter beginning with
i915.igt__ is interpreted as a subtest executable independently via
igt/drv_selftest.

Two classes of selftests are recognised: mock unit tests and integration
tests. Mock unit tests are run as soon as the module is loaded, before
the device is probed. At that point there is no driver instantiated and
all hw interactions must be "mocked". This is very useful for writing
universal tests to exercise code not typically run on a broad range of
architectures. Alternatively, you can hook into the live selftests and
run when the device has been instantiated - hw interactions are real.

v2: Add a macro for compiling conditional code for mock objects inside
real objects.
v3: Differentiate between mock unit tests and late integration test.
v4: List the tests in natural order, use igt to sort after modparam.
v5: s/late/live/
v6: s/unsigned long/unsigned int/
v7: Use igt_ prefixes for long helpers.
v8: Deobfuscate macros overriding functions, stop using -I$(src)
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170213171558.20942-1-chris@chris-wilson.co.uk
      953c7f82
  17. 30 1月, 2017 1 次提交
  19. 05 1月, 2017 1 次提交
    • P
      drm/i915: actually drive the BDW reserved IDs · 98b2f01c
      由 Paulo Zanoni 提交于 
      Back in 2014, commit fb7023e0 ("drm/i915: BDW: Adding Reserved PCI
IDs.") added the reserved PCI IDs in order to try to make sure we had
working drivers in case we ever released products using these IDs
(since we had instances of this type of problem in the past). The
problem is that the patch only touched the macros used by
early-quirks.c and by the user space components that rely on
i915_pciids.h, it didn't touch the macros used by i915_pci.c. So we
correctly handled the stolen memory for these theoretical IDs, but we
didn't actually drive the devices from i915.ko.

So this patch fixes the original commit by actually making i915.ko
drive these IDs, which was the goal. There's no information on what
would be the GT count on these IDs, so we just go with the safer
intel_broadwell_info, at the risk of ignoring a possibly inexistent
BSD2_RING.

I did some checking, and it seems that these IDs are driven by
intel-gpu-tools, xf86-video-intel and libdrm (since they contain old
copies of i915_pciids.h), but they are not checked by mesa.

The alternative to this patch would be to just assume we're actually
never going to use these IDs, and then remove them from our ID lists
and make sure our user space components sync the latest i915_pciids.h
copy. I'm fine with either approaches, as long as we make sure that
every component tries to drive the same list of PCI IDs.

Fixes: fb7023e0 ("drm/i915: BDW: Adding Reserved PCI IDs.")
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Ben Widawsky <ben@bwidawsk.net>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1483473860-17644-3-git-send-email-paulo.r.zanoni@intel.com
      98b2f01c
  21. 21 12月, 2016 1 次提交
  23. 20 12月, 2016 1 次提交
  25. 08 12月, 2016 1 次提交
  27. 07 12月, 2016 6 次提交
  29. 01 12月, 2016 4 次提交
  31. 16 11月, 2016 1 次提交
    • P
      drm/i915/bxt: Broxton decoupled MMIO · 85ee17eb
      由 Praveen Paneri 提交于 
      Decoupled MMIO is an alternative way to access forcewake domain
registers, which requires less cycles for a single read/write and
avoids frequent software forcewake.
This certainly gives advantage over the forcewake as this new
mechanism “decouples” CPU cycles and allow them to complete even
when GT is in a CPD (frequency change) or C6 state.

This can co-exist with forcewake and we will continue to use forcewake
as appropriate. E.g. 64-bit register writes to avoid writing 2 dwords
separately and land into funny situations.

v2:
- Moved platform check out of the function and got rid of duplicate
 functions to find out decoupled power domain (Chris)
- Added a check for forcewake already held and skipped decoupled
 access (Chris)
- Skipped writing 64 bit registers through decoupled MMIO (Chris)

v3:
- Improved commit message with more info on decoupled mmio (Tvrtko)
- Changed decoupled operation to enum and used u32 instead of
 uint_32 data type for register offset (Tvrtko)
- Moved HAS_DECOUPLED_MMIO to device info (Tvrtko)
- Added lookup table for converting fw_engine to pd_engine (Tvrtko)
- Improved __gen9_decoupled_read and __gen9_decoupled_write
 routines (Tvrtko)

v4:
- Fixed alignment and variable names (Chris)
- Write GEN9_DECOUPLED_REG0_DW1 register in just one go (Zhe Wang)

v5:
- Changed HAS_DECOUPLED_MMIO() argument name to dev_priv (Tvrtko)
- Sanitize info->had_decoupled_mmio at init (Chris)
Signed-off-by: NZhe Wang <zhe1.wang@intel.com>
Signed-off-by: NPraveen Paneri <praveen.paneri@intel.com>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1479230360-22395-1-git-send-email-praveen.paneri@intel.com
      85ee17eb
  33. 14 11月, 2016 1 次提交
    • J
      drm/i915: rename preliminary_hw_support to alpha_support · c007fb4a
      由 Jani Nikula 提交于 
      The term "preliminary hardware support" has always caused confusion both
among users and developers. It has always been about preliminary driver
support for new hardware, and not so much about preliminary hardware. Of
course, initially both the software and hardware are in early stages,
but the distinction becomes more clear when the user picks up production
hardware and an older kernel to go with it, with just the early support
we had for the hardware at the time the kernel was released. The user
has to specifically enable the alpha quality *driver* support for the
hardware in that specific kernel version.

Rename preliminary_hw_support to alpha_support to emphasize that the
module parameter, config option, and flag are about software, not about
hardware. Improve the language in help texts and debug logging as well.

This appears to be a good time to do the change, as there are currently
no platforms with preliminary^W alpha support.

Cc: Rob Clark <robdclark@gmail.com>
Cc: Dave Airlie <airlied@gmail.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1477909108-18696-1-git-send-email-jani.nikula@intel.com
      c007fb4a
  35. 03 11月, 2016 1 次提交
  37. 28 10月, 2016 1 次提交
  39. 22 9月, 2016 1 次提交
  41. 15 9月, 2016 1 次提交
  43. 08 9月, 2016 7 次提交