On Tue, 2015-06-02 at 18:17 +0300, Jani Nikula wrote:
> On Tue, 02 Jun 2015, Mika Kahola wrote:
> > From: Ville Syrjälä
> >
> > Rather that extracting the current cdclk freuqncy every time someone
> > wants to know it, cache the current value and use that. VLV/CHV already
> > stored a cached valu
Op 03-06-15 om 03:28 schreef Matt Roper:
> On Mon, Jun 01, 2015 at 03:27:10PM +0200, Maarten Lankhorst wrote:
>> Move the check for encoder cloning here.
>>
>> Signed-off-by: Maarten Lankhorst
>> ---
>> drivers/gpu/drm/i915/intel_atomic.c | 5 +-
>> drivers/gpu/drm/i915/intel_display.c | 131
Op 03-06-15 om 03:27 schreef Matt Roper:
> On Mon, Jun 01, 2015 at 03:27:07PM +0200, Maarten Lankhorst wrote:
>> Use for_each_crtc_state to only touch affected crtc's.
>> In order to make sure that the initial power is still set
>> correctly we make sure modeset_update_crtc_power_domains is called
Op 03-06-15 om 03:27 schreef Matt Roper:
> On Mon, Jun 01, 2015 at 03:27:06PM +0200, Maarten Lankhorst wrote:
>> Apply force if needed.
> It's not clear to me what this means; can you elaborate? It seems that
> 'force' in the context of intel_crtc_control() means we're updating the
> 'enable' fiel
On Wed, 03 Jun 2015, Ben Widawsky wrote:
> in
> commit 65ca7514e21adbee25b8175fc909759c735d00ff
> Author: Damien Lespiau
> Date: Mon Feb 9 19:33:22 2015 +
>
> drm/i915/skl: Implement WaBarrierPerformanceFixDisable
>
> The workaround ended up in the chv workarounds. Not sure what the rea
+intel-gfx, anyone up for a backport?
BR,
Jani.
On Wed, 03 Jun 2015, gre...@linuxfoundation.org wrote:
> The patch below does not apply to the 4.0-stable tree.
> If someone wants it applied there, or to any other stable or longterm
> tree, then please email the backport, including the original g
On 5/26/2015 5:50 PM, Sonika Jindal wrote:
BXT supports following intermediate link rates for edp:
2.16GHz, 2.43GHz, 3.24GHz, 4.32GHz.
Adding support for programming the intermediate rates.
v2: Adding clock in bxt_clk_div struct and then look for the entry with
required rate (Ville)
v3: 'clock
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6527
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV
Hi Vandana,
Can you please review the v6 of this patch?
This was rebased recently on top of your patch:
commit b6dc71f38a84e36c5445b95f9f7a2dac6b25636f
Author: Vandana Kannan
Date: Wed May 13 12:18:52 2015 +0530
drm/i915/bxt: Port PLL programming BUN
Thanks,
Sonika
On 5/26/2015 5:
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6526
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV
> -Original Message-
> From: Roper, Matthew D
> Sent: Tuesday, June 02, 2015 6:30 PM
> To: Maarten Lankhorst
> Cc: intel-gfx@lists.freedesktop.org; Konduru, Chandra
> Subject: Re: [Intel-gfx] [PATCH 08/24] drm/i915: Do not add planes from
> intel_atomic_setup_scalers.
>
> On Mon, Jun 01,
On Mon, Jun 01, 2015 at 03:27:11PM +0200, Maarten Lankhorst wrote:
> This may postpone going to HQ mode until the plane is in the
> drm_atomic_state if it's not using scaler 0, but it does allow moving
> intel_atomic_setup_scalers to the crtc check function.
>
> Signed-off-by: Maarten Lankhorst
>
On Mon, Jun 01, 2015 at 03:27:07PM +0200, Maarten Lankhorst wrote:
> Use for_each_crtc_state to only touch affected crtc's.
> In order to make sure that the initial power is still set
> correctly we make sure modeset_update_crtc_power_domains is called
> during the initial modeset.
>
> Signed-off-
On Mon, Jun 01, 2015 at 03:27:10PM +0200, Maarten Lankhorst wrote:
> Move the check for encoder cloning here.
>
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/intel_atomic.c | 5 +-
> drivers/gpu/drm/i915/intel_display.c | 131
> ---
> 2 files
On Mon, Jun 01, 2015 at 03:27:06PM +0200, Maarten Lankhorst wrote:
> Apply force if needed.
It's not clear to me what this means; can you elaborate? It seems that
'force' in the context of intel_crtc_control() means we're updating the
'enable' field as well, not just the 'active' field.
> During
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6525
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV
in
commit 65ca7514e21adbee25b8175fc909759c735d00ff
Author: Damien Lespiau
Date: Mon Feb 9 19:33:22 2015 +
drm/i915/skl: Implement WaBarrierPerformanceFixDisable
The workaround ended up in the chv workarounds. Not sure what the reason or
history of that is, but it /seems/ wrong. Don't k
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6524
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6523
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV
After GPU reset, HW is losing the address of HWS page in the register.
The page itself is valid except that HW is not aware of its location.
[ 64.368623] [drm:gen8_init_common_ring [i915]] *ERROR* HWS Page address =
0x
[ 64.368655] [drm:gen8_init_common_ring [i915]] *ERROR* HWS Page a
> > > @@ -541,6 +541,66 @@ static void g4x_set_infoframes(struct drm_encoder
> > > *encoder,
> > > intel_hdmi_set_hdmi_infoframe(encoder, adjusted_mode); }
> > >
> > > +static bool hdmi_sink_is_deep_color(struct drm_encoder *encoder) {
> >
> > Some static functions are prefixed but this isn't. C
On 02/06/15 19:36, Siluvery, Arun wrote:
> On 01/06/2015 11:22, Daniel, Thomas wrote:
>>>
>>> Indeed, allocating an extra scratch page in the context would simplify
>>> vma/mm management. A trick might be to allocate the scratch page at the
>>> start, then offset the lrc regs etc - that would then
On 01/06/2015 11:22, Daniel, Thomas wrote:
Indeed, allocating an extra scratch page in the context would simplify
vma/mm management. A trick might be to allocate the scratch page at the
start, then offset the lrc regs etc - that would then be consistent
amongst gen and be easy enough to extend i
On 29/05/2015 17:44, john.c.harri...@intel.com wrote:
From: John Harrison
As there is no OLR to check, the check_olr() function is now a no-op and can be
removed.
For: VIZ-5115
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i915_drv.h |1 -
drivers/gpu/drm/i915/i915_gem.c
On 29/05/2015 17:44, john.c.harri...@intel.com wrote:
From: John Harrison
The i915_gem_object_flush_active() call used to do lots. Over time it has done
less and less. Now all it does check the various associated requests to see if
they can be retired. Hence this patch renames the function and
On 29/05/2015 17:43, john.c.harri...@intel.com wrote:
From: John Harrison
The plan is to pass requests around as the basic submission tracking structure
rather than rings and contexts. This patch updates the i915_gem_object_sync()
code path.
v2: Much more complex patch to share a single reques
On 29/05/2015 17:43, john.c.harri...@intel.com wrote:
From: John Harrison
In execlist mode, context initialisation is deferred until first use of the
given context. This is because execlist mode has per ring context state and thus
many more context storage objects than legacy mode and many are
> > > @@ -560,6 +560,49 @@ static bool hdmi_sink_is_deep_color(struct
> > > drm_encoder *encoder)
> > > return false;
> > > }
> > >
> > > +/*
> > > + * Determine if default_phase=1 can be indicated in the GCP infoframe.
> > > + *
> > > + * From HDMI specification 1.4a:
> > > + * - The first pixe
On 29/05/2015 17:43, john.c.harri...@intel.com wrote:
From: John Harrison
Now that a single per ring loop is being done for all the different
intialisation steps in i915_gem_init_hw(), it is possible to add proper request
management as well. The last remaining issue is that the context enable c
> -Original Message-
> From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> Sent: Tuesday, June 02, 2015 4:11 AM
> To: Konduru, Chandra
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v2 6/9] drm/i915: Disable all infoframes when
> turning off the HDMI port
On 29/05/2015 17:43, john.c.harri...@intel.com wrote:
From: John Harrison
In order to explcitly track all GPU work (and completely remove the outstanding
lazy request), it is necessary to add extra i915_add_request() calls to various
places. Some of these do not need the implicit cache flush do
On 29/05/2015 17:43, john.c.harri...@intel.com wrote:
From: John Harrison
The i915_add_request() function is called to keep track of work that has been
written to the ring buffer. It adds epilogue commands to track progress (seqno
updates and such), moves the request structure onto the right li
On 29/05/2015 17:43, john.c.harri...@intel.com wrote:
From: John Harrison
It is a bad idea for i915_add_request() to fail. The work will already have been
send to the ring and will be processed, but there will not be any tracking or
management of that work.
The only way the add request call ca
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6522
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV
On Tue, 02 Jun 2015, Ville Syrjälä wrote:
> On Tue, Jun 02, 2015 at 07:21:15PM +0300, Jani Nikula wrote:
>> Passive DP->DVI/HDMI dongles on DP++ ports show up to the system as HDMI
>> devices, as they do not have a sink device in them to respond to any AUX
>> traffic. When probing these dongles ov
On Tue, Jun 02, 2015 at 07:21:15PM +0300, Jani Nikula wrote:
> Passive DP->DVI/HDMI dongles on DP++ ports show up to the system as HDMI
> devices, as they do not have a sink device in them to respond to any AUX
> traffic. When probing these dongles over the DDC, sometimes they will
> NAK the first
Passive DP->DVI/HDMI dongles on DP++ ports show up to the system as HDMI
devices, as they do not have a sink device in them to respond to any AUX
traffic. When probing these dongles over the DDC, sometimes they will
NAK the first attempt even though the transaction is valid and they
support the DDC
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6520
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV
On Tue, 02 Jun 2015, Mika Kahola wrote:
> From: Ville Syrjälä
>
> Rather that extracting the current cdclk freuqncy every time someone
> wants to know it, cache the current value and use that. VLV/CHV already
> stored a cached value there so just expand that to cover all platforms.
All of the be
On Tue, Jun 02, 2015 at 03:51:26PM +0100, Michel Thierry wrote:
> On 5/22/2015 6:05 PM, Mika Kuoppala wrote:
> > When we setup page directories and tables, we point the entries
> > to a to the next level scratch structure. Make this generic
> > by introducing a fill_page_dma which maps and flushes.
On 5/22/2015 6:05 PM, Mika Kuoppala wrote:
When we setup page directories and tables, we point the entries
to a to the next level scratch structure. Make this generic
by introducing a fill_page_dma which maps and flushes. We also
need 32 bit variant for legacy gens.
v2: Fix flushes and handle va
On 5/22/2015 6:05 PM, Mika Kuoppala wrote:
This has slipped in somewhere but it was harmless
as we check the page pointer before teardown.
Signed-off-by: Mika Kuoppala
Right, free_pd is only for gen8+.
Reviewed-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 1 -
1 file cha
On Tue, Jun 02, 2015 at 01:42:52PM +0300, Jani Nikula wrote:
> Passive DP->DVI/HDMI dongles on DP++ ports show up to the system as HDMI
> devices, as they do not have a sink device in them to respond to any AUX
> traffic. When probing these dongles over the DDC, sometimes they will
> NAK the first
On 5/22/2015 6:05 PM, Mika Kuoppala wrote:
All the paging structures are now similar and mapped for
dma. The unmapping is taken care of by common accessors, so
don't overload the reader with such details.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 32 ++
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6519
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV
On Mon, Jun 01, 2015 at 09:49:40PM +, Konduru, Chandra wrote:
>
>
> > -Original Message-
> > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> > Of
> > ville.syrj...@linux.intel.com
> > Sent: Tuesday, May 05, 2015 7:06 AM
> > To: intel-gfx@lists.freedesktop
On Tue, Jun 02, 2015 at 03:37:35PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> commit 65ca7514e21adbee25b8175fc909759c735d00ff
> Author: Damien Lespiau
> Date: Mon Feb 9 19:33:22 2015 +
>
> drm/i915/skl: Implement WaBarrierPerformanceFixDisable
>
> got mi
On Mon, Jun 01, 2015 at 11:11:15AM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Current userptr kernel implementation downgrades tracking VMA ranges (real
> userspace ones) to an inefficient linear walk for any process which has
> instantiated overlapping userptr objects.
>
> This add
On 5/22/2015 6:05 PM, Mika Kuoppala wrote:
All our paging structures have struct page and dma address
for that page.
Add struct for page/dma address pairs and use it to make
the setup and teardown for different paging structures
identical.
Include the page directory offset also in the struct fo
From: Ville Syrjälä
INSTPM is saved in the logical context so we should initialize it using
LRIs on gen8. It actually defaults to 1 starting from HSW, but let's
keep the write around anyway.
Also drop the INSTPM_FORCE_ORDERING setup entirely on gen9+ since it's
now a reserved bit.
Signed-off-by
From: Ville Syrjälä
MI_MODE is saved in the logical context so WaDisableAsyncFlipPerfMode
must be applied using LRIs on gen8.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/
From: Ville Syrjälä
commit 65ca7514e21adbee25b8175fc909759c735d00ff
Author: Damien Lespiau
Date: Mon Feb 9 19:33:22 2015 +
drm/i915/skl: Implement WaBarrierPerformanceFixDisable
got misapplied and the code landed in chv_init_workarounds() instead of
the intended skl_init_workaroun
I am seeing the following in the dmesg on 4.0.4 with rt patch
[5.720319] [ cut here ]
[5.720347] WARNING: CPU: 6 PID: 466 at
drivers/gpu/drm/i915/intel_display.c:9748
intel_check_page_flip+0xaa/0xf0 [i915]()
[5.720349] WARN_ON(!in_interrupt())
[5.720350] Mod
Hello,
I want to use custom EDID for one of my monitors. This because the monitor
has a broken EDID structure. I have been trying to use a custom EDID (a
binary message was saved before) within Xorg.conf. Is this possible?
I have installed the drivers by using :
Intel(R) Graphics Installer for
Hey,
this just popped up in the dmesg of my Dell XPS 13 -- the system seems to
run well, but still, it asks about being cut and sent, so here it is. It is
on 4.1.0-rc4+ (Linus' tree as of May 24th, around 3pm UTC -- don't have the
git commit ID anymore).
[ cut here ]
WARNI
Hi Damien,
Yes we are getting the IGT's ready, and already we have a test tool to apply
CSC/Gamma already, which we used for ULT.
As discussed in the parallel forums, we will finally use Chrome UI to test the
end-to-end UI level effects
Regards
Shashank
-Original Message-
From: Lespi
On Tue, Jun 02, 2015 at 01:22:42AM +0530, Kausal Malladi wrote:
> From: Kausal Malladi
>
> This patch set adds color manager implementation in drm/i915 layer.
Is anyone working on tests/test plan?
Thanks,
--
Damien
___
Intel-gfx mailing list
Intel-g
On Tue, 02 Jun 2015, Ville Syrjälä wrote:
> On Tue, Jun 02, 2015 at 02:17:47PM +0300, Ander Conselvan de Oliveira wrote:
>> Add all missing platforms handled by intel_set_memory_cxsr() to the
>> i915_sr_status debugfs entry.
>>
>> v2: Add G4X too. (Ville)
>> Clarify the change also affects CH
Hi,
On 2 June 2015 at 12:38, Jindal, Sonika wrote:
> On 6/2/2015 1:22 AM, Kausal Malladi wrote:
>> +int drm_mode_crtc_update_color_property(struct drm_device *dev,
>> + struct drm_property_blob **blob,
>> + size_t length, const void *color_data,
>> + stru
On Tue, Jun 02, 2015 at 02:17:47PM +0300, Ander Conselvan de Oliveira wrote:
> Add all missing platforms handled by intel_set_memory_cxsr() to the
> i915_sr_status debugfs entry.
>
> v2: Add G4X too. (Ville)
> Clarify the change also affects CHV. (Ander)
>
> References: https://bugs.freedeskt
On Mon, Jun 01, 2015 at 09:49:53PM +, Konduru, Chandra wrote:
>
>
> > -Original Message-
> > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> > Of
> > ville.syrj...@linux.intel.com
> > Sent: Tuesday, May 05, 2015 7:06 AM
> > To: intel-gfx@lists.freedesktop
Oops, didn't mean to send this here since it is not graphics related.
But it does happen on SKL so maybe it will be useful for someone.
Tvrtko
On 06/02/2015 12:37 PM, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Since this drivers creates attributes on the heap, lockdep
gets upset and disable
On 6/2/2015 1:22 AM, Kausal Malladi wrote:
From: Kausal Malladi
This patch does the following:
1. Adds the core function to program Gamma correction values for CHV/BSW
platform
2. Adds Gamma correction macros/defines
3. Adds drm_mode_crtc_update_color_property function, which replaces the
From: Tvrtko Ursulin
Since this drivers creates attributes on the heap, lockdep
gets upset and disabled itself.
Fix by setting ignore_lockdep flags for problematic attributes.
Signed-off-by: Tvrtko Ursulin
Cc: Alexander Shishkin
Cc: Ingo Molnar
Cc: Peter Zijlstra (Intel)
Cc: x...@kernel.org
Hi,
On 2 June 2015 at 12:25, Jindal, Sonika wrote:
> On 6/2/2015 1:22 AM, Kausal Malladi wrote:
>> struct drm_intel_gamma {
>> __u32 flags;
>> (The flag variable will indicate if the property to be set/get
>> is Gamma or DeGamma)
>> __u32 gamma_level;
>> (T
On 6/2/2015 1:22 AM, Kausal Malladi wrote:
From: Kausal Malladi
This patch adds a new structure in DRM layer for Gamma color correction.
This structure will be used by all user space agents to configure
appropriate Gamma precision and Gamma level.
struct drm_intel_gamma {
__u32 flags
On 6/2/2015 1:22 AM, Kausal Malladi wrote:
From: Kausal Malladi
This patch adds set property interface for Intel CRTC. This interface
will be used to set color correction DRM properties.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/intel_display.c
Add all missing platforms handled by intel_set_memory_cxsr() to the
i915_sr_status debugfs entry.
v2: Add G4X too. (Ville)
Clarify the change also affects CHV. (Ander)
References: https://bugs.freedesktop.org/show_bug.cgi?id=89792
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/
On Mon, Jun 01, 2015 at 10:48:03PM +, Konduru, Chandra wrote:
>
>
> > -Original Message-
> > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> > Of
> > ville.syrj...@linux.intel.com
> > Sent: Tuesday, May 05, 2015 7:06 AM
> > To: intel-gfx@lists.freedesktop
On 6/2/2015 1:22 AM, Kausal Malladi wrote:
From: Kausal Malladi
Color Manager is an extension in i915 driver to handle color correction
and enhancements across various Intel platforms.
This patch initializes color manager framework by :
1. Adding two new files, intel_color_manager(.c/.h)
2.
Zhigang Gong writes:
> The patchset LGTM and works well with beignet. The 80%+ performance
> regression issue in darktable also has been fixed
> after this patchset applied and enable the atomic in L3 at beignet side. So,
>
> Reviewed-by: Zhigang Gong
>
> Thanks,
> Zhigang Gong.
>
Thanks!
>> -
On Tue, Jun 02, 2015 at 10:20:58AM +0300, Mika Kahola wrote:
> This patch series rebases Ville's original cdclk patch series
> excluding the ones that has already been reviewed.
FYI, When a patch that has been reviewed is resent, we usually but the
r-b tags tags along (yes, I know, confusing
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6518
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV
Passive DP->DVI/HDMI dongles on DP++ ports show up to the system as HDMI
devices, as they do not have a sink device in them to respond to any AUX
traffic. When probing these dongles over the DDC, sometimes they will
NAK the first attempt even though the transaction is valid and they
support the DDC
On Tue, Jun 02, 2015 at 11:29:23AM +0300, Jani Nikula wrote:
> Passive DP->DVI/HDMI dongles on DP++ ports show up to the system as HDMI
> devices, as they do not have a sink device in them to respond to any AUX
> traffic. When probing these dongles over the DDC, sometimes they will
> NAK the first
On 5/22/2015 6:05 PM, Mika Kuoppala wrote:
The legacy mode mm switch and the execlist context assignment
needs dma address for the page directories.
Introduce a function that encapsulates the scratch_pd dma
fallback if no pd is found.
Signed-off-by: Mika Kuoppala
Reviewed-by: Michel Thierry
On 5/22/2015 6:04 PM, Mika Kuoppala wrote:
We are always allocating a single page. No need to be verbose so
remove the suffix.
Signed-off-by: Mika Kuoppala
I saw another of your patches will take care of
i915_dma_map_single/i915_dma_unmap_single...
Reviewed-by: Michel Thierry
__
On pe, 2015-05-22 at 20:04 +0300, Mika Kuoppala wrote:
> We are always allocating a single page. No need to be verbose so
> remove the suffix.
>
> Signed-off-by: Mika Kuoppala
Reviewed-by: Joonas Lahtinen
> ---
> drivers/gpu/drm/i915/i915_gem_gtt.c | 16
> 1 file changed, 8 ins
On ma, 2015-06-01 at 12:01 -0700, Rodrigo Vivi wrote:
> On Mon, Jun 1, 2015 at 12:32 AM, Imre Deak wrote:
> > The divider value to convert from CZ clock rate to ms needs a +1
> > adjustment on VLV just like on CHV. This matches both the spec and
> > the accuracy test by pm_rc6_residency.
> >
> > v
The patchset LGTM and works well with beignet. The 80%+ performance regression
issue in darktable also has been fixed
after this patchset applied and enable the atomic in L3 at beignet side. So,
Reviewed-by: Zhigang Gong
Thanks,
Zhigang Gong.
> -Original Message-
> From: Francisco Jere
Op 01-06-15 om 15:27 schreef Maarten Lankhorst:
> This patch series requires the following prerequisites:
> "[PATCH v4 00/27] Convert to atomic, part 2"
> "[PATCH] drm/atomic: Clear crtc_state->active in
> drm_atomic_helper_set_config."
>
> Now that suspend/restore is atomic it's time to clean up
Passive DP->DVI/HDMI dongles on DP++ ports show up to the system as HDMI
devices, as they do not have a sink device in them to respond to any AUX
traffic. When probing these dongles over the DDC, sometimes they will
NAK the first attempt even though the transaction is valid and they
support the DDC
On 27.05.2015 14:34, Daniel Vetter wrote:
> On Tue, May 26, 2015 at 05:21:56PM -0700, Rodrigo Vivi wrote:
>> On Thu, May 21, 2015 at 5:04 AM, Animesh Manna
>> wrote:
>>> Naming convention of csr firmware will be -
>>> _dmc__.bin
>>>
>>> Accordingly updated the same in code.
>>>
>>> Signed-off-by:
On pe, 2015-05-22 at 20:04 +0300, Mika Kuoppala wrote:
> Free the scratch page if dma mapping fails.
>
> Signed-off-by: Mika Kuoppala
Reviewed-by: Joonas Lahtinen
> ---
> drivers/gpu/drm/i915/i915_gem_gtt.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/g
On Tue, 2015-06-02 at 09:27 +0200, Maarten Lankhorst wrote:
> Op 02-06-15 om 09:12 schreef Jani Nikula:
> > On Mon, 01 Jun 2015, Ander Conselvan de Oliveira
> > wrote:
> >> Since the force restore logic will restore the CRTCs state one at a
> >> time, it is possible that the state will be inconsi
Op 02-06-15 om 09:12 schreef Jani Nikula:
> On Mon, 01 Jun 2015, Ander Conselvan de Oliveira
> wrote:
>> Since the force restore logic will restore the CRTCs state one at a
>> time, it is possible that the state will be inconsistent until the whole
>> operation finishes. A call to intel_modeset_c
This patch series rebases Ville's original cdclk patch series
excluding the ones that has already been reviewed.
http://lists.freedesktop.org/archives/intel-gfx/2014-November/055633.html
The patches are rebased to the latest drm-intel-nightly. The major change
to the original series is the patch
From: Ville Syrjälä
Add support for changing cdclk frequency during runtime on BDW. The
procedure is quite a bit different on BDW from the one on HSW, so
add a separate function for it.
Also with IPS enabled the actual pixel rate mustn't exceed 95% of cdclk,
so take that into account when comput
From: Ville Syrjälä
ilk_get_aux_clock_divider() is now a subset of
hsw_get_aux_clock_divider() so unify them.
Signed-off-by: Ville Syrjälä
v2: Rebased to the latest
v3: Rebased to the latest
Signed-off-by: Mika Kahola
Author:Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dp.c | 23 +++--
From: Ville Syrjälä
Rather that extracting the current cdclk freuqncy every time someone
wants to know it, cache the current value and use that. VLV/CHV already
stored a cached value there so just expand that to cover all platforms.
Signed-off-by: Ville Syrjälä
v2: Rebased to the latest
v3: Re
From: Ville Syrjälä
Implement support for changing the cdclk frequency during runtime on
HSW. VLV/CHV already have support for this, so we can follow their
example for the most part. Only the actual hardware programming differs,
the rest is pretty much the same.
The pipe pixel rate stuff is hand
From: Ville Syrjälä
Rather than reading out the current cdclk value use the cached value we
have tucked away in dev_priv.
Signed-off-by: Ville Syrjälä
v2: Rebased to the latest
v3: Rebased to the latest
Signed-off-by: Mika Kahola
Author:Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dis
From: Ville Syrjälä
Keep the cdclk maximum supported frequency around in dev_priv so that we
can verify certain things against it before actually changing the cdclk
frequency.
For now only VLV/CHV have support changing cdclk frequency, so other
plarforms get to assume cdclk is fixed.
Signed-off
From: Ville Syrjälä
We need to tell BDW ULT and ULX apart.
Signed-off-by: Ville Syrjälä
v2: Rebased to the latest
v3: Rebased to the latest
Signed-off-by: Mika Kahola
Author:Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/driver
From: Ville Syrjälä
Bspec says we shouldn't enable IPS on BDW when the pipe pixel rate
exceeds 95% of the core display clock. Apparently this can cause
underruns.
There's no similar restriction listed for HSW, so leave that one alone
for now.
v2: Add pipe_config_supports_ips() (Chris)
v3: Compa
On Mon, 01 Jun 2015, Ander Conselvan de Oliveira
wrote:
> Since the force restore logic will restore the CRTCs state one at a
> time, it is possible that the state will be inconsistent until the whole
> operation finishes. A call to intel_modeset_check_state() is done once
> it's over, so don't c
All users of async updates seem to clear clear crtc_state->event
correctly, so move destroying vblank event to crtc_destroy_state.
This is better than manually free'ing it in the atomic ioctl, since
this code seems to do it wrong.
While we're at it handle -EDEADLK from atomic_commit correctly,
be
97 matches
Mail list logo
