HDCP 1.x capability needs to be checked even if setup is not
HDCP 2.x capable.
--v2
-Assign hdcp_capable and hdcp2_capable to false [Chaitanya]
--v3
-Fix variable assignment [Chaitanya]
Fixes: 813cca96e4ac ("drm/i915/hdcp: Add new remote capability check shim
function")
Signed-off-by: Suraj
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Friday, March 29, 2024 6:43 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH 01/22] drm/i915: Disable port sync when bigjoiner is used
>
> From: Ville Syrjälä
>
> The current modeset sequence can't
Hello Suraj,
> -Original Message-
> From: Kandpal, Suraj
> Sent: Monday, April 1, 2024 8:31 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Borah, Chaitanya Kumar ; Kandpal,
> Suraj
> Subject: [PATCH 2/2] drm/i915/hdcp: Fix get remote hdcp capability function
>
> HDCP 1.x capability
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Friday, March 29, 2024 6:43 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH 22/22] drm/i915: Use debugfs_create_bool() for
> "i915_bigjoiner_force_enable"
>
> From: Ville Syrjälä
>
> There is no
== Series Details ==
Series: drm/ttm: remove unused paramter (rev2)
URL : https://patchwork.freedesktop.org/series/131576/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_14509 -> Patchwork_131576v2
Summary
---
== Series Details ==
Series: drm/ttm: remove unused paramter (rev2)
URL : https://patchwork.freedesktop.org/series/131576/
State : warning
== Summary ==
Error: dim checkpatch failed
372ac4183a0f drm/ttm: remove unused paramter
-:4: WARNING:TYPO_SPELLING: 'paramter' may be misspelled - perhaps
== Series Details ==
Series: Fix UBSAN warning in hdcp_info (rev2)
URL : https://patchwork.freedesktop.org/series/131673/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_14509 -> Patchwork_131673v2
Summary
---
> Subject: [PATCH] drm/i915: Fix i915_display_info output when connectors are
> not active
>
> From: Ville Syrjälä
>
> Currently intel_connector_info(), which prints the per-connector output for
> i915_display_info, just bails out early if the connector doesn't have a
> current
> encoder. That
== Series Details ==
Series: Fix UBSAN warning in hdcp_info (rev2)
URL : https://patchwork.freedesktop.org/series/131673/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
From: Jesse Zhang
remove the unsed the paramter in the function
ttm_bo_bounce_temp_buffer and ttm_bo_add_move_fence.
V2:rebase the patch on top of drm-misc-next (Christian)
Signed-off-by: Jesse Zhang
Reviewed-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 8 +++-
1 file changed,
HDCP 1.x capability needs to be checked even if setup is not
HDCP 2.x capable.
--v2
-Assign hdcp_capable and hdcp2_capable to false [Chaitanya]
Fixes: 813cca96e4ac ("drm/i915/hdcp: Add new remote capability check shim
function")
Signed-off-by: Suraj Kandpal
---
Initialize HDCP capability variables to false to avoid UBSAN
warning in boolean value as some functions invoking this could
return without filling the two capability values.
--v2
-Fix Typo [Chaitanya]
Signed-off-by: Suraj Kandpal
Reviewed-by: Chaitanya Kumar Borah
---
This patch series fixes the UBSAN warning which gets called
when hdcp_info is invoked accompanied by some other logical fixes
required in the hdcp capability function.
Signed-off-by: Suraj Kandpal
Suraj Kandpal (2):
drm/i915/display: Initialize capability variables
drm/i915/hdcp: Fix get
== Series Details ==
Series: Make I2C terminology more inclusive for I2C Algobit and consumers
URL : https://patchwork.freedesktop.org/series/131867/
State : failure
== Summary ==
Error: make failed
CALLscripts/checksyscalls.sh
DESCEND objtool
INSTALL libsubcmd_headers
CC [M]
Hello,
I enabled the CMA (CONFIG_CMA=y) for an x86 machine on Linux kernel v5.10 and
v5.15 When I boot the system the CMA reserved memory, but when the graphic card
driver i915 or hda_intel is loaded the system crashed.
I see that ioremap on RAM at 0x - 0xd000 get
On 3/29/2024 10:16 AM, Andi Shyti wrote:
> Hi Easwar,
>
> On Fri, Mar 29, 2024 at 05:00:26PM +, Easwar Hariharan wrote:
>> I2C v7, SMBus 3.2, and I3C specifications have replaced "master/slave"
>
> I don't understand why we forget that i3c is 1.1.1 :-)
That's because it's a copy-paste error
On 3/29/2024 10:28 AM, Easwar Hariharan wrote:
> On 3/29/2024 10:16 AM, Andi Shyti wrote:
>> Hi Easwar,
>>
>>
>> The specification talks about:
>>
>> - master -> controller
>> - slave -> target (and not client)
>>
>> But both you and Wolfram have used client. I'd like to reach
>> some more
I2C v7, SMBus 3.2, and I3C specifications have replaced "master/slave"
with more appropriate terms. Inspired by and following on to Wolfram's
series to fix drivers/i2c/[1], fix the terminology for users of
I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
in the
I2C v7, SMBus 3.2, and I3C specifications have replaced "master/slave"
with more appropriate terms. Inspired by and following on to Wolfram's
series to fix drivers/i2c/[1], fix the terminology for users of
I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
in the
I2C v7, SMBus 3.2, and I3C specifications have replaced "master/slave"
with more appropriate terms. Inspired by and following on to Wolfram's
series to fix drivers/i2c/[1], fix the terminology for users of
I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
in the
I2C v7, SMBus 3.2, and I3C specifications have replaced "master/slave"
with more appropriate terms. Inspired by and following on to Wolfram's series
to fix drivers/i2c[1], fix the terminology where I had a role to play, now that
the approved verbiage exists in the specification.
Compile tested,
I2C v7, SMBus 3.2, and I3C specifications have replaced "master/slave"
with more appropriate terms. Inspired by and following on to Wolfram's
series to fix drivers/i2c/[1], fix the terminology for users of
I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
in the
I2C v7, SMBus 3.2, and I3C specifications have replaced "master/slave"
with more appropriate terms. Inspired by and following on to Wolfram's
series to fix drivers/i2c/[1], fix the terminology for users of
I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
in the
I2C v7, SMBus 3.2, and I3C specifications have replaced "master/slave"
with more appropriate terms. Inspired by and following on to Wolfram's
series to fix drivers/i2c/[1], fix the terminology for users of
I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
in the
On 3/29/2024 10:38 AM, Andi Shyti wrote:
> Hi,
>
>
with more appropriate terms. Inspired by and following on to Wolfram's
series to fix drivers/i2c/[1], fix the terminology for users of
I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
in the
I2C v7, SMBus 3.2, and I3C specifications have replaced "master/slave"
with more appropriate terms. Inspired by and following on to Wolfram's
series to fix drivers/i2c/[1], fix the terminology for users of
I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
in the
I2C v7, SMBus 3.2, and I3C specifications have replaced "master/slave"
with more appropriate terms. Inspired by and following on to Wolfram's
series to fix drivers/i2c/[1], fix the terminology for users of the
I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
in the
I2C v7, SMBus 3.2, and I3C specifications have replaced "master/slave"
with more appropriate terms. Inspired by and following on to Wolfram's
series to fix drivers/i2c/[1], fix the terminology for users of
I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
in the
I2C v7, SMBus 3.2, and I3C specifications have replaced "master/slave"
with more appropriate terms. Inspired by and following on to Wolfram's
series to fix drivers/i2c/[1], fix the terminology for users of
I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
in the
I2C v7, SMBus 3.2, and I3C specifications have replaced "master/slave"
with more appropriate terms. Inspired by and following on to Wolfram's
series to fix drivers/i2c/[1], fix the terminology for users of
I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
in the
I2C v7, SMBus 3.2, and I3C specifications have replaced "master/slave"
with more appropriate terms. Inspired by and following on to Wolfram's
series to fix drivers/i2c/[1], fix the terminology for users of
I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
in the
I2C v7, SMBus 3.2, and I3C specifications have replaced "master/slave"
with more appropriate terms. Inspired by and following on to Wolfram's
series to fix drivers/i2c/[1], fix the terminology for users of
I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
in the
I2C v7, SMBus 3.2, and I3C specifications have replaced "master/slave"
with more appropriate terms. Inspired by and following on to Wolfram's
series to fix drivers/i2c[1], fix the terminology for users of
I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
in the specification.
This is a reminder that the membership renewal period ends in 2 days,
and elections will start after that. Please register as an X.Org
Foundation member to be able to vote in the upcoming elections. Thanks!
-Ricardo Garcia, on behalf of the X.Org elections committee.
On Tue, 2024-03-26 at 11:42
34 matches
Mail list logo
