From: Nick Hoath
Swap the order of context & engine cleanup, so that contexts are cleaned
up first, and *then* engines. This is a more sensible order anyway, but
in particular has become necessary since the 'intel_ring_initialized()
must be simple and inline' patch, which now uses ring->dev as an
On 21/01/16 19:37, Dave Gordon wrote:
Also includes Nick Hoath's patch to swap context/engine teardown.
In-Reply-To:
Hmm, editor/mailer seems to have dropped most of this summary :(
Probably something to do with that IRT-line above ... what it was
supposed to say was approximately this:
Su
Instead of waiting for 50ms, just wait until the next vblank, since
it's the minimum requirement. The whole infrastructure of FBC is based
on vblanks, so waiting for X vblanks instead of X milliseconds sounds
like the correct way to go. Besides, 50ms may be less than a vblank on
super slow modes th
We say "dev_priv->fbc.something" way too many times in our code while
we could be saying just "fbc->something" with a previous declaration
of fbc. This has been bothering me for a while but I didn't want to
patch it since I wanted to fix the real problems first. But as I add
more code I keep thinki
On Wed, 2016-01-20 at 14:11 +, Zanoni, Paulo R wrote:
> Em Sex, 2015-12-11 às 08:39 -0800, Rodrigo Vivi escreveu:
> > Current platforms that support PSR on other port than A only
> > support
> > link
> > standby mode.
> >
> > The logic here was wrong since 'commit 89251b177b ("drm/i915: PSR:
We unconditionally disable/update FBC even during the page flip
IOCTLs, and an unconditional disable/update at every atomic commit
touching the primary plane shouldn't impact PC state residency
noticeably. Besides, the code that checks for rotation is a good hint
that we may be forgetting something
Em Ter, 2016-01-19 às 14:50 +, Patchwork escreveu:
> == Summary ==
>
> Built on 20c388faff9d8c41ab27e825c685526561b892a2 drm-intel-nightly:
> 2016y-01m-19d-13h-31m-46s UTC integration manifest
>
> Test kms_flip:
> Subgroup basic-flip-vs-modeset:
> pass -> DMESG-W
On Thu, Jan 21, 2016 at 06:11:01PM +, Peter Antoine wrote:
> This patch resizes the GuC WOPCM to so that the GuC and the RC6 memory
> spaces do not overlap.
>
> Issue: https://jira01.devtools.intel.com/browse/VIZ-6638
> Signed-off-by: Peter Antoine
> ---
> drivers/gpu/drm/i915/i915_guc_reg.h
Required for WaEnablePreemptionGranularityControlByUMD:skl,bxt
This register is added to HW whitelist to support WA required for future
enabling of pre-emptive command execution, WA implementation will be in
userspace and it cannot program this register if it is not on HW whitelist.
v2: explain p
Per context preemption granularity control is only available from SKL:E0+
Actual WA is to disable percontext preemption granularity control until D0
which is the default case so this is equivalent to the inverse of
WaDisablePerCtxtPreemptionGranularityControl:skl
v2: add some detail to commit msg
Required for,
WaDisableObjectLevelPreemptionForTrifanOrPolygon:bxt
WaDisableObjectLevelPreemptionForInstancedDraw:bxt
WaDisableObjectLevelPreemtionForInstanceId:bxt
According to WA database these are only applicable for BXT:A0 but since
A0 and A1 shares the same GT these are extended for A1 as wel
Required for WaAllowUMDToModifyHDCChicken1:skl,bxt
This register is added to HW whitelist to support WA required for future
enabling of pre-emptive command execution, WA implementation will be in
userspace and it cannot program this register if it is not on HW whitelist.
v2: explain purpose of ch
This is mainly required for future enabling of pre-emptive
command execution.
v2: explain purpose of change (Chris)
Reviewed-by: Nick Hoath
Cc: Dave Gordon
Signed-off-by: Arun Siluvery
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/
Some of the HW registers are privileged and cannot be written to from
non-privileged batch buffers coming from userspace unless they are added to
the HW whitelist. This whitelist is maintained by HW and it is different from
SW whitelist. Userspace need write access to them to implement preemption
r
Some comments from Chris to improve commit message, no functional changes.
All of them are reviewed and so have r-b tags.
previous version,
http://www.spinics.net/lists/intel-gfx/msg85969.html
Arun Siluvery (8):
drm/i915/gen9: Add framework to whitelist specific GPU registers
drm/i915/gen9: A
Required for WaDisableLSQCROPERFforOCL:bxt
According to WA database these are only applicable for BXT:A0 but since
A0 and A1 shares the same GT these are extended for A1 as well.
This register is added to HW whitelist to support WA required for future
enabling of pre-emptive command execution, WA
Required for WaDisableLSQCROPERFforOCL:skl
This register is added to HW whitelist to support WA required for future
enabling of pre-emptive command execution, WA implementation will be in
userspace and it cannot program this register if it is not on HW whitelist.
v2: explain purpose of changes (C
On Mon, Jan 18, 2016 at 08:45:39PM +0530, Vandita Kulkarni wrote:
> From: Damien Lespiau
>
> This patch adds support for blending modes involving
> color.
>
> Signed-off-by: Damien Lespiau
> ---
> drivers/gpu/drm/i915/intel_display.c | 28
> drivers/gpu/drm/i915/in
From: Lukas Wunner
Rafael Antognolli's new DRM_DP_AUX_CHARDEV feature causes a WARN_ON
if drm_dp_aux->dev == drm_connector->kdev and drm_dp_aux_unregister()
is called after drm_connector_unregister(). radeon is the only driver
affected by this besides i915. (amdgpu calls drm_dp_aux_unregister()
b
The module_init and module_exit functions will start here, and call the
subsequent init's and exit's.
v10:
- Keep __init on drm_fb_helper init function.
- Move MODULE_* macros to the common file.
Signed-off-by: Rafael Antognolli
---
drivers/gpu/drm/Makefile| 4 ++-
drivers/gp
This series implement support to a drm_dp_aux chardev that allows reading and
writing an arbitrary amount of bytes to arbitrary dpcd register addresses using
regular read, write and lseek operations.
Lukas Wunner (1):
drm/radeon: Fix WARN_ON if DRM_DP_AUX_CHARDEV is enabled
Rafael Antognolli (3
So far, the i915 driver and some other drivers set it to the drm_device,
which doesn't allow one to know which DP a given aux channel is related
to. Changing this to be the drm_connector provides proper nesting, still
allowing one to get the drm_device from it. Some drivers already set it
to the dr
This module is heavily based on i2c-dev. Once loaded, it provides one
dev node per DP AUX channel, named drm_dp_auxN, where N is an integer.
It's possible to know which connector owns this aux channel by looking
at the respective sysfs /sys/class/drm_aux_dev/drm_dp_auxN/connector, if
the connector
Hi Lukas,
Sorry for the late answer, I went on vacation and then was busy with
something else. Anyway, I tried to address all comments (yours and
Daniel's) on a new version. See some comments below.
On Sun, Dec 06, 2015 at 05:08:49PM +0100, Lukas Wunner wrote:
> Hi Rafael,
>
> On Thu, Dec 03, 20
On Thu, Jan 21, 2016 at 01:50:34PM +, Patchwork wrote:
> == Summary ==
>
> Built on 8fe9e785ae04fa7c37f7935cff12d62e38054b60 drm-intel-nightly:
> 2016y-01m-21d-11h-02m-42s UTC integration manifest
>
> Test drv_getparams_basic:
> Subgroup basic-eu-total:
> pass -
On Wed, Jan 13, 2016 at 11:08 AM, Dave Gordon wrote:
> On 12/01/16 23:49, Chris Wilson wrote:
>>
>> On Tue, Jan 12, 2016 at 11:40:06PM +, Chris Wilson wrote:
>>>
>>> struct drm_i915_gem_object_ops {
>>> + const unsigned int flags;
>>
>>
>> Bleh, const is redundant as the definitions sh
On Mon, Jan 18, 2016 at 08:45:34PM +0530, Vandita Kulkarni wrote:
> From: vandita kulkarni
>
> The below patches support plane and pixel blending
> by adding two properties blend_func and blend_color.
> As per Damien's initial patches, this design based on
> OpenGL's blend equations is suggested
Thanks Matt for pointing me to this.
Vlad,
As Matt mentioned, we are also working on this to get atomic support in i-g-t.
Last week we finalized the design with Matt. I am putting the design we
discussed here for reference,
- New commit style will be added as "COMMIT_NUCLEAR"
- If the commit st
On 01/21/2016 05:47 PM, Kumar, Abhay wrote:
On 1/20/2016 5:06 AM, Ville Syrjälä wrote:
On Wed, Jan 20, 2016 at 03:29:00PM +0530, Kumar, Shobhit wrote:
On 01/20/2016 02:30 PM, Daniel Vetter wrote:
On Tue, Jan 19, 2016 at 02:37:55PM -0800, Kumar, Abhay wrote:
On 1/12/2016 5:57 PM, Kumar, Abh
== Summary ==
Built on 8fe9e785ae04fa7c37f7935cff12d62e38054b60 drm-intel-nightly:
2016y-01m-21d-11h-02m-42s UTC integration manifest
bdw-nuci7total:140 pass:131 dwarn:0 dfail:0 fail:0 skip:9
bdw-ultratotal:143 pass:137 dwarn:0 dfail:0 fail:0 skip:6
bsw-nuc-2
== Summary ==
Built on 8fe9e785ae04fa7c37f7935cff12d62e38054b60 drm-intel-nightly:
2016y-01m-21d-11h-02m-42s UTC integration manifest
Test kms_pipe_crc_basic:
Subgroup read-crc-pipe-a-frame-sequence:
pass -> DMESG-WARN (ilk-hp8440p)
bdw-nuci7total:140 pass
Every new KMS driver writer seems to run into this and wonder how
exactly drm_fb_helper_initial_config can die doing nothing at all.
Set up some big warnings signs around this newbie trap to avoid future
frustration and wasting everyone's time.
Cc: Carlos Palminha
Cc: Xinliang Liu
Cc: laurent.pi
101 - 132 of 132 matches
Mail list logo
