The Hardkernel ODROID-GO Ultra is a handheld gaming devices, with
a 5 inch 480x854 display. Add support for the display.
Signed-off-by: Adam Green
---
drivers/gpu/drm/panel/panel-sitronix-st7701.c | 158 +-
1 file changed, 157 insertions(+), 1 deletion(-)
diff --git
Hi David,
Thanks for fixing drivers/rtc/lib_test.c
Best wishes,
Cassio.
On Wed, 21 Feb 2024 at 09:28, David Gow wrote:
> 'days' is a s64 (from div_s64), and so should use a %lld specifier.
>
> This was found by extending KUnit's assertion macros to use gcc's
> __printf attribute.
>
> Fixes:
Hi David,
Thanks for fixing kernel/time/time_test.c
Best wishes,
Cassio.
On Wed, 21 Feb 2024 at 09:28, David Gow wrote:
> 'days' is a s64 (from div_s64), and so should use a %lld specifier.
>
> This was found by extending KUnit's assertion macros to use gcc's
> __printf attribute.
>
> Fixes:
Hi Biju,
On Thu, Feb 22, 2024 at 9:14 AM Biju Das wrote:
> > -Original Message-
> > From: Stephen Rothwell
> > Sent: Thursday, February 22, 2024 1:46 AM
> > Subject: linux-next: build failure after merge of the drm-misc tree
> >
> > After merging the drm-misc tree, today's linux-next
Hi Biju,
On Thu, Feb 22, 2024 at 08:14:14AM +, Biju Das wrote:
> > -Original Message-
> > From: Stephen Rothwell
> > Sent: Thursday, February 22, 2024 1:46 AM
> > Subject: linux-next: build failure after merge of the drm-misc tree
> >
> > Hi all,
> >
> > After merging the drm-misc
On Thu, 2024-02-22 at 08:34 +0100, Thomas Hellström wrote:
> On Wed, 2024-02-21 at 11:26 +0100, Christian König wrote:
> > Am 21.02.24 um 08:33 schrieb Thomas Hellström:
> > > If caching mode change fails due to, for example, OOM we
> > > free the allocated pages in a two-step process. First the
Il 21/02/24 17:56, Justin Green ha scritto:
Add MT8188 overlay driver configuration data. This change consequently
enables 10-bit overlay support on MT8188 devices.
Tested by running ChromeOS UI on MT8188 and using modetest -P. AR30 and
BA30 overlays are confirmed to work from modetest.
Hi All,
> -Original Message-
> From: Stephen Rothwell
> Sent: Thursday, February 22, 2024 1:46 AM
> Subject: linux-next: build failure after merge of the drm-misc tree
>
> Hi all,
>
> After merging the drm-misc tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
Hi Maxime Ripard,
> -Original Message-
> From: Maxime Ripard
> Sent: Thursday, February 22, 2024 8:32 AM
> To: Biju Das
> Subject: Re: linux-next: build failure after merge of the drm-misc tree
>
> Hi Biju,
>
> On Thu, Feb 22, 2024 at 08:14:14AM +, Biju Das wrote:
> > >
On 2/22/24 00:19, Bjorn Andersson wrote:
The newly introduced mechanism for selecting eDP mode allow us to make a
DisplayPort controller operate in eDP mode, but not the other way
around. The qcom,sc7280-edp compatible is obviously tied to eDP, so this
would not allow us to select
On 2/22/24 00:41, Dmitry Baryshkov wrote:
On Thu, 22 Feb 2024 at 01:19, Bjorn Andersson wrote:
The max frequency listed in the DPU opp-table is 506MHz, this is not
sufficient to drive a 4k@60 display, resulting in constant underrun.
Add the missing MDP_CLK turbo frequency of 608MHz to the
On 2/22/24 00:19, Bjorn Andersson wrote:
The max frequency listed in the DPU opp-table is 506MHz, this is not
sufficient to drive a 4k@60 display, resulting in constant underrun.
Add the missing MDP_CLK turbo frequency of 608MHz to the opp-table to
fix this.
Signed-off-by: Bjorn
On 2/22/24 00:19, Bjorn Andersson wrote:
The RB3gen2 has a USB redriver on APPS_I2C, enable the bus and introduce
the redriver. The plumbing with other components is kept separate for
clarity.
Signed-off-by: Bjorn Andersson
---
Any chance you could add an alias for this I2C bus?
Or all
On Wed, 21 Feb 2024 23:17:52 +0100
Pavel Machek wrote:
> Hi!
>
> > so after more feedback from the OpenRGB maintainers I came up with an even
> > more generic proposal:
> > https://gitlab.com/CalcProgrammer1/OpenRGB/-/issues/3916#note_1753072869
>
> > >evaluate-set-command ioctl taking:
> >
On Thu, 22 Feb 2024 at 10:56, Konrad Dybcio wrote:
>
>
>
> On 2/22/24 00:41, Dmitry Baryshkov wrote:
> > On Thu, 22 Feb 2024 at 01:19, Bjorn Andersson
> > wrote:
> >>
> >> The max frequency listed in the DPU opp-table is 506MHz, this is not
> >> sufficient to drive a 4k@60 display, resulting in
Hi Geert,
Thanks for the feedback.
> -Original Message-
> From: Geert Uytterhoeven
> Sent: Thursday, February 22, 2024 8:29 AM
> Subject: Re: linux-next: build failure after merge of the drm-misc tree
>
> Hi Biju,
>
> On Thu, Feb 22, 2024 at 9:14 AM Biju Das
> wrote:
> > >
Hi, Dmitry
Thanks for review and comment.
> -Original Message-
> From: Dmitry Baryshkov
> Sent: 2024年2月7日 18:58
> To: Shengyang Chen
> Cc: devicet...@vger.kernel.org; dri-devel@lists.freedesktop.org;
> andrzej.ha...@intel.com; neil.armstr...@linaro.org; rf...@kernel.org;
>
On 2/22/24 10:04, Dmitry Baryshkov wrote:
On Thu, 22 Feb 2024 at 10:56, Konrad Dybcio wrote:
On 2/22/24 00:41, Dmitry Baryshkov wrote:
On Thu, 22 Feb 2024 at 01:19, Bjorn Andersson wrote:
The max frequency listed in the DPU opp-table is 506MHz, this is not
sufficient to drive a 4k@60
On 22/02/2024 00:19, Bjorn Andersson wrote:
With MDSS, pmic_glink, and the redriver in place, wire up the various
components to enable USB Type-C display on the RB3gen2.
Signed-off-by: Bjorn Andersson
---
arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts | 63 +++-
1 file
Am 21.02.24 um 19:01 schrieb Rodrigo Siqueira Jordao:
[SNIP]
diff --git
a/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_resource_helpers.c
b/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_resource_helpers.c
index 87760600e154..e179dea148e7 100644
---
On Thu, 22 Feb 2024 at 11:28, Konrad Dybcio wrote:
>
>
>
> On 2/22/24 10:04, Dmitry Baryshkov wrote:
> > On Thu, 22 Feb 2024 at 10:56, Konrad Dybcio
> > wrote:
> >>
> >>
> >>
> >> On 2/22/24 00:41, Dmitry Baryshkov wrote:
> >>> On Thu, 22 Feb 2024 at 01:19, Bjorn Andersson
> >>> wrote:
>
Am 22.02.24 um 08:34 schrieb Thomas Hellström:
On Wed, 2024-02-21 at 11:26 +0100, Christian König wrote:
Am 21.02.24 um 08:33 schrieb Thomas Hellström:
If caching mode change fails due to, for example, OOM we
free the allocated pages in a two-step process. First the pages
for which the caching
On Wed, 2024-02-21 at 17:27 +0800, David Gow wrote:
> KUNIT_FAIL() is used to fail the xe_migrate test when an error
> occurs.
> However, there's a mismatch in the format specifier: '%li' is used to
> log 'err', which is an 'int'.
>
> Use '%i' instead of '%li', and for the case where we're
Fix the redefinition errors for the below functions on x86 by replacing
CONFIG_DRM_RCAR_VSP->IS_ENABLED(CONFIG_VIDEO_RENESAS_VSP1) and adding
EXPORT_SYMBOL_GPL for all:
1) rzg2l_du_vsp_init()
2) rzg2l_du_vsp_enable()
3) rzg2l_du_vsp_disable()
4) rzg2l_du_vsp_atomic_flush()
5)
On 2/22/24 10:46, Dmitry Baryshkov wrote:
On Thu, 22 Feb 2024 at 11:28, Konrad Dybcio wrote:
On 2/22/24 10:04, Dmitry Baryshkov wrote:
On Thu, 22 Feb 2024 at 10:56, Konrad Dybcio wrote:
On 2/22/24 00:41, Dmitry Baryshkov wrote:
On Thu, 22 Feb 2024 at 01:19, Bjorn Andersson wrote:
On 2/22/24 06:58, Marek Behún wrote:
A few drivers are doing resource-managed mutex initialization by
implementing ad-hoc one-liner mutex dropping functions and using them
with devm_add_action_or_reset(). Help drivers avoid these repeated
one-liners by adding managed version of mutex
Since this new platform supports both DP and eDP, it's the perfect time
to drop the dual compatible (eDP and DP) and figure out a different way
to specify the mode. After some off-list discussion, one suggested way
was to add a 'is-edp' property to the controller node and call
phy_set_mode to let
Add the X1E80100 to the list of compatibles and document the is-edp
flag. The controllers are expected to operate in DP mode by default,
and this flag can be used to select eDP mode.
Signed-off-by: Abel Vesa
---
Documentation/devicetree/bindings/display/msm/dp-controller.yaml | 6 ++
1 file
Instead of relying on different compatibles for eDP and DP, use
the is-edp property from DT to figure out the connector type and
then pass on that information to the PHY.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Abel Vesa
---
drivers/gpu/drm/msm/dp/dp_ctrl.c| 11 +++
Add the X1E80100 DP descs and compatible. This platform will be using
a single compatible for both eDP and DP mode. The actual mode will
be set in devicetree via is-edp flag.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Abel Vesa
---
drivers/gpu/drm/msm/dp/dp_display.c | 9 +
1 file
On 2/22/24 7:58 AM, Marek Behún wrote:
> A few drivers register a devm action to remove a debugfs directory,
> implementing a one-liner function that calls debufs_remove_recursive().
> Help drivers avoid this repeated implementations by adding managed
> version of debugfs directory create
Hi!
> > Yeah, so ... this is not a interface. This is a backdoor to pass
> > arbitrary data. That's not going to fly.
>
> Pavel, Note the data will be interpreted by a kernel driver and
> not passed directly to the hw.
Yes, still not flying :-).
> With that said I tend to agree that this seems
On 22/02/2024 17:43, Adam Green wrote:
> The ODROID-GO Ultra panel is a panel specific to the Hardkernel
> ODROID-GO Ultra. It is 5 inches in size (diagonally) with a
> resolution of 480x854.
>
> Signed-off-by: Adam Green
> ---
Acked-by: Krzysztof Kozlowski
Best regards,
Krzysztof
On Wed, Feb 21, 2024 at 10:22 PM David Gow wrote:
>
> On Thu, 22 Feb 2024 at 04:10, 'Justin Stitt' via KUnit Development
> wrote:
> >
> > Hi,
> >
> > On Wed, Feb 21, 2024 at 05:27:15PM +0800, David Gow wrote:
> > > The correct format specifier for p - n (both p and n are pointers) is
> > > %td,
Hi!
> > To be honest, I think the kernel shouldn't include too much high-level
> > complexity. If there is a desire to implement a generic display device on
> > top of the RGB device, this should be a configurable service running in
> > user space. The kernel should provide an interface to
On Mon, 19 Feb 2024 13:14:23 +, Tvrtko Ursulin wrote:
> Request can be NULL if no guilty request was identified so simply use
> engine->i915 instead.
>
>
Applied to drm/drm-misc (drm-misc-next-fixes).
Thanks!
Maxime
The ODROID-GO Ultra panel is a panel specific to the Hardkernel
ODROID-GO Ultra. It is 5 inches in size (diagonally) with a
resolution of 480x854.
Signed-off-by: Adam Green
---
.../devicetree/bindings/display/panel/sitronix,st7701.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git
On 22/02/2024 17:14, Jessica Zhang wrote:
Hi Adam,
Just wondering, why the change to 120 here?
Thanks,
Jessica Zhang
Hi,
The 120ms is taken from the datasheet specification for the controller
as maximum time it takes for the display to reset,
Kind regards,
Adam
I forgot to include the 2nd patch in the series in v1.
Kind regards,
Adam Green (2):
drm: panel: st7701: Add Hardkernel ODROID-GO Ultra panel support
dt-bindings: display: st7701: Add Hardkernel ODROID-GO Ultra panel
.../display/panel/sitronix,st7701.yaml| 1 +
The new HDMI connector infrastructure allows to remove some boilerplate,
especially to generate infoframes. Let's switch to it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/rockchip/inno_hdmi.c | 123 ---
1 file changed, 42 insertions(+), 81 deletions(-)
container_of_const() allows to preserve the pointer constness and is
thus more flexible than inline functions.
Let's switch all our instances of container_of() to container_of_const().
Reviewed-by: Sui Jingfeng
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 16
The new HDMI connector infrastructure allows to remove some boilerplate,
especially to generate infoframes. Let's switch to it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 80 ++
1 file changed, 51 insertions(+), 29 deletions(-)
We're not doing anything special in atomic_mode_set so we can simply
merge it into atomic_enable.
Acked-by: Sui Jingfeng
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 38 +-
1 file changed, 14 insertions(+), 24 deletions(-)
diff
atomic_check and mode_valid do not check for the same things which can
lead to surprising result if the userspace commits a mode that didn't go
through mode_valid. Let's merge the two implementations into a function
called by both.
Acked-by: Sui Jingfeng
Signed-off-by: Maxime Ripard
---
On 2/22/2024 1:46 AM, Dmitry Baryshkov wrote:
On Thu, 22 Feb 2024 at 11:28, Konrad Dybcio wrote:
On 2/22/24 10:04, Dmitry Baryshkov wrote:
On Thu, 22 Feb 2024 at 10:56, Konrad Dybcio wrote:
On 2/22/24 00:41, Dmitry Baryshkov wrote:
On Thu, 22 Feb 2024 at 01:19, Bjorn Andersson
On Thu, 22 Feb 2024 14:04:20 -0500
Rodrigo Vivi wrote:
> > Note, I have patches that depend on this fix, so if one of the maintainers
> > would like to just give me an "Acked-by", I'll take it through my tree. I
> > doubt it will have any conflicts, unless you are planning on changing the
> >
Hi Dave, Sima,
Fixes for 6.8.
The following changes since commit b401b621758e46812da61fa58a67c3fd8d91de0d:
Linux 6.8-rc5 (2024-02-18 12:56:25 -0800)
are available in the Git repository at:
https://gitlab.freedesktop.org/agd5f/linux.git
tags/amd-drm-fixes-6.8-2024-02-22
for you to fetch
Dne sreda, 21. februar 2024 ob 14:45:20 CET je Maxime Ripard napisal(a):
> Hi,
>
> On Fri, Feb 16, 2024 at 08:04:26PM +0100, Ondřej Jirman wrote:
> > From: Ondrej Jirman
> >
> > Identical configurations of planes can lead to different (and wrong)
> > layer -> pipe routing at HW level, depending
On 21/02/2024 21:28, Rodrigo Vivi wrote:
On Wed, Feb 21, 2024 at 09:42:34AM +, Tvrtko Ursulin wrote:
On 21/02/2024 00:14, Vinay Belgaumkar wrote:
Allow user to provide a context hint. When this is set, KMD will
send a hint to GuC which results in special handling for this
context. SLPC
Hi Marco,
On 2/22/24 07:32, Marco Pagani wrote:
On 2024-02-18 16:49, Guenter Roeck wrote:
Hi,
On Thu, Nov 30, 2023 at 06:14:16PM +0100, Marco Pagani wrote:
This patch introduces an initial KUnit test suite for GEM objects
backed by shmem buffers.
Suggested-by: Javier Martinez Canillas
From: Maíra Canal
KUnit unifies the test structure and provides helper tools that simplify
the development of tests. Basic use case allows running tests as regular
processes, which makes easier to run unit tests on a development machine
and to integrate the tests in a CI system.
This commit
From: Maíra Canal
The display_mode_vba library deals with hundreds of display parameters
and sometimes does it in odd ways. The addition of unit tests intends to
assure the quality of the code delivered by HW engineers and, also make
it possible to refactor the code decreasing concerns about
From: Isabella Basso
This adds tests to the bit encoding format verification functions on the
file. They're meant to be simpler so as to provide a proof of concept on
testing DML code.
Change since v4:
- Use DRM_AMD_DC_FP guard for FPU tests
Signed-off-by: Isabella Basso
Signed-off-by: Maíra
From: Maíra Canal
The display_mode_vba_20 deals with hundreds of display parameters for
the DCN20 and sometimes does it in odd ways. The addition of unit tests
intends to assure the quality of the code delivered by HW engineers and,
also make it possible to refactor the code decreasing concerns
From: Tales Aparecida
The fixed31_32 library performs a lot of the mathematical operations
involving fixed-point arithmetic and the conversion of integers to
fixed-point representation.
This unit tests intend to assure the proper functioning of the basic
mathematical operations of fixed-point
In 2022, we got a great patchset from a GSoC project introducing unit
tests to the amdgpu display. Since version 3, this effort was put on
hold, and now I'm attempting to revive it. I'll add part of the original
cover letter at the bottom of this cover letter, but you can read all
the original
On 2/22/2024 05:08, Maxime Ripard wrote:
Hi Daniel,
On Mon, Feb 19, 2024 at 05:02:34PM +0800, Daniel van Vugt wrote:
Until now, deferred console takeover only meant defer until there is
output. But that risks stepping on the toes of userspace splash screens
as console messages may appear
submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Thomas-Zimmermann/arch-Select-fbdev-helpers-with-CONFIG_VIDEO/20240222-001622
base: tip/x86/core
patch link
This is an effort to get rid of all multiplications from allocation
functions in order to prevent integer overflows [1] [2].
In this case, the memory allocated to store RADEONFB_CONN_LIMIT pointers
to "drm_connector" structures can be avoided. This is because this
memory area is never accessed.
The new HDMI connector infrastructure allows us to remove a lot of
boilerplate, so let's switch to it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 638 +
drivers/gpu/drm/vc4/vc4_hdmi.h | 44 +--
Infoframes in KMS is usually handled by a bunch of low-level helpers
that require quite some boilerplate for drivers. This leads to
discrepancies with how drivers generate them, and which are actually
sent.
Now that we have everything needed to generate them in the HDMI
connector state, we can
Most HDMI drivers have some code to calculate the TMDS character rate,
usually to adjust an internal clock to match what the mode requires.
Since the TMDS character rates mostly depends on the resolution, whether
we need to repeat pixels or not, the bpc count and the format, we can
now derive it
Most of the HDMI controllers have an upper TMDS character rate limit
they can't exceed. On "embedded"-grade display controllers, it will
typically be lower than what high-grade monitors can provide these days,
so drivers will filter the TMDS character rate based on the controller
capabilities.
To
The previous patch stores in the connector state the expected TMDS
character rate matching the configuration of the HDMI connector. Let's
add a few tests to make sure it works as expected.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
The previous patch adds a new hook for HDMI connectors to filter out
configurations based on the TMDS character rate. Let's add some tests to
make sure it works as expected.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
.../gpu/drm/tests/drm_atomic_state_helper_test.c | 65
The i915 driver has a property to force the RGB range of an HDMI output.
The vc4 driver then implemented the same property with the same
semantics. KWin has support for it, and a PR for mutter is also there to
support it.
Both drivers implementing the same property with the same semantics,
plus
HDMI controller drivers will need to figure out the RGB range they need
to configure based on a mode and property values. Let's expose that in
the HDMI connector state so drivers can just use that value.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_atomic.c
The previous patch added the bpc and format an HDMI connector needs to
be set up with for a given connector state.
Let's add a few tests to make sure it works as expected.
Signed-off-by: Maxime Ripard
---
.../gpu/drm/tests/drm_atomic_state_helper_test.c | 504 +
There has been some discussions recently about the infoframes sent by
drivers and if they were properly generated.
In parallel, there's been some interest in creating an infoframe-decode
tool similar to edid-decode.
Both would be much easier if we were to expose the infoframes programmed
in the
The vc4_dummy_plane structure is an exact equivalent to vc4_plane, so we
don't need it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/tests/vc4_mock.c | 6 ++
drivers/gpu/drm/vc4/tests/vc4_mock.h | 9 ++---
drivers/gpu/drm/vc4/tests/vc4_mock_plane.c | 14
The previous commit added the infrastructure to the connector state to
track what RGB Quantization should be used in a given state for an HDMI
connector.
Let's add some kunit tests to make sure it works as expected.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
Now that we have a plane create helper for kunit mocked drivers, let's
convert to it in vc4.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/tests/vc4_mock_plane.c | 34 +++---
1 file changed, 8 insertions(+), 26 deletions(-)
diff --git
The previous patch added the generation of the infoframes matching an
HDMI connector state. Let's add a few tests to make sure it works as
expected.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_connector_test.c | 219 +
1 file changed, 219 insertions(+)
The sun4i_hdmi driver still uses the non-atomic variants of the encoder
hooks, so let's convert to their atomic equivalents.
Acked-by: Sui Jingfeng
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
Now that we have all the infrastructure needed, we can add some code
that will, for a given connector state and mode, compute the best output
format and bpc.
The algorithm is equivalent to the one already found in i915 and vc4.
Signed-off-by: Maxime Ripard
---
The previous patch added an helper to compute the TMDS character rate on
an HDMI connector. Let's add a few tests to make sure it works as
expected.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_connector_test.c | 323 +
1
This had a bunch of kunit tests to make sure our code to handle the
Broadcast RGB property behaves properly.
This requires bringing a bit of infrastructure to create mock HDMI
connectors, with custom EDIDs.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
On Thu, Feb 22, 2024 at 01:43:49PM -0500, Steven Rostedt wrote:
> On Thu, 22 Feb 2024 13:30:57 -0500
> Steven Rostedt wrote:
>
> > From: "Steven Rostedt (Google)"
> >
> > I'm working on improving the __assign_str() and __string() macros to be
> > more efficient, and removed some unneeded
Dne četrtek, 22. februar 2024 ob 19:14:21 CET je Maxime Ripard napisal(a):
> atomic_check and mode_valid do not check for the same things which can
> lead to surprising result if the userspace commits a mode that didn't go
> through mode_valid. Let's merge the two implementations into a function
>
Add support to pack and send the VSC SDP packet for DP. This therefore
allows the transmision of format information to the sinks which is
needed for YUV420 support over DP.
Changes in v5:
- Slightly modify use of drm_dp_vsc_sdp_pack()
- Remove dp_catalog NULL checks
-
DP controller can be setup to operate in either SDP update flush mode or
peripheral flush mode based on the DP controller hardware version.
Starting in DP v1.2, the hardware documents require the use of
peripheral flush mode for SDP packets such as PPS OR VSC SDP packets.
In-line with this
Adjust the encoder timing engine setup programming in the case of video
mode for YUV420 over DP to accommodate CDM.
Changes in v3:
- Move drm_display_mode's hskew division to another patch
- Minor cleanup
Changes in v2:
- Move timing engine programming to this patch
Move dpu_encoder_helper_phys_setup_cdm to dpu_encoder in preparation for
implementing YUV420 over DP, which requires CDM compatibility.
Changes in v2:
- Slightly change the wording of the commit text to make clear
that YUV over DP requires CDM
Signed-off-by: Paloma Arellano
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 usable by SDP
programming in both dp_catalog.c and dp_audio.c
Changes in v3:
- Change ordering of the
Change all relevant DP controller related programming for YUV420 cases.
Namely, change the pixel clock math to consider YUV420 and modify the
MVID programming to consider YUV420.
Changes in v2:
- Move configuration control programming to a different commit
- Slight code
Generalize dpu_encoder_helper_phys_setup_cdm to be compatible with DP.
Changes in v2:
- Minor formatting changes
- Move the modification of the dimensions for CDM setup to a new
patch
Signed-off-by: Paloma Arellano
Reviewed-by: Dmitry Baryshkov
---
CDM block supports formats other than H1V2 for DP. Since we are now
adding support for CDM over DP, relax the checks to allow all other
formats for DP other than H1V2.
Changes in v2:
- Add fixes tag
- Move patch to top of series
Fixes: 0afac0ba6024 ("drm/msm/dpu: add dpu_hw_cdm
Setting up the timing engine when the physical encoder has a split role
neglects dividing the drm_display_mode's hskew parameter. Let's fix this
since this must also be done in preparation for implementing YUV420 over
DP.
Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
Signed-off-by:
Modify the output width and height parameters of hw_cdm to utilize the
physical encoder's data instead of obtaining the information from the
framebuffer. CDM is to be set up to utilize the actual output data since
at CDM setup, there is no difference between the two sources.
Changes in v2:
The Chroma Down Sampling (CDM) block is a hardware component in the DPU
pipeline that includes a CSC block capable of converting RGB input from
the DPU to YUV data.
This block can be used with either HDMI, DP, or writeback interfaces.
This series adds support for the CDM block to be used with DP
On 2024-02-22 16:52, Guenter Roeck wrote:
> Hi Marco,
>
> On 2/22/24 07:32, Marco Pagani wrote:
>>
>>
>> On 2024-02-18 16:49, Guenter Roeck wrote:
>>> Hi,
>>>
>>> On Thu, Nov 30, 2023 at 06:14:16PM +0100, Marco Pagani wrote:
This patch introduces an initial KUnit test suite for GEM
On Thu, 22 Feb 2024 at 17:04, Bjorn Andersson wrote:
>
> On Thu, Feb 22, 2024 at 11:46:26AM +0200, Dmitry Baryshkov wrote:
> > On Thu, 22 Feb 2024 at 11:28, Konrad Dybcio
> > wrote:
> > >
> > >
> > >
> > > On 2/22/24 10:04, Dmitry Baryshkov wrote:
> > > > On Thu, 22 Feb 2024 at 10:56, Konrad
Hi!
> > > so after more feedback from the OpenRGB maintainers I came up with an even
> > > more generic proposal:
> > > https://gitlab.com/CalcProgrammer1/OpenRGB/-/issues/3916#note_1753072869
> >
> > > >evaluate-set-command ioctl taking:
> > > >{
> > > > enum command /* one
On Thu, 22 Feb 2024 at 09:36, Daniel Latypov wrote:
>
> Copying the line for context, it's about `p-r` where
> p = memchr_inv([1], 0, sizeof(r) - sizeof(r[0]));
> `p-r` should never be negative unless something has gone horribly
> horribly wrong.
Sure it would - if 'p' is NULL.
Of course,
From: "Steven Rostedt (Google)"
I'm working on improving the __assign_str() and __string() macros to be
more efficient, and removed some unneeded semicolons. This triggered a bug
in the build as some of the __assign_str() macros in intel_display_trace
was missing a terminating semicolon.
Fixes:
On Thu, 22 Feb 2024 13:30:57 -0500
Steven Rostedt wrote:
> From: "Steven Rostedt (Google)"
>
> I'm working on improving the __assign_str() and __string() macros to be
> more efficient, and removed some unneeded semicolons. This triggered a bug
> in the build as some of the __assign_str()
Use cmdq_pkt_create() and cmdq_pkt_destroy() common function
instead of implementing mdp3 version.
Signed-off-by: Chun-Kuang Hu
---
.../platform/mediatek/mdp3/mtk-mdp3-cmdq.c| 45 ++-
1 file changed, 4 insertions(+), 41 deletions(-)
diff --git
In order to have fine-grained control, use cmdq_pkt_eoc() and
cmdq_pkt_jump_rel() to replace cmdq_pkt_finalize().
Signed-off-by: Chun-Kuang Hu
---
drivers/soc/mediatek/mtk-cmdq-helper.c | 22 --
include/linux/soc/mediatek/mtk-cmdq.h | 13 -
2 files changed, 35
In order to have fine-grained control, use cmdq_pkt_eoc() and
cmdq_pkt_jump_rel() to replace cmdq_pkt_finalize().
Signed-off-by: Chun-Kuang Hu
---
drivers/media/platform/mediatek/mdp3/mtk-mdp3-cmdq.c | 3 ++-
drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.c | 2 ++
cmdq_pkt_flush_async() is not used by all client drivers (MediaTek
drm driver and MediaTek mdp3 driver), so remove it.
Signed-off-by: Chun-Kuang Hu
---
drivers/soc/mediatek/mtk-cmdq-helper.c | 15 ---
include/linux/soc/mediatek/mtk-cmdq.h | 18 --
2 files changed,
1 - 100 of 259 matches
Mail list logo
