Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5876
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV -8 278/278
On Fri, Feb 20, 2015 at 11:15 PM, Michel Thierry
wrote:
> From: Ben Widawsky
>
> Up until now, ppgtt->pdp has always been the root of our page tables.
> Legacy 32b addresses acted like it had 1 PDP with 4 PDPEs.
>
> In preparation for 4 level page tables, we need to stop use ppgtt->pdp
> directly
On Fri, Feb 20, 2015 at 11:15 PM, Michel Thierry
wrote:
> From: Ben Widawsky
>
> The code for 4lvl works just as one would expect, and nicely it is able
> to call into the existing 3lvl page table code to handle all of the
> lower levels.
>
> PML4 has no special attributes, and there will always
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5875
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV -5 278/278
Universal planes allow us to have an active CRTC without a primary plane
framebuffer bound. Drop the test for primary->fb from
intel_crtc_active() since we can clearly have active CRTC's without a
framebuffer, and this check is now interfering with watermark
calculations when we try to re-enable t
Current ILK-style watermark code assumes the primary plane and cursor
plane are always enabled. This assumption, along with the combination
of two independent commits that got merged at the same time, results in
a NULL dereference. The offending commits are:
commit fd2d61341bf39d1054256c
On Sun, Mar 01, 2015 at 10:41:37AM +, Chris Wilson wrote:
> i915.ko depends upon the acpi/video.ko module and so refuses to load if
> ACPI is disabled at runtime if for example the BIOS is broken beyond
> repair. acpi/video provides an optional service for i915.ko and so we
> should just allow
On Fri, Feb 13, 2015 at 11:23 AM, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Kill the blt/render tracking we currently have and use the frontbuffer
> tracking infrastructure.
>
> Don't enable things by default yet.
>
> v2: (Rodrigo) Fix small conflict on rebase and typo at subject.
> v3: (Paulo
Reviewed-by: Rodrigo Vivi
On Fri, Feb 13, 2015 at 11:23 AM, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> We need this for FBC, and possibly for PSR too.
>
> v2: Don't only flush: invalidate too (Daniel).
>
> Signed-off-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/i915_gem.c | 23
Sorry for the long delay here.
Reviewed-by: Rodrigo Vivi
On Fri, Feb 13, 2015 at 11:23 AM, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> We want to port FBC to the frontbuffer tracking infrastructure, but
> for that we need to know what caused the object invalidation so
> we can react according
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5874
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV -4 278/278
On 03/03/2015 04:06 PM, Daniel Vetter wrote:
> On Tue, Mar 3, 2015 at 10:15 PM, Chris Wilson
> wrote:
>> On Tue, Mar 03, 2015 at 11:23:53AM -0800, Jesse Barnes wrote:
>>> On 03/03/2015 09:03 AM, Daniel Vetter wrote:
This is useful for writing igts to make sure we don't break this,
witho
On Tue, Mar 3, 2015 at 10:15 PM, Chris Wilson wrote:
> On Tue, Mar 03, 2015 at 11:23:53AM -0800, Jesse Barnes wrote:
>> On 03/03/2015 09:03 AM, Daniel Vetter wrote:
>> > This is useful for writing igts to make sure we don't break this,
>> > without being forced to own a one of these dinosaurs.
>>
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5873
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV -5 278/278
On Tue, Mar 03, 2015 at 11:23:53AM -0800, Jesse Barnes wrote:
> On 03/03/2015 09:03 AM, Daniel Vetter wrote:
> > This is useful for writing igts to make sure we don't break this,
> > without being forced to own a one of these dinosaurs.
> >
> > Suggested-by: Jesse Barnes
> > Cc: Matt Roper
> > S
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5872
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV -7 278/278
On 03/03/2015 09:03 AM, Daniel Vetter wrote:
> This is useful for writing igts to make sure we don't break this,
> without being forced to own a one of these dinosaurs.
>
> Suggested-by: Jesse Barnes
> Cc: Matt Roper
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_drv.h| 1
On Tue, 03 Mar 2015, "Brian J. Murrell" wrote:
> On Tue, 2015-03-03 at 20:40 +0200, Jani Nikula wrote:
>>
>> You'll lose the flicker with LCD,
>
> Even with an analog DSUB input? I only ask again due to the confusion
> below...
Yes. You may get other artefacts due to the D/A-A/D conversions and
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5871
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV -5 278/278
On Tue, 2015-03-03 at 20:40 +0200, Jani Nikula wrote:
>
> You'll lose the flicker with LCD,
Even with an analog DSUB input? I only ask again due to the confusion
below...
> but given a digital source
I don't have a digital source. I have a 15-pin DSUB analog source.
> and a
> digital display
On Tue, 03 Mar 2015, "Brian J. Murrell" wrote:
> Slightly off on a tangent... do LCD screens driven through the DSUB have
> the same flicker issues as CRTs or does that somehow get washed out by
> the difference between LCD and CRT technology?
You'll lose the flicker with LCD, but given a digital
On Tue, Mar 03, 2015 at 05:11:12PM +, Damien Lespiau wrote:
> On Tue, Mar 03, 2015 at 05:05:52PM +, Chris Wilson wrote:
> > On Tue, Mar 03, 2015 at 02:20:03PM +, Damien Lespiau wrote:
> > > On Tue, Dec 09, 2014 at 04:53:01PM +, Damien Lespiau wrote:
> > > > Right that leaves the las
On Tue, Mar 03, 2015 at 09:12:47AM -0800, Linus Torvalds wrote:
> On Tue, Mar 3, 2015 at 9:11 AM, Daniel Vetter wrote:
> >
> > Fine with me. If you haven't pushed out yet can you maybe clarify the
> > commit message?
>
> Oh well. I already applied and tagged it, so it's what it is..
No biggie, t
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5870
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV -5 278/278
On Tue, Mar 03, 2015 at 05:13:41PM +, Chris Wilson wrote:
> On Tue, Mar 03, 2015 at 05:11:12PM +, Damien Lespiau wrote:
> > On Tue, Mar 03, 2015 at 05:05:52PM +, Chris Wilson wrote:
> > > On Tue, Mar 03, 2015 at 02:20:03PM +, Damien Lespiau wrote:
> > > > On Tue, Dec 09, 2014 at 04:
On Tue, Mar 3, 2015 at 9:11 AM, Daniel Vetter wrote:
>
> Fine with me. If you haven't pushed out yet can you maybe clarify the
> commit message?
Oh well. I already applied and tagged it, so it's what it is..
Linus
___
Intel-gfx mai
On Tue, Mar 03, 2015 at 05:05:52PM +, Chris Wilson wrote:
> On Tue, Mar 03, 2015 at 02:20:03PM +, Damien Lespiau wrote:
> > On Tue, Dec 09, 2014 at 04:53:01PM +, Damien Lespiau wrote:
> > > Right that leaves the last point in my answer to v3. With that addressed
> > > this is:
> > >
>
On Tue, Mar 03, 2015 at 09:03:32AM -0800, Linus Torvalds wrote:
> On Tue, Mar 3, 2015 at 8:31 AM, Daniel Vetter wrote:
> >
> > Fix this all by applying the same duct-tape as for the legacy setcrtc
> > ioctl code and set crtc->primary->crtc properly.
>
> Ack. Tests fine on the machine that showed
On Tue, Mar 3, 2015 at 8:31 AM, Daniel Vetter wrote:
>
> Fix this all by applying the same duct-tape as for the legacy setcrtc
> ioctl code and set crtc->primary->crtc properly.
Ack. Tests fine on the machine that showed issues for me.
I'll apply it manually directly to my tree, since I want to
On Tue, Mar 03, 2015 at 02:20:03PM +, Damien Lespiau wrote:
> On Tue, Dec 09, 2014 at 04:53:01PM +, Damien Lespiau wrote:
> > Right that leaves the last point in my answer to v3. With that addressed
> > this is:
> >
> > Reviewed-by: Damien Lespiau
>
> Hum it seems that we've upstreamed t
This is useful for writing igts to make sure we don't break this,
without being forced to own a one of these dinosaurs.
Suggested-by: Jesse Barnes
Cc: Matt Roper
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.h| 1 +
drivers/gpu/drm/i915/i915_params.c | 8 +++-
drivers/
On Tue, 2015-03-03 at 15:31 +0200, Ville Syrjälä wrote:
>
> I suppose any increase is good. But personally I just couldn't stand
> anything below 75Hz when I was still using a CRT.
Yeah. 75Hz is what I was using with the nVidia card I replaced with
this new motherboard and Celeron G1840.
Slight
On Mon, Mar 02, 2015 at 04:35:20PM +0100, Daniel Vetter wrote:
> This reverts commit 3f678c96abb43a977d2ea41aefccdc49e8a3e896.
>
> We've been a bit too optimistic with this one here :(
>
> The trouble is that internally we're still using these plane
> update/disable hooks. Which was totally ok pr
On Fri, Feb 20, 2015 at 11:16 PM, Michel Thierry
wrote:
> From: Ben Widawsky
>
> v2: 0 pad the new 8B fields or else intel_error_decode has a hard time.
> Note, regardless we need an igt update.
>
> v3: Make reloc_offset 64b also.
>
> Signed-off-by: Ben Widawsky
> Signed-off-by: Michel Thierry
On Fri, Feb 20, 2015 at 11:16 PM, Michel Thierry
wrote:
> When 48b is enabled, gen8_ppgtt_insert_entries needs to read the Page Map
> Level 4 (PML4), before it selects which Page Directory Pointer (PDP)
> it will write to.
>
> Similarly, gen8_ppgtt_clear_range needs to get the correct PDP/PD range
This is a tricky story of the new atomic state handling and the legacy
code fighting over each another. The bug at hand is an underrun of the
framebuffer reference with subsequent hilarity caused by the load
detect code. Which is peculiar since the the exact same code works
fine as the implementati
On Tue, Mar 03, 2015 at 05:03:29PM +0200, Mika Kuoppala wrote:
> If the mappable size is less than what the full range
> of pdps can address, we end up setting pdps for only the
> mappable area.
mappable is not a factor here. The global gtt is 2GiB and we just used
the same size for the ppgtt, whi
> -Original Message-
> From: Tvrtko Ursulin [mailto:tvrtko.ursu...@linux.intel.com]
> Sent: Tuesday, March 03, 2015 4:04 PM
> To: Intel-gfx@lists.freedesktop.org; Lespiau, Damien
> Cc: Ceraolo Spurio, Daniele; Gore, Tim
> Subject: Re: [Intel-gfx] [PATCH i-g-t 02/13] lib: Extract
> igt_buf
On 03/03/2015 02:10 PM, Tvrtko Ursulin wrote:
From: Damien Lespiau
Now that the Android build has cairo, we can put cairo-dependant code
back into lib/
Looks like we'll have to drop this one - Cairo is not available in
Android after all.
I looked at the following patches and couldn't see
On Tue, Mar 03, 2015 at 08:44:04PM +0530, Vijay Purushothaman wrote:
> This patch implements latest PHY changes in Gain, prop and int co-efficients
> based on the vco freq.
>
> v2: Split the original changes into multiple smaller patches based on
> review by Ville
>
> v3: Addressed Ville's review
On Tue, Mar 03, 2015 at 08:43:12PM +0530, Vijay Purushothaman wrote:
> Initialize lock detect threshold and select coarse threshold for the
> case where M2 fraction division is disabled.
>
> v2: Split the changes into multiple smaller patches based on review by
> Ville
>
> v3: Addressed rest of t
On Tue, Mar 03, 2015 at 08:21:44AM -0300, Paulo Zanoni wrote:
> Hi
>
> 2015-02-27 15:12 GMT-03:00 Matt Roper :
> > plane->fb is a legacy pointer that not always be up-to-date (or updated
> > early enough). Make sure the watermark code uses plane->state->fb so
> > that we're always doing our calcu
On Tue, Mar 03, 2015 at 08:41:54PM +0530, Vijay Purushothaman wrote:
> v2 : Handle M2 frac division for both M2 frac and int cases
>
> v3 : Addressed Ville's review comments. Cleared the old bits for RMW
>
> Signed-off-by: Vijay Purushothaman
> ---
> drivers/gpu/drm/i915/i915_reg.h |1
From: Vandana Kannan
Adding a debugfs entry to determine if DRRS is supported or not
V2: [By Ram]: Following details about the active crtc will be filled
in seq-file of the debugfs
1. Encoder output type
2. DRRS Support on this CRTC
3. DRRS current state
4
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5868
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV -5 278/278
If the mappable size is less than what the full range
of pdps can address, we end up setting pdps for only the
mappable area.
The logical context however needs valid pdp entries.
Prior to commit 06fda602dbca ("drm/i915: Create page table allocators")
we just have been writing pdp entries with dma
Initialize lock detect threshold and select coarse threshold for the
case where M2 fraction division is disabled.
v2: Split the changes into multiple smaller patches based on review by
Ville
v3: Addressed rest of the review comments. Clear out the old bits before
we modify those bits as part of R
This patch implements latest PHY changes in Gain, prop and int co-efficients
based on the vco freq.
v2: Split the original changes into multiple smaller patches based on
review by Ville
v3: Addressed Ville's review comments. Fixed the error introduced in v2.
Clear the old bits before we modify th
v2 : Handle M2 frac division for both M2 frac and int cases
v3 : Addressed Ville's review comments. Cleared the old bits for RMW
Signed-off-by: Vijay Purushothaman
---
drivers/gpu/drm/i915/i915_reg.h |1 +
drivers/gpu/drm/i915/intel_display.c | 24 ++--
2 files ch
On 2/23/2015 9:43 PM, Daniel Vetter wrote:
On Mon, Feb 16, 2015 at 01:21:34PM +0200, Ville Syrjälä wrote:
On Mon, Feb 16, 2015 at 03:07:59PM +0530, Vijay Purushothaman wrote:
As per the recommendation from PHY team, limit the max vco supported in CHV to
6.48 GHz
Signed-off-by: Vijay Purushoth
On 2/16/2015 5:02 PM, Ville Syrjälä wrote:
On Mon, Feb 16, 2015 at 03:08:02PM +0530, Vijay Purushothaman wrote:
This patch implements latest PHY changes in Gain, prop and int co-efficients
based on the vco freq.
Signed-off-by: Vijay Purushothaman
---
drivers/gpu/drm/i915/i915_reg.h |
From: Tvrtko Ursulin
To support frame buffer rotation we need to be able to pass on the information
on what kind of GGTT view is required for display.
This patch just adds the parameter and makes all the callers default to the
normal view.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i91
From: Tvrtko Ursulin
For now only default implementation defaulting to normal view.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_display.c | 26 +++---
1 file changed, 23 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/dri
From: Tvrtko Ursulin
Display engine on Skylake can scan out specially prepared frame buffers
rotated by 90 or 270 degrees.
This adds partial support for that - display programming patches are missing
from this initial posting because for now the only purpose is to see if people
now like the appr
From: Tvrtko Ursulin
It will be used in a later patch.
v2: Rebased for fb modifiers.
v3: Fixed v2 rebase.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Michel Thierry (v1)
---
drivers/gpu/drm/i915/intel_display.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff
From: Tvrtko Ursulin
v2: Pass in rotation info to sprite plane updates as well.
v3: Use helper to determine 90/270 rotation. (Michel Thierry)
v4: Rebased for fb modifiers and atomic changes.
For: VIZ-4546
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Michel Thierry (v3)
---
drivers/gpu/drm/i91
From: Tvrtko Ursulin
Plane state carries the rotation information which is needed for determining
the appropriate GGTT view type.
This just adds the parameter with the actual usage coming in future patches.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_display.c | 18 ++
From: Tvrtko Ursulin
Use cases like rotation require these hooks to have some context so they
know how to prepare and cleanup the frame buffer correctly.
For i915 specifically, object backing pages need to be mapped differently
for different rotation modes and the driver needs to know which mapp
From: Tvrtko Ursulin
Need to do this in order to support 90/270 rotated display.
v2: Pass in drm_plane instead of plane index to intel_obj_display_address.
v3:
* Renamed intel_obj_display_address to intel_plane_obj_offset.
(Chris Wilson)
* Simplified rotation check to bitwise AND.
From: Tvrtko Ursulin
90/270 rotated scanout needs a rotated GTT view of the framebuffer.
This is put in a separate VMA with a dedicated ggtt view and wired such that
it is created when a framebuffer is pinned to a 90/270 rotated plane.
Rotation is only possible with Yb/Yf buffers and error is p
On Tue, Dec 09, 2014 at 04:53:01PM +, Damien Lespiau wrote:
> Right that leaves the last point in my answer to v3. With that addressed
> this is:
>
> Reviewed-by: Damien Lespiau
Hum it seems that we've upstreamed the kernel part without the libdrm
API. Is it time to fix this? Akash, Chris, a
From: Damien Lespiau
v2: Adjust for BB handling changes. (Tvrtko Ursulin)
Correct XY_FAST_COPY_DST_TILING_Yf. (Tvrtko Ursulin)
v3: New tiling modes are not defined in the kernel any more. (Tvrtko Ursulin)
Signed-off-by: Damien Lespiau
Signed-off-by: Tvrtko Ursulin
---
lib/intel_batchbuff
From: Tvrtko Ursulin
v2: Moved all init into fixtures.
Signed-off-by: Tvrtko Ursulin
---
lib/ioctl_wrappers.h | 2 ++
tests/kms_addfb.c| 70 +++-
2 files changed, 71 insertions(+), 1 deletion(-)
diff --git a/lib/ioctl_wrappers.h b/lib/ioctl
From: Damien Lespiau
So we can use it with bare kernel types, without going through libdrm
bos.
v2: Don't forget the object handle. (Tvrtko)
Correct surface pitch calculation. (Tvrtko)
Signed-off-by: Damien Lespiau
Signed-off-by: Tvrtko Ursulin
---
lib/intel_batchbuffer.c | 134 +
From: Tvrtko Ursulin
This converts the IGT API only, underneath legacy set_tiling is still used.
v2: One got away in kms_flip.
Signed-off-by: Tvrtko Ursulin
---
lib/igt_fb.c| 20 ++--
lib/igt_fb.h| 10 +-
lib/igt_kms.h | 1
From: Damien Lespiau
There's no fencing for those tiling layouts, so we create a linear bo
for cairo to play with, and when cairo is finished with it, we do a fast
copy blit to the fb BO with its final tiling.
v2: Move to correct domain after CPU is done with the object (-EINVAL). (Tvrtko
Ursul
From: Tvrtko Ursulin
Signed-off-by: Tvrtko Ursulin
---
tests/kms_flip_tiling.c | 28 +---
1 file changed, 25 insertions(+), 3 deletions(-)
diff --git a/tests/kms_flip_tiling.c b/tests/kms_flip_tiling.c
index 9adf143..9ca12f7 100644
--- a/tests/kms_flip_tiling.c
+++ b/te
From: Tvrtko Ursulin
New functionality accessesed via the __kms_addfb wrapper.
Signed-off-by: Tvrtko Ursulin
---
lib/ioctl_wrappers.c | 26 ++
lib/ioctl_wrappers.h | 9 +
2 files changed, 35 insertions(+)
diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.
From: Damien Lespiau
Signed-off-by: Damien Lespiau
---
tests/testdisplay.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/tests/testdisplay.c b/tests/testdisplay.c
index 64ce4d7..dab9e12 100644
--- a/tests/testdisplay.c
+++ b/tests/testdisplay.c
@@ -51,6 +
From: Damien Lespiau
So we can use this function in a "raw" (ie without igt_buf) version.
Signed-off-by: Damien Lespiau
---
lib/intel_batchbuffer.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/lib/intel_batchbuffer.c b/lib/intel_batchbuffer.c
index 9b8ae0d..
From: Tvrtko Ursulin
Signed-off-by: Tvrtko Ursulin
---
lib/igt_fb.c | 36 +++-
1 file changed, 23 insertions(+), 13 deletions(-)
diff --git a/lib/igt_fb.c b/lib/igt_fb.c
index 853b2f9..c54907e 100644
--- a/lib/igt_fb.c
+++ b/lib/igt_fb.c
@@ -404,16 +404,10 @@ ig
From: Damien Lespiau
Again, these helpers will be useful for a raw version of the gen9 fast
copy.
Signed-off-by: Damien Lespiau
---
lib/intel_batchbuffer.c | 96 +
1 file changed, 57 insertions(+), 39 deletions(-)
diff --git a/lib/intel_batchbuf
From: Tvrtko Ursulin
Just a few basic tests to make sure fb modifiers can be used and
behave sanely when mixed with the old set_tiling API.
v2:
* Review feedback from Daniel Vetter:
1. Move cap detection into the subtest so skipping works.
2. Added some gtkdoc comments.
3. T
From: Damien Lespiau
Now that the Android build has cairo, we can put cairo-dependant code
back into lib/
v2: Document image format. (Daniel Vetter)
Signed-off-by: Damien Lespiau
---
lib/intel_batchbuffer.c | 26 ++
lib/intel_batchbuffer.h | 2 ++
tests/gem_render_cop
From: Tvrtko Ursulin
Starting with Skylake the display engine can scan out Y tiled objects. (Both
legacy Y tiled, and the new Yf format.)
This series takes the original work by Damien Lespiau and converts it to use the
new frame buffer modifiers instead of object set/get tiling. Some patches nee
On Fri, Feb 20, 2015 at 05:45:54PM +, Michel Thierry wrote:
> These patches rely on "PPGTT dynamic page allocations", currently under
> review,
> to provide GEN8 dynamic page table support with 64b addresses. As the review
> progresses, these patches may be combined.
>
> In order expand the G
On Tue, Mar 03, 2015 at 08:23:04AM -0500, Brian J. Murrell wrote:
> On Mon, 2015-03-02 at 14:27 +, Chris Wilson wrote:
> >
> > Mixing ZaphodHeads and DRI,
>
> Oh wait! You said "mixing" not "missing". But yeah, I'm an old-timer
> trying to maintain his 20+ year old preference for truly sep
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5867
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV -4 278/278
On Sat, 28 Feb 2015, Michael Leuchtenburg wrote:
> No changes, even while the brightness is in the process of changing. Is it
> possible there's some other bit used on this hardware? The Broadwell chips
> are pretty new. I haven't had a chance to look for specs yet.
The DPCD info is specific to y
On Tue, Mar 03, 2015 at 08:16:56AM -0500, Brian J. Murrell wrote:
> On Tue, 2015-03-03 at 15:03 +0200, Ville Syrjälä wrote:
> >
> > Oh that's an a CRT monitor you have there. Been a while since I've
> > come across one of those :)
>
> Heh. Yeah. I have been in the market to replace it but no go
Move towards atomic by using the legacy modeset's drm_atomic_state
instead.
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/intel_dp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index
Follow up patches will convert some functions called from there to use
the atomic state, instead of directly accessing the new or current
config. This patch just changes the parameters, but shouldn't have any
functional changes.
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i91
Pass a crtc_state to it and find whether the pipe has an encoder of a
given type by looking at the drm_atomic_state the crtc_state points to.
Note that is possible to reach i9xx_get_refclk() without a proper atomic
state, since in the function vlv_force_pll_on() a minimally initialized
crtc_state
The function intel_dp_set_drrs_state() would decide which pipe to
downclock based on the staged config for the given connector. However,
the result of that function is immediate, and it uses input values from
crtc->config, so it should be looking at the current crtc instead.
Signed-off-by: Ander C
On Mon, 2015-03-02 at 14:27 +, Chris Wilson wrote:
>
> Mixing ZaphodHeads and DRI,
Oh wait! You said "mixing" not "missing". But yeah, I'm an old-timer
trying to maintain his 20+ year old preference for truly separate
screens -- like from way back when even Xinerama didn't even exist. :-)
Some of the crtc_compute_clock() still depended on encoder->new_crtc
since they didn't use intel_pipe_will_have_type() and used an open
coded version of that function instead. This patch replaces those with
the appropriate code that checks the atomic state intead.
Signed-off-by: Ander Conselvan de
Instead of using connector->new_encoder, get the same information from
the pipe_config, thus making the function ready for the atomic
conversion.
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/intel_ddi.c | 24 +++-
1 file changed, 15 insertions(+), 9 de
Move towards atomic by using the legacy modeset's drm_atomic_state
instead.
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/intel_hdmi.c | 21 -
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gp
Move towards atomic by using the legacy modeset's drm_atomic_state
instead.
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/intel_dp_mst.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
b/drivers/gp
So that we can add connector states to the drm_atomic_state used in the
legacy modeset.
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/intel_crt.c| 1 +
drivers/gpu/drm/i915/intel_dp.c | 1 +
drivers/gpu/drm/i915/intel_dp_mst.c | 1 +
drivers/gpu/drm/i915/intel_dsi.
With this in place, we can start converting pieces of the modeset code
to look at the connector atomic state instead of the staged config.
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/intel_display.c | 23 ---
1 file changed, 20 insertions(+), 3 deleti
Create an atomic state and initialize it for the load detect pipe
modesets, so it doesn't break once the rest of the mode set code starts
using atomic states instead of the staged config.
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/intel_crt.c | 2 +-
drivers/gpu/dr
In the set config modeset path, the atomic state is updated when
changing the staged config in intel_modeset_stage_output_config(). The
load detect code also causes a modeset, but it changes the staged config
before calling intel_set_mode(). A follow up patch will change that
function to also updat
The pattern of getting the crtc state with drm_atomic_get_crtc_state()
and then converting it to intel_crtc_state will repeat quite often in
the following patches, so add a helper function to save some typing.
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/intel_drv.h | 10
In the path were there is no state to duplicate, the allocated crtc
state wouldn't have the crtc backpointer initialized.
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/intel_atomic.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/g
This patch series starts to remove dependencies from the modeset code to
enable the transition to atomic. That is achieved by using an atomic
state struct for the legacy modeset, and changing related functiond to
depend on it.
I wasn't able to test all of the changes, so I'm very interested on
PRT
This function is called indirectly by intel_crtc_compute_config(),
which needs to be converted to work only with an atomic state.
---
I'm not sure what are the implications of ignoring intel_crtc->active in
pipe_has_enabled_pch(). If we allow a config because the third pipe is
enabled but not act
Move towards atomic by using the legacy modeset's drm_atomic_state
instead.
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/intel_lvds.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/gpu/drm/i915/intel_lvds.c
Move towards atomic by using the legacy modeset's drm_atomic_state
instead.
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/intel_display.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/dr
For the atomic conversion, the mode set paths need to be changed to rely
on an atomic state instead of using the staged config. By using an
atomic state for the legacy code, we will be able to convert the code
base in small chunks.
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/
1 - 100 of 130 matches
Mail list logo
