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
We're not doing anything special in atomic_mode_set so we can simply
merge it into atomic_enable.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 38 +-
1 file changed, 14 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm
The inno_hdmi driver relies on its own internal infoframe type matching
the hardware.
This works fine, but in order to make further reworks easier, let's
switch to the HDMI spec definition of those types.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/rockchip/inno_hdmi.c | 21
The HDMI vendor infoframe is only meant to be sent with 4k60 modes and
higher, but the controller doesn't support them. Let's drop them from
the kernel.
Suggested-by: Johan Jonker
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/rockchip/inno_hdmi.c | 35 ++-
1
The inno_hdmi mode_valid implementation always return MODE_OK which is
what the core assumes when we don't have an implementation.
Let's get rid of it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/rockchip/inno_hdmi.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/gpu
The drm_dev field in the inno_hdmi struct stores a pointer to the DRM
device but is never used anywhere in the driver. Let's remove it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/rockchip/inno_hdmi.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c
it obvious what
we are doing in the error path.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/rockchip/inno_hdmi.c | 47
1 file changed, 31 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c
b/drivers/gpu/drm/rockchip
The CSC_* enum has no users left, so let's remove it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/rockchip/inno_hdmi.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c
b/drivers/gpu/drm/rockchip/inno_hdmi.c
index c342bc8b3a23..f05417c6b637
The coeff_csc matrix isn't used anymore, let's remove it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/rockchip/inno_hdmi.c | 70
1 file changed, 70 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c
b/drivers/gpu/drm/rockchip/inno_hdmi.c
The colorimetry field of hdmi_data_info is not used anywhere so we can
get rid of it. This was the last field left in that structure so we can
get rid of it too.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/rockchip/inno_hdmi.c | 15 ---
1 file changed, 15 deletions(-)
diff
when we
don't have a mode yet.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/rockchip/inno_hdmi.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c
b/drivers/gpu/drm/rockchip/inno_hdmi.c
index f05417c6b637..35f44e556fcf
The inno_hdmi encoder still uses the !atomic variants of enable, disable
and modeset. Convert to their atomic equivalents.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/rockchip/inno_hdmi.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu
Similarly to the input format, the driver has a lot of code to deal with
various output format, but the driver hardcodes it to RGB always.
Let's get rid of the dead code.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/rockchip/inno_hdmi.c | 57
1 file
We're not doing anything special in atomic_mode_set so we can simply
merge it into atomic_enable.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/rockchip/inno_hdmi.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/rockchip
The sink_has_audio flag is not used anywhere in the driver so let's get
rid of it. It's redundant with drm_display_info.has_audio anyway.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/rockchip/inno_hdmi.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/rockchip
The driver has a lot of logic to deal with multiple input formats, but
hardcodes it to RGB. This means that most of that code has been dead
code, so let's get rid of it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/rockchip/inno_hdmi.c | 39 +---
1 file
The mode's VIC is only ever used in the inno_hdmi_setup() function so
there's no need to store it in the main structure.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/rockchip/inno_hdmi.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm
The driver maintains a copy of the adjusted mode but doesn't use it
anywhere. Remove it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/rockchip/inno_hdmi.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c
b/drivers/gpu/drm/rockchip/inno_hdmi.c
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 a/drivers/gpu/drm/vc4/tests
The mode_fixup implementation doesn't do anything, so we can simply
remove it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/rockchip/inno_hdmi.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c
b/drivers/gpu/drm/rockchip/inno_hdmi.c
index
still fragile so let's fix this properly.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 25c9c71256d3..f05e2c95a60d 100644
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
in the hardware. It won't be perfect since we have no guarantee that
it's actually what goes through the wire, but it's the best we can do.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_debugfs.c | 110 ++
1 file changed, 110 insertions(+)
diff --git
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 +--
drivers/gpu/drm/vc4
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 the same one than the one already found in i915 and
vc4.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm
generate them in our common logic so that
drivers can simply reuse what we precomputed.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/Kconfig| 1 +
drivers/gpu/drm/drm_atomic_state_helper.c | 327 +
drivers/gpu/drm/drm_connector.c
given mode.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_atomic_state_helper.c | 9 +++
drivers/gpu/drm/drm_connector.c| 4 ++
.../gpu/drm/tests/drm_atomic_state_helper_test.c | 69 ++
drivers/gpu/drm/tests/drm_connector_test.c
it from the HDMI connector state that stores all those infos
and remove the duplication from drivers.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_atomic.c | 1 +
drivers/gpu/drm/drm_atomic_state_helper.c | 44 +
.../gpu/drm/tests
A lot of HDMI drivers have some variation of the formula to calculate
the TMDS character rate from a mode, but few of them actually take all
parameters into account.
Let's create a helper to provide that rate taking all parameters into
account.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm
We'll add automatic selection of the output BPC in a following patch,
but let's add it to the HDMI connector state already.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_atomic.c | 1 +
drivers/gpu/drm/drm_atomic_state_helper.c | 7 +-
drivers/gpu/drm
Just like BPC, we'll add support for automatic selection of the output
format for HDMI connectors.
Let's add the needed defaults and fields for now.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_atomic.c | 2 +
drivers/gpu/drm/drm_atomic_state_helper.c
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.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_atomic.c | 4
the userspace having support for it, is proof enough that it's
pretty much a de-facto standard now and we can provide helpers for it.
Let's plumb it into the newly created HDMI connector.
Signed-off-by: Maxime Ripard
---
Documentation/gpu/kms-properties.csv | 1 -
drivers/gpu/drm
The next features we will need to share across drivers will need to
store some parameters for drivers to use, such as the selected output
format.
Let's create a new connector sub-state dedicated to HDMI controllers,
that will eventually store everything we need.
Signed-off-by: Maxime Ripard
with a few
requirements though, and thus we need a new initialization function.
Hopefully, this will make drivers simpler to handle, and their behaviour
more consistent.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_connector.c| 39 +
drivers/gpu/drm/tests
drmm_connector_init is the preferred function to initialize a
drm_connector structure. Let's add a bunch of unit tests for it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_connector_test.c | 170 -
1 file changed, 169 insertions(+), 1 deletion(-)
diff
that.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_kunit_helpers.c | 62 +++
include/drm/drm_kunit_helpers.h | 10 +
2 files changed, 72 insertions(+)
diff --git a/drivers/gpu/drm/tests/drm_kunit_helpers.c
b/drivers/gpu/drm/tests/drm_kunit_helpers.c
We're going to need a full-blown, functional, KMS device to test more
components of the atomic modesetting infrastructure.
Let's add a new helper to create a dumb, mocked, primary plane. By
default, it will create a linear XRGB plane, using the default
helpers.
Signed-off-by: Maxime Ripard
The mock device we were creating was missing any of the driver-wide
helpers. That was fine before since we weren't testing the atomic state
path, but we're going to start, so let's use the default
implementations.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_kunit_helpers.c | 3
lpers: Allow to pass a custom drm_driver")
Signed-off-by: Maxime Ripard
---
include/drm/drm_kunit_helpers.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/drm/drm_kunit_helpers.h b/include/drm/drm_kunit_helpers.h
index ba483c87f0e7..3ae19892229d 100644
--- a/include/drm/drm_kunit
est to run with a particular set of capabilities.
This entire series has been tested on a Pi4, passes all its unittests
(125 new tests), and has only been build-tested for sunxi and rockchip.
Let me know what you think,
Maxime
Signed-off-by: Maxime Ripard
---
Changes in v5:
- Dropped the connecto
On Tue, Dec 05, 2023 at 10:51:06AM +0200, Pekka Paalanen wrote:
> On Mon, 4 Dec 2023 13:17:06 +0100
> Maxime Ripard wrote:
>
> > The current documentation of drm_atomic_state says that it's the "global
> > state object". This is confusing since, while it d
On Tue, Dec 05, 2023 at 11:15:29AM +0200, Pekka Paalanen wrote:
> On Tue, 5 Dec 2023 10:51:06 +0200
> Pekka Paalanen wrote:
>
> > On Mon, 4 Dec 2023 13:17:06 +0100
> > Maxime Ripard wrote:
> >
> > > The current documentation of drm_atomic_state says that
On Tue, Dec 05, 2023 at 04:52:06PM +, Simon Ser wrote:
> > I think the logicvc is a much better example for this, since it requires
> > framebuffers to be in a specific area, with each plane having a
> > dedicated area.
> >
> > AFAIK that's the most extreme example we have upstream.
>
> That
On Thu, Dec 07, 2023 at 10:23:08AM +0100, Andi Shyti wrote:
> Hi Thomas and Maxime,
>
> thanks for the answer,
>
> On Thu, Dec 07, 2023 at 10:10:55AM +0100, Maxime Ripard wrote:
> > On Wed, Dec 06, 2023 at 10:09:46PM +0100, Andi Shyti wrote:
> > > This is
On Thu, Dec 07, 2023 at 12:18:13PM +0200, Jani Nikula wrote:
> On Wed, 06 Dec 2023, Maxime Ripard wrote:
> > All of the current plane init / allocation functions behave slightly
> > differently when it comes to argument sanitizing:
> >
> > - drm_universal_pla
Hi,
On Wed, Dec 06, 2023 at 01:14:54PM +0300, Dmitry Baryshkov wrote:
> The drm_atomic_helper_check_wb_encoder_state() function doesn't use
> encoder for anything other than getting the drm_device instance. The
> function's description talks about checking the writeback connector
> state, not the
Hi Dave, Sima,
Here's this week drm-misc-next PR
Maxime
drm-misc-next-2023-12-07:
drm-misc-next for 6.8:
UAPI Changes:
- Remove Userspace Mode-Setting ioctls
- v3d: New uapi to handle jobs involving the CPU
Cross-subsystem Changes:
Core Changes:
- atomic: Add support for FB-less planes
On Tue, Dec 05, 2023 at 09:33:28AM -0800, Abhinav Kumar wrote:
>
>
> On 12/5/2023 3:46 AM, Maxime Ripard wrote:
> > On Tue, Dec 05, 2023 at 12:05:02PM +0300, Dan Carpenter wrote:
> > > On Tue, Dec 05, 2023 at 09:37:05AM +0100, Maxime Ripard wrote:
> > > >
On Thu, Dec 07, 2023 at 10:29:12AM +0100, Krzysztof Kozlowski wrote:
> On 06/12/2023 15:33, Rob Herring wrote:
> > On Tue, Dec 05, 2023 at 11:52:54AM +0100, Dario Binacchi wrote:
> >> From: Michael Trimarchi
> >>
> >> Add documentation for "ilitek,ili9805" panel.
> >>
> >> Signed-off-by: Michael
On Tue, Dec 05, 2023 at 02:50:08PM +0100, H. Nikolaus Schaller wrote:
> Hi,
>
> > Am 05.12.2023 um 14:29 schrieb Maxime Ripard :
> >
> > Hi,
> >
> > On Tue, Dec 05, 2023 at 09:18:58AM +0100, H. Nikolaus Schaller wrote:
> >>> Am 05.12.2023 um 0
On Wed, Dec 06, 2023 at 10:09:46PM +0100, Andi Shyti wrote:
> This is the second time I am resending this series in its v2. It
> has been reviewd, acked, blessed, discussed, rectified, assessed,
> authorized, validated, glorified, praised, demanded, approved,
> and yet, I don't understand why no
Hi Mark,
On Tue, Dec 05, 2023 at 04:13:41PM +, Mark Brown wrote:
> On Sun, Dec 03, 2023 at 02:53:13PM +0300, Dmitry Baryshkov wrote:
>
> > Each of connectors and CRTCs used by the DRM device provides debugfs
> > directory, which is used by several standard debugfs files and can
> > further
4 files changed, 5 insertions(+), 4 deletions(-)
> > ---
> > base-commit: 9d7c8c066916f231ca0ed4e4fce6c4b58ca3e451
> > change-id: 20230804-uninit-fixes-188f92d60ac3
> >
> > Best regards,
>
> Ping on this (or I'll forget the series...).
Acked-by: Maxime Ripard
Maxime
signature.asc
Description: PGP signature
On Mon, 04 Dec 2023 08:32:10 +0100, Arnd Bergmann wrote:
> This function is only used when debugfs is enabled, and otherwise
> causes a build warning:
>
> drivers/gpu/drm/imagination/pvr_fw_trace.c:135:1: error: 'update_logtype'
> defined but not used [-Werror=unused-function]
>
> Move the
On Mon, 04 Dec 2023 15:13:37 +, Donald Robson wrote:
> Fixing the warning below due to an unused file level vtable. Removing
> only this causes additional warnings for the now unused functions, so
> I've removed those too.
>
> >> drivers/gpu/drm/imagination/pvr_fw_trace.c:205:37: warning:
>
variant, leading to
> > a crash. And probably the driver will crash if it happens, for some
> > reason, to try to send a message via the DSI bus.
> >
> > But that's another topic.
> >
> > Signed-off-by: Tomi Valkeinen
> > ---
>
> Any comments? I can push this via drm-misc, but I'd like an ack.
An ack is a requirement, it's not optional.
Acked-by: Maxime Ripard
Maxime
signature.asc
Description: PGP signature
On Wed, Dec 06, 2023 at 08:02:55PM +0800, Keith Zhao wrote:
> >> +static const struct of_device_id starfive_hdmi_dt_ids[] = {
> >> + { .compatible = "starfive,jh7110-inno-hdmi",},
> >
> > So it's inno hdmi, just like Rockchip then?
> >
> > This should be a common driver.
>
> Rockchip has a inno
is not
welcome.
Let's make all functions consider those three pointers to be always set
and explicitly panic if they aren't. And let's document that behaviour
too.
Link:
https://lore.kernel.org/dri-devel/20231128-kms-hdmi-connector-state-v4-5-c76021583...@kernel.org/
Signed-off-by: Maxime Ripard
---
drivers
to be always set
and explicitly panic if they aren't. And let's document that behaviour
too.
Link:
https://lore.kernel.org/dri-devel/20231128-kms-hdmi-connector-state-v4-5-c76021583...@kernel.org/
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_crtc.c | 18 --
include/drm
-devel/20231128-kms-hdmi-connector-state-v4-5-c76021583...@kernel.org/
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_encoder.c | 19 +--
include/drm/drm_encoder.h | 6 ++
2 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_encoder.c b
-devel/20231128-kms-hdmi-connector-state-v4-5-c76021583...@kernel.org/
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_plane.c | 15 +++
include/drm/drm_plane.h | 6 ++
2 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu
On Mon, Dec 04, 2023 at 08:33:14PM +0800, Keith Zhao wrote:
> add hdmi driver as encoder and connect
>
> Signed-off-by: Keith Zhao
> ---
> drivers/gpu/drm/verisilicon/Kconfig | 8 +
> drivers/gpu/drm/verisilicon/Makefile| 1 +
> drivers/gpu/drm/verisilicon/starfive_hdmi.c |
On Mon, Dec 04, 2023 at 08:33:13PM +0800, Keith Zhao wrote:
> +static const struct vs_plane_info dc_hw_planes_rev0[PLANE_NUM] = {
> + {
> + .name = "Primary",
> + .id = PRIMARY_PLANE_0,
> + .type =
On Tue, Dec 05, 2023 at 04:40:40PM +0100, Danilo Krummrich wrote:
> On Tue, Dec 05, 2023 at 04:35:00PM +0100, Maxime Ripard wrote:
> > Hi,
> >
> > On Wed, Nov 29, 2023 at 11:07:59PM +0100, Danilo Krummrich wrote:
> > > Some major GPUVM changes landed just b
On Tue, Dec 05, 2023 at 12:45:07PM -0800, Doug Anderson wrote:
> Hi,
>
> On Fri, Nov 17, 2023 at 3:00 PM Doug Anderson wrote:
> >
> > Hi,
> >
> > On Fri, Sep 22, 2023 at 2:06 PM Lyude Paul wrote:
> > >
> > > actually very glad to see this because I think I've seen one bug in the
> > > wild
> >
Hi,
On Wed, Nov 29, 2023 at 11:07:59PM +0100, Danilo Krummrich wrote:
> Some major GPUVM changes landed just before v8 of the PowerVR series. Since v8
> went in rather quickly (review process was finished otherwise) I haven't had
> the
> chance to review the subsequent code changes.
>
> Hence,
Hi,
Thanks for the rework
On Tue, Dec 05, 2023 at 02:22:10AM +0100, Michał Winiarski wrote:
> Add a simple test that checks whether the action is indeed called right
> away and that it is not called on the final drm_dev_put().
>
> Signed-off-by: Michał Winiarski
> ---
>
Hi,
On Tue, Dec 05, 2023 at 09:18:58AM +0100, H. Nikolaus Schaller wrote:
> > Am 05.12.2023 um 07:57 schrieb Maxime Ripard :
> >
> > On Mon, Dec 04, 2023 at 12:22:36PM -0600, Andrew Davis wrote:
> >> The Imagination PowerVR Series5 "SGX" GPU is part of se
On Tue, Dec 05, 2023 at 03:37:15AM +0200, Dmitry Baryshkov wrote:
> On 04/12/2023 10:38, Maxime Ripard wrote:
> > On Sat, Dec 02, 2023 at 12:07:49AM +0200, Dmitry Baryshkov wrote:
> > > The drm_atomic_helper_check_wb_encoder_state() function doesn't use
> > > enco
On Tue, Dec 05, 2023 at 12:05:02PM +0300, Dan Carpenter wrote:
> On Tue, Dec 05, 2023 at 09:37:05AM +0100, Maxime Ripard wrote:
> > Hi Naresh,
> >
> > Thanks for the report
> >
> > On Mon, Dec 04, 2023 at 11:05:36PM +0530, Naresh Kamboju wrote:
> > >
Kunit recently gained helpers to create test managed devices. This means
that we no longer have to roll our own helpers in KMS and we can reuse
them.
Signed-off-by: Maxime Ripard
---
David, feel free to integrate that patch into your series and merge it
whenever and wherever you see fit
Hi,
On Fri, Oct 27, 2023 at 03:32:57PM -0700, Jessica Zhang wrote:
> Loosen the requirements for atomic and legacy commit so that, in cases
> where pixel_source != FB, the commit can still go through.
>
> This includes adding framebuffer NULL checks in other areas to account for
> FB being NULL
Hi Naresh,
Thanks for the report
On Mon, Dec 04, 2023 at 11:05:36PM +0530, Naresh Kamboju wrote:
> The Kunit drm_plane_helper failed on all devices running Linux next-20231204
>
> ## Test Regressions (compared to next-20231201)
> * qemu-armv7, kunit and
> * x86, kunit
> -
On Mon, Dec 04, 2023 at 12:22:36PM -0600, Andrew Davis wrote:
> The Imagination PowerVR Series5 "SGX" GPU is part of several SoCs from
> multiple vendors. Describe how the SGX GPU is integrated in these SoC,
> including register space and interrupts. Clocks, reset, and power domain
> information
lementation nor
>
> [ ... ]
Acked-by: Maxime Ripard
Thanks!
Maxime
On Mon, 04 Dec 2023 13:28:47 +, Frank Binns wrote:
> This is the tree used by nearly all other DRM drivers, so use it for the
> PowerVR driver as well.
>
>
Applied to drm/drm-misc (drm-misc-next).
Thanks!
Maxime
Hi,
On Mon, Dec 04, 2023 at 01:36:11PM +, Donald Robson wrote:
> Fixing the warning below due to an unused file level vtable. Removing
> only this causes additional warnings for the now unused functions, so
> I've removed those too.
>
> >> drivers/gpu/drm/imagination/pvr_fw_trace.c:205:37:
On Wed, Nov 29, 2023 at 04:47:05PM +0100, Boris Brezillon wrote:
> On Wed, 29 Nov 2023 16:15:27 +0100
> Maxime Ripard wrote:
>
> > > Now, let's assume we drop the _locked() suffix on
> > > drm_gem_shmem_v[un]map(), but keep it on other helpers that need both
&
On Fri, Dec 01, 2023 at 08:09:22PM +0200, Ville Syrjälä wrote:
> > When I was working on Weston atomic KMS support many years ago, I
> > created a framework that emitted KMS property changes only when they
> > actually needed changing. By review feedback (*), all that machinery was
> > dropped in
old and new state. There's no per-object data there.
Let's rephrase those fields a bit to better match the current situation.
Signed-off-by: Maxime Ripard
---
include/drm/drm_atomic.h | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/include/drm
The name of the structure drm_atomic_state is confusing. Let's add an
entry to our todo list to rename it.
Signed-off-by: Maxime Ripard
---
Documentation/gpu/todo.rst | 18 ++
1 file changed, 18 insertions(+)
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
The num_connectors field documentation mentions a connector_states field
that has never been part of this structure.
Signed-off-by: Maxime Ripard
---
include/drm/drm_atomic.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
not truly a "global state", unlike object state structures
that do contain the entire state of a given object.
Signed-off-by: Maxime Ripard
---
include/drm/drm_atomic.h | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/include/drm/drm_atomic.h b/include/dr
Some fields of drm_atomic_state have been documented in-line, but some
were documented in the main kerneldoc block before the structure.
Since the former is the preferred option in DRM, let's move all the
fields to an inline documentation.
Signed-off-by: Maxime Ripard
---
include/drm
Hi
On Fri, Dec 01, 2023 at 06:03:48PM +0200, Pekka Paalanen wrote:
> On Fri, 1 Dec 2023 14:20:55 +0100
> Maxime Ripard wrote:
>
> > On Fri, Dec 01, 2023 at 12:06:48PM +0200, Pekka Paalanen wrote:
> > > On Fri, 1 Dec 2023 10:25:09 +0100
> > > Maxime Ripard wrote
On Sun, Dec 03, 2023 at 08:10:31PM +0200, Dmitry Baryshkov wrote:
> On Sun, 3 Dec 2023 at 14:15, Simon Ser wrote:
> >
> > On Saturday, December 2nd, 2023 at 22:41, Dmitry Baryshkov
> > wrote:
> >
> > > On Fri, 27 Oct 2023 15:32:50 -0700, Jessica Zhang wrote:
> > >
> > > > Some drivers support
r *encoder);
> +void drm_debugfs_encoder_remove(struct drm_encoder *encoder);
> #else
> static inline void drm_debugfs_dev_fini(struct drm_device *dev)
> {
> @@ -231,6 +233,13 @@ static inline void drm_debugfs_crtc_crc_add(struct
> drm_crtc *crtc)
> {
> }
>
> +static inline void drm_debugfs_encoder_add(struct drm_encoder *encoder)
> +{
> +}
<- You need to insert a new line here.
Once fixed,
Acked-by: Maxime Ripard
Maxime
signature.asc
Description: PGP signature
> output and into debugfs/dri/N/state file.
>
>
> [ ... ]
Acked-by: Maxime Ripard
Thanks!
Maxime
obably amdgpu-next with drm-misc maintainer acks for the 3 core
> > patches. Or if amdgpu-next pull won't come for a while, put them into
> > drm-misc-next and just wait a week until it's in drm-next, then
> > forward amdgpu-next.
> >
>
> Maxime, Maarten, Thomas, could I get an ACK from you for the three
> DRM core patches and an ACK for pulling them through the AMD tree?
Acked-by: Maxime Ripard
Maxime
signature.asc
Description: PGP signature
On Sun, 03 Dec 2023 01:55:52 +0300, Dmitry Baryshkov wrote:
> In case the drm_modeset_register_all() function fails, its error code
> will be ignored. Instead make the drm_dev_register() bail out in case of
> such an error.
>
>
Applied to drm/drm-misc (drm-misc-next).
Thanks!
Maxime
On Fri, 10 Nov 2023 13:50:31 +0800, heminhong wrote:
> Some functions are never used by the driver,
> removing the functions declaration, it can be reducing program size,
> and improving code readability and maintainability.
>
>
Applied to drm/drm-misc (drm-misc-next).
Thanks!
Maxime
On Sat, Dec 02, 2023 at 12:07:49AM +0200, Dmitry Baryshkov wrote:
> The drm_atomic_helper_check_wb_encoder_state() function doesn't use
> encoder for anything other than getting the drm_device instance. The
> function's description talks about checking the writeback connector
> state, not the
On Fri, Dec 01, 2023 at 12:06:48PM +0200, Pekka Paalanen wrote:
> On Fri, 1 Dec 2023 10:25:09 +0100
> Maxime Ripard wrote:
>
> > On Fri, Dec 01, 2023 at 11:06:16AM +0200, Pekka Paalanen wrote:
> > > On Fri, 1 Dec 2023 09:29:05 +0100
> > > Maxime R
On Fri, Dec 01, 2023 at 11:06:16AM +0200, Pekka Paalanen wrote:
> On Fri, 1 Dec 2023 09:29:05 +0100
> Maxime Ripard wrote:
>
> > Hi,
> >
> > On Thu, Nov 30, 2023 at 05:07:40PM -0300, André Almeida wrote:
> > > From: Pekka Paalanen
> > >
> > &
On Wed, Nov 29, 2023 at 11:18:24AM +0200, Ville Syrjälä wrote:
> On Wed, Nov 29, 2023 at 10:11:26AM +0100, Maxime Ripard wrote:
> > Hi Ville,
> >
> > On Tue, Nov 28, 2023 at 03:49:08PM +0200, Ville Syrjälä wrote:
> > > On Tue, Nov 28, 2023 at 02:29:40PM +0100, Maxim
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
> Signed-off-by: Marco Pagani
>
> v5:
> - using __drm_kunit_helper_alloc_drm_device() to avoid
On Thu, 30 Nov 2023 16:00:16 +, Donald Robson wrote:
> The function below is used only within this source file, but is not static.
>
> drivers/gpu/drm/imagination/pvr_vm.c:542:6: error: no previous prototype for
> 'pvr_gpuvm_free' [-Werror=missing-prototypes]
> 542 | void
On Thu, 30 Nov 2023 16:00:17 +, Donald Robson wrote:
> This function is now unused, hence it causes a compiler warning.
>
>drivers/gpu/drm/imagination/pvr_vm.c:112:22: warning: unused function
> 'to_pvr_vm_gpuva' [-Wunused-function]
> 112 | struct pvr_vm_gpuva
On Thu, 30 Nov 2023 16:00:14 +, Donald Robson wrote:
> A missing header causes the compiler to warn that the function below is not
> forward declared.
>
> >> drivers/gpu/drm/imagination/pvr_fw_meta.c:33:1: warning: no previous
> >> prototype for function 'pvr_meta_cr_read32'
601 - 700 of 7441 matches
Mail list logo
