Hi,
On 21-02-17 07:21, Srinivas, Vidya wrote:
-Original Message-
From: Nikula, Jani
Sent: Tuesday, February 21, 2017 12:49 AM
To: Hans de Goede ; Srinivas, Vidya
; Paauwe, Bob J
Cc: intel-gfx@lists.freedesktop.org; Chauhan, Madhav
Subject: Re: [Intel-gfx] [PATCH 8/9] drm/i915/bxt: E
> -Original Message-
> From: Nikula, Jani
> Sent: Tuesday, February 21, 2017 12:49 AM
> To: Hans de Goede ; Srinivas, Vidya
> ; Paauwe, Bob J
> Cc: intel-gfx@lists.freedesktop.org; Chauhan, Madhav
>
> Subject: Re: [Intel-gfx] [PATCH 8/9] drm/i915/bxt: Enable BXT DSI dual link
>
> On Mo
>
> No.
>
> IMO Not fixing this immediately through stable is out of the question.
> The deal is that we don't break userspace.
> Having said that, I'm not against a long term vmwgfx-only solution. But
> let's fix this now.
>
> Admittedly we missed testing this but you got to understand that no
No.
IMO Not fixing this immediately through stable is out of the question.
The deal is that we don't break userspace.
Having said that, I'm not against a long term vmwgfx-only solution. But
let's fix this now.
Admittedly we missed testing this but you got to understand that not all
developer team
On 2017.02.20 14:58:25 +0100, Takashi Iwai wrote:
> send_display_send_uevent() sends two environment variable, and the
> first one GVT_DISPLAY_READY is set including a new line at the end of
> the string; that is obviously superfluous and wrong -- at least, it
> *looks* so when you only read the co
On 2/17/2017 3:43 PM, Kelvin Gardiner wrote:
The reply bit of the ring mode register is only valid on Gen 8.
s/reply/replay. Also, from the specs it looks like this bit is reserved
in Gen8 production steppings, so we should be able to drop it entirely.
Thanks,
Daniele
Therefore do not wr
For next time around, pls cc dri-devel (it's in MAINTAINERS,
get_maintainers.pl gets it right) too.
-Daniel
On Mon, Dec 5, 2016 at 10:49 PM, Pierre-Louis Bossart
wrote:
> 100% reproducible issue found on SKL SkullCanyon NUC with two external
> DP daisy-chained monitors in DP/MST mode. When turnin
On Sun, Feb 19, 2017 at 4:21 PM, Thomas Hellstrom wrote:
> So I think we need a quick revert of this commit or a quick stable
> follow-up to unbreak things on our side.
I'd much prefer we just register control nodes for vmwgfx only, with a
commit message explaining in detail what exactly your con
== Series Details ==
Series: series starting with [v2,1/2] drm/i915: Skip clflushes for all non-page
backed objects
URL : https://patchwork.freedesktop.org/series/19976/
State : failure
== Summary ==
Series 19976v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/1
Generalise the skip for physical and stolen objects by skipping anything
we do not have a valid address for inside the sg.
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_gem.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drive
Flushing the cachelines for an object is slow, can be as much as 100ms
for a large framebuffer. We currently do this under the struct_mutex BKL
on execution or on pageflip. But now with the ability to add fences to
obj->resv for both flips and execbuf (and we naturally wait on the fence
before CPU
== Series Details ==
Series: Small clocking code refactor, v2.
URL : https://patchwork.freedesktop.org/series/19974/
State : success
== Summary ==
Series 19974v1 Small clocking code refactor, v2.
https://patchwork.freedesktop.org/api/1.0/series/19974/revisions/1/mbox/
fi-bdw-5557u total:2
On Mon, Feb 20, 2017 at 06:41:04PM +, Matthew Auld wrote:
> On 17 February 2017 at 14:07, Chris Wilson wrote:
> > Flushing the cachelines for an object is slow, can be as much as 100ms
> > for a large framebuffer. We currently do this under the struct_mutex BKL
> > on execution or on pageflip.
With Ville's comments addressed. The main difference now is that what used to be
patches 1 and 2 are now just patch 1.
Paulo Zanoni (3):
drm/i915: unify the x_modeset_calc_cdclk() functions
drm/i915: remove potentially confusing IS_G4X checks
drm/i915: reorganize the get_cdclk assignment
d
There's a lot of duplicated platform-independent logic in the current
modeset_calc_cdclk() functions. Adding cdclk support for more
platforms will only add more copies of this code.
To solve this problem, in this patch we create a new function called
intel_modeset_calc_cdclk() which unifies the pl
Possible problems of the current if-ladder:
- It's a huge if ladder with almost a different check for each of
our platforms.
- It mixes 3 different types of checks: IS_GENX, IS_PLATFORM and
IS_GROUP_OF_PLATFORMS.
- As demonstrated by the recent IS_G4X commit, it's not easy to be
s
The IS_G4X macro is defined as IS_G45 || IS_GM45. We have two points
in our code where we have an if statement checking for GM45 followed
by an else if statement checking for IS_G4X. This can be confusing
since the IS_G4X check won't be catching the previously-checked GM45.
Someone quickly trying t
On Mon, 20 Feb 2017, Hans de Goede wrote:
> Hi,
>
> On 20-02-17 12:00, Jani Nikula wrote:
>> On Mon, 20 Feb 2017, "Srinivas, Vidya" wrote:
>>> Thanks Jani. I will rebase and re-submit and also to remove drm_panel
>>> interface dependency, I am planning to create panel sequence callbacks
>>> in i
On 17 February 2017 at 14:07, Chris Wilson wrote:
> Flushing the cachelines for an object is slow, can be as much as 100ms
> for a large framebuffer. We currently do this under the struct_mutex BKL
> on execution or on pageflip. But now with the ability to add fences to
> obj->resv for both flips
On 17 February 2017 at 14:07, Chris Wilson wrote:
> Generalise the skip for physical and stolen objects by skipping anything
> we do not have a valid address inside the sg.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
___
Intel-gfx mailing
On Mon, 20 Feb 2017, Eric Johansson wrote:
> On 2/20/2017 at 8:41 AM, "Jani Nikula" wrote:
>>
>>On Fri, 17 Feb 2017, Eric Johansson
>>wrote:
>>> On 2/17/2017 at 2:30 PM, "Jani Nikula" wrote:
Relevant bug report
https://bugs.freedesktop.org/show_bug.cgi?id=97822
>>>
>>Depending on how
== Series Details ==
Series: drm/i915/gen9: Increase PCODE request timeout to 100ms
URL : https://patchwork.freedesktop.org/series/19961/
State : success
== Summary ==
Series 19961v1 drm/i915/gen9: Increase PCODE request timeout to 100ms
https://patchwork.freedesktop.org/api/1.0/series/19961/r
On 20/02/2017 16:07, Chris Wilson wrote:
On Mon, Feb 20, 2017 at 03:58:12PM +, Tvrtko Ursulin wrote:
On 30/01/2017 19:44, Chris Wilson wrote:
On Mon, Jan 30, 2017 at 06:07:29PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
i915_gem_ring_notify is more appropriate since we do not ha
On 2/20/2017 at 8:41 AM, "Jani Nikula" wrote:
>
>On Fri, 17 Feb 2017, Eric Johansson
>wrote:
>> On 2/17/2017 at 2:30 PM, "Jani Nikula" wrote:
>>>Relevant bug report
>>>https://bugs.freedesktop.org/show_bug.cgi?id=97822
>>
>Depending on how much you've tweaked the installed system and what
>yo
== Series Details ==
Series: drm/edid: Add EDID_QUIRK_FORCE_8BPC quirk for Rotel RSX-1058
URL : https://patchwork.freedesktop.org/series/19959/
State : failure
== Summary ==
Series 19959v1 drm/edid: Add EDID_QUIRK_FORCE_8BPC quirk for Rotel RSX-1058
https://patchwork.freedesktop.org/api/1.0/se
== Series Details ==
Series: drm/i915: Do .init_clock_gating() earlier to avoid it clobbering
watermarks
URL : https://patchwork.freedesktop.org/series/19953/
State : success
== Summary ==
Series 19953v1 drm/i915: Do .init_clock_gating() earlier to avoid it clobbering
watermarks
https://patc
On Mon, Feb 20, 2017 at 03:58:12PM +, Tvrtko Ursulin wrote:
>
> On 30/01/2017 19:44, Chris Wilson wrote:
> >On Mon, Jan 30, 2017 at 06:07:29PM +, Tvrtko Ursulin wrote:
> >>From: Tvrtko Ursulin
> >>
> >>i915_gem_ring_notify is more appropriate since we do not have
> >>the request informati
On Mon, Feb 20, 2017 at 05:29:44PM +0200, Imre Deak wrote:
> After
> commit 2c7d0602c815277f7cb7c932b091288710d8aba7
> Author: Imre Deak
> Date: Mon Dec 5 18:27:37 2016 +0200
>
> drm/i915/gen9: Fix PCODE polling during CDCLK change notification
>
> there is still one report of the CDCLK-ch
On 30/01/2017 19:44, Chris Wilson wrote:
On Mon, Jan 30, 2017 at 06:07:29PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
i915_gem_ring_notify is more appropriate since we do not have
the request information at this point, but it is simply a
signal from the engine that some request has be
On Mon, Feb 20, 2017 at 04:37:47PM +0100, Tomasz Lis wrote:
> I tested this variant (reverted the change to "pass" variable before
> testing), and it fixes the issue with count=0 as well as possible
> infinite loop issue.
>
> But something needs to be done with the "pass" var, one way or the
> oth
I tested this variant (reverted the change to "pass" variable before
testing), and it fixes the issue with count=0 as well as possible
infinite loop issue.
But something needs to be done with the "pass" var, one way or the other
- commented below.
W dniu 2017-02-18 o 16:37, Chris Wilson pis
After
commit 2c7d0602c815277f7cb7c932b091288710d8aba7
Author: Imre Deak
Date: Mon Dec 5 18:27:37 2016 +0200
drm/i915/gen9: Fix PCODE polling during CDCLK change notification
there is still one report of the CDCLK-change request timing out on a
KBL machine, see the Reference link. On that m
Rotel RSX-1058 is a receiver with 4 HDMI inputs and a HDMI output, all
1.1.
When a sink that supports deep color is connected to the output, the
receiver will send EDIDs that advertise this capability, even if it
isn't possible with HDMI versions earlier than 1.3.
Currently the kernel is assuming
Chris Wilson writes:
> On Mon, Feb 20, 2017 at 04:40:47PM +0200, Mika Kuoppala wrote:
>> Chris Wilson writes:
>>
>> > During initialisation, we set different flags for different
>> > architectures - these should be preserved when we reload the RPS
>> > thresholds. If we use a mmio read, it will
On Mon, Feb 20, 2017 at 02:45:30PM +0100, Michał Winiarski wrote:
> On Fri, Feb 17, 2017 at 04:38:33PM +, Chris Wilson wrote:
> > The hardware requires that the tail pointer only advance in qword units,
> > so assert that the value we write is aligned to qwords, and similarly
> > enforce this r
== Series Details ==
Series: drm/i915/gvt: Fix superfluous newline in GVT_DISPLAY_READY env var
URL : https://patchwork.freedesktop.org/series/19952/
State : success
== Summary ==
Series 19952v1 drm/i915/gvt: Fix superfluous newline in GVT_DISPLAY_READY env
var
https://patchwork.freedesktop.o
Chris Wilson writes:
> During initialisation, we set different flags for different
> architectures - these should be preserved when we reload the RPS
> thresholds. If we use a mmio read, it will first ensure that the
> threshold registers are written before we apply the latch in RP_CONTROL.
>
> S
Chris Wilson writes:
> Disable RPS by setting RP_CONTROL to 0, remembering its earlier value.
> Then adjust the thresholds before re-enabling RP_CONTROL.
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> Cc: sta...@vger.kernel.org
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/
On Mon, Feb 20, 2017 at 04:40:47PM +0200, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > During initialisation, we set different flags for different
> > architectures - these should be preserved when we reload the RPS
> > thresholds. If we use a mmio read, it will first ensure that the
> > thr
On Mon, Feb 20, 2017 at 04:34:43PM +0200, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > Take forcewake for the entire duration of reprogramming the RPS
> > thresholds. By itself it should not achieve much as instead of going
> > into the FIFO, we force the device to wake for the reprograming,
On Mon, Feb 20, 2017 at 04:29:16PM +0200, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > Defer actual enabling of RPS to the set rps routine, called upon
> > enabling and so we only start RPS when all thresholds have been set.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Mika Kuoppala
> > Cc:
Op 20-02-17 om 14:38 schreef Ville Syrjälä:
> On Mon, Feb 20, 2017 at 10:04:06AM +0100, Maarten Lankhorst wrote:
>> Op 17-02-17 om 16:01 schreef ville.syrj...@linux.intel.com:
>>> From: Ville Syrjälä
>>>
>>> In order to make cursor updates actually safe wrt. watermark programming
>>> we have to cl
Chris Wilson writes:
> Defer actual enabling of RPS to the set rps routine, called upon
> enabling and so we only start RPS when all thresholds have been set.
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> Cc: sta...@vger.kernel.org
As discussed in irc, we will need a followup cleanup a
Chris Wilson writes:
> Take forcewake for the entire duration of reprogramming the RPS
> thresholds. By itself it should not achieve much as instead of going
> into the FIFO, we force the device to wake for the reprograming, but it
> should help in regards to the next patch that introduces a read
== Series Details ==
Series: Fix Geminilake DDI power well enable timeouts (rev2)
URL : https://patchwork.freedesktop.org/series/19451/
State : failure
== Summary ==
Series 19451v2 Fix Geminilake DDI power well enable timeouts
https://patchwork.freedesktop.org/api/1.0/series/19451/revisions/2/
For v3 VBTs in vid-mode the delays are part of the VBT sequences, so
we should not also delay ourselves otherwise we get double delays.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/intel_dsi.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/drive
Now that we are no longer bound to the drm_panel_ callbacks, call
MIPI_SEQ_POWER_ON/OFF at the proper place.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/intel_dsi.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers
According to the spec for v2 VBTs we should call MIPI_SEQ_DISPLAY_OFF
before sending SHUTDOWN, where as for v3 VBTs we should send SHUTDOWN
first.
Since the v2 order has known issues, we use the v3 order everywhere,
add a comment documenting this.
Signed-off-by: Hans de Goede
---
drivers/gpu/dr
According to the spec we should call MIPI_SEQ_TEAR_ON and DISPLAY_ON
on enable for cmd-mode, just like we already call their counterparts
on disable. Note: untested, my panel is a vid-mode panel.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/intel_dsi.c | 2 ++
1 file changed, 2 insertio
Move the DPOunit clock gate workaround to directly after the PLL enable.
The exact location of the workaround does not matter and there are 2
reasons to group it with the PLL enable:
1) This moves it out of the middle of the init sequence from the spec,
making it easier to follow the init sequ
MIPI_SEQ_ASSERT_RESET before POWER_ON is not necessary for 2 reasons:
1) The reset should already be asserted before intel_dsi_pre_enable()
gets called
2) Most (some?) VBTs will ensure reset was asserted in their
MIPI_SEQ_DEASSERT_RESET themselves
Signed-off-by: Hans de Goede
---
drivers/g
For v3 VBTs we should call MIPI_SEQ_TEAR_OFF before
MIPI_SEQ_DISPLAY_OFF, for non v3 VBTs this is a nop.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/intel_dsi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index
The drm_panel_enable/disable and drm_panel_prepare/unprepare calls are
not fine grained enough to abstract all the different steps we need to
take (and VBT sequences we need to exec) properly. So simply remove the
panel _enable/disable and prepare/unprepare callbacks and instead
export intel_dsi_ex
Execute MIPI_SEQ_DEASSERT_RESET before putting the device in ready
state (LP-11), this is the sequence in which things should be done
according to the spec.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/intel_dsi.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --gi
Execute the MIPI_SEQ_BACKLIGHT_ON/OFF VBT sequences at the same time as
we call intel_panel_enable_backlight() / intel_panel_disable_backlight().
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/intel_dsi.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gp
intel_dsi_disable/enable only have one caller, merge them into their
respective callers.
Change msleep(2) into usleep_range(2000, 5000) to make checkpatch happy,
otherwise no functional changes.
The main advantage of this change is that it makes it easier to
follow all the steps of the panel enab
Instead of calling wait_for_dsi_fifo_empty on all dsi ports after calling
a drm_panel_foo helper which calls VBT sequences, move it to the VBT
mipi_exec_send_packet helper, which is the one VBT instruction which
actually puts data in the fifo.
This results in a nice cleanup making it clearer what
Hi All,
Here is a resend of my "cleanup dsi enable / disable sequences" patch
series as requested by Jani.
Here is the original cover letter, there have been no changes other then
dropping 3 patches which have already been merged:
So while trying to fix my cherrytrail tablet's screen sometimes n
Document the DSI panel enable / disable sequences from the spec,
for easy comparison between the code and the spec.
Signed-off-by: Hans de Goede
Acked-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dsi.c | 68
1 file changed, 68 insertions(+)
diff --git
Move the intel_dsi_clear_device_ready() function to higher up in
intel_dsi.c this pairs it with intel_dsi_device_ready(); and pairs
intel_dsi_*enable* with intel_dsi_*disable without
intel_dsi_clear_device_ready() sitting in the middle of them.
This commit purely moves code around, it does not mak
The enable path has an intel_dsi_prepare() helper which prepares various
registers for the mode-set. Move the code undoing this to a new
intel_dsi_unprepare() helper function for better symmetry between the
enable and disable paths. No functional changes.
Signed-off-by: Hans de Goede
Acked-by: Ja
From: Ville Syrjälä
Currently ILK-BDW explicitly disable LP1+ watermarks from their
.init_clock_gating() hooks. Unfortunately that hook gets called way too
late since by that time we've already initialized all the watermark
state tracking which then gets out of sync with the hardware state.
We m
send_display_send_uevent() sends two environment variable, and the
first one GVT_DISPLAY_READY is set including a new line at the end of
the string; that is obviously superfluous and wrong -- at least, it
*looks* so when you only read the code.
However, it doesn't appear in the actual output by a
== Series Details ==
Series: drm/i915: Remove Braswell GGTT update w/a
URL : https://patchwork.freedesktop.org/series/19942/
State : success
== Summary ==
Series 19942v1 drm/i915: Remove Braswell GGTT update w/a
https://patchwork.freedesktop.org/api/1.0/series/19942/revisions/1/mbox/
fi-bdw-5
On Fri, Feb 17, 2017 at 04:38:33PM +, Chris Wilson wrote:
> The hardware requires that the tail pointer only advance in qword units,
> so assert that the value we write is aligned to qwords, and similarly
> enforce this restriction onto the request->tail.
>
> Signed-off-by: Chris Wilson
> Cc:
On Mon, Feb 20, 2017 at 10:04:06AM +0100, Maarten Lankhorst wrote:
> Op 17-02-17 om 16:01 schreef ville.syrj...@linux.intel.com:
> > From: Ville Syrjälä
> >
> > In order to make cursor updates actually safe wrt. watermark programming
> > we have to clear the legacy_cursor_update flag in the atomic
On Mon, 2017-02-20 at 09:47 +, Chris Wilson wrote:
> During initialisation, we set different flags for different
> architectures - these should be preserved when we reload the RPS
> thresholds. If we use a mmio read, it will first ensure that the
> threshold registers are written before we appl
Hi,
On 16-02-17 17:58, Ville Syrjälä wrote:
On Thu, Feb 16, 2017 at 11:01:29AM +0100, Hans de Goede wrote:
Hi,
On 15-02-17 15:59, Ville Syrjälä wrote:
On Wed, Feb 15, 2017 at 03:54:17PM +0100, Hans de Goede wrote:
Hi Jani,
As discussed here:
https://bugs.freedesktop.org/show_bug.cgi?id=948
On Thu, Feb 09, 2017 at 08:20:58AM +, Chris Wilson wrote:
> Another bug found first in the wild...
>
> Signed-off-by: Chris Wilson
> Cc: Petri Latvala
Behaviour on farm2 looks alright.
Acked-by: Petri Latvala
> ---
> tests/intel-ci/fast-feedback.testlist | 1 +
> 1 file changed, 1 ins
According to bspec, the DDI IO power domains should be enabled after
enabling the DPLL and mapping it to the DDI. The current order doesn't
seem to create problems with Skylake and Kabylake, but causes enable
timeouts in Geminilake.
v2: Rebase.
- Take power domain references before sanitizing en
In Geminilake, the DDI IO power domains can't be enabled before a DPLL
is running and mapped to the appropriate DDI. At least on Geminilake,
attempting to enable those during init will lead to a timeout.
The failure to enable the power domain also causes issues with the state
verifier during resum
Implement WaDDIIOTimeout to avoid a timeout when enabling the DDI IO
power domains.
Signed-off-by: Ander Conselvan de Oliveira
Reviewed-by: Imre Deak
---
drivers/gpu/drm/i915/i915_drv.h | 6 ++
drivers/gpu/drm/i915/i915_reg.h | 5 +
drivers/gpu/drm/i915/intel_pm.c | 10 ++
3
The encoder power domain is obviously tied to the encoder, so store it
in struct intel_encoder. This avoids some indirection.
v2: Rebase
Signed-off-by: Ander Conselvan de Oliveira
Reviewed-by: Imre Deak
---
drivers/gpu/drm/i915/intel_crt.c | 21 +
drivers/gpu/drm/i915/i
The aux power domain only makes sense in the DP code. Storing it in
struct intel_dp avoids some indirection.
v2: Rebase
Signed-off-by: Ander Conselvan de Oliveira
Reviewed-by: Imre Deak
---
drivers/gpu/drm/i915/intel_display.c | 50 -
drivers/gpu/drm/i915/intel_dp.c
Ander Conselvan de Oliveira (5):
drm/i915: Store aux power domain in intel_dp
drm/i915: Store encoder power domain in struct intel_encoder
drm/i915/glk: Implement WaDDIIOTimeout
drm/i915/glk: Don't enable DDI IO power domains during init
drm/i915: Only enable DDI IO power domains after en
On Fri, Feb 17, 2017 at 07:52:12PM +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Fix clearing of BIOS power well requests (rev2)
> URL : https://patchwork.freedesktop.org/series/19699/
> State : success
Pushed to dinq, thanks for the review.
--Imre
>
> == Summary ==
>
Testing with concurrent GGTT accesses no longer show the coherency
problems from yonder, commit 5bab6f60cb4d ("drm/i915: Serialise updates
to GGTT with access through GGTT on Braswell"). My presumption is that
the root cause was more likely fixed by commit 3b5724d702ef ("drm/i915:
Wait for writes t
On Mon, Feb 20, 2017 at 11:15:23AM +, Szwichtenberg, Radoslaw wrote:
> On Mon, 2017-02-20 at 09:47 +, Chris Wilson wrote:
> > The uncached mmio is sufficient to queue the mmio writes without raising
> > forcewake. The forced flush along with acquiring forcewake from the
> > posting read is
On Mon, 2017-02-20 at 09:47 +, Chris Wilson wrote:
> If intel_set_rps() is called whilst the hw is disabled, just store the
> requested frequency (from the user) for application when we wake the hw
> up.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Radoslaw Szwichtenberg
On Mon, 2017-02-20 at 09:47 +, Chris Wilson wrote:
> Disable RPS by setting RP_CONTROL to 0, remembering its earlier value.
> Then adjust the thresholds before re-enabling RP_CONTROL.
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> Cc: sta...@vger.kernel.org
Reviewed-by: Radoslaw Szwic
Op 10-02-17 om 17:29 schreef Shashank Sharma:
> Geminilake platform sports a native HDMI 2.0 controller, and is
> capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec
> mendates scrambling for these higher clocks, for reduced RF footprint.
>
> This patch checks if the monitor supports scrambl
Op 20-02-17 om 13:03 schreef Chris Wilson:
> On Mon, Feb 20, 2017 at 01:32:42PM +0200, Joonas Lahtinen wrote:
>> On pe, 2017-02-17 at 18:35 +, Chris Wilson wrote:
>>> The code currently assumes that all fence arrays it sees are the normal
>>> signal-on-all variety, and decomposes the array into
Op 18-02-17 om 13:08 schreef Tahvanainen, Jari:
> Hello folks,
>
> I took some time and executed these tests on the latest drm-tip and would
> propose for fluent execution that we will have few test-groups excluded from
> this list with comment #FIXME and action to have bugs on each of these
> s
On Mon, Feb 20, 2017 at 01:32:42PM +0200, Joonas Lahtinen wrote:
> On pe, 2017-02-17 at 18:35 +, Chris Wilson wrote:
> > The code currently assumes that all fence arrays it sees are the normal
> > signal-on-all variety, and decomposes the array into its individual
> > fences so that it can extr
On Mon, 20 Feb 2017, Hans de Goede wrote:
> Hi,
>
> On 20-02-17 12:00, Jani Nikula wrote:
>> On Mon, 20 Feb 2017, "Srinivas, Vidya" wrote:
>>> Thanks Jani. I will rebase and re-submit and also to remove drm_panel
>>> interface dependency, I am planning to create panel sequence callbacks
>>> in i
Hi,
On 20-02-17 12:00, Jani Nikula wrote:
On Mon, 20 Feb 2017, "Srinivas, Vidya" wrote:
Thanks Jani. I will rebase and re-submit and also to remove drm_panel
interface dependency, I am planning to create panel sequence callbacks
in intel_dsi structure itself. Is this approach okay?
I think
On pe, 2017-02-17 at 18:35 +, Chris Wilson wrote:
> The code currently assumes that all fence arrays it sees are the normal
> signal-on-all variety, and decomposes the array into its individual
> fences so that it can extract the native i915 fences. If the fence array
> is using signal-on-any,
On 20/02/2017 11:22, Patchwork wrote:
== Series Details ==
Series: drm/i915: Fix typo in semaphore debug message
URL : https://patchwork.freedesktop.org/series/19937/
State : success
== Summary ==
Series 19937v1 drm/i915: Fix typo in semaphore debug message
https://patchwork.freedesktop.org
== Series Details ==
Series: drm/i915: Fix typo in semaphore debug message
URL : https://patchwork.freedesktop.org/series/19937/
State : success
== Summary ==
Series 19937v1 drm/i915: Fix typo in semaphore debug message
https://patchwork.freedesktop.org/api/1.0/series/19937/revisions/1/mbox/
On Mon, 2017-02-20 at 09:47 +, Chris Wilson wrote:
> The uncached mmio is sufficient to queue the mmio writes without raising
> forcewake. The forced flush along with acquiring forcewake from the
> posting read is not required for adjusting the RPS frequency.
>
> Signed-off-by: Chris Wilson
R
On Mon, Feb 20, 2017 at 11:02:10AM +, Szwichtenberg, Radoslaw wrote:
> On Sat, 2017-02-18 at 11:27 +, Chris Wilson wrote:
> > Either by chance, or by misread, the current evaluation interval may be
> > zero. If that is the case, don't divide by it!
> >
> > Signed-off-by: Chris Wilson
> Re
The dynamic plane support means that if there's no cursor plane, then
there is no space in the pipe->planes array for it, and thus assigning
a "drm_plane-less" plane is out-of-bounds and leads to heap corruption
and later crashes.
The "drm_plane-less" cursor plane isn't included in n_planes anyway
Remove a bunch of branches, functionally equivalent.
Changes since v1:
- Added back display->has_cursor_plane assignment
Signed-off-by: Brian Starkey
Reviewed-by: Robert Foss
---
lib/igt_kms.c | 33 ++---
1 file changed, 10 insertions(+), 23 deletions(-)
diff --
If there's no primary plane, pipe->plane_primary == -1, and the assert
meant to check that it's valid will access pipe->planes[-1].
Fix that to check that pipe->plane_primary has been set instead.
Fixes: 36656239ef96 lib/igt_kms: Implement dynamic plane count support
Signed-off-by: Brian Starkey
The dynamic plane support means that there should never be gaps in the
pipe->planes array. This means we should never need to move the cursor
plane from the last slot to another.
Remove the unnecessary code, and add an assert that makes sure nothing
strange happened that broke the assignment logic
On Sat, 2017-02-18 at 11:27 +, Chris Wilson wrote:
> Either by chance, or by misread, the current evaluation interval may be
> zero. If that is the case, don't divide by it!
>
> Signed-off-by: Chris Wilson
Reviewed-by: Radoslaw Szwichtenberg
___
In
In the loop looking for planes on a pipe, we always want to free up
the drm_plane afterwards.
Fixes: 36656239ef96 lib/igt_kms: Implement dynamic plane count support
Signed-off-by: Brian Starkey
Reviewed-by: Robert Foss
---
lib/igt_kms.c |8 +++-
1 file changed, 3 insertions(+), 5 deleti
On Mon, 20 Feb 2017, "Srinivas, Vidya" wrote:
> Thanks Jani. I will rebase and re-submit and also to remove drm_panel
> interface dependency, I am planning to create panel sequence callbacks
> in intel_dsi structure itself. Is this approach okay?
I think that's unnecessary overhead. I've come to
On Mon, Feb 20, 2017 at 10:46:57AM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Pronounces less rude when fixed.
>
> Signed-off-by: Tvrtko Ursulin
I make that typo so often, I can't believe it's the only one.
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Tec
On to, 2017-02-16 at 06:18 -0800, Oscar Mateo wrote:
> Starting with intel_guc_loader, down to intel_guc_submission
> and finally to intel_guc_log.
>
> Signed-off-by: Oscar Mateo
> -static void guc_client_free(struct i915_guc_client *client)
> +static void guc_client_free(struct i915_guc_clien
1 - 100 of 131 matches
Mail list logo
