On 9/2/24 18:58, Daniel Vetter wrote:
> On Thu, Feb 08, 2024 at 09:16:50AM +0800, Daniel van Vugt wrote:
>> On 8/2/24 04:21, Mario Limonciello wrote:
>>> On 2/7/2024 03:51, Daniel Vetter wrote:
On Wed, Feb 07, 2024 at 10:03:10AM +0800, Daniel van Vugt wrote:
> On 6/2/24 23:41, Mario
From: Chaitanya Kumar Borah
Expose color pipeline and add capability to program it.
Signed-off-by: Chaitanya Kumar Borah
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/display/skl_universal_plane.c | 5 +
1 file changed, 5 insertions(+)
diff --git
From: Chaitanya Kumar Borah
The decision should be made based on the
DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE.
Right now the value of this cap is not passed on to the driver.
Signed-off-by: Chaitanya Kumar Borah
---
drivers/gpu/drm/i915/display/skl_universal_plane.c | 14 --
1 file
Extract the LUT and program plane post csc registers.
Signed-off-by: Uma Shankar
Signed-off-by: Chaitanya Kumar Borah
---
drivers/gpu/drm/i915/display/intel_color.c | 88 ++
1 file changed, 88 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
Add callback for programming Pre-CSC LUT for TGL and beyond
Signed-off-by: Chaitanya Kumar Borah
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_color.c | 88 ++
1 file changed, 88 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
Add macros to define Plane Post CSC registers
Signed-off-by: Uma Shankar
Signed-off-by: Chaitanya Kumar Borah
---
drivers/gpu/drm/i915/i915_reg.h | 73 +
1 file changed, 73 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h
From: Chaitanya Kumar Borah
Add framework that will help in loading LUT to Pre/Post CSC color
blocks.
Signed-off-by: Chaitanya Kumar Borah
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_color.c | 27 ++
drivers/gpu/drm/i915/display/intel_color.h | 2 ++
Add macros to define Plane Degamma registers
Signed-off-by: Uma Shankar
Signed-off-by: Chaitanya Kumar Borah
---
drivers/gpu/drm/i915/i915_reg.h | 51 +
1 file changed, 51 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h
Add callback for setting CTM block in platforms TGL and beyond
Signed-off-by: Chaitanya Kumar Borah
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_color.c | 79 ++
1 file changed, 79 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
From: Chaitanya Kumar Borah
Add callback to intel color functions for setting plane CTM.
Signed-off-by: Chaitanya Kumar Borah
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_color.c | 22 ++
drivers/gpu/drm/i915/display/intel_color.h | 2 ++
2 files
From: Chaitanya Kumar Borah
Add infrastructure to set colorop. We iterate through all the color ops
in a selected COLOR PIPELINE and set them one by one.
Signed-off-by: Chaitanya Kumar Borah
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_color.c | 31 ++
From: Chaitanya Kumar Borah
Add supported color pipelines and attach it to plane.
Signed-off-by: Chaitanya Kumar Borah
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_color.c | 37 ++
drivers/gpu/drm/i915/display/intel_color.h | 3 ++
2 files changed,
This defines the lut segments and create the color pipeline
Signed-off-by: Uma Shankar
Signed-off-by: Chaitanya Kumar Borah
---
drivers/gpu/drm/i915/display/intel_color.c | 109 +
1 file changed, 109 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
From: Chaitanya Kumar Borah
Add a color pipeline with three colorops in the sequence
1D LUT - CTM - 1D LUT
This pipeline can be used to do any color space conversion or HDR
tone mapping
Signed-off-by: Chaitanya Kumar Borah
Signed-off-by: Uma Shankar
---
From: Chaitanya Kumar Borah
Add intel colorop create helper
Signed-off-by: Chaitanya Kumar Borah
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_color.c | 14 ++
drivers/gpu/drm/i915/display/intel_color.h | 2 ++
2 files changed, 16 insertions(+)
diff --git
From: Chaitanya Kumar Borah
Add helper to allocate memory for intel colorop
Signed-off-by: Chaitanya Kumar Borah
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_color.c | 25 ++
drivers/gpu/drm/i915/display/intel_color.h | 1 +
2 files changed, 26
From: Chaitanya Kumar Borah
Add data structure to store intel specific details of colorop
Signed-off-by: Chaitanya Kumar Borah
Signed-off-by: Uma Shankar
---
.../gpu/drm/i915/display/intel_display_types.h | 17 +
1 file changed, 17 insertions(+)
diff --git
From: Chaitanya Kumar Borah
Add macros to identify intel color blocks. It will help
in mapping drm_color_ops to intel color HW blocks
Signed-off-by: Chaitanya Kumar Borah
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_display_limits.h | 13 +
1 file changed, 13
This adds helper functions to create 1D Lut color block
capabilities. It exposes the hardware block as segments
which are converted to blob and passed in the property.
Signed-off-by: Chaitanya Kumar Borah
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/drm_colorop.c | 24
Add a helper to create capability property for a colorop
Signed-off-by: Uma Shankar
Signed-off-by: Chaitanya Kumar Borah
---
drivers/gpu/drm/drm_colorop.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/drm_colorop.c b/drivers/gpu/drm/drm_colorop.c
Add capability property which a colorop can expose it's
hardware's abilities. It's a blob property that can be
filled with respective data structures depending on the
colorop. The user space is expected to read this property
and program the colorop accordingly.
Signed-off-by: Uma Shankar
This defines a new structure to define color lut ranges,
along with related macro definitions and enums. This will help
describe segmented lut ranges/PWL LUTs in the hardware.
Signed-off-by: Uma Shankar
Signed-off-by: Chaitanya Kumar Borah
---
include/uapi/drm/drm_mode.h | 58
From: Chaitanya Kumar Borah
Add support for color ops that can be programmed
by 1 dimensional Look Up Tables.
Signed-off-by: Chaitanya Kumar Borah
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/drm_atomic_uapi.c | 3 +++
drivers/gpu/drm/drm_colorop.c | 2 +-
include/uapi/drm/drm_mode.h
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.
Signed-off-by: Uma Shankar
Signed-off-by: Chaitanya Kumar Borah
---
From: Chaitanya Kumar Borah
Add support for 3x3 Color Transformation Matrices in Color Pipeline.
Signed-off-by: Chaitanya Kumar Borah
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/drm_atomic_uapi.c | 3 +++
drivers/gpu/drm/drm_colorop.c | 2 +-
include/uapi/drm/drm_mode.h | 1 +
3
From: Chaitanya Kumar Borah
Fix error logging in set Color Pipeline
Note: This patch can be squashed with the following patch
("drm/colorop: Introduce DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE") [1]
[1] https://patchwork.freedesktop.org/patch/566623/?series=123446=3
Signed-off-by: Chaitanya Kumar
From: Chaitanya Kumar Borah
In scenarios, where there is only one colorop in a colorpipeline,
the user of the helper drm_colorop_set_next_property could use it
to set the next colorop as NULL explicitly. Make the helper handle
this case.
Note: This patch can be squashed with following patch
From: Chaitanya Kumar Borah
add missing declarations to avoid warnings.
Note: This patch should be squashed with patches it fixes
in the colorop series by Harry [1]
("drm/colorop: Introduce new drm_colorop mode object") [2]
("drm/plane: Add COLOR PIPELINE property") [3]
[1]
From: Harry Wentland
This is a squashed patch based on a series sent out by Harry wentland.
It contains all the changes in the series(v3) currently under review
below.
https://patchwork.freedesktop.org/patch/566614/?series=123446=3
This patch lays the ground work for incremental changes and
This series intends to add support for Plane Color Management for
Intel platforms. This is based on the design which has been agreed
upon by the community. Series implementing the design for generic
DRM core has been sent out by Harry Wentland and is under review
below:
Fix some typos and punctuation.
Signed-off-by: Randy Dunlap
Cc: Alex Deucher
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
---
v2: s/instances/instance/ (Alex)
v3: rebase and resend;
add more Cc:s
* Rob Herring [240212 13:51]:
> On Mon, Feb 12, 2024 at 12:30:12PM +0100, Krzysztof Kozlowski wrote:
> > On 12/02/2024 09:17, Tony Lindgren wrote:
> > > usage: yamllint [-h] [-] [-c CONFIG_FILE | -d CONFIG_DATA] [--list-files]
> > > [-f {parsable,standard,colored,github,auto}] [-s]
Hi Thomas,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on linus/master v6.8-rc4 next-20240212]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: ae00c445390b349e070a64dc62f08aa878db7248 Add linux-next specific
files for 20240212
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202402122047.ydhrzmm4-...@intel.com
https
On Mon, Feb 12, 2024 at 04:16:41PM +0100, Thomas Gleixner wrote:
> On Tue, Jan 30 2024 at 11:58, Byungchul Park wrote:
> > On Fri, Jan 26, 2024 at 06:30:02PM +0100, Thomas Gleixner wrote:
> >> On Wed, Jan 24 2024 at 20:59, Byungchul Park wrote:
> >>
> >> Why is lockdep in the subsystem prefix
Hi all,
After merging the drm-misc tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/gpu/drm/xe/xe_guc_submit.c: In function 'simple_error_capture':
drivers/gpu/drm/xe/xe_guc_submit.c:814:48: error: passing argument 1 of
'drm_err_printer' from incompatible pointer
After destroying dmub_srv, the memory associated with it is
not freed, causing a memory leak:
unreferenced object 0x896302b45800 (size 1024):
comm "(udev-worker)", pid 222, jiffies 4294894636
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Hi John,
On Wed, Jan 10, 2024 at 01:02:16PM -0800, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> The context persistence code does things like send super high priority
> heartbeat pulses to ensure any leaked context can still be pre-empted
> and thus isn't a total denial of service
From: Prike Liang
[ Upstream commit 6ef82ac664bb9568ca3956e0d9c9c478e25077ff ]
In the s3 suspend abort case some type of gfx9 power
rail not turn off from FCH side and this will put the
GPU in an unknown power status, so let's reset the gpu
to a known good power state before reinitialize gpu
From: Prike Liang
[ Upstream commit 93bafa32a6918154aa0caf9f66679a32c2431357 ]
In the suspend abort cases, the gfx power rail doesn't turn off so
some GFXDEC registers/CSB can't reset to default value and at this
moment reinitialize GFXDEC/CSB will result in an unexpected error.
So let skip
From: Prike Liang
[ Upstream commit 6ef82ac664bb9568ca3956e0d9c9c478e25077ff ]
In the s3 suspend abort case some type of gfx9 power
rail not turn off from FCH side and this will put the
GPU in an unknown power status, so let's reset the gpu
to a known good power state before reinitialize gpu
From: Prike Liang
[ Upstream commit 93bafa32a6918154aa0caf9f66679a32c2431357 ]
In the suspend abort cases, the gfx power rail doesn't turn off so
some GFXDEC registers/CSB can't reset to default value and at this
moment reinitialize GFXDEC/CSB will result in an unexpected error.
So let skip
From: Lijo Lazar
[ Upstream commit 534c8a5b9d5d41d30cdcac93cfa1bca5e17be009 ]
HDP flush remapping is not done for VFs. Keep the original offsets in VF
environment.
Signed-off-by: Lijo Lazar
Reviewed-by: Hawking Zhang
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
From: "Stanley.Yang"
[ Upstream commit 2dcf82a8e8dc930655787797ef8a3692b527c7a9 ]
ta if invoke node buffer
| ta type --|
| ta id --|
| cmd id --|
|-- shared buf len -|
|-- shared buffer --|
ta if invoke node buffer is as above,
From: Prike Liang
[ Upstream commit 6ef82ac664bb9568ca3956e0d9c9c478e25077ff ]
In the s3 suspend abort case some type of gfx9 power
rail not turn off from FCH side and this will put the
GPU in an unknown power status, so let's reset the gpu
to a known good power state before reinitialize gpu
From: Prike Liang
[ Upstream commit 93bafa32a6918154aa0caf9f66679a32c2431357 ]
In the suspend abort cases, the gfx power rail doesn't turn off so
some GFXDEC registers/CSB can't reset to default value and at this
moment reinitialize GFXDEC/CSB will result in an unexpected error.
So let skip
From: Krystian Pradzynski
[ Upstream commit 553099da45397914a995dce6307d6c26523c2567 ]
This parameter was never used by the 40xx FW.
Signed-off-by: Krystian Pradzynski
Signed-off-by: Jacek Lawrynowicz
Reviewed-by: Jeffrey Hugo
Link:
From: Jacek Lawrynowicz
[ Upstream commit a7f31091ddf457352e3dd7ac183fdbd26b4dcd04 ]
NPU does not require this delay regardless of the generation.
All generations are integrated into the SOC.
Signed-off-by: Jacek Lawrynowicz
Reviewed-by: Jeffrey Hugo
Link:
From: "Wachowski, Karol"
[ Upstream commit c9da9a1f17bf4fa96b115950fd389c917b583c1c ]
Set AW_SNOOP_OVERRIDE bit in VPU_37/40XX_HOST_IF_TCU_PTW_OVERRIDES
to force snooping for MMU write accesses (setting event queue events).
MMU event queue buffer is the only buffer written by MMU and
mapped as
From: Lijo Lazar
[ Upstream commit 534c8a5b9d5d41d30cdcac93cfa1bca5e17be009 ]
HDP flush remapping is not done for VFs. Keep the original offsets in VF
environment.
Signed-off-by: Lijo Lazar
Reviewed-by: Hawking Zhang
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
From: "Stanley.Yang"
[ Upstream commit 2dcf82a8e8dc930655787797ef8a3692b527c7a9 ]
ta if invoke node buffer
| ta type --|
| ta id --|
| cmd id --|
|-- shared buf len -|
|-- shared buffer --|
ta if invoke node buffer is as above,
From: Prike Liang
[ Upstream commit 6ef82ac664bb9568ca3956e0d9c9c478e25077ff ]
In the s3 suspend abort case some type of gfx9 power
rail not turn off from FCH side and this will put the
GPU in an unknown power status, so let's reset the gpu
to a known good power state before reinitialize gpu
From: Prike Liang
[ Upstream commit 93bafa32a6918154aa0caf9f66679a32c2431357 ]
In the suspend abort cases, the gfx power rail doesn't turn off so
some GFXDEC registers/CSB can't reset to default value and at this
moment reinitialize GFXDEC/CSB will result in an unexpected error.
So let skip
From: "Wachowski, Karol"
[ Upstream commit c9da9a1f17bf4fa96b115950fd389c917b583c1c ]
Set AW_SNOOP_OVERRIDE bit in VPU_37/40XX_HOST_IF_TCU_PTW_OVERRIDES
to force snooping for MMU write accesses (setting event queue events).
MMU event queue buffer is the only buffer written by MMU and
mapped as
From: Krystian Pradzynski
[ Upstream commit 553099da45397914a995dce6307d6c26523c2567 ]
This parameter was never used by the 40xx FW.
Signed-off-by: Krystian Pradzynski
Signed-off-by: Jacek Lawrynowicz
Reviewed-by: Jeffrey Hugo
Link:
From: Jacek Lawrynowicz
[ Upstream commit a7f31091ddf457352e3dd7ac183fdbd26b4dcd04 ]
NPU does not require this delay regardless of the generation.
All generations are integrated into the SOC.
Signed-off-by: Jacek Lawrynowicz
Reviewed-by: Jeffrey Hugo
Link:
From: Timur Tabi
[ Upstream commit 34e659f34a7559ecfd9c1f5b24d4c291f3f54711 ]
Function nvkm_gsp_radix3_sg() uses nvkm_gsp_mem objects to allocate the
radix3 tables, but it unnecessarily creates those objects manually
instead of using the standard nvkm_gsp_mem_ctor() function like the
rest of
On 2/12/2024 1:20 PM, Dmitry Baryshkov wrote:
On Mon, 12 Feb 2024 at 23:13, Abhinav Kumar wrote:
On 2/10/2024 1:17 PM, Dmitry Baryshkov wrote:
On Sat, 10 Feb 2024 at 21:19, Abhinav Kumar wrote:
On 2/10/2024 3:33 AM, Dmitry Baryshkov wrote:
On Sat, 10 Feb 2024 at 03:52, Paloma
On 2/12/2024 1:55 PM, Rob Clark wrote:
From: Rob Clark
DRM_MODESET_LOCK_ALL_BEGIN() has a hidden trap-door (aka retry loop),
which means we can't rely too much on variable initializers.
Fixes: 6e455f5dcdd1 ("drm/crtc: fix uninitialized variable use")
Signed-off-by: Rob Clark
---
I have
On Mon, Feb 12, 2024 at 1:55 PM Rob Clark wrote:
>
> From: Rob Clark
>
> DRM_MODESET_LOCK_ALL_BEGIN() has a hidden trap-door (aka retry loop),
> which means we can't rely too much on variable initializers.
>
> Fixes: 6e455f5dcdd1 ("drm/crtc: fix uninitialized variable use")
> Signed-off-by: Rob
From: Rob Clark
DRM_MODESET_LOCK_ALL_BEGIN() has a hidden trap-door (aka retry loop),
which means we can't rely too much on variable initializers.
Fixes: 6e455f5dcdd1 ("drm/crtc: fix uninitialized variable use")
Signed-off-by: Rob Clark
---
I have mixed feelings about
On Mon, 12 Feb 2024 at 23:13, Abhinav Kumar wrote:
>
>
>
> On 2/10/2024 1:17 PM, Dmitry Baryshkov wrote:
> > On Sat, 10 Feb 2024 at 21:19, Abhinav Kumar
> > wrote:
> >>
> >>
> >>
> >> On 2/10/2024 3:33 AM, Dmitry Baryshkov wrote:
> >>> On Sat, 10 Feb 2024 at 03:52, Paloma Arellano
> >>>
On 2/12/2024 10:31, Mario Limonciello wrote:
On 2/10/2024 23:50, Mario Limonciello wrote:
Some manufacturers have intentionally put an EDID that differs from
the EDID on the internal panel on laptops. Drivers that prefer to
fetch this EDID can set a bit on the drm_connector to indicate that
The LOGINIT, LOGINTR, LOGRM, and LOGPMU buffers are circular buffers
that have printf-like logs from GSP-RM and PMU encoded in them.
LOGINIT, LOGINTR, and LOGRM are allocated by Nouveau and their DMA
addresses are passed to GSP-RM during initialization. The buffers are
required for GSP-RM to
Add the NVreg_RegistryDwords command line parameter, which allows
specifying additional registry keys to be sent to GSP-RM. This
allows additional configuration, debugging, and experimentation
with GSP-RM, which uses these keys to alter its behavior.
Note that these keys are passed as-is to
Two patches that were previosly posted, but now updated for drm-next.
Timur Tabi (2):
[v3] nouveau: add command-line GSP-RM registry support
[v3] drm/nouveau: expose GSP-RM logging buffers via debugfs
.../gpu/drm/nouveau/include/nvkm/subdev/gsp.h | 18 +
On 2/12/2024 10:49 AM, Chris Morgan wrote:
From: Chris Morgan
The Powkiddy RGB10MAX3 is a handheld device with a 5 inch 720x1280
display panel with a Sitronix ST7703 display controller. The panel
is installed rotated 270 degrees.
Signed-off-by: Chris Morgan
Hi Chris,
Reviewed-by:
On 2/10/2024 1:17 PM, Dmitry Baryshkov wrote:
On Sat, 10 Feb 2024 at 21:19, Abhinav Kumar wrote:
On 2/10/2024 3:33 AM, Dmitry Baryshkov wrote:
On Sat, 10 Feb 2024 at 03:52, Paloma Arellano wrote:
All the components of YUV420 over DP are added. Therefore, let's mark the
connector
Add shared stats. Useful for seeing shared memory.
v2: take dma-buf into account as well
v3: use the new gem helper
Link:
https://lore.kernel.org/all/20231207180225.439482-1-alexander.deuc...@amd.com/
Signed-off-by: Alex Deucher
Cc: Rob Clark
---
drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c |
Switch to using the new gem shared memory stats helper
rather than hand rolling it.
Link:
https://lore.kernel.org/all/20231207180225.439482-1-alexander.deuc...@amd.com/
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/xe/xe_drm_client.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Add a helper so that drm drivers can consistently report
shared status via the fdinfo shared memory stats interface.
In addition to handle count, show buffers as shared if they
are shared via dma-buf as well (e.g., shared with v4l or some
other subsystem).
v2: switch to inline function
Link:
Switch to using the new gem shared memory stats helper
rather than hand rolling it.
Link:
https://lore.kernel.org/all/20231207180225.439482-1-alexander.deuc...@amd.com/
Reviewed-by: Tvrtko Ursulin
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/i915/i915_drm_client.c | 2 +-
1 file changed, 1
Clarify the documentation in preparation for updated
helpers which check the handle count as well as whether
a dma-buf has been attached.
Link:
https://lore.kernel.org/all/20231207180225.439482-1-alexander.deuc...@amd.com/
Reviewed-by: Tvrtko Ursulin
Signed-off-by: Alex Deucher
---
Show buffers as shared if they are shared via dma-buf as well
(e.g., shared with v4l or some other subsystem).
v2: switch to gem helper
Link:
https://lore.kernel.org/all/20231207180225.439482-1-alexander.deuc...@amd.com/
Reviewed-by: Rob Clark (v1)
Reviewed-by: Tvrtko Ursulin
Signed-off-by:
We had a request to add shared buffer stats to fdinfo for amdgpu and
while implementing that, Christian mentioned that just looking at
the GEM handle count doesn't take into account buffers shared with other
subsystems like V4L or RDMA. Those subsystems don't use GEM, so it
doesn't really matter
tree: git://anongit.freedesktop.org/drm/drm-misc for-linux-next
head: 247f2ee4498cfcaf18b3c3486dffd2302d56fc17
commit: 5e0c04c8c40b69ab165d52964433859d8b666376 [40/49] drm/print: make
drm_err_printer() device specific by using drm_err()
config: alpha-allyesconfig
set"
leds: expresswire: don't depend on NEW_LEDS
drivers/Makefile | 2 +-
drivers/leds/Kconfig | 10 ++
2 files changed, 7 insertions(+), 5 deletions(-)
---
base-commit: ae00c445390b349e070a64dc62f08aa878db7248
change-id: 20240212-expresswire-deps-e895e8da8ea3
Best regards
This reverts commit b1ae40a5db6191c42e2e45d726407096f030ee08.
The ExpressWire library introduced in 25ae5f5f4168 ("leds: Introduce
ExpressWire library") does not depend on NEW_LEDS, but without this
revert it would never get compiled if NEW_LEDS is not enabled. Revert
this commit to allow the
The ExpressWire library does not depend on NEW_LEDS and selecting it
from a subsystem other than LEDs may cause Kconfig warnings:
WARNING: unmet direct dependencies detected for LEDS_EXPRESSWIRE
Depends on [n]: NEW_LEDS [=n] && GPIOLIB [=y]
Selected by [y]:
- BACKLIGHT_KTD2801 [=y] &&
Hi Thomas,
kernel test robot noticed the following build errors:
[auto build test ERROR on drm-misc/drm-misc-next]
[also build test ERROR on linus/master v6.8-rc4 next-20240212]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use
Hi Thomas,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on linus/master v6.8-rc4 next-20240212]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest
On Mon, Feb 12, 2024, at 15:31, Duje Mihanović wrote:
> On Monday, February 12, 2024 1:44:28 PM CET Daniel Thompson wrote:
>> On Mon, Feb 12, 2024 at 12:18:12PM +0100, Arnd Bergmann wrote:
> I believe this would be the best thing to do here. Making LEDS_EXPRESSWIRE
> user selectable doesn't make
On 2/11/24 23:13, Thomas Zimmermann wrote:
> Hi
>
> Am 12.02.24 um 05:28 schrieb Randy Dunlap:
>> Correct spellos/typos in comments.
>>
>> Signed-off-by: Randy Dunlap
>> Cc: Thomas Zimmermann
>> Cc: dri-devel@lists.freedesktop.org
>> ---
>> include/linux/iosys-map.h | 4 ++--
>> 1 file
From: Chris Morgan
The Powkiddy RGB10MAX3 is a handheld device with a 5 inch 720x1280
display panel with a Sitronix ST7703 display controller. The panel
is installed rotated 270 degrees.
Signed-off-by: Chris Morgan
---
drivers/gpu/drm/panel/panel-sitronix-st7703.c | 91 +++
1
From: Chris Morgan
Add support for panel rotation to ST7703 based devices.
Signed-off-by: Chris Morgan
---
drivers/gpu/drm/panel/panel-sitronix-st7703.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
From: Chris Morgan
Move the vdd_cpu regulator to the device specific dts. This is in
preparation of adding the Powkiddy RGB10MAX3 device, which uses
a different vendor for the CPU regulator at a different i2c address.
Also add an alias to the bluetooth device so that we can change the
From: Chris Morgan
The RGB10MAX3 panel is a panel specific to the Powkiddy RGB10MAX3
handheld device that measures 5 inches diagonally with a resolution
of 720x1280.
Signed-off-by: Chris Morgan
---
.../devicetree/bindings/display/panel/rocktech,jh057n00900.yaml | 2 ++
1 file changed, 2
From: Chris Morgan
Add support for the Powkiddy RGB10MAX3 handheld gaming console.
[1]
https://powkiddy.com/products/pre-sale-powkiddy-rgb10max3-handheld-game-console
Chris Morgan (7):
dt-bindings: display: st7703: Add Powkiddy RGB10MAX3 panel
drm/panel: st7703: Add Powkiddy RGB10MAX3
From: Chris Morgan
Document the rotation property for ST7703 based panels.
Signed-off-by: Chris Morgan
---
.../devicetree/bindings/display/panel/rocktech,jh057n00900.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git
From: Chris Morgan
Add support for the Powkiddy RGB10MAX3. The Powkiddy RGB10MAX3 is a
handheld gaming device with a 720p 5.0 inch screen powered by the
Rockchip RK3566 SoC. It includes a Realtek 8723ds WiFi/BT module, 2 ADC
joysticks powered by a 4-way muxed ADC channel, and several GPIO
face
From: Chris Morgan
The Powkiddy RGB10MAX3 is a handheld gaming device made by Powkiddy and
powered by the Rockchip RK3566 SoC.
Signed-off-by: Chris Morgan
---
Documentation/devicetree/bindings/arm/rockchip.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git
On 2/10/2024 2:50 AM, Dmitry Baryshkov wrote:
On Sat, 10 Feb 2024 at 03:52, Paloma Arellano wrote:
Adjust the encoder timing engine setup programming in the case of video
mode for YUV420 over DP to accommodate CDM.
Changes in v2:
- Move timing engine programming to this patch
On 2/10/2024 10:15 PM, Dmitry Baryshkov wrote:
On Sun, 11 Feb 2024 at 06:12, Abhinav Kumar wrote:
On 2/10/2024 2:11 PM, Dmitry Baryshkov wrote:
On Sat, 10 Feb 2024 at 23:49, Abhinav Kumar wrote:
On 2/10/2024 2:16 AM, Dmitry Baryshkov wrote:
On Sat, 10 Feb 2024 at 03:52, Paloma
On 2/10/2024 1:55 AM, Dmitry Baryshkov wrote:
On Sat, 10 Feb 2024 at 03:52, Paloma Arellano wrote:
Parity calculation is necessary for VSC SDP implementation. Therefore
create new files dp_utils.c and dp_utils.h and move the parity
calculating functions here. This ensures that they are
From: Paloma Arellano
YUV420 format is supported only in the VSC SDP packet and not through
MSA. Hence add an API which indicates the sink support which can be used
by the rest of the DP programming.
changes in v4:
- bail out early if dpcd rev check fails
changes in v3:
- fix
Hello Thomas,
On Mon, Feb 12, 2024 at 05:16:39PM +0100, Thomas Zimmermann wrote:
> The internal check_fb callback from struct pwm_bl_data is never
> implemented. thus the driver's implementation of check_fb always
> returns true, which is the backlight core's default if no
> implementation has
https://bugzilla.kernel.org/show_bug.cgi?id=218483
Artem S. Tashkinov (a...@gmx.com) changed:
What|Removed |Added
Status|NEW |RESOLVED
On Mon, Feb 12, 2024 at 05:53:48PM +0100, Maxime Ripard wrote:
> On Mon, Feb 12, 2024 at 05:49:33PM +0200, Ville Syrjälä wrote:
> > On Mon, Feb 12, 2024 at 11:01:07AM +0100, Maxime Ripard wrote:
> > > On Fri, Feb 09, 2024 at 09:34:35PM +0100, Sebastian Wick wrote:
> > > > On Mon, Feb 05, 2024 at
On Mon, Feb 12, 2024 at 05:39:03PM +0100, Hans Verkuil wrote:
> On 12/02/2024 16:49, Ville Syrjälä wrote:
> > On Mon, Feb 12, 2024 at 11:01:07AM +0100, Maxime Ripard wrote:
> >> On Fri, Feb 09, 2024 at 09:34:35PM +0100, Sebastian Wick wrote:
> >>> On Mon, Feb 05, 2024 at 10:39:38AM +0100, Maxime
On Mon, Feb 12, 2024 at 05:49:33PM +0200, Ville Syrjälä wrote:
> On Mon, Feb 12, 2024 at 11:01:07AM +0100, Maxime Ripard wrote:
> > On Fri, Feb 09, 2024 at 09:34:35PM +0100, Sebastian Wick wrote:
> > > On Mon, Feb 05, 2024 at 10:39:38AM +0100, Maxime Ripard wrote:
> > > > On Fri, Feb 02, 2024 at
1 - 100 of 248 matches
Mail list logo
