The ret value might be -EBUSY, caller will think lru lock is still
locked but actually NOT. So return -ENOSPC instead. Otherwise we hit
list corruption.
ttm_bo_cleanup_refs might fail too if BO is not idle. If we return 0,
caller(ttm_tt_populate -> ttm_global_swapout ->ttm_device_swapout) will
be
Use the helper macro SET_RUNTIME_PM_OPS() instead of the verbose
operators ".runtime_suspend/.runtime_resume", because the
SET_RUNTIME_PM_OPS() is a nice helper macro that could be brought
in to make code a little more concise.
Signed-off-by: Cai Huoqing
---
v1->v2: *Remove "#ifdef CONFIG_PM"
The mxsfb->crtc.funcs may already be NULL when unloading the driver,
in which case calling mxsfb_irq_disable() via drm_irq_uninstall() from
mxsfb_unload() leads to NULL pointer dereference.
Since all we care about is masking the IRQ and mxsfb->base is still
valid, just use that to clear and mask
Move detach implementation from sn65dsi83_remove() to dedicated
.detach callback. There is no functional change to the code, but
that detach is now in the correct location.
Signed-off-by: Marek Vasut
Cc: Jagan Teki
Cc: Laurent Pinchart
Cc: Linus Walleij
Cc: Robert Foss
Cc: Sam Ravnborg
Cc:
In rare cases, the bridge may not start up correctly, which usually
leads to no display output. In case this happens, warn about it in
the kernel log.
Signed-off-by: Marek Vasut
Cc: Jagan Teki
Cc: Laurent Pinchart
Cc: Linus Walleij
Cc: Robert Foss
Cc: Sam Ravnborg
Cc:
https://bugzilla.kernel.org/show_bug.cgi?id=211277
--- Comment #53 from Anthony Rabbito (ted...@gmail.com) ---
Thanks for chiming in James! Few things I've observed since adding 'pci=noats'
the graphic artifacts seem to happen way less. I did observe one lockup which
required me to hard shut down
tree: git://people.freedesktop.org/~airlied/linux.git
i915-display-struct-refactor
head: e183b125871ffdd77b6de15a963e6fc8a47173c9
commit: 5b99cab055595d1b12d7425e560b5a9fcd15c9a3 [22/25] drm/i915/display: move
dpll struct into display
config: x86_64-randconfig-a016-20210906 (attached
https://bugzilla.kernel.org/show_bug.cgi?id=211277
--- Comment #52 from James Zhu (jam...@amd.com) ---
Created attachment 298691
--> https://bugzilla.kernel.org/attachment.cgi?id=298691=edit
Fix for S3 hung issue
Hi Jerome and kolAflash,
I think iommu device init is put at wrong place during
[AMD Official Use Only]
It is the internal staging drm-next.
-Original Message-
From: Koenig, Christian
Sent: 2021年9月6日 19:26
To: Pan, Xinhui ; amd-...@lists.freedesktop.org
Cc: Deucher, Alexander ; che...@uniontech.com;
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v2 1/2]
On Mon, Sep 6, 2021 at 12:58 PM Amit Pundir wrote:
>
> On Mon, 6 Sept 2021 at 21:54, Rob Clark wrote:
> >
> > On Mon, Sep 6, 2021 at 1:02 AM Amit Pundir wrote:
> > >
> > > On Sat, 4 Sept 2021 at 01:55, Rob Clark wrote:
> > > >
> > > > On Fri, Sep 3, 2021 at 12:39 PM John Stultz
> > > >
On Tue, 7 Sept 2021 at 10:28, Karol Herbst wrote:
>
> On Tue, Sep 7, 2021 at 1:28 AM Ben Skeggs wrote:
> >
> > On Tue, 7 Sept 2021 at 09:17, Karol Herbst wrote:
> > >
> > > ."
> > >
> > >
> > > On Mon, Sep 6, 2021 at 2:56 AM Ben Skeggs wrote:
> > > >
> > > > From: Ben Skeggs
> > > >
> > > >
On Tue, Sep 7, 2021 at 1:28 AM Ben Skeggs wrote:
>
> On Tue, 7 Sept 2021 at 09:17, Karol Herbst wrote:
> >
> > ."
> >
> >
> > On Mon, Sep 6, 2021 at 2:56 AM Ben Skeggs wrote:
> > >
> > > From: Ben Skeggs
> > >
> > > We don't currently have any kind of real acceleration on Ampere GPUs,
> > >
On Mon, Sep 6, 2021 at 2:56 AM Ben Skeggs wrote:
>
> From: Ben Skeggs
>
> Prevent NVD core channel error code 67 occuring and hanging display,
> managed to reproduce on GA102 while testing suspend/resume scenarios.
>
> Required extension of earlier commit to fix interactions with EFI.
>
Hi, Nancy:
Nancy.Lin 於 2021年9月6日 週一 下午3:15寫道：
>
> Add vdosys1 RDMA definition.
>
> Signed-off-by: Nancy.Lin
> ---
> .../display/mediatek/mediatek,mdp-rdma.yaml | 77 +++
> 1 file changed, 77 insertions(+)
> create mode 100644
>
On Tue, 7 Sept 2021 at 09:17, Karol Herbst wrote:
>
> ."
>
>
> On Mon, Sep 6, 2021 at 2:56 AM Ben Skeggs wrote:
> >
> > From: Ben Skeggs
> >
> > We don't currently have any kind of real acceleration on Ampere GPUs,
> > but the TTM memcpy() fallback paths aren't really designed to handle
> >
."
On Mon, Sep 6, 2021 at 2:56 AM Ben Skeggs wrote:
>
> From: Ben Skeggs
>
> We don't currently have any kind of real acceleration on Ampere GPUs,
> but the TTM memcpy() fallback paths aren't really designed to handle
> copies between different devices, such as on Optimus systems, and
> result
On Mon, Sep 6, 2021 at 1:50 PM Rob Clark wrote:
>
> On Mon, Sep 6, 2021 at 12:58 PM Amit Pundir wrote:
> >
> > On Mon, 6 Sept 2021 at 21:54, Rob Clark wrote:
> > >
> > > On Mon, Sep 6, 2021 at 1:02 AM Amit Pundir wrote:
> > > >
> > > > On Sat, 4 Sept 2021 at 01:55, Rob Clark wrote:
> > > > >
> -Original Message-
> From: sebast...@sebastianwick.net
> Sent: Monday, August 16, 2021 7:07 PM
> To: Harry Wentland
> Cc: Brian Starkey ; Sharma, Shashank
> ; amd-...@lists.freedesktop.org; dri-
> de...@lists.freedesktop.org; ppaala...@gmail.com; mca...@google.com;
>
Enable plane gamma feature in check callbacks. Decide
based on the user input.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/display/skl_universal_plane.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c
Extract the LUT and program plane gamma registers.
Enabled multi segmented lut as well.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_color.c | 89 ++
drivers/gpu/drm/i915/i915_reg.h| 9 ++-
2 files changed, 94 insertions(+), 4 deletions(-)
Add macros to define Plane Gamma registers
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/i915_reg.h | 73 +
1 file changed, 73 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index ceee500e64d7..fc4f8b430518
Add Plane Gamma Lut as a blob property.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/drm_atomic_state_helper.c | 3 +++
drivers/gpu/drm/drm_atomic_uapi.c | 10 ++
drivers/gpu/drm/drm_color_mgmt.c | 18 ++
include/drm/drm_plane.h | 14
Define the structure with XE_LPD gamma lut ranges. HDR and SDR planes
have different capabilities, implemented respective structure for
the HDR planes. Degamma and GAMMA has same Lut caps for SDR planes,
extended the same.
Initialize the mode range caps as well.
Signed-off-by: Uma Shankar
Add Plane Gamma Mode as a blob property. This is an enum property
with values as blob_id's and exposes the various gamma modes
supported and the lut ranges. Getting the blob id in userspace,
user can get the mode supported and also the range of gamma mode
supported with number of lut coefficients.
Implement plane CSC for ICL+
Signed-off-by: Uma Shankar
---
.../gpu/drm/i915/display/intel_atomic_plane.c | 5 +-
drivers/gpu/drm/i915/display/intel_color.c| 82 +++
.../drm/i915/display/skl_universal_plane.c| 4 +
drivers/gpu/drm/i915/i915_reg.h | 1 +
Define Register macros for plane CSC.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/i915_reg.h | 43 +
1 file changed, 43 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 0c36a330734f..20c1b8ddded8 100644
Add a DRM helper to attach ctm property.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/drm_color_mgmt.c | 10 ++
include/drm/drm_plane.h | 1 +
2 files changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/drm_color_mgmt.c b/drivers/gpu/drm/drm_color_mgmt.c
index
Add a blob property for plane CSC usage.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/drm_atomic_state_helper.c | 3 +++
drivers/gpu/drm/drm_atomic_uapi.c | 10 ++
drivers/gpu/drm/drm_color_mgmt.c | 11 +++
include/drm/drm_plane.h | 15
Load plane color luts as part of atomic plane updates.
This will be done only if the plane color luts are changed.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_atomic_plane.c | 3 +++
drivers/gpu/drm/i915/display/intel_atomic_plane.h | 1 +
Initialize plane color features for XE_LPD.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_atomic_plane.h | 1 +
drivers/gpu/drm/i915/display/skl_universal_plane.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.h
Extended glk_plane_color_ctl to have plane color checks. This helps
enabling the degamma or gamma block based on user inputs.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/display/skl_universal_plane.c | 5 +
1 file changed, 5 insertions(+)
diff --git
Extract the LUT and program plane degamma registers.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_color.c | 116 +
drivers/gpu/drm/i915/i915_reg.h| 2 +
2 files changed, 118 insertions(+)
diff --git
Enable and initialize plane color features.
Also initialize the color features of HDR planes.
Signed-off-by: Uma Shankar
Signed-off-by: Bhanuprakash Modem
---
drivers/gpu/drm/i915/display/intel_color.c | 22 +-
drivers/gpu/drm/i915/display/intel_color.h | 2 ++
Add the Color capabilities of SDR planes.
Signed-off-by: Uma Shankar
Signed-off-by: Bhanuprakash Modem
---
drivers/gpu/drm/i915/display/intel_color.c | 67 --
1 file changed, 63 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
Define the structure with XE_LPD degamma lut ranges. HDR and SDR
planes have different capabilities, implemented respective
structure for the HDR planes.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_color.c | 52 ++
1 file changed, 52 insertions(+)
diff
Add macros to define Plane Degamma registers
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/i915_reg.h | 52 +
1 file changed, 52 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 313432ed6196..919982c878ac
Add Plane Degamma Lut as a blob property. User will calculate
the lut values, create the blob and send it to driver using
this property. Lut calculation will be based on the gamma mode
chosen out of the gamma mode exposed.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/drm_atomic_state_helper.c
Add Plane Degamma Mode as an enum property. Create a helper
function for all plane color management features.
This is an enum property with values as blob_id's and exposes
the various gamma modes supported and the lut ranges. Getting
the blob id in userspace, user can get the mode supported and
Existing LUT precision structure is having only 16 bit
precision. This is not enough for upcoming enhanced hardwares
and advance usecases like HDR processing. Hence added a new
structure with 32 bit precision values.
This also defines a new structure to define color lut ranges,
along with related
This is how a typical display color hardware pipeline looks like:
+---+
|RAM|
| +--++-++-+ |
| | FB 1 || FB 2 || FB N| |
| +--++-++-+
This is a RFC proposal for plane color hardware blocks.
It exposes the property interface to userspace and calls
out the details or interfaces created and the intended
purpose.
Credits: Ville Syrjälä
Signed-off-by: Uma Shankar
---
Documentation/gpu/rfc/drm_color_pipeline.rst | 167
On Mon, Sep 6, 2021 at 12:58 PM Amit Pundir wrote:
>
> On Mon, 6 Sept 2021 at 21:54, Rob Clark wrote:
> >
> > On Mon, Sep 6, 2021 at 1:02 AM Amit Pundir wrote:
> > >
> > > On Sat, 4 Sept 2021 at 01:55, Rob Clark wrote:
> > > >
> > > > On Fri, Sep 3, 2021 at 12:39 PM John Stultz
> > > >
Hi Markus,
On Mon, Sep 06, 2021 at 09:35:29PM +0200, Markus Schneider-Pargmann wrote:
> This patch adds a DisplayPort driver for the Mediatek mt8195 SoC.
>
> It supports both functional units on the mt8195, the embedded
> DisplayPort as well as the external DisplayPort units. It offers
>
Hi Markus,
On Mon, Sep 06, 2021 at 09:35:27PM +0200, Markus Schneider-Pargmann wrote:
> Similar to HDMI, DP uses audio infoframes as well which are structured
> very similar to the HDMI ones.
>
> This patch adds a helper function to pack the HDMI audio infoframe for
> DP, called
The downstream driver models this PLL lock check as an if-elseif-else.
The only way to reach the else case where pll_locked=true [1] is by
succeeding both readl_poll_timeout_atomic calls (which return zero on
success) in the if _and_ elseif condition. Hence both the "lock" and
"ready" bit need to
div_u64_rem provides the result of the divison and additonally the
remainder; don't use this function to solely calculate the remainder
while calculating the division again with div_u64.
A similar improvement was applied earlier to the 10nm pll in
5c191fef4ce2 ("drm/msm/dsi_pll_10nm: Fix dividing
Hi Markus,
On Mon, Sep 06, 2021 at 09:35:26PM +0200, Markus Schneider-Pargmann wrote:
> This patch adds two helper functions that extract the frequency and word
> length from a struct cea_sad.
>
> For these helper functions new defines are added that help translate the
> 'freq' and 'byte2'
Hi Markus,
On Mon, Sep 06, 2021 at 09:35:24PM +0200, Markus Schneider-Pargmann wrote:
> DP_INTF is similar to the actual dpi. They differ in some points
> regarding registers and what needs to be set but the function blocks
> itself are similar in design.
>
> Signed-off-by: Markus
On Mon, 6 Sept 2021 at 21:54, Rob Clark wrote:
>
> On Mon, Sep 6, 2021 at 1:02 AM Amit Pundir wrote:
> >
> > On Sat, 4 Sept 2021 at 01:55, Rob Clark wrote:
> > >
> > > On Fri, Sep 3, 2021 at 12:39 PM John Stultz
> > > wrote:
> > > >
> > > > On Thu, Jul 29, 2021 at 1:49 PM Rob Clark wrote:
>
This patch adds a DisplayPort driver for the Mediatek mt8195 SoC.
It supports both functional units on the mt8195, the embedded
DisplayPort as well as the external DisplayPort units. It offers
hot-plug-detection, audio up to 8 channels, and DisplayPort 1.4 with up
to 4 lanes.
This driver is
This controller is present on different mediatek hardware. Currently
mt8195 and mt8395 have this controller without a functional difference,
so only one compatible is added.
The controller can be in two forms, for a normal display port and for
embedded display port.
Signed-off-by: Markus
DP_INTF is similar to the actual dpi. They differ in some points
regarding registers and what needs to be set but the function blocks
itself are similar in design.
Signed-off-by: Markus Schneider-Pargmann
---
.../display/mediatek/mediatek,dpi.yaml| 43 ---
1 file
dpintf is the displayport interface hardware unit. This unit is similar
to dpi and can reuse most of the code.
This patch adds support for mt8195-dpintf to this dpi driver. Main
differences are:
- Some features/functional components are not available for dpintf
which are now excluded from
This patch adds two helper functions that extract the frequency and word
length from a struct cea_sad.
For these helper functions new defines are added that help translate the
'freq' and 'byte2' fields into real numbers.
Signed-off-by: Markus Schneider-Pargmann
---
drivers/gpu/drm/drm_edid.c |
Similar to HDMI, DP uses audio infoframes as well which are structured
very similar to the HDMI ones.
This patch adds a helper function to pack the HDMI audio infoframe for
DP, called hdmi_audio_infoframe_pack_for_dp().
hdmi_audio_infoframe_pack_only() is split into two parts. One of them
packs
Hi everyone,
this series is built around the DisplayPort driver. The dpi/dpintf driver and
the added helper functions are required for the DisplayPort driver to work.
It is version 1 of the patch series following the RFC version:
On Alderlake-P for all CCS modifiers the main surface pitch must be
either 8 Y-tile width or the multiple of 16 Y-tile widths. The CCS
surface pitch must be rounded up to power-of-two.
Adjust the modifier descriptions accordingly.
Cc: Nanley G Chery
Cc: Juha-Pekka Heikkila
Cc:
> I'll try to extract the "executive summary" from this, you tell me if I
> got it right.
>
> So using or not using dynamic debug for DRM debug ends up being about
> shifting the cost between kernel binary size (data section grows by each
> pr_debug call site) and runtime conditionals?
Yes.
>
On Mon, Sep 6, 2021 at 6:26 AM Tvrtko Ursulin <
tvrtko.ursu...@linux.intel.com> wrote:
>
>
> On 03/09/2021 20:22, jim.cro...@gmail.com wrote:
> > On Fri, Sep 3, 2021 at 5:07 AM Tvrtko Ursulin
> > wrote:
> >>
> >>
> >> On 31/08/2021 21:21, Jim Cromie wrote:
> >>> The gvt component of this driver
On 05/09/2021 13:27, Daniel Stone wrote:
Since there's a lot of confusion around this, document both the rules
and the best practice around negotiating, allocating, importing, and
using buffers when crossing context/process/device/subsystem boundaries.
This ties up all of dmabuf, formats and
We really only need memcpy restore for objects that affect the
operability of the migrate context. That is, primarily the page-table
objects of the migrate VM.
Add an object flag, I915_BO_ALLOC_PM_EARLY for objects that need early
restores using memcpy and a way to assign LMEM page-table object
Just evict unpinned objects to system. For pinned LMEM objects,
make a backup system object and blit the contents to that.
Backup is performed in three steps,
1: Opportunistically evict evictable objects using the gpu blitter.
2: After gt idle, evict evictable objects using the gpu blitter. This
Pinned contexts, like the migrate contexts need reset after resume
since their context image may have been lost. Also the GuC needs to
register pinned contexts.
Add a list to struct intel_engine_cs where we add all pinned contexts on
creation, and traverse that list at resume time to reset the
Pinned context images are now reset during resume. Don't back them up,
and assuming that rings can be assumed empty at suspend, don't back them
up either.
Introduce a new object flag, I915_BO_ALLOC_PM_VOLATILE meaning that an
object is allowed to lose its content on suspend.
Signed-off-by:
An upcoming common pattern is to traverse the region object list and
perform certain actions on all objects in a region. It's a little tricky
to get the list locking right, in particular since a gem object may
change region unless it's pinned or the object lock is held.
Define a function that
When backing up or restoring contents of pinned objects at suspend /
resume time we need to allocate a new object as the backup. Add a function
to facilitate copies between the two. Some data needs to be copied before
the migration context is ready for operation, so make sure we can
disable
Implement backup and restore of LMEM during suspend / resume.
What complicates things a bit is handling of pinned LMEM memory during
suspend and the fact that we might be dealing with unmappable LMEM in
the future, which makes us want to restrict the number of pinned objects that
need memcpy
On Mon, Sep 6, 2021 at 1:02 AM Amit Pundir wrote:
>
> On Sat, 4 Sept 2021 at 01:55, Rob Clark wrote:
> >
> > On Fri, Sep 3, 2021 at 12:39 PM John Stultz wrote:
> > >
> > > On Thu, Jul 29, 2021 at 1:49 PM Rob Clark wrote:
> > > > On Thu, Jul 29, 2021 at 1:28 PM Caleb Connolly
> > > > wrote:
>
On 06/09/2021 14:48, Matthew Auld wrote:
On 06/09/2021 13:53, Tvrtko Ursulin wrote:
On 06/09/2021 13:30, Matthew Auld wrote:
On 06/09/2021 13:19, Tvrtko Ursulin wrote:
On 06/09/2021 10:17, Matthew Auld wrote:
Since the object might still be active here, the shrink_all will
simply
ignore
Hi Christian/Andrey/Daniel,
I read Boris's patch about ordered workqueue and I think maybe we can
leverage this change.
https://lore.kernel.org/dri-devel/20210625133327.2598825-2-boris.brezil...@collabora.com/
As the TDR race condition we are talking about is caused by a bailing
job being
On 06/09/2021 13:53, Tvrtko Ursulin wrote:
On 06/09/2021 13:30, Matthew Auld wrote:
On 06/09/2021 13:19, Tvrtko Ursulin wrote:
On 06/09/2021 10:17, Matthew Auld wrote:
Since the object might still be active here, the shrink_all will simply
ignore it, which blows up in the test, since the
On 06/09/2021 13:30, Matthew Auld wrote:
On 06/09/2021 13:19, Tvrtko Ursulin wrote:
On 06/09/2021 10:17, Matthew Auld wrote:
Since the object might still be active here, the shrink_all will simply
ignore it, which blows up in the test, since the pages will still be
there. Currently THP is
On 06/09/2021 13:19, Tvrtko Ursulin wrote:
On 06/09/2021 10:17, Matthew Auld wrote:
Since the object might still be active here, the shrink_all will simply
ignore it, which blows up in the test, since the pages will still be
there. Currently THP is disabled which should result in the test
> Since there's a lot of confusion around this, document both the rules
> and the best practice around negotiating, allocating, importing, and
> using buffers when crossing context/process/device/subsystem boundaries.
>
> This ties up all of dmabuf, formats and modifiers, and their usage.
>
>
On 03/09/2021 20:22, jim.cro...@gmail.com wrote:
On Fri, Sep 3, 2021 at 5:07 AM Tvrtko Ursulin
wrote:
On 31/08/2021 21:21, Jim Cromie wrote:
The gvt component of this driver has ~120 pr_debugs, in 9 categories
quite similar to those in DRM. Following the interface model of
drm.debug, add
On 06/09/2021 10:17, Matthew Auld wrote:
Since the object might still be active here, the shrink_all will simply
ignore it, which blows up in the test, since the pages will still be
there. Currently THP is disabled which should result in the test being
skipped, but if we ever re-enable THP we
Which branch is this patch based on? Please rebase on top drm-misc-fixes
and resend.
Thanks,
Christian.
Am 06.09.21 um 03:12 schrieb xinhui pan:
The ret value might be -EBUSY, caller will think lru lock is still
locked but actually NOT. So return -ENOSPC instead. Otherwise we hit
list
Am 06.09.21 um 12:16 schrieb Pan, Xinhui:
2021年9月6日 17:04，Christian König 写道：
Am 06.09.21 um 03:12 schrieb xinhui pan:
A long time ago, someone reports system got hung during memory test.
In recent days, I am trying to look for or understand the potential
deadlock in ttm/amdgpu code.
This
On Sat, 4 Sept 2021 at 01:55, Rob Clark wrote:
>
> On Fri, Sep 3, 2021 at 12:39 PM John Stultz wrote:
> >
> > On Thu, Jul 29, 2021 at 1:49 PM Rob Clark wrote:
> > > On Thu, Jul 29, 2021 at 1:28 PM Caleb Connolly
> > > wrote:
> > > > On 29/07/2021 21:24, Rob Clark wrote:
> > > > > On Thu, Jul
On 03/09/2021 22:57, jim.cro...@gmail.com wrote:
On Fri, Sep 3, 2021 at 5:15 AM Tvrtko Ursulin
wrote:
On 31/08/2021 21:21, Jim Cromie wrote:
drm's debug system writes 10 distinct categories of messages to syslog
using a small API[1]: drm_dbg*(10 names), DRM_DEV_DEBUG*(3 names),
> 2021年9月6日 17:04，Christian König 写道：
>
>
>
> Am 06.09.21 um 03:12 schrieb xinhui pan:
>> A long time ago, someone reports system got hung during memory test.
>> In recent days, I am trying to look for or understand the potential
>> deadlock in ttm/amdgpu code.
>>
>> This patchset aims to
On Wed, 01 Sep 2021, Douglas Anderson wrote:
> EDIDs have 32-bits worth of data which is intended to be used to
> uniquely identify the make/model of a panel. This has historically
> been used only internally in the EDID processing code to identify
> quirks with panels.
>
> We'd like to use this
On Wed, 01 Sep 2021, Douglas Anderson wrote:
> A future change wants to be able to read just block 0 of the EDID, so
> break it out of drm_do_get_edid() into a sub-function.
>
> This is intended to be a no-op change--just code movement.
>
> Signed-off-by: Douglas Anderson
> ---
>
> (no changes
From: chongjiapeng
This symbols is not used outside of dc_link_dp.c, so marks it static.
Fix the following sparse warning:
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c:1766:16:
warning: symbol 'configure_lttpr_mode_non_transparent' was not declared.
Should it be static?
From: chongjiapeng
Fix the following coccicheck warning:
./drivers/gpu/drm/amd/display/dc/clk_mgr/dcn31/dcn31_clk_mgr.c:643:35-36:
WARNING comparing pointer to 0.
Reported-by: Abaci Robot
Signed-off-by: chongjiapeng
---
drivers/gpu/drm/amd/display/dc/clk_mgr/dcn31/dcn31_clk_mgr.c | 2 +-
1
Since the object might still be active here, the shrink_all will simply
ignore it, which blows up in the test, since the pages will still be
there. Currently THP is disabled which should result in the test being
skipped, but if we ever re-enable THP we might start seeing the failure.
Fix this by
Am 06.09.21 um 03:12 schrieb xinhui pan:
A long time ago, someone reports system got hung during memory test.
In recent days, I am trying to look for or understand the potential
deadlock in ttm/amdgpu code.
This patchset aims to fix the deadlock during ttm populate.
TTM has a parameter
Am 06.09.21 um 03:12 schrieb xinhui pan:
Like vce/vcn does, visible VRAM is OK for ib test.
While commit a11d9ff3ebe0 ("drm/amdgpu: use GTT for
uvd_get_create/destory_msg") says VRAM is not mapped correctly in his
platform which is likely an arm64.
So lets change back to use VRAM on x86_64
On Fri, Sep 03, 2021 at 09:05:00AM +0100, Tvrtko Ursulin wrote:
>
> On 02/09/2021 15:20, Daniel Vetter wrote:
> > The important part isn't so much that this does an rcu lookup - that's
> > more an implementation detail, which will also be removed.
> >
> > The thing that makes this different from
Hi Kieran,
On Thu, Sep 2, 2021 at 1:39 AM Kieran Bingham
wrote:
> From: Kieran Bingham
>
> Extend the Renesas DU display bindings to support the r8a779a0 V3U.
>
> Reviewed-by: Laurent Pinchart
> Signed-off-by: Kieran Bingham
> ---
> v2:
> - Collected Laurent's tag
> - Remove clock-names
Hi,
On Mon, 6 Sep 2021, Kai-Heng Feng wrote:
> Commit 989634fb49ad ("drm/i915/audio: set HDA link parameters in
> driver") makes HDMI audio on Lenovo P350 disappear.
>
> So in addition to TGL, extend the logic to RKL to use BIOS provided
> value to fix the regression.
thanks Kai-Heng! We were
Add support for eDP panels with a built-in privacy screen using the
new drm_privacy_screen class.
One thing which stands out here is the addition of these 2 lines to
intel_atomic_commit_tail:
for_each_new_connector_in_state(>base, connector, ...
Register a privacy-screen device on laptops with a privacy-screen,
this exports the PrivacyGuard features to user-space using a
standardized vendor-agnostic sysfs interface. Note the sysfs interface
is read-only.
Registering a privacy-screen device with the new privacy-screen class
code will also
Get the privacy-screen / lcdshadow ACPI handles once and cache them,
instead of retrieving them every time we need them.
Reviewed-by: Emil Velikov
Signed-off-by: Hans de Goede
---
drivers/platform/x86/thinkpad_acpi.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
Factor the extended hotkey handling out of hotkey_notify_hotkey() and
into a new hotkey_notify_extended_hotkey() helper.
This is a preparation patch for adding support the privacy-screen hotkey
toggle (which needs some special handling, it should NOT send an evdev
key-event to userspace...).
Add 2 drm_connector privacy-screen helper functions:
1. drm_connector_attach_privacy_screen_provider(), this function creates
and attaches the standard privacy-screen properties and registers a
generic notifier for generating sysfs-connector-status-events on external
changes to the privacy-screen
Add support for privacy-screen consumers to register a notifier to
be notified of external (e.g. done by the hw itself on a hotkey press)
state changes.
Reviewed-by: Emil Velikov
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/drm_privacy_screen.c | 67 +++
Add X86 specific arch init code, which fills the privacy-screen lookup
table by checking for various vendor specific ACPI interfaces for
controlling the privacy-screen.
This initial version only checks for the Lenovo Thinkpad specific ACPI
methods for privacy-screen control.
Reviewed-by: Emil
On some new laptops the LCD panel has a builtin electronic privacy-screen.
We want to export this functionality as a property on the drm connector
object. But often this functionality is not exposed on the GPU but on some
other (ACPI) device.
This commit adds a privacy-screen class allowing the
From: Rajat Jain
Add support for generic electronic privacy screen properties, that
can be added by systems that have an integrated EPS.
Changes in v2 (Hans de Goede)
- Create 2 properties, "privacy-screen sw-state" and
"privacy-screen hw-state", to deal with devices where the OS might be
1 - 100 of 123 matches
Mail list logo
