> -Original Message-
> From: Nikula, Jani
> Sent: Wednesday, January 18, 2017 9:00 PM
> To: Chauhan, Madhav ; intel-
> g...@lists.freedesktop.org
> Cc: Shankar, Uma ; Mukherjee, Indranil
> ; Kamath, Sunil ;
> Saarinen, Jani ; Conselvan De Oliveira, Ander
> ; Konduru, Chandra
> ; Kumar, Shob
On 18/01/2017 16:53, Chris Wilson wrote:
We always try to do an unlocked wait before resorting to having a
blocking wait under the mutex - so we very rarely have to sleep under
the struct_mutex. However, when we do we want that wait to be as short
as possible as the struct_mutex is our BKL that
From: Uma Shankar
Enable MIPI IO WA for BXT DSI as per bspec and
program the DSI regulators.
v2: Moved IO enable to pre-enable as per Mika's
review comments. Also reused the existing register
definition for BXT_P_CR_GT_DISP_PWRON.
v3: Added Programming the DSI regulators as per disable/enable
s
> -Original Message-
> From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
> Sent: Wednesday, January 18, 2017 3:08 PM
> To: Srinivas, Vidya ; Ville Syrjälä
> ; Deak, Imre
> Cc: Kahola, Mika ; intel-gfx@lists.freedesktop.org;
> Conselvan De Oliveira, Ander ;
> imre.d...@linux.intel.co
> -Original Message-
> From: Deak, Imre
> Sent: Wednesday, January 18, 2017 3:46 PM
> To: Srinivas, Vidya
> Cc: Ville Syrjälä ; Jani Nikula
> ; Kahola, Mika ; intel-
> g...@lists.freedesktop.org; Conselvan De Oliveira, Ander
> ; imre.d...@linux.intel.com
> Subject: Re: [Intel-gfx] [PATCH
On 2017-01-17 03:22 AM, Mika Kahola wrote:
Fixes for issues seen on CI tests. The patches provide relaxed timing
requirement for atomic commit as well as general cleanup to favor library
functions.
v2: fix MAX_CRCS definition
Mika Kahola (2):
tests/kms_plane_multiple: Relax atomic commit time
Hi Maarten,
On Tuesday 17 Jan 2017 08:41:03 Maarten Lankhorst wrote:
> Op 17-01-17 om 00:11 schreef Laurent Pinchart:
> > On Monday 16 Jan 2017 10:37:38 Maarten Lankhorst wrote:
> >> Add for_each_(old)(new)_(plane,connector,crtc)_in_state iterators to
> >> replace the old for_each_xxx_in_state one
== Series Details ==
Series: drm/i915: prevent crash with .disable_display parameter (rev2)
URL : https://patchwork.freedesktop.org/series/18151/
State : failure
== Summary ==
Series 18151v2 drm/i915: prevent crash with .disable_display parameter
https://patchwork.freedesktop.org/api/1.0/serie
On Wed, 2017-01-18 at 10:12 +0200, Jani Nikula wrote:
> On Tue, 17 Jan 2017, Rodrigo Vivi wrote:
> > On Mon, Jan 16, 2017 at 2:04 AM, Jani Nikula
> > wrote:
> >> On Fri, 13 Jan 2017, Rodrigo Vivi wrote:
> >>> This and all the remaining patches on this series (6,7,8 and 9) got
> >>> merged to din
From: Clint Taylor
The .disable_display parameter was causing a fatal crash when fbdev
was dereferenced during driver init.
V1: protection in i915_drv.c
V2: Moved protection to intel_fbdev.c
Cc: Chris Wilson
Signed-off-by: Clint Taylor
---
drivers/gpu/drm/i915/intel_fbdev.c |3 +++
1 fi
On 16/12/16 15:48, Daniel Vetter wrote:
On Fri, Dec 16, 2016 at 12:29:05PM +0200, Jani Nikula wrote:
The two remaining patches from [1], rebased.
BR,
Jani.
[1]
http://mid.mail-archive.com/1480984058-552-1-git-send-email-manasi.d.navare@intel.com
Just for the record, I think the only thing
Execlists introduces a new wrinkle to filling rings, in that each
context has an independent set of rings. Add the subtest that exercises
filling multiple execlist rings (for the same engine) to BAT.
Signed-off-by: Chris Wilson
Cc: Petri Latvala
---
tests/intel-ci/fast-feedback.testlist | 3 ++-
On Wed, Jan 11, 2017 at 03:44:12PM +0200, Petri Latvala wrote:
>
> Hi
>
> The copyright statements still need the year
> corrected. intel_dp_compliance needs to be added to tools/.gitignore
>
> Some new comments also:
>
> - Why do some of the prints have \r\n?
The \r\n is required in some of t
Hi Maarten,
On Wednesday 18 Jan 2017 15:49:56 Maarten Lankhorst wrote:
> Op 17-01-17 om 02:01 schreef Laurent Pinchart:
> > On Monday 16 Jan 2017 10:37:41 Maarten Lankhorst wrote:
> >> Signed-off-by: Maarten Lankhorst
> >> ---
> >>
> >> drivers/gpu/drm/drm_atomic_helper.c | 293 +++-
Hi Jani,
Could you please review this patch? All your previous review comments
are addressed. Is there anything else that is blocking this patch from getting
merged?
Regards
Manasi
On Tue, Jan 17, 2017 at 02:57:15PM -0800, Manasi Navare wrote:
> The intel_dp_autotest_video_pattern() function get
Hi Jani,
I have added all the video pattern definitions from CTS
spec following the definition conventions used around this file.
This addresses all the review comments from you, is there anything else
that is blocking this patch from getting merged? Could you please review this
patch?
Regards
M
Hi Jani,
This is another simple patch that only changed EDID test to
PREFERRED vs STANDARD as per the CTS spec. Is there anything else
that is blocking this patch getting merged?
Regards
Manasi
On Tue, Jan 17, 2017 at 02:57:13PM -0800, Manasi Navare wrote:
> This patch addresses a few issues fro
Hi Jani,
Could you please review this patch?
I have added the lane count checking and other review comments you had.
Is there anything else that is blocking from getting this patch merged?
Regards
Manasi
On Tue, Jan 17, 2017 at 02:57:12PM -0800, Manasi Navare wrote:
> This patch adds support to
== Series Details ==
Series: series starting with [1/6] drm/i915/huc: Add HuC fw loading support
URL : https://patchwork.freedesktop.org/series/18193/
State : success
== Summary ==
Series 18193v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/18193/revisions/1/mbo
We always try to do an unlocked wait before resorting to having a
blocking wait under the mutex - so we very rarely have to sleep under
the struct_mutex. However, when we do we want that wait to be as short
as possible as the struct_mutex is our BKL that will stall the driver and
all clients.
Ther
We always try to do an unlocked wait before resorting to having a
blocking wait under the mutex - so we very rarely have to sleep under
the struct_mutex. However, when we do we want that wait to be as short
as possible as the struct_mutex is our BKL that will stall the driver and
all clients.
Ther
On Wed, Jan 18, 2017 at 05:56:13PM +0200, Joonas Lahtinen wrote:
> On ke, 2017-01-18 at 12:18 +, Chris Wilson wrote:
> > We commonly use an inheritance style approach to device parameters,
> > where later generations inherit the defaults from earlier generations
> > and then override settings t
On 01/18/2017 01:52 AM, Chris Wilson wrote:
On Tue, Jan 17, 2017 at 04:37:28PM -0800, clinton.a.tay...@intel.com wrote:
From: Clint Taylor
The .disable_display parameter was causing a fatal crash when fbdev was
dereferenced during driver init.
The other guards are within intel_fbdev.c, it wo
This patch adds the support to load HuC on KBL
Version 2.0
v2: rebased on top of drm-tip. Rename KBL_FW_ to KBL_HUC_FW_
v3: rebased. Remove old checks.
Cc: Michal Wajdeczko
Cc: Tvrtko Ursulin
Signed-off-by: Anusha Srivatsa
Reviewed-by: Arkadiusz Hiler
Reviewed-by: Michal Wajdeczko
---
drive
Add debugfs entry for HuC loading status check.
v2: rebased on top of drm-tip.
Cc: Michal wajdeczko
Tested-by: Xiang Haihao
Signed-off-by: Anusha Srivatsa
Signed-off-by: Alex Dai
Signed-off-by: Peter Antoine
Reviewed-by: Jeff McGee
Reviewed-by: Michal Wajdeczko
---
drivers/gpu/drm/i915/i9
This patch will allow for getparams to return the status of the HuC.
As the HuC has to be validated by the GuC this patch uses the validated
status to show when the HuC is loaded and ready for use. You cannot use
the loaded status as with the GuC as the HuC is verified after it is
loaded and is not
The HuC authentication is done by host2guc call. The HuC RSA keys
are sent to GuC for authentication.
v2: rebased on top of drm-tip. Changed name format and upped
version 1.7.
v3: changed wait_for_atomic to wait_for
v4: rebased. Rename intel_huc_auh() to intel_guc_auth_huc()
and place the prototyp
This patch adds the HuC Loading for the BXT by using
the updated file construction.
Version 1.7 of the HuC firmware.
v2: rebased on to top drm-tip. Rename BXT_FW_MAJOR to BXT_HUC_FW_
Cc: Michal Wajdeczko
Cc: Tvrtko Ursulin
Signed-off-by: Anusha Srivatsa
Reviewed-by: Arkadiusz Hiler
Reviewed-
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 of drm-intel-nightly.
removed if(HAS_GUC()) before the guc call. (D.Gordon
On ke, 2017-01-18 at 12:18 +, Chris Wilson wrote:
> We commonly use an inheritance style approach to device parameters,
> where later generations inherit the defaults from earlier generations
> and then override settings that change. For example, in i915_pci.c
> BDW_FEATURES pulls in HSW_FEATUR
Hi Clint,
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on v4.10-rc4 next-20170118]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/clinton-a-taylor-intel-com/drm
On Mon, 02 Jan 2017, Madhav Chauhan wrote:
> From: Deepak M
>
> Dual link Z-inversion overlap field is present
> in MIPI_CTRL register unlike the older platforms,
> hence setting the same in this patch.
>
> Signed-off-by: Deepak M
> Signed-off-by: Madhav Chauhan
> ---
> drivers/gpu/drm/i915/in
On Mon, 02 Jan 2017, Madhav Chauhan wrote:
> From: Deepak M
>
> Program the clk lane and tlpx time count registers
> to configure DSI PHY.
>
> v2: Addressed Jani's Review comments(renamed bit field macros)
> v3: Program clk lane timing reg same as dphy param reg.
>
> Signed-off-by: Deepak M
> Si
Op 17-01-17 om 02:01 schreef Laurent Pinchart:
> Hi Maarten,
>
> (CC'ing Daniel)
>
> Thank you for the patch.
>
> On Monday 16 Jan 2017 10:37:41 Maarten Lankhorst wrote:
>> Signed-off-by: Maarten Lankhorst
>> ---
>> drivers/gpu/drm/drm_atomic_helper.c | 293 +---
>> 1
Chris Wilson writes:
> drivers/gpu/drm/i915/intel_csr.c: In function ‘csr_load_work_fn’:
> drivers/gpu/drm/i915/intel_csr.c:399:6: error: variable ‘ret’ set but not
> used [-Werror=unused-but-set-variable]
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i9
On Wed, 18 Jan 2017, Jani Nikula wrote:
> On Mon, 02 Jan 2017, Madhav Chauhan wrote:
>> From: Deepak M
>>
>> For GEMINILAKE, dphy param reg values are programmed in terms
>> of HS byte clock count while for legacy platforms in terms of
>> HS ddr clk count.
>
> No need to call everything before t
On Wed, Jan 18, 2017 at 12:49:00PM +, Chris Wilson wrote:
> On Wed, Jan 18, 2017 at 02:34:28PM +0200, Ander Conselvan de Oliveira wrote:
> > The error paths in hsw_trans_edp_pipe_A_crc_wa() and
> > intel_prepare_reset() would potentially call drm_atomic_state_put with a
> > NULL state, which wo
== Series Details ==
Series: drm/i915: Avoid drm_atomic_state_put(NULL) on error paths (rev2)
URL : https://patchwork.freedesktop.org/series/18176/
State : success
== Summary ==
Series 18176v2 drm/i915: Avoid drm_atomic_state_put(NULL) on error paths
https://patchwork.freedesktop.org/api/1.0/s
== Series Details ==
Series: drm/i915: Avoid drm_atomic_state_put(NULL) on error paths
URL : https://patchwork.freedesktop.org/series/18176/
State : success
== Summary ==
Series 18176v1 drm/i915: Avoid drm_atomic_state_put(NULL) on error paths
https://patchwork.freedesktop.org/api/1.0/series/1
On Wed, Jan 18, 2017 at 02:34:28PM +0200, Ander Conselvan de Oliveira wrote:
> The error paths in hsw_trans_edp_pipe_A_crc_wa() and
> intel_prepare_reset() would potentially call drm_atomic_state_put with a
> NULL state, which would lead to a NULL pointer dereference.
>
> Found by coverity.
>
> v
The error paths in hsw_trans_edp_pipe_A_crc_wa() and
intel_prepare_reset() would potentially call drm_atomic_state_put with a
NULL state, which would lead to a NULL pointer dereference.
Found by coverity.
v2: Improve the error paths. (Chris)
Fixes: 0853695c3ba4 ("drm: Add reference counting to d
On Wed, 18 Jan 2017, Jani Nikula wrote:
> On Wed, 18 Jan 2017, Sreedhar Donelli wrote:
>> compilation issue on kernel-4.10-rc4 is resolved and i created a patch file.
>> please find the attachment for patch file.
>
> There are several issues with this contribution. Please learn to use git
> send-
drivers/gpu/drm/i915/intel_csr.c: In function ‘csr_load_work_fn’:
drivers/gpu/drm/i915/intel_csr.c:399:6: error: variable ‘ret’ set but not used
[-Werror=unused-but-set-variable]
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_csr.c | 4 +---
1 file changed, 1 insertion(+), 3 deletio
We commonly use an inheritance style approach to device parameters,
where later generations inherit the defaults from earlier generations
and then override settings that change. For example, in i915_pci.c
BDW_FEATURES pulls in HSW_FEATURES, makes a few changes for 48bit
contexts and then individual
On Wed, Jan 18, 2017 at 01:52:15PM +0200, Ander Conselvan de Oliveira wrote:
> The error paths in hsw_trans_edp_pipe_A_crc_wa() and
> intel_prepare_reset() would potentially call drm_atomic_state_put with a
> NULL state, which would lead to a NULL pointer dereference.
>
> Found by coverity.
>
> F
On Tue, 10 Jan 2017 06:08:40 +0100,
Jerome Anand wrote:
>
> Hdmi audio driver based on the child platform device
> created by gfx driver is implemented.
> This audio driver is derived from legacy intel
> hdmi audio driver.
>
> The interfaces for interaction between gfx and audio
> are updated and
The error paths in hsw_trans_edp_pipe_A_crc_wa() and
intel_prepare_reset() would potentially call drm_atomic_state_put with a
NULL state, which would lead to a NULL pointer dereference.
Found by coverity.
Fixes: 0853695c3ba4 ("drm: Add reference counting to drm_atomic_state")
Cc: Chris Wilson
Cc
On Tue, 10 Jan 2017 06:08:39 +0100,
Jerome Anand wrote:
>
> On Baytrail and Cherrytrail, HDaudio may be fused out or disabled
> by the BIOS. This driver enables an alternate path to the i915
> display registers and DMA.
>
> Although there is no hardware path between i915 display and LPE/SST
> aud
On Wed, Jan 18, 2017 at 01:35:33PM +0200, Ander Conselvan De Oliveira wrote:
> On Sun, 2017-01-15 at 12:58 +, Chris Wilson wrote:
> > intel_display_resume() may be called without a atomic state to restore,
> > i.e. dev_priv->modeset_reset_restore state is NULL. One such case is
> > following a
On Sun, 2017-01-15 at 12:58 +, Chris Wilson wrote:
> intel_display_resume() may be called without a atomic state to restore,
> i.e. dev_priv->modeset_reset_restore state is NULL. One such case is
> following a lid open/close event and the forced modeset in
> intel_lid_notiy().
>
> Reported-by:
On Mon, 02 Jan 2017, Madhav Chauhan wrote:
> From: Deepak M
>
> For GEMINILAKE, dphy param reg values are programmed in terms
> of HS byte clock count while for legacy platforms in terms of
> HS ddr clk count.
No need to call everything before this one "legacy".
> Signed-off-by: Deepak M
> Sig
On Tue, Jan 17, 2017 at 07:05:04PM +, Vivi, Rodrigo wrote:
> same for the other...
> dm old gcc...
>
> Also my bad here since I asked Vathsala to organize like this...
>
> Anyways, for this patch
> Reviewed-by: Rodrigo Vivi
Ta, another couple of warnings squashed. We are not that far from
On Tue, Jan 17, 2017 at 04:54:05PM -, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [1/7] drm/i915: Move engine reset preparation to
> i915_gem_reset_prepare()
> URL : https://patchwork.freedesktop.org/series/18131/
> State : success
>
> == Summary ==
>
> Series
On Wed, Jan 18, 2017 at 10:21:47AM +, Chris Wilson wrote:
> On Wed, Jan 18, 2017 at 12:14:00PM +0200, Petri Latvala wrote:
> > Thanks for the reminder about this ordering change.
> >
> > The crash from disable_display use will cause $stuff in CI, its
> > ability to recover and resume is not qu
On Wed, Jan 18, 2017 at 12:14:00PM +0200, Petri Latvala wrote:
> Thanks for the reminder about this ordering change.
>
> The crash from disable_display use will cause $stuff in CI, its
> ability to recover and resume is not quite there yet. But as it's at
> the end, we can live with it until a fix
On Wed, 18 Jan 2017, Chris Wilson wrote:
> On Wed, Jan 18, 2017 at 12:07:17PM +0200, Jani Nikula wrote:
>> On Wed, 18 Jan 2017, Chris Wilson wrote:
>> > A quick test to exercise one module paramter that should disable a chunk
>> > of code usually run at startup and shutdown.
>>
>> Going for test
On Wed, Jan 18, 2017 at 09:52:35AM +, Chris Wilson wrote:
> On Tue, Jan 17, 2017 at 04:37:28PM -0800, clinton.a.tay...@intel.com wrote:
> > From: Clint Taylor
> >
> > The .disable_display parameter was causing a fatal crash when fbdev was
> > dereferenced during driver init.
>
> The other gu
On Mon, Jan 16, 2017 at 12:06:56PM +0200, Srinivas, Vidya wrote:
>
>
> > -Original Message-
> > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> > Sent: Friday, January 13, 2017 9:02 PM
> > To: Deak, Imre
> > Cc: Jani Nikula ; Kahola, Mika
> > ; Srinivas, Vidya ; intel-
> > g
On Wed, Jan 18, 2017 at 12:07:17PM +0200, Jani Nikula wrote:
> On Wed, 18 Jan 2017, Chris Wilson wrote:
> > A quick test to exercise one module paramter that should disable a chunk
> > of code usually run at startup and shutdown.
>
> Going for test driven development, are we? The BAT test list is
Thanks for the reminder about this ordering change.
The crash from disable_display use will cause $stuff in CI, its
ability to recover and resume is not quite there yet. But as it's at
the end, we can live with it until a fix lands.
Series is
Acked-by: Petri Latvala
On Wed, Jan 18, 2017 at 09:
On Wed, 18 Jan 2017, Chris Wilson wrote:
> A quick test to exercise one module paramter that should disable a chunk
> of code usually run at startup and shutdown.
Going for test driven development, are we? The BAT test list is not the
place to add tests that will break. We should get tests to be
On Sat, 14 Jan 2017, Anusha Srivatsa wrote:
> The HuC loading process is similar to GuC. The intel_uc_fw_fetch()
> is used for both cases.
Pushed patches 1-2, stopped here because this one doesn't apply to
drm-intel-next-queued. Thanks for the patches.
BR,
Jani.
>
> HuC loading needs to be befo
We want to run the initial set of tests under "pristine startup"
conditions - so that our tests see the hardware as close to the
condition we normally would after booting. This means that we want to
avoid reloading the module until the very last set of tests.
Signed-off-by: Chris Wilson
Cc: Petri
A quick test to exercise one module paramter that should disable a chunk
of code usually run at startup and shutdown.
Signed-off-by: Chris Wilson
Cc: Petri Latvala
---
tests/intel-ci/fast-feedback.testlist | 1 +
1 file changed, 1 insertion(+)
diff --git a/tests/intel-ci/fast-feedback.testlist
On Tue, Jan 17, 2017 at 04:37:28PM -0800, clinton.a.tay...@intel.com wrote:
> From: Clint Taylor
>
> The .disable_display parameter was causing a fatal crash when fbdev was
> dereferenced during driver init.
The other guards are within intel_fbdev.c, it would be consistent to put
this as the sta
On Mon, 16 Jan 2017, "Srinivas, Vidya" wrote:
>> -Original Message-
>> From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>> Sent: Friday, January 13, 2017 9:02 PM
>> To: Deak, Imre
>> Cc: Jani Nikula ; Kahola, Mika
>> ; Srinivas, Vidya ; intel-
>> g...@lists.freedesktop.org; Cons
On Mon, 09 Jan 2017, Vidya Srinivas wrote:
> From: Uma Shankar
>
> In case of DSI, DDI PLL is not required.
> Handle the same as part of DDI PLL handling.
Show me *one* code path where the functions you change may be called for
DSI.
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/g
HI All,
compilation issue on kernel-4.10-rc4 is resolved and i created a patch file.
please find the attachment for patch file.
I have taken this issue from below link
https://lkml.org/lkml/2017/1/16/89
Thanks & Regards
Sreedhar Donelli
Tata Consultancy Services
Ph:- +91 8019039399
Ce
On Wed, 18 Jan 2017, Sreedhar Donelli wrote:
> compilation issue on kernel-4.10-rc4 is resolved and i created a patch file.
> please find the attachment for patch file.
There are several issues with this contribution. Please learn to use git
send-email to send your patches. Don't attach them. You
On Tue, 17 Jan 2017, Rodrigo Vivi wrote:
> On Mon, Jan 16, 2017 at 2:04 AM, Jani Nikula
> wrote:
>> On Fri, 13 Jan 2017, Rodrigo Vivi wrote:
>>> This and all the remaining patches on this series (6,7,8 and 9) got
>>> merged to dinq.
>>
>> Given that this patch series was not properly sent as a t
70 matches
Mail list logo
