On Thu, Dec 22, 2016 at 10:21:25AM +, Jose Abreu wrote:
> Hi Shashank,
>
>
> On 21-12-2016 15:29, Shashank Sharma wrote:
> > This patch adds a small helper function, which clears the cached
> > information about a hot-pluggable display, from connector. On event
> > This will run on event of a
On Fri, Dec 23, 2016 at 12:29:11AM +0800, kbuild test robot wrote:
> Hi Dhinakaran,
>
> [auto build test ERROR on drm/drm-next]
> [also build test ERROR on next-20161222]
> [cannot apply to v4.9]
> [if your patch is applied to the wrong git tree, please drop us a note to
> help improve the system
On Fri, Dec 23, 2016 at 02:14:00PM -0800, Dhinakaran Pandiyan wrote:
> This check is useful for drivers that do not have DRIVER_ATOMIC set but
> have atomic modesetting internally implemented. Wrap the check into a
> function since this is used in many places and as a bonus, the function
> name hel
On Thu, Dec 22, 2016 at 12:50:43AM -0800, Dhinakaran Pandiyan wrote:
> i915 does not set DRIVER_ATOMIC by default yet but uses atomic_check and
> atomic_commit. drm_object_property_get_value() does not read the correct
> value of atomic properties if DRIVER_ATOMIC is not set. Checking whether
> the
On Tue, Dec 27, 2016 at 12:09:22AM +0100, Sedat Dilek wrote:
> [ Add some pm | i915 | x86 folks ]
>
> Hi,
>
> I have built Linux v4.10-rc1 today on my Ubuntu/precise AMD64 system
> and I see some call-traces.
> It is reproducible on suspend and resume.
>
> I cannot say which area touches the pro
On Sun, 25 Dec 2016, Hans de Goede wrote:
> If there is no OPREGION_ASLE_EXT then a VBT stored in mailbox #4 may
> use the ASLE_EXT parts of the opregion. Adjust the vbt_size calculation
> for a vbt in mailbox #4 for this.
>
> This fixes the driver not finding the VBT on a jumper ezpad mini3
> che
On Mon, 26 Dec 2016, Zhenyu Wang wrote:
> This is current GVT-g device model fixes for 4.10. I need to
> base on v4.10-rc1 for merged vfio and KVMGT support.
Pulled to drm-intel-fixes, thanks.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
___
On Thu, Dec 22, 2016 at 08:36:04AM +, Chris Wilson wrote:
> When we evict from the GTT to make room for an object, the hole we
> create is put onto the MRU stack inside the drm_mm range manager. On the
> next search pass, we can speed up a PIN_HIGH allocation by referencing
> that stack for the
On Thu, Dec 22, 2016 at 02:45:14PM +, Chris Wilson wrote:
> Prime numbers are interesting for testing components that use multiplies
> and divides, such as testing DRM's struct drm_mm alignment computations.
>
> v2: Move to lib/, add selftest
> v3: Fix initial constants (exclude 0/1 from being
On Thu, Dec 22, 2016 at 08:36:08AM +, Chris Wilson wrote:
> When testing, we want a random but yet reproducible order in which to
> process elements. Here we create an array which is a random (using the
> Tausworthe PRNG) permutation of the order in which to execute.
>
> Note these are simple
On Thu, Dec 22, 2016 at 08:36:09AM +, Chris Wilson wrote:
> First we introduce a smattering of infrastructure for writing selftests.
> The idea is that we have a test module that exercises a particular
> portion of the exported API, and that module provides a set of tests
> that can either be r
On Mon, 26 Dec 2016, "Chauhan, Madhav" wrote:
>> -Original Message-
>> From: Nikula, Jani
>> Sent: Friday, December 23, 2016 7:40 PM
>> To: Chauhan, Madhav ; intel-
>> g...@lists.freedesktop.org
>> Cc: Conselvan De Oliveira, Ander ;
>> Saarinen, Jani ; Konduru, Chandra
>> ; Shankar, Uma ;
On Thu, Dec 22, 2016 at 03:12:19PM -0800, Anusha Srivatsa wrote:
> The HuC loading process is similar to GuC. The intel_uc_fw_fetch()
> is used for both cases.
>
> HuC loading needs to be before GuC loading. The WOPCM setting must
> be done early before loading any of them.
>
> v2: rebased on-top
On Thu, Dec 22, 2016 at 08:36:23AM +, Chris Wilson wrote:
> Build the struct drm_mm selftests so that we can trivially run them
> within our CI.
>
> "Enable debug, become developer." - Joonas Lahtinen
>
> Signed-off-by: Chris Wilson
> Reviewed-by: Joonas Lahtinen
Again leaving this one for
On Thu, Dec 22, 2016 at 08:36:28AM +, Chris Wilson wrote:
> A simple assert to ensure that we don't overflow start + size when
> initialising the drm_mm, or its scanner.
>
> In future, we may want to switch to tracking the value of ranges (rather
> than size) so that we can cover the full u64,
Along with below patches sharing some background details/design.
- On BXT, Display cannot generate an interrupt when in D3.
- Without display in D3, S0ix can be achieved, Power impact will be
zero if d3 is blocked. PMCSR for Graphics/Display is irrelevant, as
the power management for them is taken
To support hpd during sleep a new feature flag is
added in vbt and also in dev_priv for enabling/disabling
inside driver. By default this feature will be
disabled and based on oem request this feature can
be enabled by changing vbt feature flag.
v1: Initial version as RFC.
v2: Based on review com
While suspending the device hpd related interrupts are enabled
to get the interrupt when device is in suspend state.
Though display is in DC9 but system can be in S0 or S0i3 state.
Hot plug during S0 state will generate de_port_interrupt but if
system is in S0i3 state then display driver will get
For BXT, display engine can not generate interrupt when in D3.
On the othen hand S0ix can be achieved without display in D3. So,
Display should not put into D3 for HPD to work and will not
have any power impact.
v1: Initial version as RFC.
v2: Based on review comment from David,
condition check f
Guid is changed for bxt platform, so corrected the guid for bxt.
v1: Initial version as RFC.
v2: Based on review comment from Jani and David,
have kept guid as binary format.
v3: Based on review comment from Chris and Jani,
- kept the const for guid.
- corrected the file permission.
Sig
_DSM is added to program HPD_CTL(0x1094) register
of PMC from i915 driver which will be called
based on driver feature flag.
During S0ix display engine is completely powered down. Hot plug will be
missed by display HPD detection logic. GPIO unit detect any edge on HPD
pin and then triggers PMC->Pu
> -Original Message-
> From: Nikula, Jani
> Sent: Tuesday, December 27, 2016 6:04 PM
> To: Chauhan, Madhav ; intel-
> g...@lists.freedesktop.org
> Cc: Conselvan De Oliveira, Ander ;
> Saarinen, Jani ; Konduru, Chandra
> ; Shankar, Uma ;
> Mukherjee, Indranil ; Kumar, Shobhit
> ; Deepak M
>
== Series Details ==
Series: HPD support during suspend for BXT/APL. (rev2)
URL : https://patchwork.freedesktop.org/series/15833/
State : failure
== Summary ==
Series 15833v2 HPD support during suspend for BXT/APL.
https://patchwork.freedesktop.org/api/1.0/series/15833/revisions/2/mbox/
Test
On Thu, Dec 22, 2016 at 01:18:16PM +0200, David Weinehall wrote:
> On Thu, Dec 22, 2016 at 10:52:29AM +0200, Jani Nikula wrote:
> > On Thu, 22 Dec 2016, "Wang, Elaine" wrote:
> > >>
> > >> On Thu, 22 Dec 2016, "Wang, Elaine" wrote:
> > >> > Hi Jani, Ville,
> > >> >
> > >> > Any comment about the
On Tue, 27 Dec 2016, "Chauhan, Madhav" wrote:
>> -Original Message-
>> From: Nikula, Jani
>> Sent: Tuesday, December 27, 2016 6:04 PM
>> To: Chauhan, Madhav ; intel-
>> g...@lists.freedesktop.org
>> Cc: Conselvan De Oliveira, Ander ;
>> Saarinen, Jani ; Konduru, Chandra
>> ; Shankar, Uma ;
On Thu, Dec 22, 2016 at 11:33:23AM +0100, Maarten Lankhorst wrote:
> This reverts commit 527b6abe5fd2d2
> (Revert "drm/i915: Use atomic commits for legacy page_flips")
>
> and reapplies commit ee042aa40b66d1.
> ("drm/i915: Use atomic commits for legacy page_flips")
>
> The reason for the revert w
On Thu, Dec 22, 2016 at 06:39:39PM -0200, Paulo Zanoni wrote:
> Em Qui, 2016-12-22 às 13:52 +, Chris Wilson escreveu:
> > In commit 50349247ea80 ("drm/i915: Drop ORIGIN_GTT for untracked GTT
> > writes") partial mmaps were updated to indicate that writes through
> > them
> > were not tracked au
On Tue, 27 Dec 2016, Daniel Vetter wrote:
> On Thu, Dec 22, 2016 at 01:18:16PM +0200, David Weinehall wrote:
>> On Thu, Dec 22, 2016 at 10:52:29AM +0200, Jani Nikula wrote:
>> > On Thu, 22 Dec 2016, "Wang, Elaine" wrote:
>> > >>
>> > >> On Thu, 22 Dec 2016, "Wang, Elaine" wrote:
>> > >> > Hi Ja
On Thu, Dec 22, 2016 at 04:04:41PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> crtc->config is on its way out. Let's reduce our dependence on it a
> little bit by removing it from intel_modeset_readout_hw_state().
>
> Also replace crtc->acttive checks with crtc_state->b
On Thu, Dec 22, 2016 at 06:42:03PM -0200, Paulo Zanoni wrote:
> I couldn't think of a reason why we would need to unset the CRTCs
> before doing the modesets on this test, so remove all the mode unset
> calls.
There was (not sure whether still is) an issue with the igt_kms library
that it kept the
On Tue, Dec 27, 2016 at 04:46:40PM +0200, Jani Nikula wrote:
> On Tue, 27 Dec 2016, Daniel Vetter wrote:
> > On Thu, Dec 22, 2016 at 01:18:16PM +0200, David Weinehall wrote:
> >> On Thu, Dec 22, 2016 at 10:52:29AM +0200, Jani Nikula wrote:
> >> > On Thu, 22 Dec 2016, "Wang, Elaine" wrote:
> >> >
On Fri, Dec 23, 2016 at 10:23:58AM -0200, Paulo Zanoni wrote:
> Gen9+ platforms have been seeing a lot of screen flickerings and
> underruns, so I never felt comfortable in enabling FBC on these
> platforms since I didn't want to throw yet another feature on top of
> the already complex problem. We
On Tue, Dec 27, 2016 at 10:24:42AM +, Chris Wilson wrote:
> On Tue, Dec 27, 2016 at 12:09:22AM +0100, Sedat Dilek wrote:
> > [ Add some pm | i915 | x86 folks ]
> >
> > Hi,
> >
> > I have built Linux v4.10-rc1 today on my Ubuntu/precise AMD64 system
> > and I see some call-traces.
> > It is re
Em Ter, 2016-12-27 às 15:59 +0100, Daniel Vetter escreveu:
> On Thu, Dec 22, 2016 at 06:42:03PM -0200, Paulo Zanoni wrote:
> >
> > I couldn't think of a reason why we would need to unset the CRTCs
> > before doing the modesets on this test, so remove all the mode
> > unset
> > calls.
>
> There wa
> -Original Message-
> From: Nikula, Jani
> Sent: Tuesday, December 27, 2016 8:18 PM
> To: Chauhan, Madhav ; intel-
> g...@lists.freedesktop.org
> Cc: Conselvan De Oliveira, Ander ;
> Saarinen, Jani ; Konduru, Chandra
> ; Shankar, Uma ;
> Mukherjee, Indranil ; Kumar, Shobhit
> ; Deepak M
>
On Thu, Dec 22, 2016 at 08:36:29AM +, Chris Wilson wrote:
> The scan state occupies a large proportion of the struct drm_mm and is
> rarely used and only contains temporary state. That makes it suitable to
> moving to its struct and onto the stack of the callers.
>
> Signed-off-by: Chris Wilso
On Tue, 27 Dec 2016, Daniel Vetter wrote:
> On Tue, Dec 27, 2016 at 04:46:40PM +0200, Jani Nikula wrote:
>> On Tue, 27 Dec 2016, Daniel Vetter wrote:
>> > On Thu, Dec 22, 2016 at 01:18:16PM +0200, David Weinehall wrote:
>> >> On Thu, Dec 22, 2016 at 10:52:29AM +0200, Jani Nikula wrote:
>> >> > On
On Tue, Dec 27, 2016 at 4:10 PM, Daniel Vetter wrote:
> On Tue, Dec 27, 2016 at 10:24:42AM +, Chris Wilson wrote:
>> On Tue, Dec 27, 2016 at 12:09:22AM +0100, Sedat Dilek wrote:
>> > [ Add some pm | i915 | x86 folks ]
>> >
>> > Hi,
>> >
>> > I have built Linux v4.10-rc1 today on my Ubuntu/prec
On Tue, Dec 27, 2016 at 4:55 PM, Sedat Dilek wrote:
> On Tue, Dec 27, 2016 at 4:10 PM, Daniel Vetter wrote:
>> On Tue, Dec 27, 2016 at 10:24:42AM +, Chris Wilson wrote:
>>> On Tue, Dec 27, 2016 at 12:09:22AM +0100, Sedat Dilek wrote:
>>> > [ Add some pm | i915 | x86 folks ]
>>> >
>>> > Hi,
>>
Hi all -
This series aims at three goals:
1) Most drivers do similar things around drm_get_edid (namely convert
edid to eld, add modes, and update edid blob property). Add a helper for
the drivers, to reduce code and unify.
2) Move override and firmware EDID handling to a lower level, in the
hel
Make the firmware loader more generic and generally useful. In
particular, make it possible for the caller to distinguish between
firmware being there but without modes.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid_load.c| 17 -
drivers/gpu/drm/drm_probe_helper.c |
Will be needed in drm in followup work.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid_load.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/drm_edid_load.c b/drivers/gpu/drm/drm_edid_load.c
index 1c0495acf341..7857864f7878 100644
--- a/drivers/gpu/drm/drm_edid_load
The functional change is that if firmware edid is present, it'll still
bypass get_modes even if number of modes is 0. This is in line with
override edid handling.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_probe_helper.c | 44 --
1 file changed, 28 ins
Add a replacement for drm_get_edid that handles override and firmware
EDID at the low level, and handles EDID property update, ELD update, and
adds modes. This allows for a more transparent EDID override, and makes
it possible to unify the drivers better. It also allows reusing the EDID
cached in t
Don't do caching for now to minimize changes.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_drv.h | 1 -
drivers/gpu/drm/i915/intel_dvo.c | 5 +++--
drivers/gpu/drm/i915/intel_modes.c | 23 ---
drivers/gpu/drm/i915/intel_sdvo.c | 2 +-
4 files changed, 4 i
Will be needed in followup work.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 7 ++-
include/drm/drm_edid.h | 1 +
2 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index fead6622e4b5..56c5065bb314 100644
Make the function useful for resetting the ELD.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 67d6a73731d8..fead6622e4b5 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/
On Tue, Dec 20, 2016 at 11:00:09PM +0100, Srivatsa, Anusha wrote:
>
>
> >-Original Message-
> >From: Hiler, Arkadiusz
> >Sent: Thursday, December 15, 2016 7:47 AM
> >To: intel-gfx@lists.freedesktop.org
> >Cc: Srivatsa, Anusha ; Mcgee, Jeff
> >; Winiarski, Michal
> >Subject: [PATCH 2/5] d
On Fri, Dec 23, 2016 at 01:19:18PM -0800, Daniele Ceraolo Spurio wrote:
>
>
> On 15/12/16 07:47, Arkadiusz Hiler wrote:
> > Let intel_guc_init() focus on determining and fetching the correct
> > firmware.
> >
> > This patch introduces intel_sanitize_uc_params() that is called from
> > intel_uc_i
== Series Details ==
Series: drm: facilitate driver unification around edid read and override
URL : https://patchwork.freedesktop.org/series/17226/
State : success
== Summary ==
Series 17226v1 drm: facilitate driver unification around edid read and override
https://patchwork.freedesktop.org/ap
tree: git://anongit.freedesktop.org/drm-intel drm-intel-nightly
head: 0d15e733fab5dd48154dda2bebdacd1d87069d08
commit: 50f0033d1a0f3a8e9eed09ab68067fbb57b0669d [341/365] drm: Add some
kselftests for the DRM range manager (struct drm_mm)
config: arm-allmodconfig (attached as .config)
compiler:
On Thu, Dec 22, 2016 at 03:12:17PM -0800, Anusha Srivatsa wrote:
> From: Peter Antoine
>
> Rename some of the GuC fw loading code to make them more general. We
> will utilise them for HuC loading as well.
> s/intel_guc_fw/intel_uc_fw/g
> s/GUC_FIRMWARE/UC_FIRMWARE/g
>
> Struct intel_gu
On Thu, Dec 22, 2016 at 03:12:19PM -0800, Anusha Srivatsa wrote:
> The HuC loading process is similar to GuC. The intel_uc_fw_fetch()
> is used for both cases.
>
> HuC loading needs to be before GuC loading. The WOPCM setting must
> be done early before loading any of them.
>
> v2: rebased on-top
On Tue, Dec 27, 2016 at 06:21:53PM +0200, Jani Nikula wrote:
> Add a replacement for drm_get_edid that handles override and firmware
> EDID at the low level, and handles EDID property update, ELD update, and
> adds modes. This allows for a more transparent EDID override, and makes
> it possible to
On Tue, Dec 27, 2016 at 06:21:47PM +0200, Jani Nikula wrote:
> Hi all -
>
> This series aims at three goals:
>
> 1) Most drivers do similar things around drm_get_edid (namely convert
> edid to eld, add modes, and update edid blob property). Add a helper for
> the drivers, to reduce code and unify
On Wed, Dec 28, 2016 at 12:57:07AM +0800, kbuild test robot wrote:
> tree: git://anongit.freedesktop.org/drm-intel drm-intel-nightly
> head: 0d15e733fab5dd48154dda2bebdacd1d87069d08
> commit: 50f0033d1a0f3a8e9eed09ab68067fbb57b0669d [341/365] drm: Add some
> kselftests for the DRM range manage
tree: git://anongit.freedesktop.org/drm-intel drm-intel-nightly
head: 5ef04beec703ce4188efde073eca2bf69a6c00a3
commit: 9a71e277888b39b8f0e8364813ec1ba58a5a4371 [361/366] drm: Extract struct
drm_mm_scan from struct drm_mm
reproduce: make htmldocs
All warnings (new ones prefixed by >>):
mak
Hi!
> [ Add some pm | i915 | x86 folks ]
>
> Hi,
>
> I have built Linux v4.10-rc1 today on my Ubuntu/precise AMD64 system
> and I see some call-traces.
> It is reproducible on suspend and resume.
>
> I cannot say which area touches the problem or if these are several
> independent problems.
>
Hi Nikula,
Could you help to review this patch?
Thanks,
Elaine
-Original Message-
From: Wang, Elaine
Sent: Friday, December 23, 2016 5:02 PM
To: intel-gfx@lists.freedesktop.org
Cc: Wang, Elaine ; Chris Wilson
; Joonas Lahtinen ;
Jani Nikula
Subject: [PATCH] drm/i915: Check num_pipes
While suspending the device hpd related interrupts are enabled
to get the interrupt when device is in suspend state.
Though display is in DC9 but system can be in S0 or S0i3 state.
Hot plug during S0 state will generate de_port_interrupt but if
system is in S0i3 state then display driver will get
60 matches
Mail list logo
