On Fri, Jan 12, 2024 at 02:44:57PM +0100, Daniel Vetter wrote:
> On Thu, Jan 04, 2024 at 05:00:50PM +0100, Jocelyn Falempe wrote:
> > Add support for the drm_panic module, which displays a user-friendly
> > message to the screen when a kernel panic occurs.
> >
> > Signed-off-by: Jocelyn Falempe
On Fri, Jan 12, 2024 at 02:41:53PM +0100, Daniel Vetter wrote:
> > + fb = plane->state->fb;
> > + /* Only support linear modifier */
> > + if (fb->modifier != DRM_FORMAT_MOD_LINEAR)
> > + continue;
> > +
> > + /* Check if color format is
Hi,
Here's this week drm-misc-next-fixes PR.
Maxime
drm-misc-next-fixes-2024-01-11:
A fix for the v3d register readout, and two compilation fixes for
rockchip.
The following changes since commit eee706839333ec0643f1b4898a37588025bf4cb5:
drm/imagination: pvr_device.h: fix all kernel-doc
On Thu, Jan 04, 2024 at 02:34:33PM +, Biju Das wrote:
> Hi Maxime Ripard,
>
> > -Original Message-
> > From: Maxime Ripard
> > Sent: Friday, December 15, 2023 2:24 PM
> > Subject: Re: [PATCH v15 3/5] drm: renesas: Add RZ/G2L DU Support
> >
&g
On Fri, Jan 05, 2024 at 11:13:24AM +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
> ---
> drivers/gpu/drm/tests/drm_managed_test.c | 28
On Wed, Jan 10, 2024 at 12:00:23PM +0100, Luca Weiss wrote:
> On Wed Jan 10, 2024 at 11:58 AM CET, Konrad Dybcio wrote:
> >
> >
> > On 1/5/24 15:29, Luca Weiss wrote:
> > > Add the description for the display panel found on this phone and remove
> > > the simple-framebuffer that was in place until
Hi,
On Tue, Jan 09, 2024 at 06:11:02PM +, Andri Yngvason wrote:
> From: Werner Sembach
>
> Add a new general drm property "preferred color format" which can be used
> by userspace to tell the graphic drivers to which color format to use.
>
> Possible options are:
> - auto
st, ret, 0);
> +
> + ret = drm_dev_register(priv->drm, 0);
> + KUNIT_ASSERT_EQ(test, ret, 0);
> +
> + drm_dev_unregister(priv->drm);
> + drm_kunit_helper_free_device(test, priv->drm->dev);
> +
> + KUNIT_EXPECT_TRUE_MSG(test, priv->action_done,
On Sat, Jan 06, 2024 at 07:31:18PM +0530, Dipam Turkar wrote:
> ---
> drivers/gpu/drm/tests/drm_connector_test.c | 20
> 1 file changed, 20 insertions(+)
You're missing your commit message, Signed-off-by and version changes here.
> diff --git
On Sat, Dec 23, 2023 at 03:59:33PM +0530, Dipam Turkar wrote:
> I needed some help regarding introducing a separate test for testing if the
> function still works if called a second time as suggested. Wouldn't we need
> to call it on the same object we called in the first time. So, that will
>
On Fri, Jan 05, 2024 at 11:13:22AM +0100, Michał Winiarski wrote:
> Add comments explaining the intention behind the test and certain
> implementation details related to device lifetime.
>
> Signed-off-by: Michał Winiarski
> ---
> drivers/gpu/drm/tests/drm_managed_test.c | 11 ++-
> 1
On Fri, Jan 05, 2024 at 11:13:21AM +0100, Michał Winiarski wrote:
> DRM managed release (drm_managed_release) is called as part of devres
> release (devres_release_all), which is not async.
> The release action should have already been executed once
> drm_kunit_helper_free_device exits, meaning
On Fri, Jan 05, 2024 at 11:13:20AM +0100, Michał Winiarski wrote:
> DRM tests use "_" rather than "-" as word separator. Rename the test
> suite to match other tests.
>
> Signed-off-by: Michał Winiarski
> ---
> drivers/gpu/drm/tests/drm_managed_test.c | 2 +-
> 1 file changed, 1 insertion(+), 1
Hi,
On Thu, Jan 04, 2024 at 05:00:49PM +0100, Jocelyn Falempe wrote:
> This was initialy done for imx6, but should work on most drivers
> using drm_fb_dma_helper.
>
> Signed-off-by: Jocelyn Falempe
> ---
> drivers/gpu/drm/drm_fb_dma_helper.c | 55 +
>
Hi Arthur,
On Fri, Jan 05, 2024 at 01:35:08PM -0300, Arthur Grillo wrote:
> diff --git a/drivers/gpu/drm/vkms/vkms_formats.c
> b/drivers/gpu/drm/vkms/vkms_formats.c
> index b654b6661a20..11df990a0fa9 100644
> --- a/drivers/gpu/drm/vkms/vkms_formats.c
> +++ b/drivers/gpu/drm/vkms/vkms_formats.c
>
On Fri, 5 Jan 2024 14:58:36 -0300, MaÃra Canal wrote:
> Currently, when using non-blocking commits, we can see the following
> kernel warning:
>
> [ 110.908514] [ cut here ]
> [ 110.908529] refcount_t: underflow; use-after-free.
>
> [ ... ]
Ac
Hi!
Here's this week drm-misc-next-fixes PR
Maxime
drm-misc-next-fixes-2024-01-04:
One fix for drm/plane to avoid a use-after-free and some additional
warnings to prevent more of these occurences, a lock inversion
dependency fix and an indentation fix for drm/rockchip, and some doc
warning
Hi Dave,
Happy new year :)
On Tue, Jan 02, 2024 at 03:12:26PM +, Dave Stevenson wrote:
> Hi Maxime
>
> On Mon, 14 Nov 2022 at 13:00, Maxime Ripard wrote:
> >
> > The current construction of the named mode parsing doesn't allow to extend
> > it easily. Let's mov
On Sat, 16 Dec 2023 14:15:27 +, Simon Ser wrote:
> Bubble up any error to the caller.
>
>
Applied to drm/drm-misc (drm-misc-next).
Thanks!
Maxime
On Sat, 30 Dec 2023 21:49:10 -0800, Randy Dunlap wrote:
> Correct all kernel-doc notation on pvr_device.h so that there are no
> kernel-doc warnings remaining.
>
> pvr_device.h:292: warning: Excess struct member 'active' description in
> 'pvr_device'
> pvr_device.h:292: warning: Excess struct
On Sat, 30 Dec 2023 21:48:56 -0800, Randy Dunlap wrote:
> Update kernel-doc comments in to correct all
> kernel-doc warnings:
>
> drm_gpuvm.h:148: warning: Excess struct member 'addr' description in
> 'drm_gpuva'
> drm_gpuvm.h:148: warning: Excess struct member 'offset' description in
>
Hi,
On Wed, Dec 27, 2023 at 04:19:19PM +0100, AL13N wrote:
> I have a RPI4B with upstream kernel 6.1 64bit and there is no /dev/video10
> present. I thought if I waited a bit more, it would appear in the kernel,
> but that was folly on my part.
>
> Currently, watching a movie is painful since
to do is to include
> > drm_edid.h where needed, not from somewhat random intermediate
> > headers. I hope this uncovers anything I missed.
>
> The kernel test robot came back with clean results.
>
> Added a bunch more Cc's here. Ack to merge this via drm-misc-next,
> please?
Acked-by: Maxime Ripard
Maxime
signature.asc
Description: PGP signature
On Tue, Dec 19, 2023 at 04:40:12PM +0100, Johan Jonker wrote:
>
>
> On 12/19/23 13:55, Maxime Ripard wrote:
> > Hi,
> >
> > On Mon, Dec 18, 2023 at 04:49:06PM +0100, Johan Jonker wrote:
> >> CRTC size validation for the display controller has been added
On Tue, Dec 19, 2023 at 11:19:49AM -0600, Andrew Davis wrote:
> On 12/18/23 4:54 AM, H. Nikolaus Schaller wrote:
> >
> >
> > > Am 18.12.2023 um 11:14 schrieb Maxime Ripard :
> > >
> > > On Mon, Dec 18, 2023 at 10:28:09AM +0100, H.
On Mon, Dec 18, 2023 at 11:54:47AM +0100, H. Nikolaus Schaller wrote:
>
>
> > Am 18.12.2023 um 11:14 schrieb Maxime Ripard :
> >
> > On Mon, Dec 18, 2023 at 10:28:09AM +0100, H. Nikolaus Schaller wrote:
> >> Hi Maxime,
> >>
> >
Hi,
Here's this week drm-misc-next-fixes PR
Thanks!
Maxime
drm-misc-next-fixes-2023-12-21:
More fixes for the new imagination drier, a DT node refcount fix for the
new aux bridge driver and a missing header fix for the LUT management
code.
The following changes since commit
Hi,
On Mon, Dec 18, 2023 at 04:49:06PM +0100, Johan Jonker wrote:
> CRTC size validation for the display controller has been added with
> Commit 8e140cb60270 ("drm/rockchip: vop: limit maximum resolution to
> hardware capabilities"), so we can drop the custom fill_modes hook.
>
> Signed-off-by:
On Mon, 18 Dec 2023 16:48:40 +0100, Johan Jonker wrote:
> The drm_dev field in the rk3066_hdmi struct stores a pointer to the DRM
> device but is never used anywhere in the driver. Let's remove it.
>
> Signed-off-by: Johan Jonker
Reviewed-by: Maxime Ripard
Thanks!
Maxime
On Mon, Dec 18, 2023 at 10:28:09AM +0100, H. Nikolaus Schaller wrote:
> Hi Maxime,
>
> > Am 15.12.2023 um 14:33 schrieb Maxime Ripard :
> >
> >>>
> >>> It's for a separate architecture, with a separate driver, maintained out
> >>>
Hi,
On Fri, Dec 15, 2023 at 04:54:28PM +0200, Pekka Paalanen wrote:
> On Thu, 14 Dec 2023 11:09:15 +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
Hi,
On Mon, Dec 11, 2023 at 11:09:39PM +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
> ---
> drivers/gpu/drm/tests/drm_managed_test.c | 29
On Fri, Dec 15, 2023 at 01:25:48PM +, Biju Das wrote:
> Hi Maxime Ripard,
>
> > -Original Message-
> > From: Maxime Ripard
> > Sent: Friday, December 15, 2023 10:24 AM
> > Subject: Re: [PATCH v15 3/5] drm: renesas: Add RZ/G2L DU Support
> >
&g
On Fri, Dec 15, 2023 at 02:19:25PM +, Biju Das wrote:
> Hi Maxime Ripard,
>
> > -Original Message-
> > From: Biju Das
> > Sent: Friday, December 15, 2023 1:52 PM
> > Subject: RE: [PATCH v15 3/5] drm: renesas: Add RZ/G2L DU Support
> >
> >
On Fri, Dec 15, 2023 at 01:52:28PM +, Biju Das wrote:
> > > > > > > +static int rzg2l_du_crtc_enable_vblank(struct drm_crtc *crtc) {
> > > > > > > + struct rzg2l_du_crtc *rcrtc = to_rzg2l_crtc(crtc);
> > > > > > > +
> > > > > > > + rcrtc->vblank_enable = true;
> > > > > > > +
> > > > > > > +
On Thu, Dec 07, 2023 at 11:33:53AM +0100, H. Nikolaus Schaller wrote:
> Hi Maxime,
>
> > Am 07.12.2023 um 10:20 schrieb Maxime Ripard :
> >
> > On Tue, Dec 05, 2023 at 02:50:08PM +0100, H. Nikolaus Schaller wrote:
> >> Hi,
> >>
> >
On Wed, 13 Dec 2023 14:44:30 +, Donald Robson wrote:
> drivers/gpu/drm/imagination/pvr_vm.c:631 pvr_vm_create_context()
> error: 'vm_ctx->mmu_ctx' dereferencing possible ERR_PTR()
>
> 612 vm_ctx->mmu_ctx = pvr_mmu_context_create(pvr_dev);
> 613 err =
On Wed, 13 Dec 2023 14:44:31 +, Donald Robson wrote:
> It is possible to double free the vm_ctx->mmu_ctx object in this
> function.
>
> 630 err_page_table_destroy:
> --> 631 pvr_mmu_context_destroy(vm_ctx->mmu_ctx);
>
> The pvr_vm_context_put() function does:
>
> [...]
Applied
On Fri, 08 Dec 2023 16:30:19 +, Donald Robson wrote:
> While writing the matching IGT suite I discovered that it's possible to
> cause a kernel oops when using DRM_IOCTL_PVR_CREATE_HWRT_DATASET when
> the call to hwrt_init_common_fw_structure() fails.
>
> Use an unwind-type error path to
On Fri, 08 Dec 2023 16:08:25 +, Donald Robson wrote:
> Unwinding loop in error path for this function uses unsigned limit
> variable, causing the promotion of the signed counter variable.
>
> --> 204 for (; pfn >= start_pfn; pfn--)
>
> If
On Fri, Dec 15, 2023 at 11:37:07AM +, Biju Das wrote:
> Hi Maxime Ripard,
>
> > -Original Message-
> > From: Maxime Ripard
> > Sent: Friday, December 15, 2023 10:24 AM
> > To: Biju Das
> > Subject: Re: [PATCH v15 3/5] drm: renesas: Add RZ/G2L DU S
On Wed, Dec 13, 2023 at 04:52:52PM +0100, Uwe Kleine-König wrote:
> On Wed, Dec 13, 2023 at 12:54:14PM +0100, Maxime Ripard wrote:
> > On Wed, Dec 13, 2023 at 12:08:29PM +0100, Uwe Kleine-König wrote:
> > > On Wed, Dec 13, 2023 at 09:36:49AM +0100, Maxime Ripard wrote:
> >
On Mon, Dec 11, 2023 at 11:09:38PM +0100, Michał Winiarski wrote:
> It simplifies the process of extending the test suite with additional
> test cases without unnecessary duplication.
>
> Signed-off-by: Michał Winiarski
> ---
> drivers/gpu/drm/tests/drm_managed_test.c | 51
On Mon, 11 Dec 2023 23:09:37 +0100, MichaÅ Winiarski wrote:
> Similar to devres equivalent, it allows to call the "release" action
> directly and remove the resource from the managed resources list.
>
> Signed-off-by: MichaÅ Winiarski
Reviewed-by: Maxime Ripard
Thanks!
Maxime
On Thu, Dec 14, 2023 at 03:24:17PM +, Biju Das wrote:
> Hi Maxime Ripard,
>
> Thanks for the feedback.
>
> > -Original Message-
> > From: Maxime Ripard
> > Sent: Wednesday, December 13, 2023 3:47 PM
> > To: Biju Das
> > Subject: Re: [
On Fri, Dec 15, 2023 at 07:47:07AM +, Biju Das wrote:
> Hi Maxime Ripard,
>
> > -Original Message-
> > From: Biju Das
> > Sent: Thursday, December 14, 2023 8:50 PM
> > Subject: RE: [PATCH v15 3/5] drm: renesas: Add RZ/G2L DU Sup
On Thu, Dec 14, 2023 at 08:50:14PM +, Biju Das wrote:
> Hi Maxime Ripard,
>
>
> > -Original Message-
> > From: Biju Das
> > Sent: Thursday, December 14, 2023 3:24 PM
> > Subject: RE: [PATCH v15 3/5] drm: renesas: Add RZ/G2L DU Support
> >
>
Hi Neil,
On Wed, Dec 13, 2023 at 05:44:28PM +0100, Neil Armstrong wrote:
> Le 13/12/2023 à 09:36, Maxime Ripard a écrit :
> > On Wed, Dec 13, 2023 at 08:43:00AM +0100, Uwe Kleine-König wrote:
> > > On Wed, Dec 13, 2023 at 08:16:04AM +0100, Maxime Ripard wrote:
> > > &
On Thu, Dec 14, 2023 at 04:03:04PM +0100, Jocelyn Falempe wrote:
> > > +static int imx_drm_get_scanout_buffer(struct drm_device *dev,
> > > + struct drm_scanout_buffer *sb)
> > > +{
> > > + struct drm_plane *plane;
> > > + struct drm_gem_dma_object *dma_obj;
> > > +
>
On Tue, Dec 05, 2023 at 02:43:16PM +0300, Dmitry Osipenko wrote:
> On 12/4/23 15:55, Maxime Ripard wrote:
> >> Okay, that means s/_locked/_nolock/ in drm_gem_shmem_helpers.{c,h}, I
> >> guess.
>
> DRM subsys and majority of kernel uses common _locked postfix. We sho
On Thu, Dec 14, 2023 at 02:48:21PM +0100, Maxime Ripard wrote:
> Hi,
>
> On Fri, Nov 03, 2023 at 03:53:30PM +0100, Jocelyn Falempe wrote:
> > Proof of concept to add drm_panic support on an arm based GPU.
> > I've tested it with X11/llvmpipe, because I wasn't able to
Hi,
On Fri, Nov 03, 2023 at 03:53:30PM +0100, Jocelyn Falempe wrote:
> Proof of concept to add drm_panic support on an arm based GPU.
> I've tested it with X11/llvmpipe, because I wasn't able to have
> 3d rendering with etnaviv on my imx6 board.
>
> Signed-off-by: Jocelyn Falempe
Like I said
ixel_xy() API for drivers that can't provide a linear buffer.
> * Add a flush() callback for drivers that needs to synchronize the buffer.
> * Add a void *private field, so drivers can pass private data to
>draw_pixel_xy() and flush().
> * Add ast support.
> * Add experimental imx/
Hi,
On Thu, Dec 14, 2023 at 10:33:53AM +, Donald Robson wrote:
> I will be leaving Imagination Technologies on 2023-12-15 and will no
> longer be working on this driver.
>
> Signed-off-by: Donald Robson
Applied, thanks
Good luck on your next adventure :)
Maxime
signature.asc
The name of the structure drm_atomic_state is confusing. Let's add an
entry to our todo list to rename it.
Reviewed-by: Daniel Vetter
Signed-off-by: Maxime Ripard
---
Documentation/gpu/todo.rst | 23 +++
1 file changed, 23 insertions(+)
diff --git a/Documentation/gpu
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 | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.
Commit 63e83c1dba54 ("drm: Consolidate connector arrays in
drm_atomic_state") removed the connector_states field but didn't remove
its mention in the num_connectors documentation.
Acked-by: Sui Jingfeng
Reviewed-by: Daniel Vetter
Signed-off-by: Maxime Ripard
---
include/drm/drm_at
nd its old and new state. There's no per-object data there, and there's
more than just a pointer to the objects.
Let's rephrase those fields a bit to better match the current situation.
Acked-by: Sui Jingfeng
Reviewed-by: Daniel Vetter
Signed-off-by: Maxime Ripard
---
include/drm/drm_atomic.h |
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.
Acked-by: Sui Jingfeng
Signed-off-by: Maxime Ripard
t-bindings: vendor-prefixes: Add fascontek
dt-bindings: display: panel: add Fascontek FS035VG158 panel
Marek Szyprowski (1):
drm/debugfs: fix potential NULL pointer dereference
Matthew Brost (1):
drm/doc/rfc: Mark long running workload as complete.
Maxime Ripard (1):
drm
Hi Dave,
On Tue, Dec 12, 2023 at 11:40:26AM +, Dave Stevenson wrote:
> On Thu, 7 Dec 2023 at 15:50, Maxime Ripard wrote:
> >
> > Even though we were rolling our own custom state for the vc4 HDMI
> > controller driver, we were still using the generic helper to d
On Wed, Dec 13, 2023 at 04:47:09PM +0100, Maxime Ripard wrote:
> On Tue, Nov 28, 2023 at 10:51:27AM +, Biju Das wrote:
> > +int rzg2l_du_vsp_init(struct rzg2l_du_vsp *vsp, struct device_node *np,
> > + unsigned int crtcs)
> > +{
> > + struct rzg2l
On Tue, Nov 28, 2023 at 10:51:27AM +, Biju Das wrote:
> The LCD controller is composed of Frame Compression Processor (FCPVD),
> Video Signal Processor (VSPD), and Display Unit (DU).
>
> It has DPI/DSI interfaces and supports a maximum resolution of 1080p
> along with 2 RPFs to support the
On Thu, Dec 07, 2023 at 11:14:34AM -0800, Doug Anderson wrote:
> Hi,
>
> On Thu, Dec 7, 2023 at 10:58 AM Maxime Ripard wrote:
> >
> > On Thu, Dec 07, 2023 at 10:23:53AM -0800, Doug Anderson wrote:
> > > Hi,
> > >
> > > On Thu, D
On Fri, 08 Dec 2023 18:08:56 +0100, Alex Bee wrote:
> When conditionally checking for heap existence of a certian address in
> pvr_vm_bind_op_map_init the condition whether the map request comes from a
> user is incorrect: The context must not be the kernel-context to be a
> user(space) context
On Wed, 13 Dec 2023 12:24:01 +0100, Dario Binacchi wrote:
> Adjust the includes to explicitly include the correct headers.
>
>
Applied to drm/drm-misc (drm-misc-next).
Thanks!
Maxime
On Thu, 07 Dec 2023 16:49:41 +0100, Maxime Ripard wrote:
> Even though we were rolling our own custom state for the vc4 HDMI
> controller driver, we were still using the generic helper to destroy
> that state.
>
> It was mostly working since the underlying state is the first member
On Wed, 13 Dec 2023 12:24:32 +0100, Dario Binacchi wrote:
> Adjust the includes to explicitly include the correct headers.
>
>
Applied to drm/drm-misc (drm-misc-next).
Thanks!
Maxime
On Tue, 12 Dec 2023 20:41:07 -0800, Randy Dunlap wrote:
> Correct spellos reported by codespell.
> Fix some grammar (as 's' to a few words).
>
>
Applied to drm/drm-misc (drm-misc-next).
Thanks!
Maxime
On Tue, 12 Dec 2023 20:32:26 -0800, Randy Dunlap wrote:
> Fix spelling problems as identified by codespell.
>
>
Applied to drm/drm-misc (drm-misc-next).
Thanks!
Maxime
On Tue, 12 Dec 2023 20:39:25 -0800, Randy Dunlap wrote:
> Correct spelling mistakes that were identified by codespell.
>
>
Applied to drm/drm-misc (drm-misc-next).
Thanks!
Maxime
On Wed, Dec 13, 2023 at 12:59:05PM +0100, Dario Binacchi wrote:
> Hi Jagan and Dave,
>
> On Wed, Dec 6, 2023 at 2:57 PM Michael Nazzareno Trimarchi
> wrote:
> >
> > Hi Jagan
> >
> > On Wed, Dec 6, 2023 at 2:31 PM Jagan Teki
> > wrote:
> > >
> > > Hi Dario,
> > >
> > > On Wed, Dec 6, 2023 at
On Wed, Dec 13, 2023 at 12:08:29PM +0100, Uwe Kleine-König wrote:
> On Wed, Dec 13, 2023 at 09:36:49AM +0100, Maxime Ripard wrote:
> > On Wed, Dec 13, 2023 at 08:43:00AM +0100, Uwe Kleine-König wrote:
> > > On Wed, Dec 13, 2023 at 08:16:04AM +0100, Maxime Ripard wrote:
> >
Hi,
On Wed, Dec 13, 2023 at 08:43:00AM +0100, Uwe Kleine-König wrote:
> On Wed, Dec 13, 2023 at 08:16:04AM +0100, Maxime Ripard wrote:
> > On Tue, Dec 12, 2023 at 06:26:37PM +0100, Uwe Kleine-König wrote:
> > > clk_rate_exclusive_get() returns zero unconditionally
Hi,
On Tue, Dec 12, 2023 at 06:26:37PM +0100, Uwe Kleine-König wrote:
> Hello,
>
> clk_rate_exclusive_get() returns zero unconditionally. Most users "know"
> that and don't check the return value. This series fixes the four users
> that do error checking on the returned value and then makes
as first hoping for.
> >
> > I was aware that there was a challenge going from fbtft to DRM because
> > in fbtft there is support for all panel setups using the
> > property, but in DRM every panel needed support in a driver. So I
> > started to look at adding
On Sat, 9 Dec 2023 07:36:59 +0100, Marek Vasut wrote:
> From: Elmar Albert
>
> Document support for the AUO G156HAN04.0 LVDS display.
>
> G156HAN04.0 is a Color Active Matrix Liquid Crystal Display composed of
>
> [ ... ]
Acked-by: Maxime Ripard
Thanks!
Maxime
1080(V) screen
>
> [ ... ]
Acked-by: Maxime Ripard
Thanks!
Maxime
On Fri, Dec 08, 2023 at 03:59:46PM +0200, Pekka Paalanen wrote:
> On Fri, 8 Dec 2023 13:25:22 +0100
> Maxime Ripard wrote:
>
> > On Fri, Dec 08, 2023 at 10:08:28AM +0200, Pekka Paalanen wrote:
> > > On Thu, 7 Dec 2023 15:27:33 +0100
> > > Maxime Ripard wrote
On Fri, 08 Dec 2023 15:12:38 +0200, Jani Nikula wrote:
> Commit 3823119b9c2b ("drm/crtc: Fix uninit-value bug in
> drm_mode_setcrtc") was supposed to fix use of an uninitialized variable,
> but introduced another.
>
> num_connectors is only initialized if crtc_req->count_connectors > 0,
> but
On Fri, Dec 08, 2023 at 10:08:28AM +0200, Pekka Paalanen wrote:
> On Thu, 7 Dec 2023 15:27:33 +0100
> Maxime Ripard wrote:
>
> > On Tue, Dec 05, 2023 at 10:51:06AM +0200, Pekka Paalanen wrote:
> > > On Mon, 4 Dec 2023 13:17:06 +0100
> > > Maxime Ripard wr
On Fri, 08 Dec 2023 08:30:34 +0800, Yang Li wrote:
> ./drivers/gpu/drm/imagination/pvr_fw_trace.c:251:2-3: Unneeded semicolon
>
>
Applied to drm/drm-misc (drm-misc-next).
Thanks!
Maxime
On Wed, 06 Dec 2023 17:37:24 +0300, Dan Carpenter wrote:
> This code dereferences "page->pvr_dev" and then checked for NULL on the
> next line. Re-order it to avoid a potential NULL pointer dereference.
>
>
Applied to drm/drm-misc (drm-misc-next).
Thanks!
Maxime
On Fri, 08 Dec 2023 04:03:14 +0300, Dmitry Baryshkov wrote:
> As the renamed drm_atomic_helper_check_wb_connector_state() now accepts
> drm_writeback_connector as the first argument (instead of drm_encoder),
> move the VKMS writeback atomic_check from drm_encoder_helper_funcs to
>
On Fri, 08 Dec 2023 04:03:13 +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 encoder
On Fri, 21 Jul 2023 09:14:46 -0700, Ziqi Zhao wrote:
> The connector_set contains uninitialized values when allocated with
> kmalloc_array. However, in the "out" branch, the logic assumes that any
> element in connector_set would be equal to NULL if failed to
> initialize, which causes the bug
t; >> 在 2023-12-07 18:48:13，"Keith Zhao" 写道：
> >>>
> >>>
> >>>On 2023/12/7 17:02, Andy Yan wrote:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> Hi Keith：
> >>>>
On Thu, Dec 07, 2023 at 10:23:53AM -0800, Doug Anderson wrote:
> Hi,
>
> On Thu, Dec 7, 2023 at 12:18 AM Pin-yen Lin wrote:
> >
> > These panels are used by Mediatek MT8173 Chromebooks but we can't find
> > the corresponding data sheets, and these panels used to work on v4.19
> > kernel without
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
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/rockchip/inno_hdmi.c | 86 ++--
1 file changed, 42 insertions(+), 44 deletions
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
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
701 - 800 of 7633 matches
Mail list logo
