On 2016-12-13 06:08 PM, Daniel Vetter wrote:
Mostly nothing special (except making sure that really all error paths
and friends call iter_put).
v2: Don't forget the raw connector_list walking in
drm_helper_move_panel_connectors_to_head. That one unfortunately can't
be converted to the iterator h
On Fri, Dec 09, 2016 at 11:42:09PM +0530, vathsala nagaraju wrote:
> For PSR2 , as per spec, PSR2_CTL bit 31 to be set.
> for psr1, bit 31 in SRD_CTL to be set. Reporting
> "HW Enabled & Active bit" status for psr2 from SRD_CTL
> gives wrong status.
>
> Cc: Rodrigo Vivi
> Cc: Jim Bride
> Signed
On Wed, Dec 14, 2016 at 09:02:44PM +0530, vathsala nagaraju wrote:
> when psr2 is enabled, psr idle condition is taken
> from psr1 register(SRD_STATUS) instead of psr2_status
> register, resulting in looping and blank screen.
> code changed to lookup from psr2_status and
> psr2_ctl instead of srd_s
Op 15-12-16 om 16:47 schreef Ville Syrjälä:
> On Thu, Dec 15, 2016 at 04:34:58PM +0100, Maarten Lankhorst wrote:
>> Op 12-12-16 om 21:35 schreef ville.syrj...@linux.intel.com:
>>> From: Ville Syrjälä
>>>
>>> On VLV/CHV enabling sprite0 when sprite1 has already been enabled may
>>> lead to an under
Op 15-12-16 om 16:55 schreef Daniel Vetter:
> On Thu, Dec 15, 2016 at 12:51:42PM +0100, Maarten Lankhorst wrote:
>> Stop relying on a per crtc_state last_vblank_count, we shouldn't touch
>> crtc_state after commit. Move it to atomic_state->crtcs.
>>
>> Also stop re-using new_crtc_state->enable, we
On Thu, Dec 15, 2016 at 04:45:49PM +0100, Maarten Lankhorst wrote:
> Op 15-12-16 om 16:38 schreef Ville Syrjälä:
> > On Thu, Dec 15, 2016 at 04:30:54PM +0100, Maarten Lankhorst wrote:
> >> Op 12-12-16 om 21:35 schreef ville.syrj...@linux.intel.com:
> >>> From: Ville Syrjälä
> >>>
> >>> Start compu
On Thu, Dec 15, 2016 at 05:13:37PM +0100, Maarten Lankhorst wrote:
> Op 15-12-16 om 16:47 schreef Ville Syrjälä:
> > On Thu, Dec 15, 2016 at 04:34:58PM +0100, Maarten Lankhorst wrote:
> >> Op 12-12-16 om 21:35 schreef ville.syrj...@linux.intel.com:
> >>> From: Ville Syrjälä
> >>>
> >>> On VLV/CHV
On Thu, Dec 15, 2016 at 04:47:04PM +0100, Arkadiusz Hiler wrote:
> GuC historically has two "startup" functions called _init() and _setup()
>
> Then HuC came with it's _init() and _load().
>
> To make naming more consistent this commit renames intel_guc_setup() to
> intel_guc_load() as it it seam
== Series Details ==
Series: drm: Resurrect atomic rmfb code.
URL : https://patchwork.freedesktop.org/series/16849/
State : warning
== Summary ==
Series 16849v1 drm: Resurrect atomic rmfb code.
https://patchwork.freedesktop.org/api/1.0/series/16849/revisions/1/mbox/
Test core_auth:
Su
Op 15-12-16 om 17:23 schreef Patchwork:
> == Series Details ==
>
> Series: drm: Resurrect atomic rmfb code.
> URL : https://patchwork.freedesktop.org/series/16849/
> State : warning
>
> == Summary ==
>
> Series 16849v1 drm: Resurrect atomic rmfb code.
> https://patchwork.freedesktop.org/api/1.0/s
On Thu, Dec 15, 2016 at 04:47:06PM +0100, Arkadiusz Hiler wrote:
> Current version of intel_guc_load() does a lot:
> - cares about submission
> - loads huc
> - implement WA
>
> This change offloads some of the logic to intel_uc_load(), which now
> cares about the above.
>
> Cc: Anusha Srivatsa
On Thu, Dec 15, 2016 at 04:41:51PM +0100, Maarten Lankhorst wrote:
> Op 15-12-16 om 16:36 schreef Ville Syrjälä:
> > On Thu, Dec 15, 2016 at 04:28:52PM +0100, Maarten Lankhorst wrote:
> >> Op 15-12-16 om 16:23 schreef Ville Syrjälä:
> >>> On Thu, Dec 15, 2016 at 04:17:45PM +0100, Maarten Lankhorst
== Series Details ==
Series: drm/i915: use udelay for very short delays
URL : https://patchwork.freedesktop.org/series/16851/
State : success
== Summary ==
Series 16851v1 drm/i915: use udelay for very short delays
https://patchwork.freedesktop.org/api/1.0/series/16851/revisions/1/mbox/
Test k
Reviewed-by: Harry Wentland:
On 2016-12-15 10:58 AM, Daniel Vetter wrote:
Mostly nothing special (except making sure that really all error paths
and friends call iter_put).
v2: Don't forget the raw connector_list walking in
drm_helper_move_panel_connectors_to_head. That one unfortunately can't
On 13/12/2016 14:47, Chris Wilson wrote:
On Tue, Dec 13, 2016 at 02:37:27PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Cast VM pointers before substraction to save the compiler
doing a smart one which includes multiplication.
v2: Only keep the first optimisation and prettify it. (Chri
Em Qui, 2016-12-01 às 21:19 +0530, Mahesh Kumar escreveu:
> This patch implemnets Workariunds related to display arbitrated
> memory
> bandwidth. These WA are applicabe for all gen-9 based platforms.
3 typos above.
The WA is already implemented. What the patch does is that it opts-out
of the WA i
On Thu, Dec 15, 2016 at 04:49:49PM +, Tvrtko Ursulin wrote:
>
> On 13/12/2016 14:47, Chris Wilson wrote:
> >On Tue, Dec 13, 2016 at 02:37:27PM +, Tvrtko Ursulin wrote:
> >>From: Tvrtko Ursulin
> >>
> >>Cast VM pointers before substraction to save the compiler
> >>doing a smart one which i
Op 12-12-16 om 21:35 schreef ville.syrj...@linux.intel.com:
> From: Ville Syrjälä
>
> We now compute the watermarks correctly, so just return an error if we
> can't support the configuration.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_pm.c | 4
> 1 file changed, 4 d
Op 15-12-16 om 16:02 schreef Ville Syrjälä:
> On Thu, Dec 15, 2016 at 03:56:03PM +0100, Maarten Lankhorst wrote:
>> Op 12-12-16 om 21:35 schreef ville.syrj...@linux.intel.com:
>>> From: Ville Syrjälä
>>>
>>> In a lot of place we wish to know which planes on the crtc are actually
>>> visible, or ho
Op 15-12-16 om 17:09 schreef Ville Syrjälä:
> On Thu, Dec 15, 2016 at 04:45:49PM +0100, Maarten Lankhorst wrote:
>> Op 15-12-16 om 16:38 schreef Ville Syrjälä:
>>> On Thu, Dec 15, 2016 at 04:30:54PM +0100, Maarten Lankhorst wrote:
Op 12-12-16 om 21:35 schreef ville.syrj...@linux.intel.com:
>>>
== Series Details ==
Series: drm/i915: use udelay for very small delays
URL : https://patchwork.freedesktop.org/series/16852/
State : success
== Summary ==
Series 16852v1 drm/i915: use udelay for very small delays
https://patchwork.freedesktop.org/api/1.0/series/16852/revisions/1/mbox/
Test k
On Thu, Dec 15, 2016 at 06:12:12PM +0100, Maarten Lankhorst wrote:
> Op 15-12-16 om 17:09 schreef Ville Syrjälä:
> > On Thu, Dec 15, 2016 at 04:45:49PM +0100, Maarten Lankhorst wrote:
> >> Op 15-12-16 om 16:38 schreef Ville Syrjälä:
> >>> On Thu, Dec 15, 2016 at 04:30:54PM +0100, Maarten Lankhorst
On 2016-12-13 06:08 PM, Daniel Vetter wrote:
Only static connectors should be left at this point, and we should be
able to clean them out by simply dropping that last reference still
around from drm_connector_init.
If that leaves anything behind then we have a driver bug.
Doing the final cleanu
On Thu, Dec 15, 2016 at 06:11:24PM +0100, Maarten Lankhorst wrote:
> Op 15-12-16 om 16:02 schreef Ville Syrjälä:
> > On Thu, Dec 15, 2016 at 03:56:03PM +0100, Maarten Lankhorst wrote:
> >> Op 12-12-16 om 21:35 schreef ville.syrj...@linux.intel.com:
> >>> From: Ville Syrjälä
> >>>
> >>> In a lot of
On Thu, Dec 15, 2016 at 06:42:08PM +0200, Ville Syrjälä wrote:
> On Thu, Dec 15, 2016 at 04:41:51PM +0100, Maarten Lankhorst wrote:
> > Op 15-12-16 om 16:36 schreef Ville Syrjälä:
> > > On Thu, Dec 15, 2016 at 04:28:52PM +0100, Maarten Lankhorst wrote:
> > >> Op 15-12-16 om 16:23 schreef Ville Syrj
From: Ville Syrjälä
The scanline counter is bonkers on VLV/CHV DSI. The scanline counter
increment is not lined up with the start of vblank like it is on
every other platform and output type. This causes problems for
both the vblank timestamping and atomic update vblank evasion.
On my FFRD8 mach
== Series Details ==
Series: GuC Scrub vol. 1
URL : https://patchwork.freedesktop.org/series/16856/
State : failure
== Summary ==
Series 16856v1 GuC Scrub vol. 1
https://patchwork.freedesktop.org/api/1.0/series/16856/revisions/1/mbox/
Test drv_module_reload:
Subgroup basic-reload-inje
Remove the enable_guc_loading parameter. GuC loads are now
controlled through enable_huc and enable_guc_submission
parameter. If either or both of these parameters are set.
GuC is loaded.
If we need to debug GuC we can do so by removing the firmware from
the rootfs instead of disabling with a para
From: Anusha Srivatsa
Add a new kernel parameter: enable_huc. This parameter
controls HuC functionality. If this parameter
is set to 1, it suggests that HuC functionality is being
used and also that the GuC has to be loaded. GuC has to be
loaded in order to authenticate the HuC.
Cc: Jani Nikula
On Thu, Dec 15, 2016 at 10:24:56AM -0800, anushasr wrote:
> From: Anusha Srivatsa
>
> Add a new kernel parameter: enable_huc. This parameter
> controls HuC functionality. If this parameter
> is set to 1, it suggests that HuC functionality is being
> used and also that the GuC has to be loaded. Gu
Em Ter, 2016-11-22 às 18:02 +0200, ville.syrj...@linux.intel.com
escreveu:
> From: Ville Syrjälä
>
> Rename the SKL plane register define 'plane' parameter to 'plane_id'
> to
> reflect the fact that you're supposed to pass in the enum plane_id
> rather than enum plane.
>
> Do the same for the sc
>-Original Message-
>From: Wajdeczko, Michal
>Sent: Thursday, December 15, 2016 10:32 AM
>To: Srivatsa, Anusha
>Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani
>Subject: Re: [Intel-gfx] [PATCH 1/2] drm/i915/huc: Introduce enable_huc
>parameter
>
>On Thu, Dec 15, 2016 at 10:24:56AM -08
>>> +static void lpe_audio_irq_unmask(struct irq_data *d) {
>>> + struct drm_i915_private *dev_priv = d->chip_data;
>>> + unsigned long irqflags;
>>> + u32 val = (I915_LPE_PIPE_A_INTERRUPT |
>>> + I915_LPE_PIPE_B_INTERRUPT);
>>
>> PIPE_C missing?
>>
>
> No PIPE_C on vlv
Good catch Da
Em Ter, 2016-11-22 às 18:02 +0200, ville.syrj...@linux.intel.com
escreveu:
> From: Ville Syrjälä
>
> With plane->plane now purely reserved for the primary planes, let's
> not even populate it for cursors and sprites. Let's switch the type
> to enum plane as well since it's no longer being abused
On Thu, Dec 15, 2016 at 05:05:05PM -0200, Paulo Zanoni wrote:
> Em Ter, 2016-11-22 às 18:02 +0200, ville.syrj...@linux.intel.com
> escreveu:
> > From: Ville Syrjälä
> >
> > With plane->plane now purely reserved for the primary planes, let's
> > not even populate it for cursors and sprites. Let's
== Series Details ==
Series: drm/i915: Workaround VLV/CHV DSI scanline counter hardware fail
URL : https://patchwork.freedesktop.org/series/16863/
State : success
== Summary ==
Series 16863v1 drm/i915: Workaround VLV/CHV DSI scanline counter hardware fail
https://patchwork.freedesktop.org/api/
On 12/14/16 7:13 AM, Takashi Iwai wrote:
On Wed, 14 Dec 2016 13:55:52 +0100,
Daniel Vetter wrote:
Only noticed it here, but why again do we need to re-roll our intel-only
hdmi/eld notification? The one we have for hda is somewhat justified since
it went in at roughly the same time as the new sh
Em Qui, 2016-12-15 às 21:11 +0200, Ville Syrjälä escreveu:
> On Thu, Dec 15, 2016 at 05:05:05PM -0200, Paulo Zanoni wrote:
> >
> > Em Ter, 2016-11-22 às 18:02 +0200, ville.syrj...@linux.intel.com
> > escreveu:
> > >
> > > From: Ville Syrjälä
> > >
> > > With plane->plane now purely reserved for
We usually use 'client' as identifier for the i915_guc_client.
For unknown reason, few functions were using 'gc' name.
Signed-off-by: Michal Wajdeczko
---
drivers/gpu/drm/i915/i915_guc_submission.c | 64 +++---
1 file changed, 32 insertions(+), 32 deletions(-)
diff --git
On Thu, Dec 15, 2016 at 05:50:02PM -0200, Paulo Zanoni wrote:
> Em Qui, 2016-12-15 às 21:11 +0200, Ville Syrjälä escreveu:
> > On Thu, Dec 15, 2016 at 05:05:05PM -0200, Paulo Zanoni wrote:
> > >
> > > Em Ter, 2016-11-22 às 18:02 +0200, ville.syrj...@linux.intel.com
> > > escreveu:
> > > >
> > > >
== Series Details ==
Series: drm/i915: Fix inconsistent naming of i915_guc_client parameter
URL : https://patchwork.freedesktop.org/series/16869/
State : success
== Summary ==
Series 16869v1 drm/i915: Fix inconsistent naming of i915_guc_client parameter
https://patchwork.freedesktop.org/api/1.
Subject: Re: [PATCH 3/7] ALSA: add shell for Intel HDMI LPE audio driver
Why do we need a "shell" and indirect calls?
This is a small driver set, so it's not utterly unacceptable, but it still makes
things a bit more complicated than necessary, so I'd like to understand the
idea behind it.
This change itself is OK, but this made me wonder about the driver
implementation: the current MAX_PB=1 is the hardware limitation or the
soft limitation? That is, can't we play back two streams when we connect
two HDMI monitors?
Two streams was never validated from hardware per se. So setti
Hello Tvrtko Ursulin,
The patch a19d6ff29a82: "drm/i915: Small compaction of the engine
init code" from Jun 23, 2016, leads to the following static checker
warning:
drivers/gpu/drm/i915/intel_lrc.c:1973 logical_render_ring_init()
warn: passing freed memory 'engine'
drivers/gpu/dr
On Thu, Dec 15, 2016 at 11:44:13PM +0300, Dan Carpenter wrote:
> Hello Tvrtko Ursulin,
>
> The patch a19d6ff29a82: "drm/i915: Small compaction of the engine
> init code" from Jun 23, 2016, leads to the following static checker
> warning:
>
> drivers/gpu/drm/i915/intel_lrc.c:1973 logical_ren
On Thu, 15 Dec 2016 21:37:03 +0100,
Pierre-Louis Bossart wrote:
>
>
> >>> Subject: Re: [PATCH 3/7] ALSA: add shell for Intel HDMI LPE audio driver
>
> >>> Why do we need a "shell" and indirect calls?
> >>> This is a small driver set, so it's not utterly unacceptable, but it
> >>> still makes
>
On 15/12/16 07:47, Arkadiusz Hiler wrote:
Current version of intel_guc_load() does a lot:
- cares about submission
- loads huc
- implement WA
This change offloads some of the logic to intel_uc_load(), which now
cares about the above.
Cc: Anusha Srivatsa
Cc: Jeff McGee
Cc: Michal Winiarsk
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_guc_fw is renamed to intel_uc_fw. Prefix of tts members,
such as 'guc' or 'guc_fw'
From: Peter Antoine
HuC firmware css header has almost exactly same definition as GuC
firmware except for the sw_version. Also, add a new member fw_type
into intel_uc_fw to indicate what kind of fw it is. So, the loader
will pull right sw_version from header.
v2: rebased on-top of drm-intel-nigh
From: Anusha Srivatsa
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
From: Anusha Srivatsa
This patch adds the support to load HuC on KBL
Version 2.0
v2: rebased.
v3: rebased on top of drm-tip
v4: rebased.
v5: rebased. Rename KBL_FW_ to KBL_HUC_FW_
Cc: Jeff Mcgee
Signed-off-by: Anusha Srivatsa
Reviewed-by: Jeff McGee
---
drivers/gpu/drm/i915/intel_huc_loader
These patches add HuC loading support. The driver builds a frame level
workload which is stored in the graphics memory. This workload is presented
to HuC for processing. The driver, therefore should first determine if the
HuC is enabled and also read the huC athentication status bit to determine
if
From: Anusha Srivatsa
This patch adds the HuC Loading for the BXT by using
the updated file construction.
Version 1.7 of the HuC firmware.
v2: rebased.
v3: rebased on top of drm-tip
v4: rebased.
v5: rebased. Rename BXT_FW_MAJOR to BXT_HUC_FW_
Cc: Jeff Mcgee
Signed-off-by: Anusha Srivatsa
Rev
From: Peter Antoine
The HuC authentication is done by host2guc call. The HuC RSA keys
are sent to GuC for authentication.
v2: rebased on top of drm-intel-nightly.
changed name format and upped version 1.7.
v3: rebased on top of drm-intel-nightly.
v4: changed wait_for_automic to wait_for
v5:
From: Peter Antoine
Add debugfs entry for HuC loading status check.
v2: rebase on-top of drm-intel-nightly.
v3: rebased again.
v7: rebased.
v8: rebased.
v9: rebased.
v10: rebased.
v11: rebased on top of drm-tip
v12: rebased.
Tested-by: Xiang Haihao
Signed-off-by: Anusha Srivatsa
Signed-off-by
From: Peter Antoine
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 i
Hi All,
I was wondering if we intend to keep -1 and 2 for the enable_guc_submission
parameter. Since now we are gating guc loads if either guc_submission or
enable_huc parameter is set, why have a -1(platform default) and 2(forcefully
load) option? We anyway do not have any special default set
On Thu, Dec 15, 2016 at 02:29:50PM -0800, anushasr wrote:
> From: Peter Antoine
>
> 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
Hi Daniel,
[auto build test ERROR on drm/drm-next]
[also build test ERROR on next-20161215]
[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]
url:
https://github.com/0day-ci/linux/commits/Daniel-Vetter/drm-Convert-all
Hi Daniel,
[auto build test ERROR on drm/drm-next]
[also build test ERROR on next-20161215]
[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]
url:
https://github.com/0day-ci/linux/commits/Daniel-Vetter/drm-Convert-all
== Series Details ==
Series: HuC Loading Patches
URL : https://patchwork.freedesktop.org/series/16878/
State : success
== Summary ==
Series 16878v1 HuC Loading Patches
https://patchwork.freedesktop.org/api/1.0/series/16878/revisions/1/mbox/
fi-bdw-5557u total:247 pass:233 dwarn:0 dfa
> On Thu, 15 Dec 2016, Ville Syrjälä wrote:
> > On Mon, Dec 12, 2016 at 02:57:44PM +0800, Wang Elaine wrote:
> >> From: Elaine Wang
> >>
> >> Some platforms don't have display. To avoid accessing the
> >> non-existent registers, check HAS_PCH_NOP before invoking display IRQ
> >> install or reset
inst 4.9.0 (localversion-next is next-20161215)
drivers/gpu/drm/i915/intel_dsi_pll.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c
b/drivers/gpu/drm/i915/intel_dsi_pll.c
index 56eff60..d210bc4 100644
--- a/drivers/gpu/drm/i915/intel
inst 4.9.0 (localversion-next is next-20161215)
drivers/gpu/drm/i915/intel_dsi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 5b72c50..92b96fa 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gp
== Series Details ==
Series: drm/i915: relax uncritical udelay_range()
URL : https://patchwork.freedesktop.org/series/16897/
State : success
== Summary ==
Series 16897v1 drm/i915: relax uncritical udelay_range()
https://patchwork.freedesktop.org/api/1.0/series/16897/revisions/1/mbox/
fi-bdw-
== Series Details ==
Series: drm/i915: relax uncritical udelay_range() settings
URL : https://patchwork.freedesktop.org/series/16900/
State : failure
== Summary ==
Series 16900v1 drm/i915: relax uncritical udelay_range() settings
https://patchwork.freedesktop.org/api/1.0/series/16900/revisions
On 2016.12.15 22:36:40 +, Srivatsa, Anusha wrote:
> Hi All,
>
>
>
> I was wondering if we intend to keep -1 and 2 for the enable_guc_submission
> parameter. Since now we are gating guc loads if either guc_submission or
> enable_huc parameter is set, why have a -1(platform default) and 2(for
From: Elaine Wang
when num_pipes is zero, it indicates there is no display and HDMI
audio doesn't exist.
Cc: Chris Wilson
Cc: Joonas Lahtinen
Signed-off-by: Elaine Wang
---
drivers/gpu/drm/i915/i915_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i
From: Elaine Wang
when num_pipes is zero, it indicates display doesn't exist, so there
is no need to initialize display hooks. And to avoid calling these
uninitialized display hooks, respect num_pipes at the beginning of
intel_modeset_init_hw and intel_init_clock_gating.
intel_init_pm() calls FB
== Series Details ==
Series: series starting with [1/2] drm/i915: Check num_pipes before
initializing audio component
URL : https://patchwork.freedesktop.org/series/16902/
State : warning
== Summary ==
Series 16902v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series
]
> [also build test ERROR on next-20161215]
> [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]
>
> url:
> https://github.com/0day-ci/linux/commits/Daniel-Vetter/drm-Convert-all-helpers-t
> == Series Details ==
>
> Series: drm/i915: relax uncritical udelay_range() settings
> URL : https://patchwork.freedesktop.org/series/16900/
> State : failure
>
> == Summary ==
>
> Series 16900v1 drm/i915: relax uncritical udelay_range() settings
> https://patchwork.freedesktop.org/api/1.0/se
requent enough in
LKML to worth the efforts to add auto detect logic for.
Thanks,
Fengguang
On Thu, Dec 15, 2016 at 11:59 PM, kbuild test robot wrote:
Hi Daniel,
[auto build test ERROR on drm/drm-next]
[also build test ERROR on next-20161215]
[cannot apply to v4.9]
[if your patch is applied to t
The goal of this series is to fix top-down allocations to be allocated
from the top and aligned correctly, introduce bottom-up allocations, and
speed up searches and tighten evictions.
More polish on the test cases to reduce code duplication and to improve
expectation checking. And a little more p
Prime numbers are interesting for testing components that use multiplies
and divides, such as testing struct drm_mm alignment computations.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/Kconfig | 4 +
drivers/gpu/drm/Makefile| 1 +
drivers/gpu/drm/lib/drm_pr
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 run as an ensemble via kselftest or individually via
an igt harness (in
A complement to drm_mm_for_each_node(), wraps list_for_each_entry_safe()
for walking the list of nodes safe against removal.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/drm_mm.c | 9 -
include/drm/drm_mm.h | 19 ---
2 files changed,
If we remember that node_list is a circular list containing the fake
head_node, we can use a simple list_next_entry() and skip the NULL check
for the allocated check against the head_node.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 6 ++---
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 new hole.
v2: Pull together the 3 identical implements (ahem, a coup
Simple first test to just exercise initialisation of struct drm_mm.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_mm.c | 114 +++
2 files changed, 115 insertions(+)
diff --git a/drivers/gpu/d
Doing the check is trivial (low cost in comparison to overall eviction)
and helps simplify the code.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/drm_mm.c | 53 +++
drivers/gpu/drm/i915/i915_gem_evict.c | 10 ++-
i
Exercise drm_mm_insert_node(), check that we can't overfill a range and
that the lists are correct after reserving/removing.
v2: Extract helpers for the repeated tests
v3: Iterate over all allocation flags
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
dri
Acknowledging that we were building up the hole was more useful to me
when reading the code, than knowing the relationship between this node
and the previous node.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_mm.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
dif
Use CONFIG_DRM_DEBUG_MM to conditionally enable the internal and
validation checking using BUG_ON. Ideally these paths should all be
exercised by CI selftests (with the asserts enabled).
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/drm_mm.c | 45 +
The range restriction should be applied after the color adjustment, or
else we may inadvertently apply the color adjustment to the restricted
hole (and not against its neighbours).
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/drm_mm.c | 15 +--
1 file
The nodes must be removed in the *reverse* order. This is correct in the
overview, but backwards in the function description. Whilst here add
Intel's copyright statement and tweak some formatting.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_mm.c | 34 ++
i
Check that we add arbitrary blocks to the eviction scanner in order to
find the first minimal hole that matches our request.
v2: Refactor out some common eviction code for later
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
d
Protect ourselves from a caller passing in node.start + node.size that
will overflow and trick us into reserving that node.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_mm.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm
Since commit ea7b1dd44867 ("drm: mm: track free areas implicitly"),
to test whether there are any nodes allocated within the range manager,
we merely have to ask whether the node_list is empty.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/drm_mm.c | 19 +-
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, for example like resource
tracking.
Signed-off-by: Chris Wilson
---
Check that if we request top-down allocation from drm_mm_insert_node()
we receive the next available hole from the top.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_mm.c | 123 +
Check that after applying the driver's color adjustment, fitting of the
node and its alignment are still correct.
v2: s/no_color_touching/separate_adjacent_colors/
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm
On Fri, Dec 16, 2016 at 07:29:59AM +, Saarinen, Jani wrote:
> > == Series Details ==
> >
> > Series: drm/i915: relax uncritical udelay_range() settings
> > URL : https://patchwork.freedesktop.org/series/16900/
> > State : failure
> >
> > == Summary ==
> >
> > Series 16900v1 drm/i915: relax
Mark up the pointers as constant through the API where appropriate.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_mm.c| 24
drivers/gpu/drm/i915/i915_gem_gtt.c | 2 +-
include/drm/drm_mm.h| 27 +--
3 files change
Check that we add arbitrary blocks to a restrited eviction scanner in
order to find the first minimal hole that matches our request.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_mm.c |
Since we mandate a strict reverse-order of drm_mm_scan_remove_block()
after drm_mm_scan_add_block() we can further simplify the list
manipulations when generating the temporary scan-hole.
v2: Highlight the games being played with the lists to track the scan
holes without allocation.
Signed-off-by
In places (e.g. i915.ko), the alignment is exported to userspace as u64
and there now exists hardware for which we can indeed utilize a u64
alignment. As such, we need to keep 64bit integers throughout when
handling alignment.
Testcase: igt/drm_mm/align64
Testcase: igt/gem_exec_alignment
Signed-of
Check that after applying the driver's color adjustment, restricted
eviction scanning find a suitable hole.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_mm.c | 119 ++-
2 files changed, 116 i
Exercise drm_mm_reserve_node(), check that we can't reserve an already
occupied range and that the lists are correct after reserving/removing.
v2: Check for invalid node reservation.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1
Compute the minimal required hole during scan and only evict those nodes
that overlap. This enables us to reduce the number of nodes we need to
evict to the bare minimum.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/drm_mm.c| 60 ++
101 - 200 of 215 matches
Mail list logo
