On Mon, 26 Sep 2016, Paulo Zanoni wrote:
> Em Seg, 2016-09-26 às 15:07 +0300, Jani Nikula escreveu:
>> Cc: Paulo Zanoni
>> Signed-off-by: Jani Nikula
>
> Reviewed-by: Paulo Zanoni
Thanks, pushed both to dinq.
BR,
Jani.
>
>> ---
>> drivers/gpu/drm/i915/intel_guc_loader.c | 2 +-
>> drivers/g
Hi Chris
On Mon, Sep 26, 2016 at 10:44 PM, Chris Wilson wrote:
> Currently we use a linear walk to lookup a handle and return a dma-buf,
> and vice versa. A long overdue TODO task is to convert that to a
> hashtable. Since the initial implementation of dma-buf/prime, we now
> have resizeable hash
== Series Details ==
Series: drm: Convert prime dma-buf <-> handle to rhashtable (rev2)
URL : https://patchwork.freedesktop.org/series/12787/
State : warning
== Summary ==
Series 12787v2 drm: Convert prime dma-buf <-> handle to rhashtable
https://patchwork.freedesktop.org/api/1.0/series/12787/
Currently we use a linear walk to lookup a handle and return a dma-buf,
and vice versa. A long overdue TODO task is to convert that to a
hashtable. Since the initial implementation of dma-buf/prime, we now
have resizeable hashtables we can use (and now a future task is to RCU
enable the lookup!). H
On 26/09/2016 12:08, Paneri, Praveen wrote:
On 9/23/2016 3:19 PM, Tvrtko Ursulin wrote:
Hi,
On 19/09/2016 18:15, Praveen Paneri wrote:
[snip]
+
enum forcewake_domains
intel_uncore_forcewake_for_reg(struct drm_i915_private *dev_priv,
i915_reg_t reg, unsigned in
On 16-09-15 17:30:10, Mika Kuoppala wrote:
Imre Deak writes:
From: Ben Widawsky
v2: (Imre)
- Access only subslices that are known to exist.
- Reset explictly the MCR selector to slice/sub-slice ID 0 after the
readout.
- Use the subslice INSTDONE bits for the hangcheck/subunits-stuck
dete
Em Qui, 2016-09-22 às 14:19 +0530, vathsala nagaraju escreveu:
> when i915_fbc_status is read while fbc is disabled,
> it reports compressing to be true, which is confusing.
> report compressing only when fbc is enabled.
>
> Signed-off-by: vathsala nagaraju
> ---
> drivers/gpu/drm/i915/i915_debu
Em Qui, 2016-09-22 às 21:49 +, Patchwork escreveu:
> == Series Details ==
>
> Series: SKL/KBL watermark fixes (rev3)
> URL : https://patchwork.freedesktop.org/series/12082/
> State : warning
>
> == Summary ==
>
> Series 12082v3 SKL/KBL watermark fixes
> https://patchwork.freedesktop.org/ap
Em Seg, 2016-09-26 às 15:07 +0300, Jani Nikula escreveu:
> Cc: Paulo Zanoni
> Signed-off-by: Jani Nikula
Reviewed-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/intel_guc_loader.c | 2 +-
> drivers/gpu/drm/i915/intel_pm.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
>
Em Seg, 2016-09-26 às 13:20 +, Patchwork escreveu:
> == Series Details ==
>
> Series: series starting with [1/2] drm/i915: add a few missing
> platform tags to workaround tags
> URL : https://patchwork.freedesktop.org/series/12925/
> State : warning
>
> == Summary ==
>
> Series 12925v1 Ser
== Series Details ==
Series: drm: drm: Per-plane rotation etc.
URL : https://patchwork.freedesktop.org/series/12938/
State : warning
== Summary ==
Series 12938v1 drm: drm: Per-plane rotation etc.
https://patchwork.freedesktop.org/api/1.0/series/12938/revisions/1/mbox/
Test gem_exec_gttfill:
On Mon, Sep 26, 2016 at 12:30 PM, wrote:
> From: Ville Syrjälä
>
> Another, rebased, version of my earlier series [1] to add the per-plane
> rotation property. One thing holding back the previous version was the
> weird regression on omap, but apparently I managed to fix it (see [2]).
>
> msm an
On Mon, Sep 26, 2016 at 07:30:45PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Another, rebased, version of my earlier series [1] to add the per-plane
> rotation property. One thing holding back the previous version was the
> weird regression on omap, but apparently I ma
Some of the Intel platforms have odd numbers of LUT entries and we
need to tests a couple of values around the expected result. Bring
back the CRC equal function we need that doesn't trigger an assert
right away, while we still assert if we can't find a correct result in
the outter loop.
v2: updat
From: Ville Syrjälä
Using == to check for 180 degree rotation only works as long as the
reflection bits aren't set. That will change soon enough for CHV, so
let's stop doing things the wrong way.
v2: Drop the BIT()
Signed-off-by: Ville Syrjälä
Reviewed-by: Chris Wilson
Reviewed-by: Joonas Lah
From: Ville Syrjälä
Since the hardware can apparently do both X and Y reflection, we
can advertize also 180 degree rotation as thats just X+Y reflection.
v2: Drop the BIT()
Cc: Rob Clark
Cc: Jilai Wang
Cc: Archit Taneja
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_pla
From: Ville Syrjälä
The primary and sprite planes on CHV pipe B support horizontal
mirroring. Expose it to the world.
Sadly the hardware ignores the mirror bit when the rotate bit is
set, so we'll have to reject the 180+X case.
v2: Drop the BIT()
Signed-off-by: Ville Syrjälä
Reviewed-by: Joon
From: Ville Syrjälä
Now that all drivers have been converted over to the per-plane rotation
property, we can just nuke the global rotation property.
v2: Rebase due to BIT(),__builtin_ffs() & co.
Deal with superfluous code shuffling
Signed-off-by: Ville Syrjälä
Reviewed-by: Joonas Lahtinen
From: Ville Syrjälä
Move the plane control register rotation setup away from the
coordinate munging code. This will result in neater looking
code once we add reflection support for CHV.
v2: Drop the BIT(), drop some usless parens,
Signed-off-by: Ville Syrjälä
Reviewed-by: Chris Wilson
Reviewe
From: Ville Syrjälä
On certain platforms not all planes support the same set of
rotations/reflections, so let's use the per-plane property
for this.
This is already a problem on SKL when we use the legay cursor plane
as it only supports 0|180 whereas the universal planes support
0|90|180|270, an
From: Ville Syrjälä
The global mode_config.rotation_property is going away, switch over to
per-plane rotation_property.
v2: Drop the BIT()
Cc: Rob Clark
Cc: Jilai Wang
Cc: Archit Taneja
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 14 +-
1 file c
From: Ville Syrjälä
We have intel_rotation_90_or_270() in i915 to check if the rotation is
90 or 270 degrees. Similar checks are elsewhere in drm, so let's move
the helper into a central place and use it everwhere.
v2: Drop the BIT()
Convert all new intel_rotation_90_or_270() calls
Deal
From: Ville Syrjälä
Another, rebased, version of my earlier series [1] to add the per-plane
rotation property. One thing holding back the previous version was the
weird regression on omap, but apparently I managed to fix it (see [2]).
msm and omap still lack r-bs/acks.
Entire series available h
From: Ville Syrjälä
The global mode_config.rotation_property is going away, switch over to
per-plane rotation_property.
v2: Drop the BIT()
Cc: Liviu Dudau
Cc: Brian Starkey
Cc: Mali DP Maintainers
Signed-off-by: Ville Syrjälä
Acked-by: Brian Starkey
---
drivers/gpu/drm/arm/malidp_planes.c
From: Ville Syrjälä
The rotation property should only accept exactly one rotation angle
at once. Let's reject attempts to set none or multiple angles.
Testcase: igt/kms_rotation_crc/bad-rotation
Signed-off-by: Ville Syrjälä
Reviewed-by: Joonas Lahtinen
Reviewed-by: Chris Wilson
---
drivers/g
From: Ville Syrjälä
The global mode_config.rotation_property is going away, switch over to
per-plane rotation_property.
v2: Propagate error upwards (Boris)
v3: Drop the BIT()
Cc: Boris Brezillon
Signed-off-by: Ville Syrjälä
Acked-by: Boris Brezillon
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlc
From: Ville Syrjälä
0 isn't a valid rotation property value, so let's set the initial value
of the property to BIT(DRM_ROTATE_0) instead.
v2: Drop the BIT()
Cc: Tomi Valkeinen
Cc: Rob Clark
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/omapdrm/omap_drv.c | 6 --
drivers/gpu/drm/oma
From: Ville Syrjälä
The global mode_config.rotation_property is going away, switch over to
per-plane rotation_property.
Not sure I got the annoying crtc rotation_property handling right.
Might work, or migth not.
v2: Drop the BIT()
Don't create rotation property twice for each primary plane
From: Ville Syrjälä
0 isn't a valid rotation property value, so let's set the initial value
of the property to BIT(DRM_ROTATE_0) instead.
In the same vein, we must always have at leat one angle as part of
set of supported rotation bits, so let's include DRM_ROTATE_0
in there.
v2: Drop the BIT()
From: Ville Syrjälä
Not all planes on the system may support the same rotations/reflections,
so make it possible to create a separate property for each plane.
This way userspace gets told exactly which rotations/reflections are
possible for each plane.
v2: Add drm_plane_create_rotation_property(
== Series Details ==
Series: drm/i915/bxt: Fix HDMI DPLL configuration
URL : https://patchwork.freedesktop.org/series/12930/
State : failure
== Summary ==
Series 12930v1 drm/i915/bxt: Fix HDMI DPLL configuration
https://patchwork.freedesktop.org/api/1.0/series/12930/revisions/1/mbox/
Test kms
On Mon, 26 Sep 2016, Imre Deak wrote:
> a277ca7dc01d should've been a no-functional-change commit, but it
> removed the initialization of the dpll_hw_state for HDMI outputs,
> resulting in state mismatches and a failed modeset with blank
> screen. Fix this by reinstating the dpll_hw_state initiali
On Tue, 06 Sep 2016, Jim Bride wrote:
> Ville wrote:
>> On Thu, Aug 18, 2016 at 05:11:31PM -0700, Anusha Srivatsa wrote:
>> > Change intel_dp_mst_mode_valid() to use available link bandwidth
>> > rather than the link's maximum supported bandwidth to evaluate whether
>> > modes are legal for the
a277ca7dc01d should've been a no-functional-change commit, but it
removed the initialization of the dpll_hw_state for HDMI outputs,
resulting in state mismatches and a failed modeset with blank
screen. Fix this by reinstating the dpll_hw_state initialization.
Fixes: a277ca7dc01d ("drm/i915: Split
Hi
Is there any chance this could be removed from the upcoming drm-4.9
pull, at least until this issue has been fixed
Regards
Mike
On 21 September 2016 at 12:34, Mike Lothian wrote:
> I've raised https://bugs.freedesktop.org/show_bug.cgi?id=97888 I'll
> attach the info you requested once I get
On Fri, 16 Sep 2016, Manasi Navare wrote:
> Replace dev with dev_priv and INTEL_INFO with INTEL_GEN
Patches like this could easily sent separately, or at the very least as
the first patches in the series. Then we could have merged this
already. Now it conflicts, please rebase.
BR,
Jani.
>
> Sig
On Fri, 16 Sep 2016, Manasi Navare wrote:
> While configuring the pipe during modeset, it should use
> max clock and max lane count and reduce the bpp until
> the requested mode rate is less than or equal to
> available link BW.
> This is required to pass DP Compliance.
As I wrote in reply to pat
On Fri, 16 Sep 2016, Manasi Navare wrote:
> According to the DisplayPort Spec, in case of Clock Recovery failure
> the link training sequence should fall back to the lower link rate
> followed by lower lane count until CR succeeds.
> On CR success, the sequence proceeds with Channel EQ.
> In case
== Series Details ==
Series: series starting with [1/2] drm/i915: add a few missing platform tags to
workaround tags
URL : https://patchwork.freedesktop.org/series/12925/
State : warning
== Summary ==
Series 12925v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/
On Thu, 22 Sep 2016, Paulo Zanoni wrote:
> Em Sex, 2016-09-16 às 16:59 +0300, Jani Nikula escreveu:
>> Only production steppings are supported, drop workarounds for
>> anything
>> else. The series is split by revision so we can bikeshed if there are
>> steppings some people still need to use for s
From: Paulo Zanoni
We just removed the implementation for all the pre-production
workarounds, so now tell the user that we expect his machine to not
work properly. Also convert this to DRM_ERROR so we can more easily
spot these problems in bug reports and CI/QA runs.
Cc: Jani Nikula
Signed-off-
Cc: Paulo Zanoni
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_guc_loader.c | 2 +-
drivers/gpu/drm/i915/intel_pm.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c
b/drivers/gpu/drm/i915/intel_guc_loader.c
index
Thanks. Unless there's a trivial quick fix, I expect a revert first.
BR,
Jani.
On Mon, 26 Sep 2016, "Yang, Libin" wrote:
> Yes, I see. I will co-work with DK to fix the issue.
>
> Regards,
> Libin
>
>
>> -Original Message-
>> From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
>> Se
Yes, I see. I will co-work with DK to fix the issue.
Regards,
Libin
> -Original Message-
> From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
> Sent: Monday, September 26, 2016 4:39 PM
> To: Yang, Libin ; libin.y...@linux.intel.com; intel-
> g...@lists.freedesktop.org; ville.syrj...@
On 9/23/2016 3:19 PM, Tvrtko Ursulin wrote:
Hi,
On 19/09/2016 18:15, Praveen Paneri wrote:
Decoupled MMIO is an alternative way to access forcewake domain
registers, which requires less cycles and avoids frequent software
forcewake.
I would like to see a sentence or two on how it works he
== Series Details ==
Series: series starting with [1/3] Revert "Skip intel_crt_init for Dell XPS
8700"
URL : https://patchwork.freedesktop.org/series/12920/
State : warning
== Summary ==
Series 12920v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/12920/revision
On Mon, Sep 26, 2016 at 11:57:04AM +0300, Jani Nikula wrote:
> On Wed, 21 Sep 2016, Giacomo Comes wrote:
> > Hi,
> > I hope this is the appropriate place to ask what follows.
> > If not please point me to the right place.
> >
> > I have a couple of cerryview systems
> > (Acer Aspire R11 and Intel
On Mon, Sep 26, 2016 at 09:23:55AM -, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Allow PCH DPLL sharing regardless of DPLL_SDVO_HIGH_SPEED
> URL : https://patchwork.freedesktop.org/series/12918/
> State : warning
>
> == Summary ==
>
> Series 12918v1 drm/i915: Allow PCH D
On Mon, Sep 26, 2016 at 12:06:19PM +0300, Joonas Lahtinen wrote:
> On ma, 2016-09-26 at 10:04 +0100, Chris Wilson wrote:
> > On Mon, Sep 26, 2016 at 11:53:05AM +0300, Joonas Lahtinen wrote:
> > >
> > > On ti, 2016-09-20 at 09:30 +0100, Chris Wilson wrote:
> > > >
> > > > Move the actual emission
== Series Details ==
Series: drm/i915: Allow PCH DPLL sharing regardless of DPLL_SDVO_HIGH_SPEED
URL : https://patchwork.freedesktop.org/series/12918/
State : warning
== Summary ==
Series 12918v1 drm/i915: Allow PCH DPLL sharing regardless of
DPLL_SDVO_HIGH_SPEED
https://patchwork.freedesktop
From: Ville Syrjälä
Intel DZ77BH-55K board doest't have a physical VGA connector,
and yet it always detects that something is connected there.
Add it to the DMI blacklist to ignore the spurious detection
results.
Allows me to drop 'video=VGA-1:d' from my kernel cmdline.
Signed-off-by: Ville Syr
From: Ville Syrjälä
This reverts commit 10b6ee4a87811a110cb01eaca01eb04da6801baf.
According to [1] Dell XPS8700 VBT says 'int_crt_support 0', so thanks
to commit e4abb733bb72 ("drm/i915: Check VBT for CRT port presence on
HSW/BDW") we no longer need to blacklist it based on DMI.
Looking through
From: Ville Syrjälä
Having a shadow VGA connector is useful for testing purposes. We
currently skip registering the connector on machines where the
CRT detect falsely reports it as connected. Let's instead move the
the blacklist check to the detect callback (and hpd setup) and
if we get a match w
On ma, 2016-09-26 at 10:04 +0100, Chris Wilson wrote:
> On Mon, Sep 26, 2016 at 11:53:05AM +0300, Joonas Lahtinen wrote:
> >
> > On ti, 2016-09-20 at 09:30 +0100, Chris Wilson wrote:
> > >
> > > Move the actual emission of the request (the closing breadcrumb) from
> > > i915_add_request() to the
On Mon, Sep 26, 2016 at 11:53:05AM +0300, Joonas Lahtinen wrote:
> On ti, 2016-09-20 at 09:30 +0100, Chris Wilson wrote:
> > Move the actual emission of the request (the closing breadcrumb) from
> > i915_add_request() to the submit callback. (It can be moved later when
> > required.) This allows us
On ti, 2016-09-20 at 09:29 +0100, Chris Wilson wrote:
> The error state is purposefully racy as we expect it to be called at any
> time and so have avoided any locking whilst capturing the crash dump.
> However, with multi-engine GPUs and multiple CPUs, those races can
> manifest into OOPSes as we
On Wed, 21 Sep 2016, Giacomo Comes wrote:
> Hi,
> I hope this is the appropriate place to ask what follows.
> If not please point me to the right place.
>
> I have a couple of cerryview systems
> (Acer Aspire R11 and Intel compute stick STK1AW32SC) on which
> I run linux (openSUSE 42.1) with a 4.7
On ti, 2016-09-20 at 09:30 +0100, Chris Wilson wrote:
> With the infrastructure converted over to tracking multiple timelines in
> the GEM API whilst preserving the efficiency of using a single execution
> timeline internally, we can now assign a separate timeline to every
> context with full-ppgtt
On ti, 2016-09-20 at 09:30 +0100, Chris Wilson wrote:
> Move the actual emission of the request (the closing breadcrumb) from
> i915_add_request() to the submit callback. (It can be moved later when
> required.) This allows us to defer the allocation of the global_seqno
> from request construction
== Series Details ==
Series: drm/i915/audio: extend get_saved_enc() to support more scenarios
URL : https://patchwork.freedesktop.org/series/12917/
State : success
== Summary ==
Series 12917v1 drm/i915/audio: extend get_saved_enc() to support more scenarios
https://patchwork.freedesktop.org/ap
On ti, 2016-09-20 at 09:30 +0100, Chris Wilson wrote:
> +__maybe_unused static bool is_kernel_context(struct drm_i915_private
> *dev_priv)
__maybe_unused definitely most definitely does not belong here. Need
solve the GEM_BUG_ON otherwise. Also, "is_in_kernel_context" as you
have "switch_to_kerne
I will NAK all further DP MST audio patches until
https://bugs.freedesktop.org/show_bug.cgi?id=97907
is fixed.
BR,
Jani.
On Mon, 26 Sep 2016, "Yang, Libin" wrote:
> Add DK, Jim and Jeeja
>
> Regards,
> Libin
>
>
>> -Original Message-
>> From: libin.y...@linux.intel.com [mailto:libin
From: Ville Syrjälä
DPLL_SDVO_HIGH_SPEED must be set for SDVO/HDMI/DP, but nowhere is it
forbidden to set it for LVDS/CRT as well. So let's also set it on
CRT to make it possible to share the DPLL between HDMI and CRT.
What that bit apparently does is enable the x5 clock to the port,
which then
Add DK, Jim and Jeeja
Regards,
Libin
> -Original Message-
> From: libin.y...@linux.intel.com [mailto:libin.y...@linux.intel.com]
> Sent: Monday, September 26, 2016 4:21 PM
> To: intel-gfx@lists.freedesktop.org; jani.nik...@linux.intel.com;
> ville.syrj...@linux.intel.com; Vetter, Daniel
From: Libin Yang
When bootup, audio driver may not know it is MST or not. The audio
driver will poll all the port & pipe combinations in either MST or
Non-MST mode. get_saved_enc() should handle this situation.
Signed-off-by: Libin Yang
---
drivers/gpu/drm/i915/intel_audio.c | 32 +
On Tue, 20 Sep 2016, Dhinakaran Pandiyan wrote:
> From: Libin Yang
>
> (This patch is developed by Dave Airlie originally)
>
> This patch adds support for DP MST audio in i915.
>
> Enable audio codec when DP MST is enabled if has_audio flag is set.
> Disable audio codec when DP MST is disabled i
CC'ing Maarten to A-b or R-b.
On ti, 2016-09-20 at 09:30 +0100, Chris Wilson wrote:
> @@ -14615,31 +14641,25 @@ intel_prepare_plane_fb(struct drm_plane *plane,
> * This should only fail upon a hung GPU, in which case we
> * can safely continue.
> */
> -
On ti, 2016-09-20 at 09:29 +0100, Chris Wilson wrote:
> +static struct intel_engine_cs *
> +last_write_engine(struct drm_i915_gem_object *obj)
This function is repeated below, better move it to header as
__i915_gem_obj_last_write_engine?
I'd say there is not an ABI change now as non-i915 fences
On ti, 2016-09-20 at 09:29 +0100, Chris Wilson wrote:
> @@ -143,88 +149,126 @@ static int render_state_setup(struct render_state *so)
> }
>
> OUT_BATCH(d, i, MI_BATCH_BUFFER_END);
> - so->aux_batch_size = (i * sizeof(u32)) - so->aux_batch_offset;
> -
> + so->aux_size = i * siz
69 matches
Mail list logo