f working here is to fix the warnings/errors
> before adding the change to the header file. (For example when adding a
> must-check attribute).
>
> My take - but then I seldom checks the device tree files as keeping the
> bindings free of errors was the challenge in the past. Rob does a
> fantastic jobs to keep the kernel error free here and I assume focus may
> change to device trees soon.
--
Regards,
Laurent Pinchart
Hi Geert,
On Tue, Sep 21, 2021 at 05:53:52PM +0200, Geert Uytterhoeven wrote:
> On Wed, Jul 28, 2021 at 6:26 PM Laurent Pinchart wrote:
> > The R-Car MIPI DSI/CSI-2 TX is embedded in the Renesas R-Car V3U SoC. It
> > can operate in either DSI or CSI-2 mode, with up to
Hi Andrzej,
On Tue, Sep 21, 2021 at 09:42:11PM +0200, Andrzej Hajda wrote:
> W dniu 23.06.2021 o 15:56, Laurent Pinchart pisze:
> > From: LUU HOAI
> >
> > The driver supports the MIPI DSI/CSI-2 TX encoder found in the R-Car V3U
> > SoC. It currently supports DSI mode
Hi Geert,
On Wed, Sep 22, 2021 at 08:43:57AM +0200, Geert Uytterhoeven wrote:
> On Wed, Sep 22, 2021 at 3:27 AM Laurent Pinchart wrote:
> > On Tue, Sep 21, 2021 at 05:53:52PM +0200, Geert Uytterhoeven wrote:
> > > On Wed, Jul 28, 2021 at 6:26 PM Laurent Pinchart wrote:
> >
; Correct the definitions.
>
> Signed-off-by: Kieran Bingham
Reviewed-by: Laurent Pinchart
> ---
> v2:
> - New patch
>
> drivers/gpu/drm/rcar-du/rcar_du_group.c | 4 ++--
> drivers/gpu/drm/rcar-du/rcar_du_regs.h | 8
> 2 files changed, 6 insertions(+), 6 de
features independently.
>
> The other features are incremented accordingly, to keep the two crtc
> features adjacent.
>
> Signed-off-by: Kieran Bingham
Reviewed-by: Laurent Pinchart
> ---
> v2:
> - New patch
>
> drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 4 +--
> d
oup.c
> b/drivers/gpu/drm/rcar-du/rcar_du_group.c
> index a984eef265d2..27c912bab76e 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_group.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_group.c
> @@ -124,6 +124,8 @@ static void rcar_du_group_setup_didsr(struct
> rcar_du_group *rgrp)
> if (rcdu->info->lvds_clk_mask & BIT(rcrtc->index))
> didsr |= DIDSR_LDCS_LVDS0(i)
> | DIDSR_PDCS_CLK(i, 0);
> + else if (rcdu->info->dsi_clk_mask & BIT(rcrtc->index))
> + didsr |= DIDSR_LDCS_LVDS0(i);
> else
> didsr |= DIDSR_LDCS_DCLKIN(i)
> | DIDSR_PDCS_CLK(i, 0);
--
Regards,
Laurent Pinchart
> > From: Kieran Bingham
> > > >
> > > > Extend the Renesas DU display bindings to support the r8a779a0 V3U.
> > > >
> > > > Reviewed-by: Laurent Pinchart
> > > > Signed-off-by: Kieran Bingham
> > > > ---
> > &g
Hi Kieran,
On Wed, Sep 22, 2021 at 10:37:29PM +0100, Kieran Bingham wrote:
> On 30/07/2021 03:05, Laurent Pinchart wrote:
> > On R-Car Gen3, the DU uses a separate IP core named VSP to perform DMA
> > from memory and composition of planes. The DU hardware then only handles
> &
ted dma-buf
regardless of the number of scatterlist entries. The sgtable will be
mapped to the VSP at .prepare_fb() time, which will reject the
framebuffer if the VSP isn't connected to an IOMMU.
Signed-off-by: Laurent Pinchart
Reviewed-by: Kieran Bingham
---
Changes since v
Hi Andrzej,
On Wed, Sep 22, 2021 at 04:29:39AM +0300, Laurent Pinchart wrote:
> On Tue, Sep 21, 2021 at 09:42:11PM +0200, Andrzej Hajda wrote:
> > W dniu 23.06.2021 o 15:56, Laurent Pinchart pisze:
> > > From: LUU HOAI
> > >
> > > The driver supports the MIPI
Hi Cai,
Thank you for the patch.
On Tue, Aug 31, 2021 at 09:57:30PM +0800, Cai Huoqing wrote:
> Use the devm_platform_ioremap_resource() helper instead of
> calling platform_get_resource() and devm_ioremap_resource()
> separately
>
> Signed-off-by: Cai Huoqing
Reviewed-by: L
Hi Cai,
Thank you for the patch.
On Tue, Aug 31, 2021 at 03:54:42PM +0800, Cai Huoqing wrote:
> Use the devm_platform_ioremap_resource() helper instead of
> calling platform_get_resource() and devm_ioremap_resource()
> separately
>
> Signed-off-by: Cai Huoqing
Reviewed-by: L
So
> use devm_add_action_or_reset() instead of devm_add_action()
> to simplify the error handling, reduce the code.
>
> Signed-off-by: Cai Huoqing
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c | 6 ++
> 1 file changed, 2 insertion
ar-du/rcar_du_regs.h
> @@ -258,6 +258,7 @@
> #define DIDSR0x20028
> #define DIDSR_CODE (0x7790 << 16)
> #define DIDSR_LDCS_DCLKIN(n) (0 << (8 + (n) * 2))
> +#define DIDSR_LDCS_DSI(n)(2 << (8 + (n) * 2))
I'd add a /* V3U only */ comment at the end.
I can address those two small issues when applying.
> #define DIDSR_LDCS_LVDS0(n) (2 << (8 + (n) * 2))
> #define DIDSR_LDCS_LVDS1(n) (3 << (8 + (n) * 2))
> #define DIDSR_LDCS_MASK(n) (3 << (8 + (n) * 2))
--
Regards,
Laurent Pinchart
dge.h
> +++ b/include/drm/drm_bridge.h
> @@ -911,6 +911,8 @@ struct drm_bridge *devm_drm_panel_bridge_add(struct
> device *dev,
> struct drm_bridge *devm_drm_panel_bridge_add_typed(struct device *dev,
> struct drm_panel *panel,
> u32 connector_type);
> +struct drm_bridge *devm_drm_of_get_bridge(struct device *dev, struct
> device_node *node,
> + unsigned int port, unsigned int
> endpoint);
> struct drm_connector *drm_panel_bridge_connector(struct drm_bridge *bridge);
> #endif
>
--
Regards,
Laurent Pinchart
nector->mode_valid().
>
> v2: Drop unneeded connector->mode_valid()
>
> Signed-off-by: Rob Clark
> Reviewed-by: Douglas Anderson
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/ti-sn65dsi86.c | 25 +
> 1 file changed, 13
Hi Rob and Doug,
On Mon, Sep 20, 2021 at 11:32:02AM -0700, Rob Clark wrote:
> On Thu, Aug 12, 2021 at 1:08 PM Doug Anderson wrote:
> > On Thu, Aug 12, 2021 at 12:26 PM Laurent Pinchart wrote:
> > > On Wed, Aug 11, 2021 at 04:52:50PM -0700, Rob Clark wrote:
>
t drm_connector *connector;
> + unsigned bpc = 0;
> +
> + drm_connector_list_iter_begin(bridge->dev, &conn_iter);
> + drm_for_each_connector_iter(connector, &conn_iter) {
> + if (drm_connector_has_possible_encoder(connector,
> bridge->encoder)) {
> + bpc = connector->display_info.bpc;
> + break;
> + }
> + }
> + drm_connector_list_iter_end(&conn_iter);
> +
> + WARN_ON(bpc == 0);
> +
> + if (bpc <= 6)
> return 18;
> else
> return 24;
--
Regards,
Laurent Pinchart
(hdmi);
}
If DRM_BRIDGE_ATTACH_NO_CONNECTOR is not set, it will create a
connector, otherwise it will just attach to the next bridge. I'm using
it on a Renesas platform with the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag
set, without any issue as far as I can tell.
> > It does it for a reason: the dw-hdmi is a multi-function driver which does
> > HDMI and DDC/EDID stuff in a single driver (because I/O registers and power
> > management seem to be shared).
>
> The IT66121 driver does all of that too, and does not need
> DRM_BRIDGE_ATTACH_NO_CONNECTOR. The drm_bridge_funcs struct has
> callbacks to handle cable detection and DDC stuff.
>
> > Since I do not see who could split this into a separate bridge and a
> > connector driver
> > and test it on multiple SoC platforms (there are at least 3 or 4), I think
> > modifying
> > the fundamentals of the dw-hdmi architecture just to get CI20 HDMI working
> > is not
> > our turf.
>
> You could have a field in the dw-hdmi pdata structure, that would
> instruct the driver whether or not it should use the new API. Ugly, I
> know, and would probably duplicate a lot of code, but that would allow
> other drivers to be updated at a later date.
>
> > Therefore the code here should be able to detect if drm_bridge_attach()
> > already
> > creates and attaches a connector and then skip the code below.
>
> Not that easy, unfortunately. On one side we have dw-hdmi which checks
> that DRM_BRIDGE_ATTACH_NO_CONNECTOR is not set, and on the other side
> we have other drivers like the IT66121 which will fail if this flag is
> not set.
> >> + if (ret) {
> >> + dev_err(dev, "Unable to attach bridge\n");
> >>return ret;
> >> + }
> >> +
> >> + connector = drm_bridge_connector_init(drm, encoder);
> >> + if (IS_ERR(connector)) {
> >> + dev_err(dev, "Unable to init connector\n");
> >> + return PTR_ERR(connector);
> >> + }
> >> +
> >> + drm_connector_attach_encoder(connector, encoder);
> >>}
> >>
> >>drm_for_each_encoder(encoder, drm) {
> >> --
> >> 2.33.0
> >
> > I haven't replaced v2 with v3 in our test tree yet, but will do asap.
--
Regards,
Laurent Pinchart
ere
> must be a test if a connector has been created (I do not know how this
> would work).
>
> Another suggestion: can you check if there is a downstream connector defined
> in
> device tree (dw-hdmi does not need such a definition)?
> If not we call it with 0 and if there is one we call it with
> DRM_BRIDGE_ATTACH_NO_CONNECTOR and create one?
I haven't followed the ful conversation, what the reason why
DRM_BRIDGE_ATTACH_NO_CONNECTOR can't always be use here ? We're moving
towards requiring DRM_BRIDGE_ATTACH_NO_CONNECTOR for all new code, so it
will have to be done eventually.
> Just some ideas how to solve without touching hdmi drivers.
>
> BR and thanks,
> Nikolaus
--
Regards,
Laurent Pinchart
Hi Nikolaus,
On Thu, Sep 23, 2021 at 11:55:56AM +0200, H. Nikolaus Schaller wrote:
> > Am 23.09.2021 um 11:27 schrieb Laurent Pinchart:
> > On Thu, Sep 23, 2021 at 11:19:23AM +0200, H. Nikolaus Schaller wrote:
> >>
> >>>>> + ret = drm_b
Hi Rob,
On Thu, Sep 23, 2021 at 10:31:52AM -0700, Rob Clark wrote:
> On Wed, Sep 22, 2021 at 5:44 PM Laurent Pinchart wrote:
> > On Mon, Sep 20, 2021 at 03:58:00PM -0700, Rob Clark wrote:
> > > From: Rob Clark
> > >
> > > Slightly awkward to fish out the
On Mon, Sep 27, 2021 at 09:43:44PM +0200, Maxime Ripard wrote:
> On Thu, Sep 23, 2021 at 03:29:37AM +0300, Laurent Pinchart wrote:
> > Hi Maxime,
> >
> > Thank you for the patch.
> >
> > I know this has already been merged, but I have a question.
> >
>
On Mon, Sep 27, 2021 at 03:57:34PM -0500, Rob Herring wrote:
> On Thu, 23 Sep 2021 14:01:38 +0100, Kieran Bingham wrote:
> > From: Kieran Bingham
> >
> > Extend the Renesas DU display bindings to support the r8a779a0 V3U.
> >
> > Reviewed-by: Laurent
94 -
> drivers/gpu/drm/drm_bridge.c | 69 -
> drivers/gpu/drm/drm_mipi_dsi.c | 81 +++
> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 19 ++--
> drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 27 +++--
> include/drm/drm_mipi_dsi.h | 4 +
> 17 files changed, 460 insertions(+), 317 deletions(-)
--
Regards,
Laurent Pinchart
Hi Maxime,
On Thu, Sep 30, 2021 at 12:56:02AM +0300, Laurent Pinchart wrote:
> On Fri, Sep 10, 2021 at 12:11:54PM +0200, Maxime Ripard wrote:
> > Hi,
> >
> > We've encountered an issue with the RaspberryPi DSI panel that prevented the
> > whole display driver fro
16:05:36 +0300)
- R-Car DU fix for LVDS outputs on D3 and E3 SoCs
--------
Laurent Pinchart (1):
drm: rcar-du: Don't create encoder for unconnected LVDS outputs
drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 16
dri
Hi Geert,
On Tue, Sep 28, 2021 at 10:55:57AM +0200, Geert Uytterhoeven wrote:
> On Mon, Aug 23, 2021 at 4:54 PM Laurent Pinchart wrote:
> > On Mon, Aug 23, 2021 at 02:25:32PM +0200, Geert Uytterhoeven wrote:
> > > On Sun, Aug 22, 2021 at 2:36 AM Laurent Pinchart wrote:
> >
imings, then you just can't display it, even though
> they are not adjacent (unless the bridge in the middle can modify the
> timings between the input and output, but that's not always possible).
>
> Similarly, if for the RGB panel we need to increase a bit some timings
> to accommodate for a larger pixel clock and end up above what the DSI
> host can provide, we're also done.
The hard part will be to figure out a good heuristics to perform the
negotiation without going back and forth (at least not in a way that
would require too many iterations, and certainly avoiding infinite
loops). That will be an interesting problem to solve, but maybe we'll be
lucky and a simple approach will work for the use cases we have to
support today.
> > Taking SN65DSI8[3|4|5] as an example, it supports burst mode, and the
> > DSI frequency and timings are permitted to be different from that
> > which it uses on the LVDS side. The LVDS panel and LVDS side of DSI83
> > need to agree over the format, and the DSI host and DSI side of DSI83
> > need to agree, but they may be two different timings.
> > Register 0x0B (DSI_CLK_DIVIDER & REFCLK_MULTIPLIER) allows you to
> > configure the LVDS rate compared to the DSI rate (the driver currently
> > goes for 1:1), and registers 0x20 to 0x34 allow you to set the number
> > of active pixel and blanking on the LVDS side (again currently just
> > copied across).
> >
> > The way I'm seeing burst mode as having been interpreted at present is
> > that it's largely just a flag to say "drop to LP mode between lines".
> > The timing that needs to be passed to the crtc is therefore going to
> > be based on the DSI link rate (converted to pixels) with increased
> > blanking periods.
> >
> > I guess there are similarities with Media Controller and V4L2 here. A
> > typical chain there could be:
> > sensor -> scaler -> crop -> CSI-2 receiver.
> > The format on each of those links may be different, but the chain as a
> > whole needs to be valid. Media Controller largely relies on userspace
> > to configure all links, but with a DRM chain that isn't really an
> > option as it's expected that the display chain configures itself.
>
> Also, the userspace has no concept of media sub-devices in DRM, so it
> just sets the mode on the whole DRM/KMS device, unlike what v4l2 does.
> In v4l2, afaik, if you ended up with the above scenarios it would just
> be rejected when you set the format on the link, letting the userspace
> figure it out. We can't really do that here
I wonder how long we'll be able to keep userspace out of the picture to
configure the internals of the pipeline. I don't want to be the first
person who will have a use case that requires this.
--
Regards,
Laurent Pinchart
; Signed-off-by: Marek Vasut
> Cc: Laurent Pinchart
> Cc: Rob Herring
> Cc: Sam Ravnborg
> Cc: devicet...@vger.kernel.org
> To: dri-devel@lists.freedesktop.org
Reviewed-by: Laurent Pinchart
And all my apologies for the delay.
> ---
> V2: - Use allOf
> - Move the
On Tue, Oct 05, 2021 at 03:03:40AM +0300, Laurent Pinchart wrote:
> Hi Marek,
>
> Thank you for the patch.
>
> On Tue, Jul 27, 2021 at 06:13:56PM +0200, Marek Vasut wrote:
> > Decoder input LVDS format is a property of the decoder chip or even
> > its strapping. Add D
apping is not present, do nothing, since there are still
> legacy bindings which do not specify this property.
>
> Signed-off-by: Marek Vasut
> Cc: Laurent Pinchart
> Cc: Sam Ravnborg
> To: dri-devel@lists.freedesktop.org
> ---
> V2: - Move the data-mapping to endpoint
Hi Doug,
On Fri, Oct 01, 2021 at 11:02:54AM -0700, Doug Anderson wrote:
> On Thu, Sep 23, 2021 at 7:26 PM Laurent Pinchart wrote:
> >
> > > > > err_conn_init:
> > > > > drm_dp_aux_unregister(&pdata->aux);
> > > > >
From: Laurent Pinchart
The SN65DSI8x EN signal may be tied to VCC, or otherwise controlled by
means not available to the kernel. Make the GPIO optional.
Signed-off-by: Laurent Pinchart
---
.../devicetree/bindings/display/bridge/ti,sn65dsi83.yaml | 1 -
1 file changed, 1 deletion
devm_gpiod_get(ctx->dev, "enable", GPIOD_OUT_LOW);
> + ctx->enable_gpio = devm_gpiod_get_optional(ctx->dev, "enable",
> GPIOD_OUT_LOW);
You can wrap this line as
ctx->enable_gpio = devm_gpiod_get_optional(ctx->dev, "enable",
On Wed, Oct 06, 2021 at 12:18:02PM +0300, Laurent Pinchart wrote:
> Hi Alexander,
>
> Thank you for the patch.
One more thing, the subject line has a typo, it should read
ti-sn65dsi83.
> On Wed, Oct 06, 2021 at 09:47:13AM +0200, Alexander Stein wrote:
> > The enable
te_device *adev;
> struct component *c;
> size_t i;
> int ret = 0;
>
> WARN_ON(!mutex_is_locked(&component_mutex));
>
> - master = __master_find(parent, NULL);
> - if (!master)
> + adev = __aggregate_find(parent, NULL);
> + if (!adev)
> return -EINVAL;
>
> /* Bind components in match order */
> - for (i = 0; i < master->match->num; i++)
> - if (!master->match->compare[i].duplicate) {
> - c = master->match->compare[i].component;
> - ret = component_bind(c, master, data);
> + for (i = 0; i < adev->match->num; i++)
> + if (!adev->match->compare[i].duplicate) {
> + c = adev->match->compare[i].component;
> + ret = component_bind(c, adev, data);
> if (ret)
> break;
> }
>
> if (ret != 0) {
> for (; i > 0; i--)
> - if (!master->match->compare[i - 1].duplicate) {
> - c = master->match->compare[i - 1].component;
> - component_unbind(c, master, data);
> + if (!adev->match->compare[i - 1].duplicate) {
> + c = adev->match->compare[i - 1].component;
> + component_unbind(c, adev, data);
> }
> }
>
> @@ -675,8 +691,8 @@ static int __component_add(struct device *dev, const
> struct component_ops *ops,
>
> ret = try_to_bring_up_masters(component);
> if (ret < 0) {
> - if (component->master)
> - remove_component(component->master, component);
> + if (component->adev)
> + remove_component(component->adev, component);
> list_del(&component->node);
>
> kfree(component);
> @@ -757,9 +773,9 @@ void component_del(struct device *dev, const struct
> component_ops *ops)
> break;
> }
>
> - if (component && component->master) {
> - take_down_master(component->master);
> - remove_component(component->master, component);
> + if (component && component->adev) {
> + take_down_aggregate_device(component->adev);
> + remove_component(component->adev, component);
> }
>
> mutex_unlock(&component_mutex);
> diff --git a/include/linux/component.h b/include/linux/component.h
> index 16de18f473d7..71bfc3862633 100644
> --- a/include/linux/component.h
> +++ b/include/linux/component.h
> @@ -41,7 +41,7 @@ void component_del(struct device *, const struct
> component_ops *);
> int component_bind_all(struct device *master, void *master_data);
> void component_unbind_all(struct device *master, void *master_data);
>
> -struct master;
> +struct aggregate_device;
>
> /**
> * struct component_master_ops - callback for the aggregate driver
--
Regards,
Laurent Pinchart
SYNC mode when supported
drm: rcar-du: Fix DIDSR field name
drm: rcar-du: Split CRTC IRQ and Clock features
drm: rcar-du: Add r8a779a0 device support
Laurent Pinchart (9):
drm: rcar-du: Don't create encoder for unconnected LVDS outputs
drm: rcar-du: Improve kerne
; +++ b/include/drm/drm_writeback.h
> @@ -31,7 +31,7 @@ struct drm_writeback_connector {
>* by passing the @enc_funcs parameter to drm_writeback_connector_init()
>* function.
>*/
> - struct drm_encoder encoder;
> + struct drm_encoder *encoder;
>
> /**
>* @pixel_formats_blob_ptr:
--
Regards,
Laurent Pinchart
T(16)
> +
> +#define DU_MSR0 0x04
> +#define DU_MSR0_ST_DI_BSYBIT(8)
> +#define DU_MSR0_ST_PB_WFULL BIT(16)
> +#define DU_MSR0_ST_PB_WINIT BIT(18)
> +#define DU_MSR0_ST_PB_REMPTY BIT(20)
> +#define DU_MSR0_ST_PB_RUFBIT(21)
> +#define DU_MSR0_ST_PB_RINIT BIT(22)
> +
> +#define DU_MSR1 0x08
> +
> +#define DU_IMR0 0x0C
> +#define DU_MSR0_IM_PB_RUFBIT(0)
> +
> +#define DU_DITR0 0x10
> +#define DU_DITR0_DPI_CLKMD BIT(0)
> +#define DU_DITR0_DEMD_LOW0x0
> +#define DU_DITR0_DEMD_HIGH (BIT(8) | BIT(9))
> +#define DU_DITR0_VSPOL BIT(16)
> +#define DU_DITR0_HSPOL BIT(17)
> +
> +#define DU_DITR1 0x14
> +#define DU_DITR1_VSA(x) ((x) << 0)
> +#define DU_DITR1_VACTIVE(x) ((x) << 16)
> +
> +#define DU_DITR2 0x18
> +#define DU_DITR2_VBP(x) ((x) << 0)
> +#define DU_DITR2_VFP(x) ((x) << 16)
> +
> +#define DU_DITR3 0x1C
> +#define DU_DITR3_HSA(x) ((x) << 0)
> +#define DU_DITR3_HACTIVE(x) ((x) << 16)
> +
> +#define DU_DITR4 0x20
> +#define DU_DITR4_HBP(x) ((x) << 0)
> +#define DU_DITR4_HFP(x) ((x) << 16)
> +
> +#define DU_DITR5 0x24
> +#define DU_DITR5_VSFT(x) ((x) << 0)
> +#define DU_DITR5_HSFT(x) ((x) << 16)
> +
> +#define DU_PBCR0 0x4C
> +#define DU_PBCR0_PB_DEP(x) ((x) << 0)
> +
> /*
> -
> * Display Control Registers
> */
--
Regards,
Laurent Pinchart
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_RGB16 (0x0E << 16)
> +#define VICH1PPSETR_DT_RGB18 (0x1E << 16)
> +#define VICH1PPSETR_DT_RGB18_LS (0x2E << 16)
> +#define VICH1PPSETR_DT_RGB24 (0x3E << 16)
> +#define VICH1PPSETR_DT_YCbCr16 (0x2C << 16)
> +#define VICH1PPSETR_DT_YCbCr20_LS(0x0C << 16)
> +#define VICH1PPSETR_DT_YCbCr24 (0x1C << 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
> +#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
c_name;
> > unsigned int i;
> > int ret;
>
> What about changing the code to use kasprintf() instead, to prevent
> this from ever happening again?
Or maybe it's time to drop this backward compatibility code altogether ?
--
Regards,
Laurent Pinchart
R_DU_OUTPUT_MAX];
> unsigned int num_lvds;
> + unsigned int num_rpf;
> unsigned int dpll_mask;
> unsigned int dsi_clk_mask;
> unsigned int lvds_clk_mask;
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> index b7fc5b069cbc..cf045a203aa5 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> @@ -415,11 +415,7 @@ int rcar_du_vsp_init(struct rcar_du_vsp *vsp, struct
> device_node *np,
> if (ret < 0)
> return ret;
>
> - /*
> - * The VSP2D (Gen3) has 5 RPFs, but the VSP1D (Gen2) is limited to
> - * 4 RPFs.
> - */
> - num_planes = rcdu->info->gen >= 3 ? 5 : 4;
> + num_planes = rcdu->info->num_rpf;
>
> vsp->planes = kcalloc(num_planes, sizeof(*vsp->planes), GFP_KERNEL);
> if (!vsp->planes)
--
Regards,
Laurent Pinchart
; @@ -32,12 +32,20 @@
>
> u32 rcar_du_group_read(struct rcar_du_group *rgrp, u32 reg)
> {
> + struct rcar_du_device *rcdu = rgrp->dev;
> +
> + if (!rcar_du_has(rcdu, RCAR_DU_FEATURE_GROUP))
> + return 0;
That's too much of a hack, sorry. Let's write a separate driver for the
RZ/G2L DU.
> +
> return rcar_du_read(rgrp->dev, rgrp->mmio_offset + reg);
> }
>
> void rcar_du_group_write(struct rcar_du_group *rgrp, u32 reg, u32 data)
> {
> - rcar_du_write(rgrp->dev, rgrp->mmio_offset + reg, data);
> + struct rcar_du_device *rcdu = rgrp->dev;
> +
> + if (rcar_du_has(rcdu, RCAR_DU_FEATURE_GROUP))
> + rcar_du_write(rgrp->dev, rgrp->mmio_offset + reg, data);
> }
>
> static void rcar_du_group_setup_pins(struct rcar_du_group *rgrp)
--
Regards,
Laurent Pinchart
dge at
a time, the same way that we propagate formats with the bridge
.atomic_get_input_bus_fmts() and .atomic_get_output_bus_fmts()
operations. There's thus quite a bit of work required to handle all
this.
> > Any pointers would be greatly appreciated!
>
> + Laurent, Kieran
>
> Charles,
>
> I added Laurent and Kieran because they appear as the maintainers for
> the rcar-du driver.
--
Regards,
Laurent Pinchart
goto runtime_put;
> }
You need a return here, otherwise you will unconditionally call
pm_runtime_put_sync() even on success.
> +
> +runtime_put:
> + pm_runtime_put_sync(dev);
> + return;
You can drop the return here.
> }
>
> static void
--
Regards,
Laurent Pinchart
lue is "8 UI".
Otherwise, this patch looks fine to me. With or without dropping that
documentation change,
Reviewed-by: Laurent Pinchart
> So, let's fix both the dphy core driver and the kernel doc of the 'clk_pre'
> member to correctly reflect the T-CLK-PRE parameter's
e/drm/drm_plane.h b/include/drm/drm_plane.h
> index 0c1102dc4d88..cad641b1f797 100644
> --- a/include/drm/drm_plane.h
> +++ b/include/drm/drm_plane.h
> @@ -803,6 +803,9 @@ void *__drmm_universal_plane_alloc(struct drm_device *dev,
> *
> * The @drm_plane_funcs.destr
rm_WARN_ON(dev, config->fb_modifiers_not_supported &&
format_modifier_count);
Reviewed-by: Laurent Pinchart
> plane->modifier_count = format_modifier_count;
> plane->modifiers = kmalloc_array(format_modifier_count,
>
>ddev->mode_config.fb_modifiers_not_supported = true;
> +
> rdev->ddev->mode_config.fb_base = rdev->mc.aper_base;
>
> ret = radeon_modeset_create_props(rdev);
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index 91ca575a78de
/**
>* @gamma_store: Gamma ramp values used by the legacy SETGAMMA and
>* GETGAMMA IOCTls. Set up by calling drm_mode_crtc_set_gamma_size().
> + *
> + * Note that atomic drivers need to instead use
> + * &drm_crtc_state.gamma_lut. See drm_crtc_enable_color_mgmt().
>*/
> uint16_t *gamma_store;
>
--
Regards,
Laurent Pinchart
Hi Daniel,
On Mon, Jan 24, 2022 at 09:28:09PM +0100, Daniel Vetter wrote:
> On Mon, Jan 24, 2022 at 9:24 PM Laurent Pinchart wrote:
> > On Mon, Jan 24, 2022 at 08:47:06PM +0100, Daniel Vetter wrote:
> > > Also add notes that for atomic drivers it's really somewhere else
Hi Geert,
On Mon, Jan 24, 2022 at 09:18:52AM +0100, Geert Uytterhoeven wrote:
> On Sun, Jan 23, 2022 at 2:52 PM Laurent Pinchart wrote:
> > On Fri, Jan 14, 2022 at 11:17:19AM +0100, Geert Uytterhoeven wrote:
> > > On Wed, Jan 12, 2022 at 6:46 PM Biju Das wrote:
> > &g
upport for legacy bindings for clocks. The LBDS compatibility code is
thus not needed anymore. Drop it.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/Makefile | 6 -
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 15 +-
drivers/gpu/drm/rcar-du/rcar_du_of.c | 3
API with
> pm_runtime_resume_and_get(), which will not change the runtime
> PM counter on error. Besides, a matching decrement is needed
> on the error handling path to keep the counter balanced.
>
> Signed-off-by: Yongzhi Liu
Reviewed-by: Laurent Pinchart
> ---
> drivers
tloader. Whatever we draw there shows up on the screen.
I doubt that's going to work as you expect, clocks and regulators will
get disabled at boot if not used by any driver.
> > Reading your mail that brought this thread up in my inbox, I think
> > you've already hit merge on this, so don't worry about adding a tag in
> > that instance, but I think this is ok.
> >
> > Reviewed-by: Kieran Bingham
> >
> >> rcar_du_of_init(rcar_du_of_table);
> >>
> >> return platform_driver_register(&rcar_du_platform_driver);
--
Regards,
Laurent Pinchart
Hi Thomas,
On Fri, Jan 28, 2022 at 11:46:49AM +0100, Thomas Zimmermann wrote:
> Am 28.01.22 um 11:34 schrieb Laurent Pinchart:
> > On Fri, Jan 28, 2022 at 10:33:21AM +0100, Thomas Zimmermann wrote:
> >> Am 28.01.22 um 10:13 schrieb Kieran Bingham:
> >>> Quoting Jav
Hi Thomas,
On Fri, Jan 28, 2022 at 12:26:03PM +0100, Thomas Zimmermann wrote:
> Am 28.01.22 um 12:04 schrieb Laurent Pinchart:
> > On Fri, Jan 28, 2022 at 11:46:49AM +0100, Thomas Zimmermann wrote:
> >> Am 28.01.22 um 11:34 schrieb Laurent Pinchart:
> >>> On Fri, Ja
s, each with
> their own driver.
>
> This takes a pile of devices, and turns it into a single logical
> device with a single driver.
>
> So aux is 1:N, component is N:1.
>
> And yes you asked this already, I typed this up already :-)
That's clear, but I'm still not sure why we need a bus for this :-) I'm
not very enthousiastic about that. Some of our problems come from the
fact we need to coordinate many devices, adding new ones hardly seem to
be a solution to that. Granted, the components framework doesn't work
nicely, and is in dire need of love (and documentation), or possibly
better a complete replacement. I'll try to review the series this week
and see if alternatives would be possible.
--
Regards,
Laurent Pinchart
gt;ddev, wb_conn,
> @@ -220,7 +222,7 @@ void rcar_du_writeback_setup(struct rcar_du_crtc *rcrtc,
> struct drm_framebuffer *fb;
> unsigned int i;
>
> - state = rcrtc->writeback.base.state;
> + state = rcrtc->writeback.base->state;
> if (!state || !state->writeback_job)
> return;
>
--
Regards,
Laurent Pinchart
Hi Maxime,
On Wed, Feb 02, 2022 at 10:48:45AM +0100, Maxime Ripard wrote:
> On Thu, Jan 27, 2022 at 03:22:15PM +0100, Maxime Ripard wrote:
> > On Tue, Jan 11, 2022 at 03:05:10PM +0200, Laurent Pinchart wrote:
> > > On Tue, Jan 11, 2022 at 12:06:35PM +0100, Maxime Ripard wrote:
On Wed, Feb 02, 2022 at 02:16:23PM +0100, Maxime Ripard wrote:
> On Wed, Feb 02, 2022 at 02:47:14PM +0200, Laurent Pinchart wrote:
> > On Wed, Feb 02, 2022 at 10:48:45AM +0100, Maxime Ripard wrote:
> > > On Thu, Jan 27, 2022 at 03:22:15PM +0100, Maxime Ripard wrote:
> > >
).
These formats are not used by any kernel driver at this point, but need
to be exposed to applications by libcamera, which uses DRM FourCCs for
pixel formats.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/drm_fourcc.c | 2 ++
include/uapi/drm/drm_fourcc.h | 6 ++
2 files changed, 8
>
> + vcc-supply:
> +description: A 1.8V power supply (see regulator/regulator.yaml).
I would have dropped the part between parentheses as it's kind of
implied, but I don't mind much.
Reviewed-by: Laurent Pinchart
> +
>ports:
> $ref: /schemas/graph.yam
Hi Alexander,
Thank you for the patch.
On Tue, Oct 19, 2021 at 08:52:39AM +0200, Alexander Stein wrote:
> VCC needs to be enabled before releasing the enable GPIO.
>
> Reviewed-by: Sam Ravnborg
> Signed-off-by: Alexander Stein
Reviewed-by: Laurent Pinchart
> ---
> driv
already taken.
I don't think we'll need a format with padding at that end (with data
aligned to tbe MSB) as that would essentially be DRM_FORMAT_R16.
--
Regards,
Laurent Pinchart
be loaded with device tree based platform.
> >
> > Fixes: e19233955d9e ("drm/bridge: Add Cadence DSI driver")
> > Signed-off-by: Nishanth Menon
Reviewed-by: Laurent Pinchart
> > ---
> > drivers/gpu/drm/bridge/cdns-dsi.c | 1 +
> > 1 file changed
; ^^^ this is just a defer
> > > > > > [ 1.171789] imx8m_blk_ctrl_power_off dispblk-lcdif
> > > > > > [1.176655] imx_pgc_power_down dispmix
> > > > > > [1.181790] libphy: fec_enet_mii_bus: probed
> > > > > > [3.915806] panel-simple panel: Expected bpc in {6,8} but got: 0
> > > > > > ^^^ not sure what this is but had it back in my 5.10 solution as
> > > > > > well
> > > > > > so did not investigate
> > > > > > [3.921912] imx8m_blk_ctrl_power_on dispblk-mipi-dsi
> > > > > > [3.926936] imx_pgc_power_up dispmix
> > > > > > [3.931109] imx_pgc_power_up mipi
> > > > > > [3.935409] imx8m_blk_ctrl_power_on dispblk-lcdif
> > > > > > [3.940547] imx8m_blk_ctrl_power_off dispblk-lcdif
> > > > > > [3.945626] [drm] Initialized mxsfb-drm 1.0.0 20160824 for
> > > > > > 32e0.lcdif on minor 0
> > > > > > ^^^ not clear why dispblk-lcdif got disabled here
> > > > >
> > > > > I've reproduced this. look like lcdif power-domains are not notified
> > > > > ON. checking on the power-sequence for lcdif side. old patches from
> > > > > Lucas on v5.13 seems working as expected.
> > > >
> > > > I've found the issue on lcdif atomic_enable, where the bus format is
> > > > retrieved from NULL bus_state. Here is the diff for it.
> > > >
> > > > --- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
> > > > +++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
> > > > @@ -359,13 +359,14 @@ static void mxsfb_crtc_atomic_enable(struct
> > > > drm_crtc *crtc,
> > > > drm_crtc_vblank_on(crtc);
> > > >
> > > > /* If there is a bridge attached to the LCDIF, use its bus
> > > > format */
> > > > - if (mxsfb->bridge) {
> > > > + if (mxsfb->bridge && state) {
> > > > bridge_state =
> > > > drm_atomic_get_new_bridge_state(state,
> > > > mxsfb->bridge);
> > > > - bus_format = bridge_state->input_bus_cfg.format;
> > > > + if (bridge_state)
> > > > + bus_format = bridge_state->input_bus_cfg.format;
> > > >'
> > > > I believe this can be fixed via DSIM bridge. working on for those
> > > > changes, the key challenges is to make the DSIM to work even for
> > > > exynos, which indeed blocker for me to validate in hardware (i don't
> > > > have DSI based exynos).
> > > >
> > > > Meanwhile, I have posed RFC for DSIM DTS changes, please check it here.
> > > > https://patchwork.kernel.org/project/dri-devel/cover/2021101456.584061-1-ja...@amarulasolutions.com/
> > > >
> > >
> > > Jagan,
> > >
> > > Thank you! This does resolve the hang on my end as well. I will look
> > > at your 'arm64: imx8mm: Add MIPI DSI support' series.
> > >
> > > There was some discussion regarding giving up on trying to split up
> > > the exynos driver such that it could work with IMX8MM vs just
> > > duplicating it. I thought the recommendation was to duplicate it as it
> > > wasn't clear if there was a way to split it out without breaking
> > > current exynos DSI but I'll have to see if I can find the thread.
> >
> > The thread is here:
> >
> > https://lore.kernel.org/all/cakmk7uf0b1trtvx+9whasz49quha_is+77z2wx3c06bswri...@mail.gmail.com/
> >
> > Duplicating seems to be the best way forward, because the Exynos driver
> > exposes some special behavior (discussed earlier in the same thread), which
> > isn't compatible with how bridges work.
This seems to tbe the crux of the issue. I don't see what would be
specific to Exynos there, those issues should be fixed globally. If the
DRM bridge API can't support some use cases, it should be improved.
> Not quite sure about it. Laurent and Inki had similar discussion and
> looking for common bridge [1].
>
> [1]
> https://patchwork.kernel.org/project/linux-arm-kernel/patch/20210704090230.26489-7-ja...@amarulasolutions.com/
--
Regards,
Laurent Pinchart
sage since 2015.
>
> Stop interpreting the field finally so it can be removed from
> the interface.
>
> Signed-off-by: Arnd Bergmann
Reviewed-by: Laurent Pinchart
> ---
> drivers/dma/sh/shdma-base.c | 8
> 1 file changed, 8 deletions(-)
>
> diff --git a/drive
fig->peripheral_config;
This could be moved to the variable declaration above, up to you.
> + if (chan->id <= ZYNQMP_DPDMA_VIDEO2 &&
> + config->peripheral_size == sizeof(*pconfig))
Silently ignoring a size mismatch isn't nice. Could we validate the
explain why the slave_id field shouldn't be used would be
nice.
> Signed-off-by: Arnd Bergmann
Reviewed-by: Laurent Pinchart
> ---
> include/linux/dmaengine.h | 4
> 1 file changed, 4 deletions(-)
>
> diff --git a/include/linux/dmaengine.h b/include/linux/dmaengin
Hi Arnd,
On Mon, Nov 15, 2021 at 11:21:30AM +0100, Arnd Bergmann wrote:
> On Mon, Nov 15, 2021 at 10:14 AM Laurent Pinchart wrote:
> > On Mon, Nov 15, 2021 at 09:54:00AM +0100, Arnd Bergmann wrote:
> > > @@ -1285,11 +1287,13 @@ static int xilinx_dpdma_config(struct dma_
Hi Arnd,
On Mon, Nov 15, 2021 at 01:38:07PM +0100, Arnd Bergmann wrote:
> On Mon, Nov 15, 2021 at 12:49 PM Laurent Pinchart wrote:
> > On Mon, Nov 15, 2021 at 11:21:30AM +0100, Arnd Bergmann wrote:
> > > On Mon, Nov 15, 2021 at 10:14 AM Laurent Pinchart wrote:
> > > &
omas Zimmermann
I'm not sure to see what we gain from this, but I don't mind.
Reviewed-by: Laurent Pinchart
> ---
> include/drm/drm_gem_cma_helper.h | 114 ---
> 1 file changed, 60 insertions(+), 54 deletions(-)
>
> diff --git a/include/d
ic inline void drm_gem_cma_object_print_info(struct
> drm_printer *p, unsigned
> */
> static inline struct sg_table *drm_gem_cma_object_get_sg_table(struct
> drm_gem_object *obj)
> {
> - return drm_gem_cma_get_sg_table(obj);
> + struct drm_gem_cma_object *cma_obj = to_drm_gem_cma_obj(obj);
> +
> + return drm_gem_cma_get_sg_table(cma_obj);
> }
>
> /*
> @@ -107,7 +108,9 @@ static inline struct sg_table
> *drm_gem_cma_object_get_sg_table(struct drm_gem_ob
> */
> static inline int drm_gem_cma_object_vmap(struct drm_gem_object *obj, struct
> dma_buf_map *map)
> {
> - return drm_gem_cma_vmap(obj, map);
> + struct drm_gem_cma_object *cma_obj = to_drm_gem_cma_obj(obj);
> +
> + return drm_gem_cma_vmap(cma_obj, map);
> }
>
> /**
> @@ -123,7 +126,9 @@ static inline int drm_gem_cma_object_vmap(struct
> drm_gem_object *obj, struct dma
> */
> static inline int drm_gem_cma_object_mmap(struct drm_gem_object *obj, struct
> vm_area_struct *vma)
> {
> - return drm_gem_cma_mmap(obj, vma);
> + struct drm_gem_cma_object *cma_obj = to_drm_gem_cma_obj(obj);
> +
> + return drm_gem_cma_mmap(cma_obj, vma);
> }
>
> /*
--
Regards,
Laurent Pinchart
gt; > >iio: buffer-dma: Implement new DMABUF based userspace API
> > > >iio: buffer-dma: Boost performance using write-combine cache setting
> > > >iio: buffer-dmaengine: Support new DMABUF based userspace API
> > > >iio: core: Add support for cycli
Hello Esaki-san,
(CC'ing dri-devel and Daniel Stone)
On Sat, May 11, 2019 at 09:10:27PM +0300, Laurent Pinchart wrote:
> On Thu, May 09, 2019 at 06:25:19PM +0900, Esaki Tomohito wrote:
> > Hi Laurent-san
> >
> > > What's the purpose of this, as it adds no new
Hi Daniel,
On Thu, Nov 18, 2021 at 01:02:11PM +, Daniel Stone wrote:
> Hi all,
> Thanks for this Laurent. Esaki-san, could you please CC dri-devel@ on
> discussions like this?
>
> On Thu, 18 Nov 2021 at 12:32, Laurent Pinchart wrote:
> > On Sat, May 11, 2019 at 09:1
.org/schemas/display/panel/lvds.yaml#
> $schema: http://devicetree.org/meta-schemas/core.yaml#
>
> -title: LVDS Display Panel
> +title: LVDS Display Common Properties
Maybe
title: LVDS Display Panel Common Properties
or do you foresee this being useful for non-panel LBDS sin
mpatible:
> +items:
> + - enum:
> + - auo,b101ew05
> + - tbs,a711-panel
> +
> + - const: panel-lvds
> +
> +unevaluatedProperties: false
> +
> +required:
> + - compatible
> + - data-mapping
> + - width-mm
> + - height-mm
> + - panel-timing
> + - port
> +
> +...
--
Regards,
Laurent Pinchart
> > *host,
> > struct mipi_dsi_device *device)
> > {
> > struct sun6i_dsi *dsi = host_to_sun6i_dsi(host);
> > - struct drm_panel *panel = of_drm_find_panel(device->dev.of_node);
> > + struct device_node *remote = device->dev.of_node;
> > int ret;
> >
> > - if (IS_ERR(panel))
> > - return PTR_ERR(panel);
> > + if (!of_device_is_available(remote)) {
> > + /**
> > +* I2C interfaced DSI bridges will register DSI host on the
> > +* bridge drivers instead of conventional device.
> > +*
> > +* Those are probed via host of_node instead of device of_node.
> > +*/
>
> I have no idea what you mean here. Can you expand on what issue you've
> tried to solve here?
>
> > + remote = of_graph_get_remote_node(host->dev->of_node, 0, 0);
> > + if (!remote)
> > + return -ENODEV;
> > + }
> > +
> > + dsi->panel = of_drm_find_panel(remote);
> > + if (IS_ERR(dsi->panel)) {
> > + dsi->panel = NULL;
> > +
> > + dsi->next_bridge = of_drm_find_bridge(remote);
> > + if (IS_ERR(dsi->next_bridge)) {
> > + dev_err(dsi->dev, "failed to find bridge\n");
> > + return PTR_ERR(dsi->next_bridge);
> > + }
> > + } else {
> > + dsi->next_bridge = NULL;
> > + }
> > +
> > + of_node_put(remote);
>
> Using devm_drm_of_get_bridge would greatly simplify the driver
>
> Maxime
--
Regards,
Laurent Pinchart
};
> diff --git a/MAINTAINERS b/MAINTAINERS
> index f32c7d733255..a3019399dec0 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6198,6 +6198,12 @@ DRM DRIVER FOR TDFX VIDEO CARDS
> S: Orphan / Obsolete
> F: drivers/gpu/drm/tdfx/
>
> +DRM DRIVER FOR TI DLPC3433 MIPI DSI DISPLAY CONTROLLER BRIDGE
> +M: Jagan Teki
> +M: Christopher Vollo
> +S: Maintained
> +F: Documentation/devicetree/bindings/display/bridge/ti,dlpc3433.yaml
> +
> DRM DRIVER FOR TPO TPG110 PANELS
> M: Linus Walleij
> S: Maintained
--
Regards,
Laurent Pinchart
monitors.
HDMI monitors seem to be generally more tolerant to incorrect timings,
but may be affected too.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du
car_du_output' while we are here.
>
> Fixes: b291fdcf5114 ("drm: rcar-du: Add r8a779a0 device support")
> Suggested-by: Biju Das
> Signed-off-by: Kieran Bingham
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/rcar-du/rcar_du_drv.c | 6 --
> 1 file
Hi Kieran,
Thank you for the patch.
On Fri, Nov 26, 2021 at 10:15:15AM +, Kieran Bingham wrote:
> From: Kieran Bingham
>
> Signed-off-by: Kieran Bingham
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/rcar-du/Makefile | 2 +-
> 1 file changed, 1 insert
Hi Kieran,
Thank you for the patch.
On Fri, Nov 26, 2021 at 10:15:16AM +, Kieran Bingham wrote:
> The RCAR_MIPI_DSI uses the DRM_MIPI_DSI interface.
>
> Ensure that it is selected when the option is enabled.
>
> Signed-off-by: Kieran Bingham
Reviewed-by: Laurent Pinchart
tup_info->err / 100,
> + clk, fin, setup_info->fout, fout_target, setup_info->err / 100,
We don't need the fout in the caller, so it could be a local variable
(best_fout for instance). I can however imagine that we the frequency
could become useful in the caller, so
Reviewed-by: Laurent Pinchart
> setup_info->err % 100, setup_info->m,
> setup_info->n, setup_info->div);
> dev_dbg(dsi->dev,
--
Regards,
Laurent Pinchart
nitialize the DSI host. */
> dsi->host.dev = dsi->dev;
> dsi->host.ops = &rcar_mipi_dsi_host_ops;
> @@ -788,11 +799,6 @@ static int rcar_mipi_dsi_probe(struct platform_device
> *pdev)
> if (ret < 0)
> return ret;
>
> - /* Initi
;
> Fixes: b291fdcf5114 ("drm: rcar-du: Add r8a779a0 device support")
> Signed-off-by: Kieran Bingham
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 11 ++-
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git
c int rcar_mipi_dsi_probe(struct platform_device
> *pdev)
> if (ret < 0)
> return ret;
>
> - /* Initialize the DRM bridge. */
> - dsi->bridge.funcs = &rcar_mipi_dsi_bridge_ops;
> - dsi->bridge.of_node = dsi->dev->of_node;
> - drm_bridge_add(&dsi->bridge);
> -
> return 0;
> }
>
> @@ -798,8 +803,6 @@ static int rcar_mipi_dsi_remove(struct platform_device
> *pdev)
> {
> struct rcar_mipi_dsi *dsi = platform_get_drvdata(pdev);
>
> - drm_bridge_remove(&dsi->bridge);
> -
> mipi_dsi_host_unregister(&dsi->host);
>
> return 0;
--
Regards,
Laurent Pinchart
rm_of_get_bridge(dev, dev->of_node, 1, 0);
> if (IS_ERR(dsi->next_bridge)) {
> dev_err(dev, "failed to get next bridge\n");
> return PTR_ERR(dsi->next_bridge);
> }
>
> But it seems I got out of sequence and saved out the wrong patch ;-(
>
> If you think it's better with the error print, please add it while
> squashing, or if you really need, I can send an updated patch and
> retest.
I think an error message is useful, yes. I'll add it manually.
> >
> > /* Initialize the DRM bridge. */
> > dsi->bridge.funcs = &rcar_mipi_dsi_bridge_ops;
--
Regards,
Laurent Pinchart
-laurent.pinchart+rene...@ideasonboard.com/
LUU HOAI (1):
drm: rcar-du: Add R-Car DSI driver
Laurent Pinchart (1):
dt-bindings: display: bridge: Add binding for R-Car MIPI DSI/CSI-2 TX
.../display/bridge/renesas,dsi-csi2-tx.yaml | 118 +++
MAINTAINERS | 1 +
drivers
The R-Car MIPI DSI/CSI-2 TX is embedded in the Renesas R-Car V3U SoC. It
can operate in either DSI or CSI-2 mode, with up to four data lanes.
Signed-off-by: Laurent Pinchart
Reviewed-by: Kieran Bingham
Acked-by: Sam Ravnborg
Reviewed-by: Rob Herring
Reviewed-by: Geert Uytterhoeven
From: LUU HOAI
The driver supports the MIPI DSI/CSI-2 TX encoder found in the R-Car V3U
SoC. It currently supports DSI mode only.
Signed-off-by: LUU HOAI
Signed-off-by: Laurent Pinchart
Reviewed-by: Kieran Bingham
Tested-by: Kieran Bingham
Acked-by: Sam Ravnborg
---
Changes since v2
Hi Jagan,
On Wed, Dec 01, 2021 at 04:12:39PM +0530, Jagan Teki wrote:
> On Wed, Dec 1, 2021 at 10:54 AM Laurent Pinchart wrote:
> >
> > From: LUU HOAI
> >
> > The driver supports the MIPI DSI/CSI-2 TX encoder found in the R-Car V3U
> > SoC. It currently supports
From: LUU HOAI
The driver supports the MIPI DSI/CSI-2 TX encoder found in the R-Car V3U
SoC. It currently supports DSI mode only.
Signed-off-by: LUU HOAI
Signed-off-by: Laurent Pinchart
Reviewed-by: Kieran Bingham
Tested-by: Kieran Bingham
Acked-by: Sam Ravnborg
---
Changes since v3
Hi Kieran,
On Wed, Dec 01, 2021 at 10:40:07AM +, Kieran Bingham wrote:
> Quoting Laurent Pinchart (2021-12-01 05:24:06)
> > From: LUU HOAI
> >
> > The driver supports the MIPI DSI/CSI-2 TX encoder found in the R-Car V3U
> > SoC. It currently supports DSI mode o
nts the message as an dev_err if
the error code is not -EPROBE_DEFER, and as dev_dbg otherwise. It's
meant for probe time only though, so I don't think it can be used here,
but a similar feature could be useful. Or dev_err_probe() could be
extended to support non-probe use cases, but that would be more
difficult.
> #endif
>
> return ret;
--
Regards,
Laurent Pinchart
e of the helper macro
> SET_RUNTIME_PM_OPS()")
I wonder how well drivers are tested with !CONFIG_PM. We may be going
through hoops and loops to support this when it actually won't work in
most drivers. That's a separate issue though :-)
Reviewed-by: Laurent Pinchart
To
501 - 600 of 9324 matches
Mail list logo
