== Series Details ==
Series: series starting with [CI,1/4] drm/i915: Add distinct stubs for PM
hibernation phases
URL : https://patchwork.freedesktop.org/series/7181/
State : warning
== Summary ==
Series 7181v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/7181/r
Currently for handling the extra hibernation phases we just call the
equivalent suspend/resume phases. In the next couple of patches, I wish
to specialise the hibernation phases to reduce the amount of work
required for handling GEM objects.
v2: There are more! Don't forget the freeze phases.
Sig
Now that we mark the object domains for having been restored from the
hibernation image, we not need to flush everything during resume and
can instead rely on the normal domain tracking to flush only when
required. The only caveat here are objects that are pinned for use by
the hardware, whose cont
Under full-ppgtt, access to the global GTT is carefully regulated
through hardware functions (i.e. userspace cannot read and write to
arbitrary locations in the GGTT via the GPU). With this restriction in
place, we can forgo clearing stale entries from the GGTT as they will
not be accessed.
For al
When creating the hibernation image, the CPU will read the pages of all
objects and thus conflict with our domain tracking. We need to update
our domain tracking to accurately reflect the state on restoration.
v2: Perform the domain tracking inside freeze, before the image is
written, rather than
== Series Details ==
Series: drm/i915: SKL/KBL/BXT cdclk stuff
URL : https://patchwork.freedesktop.org/series/7169/
State : failure
== Summary ==
Series 7169v1 drm/i915: SKL/KBL/BXT cdclk stuff
http://patchwork.freedesktop.org/api/1.0/series/7169/revisions/1/mbox
Test gem_exec_flush:
== Series Details ==
Series: drm/i915: Refresh cached DP port register value on resume
URL : https://patchwork.freedesktop.org/series/7163/
State : failure
== Summary ==
Series 7163v1 drm/i915: Refresh cached DP port register value on resume
http://patchwork.freedesktop.org/api/1.0/series/7163
On Fri, May 13, 2016 at 07:04:07PM +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Fix for resume regression in ilk-bdw due to watermarks
> (rev2)
> URL : https://patchwork.freedesktop.org/series/7155/
> State : failure
>
> == Summary ==
>
> Series 7155v2 drm/i915: Fix fo
From: Ville Syrjälä
Make bxt_set_cdclk() more readable by looking at current vs. target
DE PLL vco to determine if the DE PLL needs disabling and/or enabling.
We can also calculate the CD2X divider simply as (vco/cdclk) instead of
depending on magic numbers.
The magic numbers are still needed th
From: Ville Syrjälä
Now that we've read out the DE PLL vco and refclk, we can just use them
in the cdclk calculation. While at it switch over to
DIV_ROUND_CLOSEST().
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 33 +++--
1 file changed, 19
From: Ville Syrjälä
In case the driver is initialized without active displays, we should
just drop the cdclk to the minimum frequency right off the bat. There
might not be a modeset to drop it to the minimum late rafter all.
With DMC supposedly we should always have the cdclk up and running.
The
From: Ville Syrjälä
We have need to know the DE PLL refclk and output frequency in various
cdclk calculations, so let's store those in dev_priv.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 27 ++-
1 file changed, 26 insertions(+), 1 deletion(
From: Ville Syrjälä
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index e65c3da744b0..95997eed9dd6 100644
--- a/drive
From: Ville Syrjälä
Currently we're trying to guess which lcpll vco frequency is used
use based on the cdclk. That doesn't work for cdclk==540 since
both vco frequencies can generate a 540 Mhz output. Let's stop
guessing and just read the actual vco frequency from the
hardware.
Signed-off-by: Vi
From: Ville Syrjälä
Let's make sure our cached cdclk state is accurate right after
broxton_init_cdclk() whether or not we end up changing the cdclk
frequency.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
d
From: Ville Syrjälä
Rather than having a BXT specific function to make sure the DE PLL is
enabled after disabling DC6, let's just make sure the current cdclk
is the same as what we last programmed.
Having another check in bxt_display_core_init() almost immediately after
the cdclk init seems redu
From: Ville Syrjälä
SKL and BXT have the same snippets of code for enabling disabling the
DBUF. Extract those into helpers and move the calls from
init/unit_cdclk() to the display core init/init since this stuff isn't
really about cdclk. Also doing the enable twice shouldn't hurt since
you're jus
From: Ville Syrjälä
Enabling and disalbing the DE PLL are two nice self contained
operations, so let's move them into a few small helper functions.
Makes it easier to see the forest from the trees in broxton_set_cdclk().
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 4
From: Ville Syrjälä
Future platforms will have multiple options for the cdclk PLL reference
clock, so let's start tracking that under dev_priv alreday on SKL,
although on SKL it's always 24 MHz.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915
From: Ville Syrjälä
The SKL 308.57 MHz cdclk is probably 8640/28 = ~308.571 Mhz.
Similartly the 617.14 MHz cdclk is probably 8640/14 = ~617.143 MHz.
Let's use the slightly more accurate numbers. Potentially we might
change to computing all of these based on dividers, but let's
stick to the curren
From: Ville Syrjälä
We'll want to store the cdclk PLL (whatever PLL that is in reality) vco
frequency somewhere on other platforms too, so let's rename the
skl_vco_freq to cdclk_pll.vco, and let's store it in kHz instead of MHz
to match most of the other clocks.
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
In case we originally guessed wrong which lcpll vco frequency to use,
we will need to shut down the pll and restart it when reprogamming the
cdclk.
This also allows us to track the actual vco frequency in dev_priv
instead of just a guess.
Signed-off-by: Ville Syrjälä
---
d
From: Ville Syrjälä
Now that skl_vco_freq tracks the actual DPLL0 vco frequency, we'll need
something that keeps track of which vco frequency we want to use in case
the current vco is 0. This would be important across supend/resume since
we'll disable DPLL0 around those parts.
We'll also update
From: Ville Syrjälä
Also verify the DPLL_CTRL1 register value in skl_sanitize_cdclk(), throw
out a few unneeded variables, and write the CDCLK_CTL check a bit more
legible way.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 18 +-
1 file changed, 13 ins
From: Ville Syrjälä
Currently we initialize cdclk on SKL from two different places,
depending on whether it's during driver init or resume. Let's
unify it to happen from the same place always, and that place will be
the display core init function.
To do this we first run through the cdclk sanita
From: Ville Syrjälä
We have many places where we want to pick a suitable cdclk frequency for
skl based on the dotclock and lcpll vco. Split that code into a small
helper and call it from all over.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 63 +-
From: Ville Syrjälä
Shared plls won't get assigned until the .compute_clocks() hook gets
called, which happens from the crtc .atomic_check hook. That's too late
as the cdclk computation has already happened. So let's move the DPLL0
VCO computation into intel_dp_compute_config() so that it's done
From: Ville Syrjälä
commit 4e5ca60fd35a ("drm/i915: Use ilk_max_pixel_rate() for BXT cdclk
calculation")
tried to change BXT to use ilk_max_pixel_rate() to compute the
pipe pixel rate. I failed to notice that there was another place
in the state readout code that needs the same treatment. So let
From: Clint Taylor
WARNING: Using ChromeOS with an eDP panel and a 4K@60 DP monitor connected
to DDI1 the system will hard hang during a cold boot. Occurs when DDI1
is enabled when the cdclk is less then required. DP connected to DDI2
and HPD on either port works correctly.
Set cdclk based on th
From: Ville Syrjälä
Here's my second installment of SKL+ cdclk stuff. I've picked up Clint's latest
SKL/KBL cdclk patch and expanded on it quite a bit. After this series we're
capable of actually changing the DPLL0 VCO frequency dynamically, and a lot of
the code gets a much more uniform feel to
== Series Details ==
Series: series starting with [1/4] drm/i915: Add distinct stubs for PM
hibernation phases (rev7)
URL : https://patchwork.freedesktop.org/series/7063/
State : failure
== Summary ==
Applying: drm/i915: Add distinct stubs for PM hibernation phases
Applying: drm/i915: Update
== Series Details ==
Series: drm/i915: Fix for resume regression in ilk-bdw due to watermarks (rev2)
URL : https://patchwork.freedesktop.org/series/7155/
State : failure
== Summary ==
Series 7155v2 drm/i915: Fix for resume regression in ilk-bdw due to watermarks
http://patchwork.freedesktop.or
On Wed, May 11, 2016 at 10:44:39PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Here's a bunch of cleanup, refactoring, etc. of the cdclk code. Much of
> this serves as prep work for a larger series I have lined up which
> takes Clint's SKL cdclk patch, expands on it, and
From: Ville Syrjälä
During hibernation the cached DP port register value will be left with
whatever value we have there when we create the hibernation image.
Currently that means the port (and eDP PLL) will be off in the cached
value. However when we resume there is no guarantee that the value
in
On Fri, May 13, 2016 at 10:35:16AM -0700, Matt Roper wrote:
> On Fri, May 13, 2016 at 08:18:18PM +0300, Ville Syrjälä wrote:
> > On Fri, May 13, 2016 at 09:58:55AM -0700, Matt Roper wrote:
> > > On Fri, May 13, 2016 at 05:55:18PM +0300, ville.syrj...@linux.intel.com
> > > wrote:
> > > > From: Vill
Now that we mark the object domains for having been restored from the
hibernation image, we not need to flush everything during resume and
can instead rely on the normal domain tracking to flush only when
required. The only caveat here are objects that are pinned for use by
the hardware, whose cont
When creating the hibernation image, the CPU will read the pages of all
objects and thus conflict with our domain tracking. We need to update
our domain tracking to accurately reflect the state on restoration.
v2: Perform the domain tracking inside freeze, before the image is
written, rather than
Currently for handling the extra hibernation phases we just call the
equivalent suspend/resume phases. In the next couple of patches, I wish
to specialise the hibernation phases to reduce the amount of work
required for handling GEM objects.
v2: There are more! Don't forget the freeze phases.
Sig
Under full-ppgtt, access to the global GTT is carefully regulated
through hardware functions (i.e. userspace cannot read and write to
arbitrary locations in the GGTT via the GPU). With this restriction in
place, we can forgo clearing stale entries from the GGTT as they will
not be accessed.
For al
On Fri, May 13, 2016 at 08:18:18PM +0300, Ville Syrjälä wrote:
> On Fri, May 13, 2016 at 09:58:55AM -0700, Matt Roper wrote:
> > On Fri, May 13, 2016 at 05:55:18PM +0300, ville.syrj...@linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > When we resume the watermark register may cont
On Fri, May 13, 2016 at 09:58:55AM -0700, Matt Roper wrote:
> On Fri, May 13, 2016 at 05:55:18PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > When we resume the watermark register may contain some BIOS leftovers,
> > or just the hardware reset values. We should igno
From: Ville Syrjälä
When we resume the watermark register may contain some BIOS leftovers,
or just the hardware reset values. We should ignore those as the
pipes will be off anyway, and so frobbing around with intermediate
watermarks doesn't make much sense.
In fact I think we should just throw
== Series Details ==
Series: drm/i915: Use DRM_DEBUG_KMS instead of DRM_DEBUG_ATOMIC in modeset
error paths
URL : https://patchwork.freedesktop.org/series/7158/
State : failure
== Summary ==
Series 7158v1 drm/i915: Use DRM_DEBUG_KMS instead of DRM_DEBUG_ATOMIC in
modeset error paths
http://p
On Fri, May 13, 2016 at 05:55:18PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> When we resume the watermark register may contain some BIOS leftovers,
> or just the hardware reset values. We should ignore those as the
> pipes will be off anyway, and so frobbing around wit
== Series Details ==
Series: Enable GuC submission
URL : https://patchwork.freedesktop.org/series/7153/
State : failure
== Summary ==
Series 7153v1 Enable GuC submission
http://patchwork.freedesktop.org/api/1.0/series/7153/revisions/1/mbox
Test drv_hangman:
Subgroup error-state-basic:
== Series Details ==
Series: drm/i915: Fix for resume regression in ilk-bdw due to watermarks
URL : https://patchwork.freedesktop.org/series/7155/
State : failure
== Summary ==
CC drivers/usb/host/xhci-trace.o
CC [M] drivers/video/fbdev/core/sysfillrect.o
CC [M] drivers/video/fbde
== Series Details ==
Series: series starting with [1/4] drm/i915: Add distinct stubs for PM
hibernation phases (rev4)
URL : https://patchwork.freedesktop.org/series/7063/
State : failure
== Summary ==
Applying: drm/i915: Add distinct stubs for PM hibernation phases
Applying: drm/i915: Update
== Series Details ==
Series: Move dpio access out of intel_display.c
URL : https://patchwork.freedesktop.org/series/7150/
State : failure
== Summary ==
Series 7150v1 Move dpio access out of intel_display.c
http://patchwork.freedesktop.org/api/1.0/series/7150/revisions/1/mbox
Test drv_hangman:
On 13/05/16 15:36, Dave Gordon wrote:
For now, anything with a GuC requires uCode loading, and then supports
command submission once loaded. But these are logically distinct from
simply "having a GuC", so we need a separate macro for the latter. Then,
various tests should use this new macro rath
On 13/05/16 15:36, Dave Gordon wrote:
Rather than wait to see whether more space becomes available in the GuC
submission workqueue, we can just return -EAGAIN and let the caller try
again in a little while. This gets rid of an uninterruptable sleep in
the polling code :)
We'll also add a counte
On 13/05/16 15:36, Dave Gordon wrote:
Split the function of "enable_guc_submission" into two separate
options. The new one ("enable_guc_loading") controls only the
*fetching and loading* of the GuC firmware image. The existing
one is redefined to control only the *use* of the GuC for batch
subm
From: Ville Syrjälä
DRM_DEBUG_ATOMIC generates a lot of noise that no one normally cares
about. However error paths everyone cares about, so hiding the error
debugs under DRM_DEBUG_ATOMIC is a bad idea. Let's use DRM_DEBUG_KMS
for those instead.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm
This reverts commit a633ad03c6a0e96eecfd4933ea0dffb68ed40e07 as it
completely breaks building the gem_concurrent_blit tests.
---
tests/Makefile.am | 12 +++-
tests/Makefile.sources | 22 ++
2 files changed, 5 insertions(+), 29 deletions(-)
diff --git a/tests/Makef
On 13/05/16 15:36, Dave Gordon wrote:
The GuC initialisation code could do other things apart from loading
firmware, so here we rename the three primary entry points to remove any
specific reference to "ucode" (no functional changes, just renaming).
Signed-off-by: Dave Gordon
---
drivers/gpu
On 13/05/16 15:04, Jani Nikula wrote:
Also make the code more readable.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_dma.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 547100fa31
On 13/05/16 15:47, Jani Nikula wrote:
On Fri, 13 May 2016, Chris Wilson wrote:
On Fri, May 13, 2016 at 03:25:05PM +0100, Tvrtko Ursulin wrote:
On 13/05/16 15:04, Jani Nikula wrote:
This is more robust for assignments and comparisons.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i
== Series Details ==
Series: series starting with [RESEND,1/2] drm/i915: make device info bitfield
flags bools
URL : https://patchwork.freedesktop.org/series/7149/
State : failure
== Summary ==
Series 7149v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/7149/revi
From: Ville Syrjälä
When we resume the watermark register may contain some BIOS leftovers,
or just the hardware reset values. We should ignore those as the
pipes will be off anyway, and so frobbing around with intermediate
watermarks doesn't make much sense.
In fact I think we should just throw
From: Ville Syrjälä
When we read out the watermark state from the hardware we're supposed to
transfer that into the active watermarks, but currently we fail to any
part of the active watermarks that isn't explicitly written. Let's clear
it all upfront.
Looks like this has been like this since th
From: Ville Syrjälä
My ILK was very unhappy runnin BAT tests. Caused by watermark fail during
resume.
Here's the smallest fix I thought of.
Ville Syrjälä (2):
drm/i915: Don't leave old junk in ilk active watermarks on readout
drm/i915: Ignore stale wm register values on resume on ilk-bdw
On Fri, 13 May 2016, Chris Wilson wrote:
> On Fri, May 13, 2016 at 03:25:05PM +0100, Tvrtko Ursulin wrote:
>>
>> On 13/05/16 15:04, Jani Nikula wrote:
>> >This is more robust for assignments and comparisons.
>> >
>> >Signed-off-by: Jani Nikula
>> >---
>> > drivers/gpu/drm/i915/i915_drv.h | 2 +-
On Fri, May 13, 2016 at 05:14:58PM +0300, Ander Conselvan de Oliveira wrote:
> Prefix struct dpll with intel_ to follow the convention in the driver.
>
> Cc: Ville Syrjälä
> Signed-off-by: Ander Conselvan de Oliveira
>
> ---
> drivers/gpu/drm/i915/i915_drv.h | 2 +-
> drivers/gpu/drm/i9
On Thu, May 12, 2016 at 10:52:11PM +, Patchwork wrote:
> == Series Details ==
>
> Series: Pre-calculate SKL-style atomic watermarks (final CI run) (rev2)
> URL : https://patchwork.freedesktop.org/series/7075/
> State : success
Maarten confirmed on IRC that his r-b stands for the updated ver
This patchset covers various GuC-related changes, but most important of
these are (1) splitting the original "enable_guc_submission" parameter
into separate flags for loading GuC firmware vs. using the GuC for job
submission [PATCH 3/7], and (2) actually enabling GuC submission by
default on suitab
Mostly little optimisations and future-proofing against code breakage.
For instance, if the driver is correctly following the submission
protocol, the "out of space" condition is impossible, so the previous
runtime WARN_ON() is promoted to a GEM_BUG_ON() for a more dramatic
effect in development an
This patch simply changes the default value of "enable_guc_submission"
from 0 (never) to -1 (auto). This means that GuC submission will be
used if the platform has a GuC, the GuC supports the request submission
protocol, and any required GuC firmwware was successfully loaded. If any
of these condit
For now, anything with a GuC requires uCode loading, and then supports
command submission once loaded. But these are logically distinct from
simply "having a GuC", so we need a separate macro for the latter. Then,
various tests should use this new macro rather than HAS_GUC_UCODE() or
testing enable
Split the function of "enable_guc_submission" into two separate
options. The new one ("enable_guc_loading") controls only the
*fetching and loading* of the GuC firmware image. The existing
one is redefined to control only the *use* of the GuC for batch
submission once the firmware is loaded.
In a
Rather than wait to see whether more space becomes available in the GuC
submission workqueue, we can just return -EAGAIN and let the caller try
again in a little while. This gets rid of an uninterruptable sleep in
the polling code :)
We'll also add a counter to the GuC client statistics, to see ho
The knowledge of how to derive the relevant client from the request
should be localised within i915_guc_submission.c; the LRC code shouldn't
have to know about the internal details of the GuC submission process.
And all the information the GuC code needs should be encapsulated in (or
reachable from
The GuC initialisation code could do other things apart from loading
firmware, so here we rename the three primary entry points to remove any
specific reference to "ucode" (no functional changes, just renaming).
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_dma.c | 6 +++---
On 10/05/16 15:37, Tvrtko Ursulin wrote:
On 06/05/16 17:39, Dave Gordon wrote:
On 29/04/16 16:03, Tvrtko Ursulin wrote:
[snip]
+goto fail;
+if (fw_path == NULL)
+goto fail;
+if (*fw_path == '\0') {
+DRM_ERROR("No GuC firmware known for this platform\n");
It
On Fri, May 13, 2016 at 03:25:05PM +0100, Tvrtko Ursulin wrote:
>
> On 13/05/16 15:04, Jani Nikula wrote:
> >This is more robust for assignments and comparisons.
> >
> >Signed-off-by: Jani Nikula
> >---
> > drivers/gpu/drm/i915/i915_drv.h | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
On Fri, May 13, 2016 at 05:15:02PM +0300, Ander Conselvan de Oliveira wrote:
> Reading the dividers depends on sideband messaging, so it fits well if
> the other functions in intel_dpio_phy.c. The new function will also be
> used in a future patch.
>
> Signed-off-by: Ander Conselvan de Oliveira
>
Currently for handling the extra hibernation phases we just call the
equivalent suspend/resume phases. In the next couple of patches, I wish
to specialise the hibernation phases to reduce the amount of work
required for handling GEM objects.
v2: There are more! Don't forget the freeze phases.
Sig
Now that we mark the object domains for having been restored from the
hibernation image, we not need to flush everything during resume and
can instead rely on the normal domain tracking to flush only when
required. The only caveat here are objects that are pinned for use by
the hardware, whose cont
Under full-ppgtt, access to the global GTT is carefully regulated
through hardware functions (i.e. userspace cannot read and write to
arbitrary locations in the GGTT via the GPU). With this restriction in
place, we can forgo clearing stale entries from the GGTT as they will
not be accessed.
For al
When creating the hibernation image, the CPU will read the pages of all
objects and thus conflict with our domain tracking. We need to update
our domain tracking to accurately reflect the state on restoration.
v2: Perform the domain tracking inside freeze, before the image is
written, rather than
On Fri, May 13, 2016 at 05:15:03PM +0300, Ander Conselvan de Oliveira wrote:
> This simplifies the pll enable/disable a code a bit and hides the
> sideband message neatly in intel_dpio_phy.c.
>
> Signed-off-by: Ander Conselvan de Oliveira
>
> ---
> drivers/gpu/drm/i915/i915_drv.h | 2 ++
On 13/05/16 15:04, Jani Nikula wrote:
This is more robust for assignments and comparisons.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
ind
On Fri, May 13, 2016 at 05:15:01PM +0300, Ander Conselvan de Oliveira wrote:
> Reading the dividers depends on sideband messaging, so it fits well if
> the other functions in intel_dpio_phy.c. The new function will also be
> used in a future patch.
>
> Signed-off-by: Ander Conselvan de Oliveira
>
This simplifies the pll enable/disable a code a bit and hides the
sideband message neatly in intel_dpio_phy.c.
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/intel_display.c | 19 ++-
drivers/gpu/drm/i915/intel
With the bulk of the dpio code moved out of the vlv/chv prepare pll
functions into intel_dpio_phy.c, those functions became simple enough
that they can be merged with the pll enabling function, that always
succeeds the prepare call.
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm
Reading the dividers depends on sideband messaging, so it fits well if
the other functions in intel_dpio_phy.c. The new function will also be
used in a future patch.
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/intel_display.
Reading the dividers depends on sideband messaging, so it fits well if
the other functions in intel_dpio_phy.c. The new function will also be
used in a future patch.
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/intel_display.
Hide the dpio details of setting up the dplls on VLV/CHV to
intel_dpio_phy.c. This will allow the prepare and enable pll functions
to be merged in a follow up. It also creates a better split of the code
where most of the dpio access are concentrated in one place.
Signed-off-by: Ander Conselvan de
Prefix struct dpll with intel_ to follow the convention in the driver.
Cc: Ville Syrjälä
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/intel_ddi.c | 2 +-
drivers/gpu/drm/i915/intel_display.c | 76 +
Hi,
This series moves all of the calls to vlv_dpio_{read,write} to
intel_dpio_phy.c. I think it simplifies the surrounding code a bit.
Thanks,
Ander
Ander Conselvan de Oliveira (6):
drm/i915: Rename struct dpll to struct intel_dpll
drm/i915: Move dpio code of VLV/CHV dpll enabling to intel_d
This is more robust for assignments and comparisons.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d9d07b70f05c..bb0b6f64000e 100644
--- a/
Also make the code more readable.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_dma.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 547100fa3122..a8c79f6512a4 100644
--- a/drivers/gpu/d
Fairly simple stuff, pushed the series to igt.
BR,
Jani.
On Thu, 12 May 2016, Jani Nikula wrote:
> Signed-off-by: Jani Nikula
> ---
> tools/intel_bios_reader.c | 52
> +++
> 1 file changed, 30 insertions(+), 22 deletions(-)
>
> diff --git a/tools/i
== Series Details ==
Series: series starting with [1/2] drm: Add aux plane verification in addFB2
(rev3)
URL : https://patchwork.freedesktop.org/series/4641/
State : failure
== Summary ==
Applying: drm: Add aux plane verification in addFB2
Applying: drm/i915: Render decompression support for
This patch includes enabling render decompression (RC) after checking
all the requirements (format, tiling, rotation etc.).
TODO:
1. Disable stereo 3D when render decomp is enabled (bit 7:6)
2. Render decompression must not be used in VTd pass-through mode
3. Program hashing select CHICKEN_MISC1 b
On Thu, 12 May 2016, Scott Long wrote:
> I'd like to offer a heads-up on the ongoing work in the FreeBSD project
> to update to a contemporary version of the i915 driver.
I inadvertently let this through the moderation while Scott had reposted
as subscriber. Please ignore this one and keep the co
On Thu, May 12, 2016 at 03:28:16PM +0100, Chris Wilson wrote:
> Under full-ppgtt, access to the global GTT is carefully regulated
> through hardware functions (i.e. userspace cannot read and write to
> arbitrary locations in the GGTT via the GPU). With this restriction in
> place, we can forgo clea
On Thu, May 12, 2016 at 03:28:15PM +0100, Chris Wilson wrote:
> Now that we mark the object domains for having been restored from the
> hibernation image, we not need to flush everything during resume and
> can instead rely on the normal domain tracking to flush only when
> required. The only cavea
On Fri, May 13, 2016 at 03:24:32PM +0300, Imre Deak wrote:
> On Thu, 2016-05-12 at 15:31 +, Patchwork wrote:
> > == Series Details ==
> >
> > Series: drm/i915: Fix a few code checker errors
> > URL : https://patchwork.freedesktop.org/series/7071/
> > State : failure
> >
> > == Summary ==
>
On 13.05.2016 15:00, Chris Wilson wrote:
On Fri, May 13, 2016 at 02:45:09PM +0300, Gabriel Feceoru wrote:
basic-flip-vs-wf_vblank subtest sometimes fails asserting counted frames to
be aproximately equal with the estimated number.
This is a false negative, one of the reasons being the precisi
Hello intel-gfx,
I'd like to offer a heads-up on the ongoing work in the FreeBSD project
to update to a contemporary version of the i915 driver.
For context, some background information on the earlier approaches we've
taken to import the i915 driver in FreeBSD. In the past, developers often
rewor
> I don't have any FreeBSD experience and I don't know what kind of team
> of developers you have, but it is my educated guess that you'll have
> plenty of more productive things to do than trying to maintain a
> significant amount of delta with upstream while also trying to stay
> up-to-date.
I a
1 - 100 of 147 matches
Mail list logo
