On Thu, 30 Nov 2023 10:27:01 +0300, Dan Carpenter wrote:
> The pvr_build_firmware_filename() function returns NULL on error. It
> doesn't return error pointers.
>
>
Applied to drm/drm-misc (drm-misc-next).
Thanks!
Maxime
On Thu, 30 Nov 2023 10:26:29 +0300, Dan Carpenter wrote:
> There is a cut and paste error so this code returns the wrong variable.
>
>
Applied to drm/drm-misc (drm-misc-next).
Thanks!
Maxime
Hi,
On Thu, Nov 30, 2023 at 10:52:17AM +0200, Jani Nikula wrote:
> On Wed, 29 Nov 2023, Hamza Mahfooz wrote:
> > Cc: Nathan Chancellor
> >
> > On 11/29/23 13:12, Jani Nikula wrote:
> >> At least the i915 and amd drivers enable a bunch more compiler warnings
> >> than the kernel defaults.
> >>
Hi,
Here's this week drm-misc-next PR
Thanks!
Maxime
drm-misc-next-2023-11-30:
drm-misc-next for 6.8:
UAPI Changes:
- Introduction of DRM_CAP_ATOMIC_ASYNC_PAGE_FLIP
- Introduction of DRM_CLIENT_CAP_CURSOR_PLANE_HOTSPOT
Cross-subsystem Changes:
- fbdev: Convert a big chunks of drivers to
Hi,
Thanks for creating a test for that, that's really appreciated :)
On Wed, Nov 29, 2023 at 11:14:12PM +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:
On Wed, Nov 29, 2023 at 02:46:09PM +0100, Boris Brezillon wrote:
> On Wed, 29 Nov 2023 14:09:47 +0100
> Maxime Ripard wrote:
>
> > On Wed, Nov 29, 2023 at 08:53:30AM +0100, Boris Brezillon wrote:
> > > On Wed, 29 Nov 2023 01:05:14 +0300
> > > Dmitry Osipenko wr
On Wed, Nov 29, 2023 at 01:40:38PM +0200, Jani Nikula wrote:
> On Wed, 29 Nov 2023, Maxime Ripard wrote:
> > On Wed, Nov 29, 2023 at 11:38:42AM +0200, Jani Nikula wrote:
> >> On Wed, 29 Nov 2023, Maxime Ripard wrote:
> >> > Hi Ville,
> >> >
> >>
On Wed, Nov 29, 2023 at 08:53:30AM +0100, Boris Brezillon wrote:
> On Wed, 29 Nov 2023 01:05:14 +0300
> Dmitry Osipenko wrote:
>
> > On 11/28/23 15:37, Boris Brezillon wrote:
> > > On Tue, 28 Nov 2023 12:14:42 +0100
> > > Maxime Ripard wrote:
> > >
Hi,
Thanks for writing this down
On Thu, Nov 16, 2023 at 03:53:20PM +, Simon Ser wrote:
> On Thursday, November 9th, 2023 at 08:45, Simon Ser
> wrote:
>
> > User-space sometimes needs to allocate scanout-capable memory for
> > GPU rendering purposes. On a vc4/v3d split render/display SoC,
Hi Linus,
On Mon, Nov 27, 2023 at 11:13:31PM +0100, Linus Walleij wrote:
> On Mon, Nov 27, 2023 at 5:29 PM Maxime Ripard wrote:
> > On Mon, Nov 27, 2023 at 05:03:53PM +0100, Linus Walleij wrote:
>
> > > > Liu Ying (2):
> > > > driver core: Export device_is_
Hi Donald,
On Wed, Nov 29, 2023 at 11:20:14AM +, Donald Robson wrote:
> Reported-by: kernel test robot
> Closes:
> https://lore.kernel.org/oe-kbuild-all/202311242159.hh8mwiam-...@intel.com/
> Closes:
> https://lore.kernel.org/oe-kbuild-all/202311241752.3ilyyfca-...@intel.com/
> Closes:
>
On Wed, Nov 29, 2023 at 12:08:17PM +0100, Geert Uytterhoeven wrote:
> Hi Maxime,
>
> On Wed, Nov 29, 2023 at 11:50 AM Maxime Ripard wrote:
> > On Wed, Nov 29, 2023 at 11:10:51AM +0100, Geert Uytterhoeven wrote:
> > > On Wed, Nov 29, 2023 at 10:23 AM Maxime Ripard wrote
On Wed, Nov 29, 2023 at 11:38:42AM +0200, Jani Nikula wrote:
> On Wed, 29 Nov 2023, 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, Maxime Ripard wrote:
> &
On Wed, Nov 29, 2023 at 11:10:51AM +0100, Geert Uytterhoeven wrote:
> On Wed, Nov 29, 2023 at 10:23 AM Maxime Ripard wrote:
> > On Wed, Nov 29, 2023 at 09:58:12AM +0100, Geert Uytterhoeven wrote:
> > > On Wed, Nov 29, 2023 at 9:35 AM Maxime Ripard wrote:
> > > >
On Wed, Nov 29, 2023 at 09:58:12AM +0100, Geert Uytterhoeven wrote:
> Hi Maxime,
>
> On Wed, Nov 29, 2023 at 9:35 AM Maxime Ripard wrote:
> > On Tue, Nov 28, 2023 at 08:16:18PM +0100, Geert Uytterhoeven wrote:
> > > On Tue, Nov 28, 2023 at 8:03 PM Javier Martin
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, Maxime Ripard wrote:
> > On Tue, Nov 28, 2023 at 02:54:02PM +0200, Jani Nikula wrote:
> > > On Tue, 28 Nov 2023, Maxime Ripard wrote:
> > > > All t
Hi,
On Tue, Nov 28, 2023 at 08:16:18PM +0100, Geert Uytterhoeven wrote:
> On Tue, Nov 28, 2023 at 8:03 PM Javier Martinez Canillas
> wrote:
> > Geert Uytterhoeven writes:
> > > The Imagination Technologies PowerVR Series 6 GPU is currently only
> > > supported on Texas Instruments K3 AM62x
On Tue, 28 Nov 2023 17:35:07 +, Donald Robson wrote:
> Some reported by Stephen Rothwell. The rest were found by running the
> kernel-doc build script.
> Some indentation fixes.
>
>
Applied to drm/drm-misc (drm-misc-next).
Thanks!
Maxime
Hi Dan,
On Wed, Nov 15, 2023 at 05:42:17PM -0500, Dan Carpenter wrote:
> On Mon, Nov 06, 2023 at 02:58:12PM +0100, mrip...@kernel.org wrote:
> > > But a similar thing is happening here where we have so many bogus
> > > warnings that we missed a real bug.
> >
> > IIRC, there was a similar
Hi,
On Sat, Nov 11, 2023 at 12:54:53AM +0530, Dipam Turkar wrote:
> Introduce unit tests for the drm_mode_create_dvi_i_properties() function to
> ensure
> the proper creation of DVI-I specific connector properties.
>
> Signed-off-by: Dipam Turkar
> ---
>
On Fri, Nov 24, 2023 at 11:15:12AM +0100, Marco Pagani wrote:
>
>
> On 2023-11-24 09:49, Maxime Ripard wrote:
> > Hi,
> >
> > On Thu, Nov 23, 2023 at 11:01:46AM +0100, Marco Pagani wrote:
> >> +static int drm_gem_shmem_test_init(struct kunit *test
Hi Jani,
On Tue, Nov 28, 2023 at 02:54:02PM +0200, Jani Nikula wrote:
> On Tue, 28 Nov 2023, Maxime Ripard wrote:
> > All the drm_connector_init variants take at least a pointer to the
> > device, connector and hooks implementation.
> >
> > However, none of th
On Sat, 25 Nov 2023 00:36:37 +0100, Danilo Krummrich wrote:
> Extend pvr_device_addr_and_size_are_valid() by the corresponding GPUVM
> sanity checks. This includes a, previously missing, overflow check for
> the base address and size of the requested mapping.
>
>
Applied to drm/drm-misc
On Sat, 25 Nov 2023 00:36:38 +0100, Danilo Krummrich wrote:
> The driver specific reference count indicates whether the VM should be
> teared down, whereas GPUVM's reference count indicates whether the VM
> structure can finally be freed.
>
> Hence, free the VM structure in pvr_gpuvm_free() and
On Sat, 25 Nov 2023 00:36:36 +0100, Danilo Krummrich wrote:
> Use drm_gpuvm_bo_obtain() instead of drm_gpuvm_bo_create(). The latter
> should only be used in conjunction with drm_gpuvm_bo_obtain_prealloc().
>
> drm_gpuvm_bo_obtain() re-uses existing instances of a given VM and BO
> combination,
On Mon, 27 Nov 2023 09:04:30 +0800, Yang Li wrote:
> ./drivers/gpu/drm/imagination/pvr_free_list.c:258:2-3: Unneeded semicolon
>
>
Applied to drm/drm-misc (drm-misc-next).
Thanks!
Maxime
On Fri, 24 Nov 2023 16:39:17 +, Colin Ian King wrote:
> There are a couple of spelling mistakes in literal strings in the
> stid_fmts array. Fix these.
>
>
Applied to drm/drm-misc (drm-misc-next).
Thanks!
Maxime
On Tue, Nov 28, 2023 at 11:16:23AM +0100, Linus Walleij wrote:
> On Tue, Nov 28, 2023 at 11:13 AM Neil Armstrong
> wrote:
> > On 28/11/2023 11:12, Neil Armstrong wrote:
> > > Hi,
> > >
> > > On Tue, 28 Nov 2023 00:10:18 +0100, Linus Walleij wrote:
> > >> This series reverts the attempts to fix
Hi,
On Fri, Nov 24, 2023 at 11:59:11AM +0100, Boris Brezillon wrote:
> On Fri, 24 Nov 2023 11:40:06 +0100
> Maxime Ripard wrote:
>
> > On Mon, Oct 30, 2023 at 02:01:43AM +0300, Dmitry Osipenko wrote:
> > > Add locked and remove unlocked postfixes from drm-shmem func
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.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i
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.
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 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
The register mask and bits to enable or disable a given infoframe
depends on its type.
This is currently passed as an argument to the function that writes an
infoframe, but let's create a helper function to retrieve them based on
the type to make further reworks easier.
Signed-off-by: Maxime
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 | 636 +
drivers/gpu/drm/vc4/vc4_hdmi.h | 44 +--
drivers/gpu/drm/vc4
The sun4i_hdmi driver still uses the non-atomic variants of the encoder
hooks, so let's convert to their atomic equivalents.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu
it obvious what
we are doing in the error path.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/rockchip/inno_hdmi.c | 53 +++-
1 file changed, 34 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c
b/drivers/gpu/drm/rockchip
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 | 71
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().
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 16
1 file changed
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
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 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
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 | 101 ++-
1 file changed, 41 insertions(+), 60 deletions
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
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 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
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
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
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 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
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 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
given mode.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_atomic_state_helper.c | 9 +++
drivers/gpu/drm/drm_connector.c| 7 +++
.../gpu/drm/tests/drm_atomic_state_helper_test.c | 69 ++
drivers/gpu/drm/tests/drm_connector_test.c
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
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 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
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 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
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
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
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
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
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/drm_connector_test.c
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
and error out if any is NULL.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_connector.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index b0516505f7ae..2f60755dccdd 100644
--- a/drivers/gpu/drm/drm_connector.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
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
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
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 | 219 -
1 file changed, 218 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
each test 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 v4:
- Create
o Estevam
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: NXP Linux Team
> Cc: Pengutronix Kernel Team
> Cc: Sascha Hauer
> Cc: Shawn Guo
> Cc: Stefan Agner
> Cc: Thomas Zimmermann
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-arm-ker...@lists.infr
Greg, Rafael,
On Mon, Nov 27, 2023 at 01:14:13PM +0800, Liu Ying wrote:
> Export device_is_dependent() since the drm_kms_helper module is starting
> to use it.
>
> Signed-off-by: Liu Ying
> ---
> v2:
> * Newly introduced as needed by patch 2.
>
> drivers/base/core.c | 1 +
> 1 file changed, 1
On Mon, Nov 27, 2023 at 05:03:53PM +0100, Linus Walleij wrote:
> On Mon, Nov 27, 2023 at 6:10 AM Liu Ying wrote:
>
> > This series aims to check panel device dependency upon DRM device before
> > managing device link between them. It fixes eariler patches in v6.7-rc1
> > which tried to manage
Hi,
On Sat, Nov 25, 2023 at 11:00:52AM +0100, Johan Jonker wrote:
> In stead of further cripplingRockchip HDMI drivers one could also make
> it functional based on EDID info.
I'm not crippling it, it was dead code. This has no functional impact
whatsoever.
> To start with the output could you
Hi Johan,
On Sun, Nov 26, 2023 at 11:55:03AM +0100, Johan Jonker wrote:
> Combined update for the Rockchip inno_hdmi driver in a
> somewhat similar way to what is proposed for the
> "Create HDMI Connector infrastructure patch serie".
> Keeping the inno_hdmi and rk3066_hdmi driver functions
>
Hi,
On Fri, Nov 24, 2023 at 09:41:22AM +0100, Neil Armstrong wrote:
> This add nodes to support the Khadas TS050 panel on the
> Khadas VIM3 & VIM3L boards.
>
> Signed-off-by: Neil Armstrong
> ---
> .../boot/dts/amlogic/meson-g12b-khadas-vim3.dtsi | 2 +-
>
iewed-by: Boris Brezillon
>
> [ ... ]
Acked-by: Maxime Ripard
Thanks!
Maxime
; Reviewed-by: Boris Brezillon
> Signed-off-by: Dmitry Osipenko
The naming convention discussion aside, and once it's settled and fixed:
Acked-by: Maxime Ripard
Maxime
signature.asc
Description: PGP signature
On Mon, Oct 30, 2023 at 02:01:47AM +0300, Dmitry Osipenko wrote:
> Add lockless drm_gem_shmem_get_pages() helper that skips taking reservation
> lock if pages_use_count is non-zero, leveraging from atomicity of the
> refcount_t. Make drm_gem_shmem_mmap() to utilize the new helper.
>
>
gt;
> [ ... ]
Acked-by: Maxime Ripard
Thanks!
Maxime
rd-pinned
> in memory, but whether pages exist and are soft-pinned (and could be swapped
> out). The pages_pin_count > 1 will hard-pin pages in memory.
>
> [ ... ]
Acked-by: Maxime Ripard
Thanks!
Maxime
de is gone, remove
> the obsoleted is_iomem test to clean up the code.
>
>
> [ ... ]
Acked-by: Maxime Ripard
Thanks!
Maxime
On Mon, Oct 30, 2023 at 02:01:43AM +0300, Dmitry Osipenko wrote:
> Add locked and remove unlocked postfixes from drm-shmem function names,
> making names consistent with the drm/gem core code.
>
> Reviewed-by: Boris Brezillon
> Suggested-by: Boris Brezillon
> Signed-off-by: Dmitry Osipenko
On Mon, 30 Oct 2023 02:01:42 +0300, Dmitry Osipenko wrote:
> Make all drm-shmem exported symbols GPL to make them consistent with
> the rest of drm-shmem symbols.
>
> Reviewed-by: Boris Brezillon
> Signed-off-by: Dmitry Osipenko
>
> [ ... ]
Acked-by: Maxime Ripard
Thanks!
Maxime
Boris Brezillon
>
> [ ... ]
Acked-by: Maxime Ripard
Thanks!
Maxime
m consistent with the rest of the API functions.
>
>
> [ ... ]
Acked-by: Maxime Ripard
Thanks!
Maxime
Hi,
On Thu, Nov 23, 2023 at 11:01:46AM +0100, Marco Pagani wrote:
> +static int drm_gem_shmem_test_init(struct kunit *test)
> +{
> + struct device *dev;
> + struct fake_dev {
> + struct drm_device drm_dev;
> + } *fdev;
> +
[...]
> +
> + /*
> + * The DRM core
On Fri, Nov 24, 2023 at 03:51:00PM +0800, Sui Jingfeng wrote:
> Hi,
>
> On 2023/11/24 15:38, Maxime Ripard wrote:
> > On Fri, Nov 24, 2023 at 01:52:26AM +0800, Sui Jingfeng wrote:
> > > On 2023/11/23 16:08, Dmitry Baryshkov wrote:
> > > > > I'm agree
On Fri, Nov 24, 2023 at 01:52:26AM +0800, Sui Jingfeng wrote:
> On 2023/11/23 16:08, Dmitry Baryshkov wrote:
> > > I'm agree with the idea that drm bridges drivers involved toward to a
> > > direction
> > > that support more complex design, but I think we should also leave a way
> > > for the
>
Hi,
Here's this week drm-misc-next PR.
It's been fairly calm, but there's one big change: the IMG GPU driver is
now merged!
Maxime
drm-misc-next-2023-11-23:
drm-misc-next for 6.8:
UAPI Changes:
Cross-subsystem Changes:
Core Changes:
- Drop deprecated drm_kms_helper.edid_firmware module
Hi,
On Wed, Nov 22, 2023 at 04:34:21PM +, Donald Robson wrote:
> This patch series adds the initial DRM driver for Imagination Technologies
> PowerVR
> GPUs, starting with those based on our Rogue architecture. It's worth pointing
> out that this is a new driver, written from the ground up,
Hi Luben,
On Thu, Nov 16, 2023 at 09:27:58AM +0100, Daniel Vetter wrote:
> On Thu, Nov 16, 2023 at 09:11:43AM +0100, Maxime Ripard wrote:
> > On Tue, Nov 14, 2023 at 06:46:21PM -0500, Luben Tuikov wrote:
> > > On 2023-11-13 22:08, Stephen Rothwell wrote:
> > > > BT
On Tue, Nov 21, 2023 at 04:56:44PM +0800, Liu Ying wrote:
> Fix a couple of building warnings on used uninitialized 'best_m' and
> 'best_n' local variables by initializing them to zero. This makes compiler
> happy only. No functional change.
>
> Fixes: ce62f8ea7e3f ("drm/bridge: imx: Add i.MX93
conversion rules.
> >
> > Ville Syrjälä (4):
> > drm: Fix color LUT rounding
> ^
> I'd like to merge this via drm-intel-next as needs to match
> the rounding done in the readout path in i915.
>
> Maarten,Maxime,Thomas can I get an ack for that?
Acked-by: Maxime Ripard
Maxime
signature.asc
Description: PGP signature
On Fri, Nov 17, 2023 at 12:24:22PM +0800, Sui Jingfeng wrote:
> Hi,
>
> On 2023/11/16 23:23, Dmitry Baryshkov wrote:
> > > > > Then you will need some way (fwnode?) to
> > > > > discover the bridge chain. And at the last point you will get into the
> > > > > device data and/or properties
901 - 1000 of 7633 matches
Mail list logo
