++ b/drivers/gpu/drm/tidss/tidss_scale_coefs.c
> @@ -1,4 +1,4 @@
> -// SPDX-License-Identifier: GPL-2.0
> +// SPDX-License-Identifier: GPL-2.0 OR MIT
> /*
> * Copyright (C) 2018 Texas Instruments Incorporated - https://www.ti.com/
> * Author: Jyri Sarha
> diff --git a/drivers/gpu/drm/tidss/tidss_scale_coefs.h
> b/drivers/gpu/drm/tidss/tidss_scale_coefs.h
> index 9c560d0fdac0..4689109fe560 100644
> --- a/drivers/gpu/drm/tidss/tidss_scale_coefs.h
> +++ b/drivers/gpu/drm/tidss/tidss_scale_coefs.h
> @@ -1,4 +1,4 @@
> -/* SPDX-License-Identifier: GPL-2.0 */
> +/* SPDX-License-Identifier: GPL-2.0 OR MIT */
> /*
> * Copyright (C) 2018 Texas Instruments Incorporated - https://www.ti.com/
> * Author: Jyri Sarha
--
Regards,
Laurent Pinchart
olders indeed. For
contributions whose copyright has been assigned to other entities (such
as work performed by employees for their employers), those other
entities have to ack the license change. What constitutes a substantial
enough contribution to be copyrightable is a question I won't attempt to
answer.
--
Regards,
Laurent Pinchart
oss the series.
Jiapeng Chong has sent a patch to drop the function, and I've reviewed
it. See
https://lore.kernel.org/r/20240619075436.86407-1-jiapeng.ch...@linux.alibaba.com
I've sent a pull request for v6.12 but it hasn't been processed in time
:-( See
https://lore.kernel.org/r/20240822234445.ga23...@pendragon.ideasonboard.com
--
Regards,
Laurent Pinchart
Did this one fall through the cracks ? :-(
On Fri, Aug 23, 2024 at 02:44:45AM +0300, Laurent Pinchart wrote:
> Hello Dave, Sima,
>
> The following changes since commit 11df68c265460d4dff5d19a1313f0fff69470f98:
>
> Merge tag 'drm-misc-next-2024-08-16' of
> https:
Hi Yu-Chun,
Thank you for the patch.
On Sun, Sep 01, 2024 at 09:30:46PM +0800, Yu-Chun Lin wrote:
> Corrected the spelling in the description of LVDS Display Common
> Properties.
>
> Signed-off-by: Yu-Chun Lin
Reviewed-by: Laurent Pinchart
> ---
> Documentation/devicetre
On Wed, Aug 28, 2024 at 07:21:32AM +, Biju Das wrote:
> On Tuesday, August 27, 2024 11:23 PM, Laurent Pinchart wrote:
> > Subject: Re: [PATCH v2] drm: rcar-du: Fix memory leak in rcar_du_vsps_init()
> >
> > Hi Biju,
> >
> > On Tue, Aug 27, 2024 at 04:43:12P
ange here.
>
> Signed-off-by: Jinjie Ruan
Reviewed-by: Laurent Pinchart
Tomi, feel free to push this to drm-misc.
> ---
> drivers/gpu/drm/xlnx/zynqmp_dp.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/xlnx/zynqmp_dp.c
> b/drivers
On Wed, Aug 28, 2024 at 02:52:25PM +0200, Krzysztof Kozlowski wrote:
> On 28/08/2024 14:45, Laurent Pinchart wrote:
> > On Sun, Aug 18, 2024 at 08:48:54PM +0200, Krzysztof Kozlowski wrote:
> >> On 18/08/2024 19:51, Laurent Pinchart wrote:
> >>> On Sun, Aug 18, 2024
Hi Krzysztof,
On Sun, Aug 18, 2024 at 08:48:54PM +0200, Krzysztof Kozlowski wrote:
> On 18/08/2024 19:51, Laurent Pinchart wrote:
> > On Sun, Aug 18, 2024 at 07:44:22PM +0200, Krzysztof Kozlowski wrote:
> >> On 18/08/2024 19:41, Laurent Pinchart wrote:
> >>> On S
Original Message-----
> > From: Laurent Pinchart
> > Sent: Monday, December 18, 2023 10:39 AM
> > Subject: Re: [PATCH v2] drm: rcar-du: Fix memory leak in rcar_du_vsps_init()
> >
> > Hi Biju,
> >
> > Thank you for the patch.
> >
> > On Thu, Nov
hile at it drop ARCH_RENESAS dependency as DRM_RZG2L_DU depend on
> ARCH_RZG2L.
>
> Suggested-by: Tomi Valkeinen
> Signed-off-by: Biju Das
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/renesas/rz-du/Kconfig | 15 ++-
> 1 file changed, 10 insertions(
On Fri, Aug 23, 2024 at 02:33:49PM +0100, Lad, Prabhakar wrote:
> On Wed, Jun 26, 2024 at 6:51 AM Laurent Pinchart wrote:
> > On Tue, Jun 25, 2024 at 01:32:44PM +0100, Prabhakar wrote:
> > > From: Lad Prabhakar
> > >
> > > All the RZ/G2L DU specific component
Hi Biju,
On Fri, Aug 23, 2024 at 01:52:14PM +, Biju Das wrote:
> On Friday, August 23, 2024 2:15 PM, Laurent Pinchart wrote:
> > On Thu, Aug 22, 2024 at 05:23:13PM +0100, Biju Das wrote:
> > > This patch series aims to add support for RZ/G2UL DU.
> > >
> > &g
arm64/boot/dts/renesas/r9a07g043u.dtsi | 25
> .../boot/dts/renesas/r9a07g043u11-smarc.dts | 111 ++
> drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c | 8 +-
> drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c | 11 ++
> drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.c | 3 +-
> 6 files changed, 185 insertions(+), 5 deletions(-)
--
Regards,
Laurent Pinchart
f WXGA along
> with 2 RPFs to support the blending of two picture layers and raster
> operations (ROPs).
>
> The DU module is connected to VSPD. Add RZ/G2UL DU support.
>
> Signed-off-by: Biju Das
Reviewed-by: Laurent Pinchart
> ---
> v3->v4:
> * Used "
SoCs. Currently there is no user for the DPI interface and hence there
> won't be any ABI breakage for adding port@1 as required property for
> RZ/G2L and RZ/V2L SoCs.
>
> Acked-by: Conor Dooley
> Reviewed-by: Geert Uytterhoeven
> Signed-off-by: Biju Das
Reviewed
deletions(-)
--
Regards,
Laurent Pinchart
The msm_atomic_state_clear() and msm_atomic_state_free() functions are
declared but never defined. Remove their prototypes.
Signed-off-by: Laurent Pinchart
Reviewed-by: Kieran Bingham
---
drivers/gpu/drm/msm/msm_drv.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/msm
G2UL DU bindings
> >
> > Hi Laurent and Rob,
> >
> > Thanks for the feedback
> >
> > > -Original Message-
> > > From: Laurent Pinchart
> > > Sent: Tuesday, August 13, 2024 8:39 PM
> > > Subject: Re: [PATCH v3 1/4] dt-bind
Hi Thomas,
On Tue, Aug 20, 2024 at 09:22:36AM +0200, Thomas Zimmermann wrote:
> Am 18.08.24 um 22:07 schrieb Laurent Pinchart:
> > On Fri, Aug 16, 2024 at 02:22:30PM +0200, Thomas Zimmermann wrote:
> >> DRM may support multiple in-kernel clients that run as soon as a DRM
&g
gt;
> Signed-off-by: Thomas Zimmermann
> Cc: Laurent Pinchart
> Cc: Tomi Valkeinen
> Cc: Michal Simek
> ---
> drivers/gpu/drm/xlnx/zynqmp_kms.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/xlnx/zynqmp_kms.c
&
gt;
> Signed-off-by: Thomas Zimmermann
> Cc: Laurent Pinchart
> Cc: Geert Uytterhoeven
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/renesas/shmobile/shmob_drm_drv.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/
>
> The rcar-du driver specifies a preferred color mode of 32. As this
> is the default if no format has been given, leave it out entirely.
>
> Signed-off-by: Thomas Zimmermann
> Cc: Laurent Pinchart
> Cc: Kieran Bingham
Reviewed-by: Laurent Pinchart
> ---
> driv
*format);
void drm_client_setup_with_color_mode(struct drm_device *dev, unsigned int
color_mode);
#define drm_client_setup_(dev, format_or_color_mode)
\
_Generic(format_or_color_mode,
\
const struct drm_format_info *:
drm_client_setup_with_format(dev, format_or_color_mode), \
unsigned int: drm_client_setup_with_color_mode(dev,
format_or_color_mode)\
)
Up to you.
Reviewed-by: Laurent Pinchart
> +
> +#endif
--
Regards,
Laurent Pinchart
helpers into a 4CC helper,
s/form/from/
> so that is can be shared among DRM clients.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/drm_fb_helper.c | 70 +++--
> drivers/gpu/drm/drm_fourcc.c|
On Sun, Aug 18, 2024 at 07:44:22PM +0200, Krzysztof Kozlowski wrote:
> On 18/08/2024 19:41, Laurent Pinchart wrote:
> > Hi Krzysztof,
> >
> > Thank you for the patch.
> >
> > On Sun, Aug 18, 2024 at 07:30:02PM +0200, Krzysztof Kozlowski wrote:
> >> Eac
rrowed) in "if:then:". Add missing top-level constraints
> for clocks, clock-names, interrupts, resets, reset-names, renesas,cmms
> and renesas,vsps.
>
> Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Laurent Pinchart
> ---
> .../bindings/display/renesas,du.yaml
renesas,vsps:
>minItems: 1
> + maxItems: 1
>
>required:
> - clock-names
> @@ -719,6 +737,7 @@ allOf:
> - pattern: '^dclkin\.[01]$'
>
> interrupts:
> + minItems: 2
>maxItems: 2
>
> resets:
> @@ -746,9 +765,11 @@ allOf:
>
> renesas,cmms:
>minItems: 2
> + maxItems: 2
>
> renesas,vsps:
>minItems: 2
> + maxItems: 2
>
>required:
> - clock-names
> @@ -799,6 +820,7 @@ allOf:
>
> renesas,vsps:
>minItems: 2
> + maxItems: 2
>
>required:
> - clock-names
--
Regards,
Laurent Pinchart
ogic:
for (i = 0; i < RZG2L_DU_OUTPUT_MAX; ++i) {
if (rcdu->info->routes[i].possible_outputs &&
rcdu->info->routes[i].port == ep.port) {
output = i;
break;
}
}
Testing possible_outputs skips the routes that don't exist for the
device, and the ep.port comparison picks the route corresponding to the
port.
> + output = rcdu->info->routes[i].du_output;
> break;
> }
> }
--
Regards,
Laurent Pinchart
ion, based on
my experience with the R-Car DU) on the driver side, but most
importantly, type-based numbering wouldn't scale as SoCs could have
multiple ports of the same type (we've seen that happening with R-Car).
> > +
> > + required:
> > +- port
> > +else:
> > + properties:
> > +ports:
> > + properties:
> > +port@0:
> > + description: DSI
> > +port@1:
> > + description: DPI
> > +
> > + required:
> > +- port@0
> > +- port@1
> > + required:
> > +- ports
> > +
> > examples:
> ># RZ/G2L DU
> >- |
--
Regards,
Laurent Pinchart
node
> return 0;
> }
>
> +static inline unsigned int of_graph_get_port_count(struct device_node *np)
> +{
> + return 0;
> +}
> +
> static inline struct device_node *of_graph_get_port_by_id(
> struct device_node *node, u32 id)
> {
> @@ -86,6 +118,20 @@ static inline struct device_node
> *of_graph_get_next_endpoint(
> return NULL;
> }
>
> +static inline struct device_node *of_graph_get_next_ports(
> + struct device_node *parent,
> + struct device_node *previous)
> +{
> + return NULL;
> +}
> +
> +static inline struct device_node *of_graph_get_next_port(
> + struct device_node *parent,
> + struct device_node *previous)
> +{
> + return NULL;
> +}
> +
> static inline struct device_node *of_graph_get_endpoint_by_regs(
> const struct device_node *parent, int port_reg, int reg)
> {
--
Regards,
Laurent Pinchart
by: Dmitry Baryshkov
> Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/omapdrm/dss/base.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/dss/base.c
> b/drivers/gpu/drm/omapdrm/dss/base.c
> index 050ca7eafac58..
I recently discovered that the maintainer for the ADV7511 driver (in the
> I2C) framework is not included by the get_maintainers script, so perhaps
> this is the reason?
>
> Otherwise, please enlighten me on what I need to do to get this patch
> accepted!
I have no experience with HDMI audio, so I didn't comment on your patch.
Hans, is this within your area of expertise ?
--
Regards,
Laurent Pinchart
Hi Biju,
On Mon, Jul 29, 2024 at 09:05:59AM +, Biju Das wrote:
> On Saturday, July 27, 2024 1:50 AM, Laurent Pinchart wrote:
> > On Tue, Jul 09, 2024 at 02:51:41PM +0100, Biju Das wrote:
> > > Document DU found in RZ/G2UL SoC. The DU block is identical to RZ/G2L
> >
Hi Dan,
(CC'ing Tomi)
Thank for the report. It indeed seems that something is wrong.
Tomi, could you handle this and send a fix ?
On Tue, Jul 30, 2024 at 05:01:35PM -0500, Dan Carpenter wrote:
> Hello Laurent Pinchart,
>
> Commit 3cbd0c587b12 ("drm/omap: gem: Replace stru
ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@1 {
> + reg = <1>;
This may need to change depending on the outcome of the DT bind
Hi Biju,
Thank you for the patch.
On Tue, Jul 09, 2024 at 02:51:45PM +0100, Biju Das wrote:
> Add fcpvd node to RZ/G2UL SoC DTSI.
>
> Signed-off-by: Biju Das
Reviewed-by: Laurent Pinchart
> ---
> v1->v2:
> * No change.
> ---
> arch/arm64/boot/dts/r
t;aclk", "pclk", "vclk";
> + power-domains = <&cpg>;
> + resets = <&cpg R9A07G043_LCDC_RESET_N>;
> + renesas,fcp = <&fcpvd>;
This patch looks fine, but I would move it
,
> .routes = {
> @@ -40,6 +50,7 @@ static const struct rzg2l_du_device_info
> rzg2l_du_r9a07g044_info = {
> };
>
> static const struct of_device_id rzg2l_du_of_table[] = {
> + { .compatible = "renesas,r9a07g043u-du", .data =
> &rzg2l_du_r9a07g043u_info },
> { .compatible = "renesas,r9a07g044-du", .data =
> &rzg2l_du_r9a07g044_info },
> { /* sentinel */ }
> };
--
Regards,
Laurent Pinchart
; + required:
> +- port@1
Why do you use port@1 for the DPI output here, and not port@0 ?
> +else:
> + properties:
> +ports:
> + properties:
> +port@0:
> + description: DSI
> + port@1:
> + description: DPI
> +
> + required:
> +- port@0
> +- port@1
You're missing a blank line here.
> examples:
># RZ/G2L DU
>- |
--
Regards,
Laurent Pinchart
conference we will divide in smaller working groups.
Submission Deadline: 15th July 2024
We look forward to your contributions in making complex cameras a
reality in Linux!
[1] https://lpc.events/event/18/contributions/1679/
--
Regards,
Laurent Pinchart
it in the rcar-du folder. This change improves the organization
> and modularity of the driver configuration by grouping related settings
> together.
I was thinking the same the other day. Thanks for beating me at sending
a patch :-)
Reviewed-by: Laurent Pinchart
Do you or Biju has co
On Thu, Jun 20, 2024 at 09:43:05AM +0300, Tomi Valkeinen wrote:
> On 19/06/2024 22:32, Laurent Pinchart wrote:
> > Hi Jacopo,
> >
> > Thank you for the patch.
> >
> > On Wed, Jun 19, 2024 at 12:22:16PM +0200, Jacopo Mondi wrote:
> >> From: Phong Ho
t; + * channel.
" and doesn't implement the DPTSR register."
I'm pretty sure writing it is still harmless, but...
> + */
> + if (rcdu->info->gen < 4 || rgrp->num_crtcs > 1) {
> + mutex_lock(&rgrp->lock);
> + rcar_du_group_write(rgrp, DPTSR, (rgrp->dptsr_planes << 16) |
> + rgrp->dptsr_planes);
> + mutex_unlock(&rgrp->lock);
> + }
> }
>
> /*
--
Regards,
Laurent Pinchart
Hi Jacopo,
Thank you for the patch.
On Wed, Jun 19, 2024 at 12:22:16PM +0200, Jacopo Mondi wrote:
> From: Phong Hoang
>
> Add a check to the register access function when attaching a bridge
> device.
>
> Signed-off-by: Phong Hoang
> Signed-off-by: Jacopo Mondi
Reviewed
ou be able to test
the patch ?
> #define CLOCKSET1_CLKSEL (1 << 8)
> #define CLOCKSET1_CLKINSEL_EXTAL (0 << 2)
> #define CLOCKSET1_CLKINSEL_DIG (1 << 2)
--
Regards,
Laurent Pinchart
Anywhere, maybe?
I'll fix those.
Reviewed-by: Laurent Pinchart
> > drivers/gpu/drm/renesas/rcar-du/rcar_cmm.c:35:19: warning: unused function
> > 'rcar_cmm_read'.
> >
> > Reported-by: Abaci Robot
> > Closes: https://bugzilla.openanolis.cn/show_bug.c
On Mon, Jun 17, 2024 at 10:43:44AM +0300, Tomi Valkeinen wrote:
> On 16/06/2024 21:43, Laurent Pinchart wrote:
> > On Thu, Jun 13, 2024 at 11:05:01AM -0400, Sean Anderson wrote:
> >> On 5/20/24 11:05, Sean Anderson wrote:
> >>> On 5/20/24 05:40, Chris
:
> >>zynqmp_dp_remove(dpsub);
> >
> > Reviewed-by: Sean Anderson
>
> Will this be applied soon? The patch it fixes has made its way into
> the stable tree already.
If someone can merge it in drm-misc that would be the fastest way.
Otherwise I'll send a pull request at some point, but I'm overworked at
the moment.
--
Regards,
Laurent Pinchart
his flag already took place in the very first
> iteration of the serie, it was originally using a CID and that was a proposed
> replacement from Hans.
--
Regards,
Laurent Pinchart
e MODULE_DESCRIPTION() macro.
>
> Signed-off-by: Jeff Johnson
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/lontium-lt9611.c| 1 +
> drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 1 +
> drivers/gpu/drm/bridge/sii9234.c | 1 +
> drivers/gpu/drm/bri
On Wed, May 29, 2024 at 06:19:33PM +0300, Dan Carpenter wrote:
> On Wed, May 29, 2024 at 05:52:53PM +0300, Laurent Pinchart wrote:
> > On Wed, May 29, 2024 at 05:34:41PM +0300, Dan Carpenter wrote:
> > > On Wed, May 29, 2024 at 03:40:47AM +0300, Laurent Pinchart wrote:
> >
On Wed, May 29, 2024 at 05:34:41PM +0300, Dan Carpenter wrote:
> On Wed, May 29, 2024 at 03:40:47AM +0300, Laurent Pinchart wrote:
> > > @@ -286,7 +286,7 @@ static int of_get_coresight_platform_data(struct
> > > device *dev,
> > > }
> > >
> &g
On Wed, May 29, 2024 at 04:28:44PM +0300, Dmitry Baryshkov wrote:
> On Wed, May 29, 2024 at 12:55:06PM +0300, Laurent Pinchart wrote:
> > On Wed, May 29, 2024 at 12:25:56PM +0300, Dmitry Baryshkov wrote:
> > > On Wed, May 29, 2024 at 12:10:18PM +0300, Laurent Pinchart wrote:
On Wed, May 29, 2024 at 12:25:56PM +0300, Dmitry Baryshkov wrote:
> On Wed, May 29, 2024 at 12:10:18PM +0300, Laurent Pinchart wrote:
> > Hi Dmitry,
> >
> > On Wed, May 29, 2024 at 11:27:02AM +0300, Dmitry Baryshkov wrote:
> > > On Wed, May 29, 2024 at 04:03:20AM
Hi Dmitry,
On Wed, May 29, 2024 at 11:27:02AM +0300, Dmitry Baryshkov wrote:
> On Wed, May 29, 2024 at 04:03:20AM +0300, Laurent Pinchart wrote:
> > On Mon, May 27, 2024 at 03:34:48PM +0200, Geert Uytterhoeven wrote:
> > > Add support for the drm_panic module, which dis
else
> + drm_plane_helper_add(&plane->plane,
> + &rcar_du_plane_helper_funcs);
Same comment as for the shmobile-drm patch. Let's discuss it there.
>
> drm_plane_create_alpha_property(&plane->plane);
>
--
Regards,
Laurent Pinchart
nice to have to provide different operations for the
primary and overlay planes. The documentation of
drm_fb_dma_get_scanout_buffer() states
* @plane: DRM primary plane
If the intent is that only primary planes will be used to display the
panic message, shouldn't drm_panic_register() skip overlay planes ? It
would simplify drivers.
>
> return &splane->base;
> }
--
Regards,
Laurent Pinchart
Hi Morimoto-san,
Thank you for the patch.
On Tue, May 28, 2024 at 11:55:59PM +, Kuninori Morimoto wrote:
> We already have of_graph_get_remote_port(), Let's use it.
>
> Signed-off-by: Kuninori Morimoto
Reviewed-by: Laurent Pinchart
> ---
> drivers/video/fbdev/omap2
Hi Morimoto-san,
Thank you for the patch.
On Tue, May 28, 2024 at 11:55:55PM +, Kuninori Morimoto wrote:
> We already have for_each_endpoint_of_node(), don't use
> of_graph_get_next_endpoint() directly. Replace it.
>
> Signed-off-by: Kuninori Morimoto
Reviewed-by:
e_dt(struct device *dev, struct
> isc_device *isc)
>
> INIT_LIST_HEAD(&isc->subdev_entities);
>
> - while (1) {
> + for_each_endpoint_of_node(np, epn) {
I think epn doesn't have to be initialized to NULL anymore. Same below.
Reviewed-by: Laurent P
form/xilinx/xilinx-vipp.c
> +++ b/drivers/media/platform/xilinx/xilinx-vipp.c
> @@ -205,12 +205,7 @@ static int xvip_graph_build_dma(struct
> xvip_composite_device *xdev)
I think ep doesn't have to be initialized to NULL anymore.
Reviewed-by: Laurent Pinchart
>
&g
Hello Morimoto-san,
Thank you for the patch.
On Tue, May 28, 2024 at 11:55:42PM +, Kuninori Morimoto wrote:
> We already have for_each_endpoint_of_node(), don't use
> of_graph_get_next_endpoint() directly. Replace it.
>
> Signed-off-by: Kuninori Morimoto
Reviewed-by:
ce *dev, struct
> isc_device *isc)
> struct device_node *epn = NULL;
There's no need anymore to initialize epn to NULL. Same in
microchip-sama7g5-isc.c. With this addressed,
Reviewed-by: Laurent Pinchart
> struct isc_subdev_entity *subdev_entity;
> unsigned int flags
(ret)
return ret;
which leaks the reference to ep. This is not introduced by this patch,
so
Reviewed-by: Laurent Pinchart
--
Regards,
Laurent Pinchart
Hello Morimoto-san,
Thank you for the patch.
On Tue, May 28, 2024 at 11:55:26PM +, Kuninori Morimoto wrote:
> We already have for_each_endpoint_of_node(), don't use
> of_graph_get_next_endpoint() directly. Replace it.
>
> Signed-off-by: Kuninori Morimoto
Reviewed-by:
On Wed, May 22, 2024 at 05:52:56PM +, Klymenko, Anatoliy wrote:
> On Wednesday, May 22, 2024 8:32 AM, Laurent Pinchart wrote:
> > On Mon, May 20, 2024 at 08:22:31PM -0700, Anatoliy Klymenko wrote:
> > > Unconditionally enable the DPSUB layer in the corresponding atomic
Signed-off-by: Christophe JAILLET
Reviewed-by: Laurent Pinchart
> ---
> Compile tested only
> ---
> drivers/gpu/drm/xlnx/zynqmp_dpsub.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
> b/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
On Wed, May 22, 2024 at 06:45:29PM +0300, Laurent Pinchart wrote:
> On Wed, May 22, 2024 at 05:44:02PM +0300, Laurent Pinchart wrote:
> > Hi Palmer,
> >
> > (CC'ing Anatoliy)
> >
> > Thank you for the patch.
> >
> > On Tue, May 21, 2024 at
On Wed, May 22, 2024 at 05:44:02PM +0300, Laurent Pinchart wrote:
> Hi Palmer,
>
> (CC'ing Anatoliy)
>
> Thank you for the patch.
>
> On Tue, May 21, 2024 at 07:28:15AM -0700, Palmer Dabbelt wrote:
> > From: Palmer Dabbelt
> >
> > Wi
per_funcs zynqmp_dpsub_plane_helper_funcs =
> {
>
> ---
> base-commit: 673087d8b023faf34b84e8faf63bbeea3da87bab
> change-id: 20240520-dp-layer-enable-7b561af29ca8
--
Regards,
Laurent Pinchart
right fix seems to be
if (WARN_ON(layer->mode != ZYNQMP_DPSUB_LAYER_NONLIVE)) {
Anatoliy, could you check this ? Palmer, do you plan to submit a new
version of the patch, or should I send the right fix separately ?
> *num_formats = 0;
> return NULL;
> }
--
Regards,
Laurent Pinchart
EM flag and pass a non-restricted
buffer to the device ?
The V4L2_BUF_CAP_SUPPORTS_RESTRICTED_MEM flag also needs to be
documented in the relevant section, I don't think that's done in this
series.
>
> .. raw:: latex
>
--
Regards,
Laurent Pinchart
Hi Keith,
On Wed, May 22, 2024 at 05:58:00AM +, Keith Zhao wrote:
> Hi Alex, Laurent:
>
> I want to make as few changes as possible on the current basis, and add
> bridge_fun,
>
> On 2024年5月21日 23:42, Laurent Pinchart wrote:
> > On Tue, May 21, 2024 at 05:36:43
r creation. That must happen
> somewhere else.
You're absolutely right :-) Connector creation should be handled by the
drm_bridge_connector helper. The HDMI bridge driver should focus on the
HDMI bridge itself.
> Also I'm neither seeing any drm_brige struct nor drm_bridge_funcs, which
> are both essential for a bridge driver. I don't think moving a part of a
> driver to .../drm/bridge/ makes it a bridge driver.
>
> > + drm_connector_attach_encoder(&hdmi->connector, encoder);
> > +
> > + return 0;
> > +}
> > +
>
>
--
Regards,
Laurent Pinchart
c: Conor Dooley
> Cc: Daniel Vetter
> Cc: David Airlie
> Cc: Fabio Estevam
> Cc: Jernej Skrabec
> Cc: Jonas Karlman
> Cc: Krzysztof Kozlowski
> Cc: Laurent Pinchart
> Cc: Liu Ying
> Cc: Maarten Lankhorst
> Cc: Mark Yao
> Cc: Maxime Ripard
> Cc: Neil Arms
cs should we have in the agenda?
I'm interested in attending, even if so far I have limited involvement
in that area. Looking forward we're considering usage of ML accelerators
in libcamera for various purposes, so an open ecosystem will be crucial
for us.
--
Regards,
Laurent Pinchart
Hi Sui,
On Thu, May 16, 2024 at 12:13:03AM +0800, Sui Jingfeng wrote:
> On 5/14/24 23:12, Laurent Pinchart wrote:
> > On Tue, May 14, 2024 at 12:26:15AM +0800, Sui Jingfeng wrote:
> >> On 5/13/24 16:02, Liu Ying wrote:
> >>> The connector is created by either
Hi Nicolas,
On Wed, May 15, 2024 at 01:43:58PM -0400,
nicolas.dufre...@collabora.corp-partner.google.com wrote:
> Le mardi 14 mai 2024 à 23:42 +0300, Laurent Pinchart a écrit :
> > > You'll hit the same limitation as we hit in GStreamer, which is that KMS
> > &g
On Thu, May 16, 2024 at 07:00:31AM +, Simon Ser wrote:
> On Tuesday, May 14th, 2024 at 22:42, Laurent Pinchart wrote:
>
> > My experience on Arm platforms is that the KMS drivers offer allocation
> > for scanout buffers, not render buffers, and mostly using the dumb
> &g
could be platforms where the DW HDMI DDC pins are not exposed,
making the ddc-i2c-bus property mandatory, but that's something for
platform-specific bindings to handle by simply adding a
required:
- ddc-i2c-bus
That's a separate issue. This patch looks good to me.
Reviewed-by: Laure
gt; On Wed, May 08, 2024 at 10:36:08AM +0200, Daniel Vetter wrote:
> > > > > On Tue, May 07, 2024 at 04:07:39PM -0400, Nicolas Dufresne wrote:
> > > > > > Le mardi 07 mai 2024 à 21:36 +0300, Laurent Pinchart a écrit :
> > > > > > >
On Mon, May 13, 2024 at 11:10:00AM -0400, Nicolas Dufresne wrote:
> Le lundi 13 mai 2024 à 11:34 +0300, Laurent Pinchart a écrit :
> > On Mon, May 13, 2024 at 10:29:22AM +0200, Maxime Ripard wrote:
> > > On Wed, May 08, 2024 at 10:36:08AM +0200, Daniel Vetter wrote:
> > >
_ATTACH_NO_CONNECTOR
unconditionally here.
Reviewed-by: Laurent Pinchart
> >
> > Add that flag to drm_bridge_attach() function call in
> > adv7511_bridge_attach() to fix the issue.
> >
> > This fixes the issue where the HDMI connector bridge fails to atta
On Mon, May 13, 2024 at 10:29:22AM +0200, Maxime Ripard wrote:
> On Wed, May 08, 2024 at 10:36:08AM +0200, Daniel Vetter wrote:
> > On Tue, May 07, 2024 at 04:07:39PM -0400, Nicolas Dufresne wrote:
> > > Hi,
> > >
> > > Le mardi 07 mai 2024 à 2
) { ... }".
>
> Signed-off-by: Sui Jingfeng
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c | 5 -
> 1 file changed, 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
> b/drivers/
coder) { ... }".
>
> Signed-off-by: Sui Jingfeng
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c | 5 -
> 1 file changed, 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
coder) { ... }".
>
> Signed-off-by: Sui Jingfeng
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 5 -
> 1 file changed, 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> b/drivers/gpu/drm/
coder) { ... }".
>
> Signed-off-by: Sui Jingfeng
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 5 -
> 1 file changed, 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
> b/drivers/gpu/drm/bridge/lonti
) { ... }".
>
> Signed-off-by: Sui Jingfeng
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 5 -
> 1 file changed, 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> b/drivers/gpu/drm/bridge/adv7511
s guaranteed that the .encoder member
> of the drm_bridge instance is not NULL when various imx_xxx_bridge_attach()
> function gets called.
>
> Remove the redundant checking codes "if (!bridge->encoder) { ... }".
>
> Signed-off-by: Sui Jingfeng
Reviewed-by: Laurent
king codes "if (!bridge->encoder) { ... }".
>
> Signed-off-by: Sui Jingfeng
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/analogix/analogix-anx6345.c | 5 -
> drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c | 5 -
> drivers/gpu/drm/b
checking codes "if (!bridge->encoder) { ... }".
>
> Signed-off-by: Sui Jingfeng
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/ite-it6505.c | 5 -
> 1 file changed, 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/ite-it6505.c
> b/drivers/gpu/
e the redundant checking codes
> "if (!bridge->encoder) { ... }".
>
> Signed-off-by: Sui Jingfeng
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/panel.c | 5 -
> 1 file changed, 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/pa
;
> - if (!bridge->encoder) {
> - DRM_ERROR("Parent encoder object not found");
> - return -ENODEV;
> - }
> -
> ptn_bridge->connector.polled = DRM_CONNECTOR_POLL_HPD;
> ret = drm_connector_init(bridge->dev, &ptn_bridge->connector,
> &ptn3460_connector_funcs, DRM_MODE_CONNECTOR_LVDS);
--
Regards,
Laurent Pinchart
f bridge->encoder is NULL and the driver will
> quit even if drm_bridge_attach() fails for some reasons.
>
> Therefore there is no need to check another time at the later, remove the
> redundant checking codes "if (!bridge->encoder) { ... }".
>
> Signed-o
at the later.
>
> Signed-off-by: Sui Jingfeng
Reviewed-by: Laurent Pinchart
If you end up sending a second version of this patch, please include all
similar patches you have sent at the same time in a patch series,
instead of sending them separately.
> ---
> drivers/gpu/drm/bridge/si
#size-cells = <0>;
> +port@0 {
> +reg = <0>;
> +oldi1_in: endpoint {
> + remote-endpoint = <&dpi0_out1>;
> +};
> +};
> +};
> +};
> +};
> +
> +...
> diff --git a/MAINTAINERS b/MAINTAINERS
> index c675fc296b19..4426c4d41a7f 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -7480,6 +7480,7 @@ M: Tomi Valkeinen
> L: dri-devel@lists.freedesktop.org
> S: Maintained
> T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
> +F: Documentation/devicetree/bindings/display/ti/ti,am625-oldi.yaml
> F: Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
> F: Documentation/devicetree/bindings/display/ti/ti,j721e-dss.yaml
> F: Documentation/devicetree/bindings/display/ti/ti,k2g-dss.yaml
--
Regards,
Laurent Pinchart
Hi Aradhya,
Thank you for the patch.
On Sun, May 12, 2024 at 01:00:52AM +0530, Aradhya Bhatia wrote:
> Reduce tab size from 8 spaces to 4 spaces to make the bindings
> consistent, and easy to expand.
>
> Signed-off-by: Aradhya Bhatia
Reviewed-by: Laurent Pinchart
> ---
n_pos_rounded = in_pos_aligned / 8192U;
>
> Oh, these seems to be better to use either ALIGN*(), or PFN_*() / PAGE_*()
> families of macros. What the semantic of 8192 is?
The comment mentions 19.13 fixed point, so I assume that's the
fractional part of the integer. It doesn't seem related to pages.
--
Regards,
Laurent Pinchart
1 - 100 of 1880 matches
Mail list logo
