-ci/linux/commits/Matt-Roper/drm-Add-color-management-LUT-validation-helpers/20181212-130519
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-randconfig-x011-201849 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config
tree: git://anongit.freedesktop.org/drm-intel for-linux-next-fixes
head: eeb139ca4b24d515265ad75f668333431896b1aa
commit: eeb139ca4b24d515265ad75f668333431896b1aa [5/5] drm/i915: Flush GPU
relocs harder for gen3
config: i386-randconfig-x073-201849 (attached as .config)
compiler: gcc-7 (Debian
On 12/7/2018 7:59 PM, Daniel Vetter wrote:
On Fri, Dec 07, 2018 at 11:22:44AM +0530, C, Ramalingam wrote:
On 12/6/2018 3:53 PM, Daniel Vetter wrote:
On Tue, Nov 27, 2018 at 04:13:03PM +0530, Ramalingam C wrote:
Defining the mei-i915 interface functions and initialization of
the interface.
Si
://github.com/0day-ci/linux/commits/Matt-Roper/drm-Add-color-management-LUT-validation-helpers/20181212-130519
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-randconfig-x006-201849 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached
On 12/6/2018 4:15 PM, Daniel Vetter wrote:
On Tue, Nov 27, 2018 at 04:13:06PM +0530, Ramalingam C wrote:
Implements the HDCP2.2 repeaters authentication steps such as verifying
the downstream topology and sending stream management information.
v2:
Rebased.
v3:
No Changes.
v4:
-EINVAL i
Hi Matt,
On Tue, Dec 11, 2018 at 05:05:50PM -0800, Matt Roper wrote:
> Some hardware may place additional restrictions on the gamma/degamma
> curves described by our LUT properties. E.g., that a gamma curve never
> decreases or that the red/green/blue channels of a LUT's entries must be
> equal.
On Mon, Dec 10, 2018 at 05:30:09PM +0100, Peter Zijlstra wrote:
> On Mon, Dec 10, 2018 at 05:20:10PM +0100, Michal Hocko wrote:
> > > OK, no real objections to the thing. Just so long we're all on the same
> > > page as to what it does and doesn't do ;-)
> >
> > I am not really sure whether there
On Mon, Dec 10, 2018 at 06:47:00PM -0800, Dhinakaran Pandiyan wrote:
> On Fri, 2018-09-28 at 21:04 +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Consult the I2C_M_STOP flag to determine whether to set the MOT bit
> > or
> > not. Makes it possible to send multiple messages in one go
On Wed, Dec 12, 2018 at 02:28:29PM +0530, C, Ramalingam wrote:
> On 12/7/2018 7:59 PM, Daniel Vetter wrote:
> > On Fri, Dec 07, 2018 at 11:22:44AM +0530, C, Ramalingam wrote:
> > > On 12/6/2018 3:53 PM, Daniel Vetter wrote:
> > > > On Tue, Nov 27, 2018 at 04:13:03PM +0530, Ramalingam C wrote:
> > >
On Fri, Dec 07, 2018 at 11:54:15PM +0800, Chunming Zhou wrote:
> From: Christian König
>
> Use the dma_fence_chain object to create a timeline of fence objects
> instead of just replacing the existing fence.
>
> v2: rebase and cleanup
>
> Signed-off-by: Christian König
Somewhat jumping back i
On Mon, Dec 10, 2018 at 02:40:25PM +0100, Benjamin Gaignard wrote:
> Le lun. 10 déc. 2018 à 12:10, Benjamin Gaignard
> a écrit :
> >
> > Le lun. 10 déc. 2018 à 11:24, Thierry Reding
> > a écrit :
> > >
> > > On Mon, Dec 10, 2018 at 11:11:33AM +0100, Daniel Vetter wrote:
> > > > Having the probe h
On Mon, Dec 10, 2018 at 06:20:41PM +0200, Ville Syrjälä wrote:
> On Mon, Dec 10, 2018 at 11:03:53AM +0100, Daniel Vetter wrote:
> > The correct way for legacy drivers to update properties that need to
> > do a full modeset, is to do a full modeset.
> >
> > Note that we don't need to call the drm_m
On Mon, Dec 10, 2018 at 12:12:05PM +0200, Oleksandr Andrushchenko wrote:
> On 12/10/18 12:03 PM, Daniel Vetter wrote:
> > Doesn't do anything for atomic.
> >
> > Signed-off-by: Daniel Vetter
> > Cc: Oleksandr Andrushchenko
> > Cc: xen-de...@lists.xen.org
> > ---
> > drivers/gpu/drm/xen/xen_drm
On 12/12/2018 4:08 PM, Daniel Vetter wrote:
On Wed, Dec 12, 2018 at 02:28:29PM +0530, C, Ramalingam wrote:
On 12/7/2018 7:59 PM, Daniel Vetter wrote:
On Fri, Dec 07, 2018 at 11:22:44AM +0530, C, Ramalingam wrote:
On 12/6/2018 3:53 PM, Daniel Vetter wrote:
On Tue, Nov 27, 2018 at 04:13:03PM +
Am 12.12.18 um 11:49 schrieb Daniel Vetter:
> On Fri, Dec 07, 2018 at 11:54:15PM +0800, Chunming Zhou wrote:
>> From: Christian König
>>
>> Use the dma_fence_chain object to create a timeline of fence objects
>> instead of just replacing the existing fence.
>>
>> v2: rebase and cleanup
>>
>> Signe
On Wed, Dec 12, 2018 at 12:08 PM Koenig, Christian
wrote:
>
> Am 12.12.18 um 11:49 schrieb Daniel Vetter:
> > On Fri, Dec 07, 2018 at 11:54:15PM +0800, Chunming Zhou wrote:
> >> From: Christian König
> >>
> >> Use the dma_fence_chain object to create a timeline of fence objects
> >> instead of ju
+ Daniel Rakos and Jason Ekstrand.
Below is the background, which is from Daniel R should be able to explain
that's why:
" ISVs, especially those coming from D3D12, are unsatisfied with the behavior
of the Vulkan semaphores as they are unhappy with the fact that for every
single dependency t
Fix compilation issue with CONFIG_DRM_AMDGPU on:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c: In function
‘amdgpu_dm_mode_config_init’:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:1666:30: error:
passing argument 1 of ‘drm_atomic_private_obj_init’ from incompatible
== Series Details ==
Series: drm/amd: Compile fix for amdgpu_dm.c
URL : https://patchwork.freedesktop.org/series/53948/
State : failure
== Summary ==
CALLscripts/checksyscalls.sh
DESCEND objtool
CHK include/generated/compile.h
CC [M] drivers/gpu/drm/amd/amdgpu/../display/amdgpu
> Key point is that our Vulcan guys came back and said that this
> wouldn't be sufficient, but I honestly don't fully understand why.
> Hm, sounds like we really need those testscases (vk cts on top of mesa, igt)
> so we can talk about the exact corner cases we care about and why.
Yes, that's why I
On Wed, Dec 12, 2018 at 11:30:30AM +0100, Daniel Vetter wrote:
> On Mon, Dec 10, 2018 at 06:47:00PM -0800, Dhinakaran Pandiyan wrote:
> > On Fri, 2018-09-28 at 21:04 +0300, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > Consult the I2C_M_STOP flag to determine whether to set the MOT b
On Wed, Dec 12, 2018 at 1:00 PM Koenig, Christian
wrote:
>
> > Key point is that our Vulcan guys came back and said that this
> > wouldn't be sufficient, but I honestly don't fully understand why.
> > Hm, sounds like we really need those testscases (vk cts on top of mesa, igt)
> > so we can talk a
On Wed, Dec 12, 2018 at 12:40 PM Zhou, David(ChunMing)
wrote:
>
> + Daniel Rakos and Jason Ekstrand.
>
> Below is the background, which is from Daniel R should be able to explain
> that's why:
> " ISVs, especially those coming from D3D12, are unsatisfied with the behavior
> of the Vulkan semap
On Wed, 12 Dec 2018 13:44:13 +0200
Mika Kuoppala wrote:
> Fix compilation issue with CONFIG_DRM_AMDGPU on:
> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c: In function
> ‘amdgpu_dm_mode_config_init’:
> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:1666:30: error:
> p
On Wed, 12 Dec 2018 13:44:13 +0200
Mika Kuoppala wrote:
> Fix compilation issue with CONFIG_DRM_AMDGPU on:
> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c: In function
> ‘amdgpu_dm_mode_config_init’:
> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:1666:30: error:
> p
On Tue, 2018-12-11 at 14:02 -0800, Dhinakaran Pandiyan wrote:
> On Mon, 2018-11-12 at 11:17 +0100, Maarten Lankhorst wrote:
> > Op 09-11-18 om 21:20 schreef José Roberto de Souza:
> > > If panel supports DRRS and PSR and if driver is loaded without
> > > PSR
> > > enabled, driver will enable DRRS a
Boris Brezillon writes:
> On Wed, 12 Dec 2018 13:44:13 +0200
> Mika Kuoppala wrote:
>
>> Fix compilation issue with CONFIG_DRM_AMDGPU on:
>> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c: In function
>> ‘amdgpu_dm_mode_config_init’:
>> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_
On Wed, 12 Dec 2018 13:54:48 +0100
Boris Brezillon wrote:
> On Wed, 12 Dec 2018 13:44:13 +0200
> Mika Kuoppala wrote:
>
> > Fix compilation issue with CONFIG_DRM_AMDGPU on:
> > drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c: In function
> > ‘amdgpu_dm_mode_config_init’:
> > driver
Hi Dave,
Here's two more GPU hang fixes on top of last week's PR.
This also includes stuff from last week that I sent bit late, and
was not pulled by you. This is still on top of -rc5 because it
includes the GVT merge.
Regards, Joonas
***
drm-intel-fixes-2018-12-12-1:
- Two fixes to avoid GPU
Hopefully more fixes than bugs, but these have been annoying CI and
users for yonks (the ilk-m has been known for a few _years_, but only
recently did CI start to pick up on the error and now refuses to run on
ilk-m because of it).
-Chris
___
Intel-gfx
Currently Ironlake operates under the assumption that rpm awake (and its
error checking is disabled). As such, we have missed a few places where we
access registers without taking the rpm wakeref and thus trigger
warnings. intel_ips being one culprit.
As this involved adding a potentially sleeping
We want to exclude any GGTT objects from being present on our internal
lists to avoid the deadlock we may run into with our requirement for
struct_mutex during invalidate. However, if the gup_fast fails, we put
the userptr onto the workqueue and mark it as active, so that we
remember to serialise t
After declaring a terminally wedged device, we allow ourselves to
recover on the next GPU reset (manually triggered), or resume. Check
that resetting a wedged device does work.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
.../gpu/drm/i915/selftests/intel_hangcheck.c | 23 +
We currently require that our per-engine reset can be called from any
context, even hardirq, and in the future wish to perform the device
reset without holding struct_mutex (which requires some lockless
shenanigans that demand the lowlevel intel_reset_gpu() be able to be
used in atomic context). Te
The majority of runtime-pm operations are bounded and scoped within a
function; these are easy to verify that the wakeref are handled
correctly. We can employ the compiler to help us, and reduce the number
of wakerefs tracked when debugging, by passing around cookies provided
by the various rpm_get
Include the total size of closed vma when reporting the per_ctx_stats of
debugfs/i915_gem_objects.
Whilst adjusting the context tracking, note that we can simply use our
list of contexts in i915->contexts rather than circumlocute via
dev->filelist and the per-file context idr, with the result that
Ignore trying to shrink from i915 if we fail to acquire the struct_mutex
in the shrinker while performing direct-reclaim. The trade-off being
(much) lower latency for non-i915 clients at an increased risk of being
unable to obtain a page from direct-reclaim without hitting the
oom-notifier. The pro
As the GT_IRQ power domain implies a wakeref, we can use it inplace of
our existing redundant rpm grab.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 1 -
drivers/gpu/drm/i915/i915_gem.c | 11 ---
drivers/gpu/drm/i915/selftests/mock_
From: Oscar Mateo
SFC (Scaler & Format Converter) units are shared between VD and VEBoxes.
They also happen to have separate reset bits. So, whenever we want to reset
one or more of the media engines, we have to make sure the SFCs do not
change owner in the process and, if this owner happens to b
From: Oscar Mateo
In Gen11, only even numbered "logical" VDBoxes are hooked up to an SFC
(Scaler & Format Converter) unit. We will use this information to decide
when the SFC units need to be reset.
BSpec: 20189
Signed-off-by: Tomasz Lis
Signed-off-by: Oscar Mateo
Signed-off-by: Michel Thierr
Track where and when we acquire and release the power well for pps
access along the dp aux link, with a view to detecting if we leak any
wakerefs.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_dp.c | 231 +---
1 file changed, 121 insertions(+), 110 deleti
The information presented here is not relevant to current development.
We can either use the context information, but more often we want to
inspect the active gpu state.
The ulterior motive is to eradicate dev->filelist.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 119
Frequently, we use intel_runtime_pm_get/_put around a small block.
Formalise that usage by providing a macro to define such a block with an
automatic closure to scope the intel_runtime_pm wakeref to that block,
i.e. macro abuse smelling of python.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/
As we only release each power well once, we assume that each transcoder
maps to a different domain. Complain if this is not so.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_display.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/d
When we first introduced the reset to sanitize the GPU on taking over
from the BIOS and before returning control to third parties (the BIOS!),
we restricted it to only systems utilizing HW contexts as we were
uncertain of how stable our reset mechanism truly was. We now have
reasonable coverage acr
The majority of runtime-pm operations are bounded and scoped within a
function; these are easy to verify that the wakeref are handled
correctly. We can employ the compiler to help us, and reduce the number
of wakerefs tracked when debugging, by passing around cookies provided
by the various rpm_get
Everytime we take a wakeref, record the stack trace of where it was
taken; clearing the set if we ever drop back to no owners. For debugging
a rpm leak, we can look at all the current wakerefs and check if they
have a matching rpm_put.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/Kconfig
On module load and unload, we grab the POWER_DOMAIN_INIT powerwells and
transfer them to the runtime-pm code. We can use our wakeref tracking to
verify that the wakeref is indeed passed from init to enable, and
disable to fini; and across suspend.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/
Since commit 93065ac753e4 ("mm, oom: distinguish blockable mode for mmu
notifiers") we have been able to report failure from
mmu_invalidate_range_start which allows us to use a trylock on the
struct_mutex to avoid potential recursion and report -EBUSY instead.
Furthermore, this allows us to pull th
Should be fixed already with an updated -fixes.
Regards, Joonas
Quoting kbuild test robot (2018-12-12 10:31:58)
> tree: git://anongit.freedesktop.org/drm-intel for-linux-next-fixes
> head: eeb139ca4b24d515265ad75f668333431896b1aa
> commit: eeb139ca4b24d515265ad75f668333431896b1aa [5/5] drm/i9
== Series Details ==
Series: series starting with [01/19] drm/i915: Return immediately if trylock
fails for direct-reclaim
URL : https://patchwork.freedesktop.org/series/53953/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
916a3be212e3 drm/i915: Return immediately if trylock f
== Series Details ==
Series: series starting with [01/19] drm/i915: Return immediately if trylock
fails for direct-reclaim
URL : https://patchwork.freedesktop.org/series/53953/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Return immediatel
Hi,
On 07-12-18 12:40, Mika Westerberg wrote:
On Thu, Dec 06, 2018 at 02:47:04PM +0100, Hans de Goede wrote:
Implement the exec_mipi_pmic_seq_element callback for the CHT Whiskey Cove
PMIC.
On some CHT devices this fixes the LCD panel not lighting up when it was
not initialized by the GOP, bec
Hi,
On 07-12-18 12:39, Mika Westerberg wrote:
On Thu, Dec 06, 2018 at 02:47:03PM +0100, Hans de Goede wrote:
DSI LCD panels describe an initialization sequence in the Video BIOS
Tables using so called MIPI sequences. One possible element in these
sequences is a PMIC specific element of 15 bytes
Hi,
On 07-12-18 18:17, Ville Syrjälä wrote:
On Thu, Dec 06, 2018 at 02:47:05PM +0100, Hans de Goede wrote:
Add support for PMIC mipi sequences using the new
intel_soc_pmic_exec_mipi_pmic_seq_element function.
Please document somewhere which machines you've found to need
this (commit msg shoul
== Series Details ==
Series: series starting with [01/19] drm/i915: Return immediately if trylock
fails for direct-reclaim
URL : https://patchwork.freedesktop.org/series/53953/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5296 -> Patchwork_11077
=
On 12/12/2018 13:41, Chris Wilson wrote:
From: Oscar Mateo
In Gen11, only even numbered "logical" VDBoxes are hooked up to an SFC
(Scaler & Format Converter) unit. We will use this information to decide
when the SFC units need to be reset.
BSpec: 20189
Signed-off-by: Tomasz Lis
Signed-off-b
On 12/12/2018 13:41, Chris Wilson wrote:
From: Oscar Mateo
SFC (Scaler & Format Converter) units are shared between VD and VEBoxes.
They also happen to have separate reset bits. So, whenever we want to reset
one or more of the media engines, we have to make sure the SFCs do not
change owner in
== Series Details ==
Series: series starting with [01/19] drm/i915: Return immediately if trylock
fails for direct-reclaim
URL : https://patchwork.freedesktop.org/series/53953/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5296_full -> Patchwork_11077_full
===
Hi!
> > > > > > > There's one similar for nouveau in Bugzilla, but it seems like a
> > > > > > > genuine
> > > > > > > memory corruption (1 bit flipped):
> > > > > > >
> > > > > > > https://bugs.freedesktop.org/show_bug.cgi?id=84880
> > > > > > >
> > > > > > > Any extra information would be of
During DDB allocation, we try to distribute enough blocks for each plane
to hit the highest watermark level; if that fails, we retry each lower
level (which should require fewer blocks) until we find one that's
possible (or until the whole commit is rejected as impossible). We need
to reset our ru
On Wed, Dec 12, 2018 at 11:17:20AM -0800, Matt Roper wrote:
> During DDB allocation, we try to distribute enough blocks for each plane
> to hit the highest watermark level; if that fails, we retry each lower
> level (which should require fewer blocks) until we find one that's
> possible (or until t
From: Ville Syrjälä
Rename all the watermark related structs/enums specific to ilk-bdw
to have an ilk_ prefix rather than an intel_ prefix. Should make it
less confusing for everyone when it's clear where these things
get used.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h
From: Ville Syrjälä
The maximum watermark value we can ever have on ilk-bdw is
11 bits. Thus we can safely store all of these values in
u16.
Also toss in a few s/uint16_t/u16/ etc. while at it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h | 16 ++---
drivers/gpu/drm/i915
From: Ville Syrjälä
On ILK-IVB we must write the latency value read from SSKPD into
the latency field in the WM_LP registers. While bspec was never
clear on how the punit (or whatever) interprets these values
empirical evidence has shown that these are treated as a cookie
rather than as a literal
From: Ville Syrjälä
Give names to the HSW/BDW SSKPD mask/shift values, give
and _SNB suffix to the SNB/IVB mask/shift values, and
drop the bogus non-mirrored SSKPD register define.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 26 +-
drivers/gpu/drm
From: Ville Syrjälä
snb_wm_latency_quirk() already boosts up the latency values
so the extra warning about the SSKPD value being insufficient
is now redundant. Drop it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 2 --
drivers/gpu/drm/i915/intel_pm.c | 14 --
From: Ville Syrjälä
Remove the hand rolled array of WM0_PIPE register offsets
and use the standard _MMIO_PIPE3() instead.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 9 +
drivers/gpu/drm/i915/intel_pm.c | 13 -
2 files changed, 9 insertions(+), 13 de
== Series Details ==
Series: drm/i915: Don't forget to reset blocks when testing lower wm levels
URL : https://patchwork.freedesktop.org/series/53961/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5307 -> Patchwork_11078
Su
== Series Details ==
Series: series starting with [1/6] drm/i915: Shrink ilk-bdw wm storage by using
u16
URL : https://patchwork.freedesktop.org/series/53962/
State : failure
== Summary ==
CALLscripts/checksyscalls.sh
DESCEND objtool
CHK include/generated/compile.h
CC [M] driv
On Tue, Dec 11, 2018 at 04:39:05PM -0800, Dongseong Hwang wrote:
> framebuffer for NV12 requires the pitch to the multiplier of 4, instead
> of the width. This patch corrects it.
>
> For instance, a 480p video, whose width and pitch are 854 and 896
> respectively, is excluded for NV12 plane so far
On Wed, Dec 12, 2018 at 09:23:38PM +0200, Ville Syrjälä wrote:
> On Wed, Dec 12, 2018 at 11:17:20AM -0800, Matt Roper wrote:
> > During DDB allocation, we try to distribute enough blocks for each plane
> > to hit the highest watermark level; if that fails, we retry each lower
> > level (which shoul
On Wed, Dec 12, 2018 at 9:24 PM Ville Syrjälä
wrote:
>
> On Tue, Dec 11, 2018 at 04:39:05PM -0800, Dongseong Hwang wrote:
> > framebuffer for NV12 requires the pitch to the multiplier of 4, instead
> > of the width. This patch corrects it.
> >
> > For instance, a 480p video, whose width and pitch
Hi Dave,
One lonely patch to fix a new WARN on rockchip rk3399 chromebooks.
drm-misc-fixes-2018-12-12:
- rockchip: Revert change causing WARN on shutdown (Brian)
Cc: Brian Norris
Cheers, Sean
The following changes since commit b31a3ca745a4a47ba63208d37cd50abffe58280f:
drm/fb-helper: Fix t
On Wed, Dec 12, 2018 at 09:33:49PM +0100, Daniel Vetter wrote:
> On Wed, Dec 12, 2018 at 9:24 PM Ville Syrjälä
> wrote:
> >
> > On Tue, Dec 11, 2018 at 04:39:05PM -0800, Dongseong Hwang wrote:
> > > framebuffer for NV12 requires the pitch to the multiplier of 4, instead
> > > of the width. This pa
From: Ville Syrjälä
Remove the hand rolled array of WM0_PIPE register offsets
and use the standard _MMIO_PIPE3() instead.
v2: Take care of gvt too
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/gvt/handlers.c | 6 +++---
drivers/gpu/drm/i915/i915_reg.h | 9 +
drivers/gpu/
== Series Details ==
Series: drm/i915: Don't forget to reset blocks when testing lower wm levels
URL : https://patchwork.freedesktop.org/series/53961/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5307_full -> Patchwork_11078_full
==
== Series Details ==
Series: series starting with [1/6] drm/i915: Shrink ilk-bdw wm storage by using
u16 (rev2)
URL : https://patchwork.freedesktop.org/series/53962/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Shrink ilk-bdw wm storage by
== Series Details ==
Series: series starting with [1/6] drm/i915: Shrink ilk-bdw wm storage by using
u16 (rev2)
URL : https://patchwork.freedesktop.org/series/53962/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5308 -> Patchwork_11080
On Tue, 2018-11-20 at 18:13 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Fill out the AVI infoframe quantization range bits using
> drm_hdmi_avi_infoframe_quant_range() for SDVO HDMI encoder as well.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_sdvo.c | 19 +
On Wed, Dec 12, 2018 at 1:15 PM Ville Syrjälä
wrote:
>
> On Wed, Dec 12, 2018 at 09:33:49PM +0100, Daniel Vetter wrote:
> > On Wed, Dec 12, 2018 at 9:24 PM Ville Syrjälä
> > wrote:
> > >
> > > On Tue, Dec 11, 2018 at 04:39:05PM -0800, Dongseong Hwang wrote:
> > > > framebuffer for NV12 requires t
On Tue, Dec 11, 2018 at 04:35:57PM +0200, Jani Nikula wrote:
> On Wed, 05 Dec 2018, Lucas De Marchi wrote:
> > Instead of using IS_GEN() for consecutive gen checks, let's pass the
> > range to IS_GEN_RANGE(). By code inspection these were the ranges deemed
> > necessary for spatch:
> >
> > @@
> >
On Wed, 2018-12-12 at 05:02 -0800, Souza, Jose wrote:
> On Tue, 2018-12-11 at 14:02 -0800, Dhinakaran Pandiyan wrote:
> > On Mon, 2018-11-12 at 11:17 +0100, Maarten Lankhorst wrote:
> > > Op 09-11-18 om 21:20 schreef José Roberto de Souza:
> > > > If panel supports DRRS and PSR and if driver is loa
On Wed, Dec 12, 2018 at 11:17:38PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Remove the hand rolled array of WM0_PIPE register offsets
> and use the standard _MMIO_PIPE3() instead.
>
> v2: Take care of gvt too
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Lucas De Marchi
Lucas D
On 12/12/2018 4:34 PM, C, Ramalingam wrote:
On 12/12/2018 4:08 PM, Daniel Vetter wrote:
On Wed, Dec 12, 2018 at 02:28:29PM +0530, C, Ramalingam wrote:
On 12/7/2018 7:59 PM, Daniel Vetter wrote:
On Fri, Dec 07, 2018 at 11:22:44AM +0530, C, Ramalingam wrote:
On 12/6/2018 3:53 PM, Daniel Vett
Header defines the interface for the I915 and MEI_HDCP drivers.
Signed-off-by: Ramalingam C
---
include/drm/i915_mei_hdcp_interface.h | 132 ++
1 file changed, 132 insertions(+)
create mode 100644 include/drm/i915_mei_hdcp_interface.h
diff --git a/include/drm/i9
From: Daniel Vetter
Drivers might want to remove some sysfs files, which needs the same
locks and ends up angering lockdep. Relevant snippet of the stack
trace:
kernfs_remove_by_name_ns+0x3b/0x80
bus_remove_driver+0x92/0xa0
acpi_video_unregister+0x24/0x40
i915_driver_unload+0x42/0x130 [i
If all the components associated to a component master is not added
to the component framework due to the HW capability or Kconfig
selection, component_match will be NULL at
component_master_add_with_match().
To avoid this, component_match_alloc() is added to the framework,
to allcoate the struct
This series enables the HDCP2.2 for I915. The sequence for HDCP2.2
authentication and encryption is implemented as a generic flow
between HDMI and DP. Encoder specific implementations are moved
into hdcp_shim.
Intel HWs supports HDCP2.2 through ME FW. Hence this series
introduces a client driver f
A generic component master is added to hold the i915 registration
until all required kernel modules are up and active.
This is achieved through following steps:
- moving the i915 driver registration to the component master's
bind call
- all required kernel modules will add one component ea
All HDCP1.4 routines are gathered together, followed by the generic
functions those can be extended for HDCP2.2 too.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_hdcp.c | 118 +++---
1 file changed, 59 insertions(+), 59 deletions(-)
diff --git a/dri
Add the HDCP2.2 initialization to the existing HDCP1.4 stack.
v2:
mei interface handle is protected with mutex. [Chris Wilson]
v3:
Notifiers are used for the mei interface state.
v4:
Poll for mei client device state
Error msg for out of mem [Uma]
Inline req for init function removed [Uma
Defining the mei-i915 interface functions and initialization of
the interface.
v2:
Adjust to the new interface changes. [Tomas]
Added further debug logs for the failures at MEI i/f.
port in hdcp_port data is equipped to handle -ve values.
v3:
mei comp is matched for global i915 comp master
Implements the HDCP2.2 repeaters authentication steps such as verifying
the downstream topology and sending stream management information.
v2: Rebased.
v3:
-EINVAL is returned for topology error and rollover scenario.
Endianness conversion func from drm_hdcp.h is used [Uma]
v4:
Rebased as pa
Library functions for endianness are aligned for 16/32/64 bits.
But hdcp sequence numbers are 24bits(big endian).
So for their conversion to and from u32 helper functions are developed.
Signed-off-by: Ramalingam C
---
include/drm/drm_hdcp.h | 18 ++
1 file changed, 18 insertions(
"hdcp_encrypted" flag is defined to denote the HDCP1.4 encryption status.
This SW tracking is used to determine the need for real hdcp1.4 disable
and hdcp_check_link upon CP_IRQ.
On CP_IRQ we filter the CP_IRQ related to the states like Link failure
and reauthentication req etc and handle them in
Implements the HDMI adaptation specific HDCP2.2 operations.
Basically these are DDC read and write for authenticating through
HDCP2.2 messages.
v2: Rebased.
v3:
No more special handling of Gmbus burst read for AKE_SEND_CERT.
Style fixed with few naming. [Uma]
%s/PARING/PAIRING
v4:
msg_sz
Implements the link integrity check once in 500mSec.
Once encryption is enabled, an ongoing Link Integrity Check is
performed by the HDCP Receiver to check that cipher synchronization
is maintained between the HDCP Transmitter and the HDCP Receiver.
On the detection of synchronization lost, the H
Defines the HDCP specific ME FW interfaces such as Request CMDs,
payload structure for CMDs and their response status codes.
This patch defines payload size(Excluding the Header)for each WIRED
HDCP2.2 CMDs.
v2: Rebased.
v3:
Extra comments are removed.
v4:
%s/\/\*\*/\/\*
v5:
Extra lines are
From: Tomas Winkler
Whitelist HDCP client for in kernel drm use
v2:
Rebased.
Signed-off-by: Tomas Winkler
---
drivers/misc/mei/bus-fixup.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/misc/mei/bus-fixup.c b/drivers/misc/mei/bus-fixup.c
index 80215c312f0e..5f
1 - 100 of 130 matches
Mail list logo
