The list is perpetually out of date, but giving an idea of what the
dependencies are is helpful.
Signed-off-by: Jani Nikula
---
README | 2 ++
1 file changed, 2 insertions(+)
diff --git a/README b/README
index d302af3f15dd..78a0a244d0ba 100644
--- a/README
+++ b/README
@@ -136,7 +136,9 @@ every
On Mon, 05 Dec 2016, Tomeu Vizoso wrote:
> The kernel has now a new debugfs ABI that can also allow capturing frame
> CRCs for drivers other than i915.
>
> Add alternative codepaths so the new ABI is used if the kernel is recent
> enough, and fall back to the legacy ABI if not.
>
> Signed-off-by:
This patch shouldn't impact on platforms that have non-zero num_pipes. The
warning happened to snb, which has non-zero num_pipes according to dmesg log
"[drm:intel_modeset_init [i915]] 2 display pipes available" in
https://intel-gfx-ci.01.org/CI/Patchwork_3383/fi-snb-2520m/dmesg-before.log. So
From: Elaine Wang
when num_pipes is zero, it indicates display doesn't exist, so there
is no need to initialize display hooks. And to avoid calling these
uninitialized display hooks, respect num_pipes at the beginning of
intel_modeset_init_hw.
intel_init_pm() calls FBC init function and then ini
On Thu, 2016-12-22 at 16:33 +0200, Ville Syrjälä wrote:
> On Thu, Dec 22, 2016 at 04:14:40PM +0200, Ander Conselvan De Oliveira wrote:
> >
> > On Mon, 2016-12-19 at 19:28 +0200, ville.syrj...@linux.intel.com wrote:
> > >
> > > From: Ville Syrjälä
> > >
> > > Introduce intel_cdclk state which fo
HI,
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Wang, Elaine
> Sent: Friday, December 23, 2016 11:04 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Respect num_pipes
> when in
== Series Details ==
Series: drm/i915: Check num_pipes before initializing or calling display hooks
URL : https://patchwork.freedesktop.org/series/17173/
State : success
== Summary ==
Series 17173v1 drm/i915: Check num_pipes before initializing or calling display
hooks
https://patchwork.freed
On Mon, 2016-12-19 at 19:28 +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> The current dev_cdclk vs. cdclk vs. atomic_cdclk_freq is quite a mess.
> So here I'm introducing the "actual" and "logical" naming for our
> cdclk state. "actual" is what we'll bash into the hardware
On Mon, 2016-12-19 at 19:28 +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Clean up the dev vs. dev_priv straggles that are making things
> look inconsistentt.
>
> v2: Deal with churn
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Ander Conselvan de Oliveira
> ---
> d
Ville pointed out that intel_fbc_choose_crtc() is iterating over all
planes instead of just the primary planes. There are no real
consequences of this problem for HSW+, and for the other platforms it
just means that in some obscure multi-screen cases we'll keep FBC
disabled when we could have enabl
Gen9+ platforms have been seeing a lot of screen flickerings and
underruns, so I never felt comfortable in enabling FBC on these
platforms since I didn't want to throw yet another feature on top of
the already complex problem. We now have code that automatically
disables FBC if we ever get an under
On Fri, Dec 23, 2016 at 11:09:22AM +0200, Ander Conselvan De Oliveira wrote:
> On Thu, 2016-12-22 at 16:33 +0200, Ville Syrjälä wrote:
> > On Thu, Dec 22, 2016 at 04:14:40PM +0200, Ander Conselvan De Oliveira wrote:
> > >
> > > On Mon, 2016-12-19 at 19:28 +0200, ville.syrj...@linux.intel.com wrote
On Fri, Dec 23, 2016 at 10:23:59AM -0200, Paulo Zanoni wrote:
> Ville pointed out that intel_fbc_choose_crtc() is iterating over all
> planes instead of just the primary planes. There are no real
> consequences of this problem for HSW+, and for the other platforms it
> just means that in some obscu
== Series Details ==
Series: series starting with [1/2] drm/i915: enable FBC on gen9+ too
URL : https://patchwork.freedesktop.org/series/17176/
State : warning
== Summary ==
Series 17176v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/17176/revisions/1/mbox/
Tes
On Fri, 2016-12-23 at 14:27 +0200, Ville Syrjälä wrote:
> On Fri, Dec 23, 2016 at 11:09:22AM +0200, Ander Conselvan De Oliveira wrote:
> >
> > On Thu, 2016-12-22 at 16:33 +0200, Ville Syrjälä wrote:
> > >
> > > On Thu, Dec 22, 2016 at 04:14:40PM +0200, Ander Conselvan De Oliveira
> > > wrote:
> >
On Thu, 22 Dec 2016, Madhav Chauhan wrote:
> From: Vincente Tsou
>
> The upper bits of the vsync width, vsync offset and hsync width
> were not parsed from the VBT. Parse these fields in this patch.
>
> V2: Renamed lvds dvo timing structure members and code identation
> fix (Jani's review comment
Em Sex, 2016-12-23 às 14:43 +0200, Ville Syrjälä escreveu:
> On Fri, Dec 23, 2016 at 10:23:59AM -0200, Paulo Zanoni wrote:
> >
> > Ville pointed out that intel_fbc_choose_crtc() is iterating over
> > all
> > planes instead of just the primary planes. There are no real
> > consequences of this prob
On Thu, 22 Dec 2016, vathsala nagaraju wrote:
> PSR2 vsc revision number hb2( as per table 6-11)is updated to
> 4 or 5 based on Y cordinate and Colorimetry Format as below
> 04h = 3D stereo + PSR/PSR2 + Y-coordinate.
> 05h = -3D stereo- + PSR/PSR2 + Y-coordinate + Pixel Encoding/Colorimetry
> Form
On Thu, 01 Dec 2016, Hans de Goede wrote:
> On enable intel_dsi_enable() directly calls intel_enable_dsi_pll(),
> make intel_dsi_disable() also directly call intel_disable_dsi_pll(),
> rather then hiding the call in intel_dsi_clear_device_ready(),
> no functional changes.
>
> Signed-off-by: Hans d
On Fri, Dec 23, 2016 at 11:23:56AM -0200, Paulo Zanoni wrote:
> Em Sex, 2016-12-23 às 14:43 +0200, Ville Syrjälä escreveu:
> > On Fri, Dec 23, 2016 at 10:23:59AM -0200, Paulo Zanoni wrote:
> > >
> > > Ville pointed out that intel_fbc_choose_crtc() is iterating over
> > > all
> > > planes instead o
On Mon, 2016-12-19 at 19:28 +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Rather than passing all the different parameters (cdclk,vco so
> far) sparately to the set_cdclk() functions, just pass the
> entire cdclk state.
>
> v2: Deal with churn
>
> Signed-off-by: Ville Sy
On Mon, 2016-12-19 at 19:28 +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Move the vlv_program_pfi_credits() into vlv_set_cdclk() and
> chv_set_cdclk() so that we can neuter vlv_modeset_commit_cdclk().
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_
On Mon, 2016-12-19 at 19:28 +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> The hack to grab the pipe A power domain around VLV/CHV cdclk
> programming has surely outlived its usefulness. We should be
> hold sufficient power domains during any modeset, so let's just
hold/be
On Thu, 15 Dec 2016, Madhav Chauhan wrote:
> From: Deepak M
>
> v2: Addressed Jani's Review comments (renamed bit field macros)
>
> Signed-off-by: Deepak M
> Signed-off-by: Madhav Chauhan
Pushed to drm-intel-next-queued, thanks for the patch.
BR,
Jani.
> ---
> drivers/gpu/drm/i915/i915_reg
On Thu, 15 Dec 2016, Madhav Chauhan wrote:
> From: Deepak M
>
> Program the clk lane and tlpx time count registers
> to configure DSI PHY.
>
> v2: Addressed Jani's Review comments(renamed bit field macros)
>
> Signed-off-by: Deepak M
> Signed-off-by: Madhav Chauhan
> ---
> drivers/gpu/drm/i915
On Wed, Dec 21, 2016 at 03:50:18PM -0500, Lyude wrote:
> This is a simple macro for executing a block of code at the beginning of
> intel-gpu-tools, before any tests have been ran. Useful for
> initialization of global resources used in IGT libraries.
>
> Signed-off-by: Lyude
>
> Changes since v
On Mon, 2016-12-19 at 19:28 +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> With the cdclk state, all the .modeset_commit_cdclk() hooks are
> now pointless wrappers. Let's replace them with just a .set_cdclk()
> function pointer. However let's wrap that in a small helper tha
On Mon, 2016-12-19 at 19:28 +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Move ilk_pipe_pixel_rate() next to its only caller
> (intel_crtc_compute_pixel_rate()).
Assuming a rebased patch 1,
Reviewed-by: Ander Conselvan de Oliveira
>
> Signed-off-by: Ville Syrjälä
> -
On Fri, Dec 23, 2016 at 03:49:02PM +0200, Ander Conselvan De Oliveira wrote:
> On Mon, 2016-12-19 at 19:28 +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Move the vlv_program_pfi_credits() into vlv_set_cdclk() and
> > chv_set_cdclk() so that we can neuter vlv_modeset_
On Thu, 15 Dec 2016, Madhav Chauhan wrote:
> From: Deepak M
>
> v2: Addressed Jani's Review comments(renamed bit field macros)
>
> Signed-off-by: Deepak M
> Signed-off-by: Madhav Chauhan
> ---
> drivers/gpu/drm/i915/intel_dsi.c | 134
> +++
> 1 file changed
On Thu, Dec 22, 2016 at 03:12:17PM -0800, Anusha Srivatsa wrote:
> From: Peter Antoine
>
> Rename some of the GuC fw loading code to make them more general. We
> will utilise them for HuC loading as well.
> s/intel_guc_fw/intel_uc_fw/g
> s/GUC_FIRMWARE/UC_FIRMWARE/g
>
> Struct intel_gu
On Thu, Dec 22, 2016 at 03:12:18PM -0800, Anusha Srivatsa wrote:
> From: Peter Antoine
>
> HuC firmware css header has almost exactly same definition as GuC
> firmware except for the sw_version. Also, add a new member fw_type
> into intel_uc_fw to indicate what kind of fw it is. So, the loader
>
In DP V1.3 spec , Table 2-149 , page number-374 , for Register 0x2210 ,
bit 7:4 is reserved.
-Original Message-
From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
Sent: Friday, December 23, 2016 6:57 PM
To: Nagaraju, Vathsala ;
dri-de...@lists.freedesktop.org; intel-gfx@list
On Thu, Dec 22, 2016 at 03:12:24PM -0800, Anusha Srivatsa wrote:
> From: Peter Antoine
>
> This patch will allow for getparams to return the status of the HuC.
> As the HuC has to be validated by the GuC this patch uses the validated
> status to show when the HuC is loaded and ready for use. You
On Thu, Dec 22, 2016 at 03:12:21PM -0800, Anusha Srivatsa wrote:
> This patch adds the support to load HuC on KBL
> Version 2.0
>
> v2: rebased.
> v3: rebased on top of drm-tip
> v4: rebased.
> v5: rebased. Rename KBL_FW_ to KBL_HUC_FW_
> v6: rebased. Remove old checks.
>
> Cc: Tvrtko Ursulin
>
On Thu, Dec 22, 2016 at 03:12:20PM -0800, Anusha Srivatsa wrote:
> This patch adds the HuC Loading for the BXT by using
> the updated file construction.
>
> Version 1.7 of the HuC firmware.
>
> v2: rebased.
> v3: rebased on top of drm-tip
> v4: rebased.
> v5: rebased. Rename BXT_FW_MAJOR to BXT_H
On Thu, Dec 22, 2016 at 09:40:41PM +, Chris Wilson wrote:
> On Thu, Dec 22, 2016 at 09:52:22PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Now that we're disabling L2 clock gating MI_OVERLAY_OFF actually works
> > on 830, so let's use it.
> >
> > v2: Nuke the
Since commit db6c2b4151f2 ("drm/i915: Store the vma in an rbtree under
the object") the vma are once again sorted into GGTT first, then ppGTT
so that the typical case of walking the GGTT vma can stop as soon as we
find a non-ppGTT. Apply that optimisation.
Signed-off-by: Chris Wilson
Cc: Tvrtko U
When we teardown the backing storage for the phys object, we copy from
the coherent contiguous block back to the shmemfs object, clflushing as
we go. Trying to clflush the invalid sg beforehand just oops and would
be redundant (due to it already being coherent, and clflushed
afterwards).
Reported-
Save a lot of characters by making the union anonymous, with the
side-effect of ignoring unset bits when comparing views.
v2: Roll up the memcmps back into one.
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem.c | 8
drivers/gpu/drm/i915/i915_gem_g
It is only being used to clear a struct and set the type, after which it
is overwritten. Since we no longer check the unset bits of the union,
skipping the clear is permissible.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 3 ---
drivers/gp
When creating a partial VMA assert that it first fits with the parent
object, and that if it covers the whole of the parent a normal view was
created instead.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_vma.c | 5 +
1 file changed, 5 insertions(+)
As the fence may be signaled concurrently from an interrupt on another
device, it is possible for the list of requests on the timeline to be
modified as we walk it. Take both (the context's timeline and the global
timeline) locks to prevent such modifications.
Fixes: 80b204bce8f2 ("drm/i915: Enabl
In order to reuse the partial view for selftesting, extract the common
function for computing the view.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem.c | 48 +
1 file changed, 29 insertions(+), 19 deletions(-)
The idle work handler is self-arming - if it detects that it needs to
run again it will queue itself from its work handler. Take greater care
when trying to drain the idle work, and double check that it is flushed.
The free worker has a similar issue where it is armed by an RCU task
which may be r
As trimming the sg table is merely an optimisation that gracefully fails
if we cannot allocate a new table, we do not need to report the failure
either.
Fixes: 0c40ce130e38 ("drm/i915: Trim the object sg table")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Joonas Lahtinen
---
dr
Since commit 058d88c4330f ("drm/i915: Track pinned VMA"), there is only
one user of i915_ggtt_view_normal rodate. Just treat NULL as no special
view in pin_to_display() like everywhere else.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem.c | 2 +-
Ville pointed out that intel_fbc_choose_crtc() is iterating over all
planes instead of just the primary planes. There are no real
consequences of this problem for HSW+, and for the other platforms it
just means that in some obscure multi-screen cases we'll keep FBC
disabled when we could have enabl
Em Sex, 2016-12-23 às 13:29 -0200, Paulo Zanoni escreveu:
> Ville pointed out that intel_fbc_choose_crtc() is iterating over all
> planes instead of just the primary planes. There are no real
> consequences of this problem for HSW+, and for the other platforms it
> just means that in some obscure m
On Fri, 23 Dec 2016, "Nagaraju, Vathsala" wrote:
> In DP V1.3 spec , Table 2-149 , page number-374 , for Register 0x2210
> , bit 7:4 is reserved.
See DP 1.4.
BR,
Jani.
>
> -Original Message-
> From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
> Sent: Friday, December 23, 2016 6:
== Series Details ==
Series: series starting with [01/10] drm/i915: Break after walking all GGTT vma
in bump_inactive_ggtt
URL : https://patchwork.freedesktop.org/series/17178/
State : success
== Summary ==
Series 17178v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/s
== Series Details ==
Series: series starting with [1/2] drm/i915: enable FBC on gen9+ too (rev2)
URL : https://patchwork.freedesktop.org/series/17176/
State : failure
== Summary ==
Series 17176v2 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/17176/revisions/2/mbo
PSR2 vsc revision number hb2( as per table 6-11)is updated to
4 or 5 based on Y cordinate and Colorimetry Format as below
04h = 3D stereo + PSR/PSR2 + Y-coordinate.
05h = -3D stereo- + PSR/PSR2 + Y-coordinate + Pixel Encoding/Colorimetry
Format indication. A DP Source device is allowed to indicate
>-Original Message-
>From: Hiler, Arkadiusz
>Sent: Friday, December 23, 2016 6:22 AM
>To: Srivatsa, Anusha
>Cc: intel-gfx@lists.freedesktop.org; Alex Dai ; Peter Antoine
>
>Subject: Re: [Intel-gfx] [PATCH 2/8] drm/i915/huc: Unified css_header struct
>for
>GuC and HuC
>
>On Thu, Dec 22,
> -Original Message-
> From: Nikula, Jani
> Sent: Friday, December 23, 2016 7:27 PM
> To: Chauhan, Madhav ; intel-
> g...@lists.freedesktop.org
> Cc: Conselvan De Oliveira, Ander ;
> Saarinen, Jani ; Konduru, Chandra
> ; Shankar, Uma ;
> Mukherjee, Indranil ; Kumar, Shobhit
> ; Deepak M ; C
On 15/12/16 07:47, Arkadiusz Hiler wrote:
Let intel_guc_init() focus on determining and fetching the correct
firmware.
This patch introduces intel_sanitize_uc_params() that is called from
intel_uc_init().
Then, if we have GuC, we can call intel_guc_init() conditionally and we
do not have to d
This check is useful for drivers that do not have DRIVER_ATOMIC set but
have atomic modesetting internally implemented. Wrap the check into a
function since this is used in many places and as a bonus, the function
name helps to document what the check is for.
v2:
Change return type to bool (Ville)
i915 does not set DRIVER_ATOMIC by default yet but uses atomic_check and
atomic_commit. drm_object_property_get_value() does not read the correct
value of atomic properties if DRIVER_ATOMIC is not set. Checking whether
the driver uses atomic modeset is a better check instead as the property
values
== Series Details ==
Series: series starting with [v4,1/2] drm: Wrap the check for atomic_commit
implementation
URL : https://patchwork.freedesktop.org/series/17193/
State : success
== Summary ==
Series 17193v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/17193
From: Daniele Ceraolo Spurio
GuC will validate the ring offset and fail if it is in the
[0, GUC_WOPCM_TOP) range. The bias is conditionally applied only
if GuC loading is enabled (we can't check for guc submission enabled as
in other cases because HuC loading requires this fix).
Note that the de
From: Daniele Ceraolo Spurio
The context has to obey the same offset requirements as the ring,
so we can re-use the same bias value we computed for the ring instead of
unconditionally using GUC_WOPCM_TOP.
Suggested-by: Chris Wilson
Signed-off-by: Daniele Ceraolo Spurio
Cc: Chris Wilson
---
d
== Series Details ==
Series: series starting with [v2,1/2] drm/i915: request ring to be pinned above
GUC_WOPCM_TOP
URL : https://patchwork.freedesktop.org/series/17195/
State : success
== Summary ==
Series 17195v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/17
62 matches
Mail list logo
