Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5674
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV 353/353
Now that we have asynchronous nuclear pageflip, we should be able to
push our legacy pageflip ioctl through the atomic helper and rip out a
bunch of i915-specific pageflip code.
This patch is actually pretty conservative; I think there's a lot more
flip-related infrastructure that should be ripped
Until all drivers have transitioned to atomic, the framebuffer
associated with a plane is tracked in both plane->fb (for legacy) and
plane->state->fb (for all the new atomic codeflow). All of our modeset
and plane updates use drm_plane->update_plane(), so in theory plane->fb
and plane->state->fb s
There are two sets of helper functions provided by the DRM core that can
implement the .update_plane() and .disable_plane() hooks in terms of a
driver's atomic entrypoints. The transitional helpers (which we have
been using so far) create a plane state and then use the plane's atomic
entrypoints t
The initial i915 nuclear pageflip support rejected asynchronous updates.
Allow all work after we swap in the new state structures to run
asynchronously. We also need to start sending completion events to
userspace if they were requested.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/i915_d
The first two patches here were already posted earlier this week; they allow
our legacy plane updates to make use of the main atomic helpers rather than the
transitional atomic helpers. This shouldn't have any functional change, but it
will cause us to exercise the full atomic pipeline rather than
Hi all,
New -testing cycle with cool stuff:
- chv rps improvements from Ville
- atomic state handling prep work from Ander
- execlist request tracking refactoring from Nick Hoath
- forcewake code consolidation from Chris&Mika
- fastboot plane config refactoring and skl support from Damien
- some m
On Fri, Jan 30, 2015 at 5:45 PM, Nick Hoath wrote:
> On 30/01/2015 16:33, Daniel Vetter wrote:
>>
>> On Fri, Jan 30, 2015 at 11:01:30AM +0200, Mika Kuoppala wrote:
>>>
>>> Nick Hoath writes:
>>>
Remove request from list before unreferencing it, in case it's actually
the only reference.
From: Tvrtko Ursulin
To prepare for framebuffer modifiers, move tiling definition from the
object into the framebuffer. Move in a way that framebuffer tiling is
now used for display while object tiling remains for fencing.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_display.c
From: Tvrtko Ursulin
To be used from the new addfb2 extension.
Signed-off-by: Tvrtko Ursulin
---
include/uapi/drm/i915_drm.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 6eed16b..a7327fd 100644
--- a/include/
From: Tvrtko Ursulin
Initialize the simulated ioctl with the new modifier token so it can
be passed on in line with the new API usage.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_display.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/
From: Rob Clark
In DRM/KMS we are lacking a good way to deal with tiled/compressed
formats. Especially in the case of dmabuf/prime buffer sharing, where
we cannot always rely on under-the-hood flags passed to driver specific
gem-create ioctl to pass around these extra flags.
The proposal is to
From: Tvrtko Ursulin
Instead of using driver private set tiling ioctl, use the proposed addfb2 ioctl
extension to tell the driver about display buffer special formatting.
Lightly tested only with a hacked up igt/testdisplay. Sending out early so
people can comment on the overall approach over th
From: Tvrtko Ursulin
Use the fb modifier if it was specified over object tiling mode.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_display.c | 40 +---
1 file changed, 33 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_disp
From: Tvrtko Ursulin
Let the DRM core know we can handle it.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_display.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index ca69da0..1a8d433 100644
-
On Thu, Jan 29, 2015 at 12:42:35PM +, Damien Lespiau wrote:
> Suggested-by: Daniel Vetter
> Signed-off-by: Damien Lespiau
> ---
> drivers/gpu/drm/i915/intel_uncore.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> b/drivers/g
On 30/01/2015 16:33, Daniel Vetter wrote:
On Fri, Jan 30, 2015 at 11:01:30AM +0200, Mika Kuoppala wrote:
Nick Hoath writes:
Remove request from list before unreferencing it, in case it's actually
the only reference. (Found by Tvrtko Ursulin)
Signed-off-by: Nick Hoath
Do we have a Bugzilla
On Fri, Jan 30, 2015 at 12:17:23PM +0200, Ander Conselvan de Oliveira wrote:
> The get_config() functions for ddi and dp_mst, used to read the value
> of cpu_transcoder from the crtc->config instead of the state passed as
> an argument. On the hardware state readout path, that happens to work
> sin
Just updated my thinkpad (x230, ivy bridge platform) to 3.18 and boot
fails with the error 'PCH fifo underrun'. This is under fedora 21 with
the fedora kernel version 3.18.3-201
Platform information:
[jon@localhost]~% lspci
00:00.0 Host bridge: Intel Corporation 3rd Gen Core processor DRAM
C
On Fri, Jan 30, 2015 at 11:01:30AM +0200, Mika Kuoppala wrote:
> Nick Hoath writes:
>
> > Remove request from list before unreferencing it, in case it's actually
> > the only reference. (Found by Tvrtko Ursulin)
> >
> > Signed-off-by: Nick Hoath
Do we have a Bugzilla: or similar report? Also wh
On Thu, Jan 29, 2015 at 04:55:08PM +0200, Ander Conselvan de Oliveira wrote:
> This simplifies __intel_set_mode() a little.
>
> Signed-off-by: Ander Conselvan de Oliveira
>
Merged this one here, please sign up Matt or someone else suitable for the
in-depth review.
-Daniel
> ---
> drivers/gpu/
On Thu, Jan 29, 2015 at 02:11:13PM -0600, Jeff McGee wrote:
> On Thu, Jan 29, 2015 at 02:13:38PM +, Damien Lespiau wrote:
> > We need to have a separate GT3 struct intel_device_info to declare they
> > have a second VCS. Let's start by splitting the PCI ids per-GT.
> >
> Would it be a good ide
On Thu, Jan 29, 2015 at 04:15:55PM +0200, Mika Kuoppala wrote:
> Damien Lespiau writes:
>
> > On Thu, Jan 29, 2015 at 11:32:46AM +, Chris Wilson wrote:
> >> On Thu, Jan 29, 2015 at 11:17:04AM +, Damien Lespiau wrote:
> >> > On Thu, Jan 29, 2015 at 11:12:46AM +, Chris Wilson wrote:
> >
On Thu, Jan 29, 2015 at 12:42:35PM +, Damien Lespiau wrote:
> Suggested-by: Daniel Vetter
> Signed-off-by: Damien Lespiau
Hm, I've thought the magic bit moved ... or have you found it in configdb
again?
-Daniel
> ---
> drivers/gpu/drm/i915/intel_uncore.c | 3 ++-
> 1 file changed, 2 insert
From: Rob Clark
In DRM/KMS we are lacking a good way to deal with tiled/compressed
formats. Especially in the case of dmabuf/prime buffer sharing, where
we cannot always rely on under-the-hood flags passed to driver specific
gem-create ioctl to pass around these extra flags.
The proposal is to
On Wed, Jan 28, 2015 at 02:04:27PM +, Chris Wilson wrote:
> On Wed, Jan 28, 2015 at 03:25:05PM +0200, Mika Kuoppala wrote:
> > The checking for ack and also any subsequent mmio access
> > will serialize with setting the forcewake bit. Drop the
> > posting read as superfluous.
> >
> > Note that
On Thu, Jan 29, 2015 at 01:57:16PM +0200, Ville Syrjälä wrote:
> On Wed, Jan 28, 2015 at 10:29:06AM +, Chris Wilson wrote:
> > On Tue, Jan 27, 2015 at 04:36:16PM +0200, ville.syrj...@linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > Replace the valleyview_set_rps() and gen6_se
On Fri, Jan 30, 2015 at 09:30:07AM +0200, Jani Nikula wrote:
> On Thu, 29 Jan 2015, Jeff McGee wrote:
> > On Thu, Jan 29, 2015 at 02:13:38PM +, Damien Lespiau wrote:
> >> We need to have a separate GT3 struct intel_device_info to declare they
> >> have a second VCS. Let's start by splitting th
On Fri, Jan 30, 2015 at 09:51:48AM -0500, Rob Clark wrote:
> On Fri, Jan 30, 2015 at 9:35 AM, Tvrtko Ursulin
> wrote:
> >
> > On 01/30/2015 01:43 PM, Rob Clark wrote:
> >>
> >> On Fri, Jan 30, 2015 at 5:51 AM, Tvrtko Ursulin
> >> wrote:
>
> +/*
> + * Format Modifier tokens:
>
On 01/29/2015 05:01 PM, Daniel Vetter wrote:
+#define fourcc_mod_code(vendor, val) \
+ u64)DRM_FORMAT_MOD_VENDOR_## vendor) << 56) | (val &
0x00ffL)
Unbalanced parentheses.
Finding them as I go along, sorry! :)
Regards,
Tvrtko
___
On Fri, Jan 30, 2015 at 9:35 AM, Tvrtko Ursulin
wrote:
>
> On 01/30/2015 01:43 PM, Rob Clark wrote:
>>
>> On Fri, Jan 30, 2015 at 5:51 AM, Tvrtko Ursulin
>> wrote:
+/*
+ * Format Modifier tokens:
+ *
+ * When adding a new token please document the layout with a code
On 01/30/2015 01:43 PM, Rob Clark wrote:
On Fri, Jan 30, 2015 at 5:51 AM, Tvrtko Ursulin
wrote:
+/*
+ * Format Modifier tokens:
+ *
+ * When adding a new token please document the layout with a code
comment,
+ * similar to the fourcc codes above. drm_fourcc.h is considered the
+ * authoritativ
On Fri, Jan 30, 2015 at 5:51 AM, Tvrtko Ursulin
wrote:
>> +/*
>> + * Format Modifier tokens:
>> + *
>> + * When adding a new token please document the layout with a code
>> comment,
>> + * similar to the fourcc codes above. drm_fourcc.h is considered the
>> + * authoritative source for all of thes
On Fri, Jan 30, 2015 at 12:01:53AM +0530, Vijay Purushothaman wrote:
> This patch implements latest changes in Gain, lock threshold and integer
> co-efficient values using sideband r/w. Without these changes there will
> be signal integrity issues for both HDMI and DP.
>
> Change-Id: I7b7151b5ab3a
On 01/29/2015 05:01 PM, Daniel Vetter wrote:
[snip]
+
+/*
+ * Format Modifiers:
+ *
+ * Format modifiers describe, typically, a re-ordering or modification
+ * of the data in a plane of an FB. This can be used to express tiled/
+ * swizzled formats, or compression, or a combination of the two
On pe, 2015-01-30 at 12:15 +0200, Jani Nikula wrote:
> On Fri, 30 Jan 2015, Ander Conselvan de Oliveira
> wrote:
> > On the hardware state readout path, using crtc->config happens to work
> > since the proper value is written to it before encoder->get_config() is
> > called. However, in the check
The get_config() functions for ddi and dp_mst, used to read the value
of cpu_transcoder from the crtc->config instead of the state passed as
an argument. On the hardware state readout path, that happens to work
since the proper value is written to it before encoder->get_config() is
called. However,
On Fri, 30 Jan 2015, Ander Conselvan de Oliveira
wrote:
> On the hardware state readout path, using crtc->config happens to work
> since the proper value is written to it before encoder->get_config() is
> called. However, in the check_crtc() path, the state will be read from
> the cpu_transcoder
On the hardware state readout path, using crtc->config happens to work
since the proper value is written to it before encoder->get_config() is
called. However, in the check_crtc() path, the state will be read from
the cpu_transcoder in the software tracking, instead of the one just
read out from hw
Nick Hoath writes:
> Remove request from list before unreferencing it, in case it's actually
> the only reference. (Found by Tvrtko Ursulin)
>
> Signed-off-by: Nick Hoath
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/intel_lrc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(
40 matches
Mail list logo
