https://bugzilla.kernel.org/show_bug.cgi?id=205675
serbsersntr (jesirok...@btsese.com) changed:
What|Removed |Added
CC||jesirok...@btsese.co
On 2020-11-25 04:50, Christian König wrote:
> Am 25.11.20 um 04:17 schrieb Luben Tuikov:
>> The job timeout handler now returns status
>> indicating back to the DRM layer whether the job
>> was successfully cancelled or whether more time
>> should be given to the job to complete.
>>
>> Signed-off-b
Hi Nikhil,
On 19/11/2020 18:01, Nikhil Devshatwar wrote:
> Remove the old code to iterate over the bridge chain, as this is
> already done by the framework.
> The bridge state should have the negotiated bus format and flags.
> Use these from the bridge's state.
> If the bridge does not support for
https://bugzilla.kernel.org/show_bug.cgi?id=210123
Zack Rusin (za...@vmware.com) changed:
What|Removed |Added
CC||za...@vmware.com
--- Comm
On 2020-11-25 1:57 p.m., Christian König wrote:
Well thinking more about this, it seems to be a another really good
argument why mapping pages from DMA-bufs into application address space
directly is a very bad idea :)
Apologies for going off on a tangent here...
Since allowing userspace mm
On 2020-11-25 04:55, Christian König wrote:
> Am 25.11.20 um 04:17 schrieb Luben Tuikov:
>> Introduce a macro DRM_THREAD_NAME_LEN
>> and use that to define ring name size,
>> instead of hardcoding it to 16.
>>
>> Signed-off-by: Luben Tuikov
>> ---
>> drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 2
On Wed, Nov 25, 2020 at 5:56 PM Michel Dänzer wrote:
>
> On 2020-11-25 1:57 p.m., Christian König wrote:
> >
> > Well thinking more about this, it seems to be a another really good
> > argument why mapping pages from DMA-bufs into application address space
> > directly is a very bad idea :)
>
> Ap
The only user of tlb_flush_leaf is a particularly hairy corner of the
Arm short-descriptor code, which wants a synchronous invalidation to
minimise the races inherent in trying to split a large page mapping.
This is already far enough into "here be dragons" territory that no
sensible caller should
https://bugzilla.kernel.org/show_bug.cgi?id=205675
--- Comment #41 from serbsersntr (jesirok...@btsese.com) ---
https://gitlab.com/gitlab-org/gitlab/-/issues/288077
https://gitlab.com/gitlab-org/gitlab/-/issues/288078
https://gitlab.com/gitlab-org/gitlab/-/issues/288079
https://gitlab.com/gitlab-o
On 11/25/20 4:04 AM, Daniel Vetter wrote:
On Tue, Nov 24, 2020 at 11:27 PM Andrey Grodzovsky
wrote:
On 11/24/20 9:49 AM, Daniel Vetter wrote:
On Sat, Nov 21, 2020 at 12:21:20AM -0500, Andrey Grodzovsky wrote:
Avoids NULL ptr due to kobj->sd being unset on device removal.
Signed-off-by: And
On 11/25/20 5:41 AM, Daniel Vetter wrote:
On Tue, Nov 24, 2020 at 10:51:57AM -0500, Andrey Grodzovsky wrote:
On 11/24/20 9:53 AM, Daniel Vetter wrote:
On Sat, Nov 21, 2020 at 12:21:18AM -0500, Andrey Grodzovsky wrote:
Some of the stuff in amdgpu_device_fini such as HW interrupts
disable and
Hi,
On Wed, 25 Nov 2020 at 18:06, Jason Gunthorpe wrote:
> On Wed, Nov 25, 2020 at 05:28:32PM +0100, Daniel Vetter wrote:
> > Apologies again, this shouldn't have been included. But at least I
> > have an idea now why this patch somehow was included in the git
> > send-email. Lovely interface :-/
On 2020-11-25 17:29, Robin Murphy wrote:
The only user of tlb_flush_leaf is a particularly hairy corner of the
Arm short-descriptor code, which wants a synchronous invalidation to
minimise the races inherent in trying to split a large page mapping.
This is already far enough into "here be dragons
On Tue, 2020-11-03 at 14:49 -0500, Jeremy Cline wrote:
> Rather than protecting the nouveau_drm clients list with the lock within
> the "client" nouveau_cli, add a dedicated lock to serialize access to
> the list. This is both clearer and necessary to avoid lockdep being
> upset with us when we nee
On Tue, 2020-11-03 at 14:49 -0500, Jeremy Cline wrote:
> The postclose handler can run after the device has been removed (or the
> driver has been unbound) since userspace clients are free to hold the
> file open the file as long as they want. Because the device removal
^
typo
> -Original Message-
> From: Jason Gunthorpe
> Sent: Wednesday, November 25, 2020 4:15 AM
> To: Daniel Vetter
> Cc: Xiong, Jianxin ; Leon Romanovsky
> ; linux-r...@vger.kernel.org; dri-
> de...@lists.freedesktop.org; Doug Ledford ; Vetter,
> Daniel ; Christian Koenig
>
> Subject: Re: [
On 11/25/20 11:36 AM, Daniel Vetter wrote:
On Wed, Nov 25, 2020 at 01:57:40PM +0100, Christian König wrote:
Am 25.11.20 um 11:40 schrieb Daniel Vetter:
On Tue, Nov 24, 2020 at 05:44:07PM +0100, Christian König wrote:
Am 24.11.20 um 17:22 schrieb Andrey Grodzovsky:
On 11/24/20 2:41 AM, Christ
Quoting Ville Syrjälä (2020-10-30 14:43:46)
> On Fri, Oct 30, 2020 at 02:19:45PM +, Chris Wilson wrote:
> > Quoting Ville Syrjala (2020-10-22 20:42:56)
> > > From: Ville Syrjälä
> > >
> > > The new >8k CEA modes have dotclocks reaching 5.94 GHz, which
> > > means our clock*1000 will now overf
On Wed, Nov 25, 2020 at 01:37:06PM -0500, Lyude Paul wrote:
> On Tue, 2020-11-03 at 14:49 -0500, Jeremy Cline wrote:
> > Rather than protecting the nouveau_drm clients list with the lock within
> > the "client" nouveau_cli, add a dedicated lock to serialize access to
> > the list. This is both clea
This series fixes a number of use-after-frees in nouveau's postclose()
handler. It was discovered by pointing IGT's core_hotunplug tests at a
nouveau device, but the steps to reproduce it are simple:
1. Open the device file
2. Unbind the driver or remove the device
3. Close the file opened in step
Nouveau does not currently support hot-unplugging, but it still makes
sense to switch from drm_dev_unregister() to drm_dev_unplug().
drm_dev_unplug() calls drm_dev_unregister() after marking the device as
unplugged, but only after any device critical sections are finished.
Since nouveau isn't usin
Rather than protecting the nouveau_drm clients list with the lock within
the "client" nouveau_cli, add a dedicated lock to serialize access to
the list. This is both clearer and necessary to avoid lockdep being
upset with us when we need to iterate through all the clients in the
list and potentiall
The postclose handler can run after the device has been removed (or the
driver has been unbound) since userspace clients are free to hold the
file open as long as they want. Because the device removal callback
frees the entire nouveau_drm structure, any reference to it in the
postclose handler will
> -Original Message-
> From: Nautiyal, Ankit K
> Sent: Sunday, November 1, 2020 3:37 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; Shankar, Uma ;
> Kulkarni, Vandita ; ville.syrj...@linux.intel.com;
> Sharma, Swati2
> Subject: [PATCH v2 12/13] drm/i915
> -Original Message-
> From: Nautiyal, Ankit K
> Sent: Sunday, November 1, 2020 3:37 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; Shankar, Uma ;
> Kulkarni, Vandita ; ville.syrj...@linux.intel.com;
> Sharma, Swati2
> Subject: [PATCH v2 13/13] drm/i915
On Tue, Nov 24, 2020 at 1:15 PM Colin King wrote:
> From: Colin Ian King
>
> The masking of val with ~MCDE_CRX1_CLKSEL_MASK is currently being
> ignored because there seems to be a missing bitwise-or of val in the
> following statement. Fix this by replacing the assignment of val
> with a bitwi
On Tue, Nov 24, 2020 at 11:05:35PM -0800, James Bottomley wrote:
> Now, what we have seems to be about 6 cases (at least what's been shown
> in this thread) where a missing break would cause potentially user
> visible issues. That means the value of this isn't zero, but it's not
> a no-brainer mas
On Wed, Nov 25, 2020 at 06:24:13PM +, Robin Murphy wrote:
> On 2020-11-25 17:29, Robin Murphy wrote:
> >The only user of tlb_flush_leaf is a particularly hairy corner of the
> >Arm short-descriptor code, which wants a synchronous invalidation to
> >minimise the races inherent in trying to split
https://bugzilla.kernel.org/show_bug.cgi?id=210123
--- Comment #6 from Stefan Mayr (stefan+ker...@mayr-stefan.de) ---
Kernel 5.1.16 also showed the error message after 2 days.
So this seems to be triggered by changes between 5.0.13 and 5.1.16. I'm out of
SUSE Kernels to narrow it down even more.
On 2020-11-25 05:10, Christian König wrote:
> Am 25.11.20 um 04:17 schrieb Luben Tuikov:
>> Add a "done" list to which all completed jobs are added
>> to be freed. The drm_sched_job_done() callback is the
>> producer of jobs to this list.
>>
>> Add a "done" thread which consumes from the done list
On 2020-11-25 06:09, Steven Price wrote:
> On 25/11/2020 03:17, Luben Tuikov wrote:
>> Add a "done" list to which all completed jobs are added
>> to be freed. The drm_sched_job_done() callback is the
>> producer of jobs to this list.
>>
>> Add a "done" thread which consumes from the done list
>> an
> -Original Message-
> From: Jason Gunthorpe
> Sent: Wednesday, November 25, 2020 4:00 PM
> To: Xiong, Jianxin
> Cc: Daniel Vetter ; Leon Romanovsky ;
> linux-r...@vger.kernel.org; dri-devel@lists.freedesktop.org;
> Doug Ledford ; Vetter, Daniel ;
> Christian Koenig
> Subject: Re: [PAT
On Thu, 17 Sept 2020 at 03:19, Lyude Paul wrote:
>
> Currently, every different type of backlight hook that i915 supports is
> pretty straight forward - you have a backlight, probably through PWM
> (but maybe DPCD), with a single set of platform-specific hooks that are
> used for controlling it.
>
Hi Dave and Daniel,
Please notice that commit eb0104ee498d ("drm/i915/gt: Track signaled
breadcrumbs outside of the breadcrumb spinlock")
is just a dependency of commit 2e6ce8313a53 ("drm/i915/gt: Don't cancel the
interrupt shadow too early").
Here goes drm-intel-fixes-2020-11-25:
- Fix Perf/OA
https://bugzilla.kernel.org/show_bug.cgi?id=210369
Bug ID: 210369
Summary: amdgpu fails to resume from suspend
Product: Drivers
Version: 2.5
Kernel Version: 5.9.10-050910-generic #202011221708
Hardware: All
OS: Linux
https://bugzilla.kernel.org/show_bug.cgi?id=210369
--- Comment #1 from sevenever (sevene...@gmail.com) ---
lspci output:
00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Renoir Root Complex
00:00.2 IOMMU: Advanced Micro Devices, Inc. [AMD] Renoir IOMMU
00:01.0 Host bridge: Advanced Micro De
On Mon, Nov 23, 2020 at 10:51:25AM +0100, Daniel Vetter wrote:
> On Fri, Nov 20, 2020 at 4:23 PM Matti Hamalainen wrote:
> >
> > Commit 03e0d26fcf79 ("drm/nouveau: slowpath for pushbuf ioctl") included
> > a logic-bug which results in the relocations not actually getting
> > applied at all as the
This is v6 version to test with IGT
https://patchwork.freedesktop.org/series/82987/
This v6 has added a new patch to series to avoid a crash reported on Chrome-OS
and has addressed the few cosmetics review comments from Ram.
It has been also tested manually with above IGT series.
[PATCH v6 12/18]
When crtc state need_modeset is true it is not necessary
it is going to be a real modeset, it can turns to be a
fastset instead of modeset.
This turns content protection property to be DESIRED and hdcp
update_pipe left with property to be in DESIRED state but
actual hdcp->value was ENABLED.
This i
Get DRM connector reference count while scheduling a prop work
to avoid any possible destroy of DRM connector when it is in
DRM_CONNECTOR_REGISTERED state.
Fixes: a6597faa2d59 ("drm/i915: Protect workers against disappearing
connectors")
Cc: Sean Paul
Cc: Ramalingam C
Reviewed-by: Uma Shankar
Handle CP_IRQ in DEVICE_SERVICE_IRQ_VECTOR_ESI0
It requires to call intel_hdcp_handle_cp_irq() in case
of CP_IRQ is triggered by a sink in DP-MST topology.
Cc: "Ville Syrjälä"
Cc: Ramalingam C
Reviewed-by: Uma Shankar
Reviewed-by: Ramalingam C
Tested-by: Karthik B S
Signed-off-by: Anshuman Gu
There can be situation when DP MST connector is created without
mst modeset being done, in those cases connector->encoder will be
NULL. MST connector->encoder initializes after modeset.
Don't enable HDCP in such cases to prevent any crash.
Cc: Ramalingam C
Cc: Juston Li
Signed-off-by: Anshuman G
DP MST stream encryption status requires time of a link frame
in order to change its status, but as there were some HDCP
encryption timeout observed earlier, it is safer to use
ENCRYPT_STATUS_CHANGE_TIMEOUT_MS timeout for stream status too,
it requires to move the macro to a header.
It will be used
Gen12 has H/W delta with respect to HDCP{1.x,2.x} display engine
instances lies in Transcoder instead of DDI as in Gen11.
This requires hdcp driver to use mst_master_transcoder for link
authentication and stream transcoder for stream encryption
separately.
This will be used for both HDCP 1.4 and
Both HDCP_{1.x,2.x} requires to select/deselect Multistream HDCP bit
in TRANS_DDI_FUNC_CTL in order to enable/disable stream HDCP
encryption over DP MST Transport Link.
HDCP 1.4 stream encryption requires to validate the stream encryption
status in HDCP_STATUS_{TRANSCODER,PORT} register driving th
Enable HDCP 1.4 over DP MST for Gen12.
v2:
- Enable HDCP for <= Gen12 platforms. [Ram]
Cc: Ramalingam C
Tested-by: Karthik B S
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_dp_mst.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/dr
Pass dig_port as an argument to intel_hdcp_init()
and intel_hdcp2_init().
This will be required for HDCP 2.2 stream encryption.
Cc: Ramalingam C
Reviewed-by: Uma Shankar
Reviewed-by: Ramalingam C
Tested-by: Karthik B S
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_dp_h
hdcp_port_data is specific to a port on which HDCP
encryption is getting enabled, so encapsulate it to
intel_digital_port.
This will be required to enable HDCP 2.2 stream encryption.
v2:
- 's/port_data/hdcp_port_data'. [Ram]
Cc: Ramalingam C
Reviewed-by: Uma Shankar
Reviewed-by: Ramalingam C
T
Enable HDCP 1.4 DP MST stream encryption.
Enable stream encryption once encryption is enabled on
the DP transport driving the link for each stream which
has requested encryption.
Disable stream encryption for each stream that no longer
requires encryption before disabling HDCP encryption on
the l
Fix the size of WIRED_REPEATER_AUTH_STREAM_REQ cmd buffer size.
It is based upon the actual number of MST streams and size
of wired_cmd_repeater_auth_stream_req_in.
Excluding the size of hdcp_cmd_header.
v2:
- hdcp_cmd_header size annotation nitpick. [Tomas]
Cc: Tomas Winkler
Cc: Ramalingam C
A
Let's define Maximum MST content streams up to four
generically which can be supported by modern display
controllers.
Cc: Sean Paul
Cc: Ramalingam C
Acked-by: Maarten Lankhorst
Reviewed-by: Uma Shankar
Reviewed-by: Ramalingam C
Tested-by: Karthik B S
Signed-off-by: Anshuman Gupta
---
inclu
Add HDCP 2.2 DP MST HDCP2_STREAM_STATUS
and HDCP2_AUTH_STREAM register in i915_reg header.
Cc: Ramalingam C
Reviewed-by: Uma Shankar
Reviewed-by: Ramalingam C
Tested-by: Karthik B S
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/i915_reg.h | 30 ++
1 file
This requires for HDCP 2.2 MST check link.
As for DP/HDMI shims check_2_2_link retrieves the connector
from dig_port, this is not sufficient or DP MST connector,
there can be multiple DP MST topology connector associated
with same dig_port.
Cc: Ramalingam C
Reviewed-by: Uma Shankar
Reviewed-by:
Add support for multiple mst stream in hdcp port data
which will be used by RepeaterAuthStreamManage msg and
HDCP 2.2 security f/w for m' validation.
Security f/w doesn't have any provision to mark the
stream_type for each stream separately, it just take
single input of stream_type while authentic
Add support for HDCP 2.2 DP MST shim callback.
This adds existing DP HDCP shim callback for Link Authentication
and Encryption and HDCP 2.2 stream encryption
callback.
v2:
- Added a WARN_ON() instead of drm_err. [Uma]
- Cosmetic changes. [Uma]
v3:
- 's/port_data/hdcp_port_data' [Ram]
- skip redund
Enable HDCP 2.2 over DP MST.
Authenticate and enable port encryption only once for
an active HDCP 2.2 session, once port is authenticated
and encrypted enable encryption for each stream that
requires encryption on this port.
Similarly disable the stream encryption for each encrypted
stream, once a
101 - 156 of 156 matches
Mail list logo
