move parenthesis where not needed
> - use u32 instead of uint32_t for possible_crtcs
>
> Signed-off-by: Abhinav Kumar
> Acked-by: Liviu Dudau
> Reviewed-by: Dmitry Baryshkov
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c |
we'll definitely invest some time to upstream it.
Absolutely ! I'm all for helping debugging.
> Thank you for your attention and feedback.
>
> [1] https://github.com/renesas-rcar/linux-bsp/commit/12ea79975a10f
> ("v4l: vsp1: Add underrun debug messege option")
--
Regards,
Laurent Pinchart
connector->funcs->reset(connector);
> > > + drm_connector_register(connector);
> > > + }
> >
> > Reviewed-by: Jagan Teki
>
> Fixed typos in commit message.
>
> Reviewed-by: Robert Foss
>
> Applied to drm-misc-next
Doesn't this open the door to various race conditions ?
Also, what happens if the panel bridge is detached and reattached ? If I
recall correctly, registering new connectors at runtime is at least
partly supported for DP MST, but I'm not sure about unregistration.
--
Regards,
Laurent Pinchart
le DRM_BRIDGE_OP_HPD based on HPD interrupt availability, so that
> it will fall back to polling, if HPD is not available.
>
> Signed-off-by: Biju Das
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 6 --
> 1 file changed, 4 insertion
Alexander Stein
> Signed-off-by: Marek Vasut
> Cc: Alexander Stein
> Cc: Laurent Pinchart
> Cc: Lucas Stach
> Cc: Peng Fan
> Cc: Robby Cai
> Cc: Sam Ravnborg
> Cc: Stefan Agner
Reviewed-by: Laurent Pinchart
> ---
> V2: Add AB from Alexander
> ---
> driv
t;du_atomic_check_planes(dev, state);
> }
>
> static void rcar_du_atomic_commit_tail(struct drm_atomic_state *old_state)
> @@ -882,7 +882,7 @@ int rcar_du_modeset_init(struct rcar_du_device *rcdu)
> : 0;
>
> if (!rcar_du_has(rcdu, RCAR_DU_FEATURE_VSP1_SOURCE)) {
> - ret = rcar_du_planes_init(rgrp);
> + ret = rcdu->info->fns->du_planes_init(rgrp);
> if (ret < 0)
> return ret;
> }
> @@ -910,7 +910,7 @@ int rcar_du_modeset_init(struct rcar_du_device *rcdu)
>
> rgrp = &rcdu->groups[hwindex / 2];
>
> - ret = rcar_du_crtc_create(rgrp, swindex++, hwindex);
> + ret = rcdu->info->fns->du_crtc_create(rgrp, swindex++, hwindex);
> if (ret < 0)
> return ret;
> }
--
Regards,
Laurent Pinchart
-- /dev/null
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_common.c
> @@ -0,0 +1,30 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * rcar_du_common.c -- R-Car Display Unit Common
> + *
> + * Copyright (C) 2013-2022 Renesas Electronics Corporation
> + *
> + * Contact: Laurent Pin
/*
> - * The Gen3 DU uses the VSP1 for memory access, and is limited
> - * to frame sizes of 8190x8190.
> - */
> - dev->mode_config.max_width = 8190;
> - dev->mode_config.max_height = 8190;
> - }
> + /*
> + * The Gen3 DU uses the VSP1 for memory access, and is limited
> + * to frame sizes of 8190x8190.
> + */
This comment doesn't make much sense here anymore, but I think it's
useful to keep the information. How about defining macros for the
maximum width and height on different platforms, and moving the comment
just before the macro definitions ?
> + dev->mode_config.max_width = rcdu->info->max_width;
> + dev->mode_config.max_height = rcdu->info->max_height;
>
> rcdu->num_crtcs = hweight8(rcdu->info->channels_mask);
>
--
Regards,
Laurent Pinchart
},
> },
> + .num_rpf = 5,
> .dsi_clk_mask = BIT(1) | BIT(0),
> };
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> index 101f42df86ea..68c5de59d18d 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
>
port@3: false
> +
> + required:
> +- port@0
> +- port@1
> +
> + renesas,vsps:
> + maxItems: 1
> +
> + required:
> +- clock-names
> +- interrupts
> +- resets
> +- reset-names
> +- renesas,vsps
> +
> additionalProperties: false
>
> examples:
--
Regards,
Laurent Pinchart
gt; +#define RSTCR0x110
> +#define RSTCR_SWRST BIT(0)
> +#define RSTCR_FCETXSTP BIT(16)
> +
> +/* Reset Status Register */
> +#define RSTSR0x114
> +#define RSTSR_DL0DIR BIT(15)
> +#define RSTSR_DLSTPST(0xf << 8)
> +#define RSTSR_SWRSTV1BIT(4)
> +#define RSTSR_SWRSTIBBIT(3)
> +#define RSTSR_SWRSTAPB BIT(2)
> +#define RSTSR_SWRSTLPBIT(1)
> +#define RSTSR_SWRSTHSBIT(0)
> +
> +/* Clock Lane Stop Time Set Register */
> +#define CLSTPTSETR 0x314
> +#define CLSTPTSETR_CLKKPT(x) ((x) << 24)
> +#define CLSTPTSETR_CLKBFHT(x)((x) << 16)
> +#define CLSTPTSETR_CLKSTPT(x)((x) << 2)
> +
> +/* LP Transition Time Set Register */
> +#define LPTRNSTSETR 0x318
> +#define LPTRNSTSETR_GOLPBKT(x) ((x) << 0)
> +
> +/* Physical Lane Status Register */
> +#define PLSR 0x320
> +#define PLSR_CLHS2LP BIT(27)
> +#define PLSR_CLLP2HS BIT(26)
> +
> +/* Video-Input Channel 1 Set 0 Register */
> +#define VICH1SET0R 0x400
> +#define VICH1SET0R_VSEN BIT(12)
> +#define VICH1SET0R_HFPNOLP BIT(10)
> +#define VICH1SET0R_HBPNOLP BIT(9)
> +#define VICH1SET0R_HSANOLP BIT(8)
> +#define VICH1SET0R_VSTPAFT BIT(1)
> +#define VICH1SET0R_VSTARTBIT(0)
> +
> +/* Video-Input Channel 1 Set 1 Register */
> +#define VICH1SET1R 0x404
> +#define VICH1SET1R_DLY(x)(((x) & 0xfff) << 2)
> +
> +/* Video-Input Channel 1 Status Register */
> +#define VICH1SR 0x410
> +#define VICH1SR_VIRDYBIT(3)
> +#define VICH1SR_RUNNING BIT(2)
> +#define VICH1SR_STOP BIT(1)
> +#define VICH1SR_STARTBIT(0)
> +
> +/* Video-Input Channel 1 Pixel Packet Set Register */
> +#define VICH1PPSETR 0x420
> +#define VICH1PPSETR_DT_RGB18 (0x1e << 16)
> +#define VICH1PPSETR_DT_RGB18_LS (0x2e << 16)
> +#define VICH1PPSETR_DT_RGB24 (0x3e << 16)
> +#define VICH1PPSETR_TXESYNC_PULSEBIT(15)
> +#define VICH1PPSETR_VC(x)((x) << 22)
> +
> +/* Video-Input Channel 1 Vertical Size Set Register */
> +#define VICH1VSSETR 0x428
> +#define VICH1VSSETR_VACTIVE(x) (((x) & 0x7fff) << 16)
> +#define VICH1VSSETR_VSPOL_LOWBIT(15)
> +#define VICH1VSSETR_VSPOL_HIGH (0 << 15)
> +#define VICH1VSSETR_VSA(x) (((x) & 0xfff) << 0)
> +
> +/* Video-Input Channel 1 Vertical Porch Set Register */
> +#define VICH1VPSETR 0x42C
This is the only address written as an uppercase hex value.
> +#define VICH1VPSETR_VFP(x) (((x) & 0x1fff) << 16)
> +#define VICH1VPSETR_VBP(x) (((x) & 0x1fff) << 0)
> +
> +/* Video-Input Channel 1 Horizontal Size Set Register */
> +#define VICH1HSSETR 0x430
> +#define VICH1HSSETR_HACTIVE(x) (((x) & 0x7fff) << 16)
> +#define VICH1HSSETR_HSPOL_LOWBIT(15)
> +#define VICH1HSSETR_HSPOL_HIGH (0 << 15)
> +#define VICH1HSSETR_HSA(x) (((x) & 0xfff) << 0)
> +
> +/* Video-Input Channel 1 Horizontal Porch Set Register */
> +#define VICH1HPSETR 0x434
> +#define VICH1HPSETR_HFP(x) (((x) & 0x1fff) << 16)
> +#define VICH1HPSETR_HBP(x) (((x) & 0x1fff) << 0)
> +
> +#endif /* __RZG2L_MIPI_DSI_REGS_H__ */
--
Regards,
Laurent Pinchart
given that the
hardware doesn't seem to support lane reordering.
> +
> +required:
> + - data-lanes
> +
> +required:
> + - port@0
> + - port@1
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - inter
-mipi-dsim" /* for i.MX8M Mini/Nano SoCs */
Should we have two different compatible strings for i.MX8MM and i.MX8MN
?
>- reg: physical base address and length of the registers set for the device
>- interrupts: should contain DSI interrupt
>- clocks: list of clock specifiers, must contain an entry for each required
--
Regards,
Laurent Pinchart
op = 1,
> + .num_clks = 2,
> + .max_freq = 2100,
> + .wait_for_reset = 0,
> + .num_bits_resol = 12,
> + .pll_p_offset = 14,
> + .reg_values = imx8mm_dsim_reg_values,
> +};
I haven't verified the values, the rest looks good to me.
Reviewed-by: Laurent Pin
s
> adjusted.
>
> Suggested-by: Laurent Pinchart
> Signed-off-by: Kieran Bingham
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> b/driv
lues can be added with a lower risk of a conflict, but that just a
false impression.
> > > > > I'm not sure using the raw media bus format value is ideal though,
> > > > > since
> > > > > that value could then be used by any OS, and it would effectively
> > > > > force
> > > > > the mbus stuff down their throat.
> > >
> > > I disagree here, this forces us to use code to map the device tree enum
> > > to the kernel enum for Linux, i.e. adds complexity and maintenance work
> > > if additional bus_formats are needed.
> > > Assuming there is another OS which uses the device tree it would not
> > > make a difference, that OS would still need to map the device tree enum
> > > to the corresponding representation in their kernel.
> >
> > So, you don't want to do something in Linux, but would expect someone
> > else to be completely ok with that?
>
> Yes, sort of.
> Recycling the values as used currently in the Linux kernel rather than
> inventing a new numbering will make the Linux code a little easier to
> write, read and maintain without any negative effect on how that other
> OSs would have to map the DT representation to their internal representation.
>
> Would you rather have something like:
>
>
> DT_BUS_FMT_RGB666_1X181
> DT_BUS_FMT_RGB888_1X242
> ...
>
>
> switch (bus-format) {
> case DT_BUS_FMT_RGB666_1X18:
> bus_format = MEDIA_BUS_FMT_RGB666_1X18; break;
> case DT_BUS_FMT_RGB888_1X24:
> bus_format = MEDIA_BUS_FMT_RGB888_1X24; break;
> ...
I'm having a bit of trouble providing comments on this RFC, because I
don't believe I have a good enough overview of the different cases we
need to support (and in particular the corner cases). Max, you mentioned
an interesting one on Tegra platforms, would you maybe have a short (or
long, who knows) list of use cases you need to support now, or just know
about ? I think it would be easier to discuss the problem and the best
solution with concrete examples.
One particular thing that needs to be taken into account is that not all
devices (I'm talking about both the panel side and the source side) use
a data bus with contiguous bits. How to map a format to D[23:0] is one
thing, but there are devices that document pins as R[7:0], G[7:0],
B[7:0] (possibly with some permutations of the components). It's quite
easy to map between those two representations, once a mapping is
defined. I'd like these things to be considered explicitly instead of
relying on an implicit shared knowledge, as in my experience implicit
rules lead to one version per participant in the conversation :-)
> > > I would copy the definitions of media-bus-format.h into a header in
> > > include/dt-bindings similarly as it is done for
> > > include/dt-bindings/display/sdtv-standards.h for TV standards.
> >
> > That might not be an option: that header is licensed under the GPL,
> > device trees are usually licensed under GPL+MIT, and we don't have any
> > requirements on the license for other projects using a DT (hence the
> > dual license).
>
> That one I didn't consider. That would be solved by a newly invented
> enum.
--
Regards,
Laurent Pinchart
would be solved by a newly invented
> > enum.
>
> IANAL, but we are talking about the copyright of something that is not
> even a complete API, it is just a list of name/value. I do not believe
> that this is a real problem without solution.
I agree here, I don't think it's an issue.
--
Regards,
Laurent Pinchart
Hi Alexandre,
On Thu, Apr 07, 2022 at 02:41:58PM +0200, Alexandre TORGUE wrote:
> On 3/6/22 18:39, Laurent Pinchart wrote:
> > Now that a header exists with macros for the media interface bus-type
> > values, replace hardcoding numerical constants with the corresponding
>
Signed-off-by: Marek Vasut
> Cc: Christoph Niedermaier
> Cc: Daniel Vetter
> Cc: Dmitry Osipenko
> Cc: Laurent Pinchart
> Cc: Robert Foss
> Cc: Sam Ravnborg
> Cc: Thomas Zimmermann
> To: dri-devel@lists.freedesktop.org
Reviewed-by: Laurent Pinchart
> ---
> V2: -
t only if this driver is loaded (and not e.g. blacklisted
> as module).
>
> Signed-off-by: H. Nikolaus Schaller
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/display-connector.c | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git
Hi Abhinav,
On Tue, Apr 05, 2022 at 09:53:57AM -0700, Abhinav Kumar wrote:
> On 4/5/2022 9:47 AM, Laurent Pinchart wrote:
> > On Mon, Apr 04, 2022 at 11:43:37AM -0700, Rob Clark wrote:
> >> On Fri, Apr 1, 2022 at 8:38 AM Laurent Pinchart wrote:
> >>> On Thu, Ma
Hi Rob and Abhinav,
On Mon, Apr 04, 2022 at 11:43:37AM -0700, Rob Clark wrote:
> On Fri, Apr 1, 2022 at 8:38 AM Laurent Pinchart wrote:
> > On Thu, Mar 31, 2022 at 05:12:13PM -0700, Abhinav Kumar wrote:
> > > For some vendor driver implementations, display hardware can
> >
Hi Dave,
On Tue, Apr 05, 2022 at 01:00:28PM +0100, Dave Stevenson wrote:
> On Tue, 5 Apr 2022 at 12:42, Laurent Pinchart wrote:
> > On Sun, Feb 13, 2022 at 03:26:48AM +0100, Marek Vasut wrote:
> > > In rare cases, the bridge may not start up correctly, which usually
> &g
by ? It's a bit annoying to add a 10+ms
delay at start time just to be notified of rare cases.
> Signed-off-by: Marek Vasut
> Cc: Jagan Teki
> Cc: Laurent Pinchart
> Cc: Linus Walleij
> Cc: Robert Foss
> Cc: Sam Ravnborg
> Cc: dri-devel@lists.freedesktop.org
> ---
DBI
> compatible SPI panels")
> Signed-off-by: Marek Vasut
> Cc: Christoph Niedermaier
> Cc: Daniel Vetter
> Cc: Dmitry Osipenko
> Cc: Laurent Pinchart
> Cc: Noralf Trønnes
> Cc: Rob Herring
> Cc: Robert Foss
> Cc: Sam Ravnborg
> Cc: Thomas Zimme
On Fri, Apr 01, 2022 at 10:36:24PM +0200, Marek Vasut wrote:
> On 4/1/22 20:46, Laurent Pinchart wrote:
> > On Fri, Apr 01, 2022 at 06:37:54PM +0200, Marek Vasut wrote:
> >> Make the width-mm/height-mm panel properties mandatory in
> >> of_get_drm_panel_display_mode
istoph Niedermaier
> Cc: Daniel Vetter
> Cc: Dmitry Osipenko
> Cc: Laurent Pinchart
> Cc: Noralf Trønnes
> Cc: Rob Herring
> Cc: Robert Foss
> Cc: Sam Ravnborg
> Cc: Thomas Zimmermann
> Cc: devicet...@vger.kernel.org
> To: dri-devel@lists.freedesktop.org
Revi
t;>> consistent because we made a single schema. I'd assume 'non-simple'
> > >>> panels with their own schema are not consistent.
> > >>
> > >> Maybe we would start requiring that port even for simple panels ?
> > >> The port is physically there on that panel after all.
> > >
> > > Fix this in all the dts files and then I'll agree. Though I think this
> > > ship has already sailed. I'd like to someday get to platforms without
> > > warnings and not just keep adding new warnings.
> >
> > I doubt we can fix existing DTs, but can we at least require it for new
> > DTs ?
>
> We don't have any way to do that currently and get to warning free for
> all DTs. We'd need to be able to disable specific checks for specific
> DTs. I've thought about it, but haven't come up with a way to do it.
I think Marek may have meant new bindings. While I do agree that
inconsistencies in sources can cause new submissions to blindly copy
mistakes, it shouldn't be a reason in itself to carry historical binding
design mistakes in new bindings.
--
Regards,
Laurent Pinchart
is needed to correctly report panel dimensions.
Can we guarantee this won't cause a regression ?
> Signed-off-by: Marek Vasut
> Cc: Christoph Niedermaier
> Cc: Daniel Vetter
> Cc: Dmitry Osipenko
> Cc: Laurent Pinchart
> Cc: Noralf Trønnes
> Cc: Rob Herring
>
pdate is needed.
> > Signed-off-by: Marek Vasut
> > Cc: Christoph Niedermaier
> > Cc: Daniel Vetter
> > Cc: Dmitry Osipenko
> > Cc: Laurent Pinchart
> > Cc: Noralf Trønnes
> > Cc: Rob Herring
> > Cc: Robert Foss
> > Cc: Sam Ravnborg
>
On Fri, Apr 01, 2022 at 06:11:22PM +0200, Marek Vasut wrote:
> On 4/1/22 17:48, Laurent Pinchart wrote:
>
> Hi,
>
> [...]
>
> >> diff --git a/drivers/gpu/drm/panel/panel-lvds.c
> >> b/drivers/gpu/drm/panel/panel-lvds.c
> >> index 27a1c9923b09..6
result as panel bus_flags.
>
> This fixes handling of panels with 'panel-timing { de-active = <1>; };'.
>
> Signed-off-by: Marek Vasut
> Cc: Christoph Niedermaier
> Cc: Daniel Vetter
> Cc: Dmitry Osipenko
> Cc: Laurent Pinchart
> Cc: Robert Foss
stoph Niedermaier
> Cc: Daniel Vetter
> Cc: Dmitry Osipenko
> Cc: Laurent Pinchart
> Cc: Robert Foss
> Cc: Sam Ravnborg
> Cc: Thomas Zimmermann
> To: dri-devel@lists.freedesktop.org
> ---
> drivers/gpu/drm/panel/panel-lvds.c | 28 ++--
>
ed between
> + * writeback encoder and rest of the display pipeline.
> + * To accommodate such cases, encoder is a handle to the real encoder
> + * hardware.
> + *
> + * For current existing writeback users, this shall continue to be the
> + * embedded encoder for the writeback connector.
>*/
> - struct drm_encoder encoder;
> + struct drm_encoder *encoder;
>
> /**
> + * @internal_encoder: internal encoder used by writeback when
> + * drm_writeback_connector_init() is used.
> + * @encoder will be assigned to this for those cases
> + *
> + * This will be unused when drm_writeback_connector_init_with_encoder()
> + * is used.
> + */
> + struct drm_encoder internal_encoder;
> + /**
>* @pixel_formats_blob_ptr:
>*
>* DRM blob property data for the pixel formats list on writeback
> --
> 2.7.4
>
--
Regards,
Laurent Pinchart
ARRAY_SIZE(vkms_wb_formats));
> + ARRAY_SIZE(vkms_wb_formats),
> + 1);
> }
> diff --git a/include/drm/drm_writeback.h b/include/drm/drm_writeback.h
> index 9697d27..db6214f 100644
> --- a/include/drm/drm_writeback.h
> +++ b/include/drm/drm_writeback.h
> @@ -150,7 +150,7 @@ int drm_writeback_connector_init(struct drm_device *dev,
>struct drm_writeback_connector *wb_connector,
>const struct drm_connector_funcs *con_funcs,
>const struct drm_encoder_helper_funcs
> *enc_helper_funcs,
> - const u32 *formats, int n_formats);
> + const u32 *formats, int n_formats, uint32_t
> possible_crtcs);
Line wrap here too.
>
> int drm_writeback_set_fb(struct drm_connector_state *conn_state,
>struct drm_framebuffer *fb);
--
Regards,
Laurent Pinchart
the direction we should take in the long term. I'm not
opposed to a short-term consistency-focussed patch that makes the port
optional, as long as there's an agreement on the long term goal and this
patch won't be used as an argument against it in the future.
--
Regards,
Laurent Pinchart
Hi Maxime,
On Thu, Mar 24, 2022 at 03:23:24PM +0100, Maxime Ripard wrote:
> On Thu, Mar 24, 2022 at 03:43:42PM +0200, Laurent Pinchart wrote:
> > On Thu, Mar 24, 2022 at 09:18:19AM +0100, Maxime Ripard wrote:
> > > On Wed, Mar 23, 2022 at 10:38:19PM +0200, Laurent Pinchart
Hi Maxime,
On Thu, Mar 24, 2022 at 09:18:19AM +0100, Maxime Ripard wrote:
> On Wed, Mar 23, 2022 at 10:38:19PM +0200, Laurent Pinchart wrote:
> > Hi Maxime,
> >
> > (CC'ing Sakari)
> >
> > Thank you for the patch.
> >
> > On Wed, Mar
5216c27fc0ad..a412a1da950f 100644
> --- a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.yaml
> +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.yaml
> @@ -39,7 +39,6 @@ properties:
>Video port for MIPI DPI output (panel or connector).
>
> required:
> - - port@0
>- port@1
>
> required:
--
Regards,
Laurent Pinchart
DRM framework requirements. The users of the
>* @drm_writeback_connector control the behaviour of the @encoder
>* by passing the @enc_funcs parameter to drm_writeback_connector_init()
>* function.
> + *
> + * For some vendor drivers, the hardware resources are shared between
> + * writeback encoder and rest of the display pipeline.
> + * To accommodate such cases, encoder is a handle to the real encoder
> + * hardware.
> + *
> + * For current existing writeback users, this shall continue to be the
> + * embedded encoder for the writeback connector.
> + *
> + */
> + struct drm_encoder *encoder;
> +
> + /**
> + * @internal_encoder: internal encoder used by writeback when
> + * a real encoder is not provided by the vendor drm drivers.
> + * @encoder will be assigned to this for those cases.
>*/
> - struct drm_encoder encoder;
> + struct drm_encoder internal_encoder;
None of this belong here.
>
> /**
>* @pixel_formats_blob_ptr:
> @@ -150,7 +166,7 @@ int drm_writeback_connector_init(struct drm_device *dev,
>struct drm_writeback_connector *wb_connector,
>const struct drm_connector_funcs *con_funcs,
>const struct drm_encoder_helper_funcs
> *enc_helper_funcs,
> - const u32 *formats, int n_formats);
> + const u32 *formats, int n_formats, uint32_t
> possible_crtcs);
>
> int drm_writeback_set_fb(struct drm_connector_state *conn_state,
>struct drm_framebuffer *fb);
--
Regards,
Laurent Pinchart
Hi Abhinav
On Fri, Mar 11, 2022 at 09:47:17AM -0800, Abhinav Kumar wrote:
> On 3/10/2022 11:28 PM, Laurent Pinchart wrote:
> > On Thu, Mar 10, 2022 at 05:49:59PM -0800, Abhinav Kumar wrote:
> >> Make changes to rcar_du driver to start using drm_encoder pointer
> >>
*
> > +* For some vendor drivers, the hardware resources are shared
> > between
> > +* writeback encoder and rest of the display pipeline.
> > +* To accommodate such cases, encoder is a handle to the real
> > encoder
> > +* hardware.
> > +*
> > +* For current existing writeback users, this shall continue to be
> > the
> > +* embedded encoder for the writeback connector.
> > +*
> > */
> > - struct drm_encoder encoder;
> > + struct drm_encoder *encoder;
> >
> > /**
> > * @pixel_formats_blob_ptr:
--
Regards,
Laurent Pinchart
<< drm_crtc_index(&rcrtc->crtc);
> + wb_conn->encoder = kzalloc(sizeof(struct drm_encoder), GFP_KERNEL);
Where is this freed ?
> + wb_conn->encoder->possible_crtcs = 1 << drm_crtc_index(&rcrtc->crtc);
> drm_connector_helper_add(&wb_conn->base,
>&rcar_du_wb_conn_helper_funcs);
>
--
Regards,
Laurent Pinchart
ling mode only for now.
Don't we support IRQ mode too now ?
> The implementation is limited to the bridge operations, as the connector
> operations are legacy and new users should use
> DRM_BRIDGE_ATTACH_NO_CONNECTOR.
>
> Signed-off-by: Laurent Pinchart
> Signed-off-by:
description: Number of DSI data lanes connected to the DSI host.
> $ref: /schemas/types.yaml#/definitions/uint32
--
Regards,
Laurent Pinchart
Hi Kieran,
Thank you for the patch.
On Thu, Mar 10, 2022 at 03:22:26PM +, Kieran Bingham wrote:
> From: Laurent Pinchart
>
> Implement the bridge connector-related .get_edid() operation, and report
> the related bridge capabilities and type.
>
> Signed-off-by: Laurent
Hi Kieran,
Thank you for the patch.
On Thu, Mar 10, 2022 at 03:22:25PM +, Kieran Bingham wrote:
> From: Laurent Pinchart
>
> Despite the SN65DSI86 being an eDP bridge, on some systems its output is
> routed to a DisplayPort connector. Enable DisplayPort mode when the next
&g
Hi Maxime,
On Thu, Mar 10, 2022 at 11:57:38AM +0100, Maxime Ripard wrote:
> On Thu, Mar 10, 2022 at 12:42:12PM +0200, Laurent Pinchart wrote:
> > On Tue, Mar 08, 2022 at 01:51:40PM +0100, Maxime Ripard wrote:
> > > On Tue, Mar 08, 2022 at 11:29:59AM +0100, Marek Vasut wrote:
&g
fundamentally the DT excerpt Jagan provided is
> correct. If the bridge supports DCS, there's no reason to use the OF
> graph in the first place: the bridge node will be a child node of the
> MIPI-DSI controller (and there's no obligation to use the OF-graph for a
> MIPI-DSI controller).
>
> I believe port@0 should be made optional (or downright removed if
> MIPI-DCS in the only control bus).
I think we should make ports mandatory in all cases actually.
The DT parent-child hierarchy is meant to model control relations
between devices, so a DSI device controlled through DCS should be a
child of the DSI controller. No disagreement there.
The OF graph is meant to model data connections. While a DSI device
controlled through DCS will use the same DSI link for data transfer, the
two concepts are different. We have taken shortcuts and decided to not
use OF graph for some DSI devices (not necessarily as a well thought
decision, it was sometimes just not considered). This has led to
different issues that we're having to deal with today, making it more
difficult to develop generic code. Going forward, I think new bindings
should always use OF graph to model the data connection.
--
Regards,
Laurent Pinchart
ernej Skrabec
> S: Maintained
> T: git git://anongit.freedesktop.org/drm/drm-misc
> +F: Documentation/devicetree/bindings/display/bridge/
> F: drivers/gpu/drm/bridge/
>
> DRM DRIVERS FOR EXYNOS
--
Regards,
Laurent Pinchart
process.
We may end up using those values, but I think it should be discussed and
not rushed in v5.17 if possible.
> > > -default: 1
> > > -
> > > - data-lanes: true
> > > + Video port for MIPI DSI input.
> > >
> >
dts: mt8183: jacuzzi: Fix bus properties in anx's DSI
> endpoint"
If this is enough to avoid the wrong bus-type becoming an ABI, even if
the corresponding driver support isn't reverted, then, for the whole
series,
Reviewed-by: Laurent Pinchart
> .../display/bridge/anal
Hello Xin,
On Mon, Mar 07, 2022 at 01:09:45PM +0800, Xin Ji wrote:
> On Mon, Mar 07, 2022 at 06:47:44AM +0200, Laurent Pinchart wrote:
> > On Mon, Mar 07, 2022 at 12:32:49PM +0800, Xin Ji wrote:
> > > On Mon, Mar 07, 2022 at 05:30:09AM +0200, Laurent Pinchart wrote:
> >
Hello Xin,
On Mon, Mar 07, 2022 at 12:32:49PM +0800, Xin Ji wrote:
> On Mon, Mar 07, 2022 at 05:30:09AM +0200, Laurent Pinchart wrote:
> > On Mon, Mar 07, 2022 at 11:22:48AM +0800, Xin Ji wrote:
> > > On Sun, Mar 06, 2022 at 07:13:30PM +0200, Laurent Pinchart wrote:
Hello Xin,
On Mon, Mar 07, 2022 at 11:22:48AM +0800, Xin Ji wrote:
> On Sun, Mar 06, 2022 at 07:13:30PM +0200, Laurent Pinchart wrote:
> > Hello Xin,
> >
> > (Question for Rob below, and I'm afraid this is urgent as we need to
> > merge a fix in v5.17).
> &
On Sun, Mar 06, 2022 at 07:39:03PM +0200, Laurent Pinchart wrote:
> Add a new dt-bindings/media/video-interfaces.h header that defines
> macros corresponding to the bus types from media/video-interfaces.yaml.
> This allows avoiding hardcoded constants in device tree sources.
>
>
Now that a header exists with macros for the media interface bus-type
values, replace hardcoding numerical constants with the corresponding
macros in the DT sources.
Signed-off-by: Laurent Pinchart
---
arch/arm/boot/dts/imx6ul-14x14-evk.dtsi | 4 +++-
arch/arm/boot/dts/omap3-n900
Add a new dt-bindings/media/video-interfaces.h header that defines
macros corresponding to the bus types from media/video-interfaces.yaml.
This allows avoiding hardcoded constants in device tree sources.
Signed-off-by: Laurent Pinchart
---
Changes since v1:
- Dual-license under GPL-2.0-only or
Now that a header exists with macros for the media interface bus-type
values, replace hardcoding numerical constants with the corresponding
macros in the DT binding examples.
Signed-off-by: Laurent Pinchart
---
Changes since v1:
- Rename PARALLEL to BT601
---
.../devicetree/bindings/display
. Let's discuss this in [1],
I'll update this series and rebase it on v5.18-rc1 once released based
on the outcome of the discussion.
[1] https://lore.kernel.org/all/yitruicikyxs3...@pendragon.ideasonboard.com/
Laurent Pinchart (3):
dt-bindings: media: Add macros for video interface bus
goto unregister_bridge;
> + if (!platform->pdata.is_dpi) {
> + ret = anx7625_attach_dsi(platform);
> + if (ret) {
> + DRM_DEV_ERROR(dev, "Fail to attach to dsi : %d\n", ret);
> + goto unregister_bridge;
> + }
> }
>
> DRM_DEV_DEBUG_DRIVER(dev, "probe done\n");
> diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.h
> b/drivers/gpu/drm/bridge/analogix/anx7625.h
> index 6dcf64c703f9..3ef1d8f4e575 100644
> --- a/drivers/gpu/drm/bridge/analogix/anx7625.h
> +++ b/drivers/gpu/drm/bridge/analogix/anx7625.h
> @@ -141,12 +141,20 @@
> #define HORIZONTAL_BACK_PORCH_H 0x22 /* Bit[7:4] are reserved */
>
> / END of I2C Address 0x72 */
> +
> +/***/
> +/* Register definition of device address 0x7a */
> +#define DP_TX_SWING_REG_CNT 0x14
> +#define DP_TX_LANE0_SWING_REG0 0x00
> +#define DP_TX_LANE1_SWING_REG0 0x14
> +/ END of I2C Address 0x7a */
> +
> /***/
> /* Register definition of device address 0x7e */
>
> #define I2C_ADDR_7E_FLASH_CONTROLLER 0x7E
>
> -#define FLASH_LOAD_STA 0x05
> +#define FLASH_LOAD_STA 0x05
> #define FLASH_LOAD_STA_CHK BIT(7)
>
> #define XTAL_FRQ_SEL0x3F
> @@ -349,12 +357,20 @@ struct s_edid_data {
>
> /* Display End */
>
> +#define MAX_LANES_SUPPORT4
> +
> struct anx7625_platform_data {
> struct gpio_desc *gpio_p_on;
> struct gpio_desc *gpio_reset;
> struct regulator_bulk_data supplies[3];
> struct drm_bridge *panel_bridge;
> int intp_irq;
> + int is_dpi;
> + int mipi_lanes;
> + int dp_lane0_swing_reg_cnt;
> + int lane0_reg_data[DP_TX_SWING_REG_CNT];
> + int dp_lane1_swing_reg_cnt;
> + int lane1_reg_data[DP_TX_SWING_REG_CNT];
> u32 low_power_mode;
> struct device_node *mipi_host_node;
> };
--
Regards,
Laurent Pinchart
n't have any background about why they are different other than what
> looks to be intentionally making the two things incompatible.
I think it was done for DRM purpose, to prevent signals meant for a
panel to be connected to a device that could capture video from a DP
source.
> ...so
On Thu, Mar 03, 2022 at 11:14:24AM +0200, Laurent Pinchart wrote:
> On Wed, Mar 02, 2022 at 06:00:08PM +0100, Geert Uytterhoeven wrote:
> > On Wed, Dec 29, 2021 at 5:47 PM Laurent Pinchart wrote:
> > > On Fri, Dec 24, 2021 at 08:23:09AM +0300, Nikita Yushchenko wrote:
> > &
A77961) SoC
- R-Car DU misc fixes and cleanups
--------
Laurent Pinchart (3):
drm: rcar-du: Drop LVDS device tree backward compatibility
drm: rcar-du: Don't select VSP1 sink on Gen3
drm: rcar-du: Don't restart gro
On Wed, Mar 02, 2022 at 06:00:08PM +0100, Geert Uytterhoeven wrote:
> On Wed, Dec 29, 2021 at 5:47 PM Laurent Pinchart wrote:
> > On Fri, Dec 24, 2021 at 08:23:09AM +0300, Nikita Yushchenko wrote:
> > > Document the R-Car M3-W+ (R8A77961) SoC in the R-Car LVDS enco
Hi Abhinav,
On Wed, Mar 02, 2022 at 10:28:03AM -0800, Abhinav Kumar wrote:
> On 2/28/2022 5:42 AM, Laurent Pinchart wrote:
> > On Mon, Feb 28, 2022 at 02:28:27PM +0200, Laurent Pinchart wrote:
> >> On Mon, Feb 28, 2022 at 02:09:15PM +0200, Jani Nikula wrote:
> >>>
braham I
> Cc: Vinod Koul
> Cc: Sebastian Reichel
> Cc: Bjorn Andersson
> Cc: Mathieu Poirier
> Cc: Mark Brown
> Cc: Greg Kroah-Hartman
> Cc: Laurent Pinchart
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-in..
Hello,
On Mon, Feb 28, 2022 at 02:28:27PM +0200, Laurent Pinchart wrote:
> On Mon, Feb 28, 2022 at 02:09:15PM +0200, Jani Nikula wrote:
> > On Mon, 28 Feb 2022, Laurent Pinchart wrote:
> > > On Sat, Feb 26, 2022 at 10:27:59AM -0800, Rob Clark wrote:
> > >> On We
Hi Jani,
On Mon, Feb 28, 2022 at 02:09:15PM +0200, Jani Nikula wrote:
> On Mon, 28 Feb 2022, Laurent Pinchart wrote:
> > On Sat, Feb 26, 2022 at 10:27:59AM -0800, Rob Clark wrote:
> >> On Wed, Feb 2, 2022 at 7:41 AM Jani Nikula wrote:
> >> > On Wed, 02 Feb 2022, Laure
Hi Dmitry,
On Mon, Feb 28, 2022 at 11:07:41AM +0300, Dmitry Baryshkov wrote:
> On Mon, 28 Feb 2022 at 11:00, Laurent Pinchart wrote:
> > On Sat, Feb 26, 2022 at 05:10:06AM +, Kandpal, Suraj wrote:
> > > Hi Abhinav,
> > >
> > > > Based on the discus
Hi Rob,
On Sat, Feb 26, 2022 at 10:27:59AM -0800, Rob Clark wrote:
> On Wed, Feb 2, 2022 at 7:41 AM Jani Nikula wrote:
> > On Wed, 02 Feb 2022, Laurent Pinchart wrote:
> > > On Wed, Feb 02, 2022 at 03:15:03PM +0200, Jani Nikula wrote:
> > >> On Wed, 02 Fe
DRM_CLIENT_CAP_WRITEBACK_CONNECTORS
capability to get the writeback connectors exposed by the kernel, but
more than that, a large refactoring is then often needed to chase all
code paths that assume a connector is a connector.
I'm afraid the same applies to the kernel. Drivers that don&#
er layout compared to all previous LCDIF
> variants. The new LCDIFv3 also supports 36bit address space. However,
> except for the complete bit reshuffling, this is still LCDIF and it still
> works like one.
>
> Signed-off-by: Marek Vasut
> Cc: Alexander Stein
> Cc: Laurent Pinchart
Hello,
On Wed, Feb 23, 2022 at 04:17:22PM +, Kieran Bingham wrote:
> Quoting Laurent Pinchart (2021-12-29 23:44:29)
> > On Sat, Dec 25, 2021 at 09:31:51AM +0300, Nikita Yushchenko wrote:
> > > Hotplug events reported by bridge drivers over drm_bridge_hpd_notify()
> &
Hi Doug,
On Wed, Feb 23, 2022 at 07:43:27AM -0800, Doug Anderson wrote:
> On Tue, Feb 22, 2022 at 9:08 PM Laurent Pinchart wrote:
> > On Tue, Feb 22, 2022 at 11:44:54PM +0100, Linus Walleij wrote:
> > > On Tue, Feb 22, 2022 at 11:19 PM Douglas Anderson wrote:
> > > &g
his be solved in the runtime
PM framework instead ? pm_runtime_disable() could disable auto-suspend.
If there are legitimate use cases for disabling runtime PM temporarily
without disabling auto-suspend, then a new function designed
specifically for remove() that would take care of cleaning everything up
could be another option.
> Reviewed-by: Linus Walleij
--
Regards,
Laurent Pinchart
Hi Kieran,
On Tue, Feb 22, 2022 at 12:58:25PM +, Kieran Bingham wrote:
> Quoting Laurent Pinchart (2021-11-29 22:28:13)
> > When the CMM is enabled, an offset of 25 pixels must be subtracted from
> > the HDS (horizontal display start) and HDE (horizontal display end)
> &g
Hi Dmitry,
On Tue, Feb 22, 2022 at 06:32:50AM +0300, Dmitry Baryshkov wrote:
> On Thu, 10 Feb 2022 at 07:59, Laurent Pinchart wrote:
> > On Wed, Feb 09, 2022 at 05:40:29PM -0800, Abhinav Kumar wrote:
> > > Hi Laurent
> > >
> > > Gentle reminder on this.
> &
/2021-December/333908.html
> > [4]
> > https://lists.freedesktop.org/archives/dri-devel/2021-October/328476.html
> > [5]
> > https://lists.freedesktop.org/archives/dri-devel/2021-October/325853.html
> > [6]
> > https://lists.freedesktop.org/archives/dri-devel/2022-February/341852.html
> > [7] https://github.com/6by9/linux/tree/drm-misc-next-vc4_dsi
> > [8] https://github.com/6by9/linux/tree/rpi-5.15.y-sn65dsi83
> >
> >
> > Dave Stevenson (2):
> >drm: Introduce DRM_BRIDGE_OP_UPSTREAM_FIRST to alter bridge init order
> >drm/bridge: Document the expected behaviour of DSI host controllers
> >
> > Documentation/gpu/drm-kms-helpers.rst | 7 +
> > drivers/gpu/drm/drm_bridge.c | 235
> > ++
> > include/drm/drm_bridge.h | 8 ++
> > 3 files changed, 225 insertions(+), 25 deletions(-)
--
Regards,
Laurent Pinchart
iter);
> - if (WARN_ON(!old_bridge_state))
> - return;
> + drm_atomic_bridge_call_pre_enable(iter, old_state);
>
> - iter->funcs->atomic_pre_enable(iter, old_bridge_state);
> - } else if (iter->funcs->pre_enable) {
> - iter->funcs->pre_enable(iter);
> - }
> + if (iter->ops & DRM_BRIDGE_OP_UPSTREAM_FIRST)
> + iter = limit;
>
> if (iter == bridge)
> break;
> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> index f27b4060faa2..523ec9d8f3f8 100644
> --- a/include/drm/drm_bridge.h
> +++ b/include/drm/drm_bridge.h
> @@ -725,6 +725,14 @@ enum drm_bridge_ops {
>* this flag shall implement the &drm_bridge_funcs->get_modes callback.
>*/
> DRM_BRIDGE_OP_MODES = BIT(3),
> + /**
> + * @DRM_BRIDGE_OP_UPSTREAM_FIRST: The bridge can requires
s/can //
> + * that the upstream node pre_enable is called before its pre_enable,
s/node/bridge/ ?
> + * and conversely for post_disables. This is most frequently a
s/post_disables/post_disable/
Bonus points if you use the correct markup to link to those operations.
> + * requirement for DSI devices which need the host to be initialised
> + * before them.
> + */
> + DRM_BRIDGE_OP_UPSTREAM_FIRST = BIT(4),
> };
>
> /**
--
Regards,
Laurent Pinchart
o pre_enable or after
> + * post_disable, the exact state of the lanes is undefined at this point. The
> + * DSI host should initialise the interface, transmit the data, and then
> disable
> + * the interface again.
> + *
> + * Ultra Low Power State (ULPS) is not explicitly support
;< pll->pll_e)
> + output = (fin * pll->pll_n / pll->pll_m >> pll->pll_e)
> / div7 / pll->div;
> error = (long)(output - target) * 1 / (long)target;
>
--
Regards,
Laurent Pinchart
On Gen3 hardware enabling a VSP plane doesn't change any register that
requires DRES to take effect. Avoid a group restart in that case.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_plane.c | 6 ++
drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 9 -
2 files ch
The VSP1 sink selection through register DEFR8 is only available on Gen2
hardware. Skip it on Gen3.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_plane.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
b
insertions(+), 11 deletions(-)
--
Regards,
Laurent Pinchart
by requesting
>* a restart of the group. See rcar_du_plane_atomic_update() for a more
>* detailed explanation.
> - *
> - * TODO: Check whether this is still needed on Gen3.
>*/
> crtc->group->need_restart = true;
>
--
Regards,
Laurent Pinchart
truct rcar_lvds *lvds)
> > {
> > int ret;
> >
> > - ret = drm_of_find_panel_or_bridge(lvds->dev->of_node, 1, 0,
> > - &lvds->panel, &lvds->next_bridge);
>
> I guess lvds->panel can be removed from the rcar_lvds struct as well?
It's used in rcar_lvds_get_lvds_mode() though, so this patch introduces
a regression.
--
Regards,
Laurent Pinchart
Hi Stephen,
(CC'ing Jean-Michel)
On Fri, Feb 18, 2022 at 06:24:08PM -0800, Stephen Boyd wrote:
> Quoting Laurent Pinchart (2022-02-14 01:45:56)
> > Hi Maxime and Stephen,
> >
> > We have recently posted a driver for the BCM2711 Unicam CSI-2 receiver
> > (see [
Signed-off-by: Marek Vasut
> Cc: Christoph Fritz
> Cc: Laurent Pinchart
> Cc: Maxime Ripard
> Cc: Sam Ravnborg
> Cc: Thomas Zimmermann
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/panel/panel-simple.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
py(&mode, E, S)
> + drm_mode_copy(&mode, E)
> )
>
> @@
> struct drm_display_mode *mode;
> @@
> - &*mode
> + mode
>
> Cc: Andrzej Hajda
> Cc: Neil Armstrong
> Cc: Robert Foss
> Cc: Laurent Pinchart
> Cc: Jonas Karlman
> Cc: Jernej
on
>
> drivers/clk/.kunitconfig | 1 +
> drivers/clk/Kconfig | 7 +
> drivers/clk/Makefile | 1 +
> drivers/clk/bcm/clk-raspberrypi.c | 125 +-
> drivers/clk/clk-test.c| 621 ++
> drivers/clk/clk.c | 51 ++-
>
, Dmitry Baryshkov wrote:
> >> On Wed, 2 Feb 2022 at 16:26, Laurent Pinchart
> >> wrote:
> >>>
> >>> Hi Jani,
> >>>
> >>> On Wed, Feb 02, 2022 at 03:15:03PM +0200, Jani Nikula wrote:
> >>>> On Wed, 02 Feb 2022, Laurent P
t; > > > NOC/NIC QoS would help mitigate this shift issue described below
> > > > (*).
> > >
> > > I also think the QoS would help if it is configureable.
> >
> > It is programmable, it's just the port mapping which is undocumented.
> >
> > > > Do you know if there is some additional NOC/NIC documentation for i.MX8M
> > > > Mini available ?
> > >
> > > No.
> >
> > Can you ask someone internally in NXP maybe ?
>
> Maybe, you may try community.nxp.com, like the i.MXRT case.
Overall we seem to have had little luck with community.nxp.com. I wonder
if it would be possible for key community members to get some more
direct access to support when working on upstream drivers. I'm pretty
sure nobody will try to abuse it :-)
--
Regards,
Laurent Pinchart
underneath the connector's debugfs directory. At the moment
> all bridges in the chain have their debugfs_init() called with the
> connector's root directory.
>
> Signed-off-by: Douglas Anderson
Reviewed-by: Laurent Pinchart
> ---
>
> Changes in v2:
> - (&quo
't try to
> undo the drm_bridge_attach() in error cases. There's also a comment
> indicating the lack of balance at the top of drm_bridge_attach().
>
> [1] https://lore.kernel.org/r/20210920225801.227211-4-robdcl...@gmail.com
>
> Signed-off-by: Douglas
: Rob Clark
> > Signed-off-by: Sam Ravnborg
> > Cc: Rob Clark
> > Cc: Douglas Anderson
> > Cc: Andrzej Hajda
> > Cc: Neil Armstrong
> > Cc: Robert Foss
> > Cc: Laurent Pinchart
> > Cc: Jonas Karlman
> > Cc: Jernej Skrabec
> > ---
&
t; Adjust a few comments to avoid references to the dropped functions.
>
> Signed-off-by: Sam Ravnborg
> Reviewed-by: Maxime Ripard
Reviewed-by: Laurent Pinchart
> Cc: Laurent Pinchart
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Thomas Zimmermann
> Cc: Andrzej Hajda
Cc: Andrzej Hajda
> Cc: Neil Armstrong
> Cc: Robert Foss
> Cc: Laurent Pinchart
> Cc: Jonas Karlman
> Cc: Jernej Skrabec
> ---
> drivers/gpu/drm/bridge/ti-sn65dsi86.c | 21 +
> 1 file changed, 13 insertions(+), 8 deletions(-)
>
> diff --
do kmemdup() on the array passed and fill
> in "num_output_formats" to be either the array size of 0 (if the
> kmemdup failed).
I quite like that approach. We could even have a wrapper macro that adds
the ARRAY_SIZE() argument automatically.
> > + if (!input_fmts)
> > + return NULL;
> > +
> > + /* This is the DSI-end bus format */
> > + input_fmts[0] = MEDIA_BUS_FMT_RGB888_1X24;
>
> I'm not an expert, but I'm curious. Can't DSI run in other formats?
> ...or maybe I'm misunderstanding what this is for. I guess I'm not
> sure how it relates to:
>
> enum mipi_dsi_pixel_format {
> MIPI_DSI_FMT_RGB888,
> MIPI_DSI_FMT_RGB666,
> MIPI_DSI_FMT_RGB666_PACKED,
> MIPI_DSI_FMT_RGB565,
> };
--
Regards,
Laurent Pinchart
RGB888_1X7X4_JEIDA:
> + case MEDIA_BUS_FMT_RGB888_1X7X4_SPWG:
> + return 8;
> +
> + default:
> + WARN(1, "Unknown MEDIA_BUS format %d\n", bus_format);
> + return -EINVAL;
> + }
> +}
This seems a bit big for an inline
901 - 1000 of 6346 matches
Mail list logo
