Hi all,
Here is the privacy-screen related code which I last posted in April 2021
To the best of my knowledge there is consensus about / everyone is in
agreement with the new userspace API (2 connector properties) this
patch-set add (patch 1 of the series).
This is unchanged (except for a rebase
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
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
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
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
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, ...
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 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
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...).
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(-)
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 Nancy,
On Mon, 2021-09-06 at 15:15 +0800, Nancy.Lin wrote:
> MT8195 vdosys1 has more than 32 reset bits and a different reset base
> than other chips. Modify mmsys for support 64 bit and different reset
> base.
>
> Signed-off-by: Nancy.Lin
> ---
> drivers/soc/mediatek/mt8195-mmsys.h | 1 +
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
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
On Mon, Sep 6, 2021 at 12:49 AM Stephen Rothwell wrote:
> Hi all,
>
> On Thu, 2 Sep 2021 07:50:38 +1000 Stephen Rothwell
> wrote:
> >
> > On Fri, 20 Aug 2021 15:23:34 +0900 Masahiro Yamada
> > wrote:
> > >
> > > On Fri, Aug 20, 2021 at 11:33 AM Stephen Rothwell
> > > wrote:
> > > >
> > >
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
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
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?
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
> 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
[AMD Official Use Only]
> I'm fearing that just repeating what Alex said, but to make it clear
> once more: That is *not* necessary!
>
> The shared repository is owned by upstream maintainers and they are
> usually free to do restructuring work without getting acknowledge from
> every single
MT8195 vdosys1 has more than 32 reset bits and a different reset base
than other chips. Modify mmsys for support 64 bit and different reset
base.
Signed-off-by: Nancy.Lin
---
drivers/soc/mediatek/mt8195-mmsys.h | 1 +
drivers/soc/mediatek/mtk-mmsys.c| 15 ---
Add driver data of mt8195 vdosys1 to mediatek-drm and the sub driver.
Signed-off-by: Nancy.Lin
---
drivers/gpu/drm/mediatek/mtk_disp_merge.c | 4
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 15 +++
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 1 +
Add mmsys config API. The config API is used for config mmsys reg.
Some mmsys regs need to be setting according to the HW engine binding
to the mmsys simultaneously.
Signed-off-by: Nancy.Lin
---
drivers/soc/mediatek/mt8195-mmsys.h| 62 ++
Add ovl_adaptor driver for MT8195.
Ovl_adaptor is an encapsulated module and designed for simplified
DRM control flow. This module is composed of 8 RDMAs, 4 MERGEs and
an ETHDR. Two RDMAs merge into one layer, so this module support 4
layers.
Signed-off-by: Nancy.Lin
---
Add MDP_RDMA driver for MT8195. MDP_RDMA is the DMA engine of
the ovl_adaptor component.
Signed-off-by: Nancy.Lin
---
drivers/gpu/drm/mediatek/Makefile | 3 +-
drivers/gpu/drm/mediatek/mtk_disp_drv.h | 7 +
drivers/gpu/drm/mediatek/mtk_mdp_rdma.c | 301
Add vdosys1 reset control bit for MT8195 platform.
Signed-off-by: Nancy.Lin
---
include/dt-bindings/reset/mt8195-resets.h | 12
1 file changed, 12 insertions(+)
diff --git a/include/dt-bindings/reset/mt8195-resets.h
b/include/dt-bindings/reset/mt8195-resets.h
index
MT8195 have two mmsys. Modify drm for MT8195 multi-mmsys support.
The two mmsys (vdosys0 and vdosys1) will bring up two drm drivers,
only one drm driver register as the drm device.
Each drm driver binds its own component. The first bind drm driver
will allocate the drm device, and the last bind
Add mt8195 vdosys1 clock driver name and routing table to
the driver data of mtk-mmsys.
Signed-off-by: Nancy.Lin
---
drivers/soc/mediatek/mt8195-mmsys.h| 136 +
drivers/soc/mediatek/mtk-mmsys.c | 10 ++
include/linux/soc/mediatek/mtk-mmsys.h | 2 +
3 files
MT8195 vdosys1 merge1 to merge4 have HW mute function.
Add MERGE additional mute property description.
Signed-off-by: Nancy.Lin
---
.../devicetree/bindings/display/mediatek/mediatek,merge.yaml | 3 +++
1 file changed, 3 insertions(+)
diff --git
Add merge new API.
1. Vdosys1 merge1~merge4 support HW mute function, so add unmute API.
2. Add merge new advance config API. The original merge API is
mtk_ddp_comp_funcs function prototype. The API interface parameters
cannot be modified, so add a new config API for extension.
3. Add merge
Add vdosys1 RDMA definition.
Signed-off-by: Nancy.Lin
---
.../display/mediatek/mediatek,mdp-rdma.yaml | 77 +++
1 file changed, 77 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/mediatek/mediatek,mdp-rdma.yaml
diff --git
https://bugzilla.kernel.org/show_bug.cgi?id=107381
GeorgeQQHu (huqiq...@uniontech.com) changed:
What|Removed |Added
CC|
Address the following checkpatch errors:
ERROR: do not initialise statics to false
FILE: :drivers/gpu/drm/msm/msm_drv.c:21:
-static bool reglog = false;
FILE: :drivers/gpu/drm/msm/msm_drv.c:31:
-bool dumpstate = false;
Signed-off-by: zhaoxiao
---
drivers/gpu/drm/msm/msm_drv.c | 4 ++--
1 file
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
Add cmdq support for mtk-mmsys config API.
The mmsys config register settings need to take effect with the other
HW settings(like OVL_ADAPTOR...) at the same vblanking time.
If we use CPU to write the mmsys reg, we can't guarantee all the
settings can be written in the same vblanking time.
Cmdq
The hardware path of vdosys1 with DPTx output need to go through by several
modules, such as, OVL_ADAPTOR and MERGE.
Add DRM and these modules support by the patches below:
Changes in v5:
- add mmsys reset controller reference.
Changes in v4:
- use merge common driver for merge1~4.
- refine
Add display node for vdosys1.
Signed-off-by: Nancy.Lin
---
arch/arm64/boot/dts/mediatek/mt8195.dtsi | 221 +++
1 file changed, 221 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8195.dtsi
b/arch/arm64/boot/dts/mediatek/mt8195.dtsi
index
Add mtk-mutex support for mt8195 vdosys1.
The vdosys1 path component contains ovl_adaptor, merge5,
and dp_intf1. Ovl_adaptor is composed of several sub-elements,
so change it to support multi-bit control.
Signed-off-by: Nancy.Lin
---
drivers/soc/mediatek/mtk-mutex.c | 270
ETHDR is a part of ovl_adaptor.
ETHDR is designed for HDR video and graphics conversion in the external
display path. It handles multiple HDR input types and performs tone
mapping, color space/color format conversion, and then combine
different layers, output the required HDR or SDR signal to the
Add vdosys1 ETHDR definition.
Signed-off-by: Nancy.Lin
---
.../display/mediatek/mediatek,ethdr.yaml | 144 ++
1 file changed, 144 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml
diff --git
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
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),
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
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
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
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
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
> 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 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 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:
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
>
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
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 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
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 ++
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
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
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
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
This is how a typical display color hardware pipeline looks like:
+---+
|RAM|
| +--++-++-+ |
| | FB 1 || FB 2 || FB N| |
| +--++-++-+
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 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
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
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
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:
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
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
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
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
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
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 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
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'
> 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.
>
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
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
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
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
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 |
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
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 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:
>
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
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
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
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
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
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 +
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.
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 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
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
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(-)
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 +
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
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
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
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 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
1 - 100 of 123 matches
Mail list logo
