On Tue, 07 May 2019, Jani Nikula wrote:
> On Mon, 06 May 2019, "Sharma, Swati2" wrote:
>> On 06-May-19 7:11 PM, Jani Nikula wrote:
>>> On Mon, 06 May 2019, Ville Syrjälä wrote:
On Mon, May 06, 2019 at 04:21:07PM +0300, Jani Nikula wrote:
> On Sat, 04 May 2019, Swati Sharma wrote:
>
On Mon, 06 May 2019, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> For us KBP is 100% identical to SPT. Kill the redundant enum
> value. Also bspec doesn't talk about KBP either, so this might
> avoid some confusion when cross checking the code against the
> spec.
>
> Signed-off-by: Ville Syrjäl
+Maarten - could you please have a quick look at this patch to see if it
makes sense to you? (https://patchwork.freedesktop.org/series/59284/ -
if you don't have the mailing list history.)
Thanks,
Tvrtko
On 10/04/2019 13:11, Tvrtko Ursulin wrote:
On 10/04/2019 12:48, Chris Wilson wrote:
>-Original Message-
>From: Jonas Karlman [mailto:jo...@kwiboo.se]
>Sent: Saturday, May 4, 2019 3:48 PM
>To: Shankar, Uma ; intel-gfx@lists.freedesktop.org; dri-
>de...@lists.freedesktop.org
>Cc: dcasta...@chromium.org; emil.l.veli...@gmail.com; seanp...@chromium.org;
>Syrjala, Ville ; Lan
Hi,
Here's gvt-next-fixes for 5.2-rc, which includes one revert for BXT
regression, one missed context mmio reg after RCS renaming, sanitize
display buffer size calculation and some klocwork warning/error fixes.
Thanks
--
The following changes since commit 447811a686e8da7325516a78069ccfbd139ef1a
On Tue, Apr 30, 2019 at 02:12:39PM -0700, Aditya Swarup wrote:
> On Tue, Apr 30, 2019 at 06:05:18PM +0300, Ville Syrjälä wrote:
> > On Mon, Apr 29, 2019 at 05:00:28PM -0700, Aditya Swarup wrote:
> > > From: Ville Syrjälä
> > >
> > > There is a bug in hdmi_deep_color_possible() - we compare pipe_b
On Mon, May 06, 2019 at 03:01:59PM -0700, Clinton Taylor wrote:
> Very straight forward. Nit variable names val and val1, maybe val0 and val1.
The registers are named DATA and DATA1, so I called the variables val
and val1. I guess I could have renamed them to data and data1 to make
the relationshi
On Mon, May 06, 2019 at 03:38:43PM -0700, Clinton Taylor wrote:
>
> On 5/3/19 12:08 PM, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > ICL has so many planes that it can easily exceed the maximum
> > effective memory bandwidth of the system. We must therefore check
> > that we don't exceed
On Tue, May 07, 2019 at 09:03:45AM +, Shankar, Uma wrote:
>
>
> >-Original Message-
> >From: Jonas Karlman [mailto:jo...@kwiboo.se]
> >Sent: Saturday, May 4, 2019 3:48 PM
> >To: Shankar, Uma ; intel-gfx@lists.freedesktop.org;
> >dri-
> >de...@lists.freedesktop.org
> >Cc: dcasta...@ch
On 03/05/2019 14:52, Chris Wilson wrote:
When we want to wait for a request to be executed, we first ask if it is
not on the GPU as if it's on the gpu, there's no need to wait. However,
we have to take into account that a request may not be on the GPU
because it has already completed!
The wind
On Tue, May 07, 2019 at 09:42:48AM +0300, Jani Nikula wrote:
> On Mon, 29 Apr 2019, Aditya Swarup wrote:
> > From: Clinton Taylor
> >
> > v2: Fix commit msg to reflect why issue occurs(Jani)
> > Set GCP_COLOR_INDICATION only when we set 10/12 bit deep color.
> >
> > Changing settings from 10/12 b
On 03/05/2019 15:02, Chris Wilson wrote:
Acquiring the signaler's timeline takes an active reference to their
HWSP that we would like to avoid if possible, so take it after
performing all of our allocations required to set up the fencing. The
acquisition also provides the final check that the ta
On 03/05/2019 16:22, Chris Wilson wrote:
Inside the signal handler, we expect the requests to be ordered by their
breadcrumb such that no later request may be complete if we find an
earlier incomplete. Add an assert to check that the next breadcrumb
should not be logically before the current.
v
On 03/05/2019 12:52, Chris Wilson wrote:
The counter goes to zero at the start of the parking cycle, but the
wakeref itself is held until the end. Likewise, the counter becomes one
at the end of the unparking, but the wakeref is taken first. If we check
the wakeref instead of the counter, we inc
On 03/05/2019 12:52, Chris Wilson wrote:
Due to the asynchronous tasklet and recursive GT wakeref, it may happen
that we submit to the engine (underneath it's own wakeref) prior to the
central wakeref being marked as taken. Switch to checking the local wakeref
for greater consistency.
Fixes: 79
On Tue, May 07, 2019 at 12:27:07AM +0530, Sharma, Swati2 wrote:
> On 07-May-19 12:03 AM, Ville Syrjälä wrote:
>
> > On Sat, May 04, 2019 at 10:41:40PM +0530, Swati Sharma wrote:
> >> v3: Rebase
> >> v4: -Renamed intel_compare_color_lut() to intel_color_lut_equal() [Jani]
> >> -Added the defau
On 03/05/2019 12:52, Chris Wilson wrote:
The original intent for the delay before running the idle_work was to
provide a hysteresis to avoid ping-ponging the device runtime-pm. Since
then we have also pulled in some memory management and general device
management for parking. But with the invers
tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip
head: 73db4ec12f05160528884c0b2c845b1c6b7c6718
commit: b9a2acf7709f52c77dc752ec99e3873e392d8df6 [5/8] Merge remote-tracking
branch 'drm-intel/drm-intel-next-queued' into drm-tip
config: x86_64-rhel (attached as .config)
compiler: gcc-7 (D
On 03/05/2019 12:52, Chris Wilson wrote:
Replace the racy continuation check within retire_work with a definite
kill-switch on idling. The race was being exposed by gem_concurrent_blit
where the retire_worker would be terminated too early leaving us
spinning in debugfs/i915_drop_caches with noth
Some steps in gen6_alloc_va_range require the HW to be awake, so ideally
we should be grabbing the wakeref ourselves and not relying on the
caller already holding it for us.
Suggested-by: Chris Wilson
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 8 +++-
1 file chang
The plan is to use the blitter engine for async object clearing when
using local memory, but before we can move the worker to get_pages() we
have to first tame some more of our struct_mutex usage. With this in
mind we should be able to upstream the object clearing as some
selftests, which should se
tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip
head: ae28cc6cf80a2e8cbb58f255ef7cac6b2923c98a
commit: 47f4a14297839cb4cedd725fb916a5da5eb9b5ba [/8] Merge remote-tracking
branch 'drm-intel/drm-intel-next-queued' into drm-tip
config: x86_64-rhel (attached as .config)
compiler: gcc-7 (De
On Tue, 07 May 2019, Ville Syrjälä wrote:
> On Tue, May 07, 2019 at 09:42:48AM +0300, Jani Nikula wrote:
>> On Mon, 29 Apr 2019, Aditya Swarup wrote:
>> > From: Clinton Taylor
>> >
>> > v2: Fix commit msg to reflect why issue occurs(Jani)
>> > Set GCP_COLOR_INDICATION only when we set 10/12 bit
== Series Details ==
Series: i915: disable framebuffer compression on GeminiLake (rev2)
URL : https://patchwork.freedesktop.org/series/60090/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6055 -> Patchwork_12974
Summary
---
Quoting Matthew Auld (2019-05-07 11:55:56)
> Some steps in gen6_alloc_va_range require the HW to be awake, so ideally
> we should be grabbing the wakeref ourselves and not relying on the
> caller already holding it for us.
>
> Suggested-by: Chris Wilson
> Signed-off-by: Matthew Auld
> ---
> dri
On 03/05/2019 12:52, Chris Wilson wrote:
If we couple the scheduler more tightly with the execlists policy, we
can apply the preemption policy to the question of whether we need to
kick the tasklet at all for this priority bump.
v2: Rephrase it as a core i915 policy and not an execlists foible.
Quoting Matthew Auld (2019-05-07 11:55:57)
> The plan is to use the blitter engine for async object clearing when
> using local memory, but before we can move the worker to get_pages() we
> have to first tame some more of our struct_mutex usage. With this in
> mind we should be able to upstream the
On Tue, Apr 09, 2019 at 10:14:42PM +0530, Uma Shankar wrote:
> This patch enables modeset whenever HDR metadata
> needs to be updated to sink.
>
> v2: Addressed Shashank's review comments.
>
> v3: Added Shashank's RB.
>
> Signed-off-by: Ville Syrjälä
> Signed-off-by: Uma Shankar
> Reviewed-by:
On 03/05/2019 12:52, Chris Wilson wrote:
Do not treat reset as a normal preemption event and avoid giving the
guilty request a priority boost for simply being active at the time of
reset.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 16 +---
1 file chang
On 03/05/2019 12:52, Chris Wilson wrote:
To avoid pulling in a forward declaration in the next patch, move the
i915_sched_node handling to after the main dfs of the scheduler.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_scheduler.c | 210 +-
1 file chan
On Tue, Apr 09, 2019 at 10:14:35PM +0530, Uma Shankar wrote:
> This patch adds a blob property to get HDR metadata
> information from userspace. This will be send as part
> of AVI Infoframe to panel.
>
> It also implements get() and set() functions for HDR output
> metadata property.The blob data
On Tue, May 07, 2019 at 01:25:42PM +0300, Ville Syrjälä wrote:
> On Tue, May 07, 2019 at 09:03:45AM +, Shankar, Uma wrote:
> >
> >
> > >-Original Message-
> > >From: Jonas Karlman [mailto:jo...@kwiboo.se]
> > >Sent: Saturday, May 4, 2019 3:48 PM
> > >To: Shankar, Uma ; intel-gfx@lists
The original intent for the delay before running the idle_work was to
provide a hysteresis to avoid ping-ponging the device runtime-pm. Since
then we have also pulled in some memory management and general device
management for parking. But with the inversion of the wakeref handling,
GEM is no longe
If the user is racing a call to debugfs/i915_drop_caches with ongoing
submission from another thread/process, we may never end up idling the
GPU and be uninterruptibly spinning in debugfs/i915_drop_caches trying
to catch an idle moment.
Just flush the work once, that should be enough to park the s
Replace the racy continuation check within retire_work with a definite
kill-switch on idling. The race was being exposed by gem_concurrent_blit
where the retire_worker would be terminated too early leaving us
spinning in debugfs/i915_drop_caches with nothing flushing the
retirement queue.
Although
To complete the idle worker, we must complete 2 passes of wait-for-idle.
At the end of the first pass, we queue a switch-to-kernel-context and
may only idle after waiting for its completion. Speed up the flush_work
by doing the wait explicitly, which then allows us to remove the
unbounded loop tryi
On 03/05/2019 12:52, Chris Wilson wrote:
To simplify the next patch, update bump_priority and schedule to accept
the internal i915_sched_ndoe directly and not expect a request pointer.
add/remove: 0/0 grow/shrink: 2/1 up/down: 8/-15 (-7)
Function old new
Acked-by: Satyeshwar Singh
-Original Message-
From: Roper, Matthew D
Sent: Monday, May 6, 2019 2:59 PM
To: Daniel Vetter
Cc: C, Ramalingam ; Vetter, Daniel
; intel-gfx@lists.freedesktop.org;
dri-de...@lists.freedesktop.org; Singh, Satyeshwar
Subject: Re: [Intel-gfx] [PATCH v6 03/10]
== Series Details ==
Series: series starting with [v2,1/2] drm/i915/gtt: grab wakeref in
gen6_alloc_va_range
URL : https://patchwork.freedesktop.org/series/60364/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
85a64e026cc5 drm/i915/gtt: grab wakeref in gen6_alloc_va_range
12c78
== Series Details ==
Series: series starting with [v2,1/2] drm/i915/gtt: grab wakeref in
gen6_alloc_va_range
URL : https://patchwork.freedesktop.org/series/60364/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915/gtt: grab wakeref in gen6_alloc_
If we couple the scheduler more tightly with the execlists policy, we
can apply the preemption policy to the question of whether we need to
kick the tasklet at all for this priority bump.
v2: Rephrase it as a core i915 policy and not an execlists foible.
v3: Pull the kick together.
Signed-off-by:
Quoting Tvrtko Ursulin (2019-05-07 13:12:05)
>
> On 03/05/2019 12:52, Chris Wilson wrote:
> > To simplify the next patch, update bump_priority and schedule to accept
> > the internal i915_sched_ndoe directly and not expect a request pointer.
> >
> > add/remove: 0/0 grow/shrink: 2/1 up/down: 8/-15
On 07/05/2019 13:11, Chris Wilson wrote:
To complete the idle worker, we must complete 2 passes of wait-for-idle.
At the end of the first pass, we queue a switch-to-kernel-context and
may only idle after waiting for its completion. Speed up the flush_work
by doing the wait explicitly, which then
Do not treat reset as a normal preemption event and avoid giving the
guilty request a priority boost for simply being active at the time of
reset.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 16 +---
1 file changed, 9 insertions(
Thanks, pulled this now.
Regards, Joonas
Quoting Zhenyu Wang (2019-05-07 12:05:58)
>
> Hi,
>
> Here's gvt-next-fixes for 5.2-rc, which includes one revert for BXT
> regression, one missed context mmio reg after RCS renaming, sanitize
> display buffer size calculation and some klocwork warning/e
== Series Details ==
Series: series starting with [v2,1/2] drm/i915/gtt: grab wakeref in
gen6_alloc_va_range
URL : https://patchwork.freedesktop.org/series/60364/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6057 -> Patchwork_12975
===
On 03/05/2019 12:52, Chris Wilson wrote:
The handling of the no-preemption priority level imposes the restriction
that we need to maintain the implied ordering even though preemption is
disabled. Otherwise we may end up with an AB-BA deadlock across multiple
engine due to a real preemption event
From: Uma Shankar
Currently input csc for YCbCR to RGB conversion handles only
BT601 and Bt709. Extending it to support BT2020 as well.
Signed-off-by: Uma Shankar
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_sprite.c | 24
1 file changed, 24 insertion
Framebuffer formats P01x are supported by GLK, but the function which
handles CSC on plane color control register, still expectes the input
buffer to be REC709. This can cause inaccurate output for direct P01x
flips.
This patch checks if the color_encoding property is set to YCBCR_2020,
and enable
Quoting Tvrtko Ursulin (2019-05-07 13:46:45)
>
> On 03/05/2019 12:52, Chris Wilson wrote:
> > The handling of the no-preemption priority level imposes the restriction
> > that we need to maintain the implied ordering even though preemption is
> > disabled. Otherwise we may end up with an AB-BA dea
On 4/9/19 12:44 PM, Uma Shankar wrote:
> HDR metadata block is introduced in CEA-861.3 spec.
> Parsing the same to get the panel's HDR metadata.
>
> v2: Rebase and added Ville's POC changes to the patch.
>
> v3: No Change
>
> v4: Addressed Shashank's review comments
>
> v5: Addressed Shashank's
== Series Details ==
Series: series starting with [1/4] drm/i915: Flush the switch-to-kernel-context
harder for DROP_IDLE
URL : https://patchwork.freedesktop.org/series/60367/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
76031545f275 drm/i915: Flush the switch-to-kernel-conte
Currently, data type of gamma_lut_size & degamma_lut_size elements
in intel_device_info is u16, which means it can accommodate maximum
64k values. In case of ICL multisegmented gamma, the size of gamma
LUT is 256K.
This patch changes the data type of both of these elements to u32.
Cc: Ville Syrjä
ICL introduces a new gamma correction mode in display engine, called
multi-segmented-gamma mode. This mode allows users to program the
darker region of the gamma curve with sueprfine precision. An
example use case for this is HDR curves (like PQ ST-2084).
If we plot a gamma correction curve from v
Quoting Imre Deak (2019-05-03 00:26:39)
> @@ -4521,12 +4602,12 @@ void intel_runtime_pm_cleanup(struct drm_i915_private
> *i915)
> struct i915_runtime_pm *rpm = &i915->runtime_pm;
> int count;
>
> - count = atomic_fetch_inc(&rpm->wakeref_count); /* balance untrack */
> +
On Tue, May 07, 2019 at 06:32:57PM +0530, Shashank Sharma wrote:
> From: Uma Shankar
>
> Currently input csc for YCbCR to RGB conversion handles only
> BT601 and Bt709. Extending it to support BT2020 as well.
>
> Signed-off-by: Uma Shankar
> Signed-off-by: Shashank Sharma
> ---
> drivers/gpu/
This patch series enables programming of Multi-segmented-gamma
palette for ICL.
Shashank Sharma (3):
drm/i915: Change gamma/degamma_lut_size data type to u32
drm/i915: Rename ivb_load_lut_10_max
drm/i915/icl: Add Multi-segmented gamma support
Uma Shankar (1):
drm/i915/icl: Add register de
From: Uma Shankar
Add macros to define multi segmented gamma registers
V2: Addressed Ville's comments:
Add gen-lable before bit definition
Addressed Jani's comment
- Use REG_GENMASK() and REG_BIT()
V3: Addressed Ville's comments:
- Put comments at the end of line.
- C
This patch renames function ivb_load_lut_10_max to
ivb_load_lut_ext_max.
V3: Added Vill'es r-b.
Cc: Uma Shankar
Suggested-by: Ville Syrjala
Reviewed-by: Ville Syrjala
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_color.c | 14 +++---
1 file changed, 7 insertions(+),
On Tue, May 07, 2019 at 07:26:44PM +0530, Shashank Sharma wrote:
> ICL introduces a new gamma correction mode in display engine, called
> multi-segmented-gamma mode. This mode allows users to program the
> darker region of the gamma curve with sueprfine precision. An
> example use case for this is
== Series Details ==
Series: drm/i915: Only reschedule the submission tasklet if preemption is
possible
URL : https://patchwork.freedesktop.org/series/60368/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Only reschedule the submission taskl
On 07/05/2019 14:14, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-05-07 13:46:45)
On 03/05/2019 12:52, Chris Wilson wrote:
The handling of the no-preemption priority level imposes the restriction
that we need to maintain the implied ordering even though preemption is
disabled. Otherwise w
>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Ville
>Syrjälä
>Sent: Tuesday, May 7, 2019 7:37 PM
>To: Sharma, Shashank
>Cc: intel-gfx@lists.freedesktop.org
>Subject: Re: [Intel-gfx] [PATCH] drm/i915/icl: Handle YCbCr to RGB conversio
Quoting Chris Wilson (2019-05-07 14:14:01)
> Quoting Tvrtko Ursulin (2019-05-07 13:46:45)
> >
> > On 03/05/2019 12:52, Chris Wilson wrote:
> > > diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
> > > b/drivers/gpu/drm/i915/i915_scheduler.c
> > > index 380cb7343a10..ff0ca5718f97 100644
> > > ---
== Series Details ==
Series: series starting with [1/4] drm/i915: Flush the switch-to-kernel-context
harder for DROP_IDLE
URL : https://patchwork.freedesktop.org/series/60367/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6058 -> Patchwork_12976
==
== Series Details ==
Series: i915: disable framebuffer compression on GeminiLake (rev2)
URL : https://patchwork.freedesktop.org/series/60090/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6055_full -> Patchwork_12974_full
S
== Series Details ==
Series: drm/i915: Only reschedule the submission tasklet if preemption is
possible
URL : https://patchwork.freedesktop.org/series/60368/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6059 -> Patchwork_12977
== Series Details ==
Series: drm/i915/execlists: Don't apply priority boost for resets
URL : https://patchwork.freedesktop.org/series/60369/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6059 -> Patchwork_12978
Summary
On Tue, May 07, 2019 at 02:35:15PM +, Shankar, Uma wrote:
>
>
> >-Original Message-
> >From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> >Of Ville
> >Syrjälä
> >Sent: Tuesday, May 7, 2019 7:37 PM
> >To: Sharma, Shashank
> >Cc: intel-gfx@lists.freedesktop.o
== Series Details ==
Series: Enable Multi-segmented-gamma for ICL (rev2)
URL : https://patchwork.freedesktop.org/series/60126/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6059 -> Patchwork_12979
Summary
---
**SUCCE
On every hdcp revocation check request SRM is read from fw file
/lib/firmware/display_hdcp_srm.bin
SRM table is parsed and stored at drm_hdcp.c, with functions exported
for the services for revocation check from drivers (which
implements the HDCP authentication)
This patch handles the HDCP1.4 and
Considering the significant size of hdcp related code in drm, all
hdcp related codes are moved into separate file called drm_hdcp.c.
v2:
Rebased.
v2:
Rebased.
Signed-off-by: Ramalingam C
Suggested-by: Daniel Vetter
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_connector.c | 44 --
Adding the HDCP2.2 capability of HDCP src and sink info into debugfs
entry "i915_hdcp_sink_capability"
This helps the userspace tests to skip the HDCP2.2 test on non HDCP2.2
sinks.
v2:
Rebased.
Signed-off-by: Ramalingam C
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_debugfs.c |
drm function is defined and exported to update a connector's
content protection property state and to generate a uevent along
with it.
Need ACK for the uevent from userspace consumer.
v2:
Update only when state is different from old one.
v3:
KDoc is added [Daniel]
Signed-off-by: Ramalingam C
DRM HDCP SRM revocation check services are used from I915 for HDCP1.4
and 2.2 revocation check during the respective authentication flow.
v2:
Rebased.
v3:
%s/*_ksvs_revocated/*_check_ksvs_revoked [Daniel]
unwanted noise is removed.
Signed-off-by: Ramalingam C
Reviewed-by: Daniel Vetter
--
Attaches the content type property for HDCP2.2 capable connectors.
Implements the update of content type from property and apply the
restriction on HDCP version selection.
Need ACK for content type property from userspace consumer.
v2:
s/cp_content_type/content_protection_type [daniel]
disab
DRM API for generating uevent for a status changes of connector's
property.
This uevent will have following details related to the status change:
HOTPLUG=1, CONNECTOR= and PROPERTY=
Need ACK from this uevent from userspace consumer.
v2:
Minor fixes at KDoc comments [Daniel]
v3:
Check the
This patch adds a DRM ENUM property to the selected connectors.
This property is used for mentioning the protected content's type
from userspace to kernel HDCP authentication.
Type of the stream is decided by the protected content providers.
Type 0 content can be rendered on any HDCP protected dis
Content protection property is created once and stored in
drm_mode_config. And attached to all HDCP capable connectors.
Signed-off-by: Ramalingam C
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic_uapi.c | 4 ++--
drivers/gpu/drm/drm_connector.c | 13 +++--
include/drm/drm_c
Existing functions for converting a 3bytes(be24) of big endian value
into u32 of little endian and vice versa are renamed as
s/drm_hdcp2_seq_num_to_u32/drm_hdcp_be24_to_cpu
s/drm_hdcp2_u32_to_seq_num/drm_hdcp_cpu_to_be24
Signed-off-by: Ramalingam C
Suggested-by: Daniel Vetter
cc: Tomas Winkler
This series adds the content type capability for HDCP through a
drm connetor proeprty "HDCP Content Type". By default this property will
be "Type 0". And this property is exposed by the drivers which has the
HDCP2.2 capability to enable the userspace to configure for "Type 1".
HDCP Content Type:
drm function to update the content protection property state and to
generate a uevent is invoked from the intel hdcp property work.
Hence whenever kernel changes the property state, userspace will be
updated with a uevent.
Need a ACK for uevent generating uAPI from userspace.
v2:
state update
== Series Details ==
Series: HDCP2.2 Phase II (rev9)
URL : https://patchwork.freedesktop.org/series/57232/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
2c27a886355d drm: move content protection property to mode_config
95b249c75379 drm/i915: debugfs: HDCP2.2 capability read
896
== Series Details ==
Series: HDCP2.2 Phase II (rev9)
URL : https://patchwork.freedesktop.org/series/57232/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm: move content protection property to mode_config
Okay!
Commit: drm/i915: debugfs: HDCP2.2 cap
Quoting Tvrtko Ursulin (2019-04-29 15:12:23)
>
> On 25/04/2019 10:19, Chris Wilson wrote:
> > static void virtual_submission_tasklet(unsigned long data)
> > {
> > struct virtual_engine * const ve = (struct virtual_engine *)data;
> > const int prio = ve->base.execlists.queue_priorit
console_trylock, called from within printk, can be called from pretty
much anywhere. Including try_to_wake_up. Note that this isn't common,
usually the box is in pretty bad shape at that point already. But it
really doesn't help when then lockdep jumps in and spams the logs,
potentially obscuring t
== Series Details ==
Series: HDCP2.2 Phase II (rev9)
URL : https://patchwork.freedesktop.org/series/57232/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6060 -> Patchwork_12980
Summary
---
**SUCCESS**
No regressio
== Series Details ==
Series: RFC: x86/smp: use printk_deferred in native_smp_send_reschedule
URL : https://patchwork.freedesktop.org/series/60384/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
79bd449b8e2d RFC: x86/smp: use printk_deferred in native_smp_send_reschedule
-:93: WA
On 5/3/19 2:30 PM, Stuart Summers wrote:
Move functions to intel_sseu.h and remove inline qualifier.
Additionally, ensure these are all prefixed with intel_sseu_*
to match the convention of other functions in i915.
v2: fix spacing from checkpatch warning
v3: squash helper function changes into
On Tue, 2019-05-07 at 11:12 -0700, Daniele Ceraolo Spurio wrote:
>
> On 5/3/19 2:30 PM, Stuart Summers wrote:
> > Move functions to intel_sseu.h and remove inline qualifier.
> > Additionally, ensure these are all prefixed with intel_sseu_*
> > to match the convention of other functions in i915.
>
There is a bug in hdmi_deep_color_possible() - we compare pipe_bpp
<= 8*3 which returns true every time for hdmi_deep_color_possible 12 bit
deep color mode test in intel_hdmi_compute_config().(Even when the
requested color mode is 10 bit through max bpc property)
Comparing pipe_bpp with bpc * 3 ta
On Thu, Apr 25, 2019 at 07:29:05PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> On HSW the pipe A panel fitter lives inside the display power well,
> and the input MUX for the EDP transcoder needs to be configured
> appropriately to route the data through the power well as needed.
> Chan
== Series Details ==
Series: RFC: x86/smp: use printk_deferred in native_smp_send_reschedule
URL : https://patchwork.freedesktop.org/series/60384/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6061 -> Patchwork_12981
Summar
On Tue, May 07, 2019 at 11:18:56AM -0700, Aditya Swarup wrote:
> There is a bug in hdmi_deep_color_possible() - we compare pipe_bpp
> <= 8*3 which returns true every time for hdmi_deep_color_possible 12 bit
> deep color mode test in intel_hdmi_compute_config().(Even when the
> requested color mode
== Series Details ==
Series: series starting with [1/4] drm/i915: Flush the switch-to-kernel-context
harder for DROP_IDLE
URL : https://patchwork.freedesktop.org/series/60367/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6058_full -> Patchwork_12976_full
On 5/3/19 2:30 PM, Stuart Summers wrote:
Currently, the subslice_mask runtime parameter is stored as an
array of subslices per slice. Expand the subslice mask array to
better match what is presented to userspace through the
I915_QUERY_TOPOLOGY_INFO ioctl. The index into this array is
then calcu
On 5/6/2019 14:36, Rodrigo Vivi wrote:
On Tue, Apr 23, 2019 at 06:50:13PM -0700, john.c.harri...@intel.com wrote:
From: John Harrison
With virtual engines, it is no longer possible to know which specific
physical engine a given request will be executed on at the time that
request is generated.
== Series Details ==
Series: drm/i915/icl: Fix setting 10 bit deep color mode (rev3)
URL : https://patchwork.freedesktop.org/series/60080/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6062 -> Patchwork_12982
Summary
--
On 5/6/2019 8:26 AM, Tejun Heo wrote:
> Hello,
>
> On Wed, May 01, 2019 at 10:04:33AM -0400, Brian Welty wrote:
>> The patch series enables device drivers to use cgroups to control the
>> following resources within a GPU (or other accelerator device):
>> * control allocation of device memory (re
== Series Details ==
Series: drm/i915: Only reschedule the submission tasklet if preemption is
possible
URL : https://patchwork.freedesktop.org/series/60368/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6059_full -> Patchwork_12977_full
==
1 - 100 of 110 matches
Mail list logo
