On Thu, Jul 30, 2015 at 09:49:28AM +0300, Mika Kahola wrote:
> Store max dotclock into dev_priv structure so we are able
> to filter out the modes that are not supported by our
> platforms.
>
> Signed-off-by: Mika Kahola
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915
From: Kristian Høgsberg Kristensen
This does everything the aub dump functionality in libdrm does, but
without being part of libdrm. This moves the very developer oriented
functionality out of core libdrm and adds some flexibility in how we
activate it (we can specify filename, for example). Mo
This will cause drm_atomic_helper_page_flip and drm_mode_atomic_ioctl to
fail with -EINVAL if a event is requested on a inactive crtc.
Signed-off-by: Maarten Lankhorst
---
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index d719ce0b10a0..679577e8e02d 100644
--- a/driver
On Tuesday 28 July 2015 04:39 PM, Sunil Kamath wrote:
On Tuesday 28 July 2015 01:38 PM, Nagaraju, Vathsala wrote:
Signed-off-by: Vatsala Nagaraju
It's Vathsala Nagaraju
Commit message: Removed byte swapping for csr firmware.
Commit message does not convey as to why the change was made. "Th
On Wednesday 29 July 2015 04:40 PM, Sunil Kamath wrote:
On Tuesday 28 July 2015 04:53 PM, Sunil Kamath wrote:
On Sunday 26 July 2015 12:30 AM, Animesh Manna wrote:
As csr firmware is taking care of loading the firmware,
so no need for driver to load again.
Cc: Damien Lespiau
Cc: Imre Deak
Cc
On Sunday 26 July 2015 12:30 AM, Animesh Manna wrote:
While display engine entering into low power state no need to disable
cdclk pll as CSR firmware of dmc will take care. If pll is already
enabled firmware execution sequence will be blocked. This is one
of the criteria for dmc to work properly.
On Sun, Jun 28, 2015 at 09:19:26AM +0100, Chris Wilson wrote:
> The old style of memory interleaving swizzled upto the end of the
> first even bank of memory, and then used the remainder as unswizzled on
> the unpaired bank - i.e. swizzling is not constant for all memory. This
> causes problems whe
On Sunday 26 July 2015 12:30 AM, Animesh Manna wrote:
Mmio register access after dc6/dc5 entry is causing the
system hang, so enabling dc6 as the last call in suspend flow.
Cc: Damien Lespiau
Cc: Imre Deak
Cc: Sunil Kamath
Signed-off-by: Animesh Manna
Signed-off-by: Vathsala Nagaraju
Signed
Op 29-07-15 om 15:09 schreef Ander Conselvan De Oliveira:
> On Mon, 2015-07-27 at 14:35 +0200, Maarten Lankhorst wrote:
>> connectors_active will be removed, so just calculate this right here.
>>
>> Signed-off-by: Maarten Lankhorst
>> ---
>> drivers/gpu/drm/i915/intel_display.c | 17 +
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6887
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK -1
From: "Thulasimani,Sivakumar"
BPP bits defined in VBT should be used only on panels whose
edid version is 1.3 or older. EDID version 1.4 introduced offsets
where bpp is defined and hence should be preferred over any value
programmed in VBT.
Signed-off-by: Sivakumar Thulasimani
---
drivers/gpu/
From: "Thulasimani,Sivakumar"
CHV does not support intermediate link rates nor does it support
HBR2. This patch removes those entries and returns HBR as the max
link rate supported on CHV platform.
Signed-off-by: Sivakumar Thulasimani
---
drivers/gpu/drm/i915/intel_dp.c | 11 +++
1 f
On Thu, 2015-07-30 at 08:54 +0200, Maarten Lankhorst wrote:
> Op 29-07-15 om 15:26 schreef Ander Conselvan De Oliveira:
> > On Mon, 2015-07-27 at 14:35 +0200, Maarten Lankhorst wrote:
> > > Now that everything's atomic, checking encoder->base.crtc is enough.
> > Don't you need to check encoder->bas
On 7/30/2015 5:46 AM, Goel, Akash wrote:
On 7/29/2015 9:53 PM, Michel Thierry wrote:
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,
On 7/30/2015 5:01 AM, Goel, Akash wrote:
On 7/29/2015 9:53 PM, Michel Thierry wrote:
Introduces the Page Map Level 4 (PML4), ie. the new top level structure
of the page tables.
To facilitate testing, 48b mode will be available on Broadwell and
GEN9+, when i915.enable_ppgtt = 3.
v2: Remove unne
On 7/30/2015 5:14 AM, Goel, Akash wrote:
On 7/29/2015 9:53 PM, Michel Thierry wrote:
@@ -1512,12 +1522,15 @@ static int gen8_emit_bb_start(struct
drm_i915_gem_request *req,
* Ideally, we should set Force PD Restore in ctx descriptor,
* but we can't. Force Restore would be a second
On Thu, 30 Jul 2015, Sivakumar Thulasimani
wrote:
> From: "Thulasimani,Sivakumar"
>
> BPP bits defined in VBT should be used only on panels whose
> edid version is 1.3 or older. EDID version 1.4 introduced offsets
> where bpp is defined and hence should be preferred over any value
> programmed i
On Thu, 30 Jul 2015, Sivakumar Thulasimani
wrote:
> From: "Thulasimani,Sivakumar"
>
> CHV does not support intermediate link rates nor does it support
> HBR2. This patch removes those entries and returns HBR as the max
> link rate supported on CHV platform.
These are two separate changes, and s
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 using ppgtt->pdp
directly unless we know it's what we want. The future structure will use
ppgtt->pml4 for the top
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
Introduces the Page Map Level 4 (PML4), ie. the new top level structure
of the page tables.
To facilitate testing, 48b mode will be available on Broadwell and
GEN9+, when i915.enable_ppgtt = 3.
v2: Remove unnecessary CONFIG_X86_64 checks, ppgtt code is already
32/64-bit safe (Chris).
v3: Add goto
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
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, and the base address to PML4 is stored in the reg state.
v2: PML4 update in legacy
Use 48b addresses if hw supports it (i915.enable_ppgtt=3).
Note, aliasing PPGTT remains 32b only.
v2: s/full_64b/full_48b/. (Akash)
Cc: Akash Goel
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 9 -
drivers/gpu/drm/i915/i915_params.c | 2 +-
2 files changed,
On 7/30/2015 3:27 PM, Jani Nikula wrote:
On Thu, 30 Jul 2015, Sivakumar Thulasimani
wrote:
From: "Thulasimani,Sivakumar"
BPP bits defined in VBT should be used only on panels whose
edid version is 1.3 or older. EDID version 1.4 introduced offsets
where bpp is defined and hence should be pr
On Thu, 2015-07-30 at 08:00 +0100, Chris Wilson wrote:
> On Thu, Jul 30, 2015 at 09:49:28AM +0300, Mika Kahola wrote:
> > Store max dotclock into dev_priv structure so we are able
> > to filter out the modes that are not supported by our
> > platforms.
> >
> > Signed-off-by: Mika Kahola
> > ---
>
On Thu, 2015-07-30 at 07:54 +0100, Chris Wilson wrote:
> On Thu, Jul 30, 2015 at 09:49:30AM +0300, Mika Kahola wrote:
> > It is possible the we request to have a mode that has
> > higher pixel clock than our HW can support. This patch
> > checks if requested pixel clock is lower than the one
> > su
On 7/30/2015 3:31 PM, Jani Nikula wrote:
On Thu, 30 Jul 2015, Sivakumar Thulasimani
wrote:
From: "Thulasimani,Sivakumar"
CHV does not support intermediate link rates nor does it support
HBR2. This patch removes those entries and returns HBR as the max
link rate supported on CHV platform.
On Thu, 2015-07-30 at 07:52 +0100, Chris Wilson wrote:
> On Thu, Jul 30, 2015 at 09:49:33AM +0300, Mika Kahola wrote:
> > It is possible the we request to have a mode that has
> > higher pixel clock than our HW can support. This patch
> > checks if requested pixel clock is lower than the one
> > su
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6889
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK
On 7/24/2015 5:54 PM, Deepak M wrote:
In CABC (Content Adaptive Brightness Control) content grey level
scale can be increased while simultaneously decreasing
brightness of the backlight to achieve same perceived brightness.
The CABC is not standardized and panel vendors are free to follow
thei
On 30 July 2015 at 15:18, Linus Torvalds wrote:
> On Wed, Jul 29, 2015 at 6:39 PM, Theodore Ts'o wrote:
>>
>> It's here: https://goo.gl/photos/xHjn2Z97JQEw6k2C9
>
> You didn't catch enough of the code line to decode the code, but it's
> early enough in drm_crtc_index() (just five bytes in) that
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6888
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK -1
On Wed, Jul 29, 2015 at 05:23:44PM +0100, Michel Thierry wrote:
> This clean-up version delays the 48-bit work to later patches and includes
> more review comments from Akash and Chris. The first 5 patches prepare the
> dynamic page allocation code to handle independent pdps, but no specific
> code
On 29/07/2015 22:19, Jesse Barnes wrote:
On 07/07/2015 02:15 AM, Tvrtko Ursulin wrote:
On 07/06/2015 01:58 PM, John Harrison wrote:
On 06/07/2015 10:29, Daniel Vetter wrote:
On Fri, Jul 03, 2015 at 12:17:33PM +0100, Tvrtko Ursulin wrote:
On 07/02/2015 04:55 PM, Chris Wilson wrote:
It would b
On 7/30/2015 12:26 PM, Chris Wilson wrote:
On Wed, Jul 29, 2015 at 05:23:44PM +0100, Michel Thierry wrote:
This clean-up version delays the 48-bit work to later patches and includes
more review comments from Akash and Chris. The first 5 patches prepare the
dynamic page allocation code to handle
On Thu, Jul 30, 2015 at 12:52:19PM +0100, Michel Thierry wrote:
> On 7/30/2015 12:26 PM, Chris Wilson wrote:
> >Just a head's up, I haven't root caused this yet, but with
> >i915.enable_ppgtt=2 I started getting GPU hangs that didn't happen
> >before this series...
>
> Sounds like I screwed up som
Reviewed-by: Ander Conselvan de Oliveira
On Mon, 2015-07-27 at 14:35 +0200, Maarten Lankhorst wrote:
> The rest will be a noop anyway, since without modeset there will be
> no updated dplls and no modeset state to update.
>
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/intel_
First step in removing dpms and validating atomic state.
There can still be a mismatch in the connector state because the dpms
callbacks are still used, but this can not happen immediately after a modeset.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_crt.c | 2 --
driver
Right now dpms callbacks can still fiddle with the connector state,
but it can only turn connectors off.
This is remediated by only checking crtc->state->active when the
connector is active, and ignore crtc->state->active when the
connector is off.
connectors_active is no longer checked, and will
Instead of allocating pipe_config on the stack use the old
crtc_state, it's only going to freed from this point on.
All crtc' are now only checked once during modeset,
because false positives can happen with encoders after
dpms changes and to limit the amount of errors for 1 failure.
Changes sinc
connectors_active will be removed, so just calculate this instead.
Changes since v1:
- Look for the right pointer in intel_sanitize_encoder.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/intel_display.c | 17 ++---
1 file changed
Now that everything's atomic, checking encoder->base.crtc is enough.
This function doesn't have the locks to dereference crtc->state, but
stealing an encoder bound to any crtc is probably enough reason to warn.
Changes since v1:
- Commit message.
Cc: Ville Syrjälä
Signed-off-by: Maarten Lankhors
On Thu, Jul 23, 2015 at 05:48:21AM -0400, Mike Frysinger wrote:
> On 01 Jul 2015 14:52, Patrik Jakobsson wrote:
> > Use pkg-config to try to find libdrm. If that fails use the standard
> > include directory for kernel drm headers in /usr/include/drm.
> >
> > * configure.ac: Use pkg-config to find
On 30 Jul 2015 15:30, Patrik Jakobsson wrote:
> On Thu, Jul 23, 2015 at 05:48:21AM -0400, Mike Frysinger wrote:
> > On 01 Jul 2015 14:52, Patrik Jakobsson wrote:
> > > Use pkg-config to try to find libdrm. If that fails use the standard
> > > include directory for kernel drm headers in /usr/include
On Wed, Jul 29, 2015 at 10:18:16PM -0700, Linus Torvalds wrote:
> drivers/gpu/drm/drm_atomic_helper.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 5b59d5ad7d1c..aac212297b49 10
On Jul 30 2015 or thereabouts, Sivakumar Thulasimani wrote:
>
>
> On 7/29/2015 8:52 PM, Benjamin Tissoires wrote:
> >On Jul 29 2015 or thereabouts, Sivakumar Thulasimani wrote:
> >>why not detect reverse in intel_dp_detect/intel_hpd_pulse ? that way you can
> >>identify both lane count and revers
On Wed, Jul 29, 2015 at 08:02:48PM +0100, Chris Wilson wrote:
> If the device does not support the aliasing ppgtt, we must translate
> user bind requests (PIN_USER) from LOCAL_BIND to a GLOBAL_BIND. However,
> since this is device specific we cannot do this conveniently in the
> upper layers and so
On Thu, Jul 30, 2015 at 08:05:07AM +0100, Chris Wilson wrote:
> On Sun, Jun 28, 2015 at 09:19:26AM +0100, Chris Wilson wrote:
> > The old style of memory interleaving swizzled upto the end of the
> > first even bank of memory, and then used the remainder as unswizzled on
> > the unpaired bank - i.e
memcpy(dmc_payload, &fw->data[readcount], dmc_header->fw_size);
dmc_header->fw_size is wrong.
This will result in 0's after 0x80734 location, results in system hang.
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Animesh Manna
Sent:
Hang is due to patch 18 not mmio access.
-Original Message-
From: Manna, Animesh
Sent: Sunday, July 26, 2015 12:31 AM
To: intel-gfx@lists.freedesktop.org
Cc: Manna, Animesh; Lespiau, Damien; Deak, Imre; Kamath, Sunil; Nagaraju,
Vathsala; Bhardwaj, Rajneesh
Subject: [PATCH 15/18] drm/i915
On Thu, Jul 30, 2015 at 04:40:02PM +0200, Daniel Vetter wrote:
> On Wed, Jul 29, 2015 at 10:18:16PM -0700, Linus Torvalds wrote:
> > drivers/gpu/drm/drm_atomic_helper.c | 8 +---
> > 1 file changed, 5 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> >
On Thu, Jul 30, 2015 at 04:40:02PM +0200, Daniel Vetter wrote:
> I have 4 patches in git://people.freedesktop.org/~danvet/drm fixes-stuff
> but I couldn't test them yet since no dp mst here and I didn't find
> anything that would ship faster than 1-2 weeks yet. I'll try to get some
> other people h
On Thu, Jul 30, 2015 at 5:32 PM, Theodore Ts'o wrote:
> On Thu, Jul 30, 2015 at 04:40:02PM +0200, Daniel Vetter wrote:
>> On Wed, Jul 29, 2015 at 10:18:16PM -0700, Linus Torvalds wrote:
>> > drivers/gpu/drm/drm_atomic_helper.c | 8 +---
>> > 1 file changed, 5 insertions(+), 3 deletions(-)
>>
On Thu, 30 Jul 2015 17:32:28 +0200,
Theodore Ts'o wrote:
>
> On Thu, Jul 30, 2015 at 04:40:02PM +0200, Daniel Vetter wrote:
> > On Wed, Jul 29, 2015 at 10:18:16PM -0700, Linus Torvalds wrote:
> > > drivers/gpu/drm/drm_atomic_helper.c | 8 +---
> > > 1 file changed, 5 insertions(+), 3 deletion
On Thu, Jul 30, 2015 at 11:50:29AM -0400, Theodore Ts'o wrote:
> I've tried pulling in your patches from fixes-stuff, onto Linus's tree
> (without Linus's fix), and the good news is that I'm no longer
> crashing on boot.
>
> The *bad* news is that (a) it breaks the external monitor attached to
> t
On Thu, Jul 30, 2015 at 11:50:29AM -0400, Theodore Ts'o wrote:
> On Thu, Jul 30, 2015 at 04:40:02PM +0200, Daniel Vetter wrote:
> > I have 4 patches in git://people.freedesktop.org/~danvet/drm fixes-stuff
> > but I couldn't test them yet since no dp mst here and I didn't find
> > anything that woul
Op 29-07-15 om 14:01 schreef Daniel Vetter:
> With drivers supporting runtime pm it's generally not a good idea to
> touch the hardware when it's off. Add an option to the commit_planes
> helper to support this case.
>
> Note that the helpers already add all planes on a crtc when a modeset
> happen
Changes since v2 [1]:
1/ Move arch_memremap() and arch_memunmap() out of line (Christoph)
2/ Convert region_is_ram() to region_intersects() and define an enum for
its 3 return values. (Luis)
3/ Fix gma500 and i915 to explicitly use cached mappings and clean up
the __iomem usage. (Daniel)
i915 expects the OpRegion to be cached (i.e. not __iomem), so explicitly
map it with memremap rather than the implied cache setting of
acpi_os_ioremap().
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: intel-gfx@lists.freedesktop.org
Cc: David Airlie
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Dan
This applies to all CHV derivatives, including BSW?
Gavin Hindman
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Sivakumar Thulasimani
Sent: Thursday, July 30, 2015 1:45 AM
To: ville.syrj...@linux.intel.com; intel-gfx@lists.freedesktop.o
On Thu, Jul 30, 2015 at 8:57 AM, Takashi Iwai wrote:
> On Thu, 30 Jul 2015 17:32:28 +0200,
> Theodore Ts'o wrote:
>>
>> BTW, is there any chance that I can suspend my laptop, and then move
>> it from my docking station at home (where I have a Dell 30" display)
>> to my docking station at work (whe
On Thu, Jul 30, 2015 at 12:52:19PM +0100, Michel Thierry wrote:
> Sounds like I screwed up something in the first 4 patches or in the
> Wa32bit one. The rest of the changes are contained to 48-bit code.
>
> Have you find a way to reproduce it?
Seems like no. Whatever happened this morning, it has
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6894
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK
From: Damien Lespiau
We need a bit book keeping around power wells' ops->enable(), namely a
nice debug message and updating hw_enabled. Let's introduce a
intel_power_well_enable() function to make sure all the callers do the
same things.
v2 (from Paulo):
- s/i915_power_well_enable/intel_power_
From: Damien Lespiau
Similar to the ->enable vfunc in commit:
commit 865720564389b2b19cf58e41ed31701e5f464b9d
Author: Damien Lespiau
Date: Wed Jun 3 14:27:05 2015 +0100
drm/i915: Extract a intel_power_well_enable() function
v2 (from Paulo):
- Same s/i915_/intel_/ bikeshed as t
Hello
So I discovered that SKL runtime PM doesn't work on drm-intel-nightly and
decided to investigate why. I found this patch in one of Damien's trees and it
fixed the problem I was seeing. I really don't know why the patches were not
sent to the list yet and I can't ask him since he's on vacatio
From: Damien Lespiau
Before this patch, we used the intel_display_power_{get,put} functions
to make sure the PW1 and Misc I/O power wells were enabled all the
time while LCPLL was enabled. We called a get() at
intel_ddi_pll_init() when we discovered that LCPLL was enabled, then
we would call put/
I was told that the "repurposed D1 definition" is still valid for SKL.
It is BDW that is special due to its hotplug bug, so let's
special-case BDW instead of HSW.
Cc: Kristen Carlson Accardi
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_drv.c | 20 +---
1 file change
good catch.
Reviewed-by: Rodrigo Vivi
On Wed, Jul 29, 2015 at 12:21 PM, Marc Herbert wrote:
> With this simple git diff command one can see that skl_init_workarounds()
> got two copies of WaBarrierPerformanceFixDisable:skl:
>
> git diff -U21 ca6e4405779e^1 ca6e4405779e
> drivers/gpu/drm/i915/
This is just a preparation patch to make clear what operation we
are performing. There is no functional change on the sink crc
logic.
hsw_disable_ips has been moved a bit further in the start function
to avoid disabling ips when sink crc is not going to be started.
and to avoid goto on this functi
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6895
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK -1
On Tue, Jul 14, 2015 at 12:30 PM Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Due to the way busy_bits was handled, we were not doing any flushes if
> we didn't previously get an invalidate. Since it's possible to get
> flushes without an invalidate first, remove the busy_bits early
> return.
>
On Tue, Jul 14, 2015 at 12:30 PM Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Because intel_unpin_work_fn() already calls
> intel_frontbuffer_flip_complete() which will call intel_fbc_flush()
> which will call intel_fbc_update() when needed.
>
> We couldn't fix this previously due to the fact th
On Wed, Jul 15, 2015 at 5:31 AM Daniel Vetter wrote:
> On Tue, Jul 14, 2015 at 04:29:13PM -0300, Paulo Zanoni wrote:
> > From: Paulo Zanoni
> >
> > Use the appropriate call.
>
Good!
Reviewed-by: Rodrigo Vivi
> >
> > I know there's a discussion about whether we need this call here at
> > all
Very good. I should've added this when adding the dirtyfb flush...
Thanks,
Reviewed-by: Rodrigo Vivi
On Tue, Jul 14, 2015 at 12:30 PM Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> First, an introduction. We currently have two types of GTT mmaps: the
> "normal" old mmap, and the WC mmap. For
Since active function on VLV immediately activate PSR let's give more
time for idleness. Different from core platforms where we have idle_frames
count.
Also kms_psr_sink_crc now is automated and always get this:
[drm:intel_enable_pipe] enabling pipe A
[drm:intel_edp_backlight_on]
[drm:intel_panel
On 7/30/2015 10:48 PM, Hindman, Gavin wrote:
This applies to all CHV derivatives, including BSW?
Gavin Hindman
yes, this will apply to all CHV derivatives.
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Sivakumar Thulasimani
Sent: Th
Reviewed the patch & it looks fine.
Reviewed-by: "Akash Goel "
On 7/30/2015 3:32 PM, Michel Thierry wrote:
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 f
Reviewed the patch & it looks fine.
Reviewed-by: "Akash Goel "
On 7/30/2015 3:32 PM, Michel Thierry wrote:
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 us
Reviewed the patch & it looks fine.
Reviewed-by: "Akash Goel "
On 7/30/2015 3:35 PM, Michel Thierry wrote:
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 p
Reviewed the patch & it looks fine.
Reviewed-by: "Akash Goel "
On 7/30/2015 3:36 PM, Michel Thierry wrote:
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
On 7/30/2015 3:34 PM, Michel Thierry wrote:
Introduces the Page Map Level 4 (PML4), ie. the new top level structure
of the page tables.
To facilitate testing, 48b mode will be available on Broadwell and
GEN9+, when i915.enable_ppgtt = 3.
v2: Remove unnecessary CONFIG_X86_64 checks, ppgtt code
From: "Thulasimani,Sivakumar"
BPP bits defined in VBT should be used only on panels whose
edid version is 1.3 or older. EDID version 1.4 introduced offsets
where bpp is defined and read into display_info, hence bpp from
VBT will be used only when bpc in display_info is zero.
v2: use display_info
From: "Thulasimani,Sivakumar"
This reverts
commit fe51bfb95c996733150c44d21e1c9f4b6322a326.
Author: Ville Syrjälä
Date: Thu Mar 12 17:10:38 2015 +0200
CHV does not support intermediate frequencies so reverting the
patch that added it in the first place
Signed-off-by: Sivakumar Thulasimani
-
From: "Thulasimani,Sivakumar"
This patch removes 5.4Gbps from supported link rate for CHV since
it is not supported in it.
Signed-off-by: Sivakumar Thulasimani
---
drivers/gpu/drm/i915/intel_dp.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i
86 matches
Mail list logo
