Op 11-06-15 om 03:35 schreef Matt Roper:
> On Thu, Jun 04, 2015 at 02:47:44PM +0200, Maarten Lankhorst wrote:
>> By passing crtc_state to the check_plane functions a lot of duplicated
>> code can be removed. And now that the transitional helpers are gone the
>> crtc_state can be reliably obtained.
Op 11-06-15 om 03:37 schreef Matt Roper:
> On Thu, Jun 04, 2015 at 02:47:48PM +0200, Maarten Lankhorst wrote:
>> Read out the initial state, and add a quirk to force disable all plane
>> that were initially active. Use this to disable planes during modeset
>> too.
>>
>> Signed-off-by: Maarten Lankh
Op 11-06-15 om 03:36 schreef Matt Roper:
> On Thu, Jun 04, 2015 at 02:47:46PM +0200, Maarten Lankhorst wrote:
>> This is probably intended to be be done during vblank evasion.
>>
>> Signed-off-by: Maarten Lankhorst
>> ---
>> drivers/gpu/drm/i915/intel_atomic.c | 3 ---
>> drivers/gpu/drm/i915/in
Op 11-06-15 om 03:35 schreef Matt Roper:
> On Thu, Jun 04, 2015 at 02:47:42PM +0200, Maarten Lankhorst wrote:
>> This makes it easier to verify that no changes are done when
>> calling this from crtc instead.
>>
>> Changes since v1:
>> - Make intel_wm_need_update static and always check it.
>>
>>
From: dhanyapr
Signed-off-by: dhanyapr
---
tests/Makefile.sources | 1 +
tests/kms_color.c | 508 +
2 files changed, 509 insertions(+)
create mode 100644 tests/kms_color.c
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index
On Thu, Jun 04, 2015 at 02:47:48PM +0200, Maarten Lankhorst wrote:
> Read out the initial state, and add a quirk to force disable all plane
> that were initially active. Use this to disable planes during modeset
> too.
>
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/intel_atomi
On Thu, Jun 04, 2015 at 02:47:46PM +0200, Maarten Lankhorst wrote:
> This is probably intended to be be done during vblank evasion.
>
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/intel_atomic.c | 3 ---
> drivers/gpu/drm/i915/intel_display.c | 8
> drivers/gpu/drm/i9
On Thu, Jun 04, 2015 at 02:47:44PM +0200, Maarten Lankhorst wrote:
> By passing crtc_state to the check_plane functions a lot of duplicated
> code can be removed. And now that the transitional helpers are gone the
> crtc_state can be reliably obtained.
>
> Signed-off-by: Maarten Lankhorst
> ---
>
On Thu, Jun 04, 2015 at 02:47:41PM +0200, Maarten Lankhorst wrote:
> It's easier to read separate functions for crtc and plane scaler state.
>
> Changes since v1:
> - Update documentation.
>
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/intel_display.c | 200
> ++
On Thu, Jun 04, 2015 at 02:47:42PM +0200, Maarten Lankhorst wrote:
> This makes it easier to verify that no changes are done when
> calling this from crtc instead.
>
> Changes since v1:
> - Make intel_wm_need_update static and always check it.
>
> Signed-off-by: Maarten Lankhorst
Do we even ne
On Wed, Jun 10, 2015 at 02:45:24PM +0200, Patrik Jakobsson wrote:
> On Wed, Jun 10, 2015 at 01:35:35AM +0300, Dmitry V. Levin wrote:
> > On Tue, Jun 09, 2015 at 01:26:43PM +0200, Patrik Jakobsson wrote:
[...]
> > > +static int i915_setparam(struct tcb *tcp, const unsigned int code, long
> > > arg)
On Wed, Jun 10, 2015 at 01:52:33PM +0200, Patrik Jakobsson wrote:
> On Wed, Jun 10, 2015 at 01:14:20AM +0300, Dmitry V. Levin wrote:
> > On Tue, Jun 09, 2015 at 01:26:42PM +0200, Patrik Jakobsson wrote:
[...]
> > > +#define DRM_MAX_NAME_LEN 128
> > > +
> > > +inline int drm_is_priv(const unsigned i
Delete the duplicate #defines introduced by:
commit 6b457d31ea0465fcadcf6d5044f5f71398954727
Author: A.Sunil Kamath
Date: Thu Apr 16 14:22:09 2015 +0530
drm/i915/skl: Implement enable/disable for Display C5 state.
Signed-off-by: Chandra Konduru
---
dr
The registers and process differ from other platforms.
Signed-off-by: Bob Paauwe
---
drivers/gpu/drm/i915/intel_display.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index c38c297..4
> > +
> > + dev_priv->rps.efficient_freq *=
> > + (IS_SKYLAKE(dev) ? GEN9_FREQ_SCALER : 1);
This line seems awkward. I suppose a good compiler could
optimize out the multiply by one.
I would prefer something like:
if(IS_SKYLAKE
On Wed, Jun 10, 2015 at 05:46:54PM +0100, Michel Thierry wrote:
> There are some allocations that must be only referenced by 32bit
> offsets. To limit the chances of having the first 4GB already full,
> objects not requiring this workaround use DRM_MM_SEARCH_BELOW/
> DRM_MM_CREATE_TOP flags
>
> Us
On Wed, Jun 10, 2015 at 05:46:53PM +0100, Michel Thierry wrote:
> GTT is only 32b and its max value is 4GB. In order to allow objects
> bigger than 4GB in 48b PPGTT, i915_gem_userptr_ioctl needs to check
> against max 48b range (1ULL << 48).
>
> Whenever possible, read the PPGTT's total instead of
Use 48b addresses if hw supports it and i915.enable_ppgtt=3.
Note, aliasing PPGTT remains 32b only.
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 2 +-
drivers/gpu/drm/i915/i915_params.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gp
Similar to PDs, while setting up a page directory pointer, make all entries
of the pdp point to the scratch pdp before mapping (and make all its entries
point to the scratch page); this is to be safe in case of out of bound
access or proactive prefetch.
Although the ggtt is always 32-bit, the scr
There are some allocations that must be only referenced by 32bit
offsets. To limit the chances of having the first 4GB already full,
objects not requiring this workaround use DRM_MM_SEARCH_BELOW/
DRM_MM_CREATE_TOP flags
User must pass I915_EXEC_SUPPORTS_48BADDRESS flag to indicate it can
be alloca
v2: Clean up patch after rebases.
v3: gen8_dump_ppgtt for 32b and 48b PPGTT.
v4: Use used_pml4es/pdpes (Akash).
v5: Rebase after Mika's ppgtt cleanup / scratch merge patch series.
Signed-off-by: Ben Widawsky
Signed-off-by: Michel Thierry (v2+)
---
drivers/gpu/drm/i915/i915_debugfs.c | 18 --
As a step towards implementing 4 levels, while not discarding the
existing pte insert functions, we need to pass the sg_iter through.
The current function understands to the page directory granularity.
An object's pages may span the page directory, and so using the iter
directly as we write the PTE
GTT is only 32b and its max value is 4GB. In order to allow objects
bigger than 4GB in 48b PPGTT, i915_gem_userptr_ioctl needs to check
against max 48b range (1ULL << 48).
Whenever possible, read the PPGTT's total instead of the GTT one, this
will be accurate in 32 and 48 bit modes.
v2: Use the d
Test I915_EXEC_SUPPORTS_48BADDRESS flag to use 32b+ segment.
Driver will try to use lower PDPs of each PPGTT for the objects
requiring Wa32bitGeneralStateOffset or Wa32bitInstructionBaseOffset.
v2: Add flink cases, (suggested by Daniel Vetter).
Signed-off-by: Michel Thierry
---
tests/gem_ppgtt.
In a 48b world, users can try to allocate buffers bigger than 4GB; in
these cases it is important that size is a 64b variable.
Also added a warning for illegal bind with size = 0.
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_gem.c | 5 +++--
drivers/gpu/drm/i915/i915_gem_gtt.
These are the rebased patches, after Mika's ppgtt clean-up series (and reusing
the macros added). New functions also follow these changes.
In order expand the GPU address space, a 4th level translation is added, the
Page Map Level 4 (PML4). This PML4 has 256 PML4 Entries (PML4E), PML4[0-255],
each
After Mika's ppgtt cleanup series, all the other free functions have
drm_device as the first parameter, except this one.
No functional changes.
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers
This transitional patch doesn't do much for the existing code. However,
it should make upcoming patches to use the full 48b address space a bit
easier. The patch also introduces the PML4, ie. the new top level structure
of the page tables.
v2: Renamed pdp_free to be similar to pd/pt (unmap_and_f
gen8_clamp_pd clamps to the next page directory boundary, but the macro
gen8_for_each_pde already has a check to stop at the page directory boundary.
Furthermore, i915_pte_count also restricts to the next page table
boundary.
v2: Rebase after Mika's ppgtt cleanup / scratch merge patch series.
Su
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 patch was inspired by Ben's "Depend exclusively on map and
The insert_entries function was the function used to write PTEs. For the
PPGTT it was "hardcoded" to only understand two level page tables, which
was the case for GEN7. We can reuse this for 4 level page tables, and
remove the concept of insert_entries, which was never viable past 2
level page tabl
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 unless we know it's what we want. The future structure will use
ppgtt->pml4 for the top l
The dynamic page allocation patch series added it for GEN6, this patch
adds them for GEN8.
v2: Consolidate pagetable/page_directory events
v3: Multiple rebases.
v4: Rebase after s/page_tables/page_table/.
v5: Rebase after Mika's ppgtt cleanup / scratch merge patch series.
Signed-off-by: Ben Widaw
In 64b (48bit canonical) PPGTT addressing, the PDP0 register contains
the base address to PML4, while the other PDP registers are ignored.
In LRC, the addressing mode must be specified in every context descriptor.
v2: PML4 update in legacy context switch is left for historic reasons,
the preferre
Signed-off-by: Ben Widawsky
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_drv.h | 4 ++--
drivers/gpu/drm/i915/i915_gpu_error.c | 17 +
2 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i91
PML4 has no special attributes, and there will always be a PML4.
So simply initialize it at creation, and destroy it at the end.
The code for 4lvl is able to call into the existing 3lvl page table code
to handle all of the lower levels.
v2: Return something at the end of gen8_alloc_va_range_4lvl
A safer way to update the PDPx registers is sending lri commands, added
in the ring before the batchbuffer start. Otherwise, the ctx must be idle
before trying to change anything (but the ring-tail) in the ctx image. An
example where the ctx won't be idle is lite-restore.
This patch depends on [1]
On Thu, Jun 04, 2015 at 06:01:35PM +0300, Imre Deak wrote:
> According to bspec the DDI PHY vswing scale value is "don't care" in
> case the scale enable bit [27] is clear. But this doesn't seem to be
> correct. The scale value seems to also matter if the scale mode bit
> [26] is set. So both bit 2
On ke, 2015-06-10 at 08:33 -0700, Jesse Barnes wrote:
> On 06/10/2015 08:26 AM, Imre Deak wrote:
> > On ke, 2015-06-10 at 08:10 -0700, Jesse Barnes wrote:
> >> On 06/10/2015 03:59 AM, Imre Deak wrote:
> >>> I think the discussion here is about two separate things:
> >>> 1. Possible ordering issue b
On Wed, Jun 10, 2015 at 06:26:58PM +0300, Imre Deak wrote:
> On ke, 2015-06-10 at 08:10 -0700, Jesse Barnes wrote:
> > On 06/10/2015 03:59 AM, Imre Deak wrote:
> > > I think the discussion here is about two separate things:
> > > 1. Possible ordering issue between the seqno store and the completion
On Wed, Jun 10, 2015 at 06:16:20PM +0300, Imre Deak wrote:
> On ke, 2015-06-10 at 18:00 +0300, Ville Syrjälä wrote:
> > On Wed, Jun 10, 2015 at 05:55:24PM +0300, Imre Deak wrote:
> > > On ke, 2015-06-10 at 15:21 +0100, Chris Wilson wrote:
> > > > On Wed, Jun 10, 2015 at 05:07:46PM +0300, Imre Deak
On 06/10/2015 08:26 AM, Imre Deak wrote:
> On ke, 2015-06-10 at 08:10 -0700, Jesse Barnes wrote:
>> On 06/10/2015 03:59 AM, Imre Deak wrote:
>>> I think the discussion here is about two separate things:
>>> 1. Possible ordering issue between the seqno store and the completion
>>> interrupt
>>> 2. C
On ke, 2015-06-10 at 08:10 -0700, Jesse Barnes wrote:
> On 06/10/2015 03:59 AM, Imre Deak wrote:
> > I think the discussion here is about two separate things:
> > 1. Possible ordering issue between the seqno store and the completion
> > interrupt
> > 2. Coherency issue that leaves the CPU with a st
On ke, 2015-06-10 at 18:00 +0300, Ville Syrjälä wrote:
> On Wed, Jun 10, 2015 at 05:55:24PM +0300, Imre Deak wrote:
> > On ke, 2015-06-10 at 15:21 +0100, Chris Wilson wrote:
> > > On Wed, Jun 10, 2015 at 05:07:46PM +0300, Imre Deak wrote:
> > > > On ti, 2015-06-09 at 11:21 +0300, Jani Nikula wrote:
On 06/10/2015 03:59 AM, Imre Deak wrote:
> I think the discussion here is about two separate things:
> 1. Possible ordering issue between the seqno store and the completion
> interrupt
> 2. Coherency issue that leaves the CPU with a stale view of the seqno
> indefinitely, which this patch works aro
On Wed, Jun 10, 2015 at 05:55:24PM +0300, Imre Deak wrote:
> On ke, 2015-06-10 at 15:21 +0100, Chris Wilson wrote:
> > On Wed, Jun 10, 2015 at 05:07:46PM +0300, Imre Deak wrote:
> > > On ti, 2015-06-09 at 11:21 +0300, Jani Nikula wrote:
> > > > On Mon, 08 Jun 2015, Imre Deak wrote:
> > > > > By ru
As the clflush operates on cache lines, and we can flush any byte
address, in order to flush all bytes given in the range we issue an
extra clflush on the last byte to ensure the last cacheline is flushed.
We can can the iteration to be over the actual cache lines to avoid this
double clflush on th
On ke, 2015-06-10 at 15:21 +0100, Chris Wilson wrote:
> On Wed, Jun 10, 2015 at 05:07:46PM +0300, Imre Deak wrote:
> > On ti, 2015-06-09 at 11:21 +0300, Jani Nikula wrote:
> > > On Mon, 08 Jun 2015, Imre Deak wrote:
> > > > By running igt/store_dword_loop_render on BXT we can hit a coherency
> > >
On Wed, Jun 10, 2015 at 01:46:53AM +0300, Dmitry V. Levin wrote:
> On Tue, Jun 09, 2015 at 01:26:44PM +0200, Patrik Jakobsson wrote:
> [...]
> > +static int drm_version(struct tcb *tcp, const unsigned int code, long arg)
> > +{
> > + struct drm_version ver;
> > + char *name, *date, *desc;
> > +
On Wed, Jun 10, 2015 at 05:07:46PM +0300, Imre Deak wrote:
> On ti, 2015-06-09 at 11:21 +0300, Jani Nikula wrote:
> > On Mon, 08 Jun 2015, Imre Deak wrote:
> > > By running igt/store_dword_loop_render on BXT we can hit a coherency
> > > problem where the seqno written at GPU command completion tim
On ti, 2015-06-09 at 11:21 +0300, Jani Nikula wrote:
> On Mon, 08 Jun 2015, Imre Deak wrote:
> > By running igt/store_dword_loop_render on BXT we can hit a coherency
> > problem where the seqno written at GPU command completion time is not
> > seen by the CPU. This results in __i915_wait_request s
On Fri, 05 Jun 2015, Paulo Zanoni wrote:
> 2015-06-04 14:23 GMT-03:00 Damien Lespiau :
>> Signed-off-by: Damien Lespiau
>
> For both patches: Reviewed-by: Paulo Zanoni
Pushed to drm-intel-next-queued, thanks for the patches and review.
BR,
Jani.
>
>> ---
>> drivers/gpu/drm/i915/i915_debugfs.
On Wed, 10 Jun 2015, Dave Gordon wrote:
> But since INTEL_INFO() can take 'dev_priv' as a parameter (as an
> alternative to 'dev'), all the uses of 'dev' here could be replaced by
> 'dev_priv' and then the parameter changed to pass that directly, thus
> potentially eliminating quite a few extra me
On Wed, Jun 10, 2015 at 01:35:35AM +0300, Dmitry V. Levin wrote:
> On Tue, Jun 09, 2015 at 01:26:43PM +0200, Patrik Jakobsson wrote:
> [...]
> > +static int i915_getparam(struct tcb *tcp, const unsigned int code, long
> > arg)
> > +{
> > + struct drm_i915_getparam param;
> > + int value;
> > +
On 10/06/15 09:09, Jani Nikula wrote:
> On Tue, 09 Jun 2015, Dave Gordon wrote:
>> Regardless of whether it's used, we have an inconsistency between the
>> definitions of PORT_DFT_I9XX and PORT_DFT2_G4X -- one includes the
>> mmio_offset and the other doesn't.
>
> It's not inconsistent, it's cons
On Thu, 04 Jun 2015, Damien Lespiau wrote:
> Signed-off-by: Damien Lespiau
> ---
> drivers/gpu/drm/i915/i915_reg.h | 7 +++
> drivers/gpu/drm/i915/intel_display.c | 13 -
> 2 files changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/d
On Fri, 05 Jun 2015, Ville Syrjälä wrote:
> On Thu, Jun 04, 2015 at 06:21:29PM +0100, Damien Lespiau wrote:
>> Signed-off-by: Damien Lespiau
>
> For patches 1-6
> Reviewed-by: Ville Syrjälä
Said patches pushed to drm-intel-next-queued, thanks for the patches and
review.
BR,
Jani.
>
>> ---
>
On Wed, 10 Jun 2015, Dhanya Pillai wrote:
> From: root
Try 'git commit --amend --reset-author' on that commit.
BR,
Jani.
>
> Signed-off-by: dhanyapr
> ---
> tests/Makefile.sources | 1 +
> tests/kms_color.c | 508
> +
> 2 files changed,
On Wed, 10 Jun 2015, Ander Conselvan De Oliveira wrote:
> For both patches,
>
> Acked-by: Ander Conselvan de Oliveira
And both pushed to drm-intel-next-queued, thanks for the patches and
ack.
BR,
Jani.
>
> On Wed, 2015-06-10 at 10:24 +0200, Maarten Lankhorst wrote:
>> Seems this is causing to
From: root
Signed-off-by: dhanyapr
---
tests/Makefile.sources | 1 +
tests/kms_color.c | 508 +
2 files changed, 509 insertions(+)
create mode 100644 tests/kms_color.c
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 994
On Wed, Jun 10, 2015 at 01:14:20AM +0300, Dmitry V. Levin wrote:
> On Tue, Jun 09, 2015 at 01:26:42PM +0200, Patrik Jakobsson wrote:
> [...]
> > --- a/Makefile.am
> > +++ b/Makefile.am
> > @@ -121,6 +121,7 @@ strace_SOURCES =\
> > utime.c \
> > utimes.c\
> > v4l2
For both patches,
Acked-by: Ander Conselvan de Oliveira
On Wed, 2015-06-10 at 10:24 +0200, Maarten Lankhorst wrote:
> Seems this is causing too many issues, revert temporarily until the issues
> are fixed.
>
> This might break some of the changes I made using atomic state:
> Can someone test
On 5/29/2015 1:53 PM, Michel Thierry wrote:
On 5/29/2015 12:05 PM, Michel Thierry wrote:
On 5/22/2015 6:04 PM, Mika Kuoppala wrote:
With BDW/SKL and 32bit addressing mode only, the hardware preloads
pdps. However the TLB invalidation only has effect on levels below
the pdps. This means that if
On Wed, Jun 10, 2015 at 06:33:49AM -0400, Brian J. Murrell wrote:
> On Sun, 2015-06-07 at 13:11 -0400, Brian J. Murrell wrote:
> > I have an:
> >
> > 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th
> > Gen Core Processor Integrated Graphics Controller (rev 06)
> >
> > in
On ma, 2015-06-08 at 20:33 +0100, Dave Gordon wrote:
> On 08/06/15 19:40, Ville Syrjälä wrote:
> > On Mon, Jun 08, 2015 at 07:00:49PM +0100, Chris Wilson wrote:
> >> On Mon, Jun 08, 2015 at 08:34:51PM +0300, Ville Syrjälä wrote:
> >>> On Mon, Jun 08, 2015 at 06:12:47PM +0100, Chris Wilson wrote:
>
On Wed, Jun 10, 2015 at 01:38:55PM +0300, Joonas Lahtinen wrote:
> Hi,
>
> As discussed in IRC, this patch is not relevant. The interface is bit
> misbehaving. CC'd Imre who agreed to go and change the interface to more
> intuitive one.
partial.offset + partial.size is never checked for correctne
Cc: Jani Nikula
Signed-off-by: Thomas Wood
---
tools/intel_iosf_sb_read.c | 3 +++
tools/intel_iosf_sb_write.c | 3 +++
tools/intel_reg_dumper.c| 3 +++
tools/intel_reg_read.c | 3 +++
tools/intel_reg_snapshot.c | 4
tools/intel_reg_write.c | 3 +++
tools/intel_vga_read.c
Hi,
As discussed in IRC, this patch is not relevant. The interface is bit
misbehaving. CC'd Imre who agreed to go and change the interface to more
intuitive one.
Regards, Joonas
On ti, 2015-06-09 at 09:56 +0100, Chris Wilson wrote:
> On Wed, May 06, 2015 at 02:35:38PM +0300, Joonas Lahtinen wrot
On Wed, Jun 10, 2015 at 09:12:16AM +0100, Peter Antoine wrote:
> This change adds the programming of the MOCS registers to the gen 9+
> platforms. This change set programs the MOCS register values to a set
> of values that are defined to be optimal.
>
> It creates a fixed register set that is prog
On Sun, 2015-06-07 at 13:11 -0400, Brian J. Murrell wrote:
> I have an:
>
> 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th Gen
> Core Processor Integrated Graphics Controller (rev 06)
>
> in a Fedora 21 machine running Linux 4.0.4.
>
> While this is all generally worki
Cc: Jani Nikula
Signed-off-by: Thomas Wood
---
configure.ac | 5 +++--
tools/Makefile.am| 3 ++-
tools/intel_reg.c| 4 ++--
tools/quick_dump/Makefile.am | 13 -
4 files changed, 15 insertions(+), 10 deletions(-)
diff --git a/configure.ac b/
On Tue, Jun 09, 2015 at 02:59:33PM -0700, Anuj Phogat wrote:
> This patch is on the list for 8 weeks now. Please take a look so I can push
> it upstream.
Could I suggest you nominate a mesa team member working on SKL as well?
that would be the ideal match I believe.
--
Damien
___
Seems this is causing too many issues, revert temporarily until the issues are
fixed.
This might break some of the changes I made using atomic state:
Can someone test on haswell with multiple crtcs,
to see if the haswell plane workaround change still works?
"drm/i915: Calculate haswell plan
This reverts commit 490f400db5d886fc28566af69b02f6497f31be4b.
We're not ready yet to make it atomic, we calculate some state in
advance, but without atomic plane support atomic the hw readout will
fail.
It's required to revert this commit to revert the atomic hw
state readout patch.
Bugzilla: ht
This reverts commit 3bae26eb2991c00670df377cf6c3bc2b0577e82a.
Seems it introduces regressions for 3 different reasons, oh boy..
In bug #90868 as I can see the atomic state will be restored on
resume without the planes being set up properly. Because plane
setup here requires the atomic state, we'l
This change adds the programming of the MOCS registers to the gen 9+
platforms. This change set programs the MOCS register values to a set
of values that are defined to be optimal.
It creates a fixed register set that is programmed across the different
engines so that all engines have the same tab
On Tue, 09 Jun 2015, Dave Gordon wrote:
> Regardless of whether it's used, we have an inconsistency between the
> definitions of PORT_DFT_I9XX and PORT_DFT2_G4X -- one includes the
> mmio_offset and the other doesn't.
It's not inconsistent, it's consistent on another level:
We've settled on incl
The context functions are not used by the i915 driver and should not
be used by modeset drivers. These driver functions contain several bugs
and security holes. This change makes these functions optional can be
turned on by a setting, they are turned off by default for modeset
driver with the excep
On Tue, 09 Jun 2015, Maarten Lankhorst
wrote:
> Hey,
>
> Op 09-06-15 om 16:24 schreef Jani Nikula:
>> On Tue, 09 Jun 2015, Maarten Lankhorst
>> wrote:
>>> Hey,
>>>
>>> Op 09-06-15 om 13:48 schreef Tvrtko Ursulin:
On 06/01/2015 11:50 AM, Maarten Lankhorst wrote:
> From: Ander Conselvan
Op 10-06-15 om 03:58 schreef Matt Roper:
> On Thu, Jun 04, 2015 at 02:47:33PM +0200, Maarten Lankhorst wrote:
>> Instead of breaking all connections manually, kill them with
>> atomic modeset, if it happens. Now that the everything's atomic
>> some code becomes obsolete.
>>
>> Forcing a atomic mode
80 matches
Mail list logo
