On 2018.04.02 16:37:55 +0800, Xiong Zhang wrote:
> vgpu ballon info consists of four drm_mm_node which is used to reserve
> ggtt space, then linux guest won't use these reserved ggtt space.
>
> Each vgpu has its own ballon info, so move ballon info into
> i915_virtual_gpu structure.
>
> Signed-of
On 04/02/2018 02:26 PM, Lyude Paul wrote:
While enabling/disabling DPMS before link training with MST hubs is
perfectly valid; unfortunately disabling DPMS results in some devices
disabling their AUX CH block as well. For SST this isn't as much of a
problem, but for MST we need to be able to cont
On 03/26/2018 03:04 AM, Michał Winiarski wrote:
On Fri, Mar 23, 2018 at 01:00:35PM -0700, Yaodong Li wrote:
On 03/23/2018 05:34 AM, Michał Winiarski wrote:
We need GuC to load HuC, but it's also possible for GuC to operate on
its own. We don't know what the size of HuC FW may be, so, not wantin
== Series Details ==
Series: GuC, HuC Loading Support for Cannonlake. (rev2)
URL : https://patchwork.freedesktop.org/series/41031/
State : failure
== Summary ==
Series 41031v2 GuC, HuC Loading Support for Cannonlake.
https://patchwork.freedesktop.org/api/1.0/series/41031/revisions/2/mbox/
---
On 03/26/2018 12:15 AM, Joonas Lahtinen wrote:
Quoting Yaodong Li (2018-03-23 19:33:15)
As I said, I agree that we would likely solve the enable_guc=1 then
enable_guc=3 case with these changes which I think this the the only benefit
that we can get from the starting from the top way.
But my poin
On Mon, Apr 02, 2018 at 03:38:26PM -0700, Pandiyan, Dhinakaran wrote:
> On Mon, 2018-04-02 at 13:51 -0700, José Roberto de Souza wrote:
> > IGT tests could be improved with sink status, knowing for sure that
> > hardware have activate or exit PSR.
> >
> > Reviewed-by: Dhinakaran Pandiyan
>
>
>
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/i915_params.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_params.h
b/drivers/gpu/drm/i915/i915_params.h
index c963603..1d23c41 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/g
GuC is now available for Cannonlake.
Load GuC v11.102 on Cannonlake.
Cc: Tomi Sarvela
Cc: Jani Saarinen
Cc: Rodrigo vivi
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/intel_guc_fw.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_guc_fw.c
Huc is available now for cannonlake.
Load v9.01.2719 on Cannonlake.
Cc: Tomi Sarvela
Cc: Jani Saarinen
Cc: Rodrigo Vivi
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/intel_huc_fw.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_huc_fw.c
Load the latest version of GuC and HuC.
Pull Request:
The following changes since commit a3be6d433f843d71edaa0f9a291297589d571ce4:
Merge https://github.com/Netronome/linux-firmware into netro (2018-03-30
10:10:27 -0400)
are available in the git repository at:
git://anongit.freedesktop.org/
On Mon, 2018-04-02 at 18:47 -0400, Lyude Paul wrote:
> There's no reason to track the atomic state three times. Unfortunately,
> this is currently what we're doing, and even worse is that there is only
> one actually correct state pointer: the one in mst_state->base.state.
> mgr->state never seems
On Mon, 2018-04-02 at 22:16 +, Souza, Jose wrote:
> On Mon, 2018-04-02 at 11:42 -0700, Pandiyan, Dhinakaran wrote:
> >
> >
> > On Mon, 2018-04-02 at 11:23 -0700, Rodrigo Vivi wrote:
> > > On Fri, Mar 30, 2018 at 03:23:32PM -0700, José Roberto de Souza
> > > wrote:
> > > > When PSR/PSR2 is ena
For a while we actually haven't had any way of retraining MST links with
fallback link parameters like we do with SST. While uncommon, certain
setups such as my Caldigit TS3 + EVGA MST hub require this since
otherwise, they end up getting stuck in an infinite MST retraining loop.
MST retraining is
The current way of handling changing VCPI allocations doesn't make a
whole ton of sense. Since drm_atomic_helper_check_modeset() can be
called multiple times which means that intel_dp_mst_atomic_check() can
also be called multiple times. However, since we make the silly mistake
of trying to free VC
Unlike SST, MST can have far more then a single display hooked up on a
single port. What this also means however, is that if the DisplayPort
link to the top-level MST branch device becomes unstable then every
single branch device also has an unstable link. Additionally, MST has a
few more steps tha
This gives drivers subclassing drm_dp_mst_topology_state the ability to
prepare their topology states for a new hub to be connected whenever
it's detected that the currently connected topology has been
disconnected from the system. We'll need this in order to correctly
track RX capabilities in i915
When a DP MST link needs retraining, sometimes the hub will detect that
the current link bw config is impossible and will update it's RX caps in
the DPCD to reflect the new maximum link rate. Currently, we make the
assumption that the RX caps in the dpcd will never change like this.
This means if t
Does what it says on the label, it's a little confusing debugging atomic
check failures otherwise.
Cc: Manasi Navare
Cc: Ville Syrjälä
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_atomic.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_atomic.c
While having the modeset_retry_work in intel_connector makes sense with
SST, this paradigm doesn't make a whole ton of sense when it comes to
MST since we have to deal with multiple connectors. In most cases, it's
more useful to just use the intel_dp struct since it indicates whether
or not we're d
This is useful for drivers (which will probably be all of them soon)
which need to track state that is exclusive to the topology, and not a
specific connector on said topology. This includes things such as the
link rate and lane count that are shared by all of the connectors on the
topology.
Signe
Since these functions are dealing with an atomic state that needs to be
modified during atomic check and commit, change the naming on this
function to drm_atomic_dp_mst_get_topology_state() since we're the only
one using the function, and it's more consistent with the naming
scheme used in drm_atom
Latest version of https://patchwork.freedesktop.org/series/39642/ ,
hopefully patchwork understands this and doesn't break anything!
Lots of changes.
Lyude Paul (10):
drm/atomic: Print debug message on atomic check failure
drm/i915: Move DP modeset retry work into intel_dp
drm/dp_mst: Fix n
There's no reason to track the atomic state three times. Unfortunately,
this is currently what we're doing, and even worse is that there is only
one actually correct state pointer: the one in mst_state->base.state.
mgr->state never seems to be used, along with the one in
mst_state->state.
This con
On Mon, 2018-04-02 at 13:51 -0700, José Roberto de Souza wrote:
> IGT tests could be improved with sink status, knowing for sure that
> hardware have activate or exit PSR.
>
> Reviewed-by: Dhinakaran Pandiyan
Please don't merge this patch yet. While the patch itself is correct,
testing it bring
On Mon, 2018-04-02 at 17:21 -0400, Lyude Paul wrote:
> While enabling/disabling DPMS before link training with MST hubs is
> perfectly valid; unfortunately disabling DPMS results in some devices
> disabling their AUX CH block as well. For SST this isn't as much of a
> problem, but for MST we nee
On Mon, 2018-04-02 at 11:42 -0700, Pandiyan, Dhinakaran wrote:
>
>
> On Mon, 2018-04-02 at 11:23 -0700, Rodrigo Vivi wrote:
> > On Fri, Mar 30, 2018 at 03:23:32PM -0700, José Roberto de Souza
> > wrote:
> > > When PSR/PSR2 is enabled hardware can do aux ch transactions by
> > > it
> > > self.
> >
On Mon, 2018-04-02 at 12:00 -0700, Pandiyan, Dhinakaran wrote:
>
>
> On Mon, 2018-04-02 at 11:23 -0700, Rodrigo Vivi wrote:
> > On Fri, Mar 30, 2018 at 03:23:32PM -0700, José Roberto de Souza
> > wrote:
> > > When PSR/PSR2 is enabled hardware can do aux ch transactions by
> > > it
> > > self.
> >
On Mon, 2018-04-02 at 11:20 -0700, Rodrigo Vivi wrote:
> On Fri, Mar 30, 2018 at 03:23:31PM -0700, José Roberto de Souza
> wrote:
> > intel_psr_activate_block_get() should be called when by some reason
> > PSR should not be activated for some time, it will increment
> > counter
> > and it should th
== Series Details ==
Series: series starting with [v2,1/2] drm/i915/debugfs: Print sink PSR status
URL : https://patchwork.freedesktop.org/series/41022/
State : warning
== Summary ==
Possible new issues:
Test kms_chv_cursor_fail:
Subgroup pipe-b-64x64-top-edge:
pa
While enabling/disabling DPMS before link training with MST hubs is
perfectly valid; unfortunately disabling DPMS results in some devices
disabling their AUX CH block as well. For SST this isn't as much of a
problem, but for MST we need to be able to continue handling aux
transactions even when non
While enabling/disabling DPMS before link training with MST hubs is
perfectly valid; unfortunately disabling DPMS results in some devices
disabling their AUX CH block as well. For SST this isn't as much of a
problem, but for MST we need to be able to continue handling aux
transactions even when non
== Series Details ==
Series: series starting with [v2,1/2] drm/i915/debugfs: Print sink PSR status
URL : https://patchwork.freedesktop.org/series/41022/
State : success
== Summary ==
Series 41022v1 series starting with [v2,1/2] drm/i915/debugfs: Print sink PSR
status
https://patchwork.freedes
On Mon, 2018-04-02 at 11:11 -0700, Rodrigo Vivi wrote:
> On Fri, Mar 30, 2018 at 03:23:28PM -0700, José Roberto de Souza
> wrote:
> > The disable and exit sequence are very similar with a lot common
> > code between both, so here sharing the code.
>
> I don't believe that we should do this.
> Disa
IGT tests could be improved with sink status, knowing for sure that
hardware have activate or exit PSR.
Reviewed-by: Dhinakaran Pandiyan
Cc: Rodrigo Vivi
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/i915_debugfs.c | 29 +
1 file changed, 29 insertio
This was my bad, spec says that the name of this bit is
'Y-coordinate valid' but the values for it is:
0: Include Y-coordinate valid eDP1.4a
1: Do not include Y-coordinate valid eDP 1.4
So not setting it.
Cc: Rodrigo Vivi
Reviewed-by: Dhinakaran Pandiyan
Signed-off-by: José Roberto de Souza
---
On Mon, 2018-04-02 at 11:23 -0700, Rodrigo Vivi wrote:
> On Fri, Mar 30, 2018 at 03:23:32PM -0700, José Roberto de Souza wrote:
> > When PSR/PSR2 is enabled hardware can do aux ch transactions by it
> > self.
> > Spec requires that PSR is inactive before do any aux ch transaction
> > in HSW and
On Mon, 2018-04-02 at 11:23 -0700, Rodrigo Vivi wrote:
> On Fri, Mar 30, 2018 at 03:23:32PM -0700, José Roberto de Souza wrote:
> > When PSR/PSR2 is enabled hardware can do aux ch transactions by it
> > self.
> > Spec requires that PSR is inactive before do any aux ch transaction
> > in HSW and
On Mon, Apr 02, 2018 at 10:42:23AM -0700, Pandiyan, Dhinakaran wrote:
>
>
>
> On Sat, 2018-03-31 at 00:17 +, Souza, Jose wrote:
> > On Fri, 2018-03-30 at 16:46 -0700, Pandiyan, Dhinakaran wrote:
> > > On Fri, 2018-03-30 at 14:15 -0700, José Roberto de Souza wrote:
> > > > This was my bad, sp
On Fri, Mar 30, 2018 at 03:23:34PM -0700, José Roberto de Souza wrote:
> eDP spec states that sink device will do a short pulse in HPD
> line when there is a PSR/PSR2 error that needs to be handled by
> source, this is handling the first and most simples error:
> DP_PSR_SINK_INTERNAL_ERROR.
>
> Si
On Fri, Mar 30, 2018 at 03:23:33PM -0700, José Roberto de Souza wrote:
> 'drm/i915/dp: Exit PSR before do a aux channel transaction' cause all
> IGT PSR and frontbuffer tracking tests to not be userful.
> Those tests depend in reading the calculated CRC value of the
> frontbuffer in sink and doing
On Fri, Mar 30, 2018 at 03:23:32PM -0700, José Roberto de Souza wrote:
> When PSR/PSR2 is enabled hardware can do aux ch transactions by it
> self.
> Spec requires that PSR is inactive before do any aux ch transaction
> in HSW and BDW, for skl+ there is a aux ch mutex but the use is not
> recommend
On Fri, Mar 30, 2018 at 03:23:31PM -0700, José Roberto de Souza wrote:
> intel_psr_activate_block_get() should be called when by some reason
> PSR should not be activated for some time, it will increment counter
> and it should the decremented by intel_psr_activate_block_put()
> when PSR can be act
On Fri, Mar 30, 2018 at 03:23:30PM -0700, José Roberto de Souza wrote:
> Export this functions so other modules can activate and exit PSR.
"module" is not a right word here.
But I also don't like the approach. In the past we had the use spread
on our driver and it was confusing and hard to deal w
On Fri, Mar 30, 2018 at 03:23:29PM -0700, José Roberto de Souza wrote:
> It is not necessary as is possible to get the pipe information
> from intel_dp.
>
> Signed-off-by: José Roberto de Souza
> Cc: Dhinakaran Pandiyan
> Cc: Rodrigo Vivi
Cc: Lucas
> ---
> drivers/gpu/drm/i915/i915_drv.h |
On Fri, Mar 30, 2018 at 03:23:28PM -0700, José Roberto de Souza wrote:
> The disable and exit sequence are very similar with a lot common
> code between both, so here sharing the code.
I don't believe that we should do this.
Disable as is has some extra wait/timeouts that could slow things down.
On Fri, Mar 30, 2018 at 03:23:27PM -0700, José Roberto de Souza wrote:
> To proper execute PSR exit it was using 'if (HAS_DDI(dev_priv))' to
> differentiate between VLV/CHV and HSW+ hardware, so here moving each
> hardware handling to his own function.
>
> Signed-off-by: José Roberto de Souza
> C
On Fri, Mar 30, 2018 at 03:23:26PM -0700, José Roberto de Souza wrote:
> It was reading some random register in VLV and CHV.
>
> Signed-off-by: José Roberto de Souza
> Cc: Dhinakaran Pandiyan
> Cc: Rodrigo Vivi
I'm sure that my patch [1] will conflict with this series.
[1] https://patchwork.f
On Sat, 2018-03-31 at 00:17 +, Souza, Jose wrote:
> On Fri, 2018-03-30 at 16:46 -0700, Pandiyan, Dhinakaran wrote:
> > On Fri, 2018-03-30 at 14:15 -0700, José Roberto de Souza wrote:
> > > This was my bad, spec says that the name of this bit is
> > > 'Y-coordinate valid' but the values for i
Chris Wilson writes:
> We would like to start doing some bookkeeping at the beginning, between
> contexts and at the end of execlists submission. We already mark the
> beginning and end using EXECLISTS_ACTIVE_USER, to provide an indication
> when the HW is idle. This give us a pair of sequence po
On 31/03/18 03:42, Chris Wilson wrote:
Let's avoid having to delve down the pointer chain to see if the i915
device has support for preemption and store that on the engine, which
made the decision in the first place!
Signed-off-by: Chris Wilson
Cc: Tomasz Lis
Cc: Daniele Ceraolo Spurio
Cc:
On Fri, 30 Mar 2018 16:01:31 +0100
Chris Wilson wrote:
> Across suspend, we may see a very large drift in timestamps if the sched
> clock is unstable, prompting the global trace's ringbuffer code to warn
> and suggest switching to the global clock. Preempt this request by
> detecting when the sch
On Mon, Apr 02, 2018 at 05:20:22PM +0530, Ramalingam C wrote:
> As per DP spec when R0 mismatch is detected, HDCP source supported
> re-read the R0 atleast twice.
>
> And For HDMI and DP minimum wait required for the R0 availability is
> 100mSec. So this patch changes the wait time to 100mSec but
On Mon, Apr 02, 2018 at 03:40:32PM +0530, Ramalingam C wrote:
> In case of V prime mismatch, DP HDCP spec mandates the re-read of
> Vprime atleast twice.
>
> This patch needed for DP HDCP1.4 CTS Test: 1B-05.
>
> v2:
> Moved the V' validation into a function for retry. [Sean Paul]
> v3:
> Remo
== Series Details ==
Series: HDCP1.4 fixes (rev5)
URL : https://patchwork.freedesktop.org/series/38978/
State : failure
== Summary ==
Possible new issues:
Test drv_module_reload:
Subgroup basic-no-display:
pass -> INCOMPLETE (shard-snb)
Test kms_cursor_crc:
== Series Details ==
Series: HDCP1.4 fixes (rev5)
URL : https://patchwork.freedesktop.org/series/38978/
State : success
== Summary ==
Series 38978v5 HDCP1.4 fixes
https://patchwork.freedesktop.org/api/1.0/series/38978/revisions/5/mbox/
Known issues:
Test kms_pipe_crc_basic:
Subg
As per DP spec when R0 mismatch is detected, HDCP source supported
re-read the R0 atleast twice.
And For HDMI and DP minimum wait required for the R0 availability is
100mSec. So this patch changes the wait time to 100mSec but retries
twice with the time interval of 100mSec for each attempt.
This
== Series Details ==
Series: HDCP1.4 fixes (rev4)
URL : https://patchwork.freedesktop.org/series/38978/
State : success
== Summary ==
Possible new issues:
Test kms_cursor_crc:
Subgroup cursor-64x64-suspend:
dmesg-warn -> PASS (shard-snb)
Known issues:
== Series Details ==
Series: Add NV12 support (rev7)
URL : https://patchwork.freedesktop.org/series/39670/
State : failure
== Summary ==
Possible new issues:
Test kms_cursor_crc:
Subgroup cursor-64x64-suspend:
dmesg-warn -> PASS (shard-snb)
Test kms_plane_sc
== Series Details ==
Series: HDCP1.4 fixes (rev4)
URL : https://patchwork.freedesktop.org/series/38978/
State : success
== Summary ==
Series 38978v4 HDCP1.4 fixes
https://patchwork.freedesktop.org/api/1.0/series/38978/revisions/4/mbox/
fi-bdw-5557u total:285 pass:264 dwarn:0 dfail:0
As per DP spec when R0 mismatch is detected, HDCP source supported
re-read the R0 atleast twice.
And For HDMI and DP minimum wait required for the R0 availability is
100mSec. So this patch changes the wait time to 100mSec but retries
twice with the time interval of 100mSec for each attempt.
This
First two patches needed for below DP HDCP compliance tests
1A-06 and 1B-05
Third patch fixes the HDCP1.4 Key loadability check. where as fourth
one fixes the downstream device count read.
Fix for HDMI HDCP1.4 CTS tests: 1A-04 and 1A-07a are functional.
But the change from v2, as thinking
HDCP1.4 key can be loaded, only when Power well #1 is enabled and cdclk
is enabled. Using the I915 power well infrastruture, above requirement
is verified.
This patch enables the hdcp initialization for HSW, BDW, and BXT.
v2:
Choose the PW# based on the platform.
v3:
No Changes.
Signed-off-b
In both HDMI and DP, device count is represented by 6:0 bits of a
register(BInfo/Bstatus)
So macro for bitmasking the device_count is fixed(0x3F->0x7F).
v3:
Retained the Rb-ed
Signed-off-by: Ramalingam C
cc: Sean Paul
Reviewed-by: Sean Paul
---
include/drm/drm_hdcp.h | 2 +-
1 file changed
In case of V prime mismatch, DP HDCP spec mandates the re-read of
Vprime atleast twice.
This patch needed for DP HDCP1.4 CTS Test: 1B-05.
v2:
Moved the V' validation into a function for retry. [Sean Paul]
v3:
Removed Inline keyword and DRM_DEBUG_KMS are used [Sean Paul]
Signed-off-by: Ramali
== Series Details ==
Series: Add NV12 support (rev7)
URL : https://patchwork.freedesktop.org/series/39670/
State : success
== Summary ==
Series 39670v7 Add NV12 support
https://patchwork.freedesktop.org/api/1.0/series/39670/revisions/7/mbox/
fi-bdw-5557u total:285 pass:264 dwarn:0 dfa
== Series Details ==
Series: Add NV12 support (rev7)
URL : https://patchwork.freedesktop.org/series/39670/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
b485c8e3c47f drm/i915/skl+: rename skl_wm_values struct to skl_ddb_values
aba1b53bed73 drm/i915/skl+: refactor WM calculation
> -Original Message-
> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> Sent: Thursday, March 29, 2018 2:19 PM
> To: Srinivas, Vidya ; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v18 18/18] drm/i915: Keep plane size mult of
> 4 for NV12
>
> O
From: Chandra Konduru
This patch updates scaler max limit support for NV12
v2: Rebased (me)
v3: Rebased (me)
v4: Missed the Tested-by/Reviewed-by in the previous series
Adding the same to commit message in this version.
v5: Addressed review comments from Ville and rebased
- calculation of max
From: Mahesh Kumar
This patch splits skl_compute_wm/ddb functions into two parts.
One adds all affected pipes after the commit to atomic_state structure
and second part does compute the DDB.
v2: Added reviewed by tag from Shashank Sharma
v3: Added reviewed by from Juha-Pekka Heikkila
v4: Rebas
Display WA 827 applies to GEN9 (excluede GLK) and CNL.
Switching the plane format from NV12 to RGB and leaving system idle
results in display underrun and corruption.
WA: Set the bit 15 & bit 19 to 1b in the CLKGATE_DIS_PSL
register for the pipe in which NV12 plane is enabled.
v2: Addressed review
From: Chandra Konduru
This patch sets appropriate scaler mode for NV12 format.
In this mode, skylake scaler does either chroma-upsampling or
chroma-upsampling and resolution scaling
v2: Review comments from Ville addressed
NV12 case to be checked first for setting
the scaler
v3: Rebased (me)
v
From: Chandra Konduru
This patch adds NV12 to list of supported formats for sprite plane.
v2: Rebased (me)
v3: Review comments by Ville addressed
- Removed skl_plane_formats_with_nv12 and added
NV12 case in existing skl_plane_formats
- Added the 10bpc RGB formats
v4: Addressed review comments
From: Chandra Konduru
This patch adds NV12 as supported format
to intel_framebuffer_init and performs various checks.
v2:
-Fix an issue in checks added (Chandra Konduru)
v3: rebased (me)
v4: Review comments by Ville addressed
Added platform check for NV12 in intel_framebuffer_init
Removed offs
From: Mahesh Kumar
NV12 requires WM calculation for UV plane as well.
UV plane WM should also fulfill all the WM related restrictions.
v2: Addressed review comments from Shashank Sharma.
v3: Addressed review comments from Shashank Sharma
Changed plane_num to plane_id in skl_compute_plane_wm_par
This patch series is adding NV12 support for Broxton display after rebasing on
latest drm-tip.
Initial series of the patches can be found here:
https://lists.freedesktop.org/archives/intel-gfx/2015-May/066786.html
Previous revision history:
The first version of patches were reviewed when floated b
From: Mahesh Kumar
skl_wm_values struct contains values of pipe/plane DDB only.
so rename it for better readability of code. Similarly
skl_copy_wm_for_pipe copies DDB values.
s/skl_wm_values/skl_ddb_values
s/skl_copy_wm_for_pipe/skl_copy_ddb_for_pipe
Changes since V1:
- also change name of skl
From: Chandra Konduru
This patch adds NV12 to list of supported formats for
primary plane
v2: Rebased (Chandra Konduru)
v3: Rebased (me)
v4: Review comments by Ville addressed
Removed the skl_primary_formats_with_nv12 and
added NV12 case in existing skl_primary_formats
v5: Rebased (me)
v6: M
If the fb format is YUV, enable the plane CSC mode bits
for the conversion.
v2: Addressed review comments from Shashank Sharma
Alignment issue fixed in i915_reg.h
v3: Adding Reviewed By from Shashank Sharma
v4: Rebased the patch. As part of rebasing, re-using
the color series defines which are a
From: Mahesh Kumar
For YUV 420 Planar formats like NV12,
buffer allocation is done for Y and UV surfaces separately.
For NV12 plane formats, the UV buffer
allocation must be programmed in the Plane Buffer Config register
and the Y buffer allocation must be programmed in the
Plane NV12 Buffer Conf
From: Mahesh Kumar
Add support of recognizing DRM_FORMAT_NV12 from plane_format
register value.
v2: Added reviewed by tag from Mika Kahola
v3: Added reviewed by from Juha-Pekka Heikkila
v4: Rebased the series
Reviewed-by: Juha-Pekka Heikkila
Reviewed-by: Mika Kahola
Signed-off-by: Mahesh Ku
As per display WA 1106, to avoid corruption issues
NV12 plane height needs to be multiplier of 4
We expect the src dimensions to be multiplier of 4
We fail the case where src width or height is not
multiple of 4 for NV12.
We also set the scaler destination height
and width to be multiple of 4. With
From: Mahesh Kumar
This patch passes skl_wm_level structure itself to watermark
computation function skl_compute_plane_wm function (instead
of its internal parameters). It reduces number of arguments
required to be passed.
v2: Addressed review comments by Shashank Sharma
v3: Adding reviewed by
From: Mahesh Kumar
Current code calculates DDB for planar formats in such a way that we
store DDB of plane-0 in plane 1 & vice-versa.
In order to make this clean this patch refactors WM/DDB calculation for
NV12 planar formats.
v2: Addressed review comments by Maarten
v3: Rebased and addressed r
From: Chandra Konduru
This patch adds NV12 to format_is_yuv() function
for sprite planes.
v2:
-Use intel_ prefix for format_is_yuv (Ville)
v3: Rebased (me)
v4: Rebased and addressed review comments from Clinton A Taylor.
"static function in intel_sprite.c is not available
to the primary plane
From: Mahesh Kumar
DDB allocation optimization algorithm requires/assumes ddb allocation for
any memory C-state level DDB value to be as high as level below the
current level. Render decompression requires level WM to be as high as
wm level-0. This patch fulfils both the requirements.
v2: Change
From: Mahesh Kumar
Display Workaround #0826 (SKL:ALL BXT:ALL) & #1059(CNL:A)
Hardware sometimes fails to wake memory from pkg C states fetching the
last few lines of planar YUV 420 (NV12) planes. This causes
intermittent underflow and corruption.
WA: Disable package C states or do not enable late
On Thursday 29 March 2018 08:08 PM, Sean Paul wrote:
On Thu, Mar 29, 2018 at 07:39:06PM +0530, Ramalingam C wrote:
In case of V prime mismatch, DP HDCP spec mandates the re-read of
Vprime atleast twice.
This patch needed for DP HDCP1.4 CTS Test: 1B-05.
v2:
Moved the V' validation into a f
> -Original Message-
> From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> Sent: Thursday, March 29, 2018 5:03 PM
> To: Maarten Lankhorst
> Cc: Srinivas, Vidya ; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v18 18/18] drm/i915: Keep plane size mult of
>
On Thursday 29 March 2018 08:05 PM, Sean Paul wrote:
On Thu, Mar 29, 2018 at 07:39:05PM +0530, Ramalingam C wrote:
As per DP spec when R0 mismatch is detected, HDCP source supported
re-read the R0 atleast twice.
And For HDMI and DP minimum wait required for the R0 availability is
100mSec. So
== Series Details ==
Series: drm/i915: Don't deballoon unused ggtt drm_mm_node in linux guest (rev3)
URL : https://patchwork.freedesktop.org/series/40851/
State : failure
== Summary ==
Series 40851v3 drm/i915: Don't deballoon unused ggtt drm_mm_node in linux guest
https://patchwork.freedesktop
On Thursday 29 March 2018 07:54 PM, Ville Syrjälä wrote:
On Thu, Mar 29, 2018 at 07:39:07PM +0530, Ramalingam C wrote:
HDCP1.4 key can be loaded, only when Power well #1 is enabled and cdclk
is enabled. Using the I915 power well infrastruture, above requirement
is verified.
This patch enables
== Series Details ==
Series: drm/i915: Don't deballoon unused ggtt drm_mm_node in linux guest (rev3)
URL : https://patchwork.freedesktop.org/series/40851/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
b0bcc0a1ee76 drm/i915: Move vgpu balloon info into i915_virtual_gpu struct
-:
vgpu ballon info consists of four drm_mm_node which is used to reserve
ggtt space, then linux guest won't use these reserved ggtt space.
Each vgpu has its own ballon info, so move ballon info into
i915_virtual_gpu structure.
Signed-off-by: Xiong Zhang
---
drivers/gpu/drm/i915/i915_drv.h | 14 +
The following call trace may exist in linux guest dmesg when guest i915
driver is unloaded.
[ 90.776610] [drm:vgt_deballoon_space.isra.0 [i915]] deballoon space: range
[0x0 - 0x0] 0 KiB.
[ 90.776621] BUG: unable to handle kernel NULL pointer dereference at
00c0
[ 90.776691] IP:
94 matches
Mail list logo