Op 06-04-17 om 03:27 schreef Pandiyan, Dhinakaran:
> On Wed, 2017-04-05 at 12:06 +0200, Daniel Vetter wrote:
>> On Wed, Apr 05, 2017 at 10:41:24AM +0200, Maarten Lankhorst wrote:
>>> The connector atomic check function may be called multiple times,
>>> or not at all. It's mostly useful for implemen
In at least SKL and GLK (possibly other devices too), using a cursor
plane to scan out an fb might result in a different pipe crc than when
using a regular plane at the same position with the same fb. The
differences could be caused by the cursor plane being limited to 8 bpc
while the regular plane
This test actually *fails* in GLK and possibly SKL and others too. When
using limited range, the pipe crc when using the cursor plane is
different than the one when using an overlay plane, although the fb and
plane position is the same.
Since this test fails it should probably not be merged, but i
On 05/04/2017 13:47, Chris Wilson wrote:
If we attempt to wake up a waiter, who is currently checking the seqno
it will be in the TASK_INTERRUPTIBLE state and ttwu will report success.
However, it is actually awake and functioning -- so delay reporting the
actual wake up until it sleeps.
v2: De
On Thu, Apr 06, 2017 at 09:04:23AM +0100, Tvrtko Ursulin wrote:
>
> On 05/04/2017 13:47, Chris Wilson wrote:
> >If we attempt to wake up a waiter, who is currently checking the seqno
> >it will be in the TASK_INTERRUPTIBLE state and ttwu will report success.
> >However, it is actually awake and fu
On 05/04/2017 17:48, Chris Wilson wrote:
On Wed, Apr 05, 2017 at 05:14:01PM +0100, Tvrtko Ursulin wrote:
+static void
+__emit_bb_end(struct w_step *w, bool terminate, bool seqnos, uint32_t seqno)
+{
+ const uint32_t bbe = 0xa << 23;
+ unsigned long bb_sz = get_bb_sz(&w->duration);
+
On Wed, Apr 05, 2017 at 03:45:41PM -0400, Alex Deucher wrote:
> On Mon, Apr 3, 2017 at 4:32 AM, Daniel Vetter wrote:
> > Hi all,
> >
> > Partially this is a resend of the patches now unblocked by the vmwgfx atomic
> > conversion just merged. I could entirely drop the vmwgfx patch since it's
> > a
On Thu, Apr 6, 2017 at 12:34 AM Maarten Lankhorst <
maarten.lankho...@linux.intel.com> wrote:
> Op 06-04-17 om 03:27 schreef Pandiyan, Dhinakaran:
> > On Wed, 2017-04-05 at 12:06 +0200, Daniel Vetter wrote:
> >> On Wed, Apr 05, 2017 at 10:41:24AM +0200, Maarten Lankhorst wrote:
> >>> The connector
Replace the handcrafter loop when checking for fifo slots
with atomic wait for. This brings this wait in line with
the other waits on register access. We also get a readable
timeout constraint, so make it to fail after 10ms.
Chris suggested that we should fail silently as the fifo debug
handler, n
From: Chris Wilson
Remove the per-mmio checking of the FIFO debug register into the common
conditional mmio debug handling. Based on patch from Chris Wilson.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_uncore.c | 74 ++---
1 file changed, 28 inse
On 06/04/2017 09:16, Chris Wilson wrote:
On Thu, Apr 06, 2017 at 09:04:23AM +0100, Tvrtko Ursulin wrote:
On 05/04/2017 13:47, Chris Wilson wrote:
If we attempt to wake up a waiter, who is currently checking the seqno
it will be in the TASK_INTERRUPTIBLE state and ttwu will report success.
How
On Thu, Apr 06, 2017 at 09:18:36AM +0100, Tvrtko Ursulin wrote:
>
> On 05/04/2017 17:48, Chris Wilson wrote:
> >On Wed, Apr 05, 2017 at 05:14:01PM +0100, Tvrtko Ursulin wrote:
> >>+static void
> >>+__emit_bb_end(struct w_step *w, bool terminate, bool seqnos, uint32_t
> >>seqno)
> >>+{
> >>+ con
On Thu, Apr 06, 2017 at 11:44:18AM +0300, Mika Kuoppala wrote:
> From: Chris Wilson
From: Mika Kuoppala
> Remove the per-mmio checking of the FIFO debug register into the common
> conditional mmio debug handling. Based on patch from Chris Wilson.
>
> Signed-off-by: Mika Kuoppala
Reviewed-by: C
On Thu, Apr 06, 2017 at 11:44:19AM +0300, Mika Kuoppala wrote:
> Replace the handcrafter loop when checking for fifo slots
> with atomic wait for. This brings this wait in line with
> the other waits on register access. We also get a readable
> timeout constraint, so make it to fail after 10ms.
>
On Thu, Apr 06, 2017 at 10:03:23AM +0100, Chris Wilson wrote:
> On Thu, Apr 06, 2017 at 11:44:18AM +0300, Mika Kuoppala wrote:
> > From: Chris Wilson
> From: Mika Kuoppala
>
> > Remove the per-mmio checking of the FIFO debug register into the common
> > conditional mmio debug handling. Based on
On Thu, Apr 06, 2017 at 09:55:27AM +0100, Tvrtko Ursulin wrote:
>
> On 06/04/2017 09:16, Chris Wilson wrote:
> >On Thu, Apr 06, 2017 at 09:04:23AM +0100, Tvrtko Ursulin wrote:
> >>
> >>On 05/04/2017 13:47, Chris Wilson wrote:
> >>>If we attempt to wake up a waiter, who is currently checking the se
Chris Wilson writes:
> On Thu, Apr 06, 2017 at 11:44:19AM +0300, Mika Kuoppala wrote:
>> Replace the handcrafter loop when checking for fifo slots
>> with atomic wait for. This brings this wait in line with
>> the other waits on register access. We also get a readable
>> timeout constraint, so ma
== Series Details ==
Series: series starting with [1/2] drm/i915: Move the GTFIFODBG to the common
mmio dbg framework
URL : https://patchwork.freedesktop.org/series/22571/
State : warning
== Summary ==
Series 22571v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series
If we attempt to wake up a waiter, who is currently checking the seqno
it will be in the TASK_INTERRUPTIBLE state and ttwu will report success.
However, it is actually awake and functioning -- so delay reporting the
actual wake up until it sleeps.
v2: Defend against !CONFIG_SMP
v3: Don't filter ou
== Series Details ==
Series: drm/i915: Only report a wakeup if the waiter was truly asleep (rev3)
URL : https://patchwork.freedesktop.org/series/22445/
State : success
== Summary ==
Series 22445v3 drm/i915: Only report a wakeup if the waiter was truly asleep
https://patchwork.freedesktop.org/a
On Wed, Apr 05, 2017 at 09:38:49AM -0700, Daniele Ceraolo Spurio wrote:
>
>
> On 05/04/17 05:24, Chris Wilson wrote:
> >On Wed, Apr 05, 2017 at 03:51:50PM +0530, Sagar Arun Kamble wrote:
> >>i915 is currently doing Full GPU reset at the end of suspend followed by
> >>GuC suspend. This reset bypas
Hello, ping for v3 review.
Thanks
Chuanxiao
> -Original Message-
> From: Dong, Chuanxiao
> Sent: Wednesday, April 5, 2017 10:05 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: intel-gvt-...@lists.freedesktop.org; Dong, Chuanxiao
>
> Subject: [PATCH v3 0/2] drm/i915/scheduler: add gvt forc
Patchwork writes:
> == Series Details ==
>
> Series: series starting with [1/2] drm/i915: Move the GTFIFODBG to the common
> mmio dbg framework
> URL : https://patchwork.freedesktop.org/series/22571/
> State : warning
>
> == Summary ==
>
> Series 22571v1 Series without cover letter
> https://p
Now that handle_conflicting_encoders no longer touches active state,
so there's no need to do the check quite that late any more.
Doing it with all the other checks makes it a lot more clear what the
below block tries to accomplish, and this feels like a better place to
put the check.
Signed-off-
Now that handle_conflicting_encoders cannot disable crtc's any more
it makes sense to set all the changed flags in 1 place.
This makes the code slightly less magical.
The (now removed) comment is out of date. The only reason the
active_changed was set late was because handle_conflicting_encoders
c
Some small cleanups I came across to make drm_atomic_helper_check_modeset
more readable.
This makes it a lot more clear what atomic_check does and why it's called in
the place it is.
Maarten Lankhorst (4):
drm/atomic: Unify conflicting encoder handling.
drm/atomic: Set all the changed flags i
The atomic_check function is useful for implementing properties, but
it can be used for other connector modeset related checks as well.
Similar to plane check functions, on a modeset atomic_check() is always
called.
Changes since v1:
- Make sure atomic_check() is called on any modeset.
Signed-of
Currently we use a flag to change behavior in atomic commit
whether a conflicting encoder should be enabled or disabled.
This is used for the legacy set_config helper, which disables
connectors that have a conflicting encoder but not part of the
active crtc list.
There's no need for this to be han
On Thu, Apr 06, 2017 at 02:13:44PM +0300, Mika Kuoppala wrote:
> Patchwork writes:
>
> > == Series Details ==
> >
> > Series: series starting with [1/2] drm/i915: Move the GTFIFODBG to the
> > common mmio dbg framework
> > URL : https://patchwork.freedesktop.org/series/22571/
> > State : warni
== Series Details ==
Series: drm/atomic: Cleanups for adding connector atomic check function.
URL : https://patchwork.freedesktop.org/series/22577/
State : success
== Summary ==
Series 22577v1 drm/atomic: Cleanups for adding connector atomic check function.
https://patchwork.freedesktop.org/ap
On Wed, 05 Apr 2017, Manasi Navare wrote:
> I agree with disentangling the fallback rate limiting
> from sink rates and instead just limiting the common_rates array
> based on max link rate.
>
> Reviewed-by:
Pushed patches 1-5 to drm-intel-next-queued, thanks for the review.
BR,
Jani.
>
> Ma
On Wed, 05 Apr 2017, Madhav Chauhan wrote:
> As per BSPEC, valid cdclk values for glk are 79.2, 158.4, 316.8 Mhz.
> Practically we can achive only 99% of these cdclk values (HW team
> checking on this). So cdclk should be calculated for the given pixclk as
> per that otherwise it may lead to scree
[Apologies, I thought I'd sent this, but it was in drafts...]
On Tue, 04 Apr 2017, Sean Paul wrote:
> Launch $EDITOR when extracting tags to curate the tags immediately. Once the
> tags are proper, automatically add them before the first Signed-off-by line
> to all patches in the range.
>
> Sign
On ke, 2017-04-05 at 23:15 +0100, Chris Wilson wrote:
> Many sightings report the greater prevalence of allocation failures.
> This is all due to the incorrect use of mapping_gfp_constraint(), so
> remove it in favour of just querying the mapping_gfp_mask() which are
> the exact gfp_t we wanted in
On Thu, Apr 06, 2017 at 02:55:16PM +0300, Joonas Lahtinen wrote:
> On ke, 2017-04-05 at 23:15 +0100, Chris Wilson wrote:
> > Many sightings report the greater prevalence of allocation failures.
> > This is all due to the incorrect use of mapping_gfp_constraint(), so
> > remove it in favour of just
On Thu, Apr 06, 2017 at 01:18:59PM +0200, Maarten Lankhorst wrote:
> Some small cleanups I came across to make drm_atomic_helper_check_modeset
> more readable.
>
> This makes it a lot more clear what atomic_check does and why it's called in
> the place it is.
>
> Maarten Lankhorst (4):
> drm/at
On Tue, Mar 28, 2017 at 05:38:41PM +0800, Chuanxiao Dong wrote:
> GVT request needs a manual mmio load/restore. Before GuC submit
> a request, send notification to gvt for mmio loading. And after
> the GuC finished this GVT request, notify gvt again for mmio
> restore. This follows the usage when u
v4 of [1], after patches 1-5 have been merged, and with Manasi's patches [2] and
[3] rebased on top.
BR,
Jani.
[1] cover.1490712890.git.jani.nikula@intel.com">http://mid.mail-archive.com/cover.1490712890.git.jani.nikula@intel.com
[2]
http://patchwork.freedesktop.org/patch/msgid/1490651090-4263-1
Now that source rates are static and sink rates are updated whenever
DPCD is updated, we can do and cache the intersection of them whenever
sink rates are updated. This reduces code complexity, as we don't have
to keep calling the functions to intersect. We also get rid of several
common rates arra
In link training fallback, we're trying to find a rate that we know is
in a sorted array of common link rates. We don't need to limit the array
using the max rate. For test request, the DP CTS doesn't say we should
limit the rate based on earlier fallback. This lets us get rid of
intel_dp_link_rate
Localize link_rate_index to the if block, and rename to just index to
reduce indent.
Cc: Manasi Navare
Cc: Ville Syrjälä
Reviewed-by: Manasi Navare
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/
This is what we have the readb and writeb variants for. Do some minor
return value and variable cleanup while at it.
Cc: Manasi Navare
Cc: Ville Syrjälä
Reviewed-by: Manasi Navare
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c | 37 +
1 file
If we modify these on the fly depending on the link conditions, don't
pretend they are sink properties.
Some link vs. sink confusion still remains, but we'll take care of them
in follow-up patches.
Cc: Manasi Navare
Cc: Ville Syrjälä
Reviewed-by: Manasi Navare
Signed-off-by: Jani Nikula
---
The source might not support as many lanes as the sink, or the link
training might have failed at higher lane counts. Take these into
account.
Cc: Dhinakaran Pandiyan
Cc: Manasi Navare
Cc: Ville Syrjälä
Reviewed-by: Manasi Navare
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c
From: Manasi Navare
Currently intel_dp_check_link_status() tries to retrain the link if
Clock recovery or Channel EQ for any of the lanes indicated by
intel_dp->lane_count is not set. However these values cached in intel_dp
structure can be stale if link training has failed for these values
durin
Looking at DPCD DP_MAX_LINK_RATE may be completely bogus for eDP 1.4
which is allowed to use link rate select method and have 0 in max link
rate. With this change, it makes sense to store the max rate as the
actual rate rather than as a bw code.
Cc: Manasi Navare
Cc: Ville Syrjälä
Signed-off-by:
From: Manasi Navare
If link training at a link rate optimal for a particular
mode fails during modeset's atomic commit phase, then we
let the modeset complete and then retry. We save the link rate
value at which link training failed, update the link status property
to "BAD" and use a lower link r
Don't clobber intel_dp->sink_count with the raw value.
Suggested-by: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 81
These are the theoretical maximums common for source and sink. These are
the maximums we should start with. They may be degraded in case of link
training failures, and the dynamic link values are stored separately.
Cc: Manasi Navare
Cc: Ville Syrjälä
Reviewed-by: Manasi Navare
Signed-off-by: Ja
> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Thursday, April 6, 2017 9:32 PM
> To: Dong, Chuanxiao
> Cc: intel-gfx@lists.freedesktop.org; intel-gvt-...@lists.freedesktop.org;
> Zheng, Xiao; Tian, Kevin; joonas.lahti...@linux.intel.com
> Subject: Re:
On Thu, Apr 06, 2017 at 02:05:15PM +, Dong, Chuanxiao wrote:
>
>
> > -Original Message-
> > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> > Sent: Thursday, April 6, 2017 9:32 PM
> > To: Dong, Chuanxiao
> > Cc: intel-gfx@lists.freedesktop.org; intel-gvt-...@lists.freedesktop.o
On Thu, Apr 06, 2017 at 04:44:09PM +0300, Jani Nikula wrote:
> Looking at DPCD DP_MAX_LINK_RATE may be completely bogus for eDP 1.4
> which is allowed to use link rate select method and have 0 in max link
> rate. With this change, it makes sense to store the max rate as the
> actual rate rather tha
On Thu, Apr 06, 2017 at 04:44:17PM +0300, Jani Nikula wrote:
> Don't clobber intel_dp->sink_count with the raw value.
>
> Suggested-by: Ville Syrjälä
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_dp.c | 7 ---
> 1 file changed, 4 insertions(+)
On Thu, Apr 06, 2017 at 04:44:18PM +0300, Jani Nikula wrote:
> From: Manasi Navare
>
> Currently intel_dp_check_link_status() tries to retrain the link if
> Clock recovery or Channel EQ for any of the lanes indicated by
> intel_dp->lane_count is not set. However these values cached in intel_dp
>
== Series Details ==
Series: drm/i915/dp: rest of refactoring, link rate fallback
URL : https://patchwork.freedesktop.org/series/22586/
State : success
== Summary ==
Series 22586v1 drm/i915/dp: rest of refactoring, link rate fallback
https://patchwork.freedesktop.org/api/1.0/series/22586/revis
> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Thursday, April 6, 2017 10:19 PM
> To: Dong, Chuanxiao
> Cc: intel-gfx@lists.freedesktop.org; intel-gvt-...@lists.freedesktop.org;
> Zheng, Xiao; Tian, Kevin; joonas.lahti...@linux.intel.com
> Subject: Re:
On Thu, Apr 06, 2017 at 02:49:54PM +, Dong, Chuanxiao wrote:
>
>
> > -Original Message-
> > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> > Sent: Thursday, April 6, 2017 10:19 PM
> > To: Dong, Chuanxiao
> > Cc: intel-gfx@lists.freedesktop.org; intel-gvt-...@lists.freedesktop.
> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Thursday, April 6, 2017 11:07 PM
> To: Dong, Chuanxiao
> Cc: intel-gfx@lists.freedesktop.org; intel-gvt-...@lists.freedesktop.org;
> Zheng, Xiao; Tian, Kevin; joonas.lahti...@linux.intel.com; Wang, Zhi A
>
Remove the per-mmio checking of the FIFO debug register into the common
conditional mmio debug handling. Based on patch from Chris Wilson.
v2: postpone warn on fifodbg for unclaimed reg debugs
Signed-off-by: Mika Kuoppala
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_uncore.c | 76 +
Replace the handcrafter loop when checking for fifo slots
with atomic wait for. This brings this wait in line with
the other waits on register access. We also get a readable
timeout constraint, so make it to fail after 10ms.
Chris suggested that we should fail silently as the fifo debug
handler, n
On Thu, Apr 06, 2017 at 06:40:16PM +0300, Mika Kuoppala wrote:
> Replace the handcrafter loop when checking for fifo slots
> with atomic wait for. This brings this wait in line with
> the other waits on register access. We also get a readable
> timeout constraint, so make it to fail after 10ms.
>
On Thu, Apr 06, 2017 at 06:39:42PM +0300, Mika Kuoppala wrote:
> Remove the per-mmio checking of the FIFO debug register into the common
> conditional mmio debug handling. Based on patch from Chris Wilson.
>
> v2: postpone warn on fifodbg for unclaimed reg debugs
>
> Signed-off-by: Mika Kuoppala
When we retire the last request on the ring, before we ever access that
ring again we know it will be completely idle and so we can advance the
ring->head fully to the end (i.e. ring->tail) and not just to the start
of the breadcrumb. This allows us to skip re-emitting the breadcrumb
after resettin
== Series Details ==
Series: series starting with [1/2] drm/i915: Move the GTFIFODBG to the common
mmio dbg framework (rev2)
URL : https://patchwork.freedesktop.org/series/22571/
State : success
== Summary ==
Series 22571v2 Series without cover letter
https://patchwork.freedesktop.org/api/1.0
On Thu, Apr 06, 2017 at 06:46:29PM +0300, Ville Syrjälä wrote:
> On Thu, Apr 06, 2017 at 06:39:42PM +0300, Mika Kuoppala wrote:
> > +static bool
> > check_for_unclaimed_mmio(struct drm_i915_private *dev_priv)
> > {
> > + bool ret = false;
> > +
> > if (HAS_FPGA_DBG_UNCLAIMED(dev_priv))
> >
== Series Details ==
Series: series starting with [1/2] drm/i915: Move the GTFIFODBG to the common
mmio dbg framework (rev3)
URL : https://patchwork.freedesktop.org/series/22571/
State : failure
== Summary ==
Series 22571v3 Series without cover letter
https://patchwork.freedesktop.org/api/1.0
On Thu, Apr 06, 2017 at 05:05:10PM +0100, Chris Wilson wrote:
> On Thu, Apr 06, 2017 at 06:46:29PM +0300, Ville Syrjälä wrote:
> > On Thu, Apr 06, 2017 at 06:39:42PM +0300, Mika Kuoppala wrote:
> > > +static bool
> > > check_for_unclaimed_mmio(struct drm_i915_private *dev_priv)
> > > {
> > > + bo
== Series Details ==
Series: series starting with [1/2] drm/i915: Assert the engine is idle before
overwiting the HWS (rev3)
URL : https://patchwork.freedesktop.org/series/22527/
State : success
== Summary ==
Series 22527v3 Series without cover letter
https://patchwork.freedesktop.org/api/1.0
Daniel Vetter writes:
> Atomic helpers really want this instead of the hacked-up legacy
> backoff trick, which unfortunately prevents drivers from using their
> own private drm_modeset_locks.
>
> Aside: There's a few atomic drivers (nv50, vc4, soon vmwgfx) which
> don't yet use the new atomic col
On 05/04/17 17:23, Robert Bragg wrote:
Enables access to OA unit metrics for BDW, CHV, SKL and BXT which all
share (more-or-less) the same OA unit design.
Of particular note in comparison to Haswell: some OA unit HW config
state has become per-context state and as a consequence it is somewhat
mo
When we retire the last request on the ring, before we ever access that
ring again we know it will be completely idle and so we can advance the
ring->head fully to the end (i.e. ring->tail) and not just to the start
of the breadcrumb. This allows us to skip re-emitting the breadcrumb
after resettin
== Series Details ==
Series: series starting with [1/2] drm/i915: Assert the engine is idle before
overwiting the HWS (rev4)
URL : https://patchwork.freedesktop.org/series/22527/
State : success
== Summary ==
Series 22527v4 Series without cover letter
https://patchwork.freedesktop.org/api/1.0
On 06/04/2017 10:30, Chris Wilson wrote:
If we attempt to wake up a waiter, who is currently checking the seqno
it will be in the TASK_INTERRUPTIBLE state and ttwu will report success.
However, it is actually awake and functioning -- so delay reporting the
actual wake up until it sleeps.
v2: D
On 05/04/2017 10:30, Oscar Mateo wrote:
From: Daniele Ceraolo Spurio
In such a way that vcs and vcs2 are just two different instances (0 and 1)
of the same engine class (VIDEO_DECODE_CLASS).
Cc: Tvrtko Ursulin
Cc: Paulo Zanoni
Cc: Rodrigo Vivi
Cc: Chris Wilson
Signed-off-by: Daniele Cerao
On 05/04/2017 10:30, Oscar Mateo wrote:
If we needed to do something different for the init functions, we could
always look at the instance number to make the distinction.But, in any
case, the two functions are virtually identical already (please notice
that BSD2_RING is only used from gen8 onwa
On Thu, Apr 6, 2017 at 6:51 PM, Eric Anholt wrote:
> Daniel Vetter writes:
>> Atomic helpers really want this instead of the hacked-up legacy
>> backoff trick, which unfortunately prevents drivers from using their
>> own private drm_modeset_locks.
>>
>> Aside: There's a few atomic drivers (nv50,
On 05/04/2017 10:30, Oscar Mateo wrote:
Not really needed, but makes the next change a little bit more compact.
Cc: Tvrtko Ursulin
Cc: Paulo Zanoni
Cc: Rodrigo Vivi
Cc: Chris Wilson
Cc: Daniele Ceraolo Spurio
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/intel_engine_cs.c | 8
On 05/04/2017 10:30, Oscar Mateo wrote:
Commit message missing.
Cc: Tvrtko Ursulin
Cc: Paulo Zanoni
Cc: Rodrigo Vivi
Cc: Chris Wilson
Cc: Daniele Ceraolo Spurio
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/intel_engine_cs.c | 72 +-
1 file changed,
On Thu, Apr 06, 2017 at 07:02:10PM +0100, Tvrtko Ursulin wrote:
>
> On 05/04/2017 10:30, Oscar Mateo wrote:
> >@@ -100,6 +100,7 @@
> > {
> > const struct engine_info *info = &intel_engines[id];
> > struct intel_engine_cs *engine;
> >+char instance[3] = "";
> >
> > GEM_BUG_ON(dev_pr
On 04/06/2017 10:48 AM, Tvrtko Ursulin wrote:
On 05/04/2017 10:30, Oscar Mateo wrote:
If we needed to do something different for the init functions, we could
always look at the instance number to make the distinction.But, in any
case, the two functions are virtually identical already (please
On 05/04/2017 10:30, Oscar Mateo wrote:
From: Daniele Ceraolo Spurio
Technically speaking, the context size is per engine class, not per
instance.
It is very nice to have the code match the documentation!
Cc: Tvrtko Ursulin
Cc: Paulo Zanoni
Cc: Rodrigo Vivi
Cc: Chris Wilson
Signed-off-
On 04/06/2017 11:02 AM, Tvrtko Ursulin wrote:
On 05/04/2017 10:30, Oscar Mateo wrote:
Not really needed, but makes the next change a little bit more compact.
Cc: Tvrtko Ursulin
Cc: Paulo Zanoni
Cc: Rodrigo Vivi
Cc: Chris Wilson
Cc: Daniele Ceraolo Spurio
Signed-off-by: Oscar Mateo
---
On Thu, Apr 06, 2017 at 05:31:07PM +0300, Ville Syrjälä wrote:
> On Thu, Apr 06, 2017 at 04:44:18PM +0300, Jani Nikula wrote:
> > From: Manasi Navare
> >
> > Currently intel_dp_check_link_status() tries to retrain the link if
> > Clock recovery or Channel EQ for any of the lanes indicated by
> >
On 06/04/2017 12:22, Oscar Mateo wrote:
On 04/06/2017 11:02 AM, Tvrtko Ursulin wrote:
On 05/04/2017 10:30, Oscar Mateo wrote:
Not really needed, but makes the next change a little bit more compact.
Cc: Tvrtko Ursulin
Cc: Paulo Zanoni
Cc: Rodrigo Vivi
Cc: Chris Wilson
Cc: Daniele Ceraolo S
On Thu, Apr 06, 2017 at 07:37:20PM +0100, Tvrtko Ursulin wrote:
>
> On 06/04/2017 12:22, Oscar Mateo wrote:
> >On 04/06/2017 11:02 AM, Tvrtko Ursulin wrote:
> >>On 05/04/2017 10:30, Oscar Mateo wrote:
> >>>Not really needed, but makes the next change a little bit more compact.
> >>>
> >>>Cc: Tvrtk
mode_valid() called from drm_helper_probe_single_connector_modes()
may need to look at connector->state because what a valid mode is may
depend on connector properties being set. For example some HDMI modes
might be rejected when a connector property forces the connector
into DVI mode.
Some implem
Legacy drivers insist that we really take all the locks in this path,
and the harm in doing so is minimal.
Fixes: 2ceb585a956c ("drm: Add explicit acquire ctx handling around
->set_config")
Cc: Harry Wentland
Cc: Daniel Vetter
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: Sean Paul
Cc: David Airlie
On Thu, Apr 6, 2017 at 2:55 PM, Daniel Vetter wrote:
> Legacy drivers insist that we really take all the locks in this path,
> and the harm in doing so is minimal.
>
> Fixes: 2ceb585a956c ("drm: Add explicit acquire ctx handling around
> ->set_config")
> Cc: Harry Wentland
> Cc: Daniel Vetter
>
Legacy drivers insist that we really take all the locks in this path,
and the harm in doing so is minimal.
v2: Like git add, it exists :(
Fixes: 2ceb585a956c ("drm: Add explicit acquire ctx handling around
->set_config")
Cc: Harry Wentland
Cc: Daniel Vetter
Cc: Daniel Vetter
Cc: Jani Nikula
On Thu, Apr 6, 2017 at 3:06 PM, Daniel Vetter wrote:
> Legacy drivers insist that we really take all the locks in this path,
> and the harm in doing so is minimal.
>
> v2: Like git add, it exists :(
>
> Fixes: 2ceb585a956c ("drm: Add explicit acquire ctx handling around
> ->set_config")
> Cc: Har
== Series Details ==
Series: drm/atomic: Acquire connection_mutex lock in
drm_helper_probe_single_connector_modes, v4.
URL : https://patchwork.freedesktop.org/series/22602/
State : success
== Summary ==
Series 22602v1 drm/atomic: Acquire connection_mutex lock in
drm_helper_probe_single_conne
From: Michel Thierry
v2: rebased to intel_lr_indirect_ctx_offset
Signed-off-by: Michel Thierry
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_lrc.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index f2
From: Ville Syrjälä
Implement the CNL display init/uninit sequence as outlined in Bspec.
Quite similar to SKL/BXT. The main complicaiton is probably the extra
procmon setup we must do based on the process/voltage information we
can read out from some register.
For now we assume DMC will handle
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 f
Cannonlake is a Intel® Processor containing Intel® HD Graphics
following Kabylake.
It is Gen10.
Let's start by adding the platform definition based on previous
platforms but yet as alpha_support.
On following patches we will start adding PCI IDs and the
platform specific changes.
Signed-off-by:
From: Damien Lespiau
Reviewed-by: Rodrigo Vivi
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/i915_pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index cb01822..c84ef7c 100644
--- a/drivers/gpu
The workaround added in
commit c6782b76d31a ("drm/i915/gen9: Reset secondary power well
equests left on by DMC/KVMR")
needs to be applied on Cannonlake as well.
So let's assume any platform using this power well setup
will also need and let's just go ahead and remove if condition.
Cc: Imre Deak
Most of south engine display that is in PCH is still the
same as SPT and KBP, except for this key differences:
- Backlight: Backlight programming changed in CNP PCH.
- Panel Power: Sligh programming changed in CNP PCH.
- GMBUS and GPIO: The pin mapping has changed in CNP PCH.
All of these changes
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 frequ
There is no confirmation if the DC5 to DC6 is available on CNL
though. But I could see DC3 to DC5 counter increasing reliably.
So let's at least add this one.
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_debugfs.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git
1 - 100 of 220 matches
Mail list logo
