Hi Boris,
s...@ravnborg.org wrote on Thu, 10 Aug 2023 19:31:25 +0200:
> > I queued it to drm-misc-next this morning.
Yeah, thanks a lot!
Cheers,
Miquèl
On Friday, August 11, 2023 3:30 AM Conor Dooley wrote:
>
> On Wed, Aug 02, 2023 at 11:51:17AM +0200, Guido Günther wrote:
> > Hi,
> > On Sun, Jul 30, 2023 at 09:41:20PM +0300, David Heidelberg wrote:
> > > i.MX8MQ uses as secondary compatible fsl,imx6sx-lcdif, which triggers
> > > requirement of
On Meteorlake onwards, HW specs require that all user contexts that
run on render or compute engines and require PXP must enforce
run-alone bit in lrc. Add this enforcement for protected contexts.
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 12
1 file
Update the max GSC-fw response time to match updated internal
fw specs. Because this response time is an SLA on the firmware,
not inclusive of i915->GuC->HW handoff latency, when submitting
requests to the GSC fw via intel_gsc_uc_heci_cmd_submit_nonpriv,
start the count after the request hits the
Update the GSC-fw input/output HECI packet size to match
updated internal fw specs.
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
For MTL, update the GSC-HECI packet size and the max firmware
response timeout to match internal fw specs. Enforce setting
run-alone bit in LRC for protected contexts.
Signed-off-by: Alan Previn
Alan Previn (3):
drm/i915/pxp/mtl: Update pxp-firmware response timeout
drm/i915/pxp/mtl: Update
On 8/10/23 21:30, Conor Dooley wrote:
On Wed, Aug 02, 2023 at 11:51:17AM +0200, Guido Günther wrote:
Hi,
On Sun, Jul 30, 2023 at 09:41:20PM +0300, David Heidelberg wrote:
i.MX8MQ uses as secondary compatible fsl,imx6sx-lcdif, which triggers
requirement of power-domains, thou it's not required.
From: Dave Airlie
With the new uapi we don't have the comp flags on the allocation,
so we shouldn't be using the first size that works, we should be
iterating until we get the correct one.
This reduces allocations from 2MB to 64k in lots of places.
Fixes
tree: git://anongit.freedesktop.org/drm/drm-misc for-linux-next
head: 68132cc6d1bcbc78ade524c6c6c226de42139f0e
commit: e3912d09bf8ddd8e274118d4c9cc550d9665115d [1/3] drm/ttm: Introduce KUnit
test
config: arm-randconfig-r006-20230811
Also add a lockdep assert to drm_sched_start_timeout.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/scheduler/sched_main.c | 23 +--
1 file changed, 13 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
Add generic schedule message interface which sends messages to backend
from the drm_gpu_scheduler main submission thread. The idea is some of
these messages modify some state in drm_sched_entity which is also
modified during submission. By scheduling these messages and submission
in the same
DRM_SCHED_POLICY_SINGLE_ENTITY creates a 1 to 1 relationship between
scheduler and entity. No priorities or run queue used in this mode.
Intended for devices with firmware schedulers.
v2:
- Drop sched / rq union (Luben)
Signed-off-by: Matthew Brost
---
Rather than a global modparam for scheduling policy, move the scheduling
policy to scheduler / entity so user can control each scheduler / entity
policy.
v2:
- s/DRM_SCHED_POLICY_MAX/DRM_SCHED_POLICY_COUNT (Luben)
- Only include policy in scheduler (Luben)
Signed-off-by: Matthew Brost
---
If the TDR is set to a value, it can fire before a job is submitted in
drm_sched_main. The job should be always be submitted before the TDR
fires, fix this ordering.
v2:
- Add to pending list before run_job, start TDR after (Luben, Boris)
Signed-off-by: Matthew Brost
---
Rather than call free_job and run_job in same work item have a dedicated
work item for each. This aligns with the design and intended use of work
queues.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/scheduler/sched_main.c | 137 ++---
include/drm/gpu_scheduler.h
Add helper to set TDR timeout and restart the TDR with new timeout
value. This will be used in XE, new Intel GPU driver, to trigger the TDR
to cleanup drm_sched_entity that encounter errors.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/scheduler/sched_main.c | 18 ++
If the TDR is set to a very small value it can fire before the run wq is
started in the function drm_sched_start. The run wq is expected to
running when the TDR fires, fix this ordering so this expectation is
always met.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/scheduler/sched_main.c |
As a prerequisite to merging the new Intel Xe DRM driver [1] [2], we
have been asked to merge our common DRM scheduler patches first.
This a continuation of a RFC [3] with all comments addressed, ready for
a full review, and hopefully in state which can merged in the near
future. More details of
In XE, the new Intel GPU driver, a choice has made to have a 1 to 1
mapping between a drm_gpu_scheduler and drm_sched_entity. At first this
seems a bit odd but let us explain the reasoning below.
1. In XE the submission order from multiple drm_sched_entity is not
guaranteed to be the same
On Thu, Aug 10, 2023 at 9:09 AM Samudrala, Sridhar
wrote:
>
>
>
> On 8/9/2023 6:57 PM, Mina Almasry wrote:
> > API takes the dma-buf fd as input, and binds it to the netdevice. The
> > user can specify the rx queue to bind the dma-buf to. The user should be
> > able to bind the same dma-buf to
On Thu, Aug 10, 2023 at 11:58 AM Jason Gunthorpe wrote:
>
> On Thu, Aug 10, 2023 at 11:44:53AM -0700, Mina Almasry wrote:
>
> > Someone will correct me if I'm wrong but I'm not sure netlink itself
> > will do (sufficient) access control. However I meant for the netlink
> > API to bind dma-bufs to
If a sched job depends on a dma-fence from a job from the same GPU
scheduler instance, but a different scheduler entity, the GPU scheduler
does only wait for the particular job to be scheduled, rather than for
the job to fully complete. This is due to the GPU scheduler assuming
that there is a
On Fri, 2023-07-07 at 11:34 -0700, Teres Alexis, Alan Previn wrote:
> Update the max GSC-HECI packet size and the max firmware
> response timeout to match internal fw specs.
>
> Signed-off-by: Alan Previn
I'm going to re-rev this and change the subject slightly to "Update gsc-heci
cmd
On Wed, Aug 09, 2023 at 10:39:40AM -0500, Chris Morgan wrote:
> From: Chris Morgan
>
> Document the Anbernic RG351V panel, which appears to be identical to
> the panel used in their 353 series except for in inclusion of an
> additional DSI format flag.
>
> Signed-off-by: Chris Morgan
> ---
>
From: Rob Clark
Avoid holding gpu lock when calling runpm, to avoid this lockdep splat:
==
WARNING: possible circular locking dependency detected
6.4.3-debug+ #14 Not tainted
--
On Thu, 10 Aug 2023 16:41:15 +0200, Luca Ceresoli wrote:
> Add bindings for LCD panels based on the ILITEK ILI9806E RGB controller
> connected over SPI and the "ShenZhen New Display Co NDS040480800-V3"
> 480x800 panel based on it.
>
> Signed-off-by: Luca Ceresoli
>
> ---
>
> Changes in v2:
>
On Thu, 10 Aug 2023 16:41:14 +0200, Luca Ceresoli wrote:
> ShenZhen New Display Co., Limited is the manufacturer of the
> NDS040480800-V3 LCD panel according the datasheet.
>
> Signed-off-by: Luca Ceresoli
>
> ---
>
> Changes in v2: none
> ---
>
On Thu, 2023-08-10 at 21:49 +0200, Thomas Hellström wrote:
> Hi, Paulo.
>
> Thanks for reviewing. I'd like to try give some answers below.
>
> On 8/4/23 23:30, Zanoni, Paulo R wrote:
> > On Fri, 2023-08-04 at 16:02 -0400, Rodrigo Vivi wrote:
> > > On Wed, Jul 19, 2023 at 07:50:21PM +,
Hi Sui,
kernel test robot noticed the following build errors:
[auto build test ERROR on pci/next]
[also build test ERROR on pci/for-linus linus/master v6.5-rc5 next-20230809]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use
On 8/10/23 20:50, Dave Airlie wrote:
From: Dave Airlie
I think there are limit checks in places for most things but the
new api wants to not have them.
Add a limit check and use the vmemdup_user helper instead.
Reviewed-by: Danilo Krummrich
Signed-off-by: Dave Airlie
---
From: Rob Clark
Fix another lockdep splat by pushing the GMU lock further down in the
pm_resume path, so that we aren't holding it while preparing/enabling
clks. Fixes:
==
WARNING: possible circular locking dependency detected
Hi Dave and Daniel,
This is likely our latest PR from drm-intel-next towards 6.6
drm-intel-next-2023-08-10:
- Display SDVO fixes (Juha-Pekka, Jani)
- Taking Stolen handling out of FBC code (Jouni)
- Replace acronym with full platform name in defines (Dnyaneshwar, A\
nusha)
- Display IRQ
Hi, Paulo.
Thanks for reviewing. I'd like to try give some answers below.
On 8/4/23 23:30, Zanoni, Paulo R wrote:
On Fri, 2023-08-04 at 16:02 -0400, Rodrigo Vivi wrote:
On Wed, Jul 19, 2023 at 07:50:21PM +, Zanoni, Paulo R wrote:
On Sat, 2023-07-15 at 17:45 +0200, Thomas Hellström wrote:
On Wed, Aug 02, 2023 at 11:51:17AM +0200, Guido Günther wrote:
> Hi,
> On Sun, Jul 30, 2023 at 09:41:20PM +0300, David Heidelberg wrote:
> > i.MX8MQ uses as secondary compatible fsl,imx6sx-lcdif, which triggers
> > requirement of power-domains, thou it's not required.
> >
> > Fixes: f62678a77d58
On Wed, Aug 09, 2023 at 10:39:40AM -0500, Chris Morgan wrote:
> From: Chris Morgan
>
> Document the Anbernic RG351V panel, which appears to be identical to
> the panel used in their 353 series except for in inclusion of an
> additional DSI format flag.
Sure?
Acked-by: Conor Dooley
Thanks,
Even if there's nothing currently parsing amdgpu's coredump files, if
we eventually have such tools they will be glad to find a version field
to properly read the file.
Create a version number to be displayed on top of coredump file, to be
incremented when the file format or content get changed.
Giving that we use codedump just for device resets, move it's functions
and structs to a more semantic file, the amdgpu_reset.{c, h}.
Signed-off-by: André Almeida
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 9 ---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 80 --
Instead of storing coredump information inside amdgpu_device struct,
move if to a proper separated struct and allocate it dynamically. This
will make it easier to further expand the logged information.
Signed-off-by: André Almeida
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 14 +++--
During a GPU reset, a normal memory reclaim could block to reclaim
memory. Giving that coredump is a best effort mechanism, it shouldn't
disturb the reset path. Change its memory allocation flag to a
nonblocking one.
Signed-off-by: André Almeida
Reviewed-by: Christian König
---
Create a module parameter to disable soft recoveries on amdgpu, making
every recovery go through the device reset path. This option makes
easier to force device resets for testing and debugging purposes.
Signed-off-by: André Almeida
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 +
Hi,
The goal of this patchset is to improve debugging device resets on amdgpu.
The first patch creates a new module parameter to disable soft recoveries,
ensuring every recovery go through the full device reset, making easier to
generate resets from userspace tools like [0] and [1]. This is
On Thu, Aug 10, 2023 at 04:41:14PM +0200, Luca Ceresoli wrote:
> ShenZhen New Display Co., Limited is the manufacturer of the
> NDS040480800-V3 LCD panel according the datasheet.
>
> Signed-off-by: Luca Ceresoli
Acked-by: Conor Dooley
signature.asc
Description: PGP signature
On Thu, Aug 10, 2023 at 04:44:45PM +0200, Alexander Stein wrote:
> Hi everyone,
>
> while working on i.MX6Q based board
> (arch/arm/boot/dts/nxp/imx/imx6q-mba6a.dts)
> I noticed several warnings on dtbs_check. The first 5 patches should be pretty
> much straight forward.
> I'm not 100% sure on
On Thu, Aug 10, 2023 at 04:44:46PM +0200, Alexander Stein wrote:
> Starting with commit 3e37c9d48f7a ("dt-bindings: hwmon: Convert lm75
> bindings to yaml") 'national,lm75' has it's own dedicated (YAML) binding.
> If kept in this file device specific properties as 'vs-supply' are
> considered
On Thu, Aug 10, 2023 at 11:44:53AM -0700, Mina Almasry wrote:
> Someone will correct me if I'm wrong but I'm not sure netlink itself
> will do (sufficient) access control. However I meant for the netlink
> API to bind dma-bufs to be a CAP_NET_ADMIN API, and I forgot to add
> this check in this
From: Dave Airlie
I think there are limit checks in places for most things but the
new api wants to not have them.
Add a limit check and use the vmemdup_user helper instead.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/nouveau_drv.h | 19 +--
1 file changed, 5
On Thu, Aug 10, 2023 at 3:29 AM Christian König
wrote:
>
> Am 10.08.23 um 03:57 schrieb Mina Almasry:
> > Changes in RFC v2:
> > --
> >
> > The sticking point in RFC v1[1] was the dma-buf pages approach we used to
> > deliver the device memory to the TCP stack. RFC v2 is a
From: Dave Airlie
I think there are limit checks in places for most things but the
new api wants to not have them.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/nouveau_drv.h | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h
> I queued it to drm-misc-next this morning.
Thanks Boris!
Sam
tree: git://anongit.freedesktop.org/drm/drm-misc for-linux-next
head: 2799804ac651da1375ecb9b9a644eba97218df07
commit: e3912d09bf8ddd8e274118d4c9cc550d9665115d [1/3] drm/ttm: Introduce KUnit
test
config: riscv-randconfig-r022-20230810
(https://download.01.org/0day-ci/archive/20230811
Hi Neil
On 8/3/2023 10:19 AM, Jessica Zhang wrote:
On 7/31/2023 6:00 AM, Neil Armstrong wrote:
Hi,
On 26/07/2023 00:56, Jessica Zhang wrote:
Due to a recent introduction of the pre_enable_prev_first bridge flag
[1],
the panel driver will be probed before the DSI is enabled, causing the
On Thu, 10 Aug 2023 16:41:15 +0200, Luca Ceresoli wrote:
> Add bindings for LCD panels based on the ILITEK ILI9806E RGB controller
> connected over SPI and the "ShenZhen New Display Co NDS040480800-V3"
> 480x800 panel based on it.
>
> Signed-off-by: Luca Ceresoli
>
> ---
>
> Changes in v2:
>
On Thu, 10 Aug 2023 16:41:14 +0200, Luca Ceresoli wrote:
> ShenZhen New Display Co., Limited is the manufacturer of the
> NDS040480800-V3 LCD panel according the datasheet.
>
> Signed-off-by: Luca Ceresoli
>
> ---
>
> Changes in v2: none
> ---
>
On 8/10/2023 6:23 AM, Dan Carpenter wrote:
The encode_dma() function has some validation on in_trans->size but it
would be more clear to move those checks to find_and_map_user_pages().
The encode_dma() had two checks:
if (in_trans->addr + in_trans->size < in_trans->addr ||
On 8/9/2023 6:57 PM, Mina Almasry wrote:
API takes the dma-buf fd as input, and binds it to the netdevice. The
user can specify the rx queue to bind the dma-buf to. The user should be
able to bind the same dma-buf to multiple queues, but that is left as
a (minor) TODO in this iteration.
To
On Thu, Aug 10, 2023 at 12:29:08PM +0200, Christian König wrote:
> Am 10.08.23 um 03:57 schrieb Mina Almasry:
> > Changes in RFC v2:
> > --
> >
> > The sticking point in RFC v1[1] was the dma-buf pages approach we used to
> > deliver the device memory to the TCP stack. RFC v2 is a
Map the plane CTM driver-specific property to DC plane, instead of DC
stream. The remaining steps to program DPP block are already implemented
on DC shared-code.
Signed-off-by: Melissa Wen
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 +
.../amd/display/amdgpu_dm/amdgpu_dm_color.c |
From: Joshua Ashton
Signed-off-by: Joshua Ashton
Signed-off-by: Melissa Wen
---
.../amd/display/amdgpu_dm/amdgpu_dm_color.c | 32 +--
.../amd/display/amdgpu_dm/amdgpu_dm_plane.c | 2 +-
include/uapi/drm/drm_mode.h | 8 +
3 files changed, 38
dc->caps.color.mpc.gamut_remap says there is a post-blending color block
for gamut remap matrix for DCN3 HW family and newer versions. However,
those drivers still follow DCN10 programming that remap stream
gamut_remap_matrix to DPP (pre-blending).
To enable pre-blending and post-blending
From: Joshua Ashton
Map plane blend properties to DPP blend gamma. Plane blend is a
post-3D LUT curve that linearizes color space for blending. It may be
defined by a user-blob LUT and/or predefined transfer function. As
hardcoded curve (ROM) is not supported on blend gamma, we use AMD color
From: Joshua Ashton
Unlike degamma, blend gamma doesn't support hardcoded curve
(predefined/ROM), but we can use AMD color module to fill blend gamma
parameters when we have non-linear plane gamma TF without plane gamma
LUT. The regular degamma path doesn't hit this.
Reviewed-by: Harry Wentland
From: Joshua Ashton
When commiting planes, we copy color mgmt resources to the stream state.
Do the same for shaper and 3D LUTs.
Reviewed-by: Harry Wentland
Signed-off-by: Joshua Ashton
Co-developed-by: Melissa Wen
Signed-off-by: Melissa Wen
---
Plane CTM for pre-blending color space conversion. Only enable
driver-specific plane CTM property on drivers that support both pre- and
post-blending gamut remap matrix, i.e., DCN3+ family. Otherwise it
conflits with DRM CRTC CTM property.
Signed-off-by: Melissa Wen
---
Wire up DC 3D LUT to DM plane color management (pre-blending). On AMD
display HW, 3D LUT comes after a shaper curve and we always have to
program a shaper curve to delinearize or normalize the color space
before applying a 3D LUT (since we have a reduced number of LUT
entries).
In this version,
From: Joshua Ashton
Need to funnel the color caps through to these functions so it can check
that the hardware is capable.
v2:
- remove redundant color caps assignment on plane degamma map (Harry)
- pass color caps to degamma params
Signed-off-by: Joshua Ashton
Signed-off-by: Melissa Wen
---
Map DC shaper LUT to DM plane color management. Shaper LUT can be used
to delinearize and/or normalize the color space for computational
efficiency and achiving specific visual styles. If a plane degamma is
apply to linearize the color space, a custom shaper 1D LUT can be used
just before applying
From: Joshua Ashton
With `dc_fixpt_from_s3132()` translation, we can just use it to set
hdr_mult.
Reviewed-by: Harry Wentland
Signed-off-by: Joshua Ashton
Signed-off-by: Melissa Wen
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 +
Enable usage of predefined transfer func in addition to shaper 1D LUT.
That means we can save some complexity by just setting a predefined
curve, instead of programming a custom curve when preparing color space
for applying 3D LUT.
Reviewed-by: Harry Wentland
Signed-off-by: Melissa Wen
---
DC only has pre-blending degamma caps (plane/DPP) that is currently in
use for CRTC/post-blending degamma, so that we don't have HW caps to
perform plane and CRTC degamma at the same time. Reject atomic updates
when serspace sets both plane and CRTC degamma properties.
Reviewed-by: Harry Wentland
From: Joshua Ashton
Detach value translation from CTM to reuse it for programming HDR
multiplier property.
Reviewed-by: Harry Wentland
Signed-off-by: Joshua Ashton
Signed-off-by: Melissa Wen
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c | 8 +---
The next patch adds pre-blending degamma to AMD color mgmt pipeline, but
pre-blending degamma caps (DPP) is currently in use to provide DRM CRTC
atomic degamma or implict degamma on legacy gamma. Detach degamma usage
regarging CRTC color properties to manage plane and CRTC color
correction
From: Joshua Ashton
Set DC plane with user degamma LUT or predefined TF from driver-specific
plane color properties. If plane and CRTC degamma are set in the same
time, plane degamma has priority. That means, we only set CRTC degamma
if we don't have plane degamma LUT or TF to configure. We
From: Joshua Ashton
We should reset a plane state if at least one of the color management
properties differs from old and new state.
Reviewed-by: Harry Wentland
Signed-off-by: Joshua Ashton
Co-developed-by: Melissa Wen
Signed-off-by: Melissa Wen
---
Describe some expected behavior of the AMD DM color mgmt programming.
Signed-off-by: Melissa Wen
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
From: Joshua Ashton
Otherwise this is just initialized to 0. This needs to actually have a
value so that compute_curve can work for PQ EOTF.
Reviewed-by: Harry Wentland
Signed-off-by: Joshua Ashton
Co-developed-by: Melissa Wen
Signed-off-by: Melissa Wen
---
From: Joshua Ashton
Add predefined transfer function programming. There is no pre-blending
out gamma ROM, but we can use AMD color modules to program LUT
parameters from a pre-defined TF and an empty regamma LUT (or bump up
LUT parameters with pre-defined TF setup).
v2:
- update crtc color mgmt
We will wire up MPC 3D LUT to DM CRTC color pipeline in the next patch,
but so far, only for atomic interface. By checking
set_output_transfer_func in DC drivers with MPC 3D LUT support, we can
verify that regamma is only programmed when 3D LUT programming fails. As
a groundwork to introduce 3D
Add AMD pre-defined transfer function property to default DRM CRTC
gamma to convert to wire encoding with or without a user gamma LUT.
v2:
- enable CRTC prop in the end of driver-specific prop sequence
- define inverse EOTFs as supported regamma TFs
- reword driver-specific function doc to remove
Add 3D LUT property for plane gamma correction using a 3D lookup table.
Since a 3D LUT has a limited number of entries in each dimension we want
to use them in an optimal fashion. This means using the 3D LUT in a
colorspace that is optimized for human vision, such as sRGB, PQ, or
another
From: Joshua Ashton
Blend 1D LUT or a pre-defined transfer function can be set to linearize
content before blending, so that it's positioned just before blending
planes in the AMD color mgmt pipeline, and after 3D LUT (non-linear
space). Shaper and Blend LUTs are 1D LUTs that sandwich 3D LUT.
Brief documentation about pre-defined transfer function usage on AMD
display driver and standardized EOTFs and inverse EOTFs.
Co-developed-by: Harry Wentland
Signed-off-by: Harry Wentland
Signed-off-by: Melissa Wen
---
.../amd/display/amdgpu_dm/amdgpu_dm_color.c | 39 +++
1
On AMD HW, 3D LUT always assumes a preceding shaper 1D LUT used for
delinearizing and/or normalizing the color space before applying a 3D
LUT. Add pre-defined transfer function to enable delinearizing content
with or without shaper LUT, where AMD color module calculates the
resulted shaper curve.
Instead of relying on color block names to get the transfer function
intention regarding encoding pixel's luminance, define supported
Electro-Optical Transfer Functions (EOTFs) and inverse EOTFs, that
includes pure gamma or standardized transfer functions.
Suggested-by: Harry Wentland
From: Joshua Ashton
Multiplier to 'gain' the plane. When PQ is decoded using the fixed func
transfer function to the internal FP16 fb, 1.0 -> 80 nits (on AMD at
least) When sRGB is decoded, 1.0 -> 1.0. Therefore, 1.0 multiplier = 80
nits for SDR content. So if you want, 203 nits for SDR
From: Joshua Ashton
Allow userspace to tell the kernel driver the input space and,
therefore, uses correct predefined transfer function (TF) to delinearize
content with or without LUT.
v2:
- rename TF enum prefix from DRM_ to AMDGPU_ (Harry)
- remove HLG TF
Signed-off-by: Joshua Ashton
Hook up driver-specific atomic operations for managing AMD color
properties. Create AMD driver-specific color management properties
and attach them according to HW capabilities defined by `struct
dc_color_caps`.
First add plane degamma LUT properties that means user-blob and its
size. We will add
We will add color mgmt properties to DRM planes in the next patches and
we want to track when one of this properties change to define atomic
commit behaviors. Using a similar approach from CRTC color props, we set
a color_mgmt_changed boolean whenever a plane color prop changes.
Reviewed-by:
Place it in drm_property where drm_property_replace_blob and
drm_property_lookup_blob live. Then we can use the DRM helper for
driver-specific KMS properties too.
Reviewed-by: Harry Wentland
Reviewed-by: Liviu Dudau
Signed-off-by: Melissa Wen
---
drivers/gpu/drm/arm/malidp_crtc.c | 2 +-
DRM_OBJECT_MAX_PROPERTY limits the number of properties to be attached
and we are increasing that value all time we add a new property (generic
or driver-specific).
In this series, we are adding 13 new KMS driver-specific properties for
AMD color manage:
- CRTC Gamma enumerated Transfer Function
Hi all,
Here is the next version of our work to enable AMD driver-specific color
management properties [1][2]. This series is a collection of
contributions from Joshua, Harry, and me to enhance the AMD KMS color
pipeline for Steam Deck/SteamOS by exposing additional pre-blending and
post-blending
From: Harry Wentland
The region and segment calculation was incapable of dealing
with regions of more than 16 segments. We first fix this.
Now that we can support regions up to 256 elements we can
define a better segment distribution for near-linear LUTs
for our maximum of 256 HW-supported
Hello Rob,
On Wed, 9 Aug 2023 14:22:59 -0600
Rob Herring wrote:
> On Wed, Aug 9, 2023 at 10:53 AM Boris Brezillon
> wrote:
> >
> > I tried to Cc anyone that was involved in any development of the code
> > I picked from panfrost, so they can acknowledge the GPL2 -> MIT+GPL2
> > change. If I
On 8/10/23 00:37, Evan Quan wrote:
> diff --git a/Documentation/admin-guide/kernel-parameters.txt
> b/Documentation/admin-guide/kernel-parameters.txt
> index a1457995fd41..21f73a0bbd0b 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++
On 8/10/23 08:34, Christian König wrote:
Am 10.08.23 um 00:17 schrieb Danilo Krummrich:
With the current mental model every GPU scheduler instance represents
a single HW ring, while every entity represents a software queue feeding
into one or multiple GPU scheduler instances and hence into one
On Thu, Aug 10, 2023 at 08:04:24PM +0800, Ruan Jinjie wrote:
> Use memdup_user_nul() helper instead of open-coding to simplify the code.
>
> Signed-off-by: Ruan Jinjie
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
On 8/10/23 06:31, Matthew Brost wrote:
On Thu, Aug 10, 2023 at 12:17:23AM +0200, Danilo Krummrich wrote:
With the current mental model every GPU scheduler instance represents
a single HW ring, while every entity represents a software queue feeding
into one or multiple GPU scheduler instances
On 8/10/2023 8:32 AM, Stanislaw Gruszka wrote:
On Thu, Aug 10, 2023 at 08:27:08AM -0600, Jeffrey Hugo wrote:
On 8/10/2023 2:07 AM, Stanislaw Gruszka wrote:
Add comments regarding new DRM_IVPU_PARAM_CAPABILITIES param.
Signed-off-by: Stanislaw Gruszka
---
include/uapi/drm/ivpu_accel.h | 19
MAC address can be provided by a nvmem-cell, thus allow referencing a
source for the address. Fixes the warning:
arch/arm/boot/dts/nxp/imx/imx6q-mba6a.dtb: ethernet@1: 'nvmem-cell-names',
'nvmem-cells' do not match any of the regexes: 'pinctrl-[0-9]+'
From schema:
Currently the dtbs_check for imx6ul generates warnings like this:
['fsl,imx7d-gpt', 'fsl,imx6sx-gpt'] is too long
The driver has no special handling for fsl,imx7d-gpt, so fsl,imx6sx-gpt is
used. Therefore make imx7d GPT compatible to the imx6sx one to fix the
warning.
Signed-off-by: Alexander
Since commit bad3db104f89 ("ARM: imx: source gpt per clk from OSC for
system timer") osc_per can be used for clocking the GPT which is not
scaled when entering low bus mode.
This clock source is available only on i.MX6Q (incl. i.MX6QP) and i.MX6DL.
Signed-off-by: Alexander Stein
---
Notes:
1 - 100 of 194 matches
Mail list logo
