On 21/04/17 13:21, Chris Wilson wrote:
On Fri, Apr 21, 2017 at 01:10:37PM -0700, Daniele Ceraolo Spurio wrote:
On 21/04/17 13:07, Michel Thierry wrote:
On 20/04/17 10:29, Michel Thierry wrote:
On 20/04/17 09:39, Daniele Ceraolo Spurio wrote:
On 20/04/17 04:33, Joonas Lahtinen wrote:
On Fri, Apr 21, 2017 at 01:10:37PM -0700, Daniele Ceraolo Spurio wrote:
>
>
> On 21/04/17 13:07, Michel Thierry wrote:
> >
> >
> >On 20/04/17 10:29, Michel Thierry wrote:
> >>
> >>
> >>On 20/04/17 09:39, Daniele Ceraolo Spurio wrote:
> >>>
> >>>
> >>>On 20/04/17 04:33, Joonas Lahtinen wrote:
> >>
On 21/04/17 13:07, Michel Thierry wrote:
On 20/04/17 10:29, Michel Thierry wrote:
On 20/04/17 09:39, Daniele Ceraolo Spurio wrote:
On 20/04/17 04:33, Joonas Lahtinen wrote:
On ke, 2017-04-19 at 11:35 -0700, Michel Thierry wrote:
From: Arun Siluvery
GuC expects a list of registers fr
On 20/04/17 10:29, Michel Thierry wrote:
On 20/04/17 09:39, Daniele Ceraolo Spurio wrote:
On 20/04/17 04:33, Joonas Lahtinen wrote:
On ke, 2017-04-19 at 11:35 -0700, Michel Thierry wrote:
From: Arun Siluvery
GuC expects a list of registers from the driver which are
saved/restored
durin
== Series Details ==
Series: drm/i915: Two stage watermarks for g4x
URL : https://patchwork.freedesktop.org/series/23358/
State : success
== Summary ==
Series 23358v1 drm/i915: Two stage watermarks for g4x
https://patchwork.freedesktop.org/api/1.0/series/23358/revisions/1/mbox/
fi-bdw-5557u
From: Ville Syrjälä
The g4x watermark TLB miss workaround requires that we bump up the
watermark by the difference between 8 full lines and the FIFO size.
Unfortunately the way we compute it at the moment ignores the size
of the pixels. The code also used the primary plane width as the
cursor wid
From: Ville Syrjälä
Implement proper two stage watermark programming for g4x. As with
other pre-SKL platforms, the watermark registers aren't double
buffered on g4x. Hence we must sequence the watermark update
carefully around plane updates.
The code is quite heavily modelled on the VLV/CHV code
From: Ville Syrjälä
I don't see why we couldn't use the HPLL watermarks on g4x. So let's
enable them. Let's assume a 35 usec memory latency for the HPLL mode.
That's roughly what PNV uses.
Based on the behaviour of the ELK box I have 35 usec is probably
overkill. Actually all the current latency
From: Ville Syrjälä
Now that the watermarks are in order, it should be safe to enable sprite
planes on g4x. We alreday have the code in fact, we just call it ilk_.
Let's rename to g4x_ and let it loose.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_device_info.c | 2 +-
drivers/
From: Ville Syrjälä
Add a tracepoint for watermark programming on g4x, similar to what we
have on vlv/chv. Should help in debugging watermark programming sequence
issues.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_trace.h | 49 +++
drivers/gp
From: Ville Syrjälä
All platforms until SKL compute their watermarks essentially
using the same method1/small buffer and method2/large buffer
formulas. Most just open code it in slightly different ways.
Let's pull it all into common helpers. This makes it a little
easier to spot the actual differ
From: Ville Syrjälä
The documentation I've seen doesn't actually specify which watermarks
need the TLB miss w/a. Currently we only apply the w/a to the normal
watermarks for both primary and cursor planes. Since the documentation
doesn't explicitly say anything I'm going to assume that the w/a sh
From: Ville Syrjälä
Pull the g4x TLB miss w/a calculation into a small helper.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 27 ---
1 file changed, 20 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i91
From: Ville Syrjälä
Add some documentation explaining what CxSR actually is.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 37 +
1 file changed, 37 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_
From: Ville Syrjälä
The watermark code for the old platforms (g4x and older) uses the
primary plane cpp when computing cursor watermarks. To keep the fix
simple let's just hardcode cpp=4 for the cursor on those platforms
since that's all we support.
Signed-off-by: Ville Syrjälä
---
drivers/gpu
From: Ville Syrjälä
Rename the VLV/CHV max_level->num_levels helper to have an intel_
prefix since it's not VLV/CHV specific and I'll want to use it on
other platforms as well.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 18 +-
1 file changed, 9 insertion
From: Ville Syrjälä
The magic numbers 0,1,2 aren't all that interesting for users perhaps.
Since we know what these watermark levels mean for VLV/CHV let's print
their names.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Ville Syrjälä
We'll be wanting to share some of these watermark structures on g4x,
so let's rename them to have a g4x_ prefix instead of vlv_.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h | 8
drivers/gpu/drm/i915/intel_drv.h | 6 +++---
drivers/gpu/drm/i9
From: Ville Syrjälä
Rename some of the vlv wm functions to reflect the fact that they
operate on the "raw" watermarks.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i
From: Ville Syrjälä
Seeing the display FIFO sizes at driver load time doesn't really provide
anything useful for us, so let's just drop the debug message. One can
always use eg. intel_watermarks to dump out the hardware settings prior
to loading the driver.
Signed-off-by: Ville Syrjälä
---
dri
From: Ville Syrjälä
This makes g4x follow the two stage watermark programming approach as
well, and as a bonus exposes the video sprites on g4x.
There is one slight problem with merging the wms from multiple pipes;
If one pipe is currently enabled and we're about to enabled another one,
we shoul
On Thu, Apr 20, 2017 at 11:50:02PM +0200, Daniel Vetter wrote:
> On Thu, Apr 20, 2017 at 10:11 PM, Sean Paul wrote:
> > Hi Dave,
> > A few fixes for you to pick up. The driver changes are trivial, and the
> > maintainer change was necessitated by the sti fix. The headliner here is the
> > dma_buf_
On Tue, Apr 18, 2017 at 04:45:29PM -0700, Oscar Mateo wrote:
> This test got inadvertently disabled by commit 83884e97 (Restore
> "lib: Open debugfs files for the given DRM device").
>
> Cc: Jeff McGee
> Cc: Chris Wilson
> Signed-off-by: Oscar Mateo
Reviewed-by: Michał Winiarski
-Michał
> -
On Fri, Apr 21, 2017 at 02:26:14PM -, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Avoid busy-spinning on VLV_GLTC_PW_STATUS mmio (rev2)
> URL : https://patchwork.freedesktop.org/series/23340/
> State : success
>
> == Summary ==
>
> Series 23340v2 drm/i915: Avoid busy-spin
On 21 April 2017 at 03:20, Daniel Vetter wrote:
>> - Rename dma_buf_ops->kmap_* to avoid naming collision (Logan)
>
> This one touches v4l and ion and is acked by the corresponding
> maintainers (but Sumit forgot to record that when applying the patch,
> and Sean didn't highlight it in the summar
From: Tvrtko Ursulin
Tool which emits batch buffers to engines with configurable
sequences, durations, contexts, dependencies and userspace waits.
Unfinished but shows promise so sending out for early feedback.
v2:
* Load workload descriptors from files. (also -w)
* Help text.
* Calibration
== Series Details ==
Series: drm/i915: Avoid busy-spinning on VLV_GLTC_PW_STATUS mmio (rev2)
URL : https://patchwork.freedesktop.org/series/23340/
State : success
== Summary ==
Series 23340v2 drm/i915: Avoid busy-spinning on VLV_GLTC_PW_STATUS mmio
https://patchwork.freedesktop.org/api/1.0/ser
The busy-spin, as the first stage of intel_wait_for_register(), is
currently under suspicion for causing:
[ 62.034926] NMI watchdog: Watchdog detected hard LOCKUP on cpu 1
[ 62.034928] Modules linked in: i2c_dev i915 intel_gtt drm_kms_helper
prime_numbers
[ 62.034932] CPU: 1 PID: 183 Comm:
On Fri, Apr 21, 2017 at 02:00:40PM +0100, Chris Wilson wrote:
> The busy-spin, as the first stage of intel_wait_for_register, is
> currently under suspicion for causing:
>
> [ 62.034926] NMI watchdog: Watchdog detected hard LOCKUP on cpu 1
> [ 62.034928] Modules linked in: i2c_dev i915 intel_g
== Series Details ==
Series: drm/i915: Avoid busy-spinning on VLV_GLTC_PW_STATUS mmio
URL : https://patchwork.freedesktop.org/series/23340/
State : failure
== Summary ==
Series 23340v1 drm/i915: Avoid busy-spinning on VLV_GLTC_PW_STATUS mmio
https://patchwork.freedesktop.org/api/1.0/series/233
The busy-spin, as the first stage of intel_wait_for_register, is
currently under suspicion for causing:
[ 62.034926] NMI watchdog: Watchdog detected hard LOCKUP on cpu 1
[ 62.034928] Modules linked in: i2c_dev i915 intel_gtt drm_kms_helper
prime_numbers
[ 62.034932] CPU: 1 PID: 183 Comm: kw
Hi,
On 21-04-17 13:38, Andy Shevchenko wrote:
On Fri, 2017-04-21 at 12:47 +0200, Hans de Goede wrote:
Several Bay / Cherry Trail devices (all of which ship with Windows 10)
hide
the LPSS PWM controller in ACPI, typically the _STA method looks like
this:
Method (_STA, 0, NotSerialized) //
On Fri, 2017-04-21 at 12:47 +0200, Hans de Goede wrote:
> Several Bay / Cherry Trail devices (all of which ship with Windows 10)
> hide
> the LPSS PWM controller in ACPI, typically the _STA method looks like
> this:
>
> Method (_STA, 0, NotSerialized) // _STA: Status
> {
> If (OSI
Hi,
On 21-04-17 12:40, Rafael J. Wysocki wrote:
On Friday, April 21, 2017 12:42:31 PM Hans de Goede wrote:
HI,
[cut]
And in that path, which I seem to have overlooked before, the
acpi_set_device_status() call is too early for invoking
acpi_device_always_present(adev), so the latter should
Several Bay / Cherry Trail devices (all of which ship with Windows 10) hide
the LPSS PWM controller in ACPI, typically the _STA method looks like this:
Method (_STA, 0, NotSerialized) // _STA: Status
{
If (OSID == One)
{
Return (Zero)
}
Return
The INT0002 device is necessary to clear wakeup interrupt sources
on Cherry Trail devices, without it we get nobody cared IRQ msgs
and some systems don't properly resume at all without it.
Signed-off-by: Hans de Goede
---
Changes in v6:
-This is a new patch in v6 of this patch-set
Changes in v7:
On Friday, April 21, 2017 12:42:31 PM Hans de Goede wrote:
> HI,
>
[cut]
> >>> And in that path, which I seem to have overlooked before, the
> >>> acpi_set_device_status() call is too early for invoking
> >>> acpi_device_always_present(adev), so the latter should be called
> >>> directly from ac
On Friday, April 21, 2017 11:59:34 AM Hans de Goede wrote:
> Hi,
>
> On 19-04-17 22:14, Rafael J. Wysocki wrote:
> > On Wed, Apr 19, 2017 at 2:04 PM, Hans de Goede wrote:
> >> Several Bay / Cherry Trail devices (all of which ship with Windows 10) hide
> >> the LPSS PWM controller in ACPI, typical
HI,
On 21-04-17 12:33, Rafael J. Wysocki wrote:
On Friday, April 21, 2017 11:59:34 AM Hans de Goede wrote:
Hi,
On 19-04-17 22:14, Rafael J. Wysocki wrote:
On Wed, Apr 19, 2017 at 2:04 PM, Hans de Goede wrote:
Several Bay / Cherry Trail devices (all of which ship with Windows 10) hide
the LP
Hi,
On 19-04-17 22:14, Rafael J. Wysocki wrote:
On Wed, Apr 19, 2017 at 2:04 PM, Hans de Goede wrote:
Several Bay / Cherry Trail devices (all of which ship with Windows 10) hide
the LPSS PWM controller in ACPI, typically the _STA method looks like this:
Method (_STA, 0, NotSerialized) /
On Fri, Apr 21, 2017 at 08:50:26AM -, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Stop touching hangcheck.seqno from
> intel_engine_init_global_seqno()
> URL : https://patchwork.freedesktop.org/series/23320/
> State : success
>
> == Summary ==
>
> Series 23320v1 drm/i915
== Series Details ==
Series: drm/i915: Stop touching hangcheck.seqno from
intel_engine_init_global_seqno()
URL : https://patchwork.freedesktop.org/series/23320/
State : success
== Summary ==
Series 23320v1 drm/i915: Stop touching hangcheck.seqno from
intel_engine_init_global_seqno()
https://
On Fri, Apr 21, 2017 at 11:12:21AM +0300, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > The hangcheck runs independently to the main flow of seqno through the
> > driver. However, we have an odd coupling of the seqno reset that is
> > unwelcome, and if poked at just the right rate can cause s
The hangcheck runs independently to the main flow of seqno through the
driver. However, we have an odd coupling of the seqno reset that is
unwelcome, and if poked at just the right rate can cause spurious hangs
(e.g. gem_exec_whisper) on an apparently idle engine.
Signed-off-by: Chris Wilson
Cc:
Chris Wilson writes:
> The hangcheck runs independently to the main flow of seqno through the
> driver. However, we have an odd coupling of the seqno reset that is
> unwelcome, and if poked at just the right rate can cause spurious hangs
> (e.g. gem_exec_whisper) on an apparently idle engine.
>
>
45 matches
Mail list logo
