On Thu, Jan 16, 2025 at 10:43:40AM +0200, Laurent Pinchart wrote:
> On Wed, Jan 15, 2025 at 02:34:26PM +, Daniel Stone wrote:
> > On Wed, 15 Jan 2025 at 14:20, Tomi Valkeinen wrote:
> > > No disagreement there, we need CREATE_DUMB2.
> > >
> > > My point is t
need a standard ioctl that can create
linear YUV buffers. I've been told many times that DRM doesn't want to
standardize buffer allocation further than what CREATE_DUMB is made for.
Can we reconsider this rule then ?
--
Regards,
Laurent Pinchart
e: 'oneOf'
> conditional failed, one must be fixed:
> ['fsl,imx7d-mipi-dsim', 'fsl,imx8mm-mipi-dsim'] is too long
>
> Signed-off-by: Alexander Stein
Reviewed-by: Laurent Pinchart
> ---
> .../devicetree/bindings/display/bridge/samsung,mipi-dsim.yam
/dts/nxp/imx/imx7s-mba7.dtb: iomuxc-gpr@3034: 'csi-mux' does
> not match any of the regexes: 'pinctrl-[0-9]+'
> from schema $id:
> http://devicetree.org/schemas/soc/imx/fsl,imx-iomuxc-gpr.yaml#
>
> Signed-off-by: Alexander Stein
Reviewed-by: Lauren
On Mon, Jan 06, 2025 at 04:36:26PM +0100, Marek Vasut wrote:
> On 1/6/25 8:05 AM, Laurent Pinchart wrote:
> > On Mon, Jan 06, 2025 at 03:48:52AM +0100, Marek Vasut wrote:
> >> On 1/6/25 12:22 AM, Laurent Pinchart wrote:
> >>> Hi Marek,
> >>
>
On Mon, Jan 06, 2025 at 03:48:52AM +0100, Marek Vasut wrote:
> On 1/6/25 12:22 AM, Laurent Pinchart wrote:
> > Hi Marek,
>
> Hi,
>
> > Thank you for the patch.
> >
> > On Sun, Jan 05, 2025 at 08:06:03PM +0100, Marek Vasut wrote:
> >> Add a flag m
(CC'ing Hans Verkuil)
On Mon, Jan 06, 2025 at 12:52:55AM +0200, Dmitry Baryshkov wrote:
> On Sun, Dec 15, 2024 at 02:38:05PM +0200, Laurent Pinchart wrote:
> > Hi Dmitry,
> >
> > Thank you for the patch.
> >
> > On Sun, Dec 15, 2024 at 01:09:08PM +0200, Dm
; > drivers/gpu/drm/tegra/hdmi.c | 2 +-
> > drivers/gpu/drm/tegra/sor.c | 2 +-
> > drivers/gpu/drm/vc4/vc4_txp.c| 2 +-
> > drivers/gpu/drm/virtio/virtgpu_display.c | 2 +-
> > drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 2 +-
> > drivers/gpu/drm/vmwgfx/vmwgfx_kms.h | 2 +-
> > drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 2 +-
> > include/drm/display/drm_hdmi_state_helper.h | 2 +-
> > include/drm/drm_encoder_slave.h | 2 +-
> > include/drm/drm_modeset_helper_vtables.h | 4 ++--
> > 71 files changed, 92 insertions(+), 93 deletions(-)
> > ---
> > base-commit: 4176cf5c5651c33769de83bb61b0287f4ec7719f
> > change-id: 20241115-drm-connector-mode-valid-const-ae3db0ef6cb7
--
Regards,
Laurent Pinchart
...
>
> ports {
> port@1 {
> hdmi_tx_out: endpoint {
> remote-endpoint = <&hdmi_connector_in>;
> };
> };
> };
> };
> ```
Are there any in-tree DT sources that use the old bindings ?
> Signed-off-
On Thu, Jan 02, 2025 at 05:26:50AM +0200, Dmitry Baryshkov wrote:
> On Thu, Jan 02, 2025 at 12:36:20AM +0200, Laurent Pinchart wrote:
> > On Tue, Dec 31, 2024 at 10:10:51PM +0100, Marek Vasut wrote:
> > > On 12/31/24 9:31 PM, Laurent Pinchart wrote:
> > >
On Tue, Dec 31, 2024 at 10:10:51PM +0100, Marek Vasut wrote:
> On 12/31/24 9:31 PM, Laurent Pinchart wrote:
> > Hi Marek,
>
> Hi,
>
> > Thank you for the patch.
> >
> > On Tue, Dec 31, 2024 at 08:28:48PM +0100, Marek Vasut wrote:
> >> Add a flag m
kernel versions later (in commit
841281fe52a769fe, "drm: rcar-du: Drop LVDS device tree backward
compatibility").
> Signed-off-by: Marek Vasut
> ---
> Cc: Andrzej Hajda
> Cc: David Airlie
> Cc: Fabio Estevam
> Cc: Jernej Skrabec
> Cc: Jonas Karlman
> Cc: Laure
t;
> Also add the minItems and maxItems to the top level properties.
>
> Signed-off-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
> ---
> Documentation/devicetree/bindings/display/renesas,du.yaml | 15
> ++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
minItems: 4
> >> + maxItems: 4
> >
> > AFAIK these two additions are not needed, as they already match the
> > values defined at the top level.
>
> But if we add a new SoC, which has 5 vsps, we would need to increase the
> values in the top level. Which would then mean these are needed, and I'm
> sure adding them could be missed.
Let's keep things consistent with maxItems specified everywhere (my
preference is to not specify the items count at the top level hereas I
don't see any value in doing so, but I won't fight on that one if it's
what it takes to get the bindings merged).
--
Regards,
Laurent Pinchart
006.h | 4 +-
> > > .../gpu/drm/nouveau/include/i2c/encoder_i2c.h | 109
> > > -
> > > .../gpu/drm/nouveau/include}/i2c/sil164.h | 4 +-
> > > drivers/gpu/drm/nouveau/nouveau_connector.c| 6 +-
> > > drivers/gpu/drm/nouveau/nouveau_encoder.h | 13 +--
> > > 22 files changed, 172 insertions(+), 232 deletions(-)
> > > ---
> > > base-commit: 4176cf5c5651c33769de83bb61b0287f4ec7719f
> > > change-id: 20241214-nouveau-encoder-slave-a6dd422fa4a9
--
Regards,
Laurent Pinchart
On Mon, Dec 16, 2024 at 01:02:26PM +0200, Tomi Valkeinen wrote:
> On 16/12/2024 10:32, Laurent Pinchart wrote:
> > On Mon, Dec 16, 2024 at 08:58:49AM +0100, Krzysztof Kozlowski wrote:
> >> On Fri, Dec 13, 2024 at 04:02:59PM +0200, Tomi Valkeinen wrote:
> >>> From: T
t; >> +port@0:
> >> + description: DSI 0
> >> +port@1: false
> >> +port@2: false
> >> + port@3: false
> >> +
> >> + required:
> >> +- port@0
> >> +
> >> +renesas,vsps:
> >> + minItems: 1
> >
> > so drop minItems here as well.
>
> Ok. I wanted to be consistent with the other vsps entries in the file,
> so I added both min and max items. But I can drop it.
I'd favour consistency with the other vsps entries, but not enough to
fight over it.
--
Regards,
Laurent Pinchart
On Mon, Dec 16, 2024 at 11:42:30AM +0100, Krzysztof Kozlowski wrote:
> On 16/12/2024 09:32, Laurent Pinchart wrote:
> > On Mon, Dec 16, 2024 at 08:58:49AM +0100, Krzysztof Kozlowski wrote:
> >> On Fri, Dec 13, 2024 at 04:02:59PM +0200, Tomi Valkeinen wrote:
> >
+)
>
> The top level property should define widest constraints as well.
I'm curious, why is that ? I understand why a top-level default would
make sense when it's optionally overridden by model-specific values, but
in this case there's no such default. Every SoC has its own fixed value.
--
Regards,
Laurent Pinchart
a, u64 *val)
> struct zynqmp_dp *dp = data;
>
> mutex_lock(&dp->lock);
> - *val = drm_dp_bw_code_to_link_rate(dp->test.bw_code) * 1;
> + *val = drm_dp_bw_code_to_link_rate(dp->test.bw_code) * 1ULL;
> mutex_unlock(&dp->lock);
> return 0;
> }
--
Regards,
Laurent Pinchart
uldn't have created a tda/ subdirectory in bridge/, but I
don't mind much either way.
Reviewed-by: Laurent Pinchart
> drivers/gpu/drm/i2c/Kconfig | 13 -
> drivers/gpu/drm/i2c/Makefile | 4
> 10 files changed, 22
onding API from the
> TDA998x driver.
>
> Signed-off-by: Dmitry Baryshkov
Reviewed-by: Laurent Pinchart
> ---
> MAINTAINERS | 1 -
> drivers/gpu/drm/i2c/tda998x_drv.c | 49
> ---
&
r\n");
> + if (ret < 0) {
> + ret = dev_err_probe(
> + &pdev->dev, ret,
> + "failed to get HDMI +5V Power regulator\n");
ret = dev_err_p
e DRM KMS helper.
>
> Suggested-by: Laurent Pinchart
> Signed-off-by: Dmitry Baryshkov
> ---
> drivers/gpu/drm/Makefile | 1 -
> drivers/gpu/drm/nouveau/dispnv04/Kbuild| 1 +
> drivers/gpu/drm/nouveau/dispnv04/dfp.c | 10
inside the DRM subsystem. In
> preparation to moving this set of helpers to the nouveau driver, move
> the only two I2C driver that use that interface to the nouveau driver
> too.
>
> Suggested-by: Laurent Pinchart
> Signed-off-by: Dmitry Baryshkov
>
xItems to match the minItems.
>
> Signed-off-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
> ---
> Documentation/devicetree/bindings/display/renesas,du.yaml | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/displa
"failed to enable PWR regulator:
> %d\n", ret);
> - return ret;
> + goto err_put;
> }
> }
>
> @@ -383,6 +391,11 @@ static int display_connector_probe(struct
> platform_device *pdev)
> drm_bridge_add(&conn->bridge);
>
> return 0;
> +
> +err_put:
> + if (conn->bridge.ddc)
i2c_put_adapter() already has a NULL check.
> + i2c_put_adapter(conn->bridge.ddc);
> + return ret;
> }
>
> static void display_connector_remove(struct platform_device *pdev)
--
Regards,
Laurent Pinchart
p->lock);
> - *val = drm_dp_bw_code_to_link_rate(dp->test.bw_code) * 1;
> + *val = drm_dp_bw_code_to_link_rate(dp->test.bw_code) * (u64)1;
You can also make the integer a 64-bit constant with
*val = drm_dp_bw_code_to_link_rate(dp->test.bw_code) * 1ULL;
> mutex_unlock(&dp->lock);
> return 0;
> }
--
Regards,
Laurent Pinchart
@@ -488,6 +489,7 @@ static int ti_sn65dsi86_add_aux_device(struct
> ti_sn65dsi86 *pdata,
> return -ENOMEM;
>
> aux->name = name;
> + aux->id = (client->adapter->nr << 10) | client->addr;
> aux->dev.parent = dev;
> aux->dev.release = ti_sn65dsi86_aux_device_release;
> device_set_of_node_from_dev(&aux->dev, dev);
--
Regards,
Laurent Pinchart
t; Suggested-by: Laurent Pinchart
> Signed-off-by: Biju Das
Reviewed-by: Laurent Pinchart
> ---
> Changes in v2:
> * Moved .mode_valid from crtc to encoder as the new state is not
>available in crtc and instead, we could check renc->output for
>.mode_valid() f
; Signed-off-by: Biju Das
Reviewed-by: Laurent Pinchart
> ---
> v1->v2:
> * Added Fixes tag.
> ---
> drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c | 8 +---
> 1 file changed, 1 insertion(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/renesas/rz-d
On Tue, Dec 10, 2024 at 01:04:19AM +0200, Laurent Pinchart wrote:
> On Fri, Dec 06, 2024 at 11:32:35AM +0200, Tomi Valkeinen wrote:
> > From: Tomi Valkeinen
> >
> > Currently the driver always writes DPTSR when setting up the hardware.
> > However, writing the regis
a plane is used, and the register is not even documented for SoCs
> that do not have the second source.
I've confirmed that for all the models currently supported by the DU
driver.
> So move the write behind a condition.
>
> Signed-off-by: Tomi Valkeinen
Reviewed-by: Laurent Pinc
; > >>
> > >> Add display related clocks for DU, DSI, FCPVD, and VSPD.
> > >>
> > >> Signed-off-by: Tomi Valkeinen
> > >> Reviewed-by: Laurent Pinchart
> > >> Tested-by: Geert Uytterhoeven
> > >
> > > Reviewed
gt; drm: adv7511: Drop dsi single lane support
> >
> > .../bindings/display/bridge/adi,adv7533.yaml | 2 +-
> > drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 12 ++--
> > drivers/gpu/drm/bridge/adv7511/adv7533.c | 4 +---
> > 3 files changed, 12 insertions(+), 6 deletions(-)
--
Regards,
Laurent Pinchart
rhoeven
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c | 18 ++
> drivers/gpu/drm/renesas/rcar-du/rcar_du_group.c | 4 +++-
> 2 files changed, 21 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/renesas/rca
t; > the second physical channel in the group, and thus does have DPTSR2.
>
> That logic does make sense. So that would be if (rgrp->channels_mask &
> BIT(1)) then write DPTSR? And probably add a comment in the code about this.
>
> > And apparently we had this discussion before...
> > https://lore.kernel.org/all/camuhmdxxf4oepnylvp84ohsa+wdehcnjbxnhjyo7-1vxpbj...@mail.gmail.com
>
> Somehow I hadn't even realized Jacopo had sent these before...
Oops...
I'll let Jacopo and you decide who will send an updated patch.
--
Regards,
Laurent Pinchart
ctions for W=1 build").
>
> Signed-off-by: Jani Nikula
https://lore.kernel.org/r/20240911095113.gb4...@pendragon.ideasonboard.com
I wonder if Dave and Sima are starting to ignore my pull request in the
hope I'll switch to using drm-misc :-S I'll send another one.
> ---
>
On Thu, Dec 05, 2024 at 07:41:09AM +0200, Tomi Valkeinen wrote:
> On 03/12/2024 12:48, Laurent Pinchart wrote:
> > On Tue, Dec 03, 2024 at 11:22:15AM +0200, Tomi Valkeinen wrote:
> >> On 03/12/2024 10:56, Laurent Pinchart wrote:
> >>> On Tue, Dec 03, 2024 at 10:01:40
On Tue, Dec 03, 2024 at 11:22:15AM +0200, Tomi Valkeinen wrote:
> On 03/12/2024 10:56, Laurent Pinchart wrote:
> > On Tue, Dec 03, 2024 at 10:01:40AM +0200, Tomi Valkeinen wrote:
> >> From: Tomi Valkeinen
> >>
> >> Add support for r8a779h0. It is very simila
Hi Tomi,
Thank you for the patch.
On Tue, Dec 03, 2024 at 10:01:43AM +0200, Tomi Valkeinen wrote:
> From: Tomi Valkeinen
>
> Add support for the mini DP output on the Gray Hawk board.
>
> Signed-off-by: Tomi Valkeinen
Assuming this has passed the DT checks,
Reviewed-by: L
>;
> +
> + port@0 {
> + reg = <0>;
> + du_out_dsi0: endpoint {
> + remote-endpoint = <&dsi0_in>;
> + };
>
Hi Tomi,
Thank you for the patch.
On Tue, Dec 03, 2024 at 10:01:41AM +0200, Tomi Valkeinen wrote:
> From: Tomi Valkeinen
>
> Fix the indent on the two regulators.
>
> Signed-off-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
> ---
> .../boot/dts/renesas/r8a779h0
ck);
> - rcar_du_group_write(rgrp, DPTSR, (rgrp->dptsr_planes << 16) |
> - rgrp->dptsr_planes);
> - mutex_unlock(&rgrp->lock);
> + if (!rcar_du_has(rcdu, RCAR_DU_FEATURE_NO_DPTSR)) {
> + /* Apply planes to CRTCs association. */
> + mutex_lock(&rgrp->lock);
> + rcar_du_group_write(rgrp, DPTSR, (rgrp->dptsr_planes << 16) |
> + rgrp->dptsr_planes);
> + mutex_unlock(&rgrp->lock);
> + }
> }
>
> /*
--
Regards,
Laurent Pinchart
lkeinen
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi.c
> b/drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi.c
> index 92f4261305
On Tue, Dec 03, 2024 at 09:38:44AM +0100, Geert Uytterhoeven wrote:
> Hi Laurent,
>
> On Tue, Dec 3, 2024 at 9:19 AM Laurent Pinchart
> wrote:
> > On Tue, Dec 03, 2024 at 10:01:36AM +0200, Tomi Valkeinen wrote:
> > > From: Tomi Valkeinen
> > >
> > &
e8924 ("drm: Place Renesas drivers in a separate dir")
Should this have CC: stable ?
> Signed-off-by: Tomi Valkeiben
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi.c | 2 +-
> drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi_reg
esent real clock topologies. I don't however
don't expect it to cause any functional issue here, as the devices
related to the above clocks do not depend on the clock frequency.
There's no strict need to model the real hardware clock tree if it has
no impact on software, so
R
R-Car V4H compatible DU
> + - renesas,du-r8a779h0 # for R-Car V4M compatible DU
>
>reg:
> maxItems: 1
You also need to add h0 to the g0 block in the conditional properties
below. With that,
Reviewed-by: Laurent Pinchart
--
Regards,
Laurent Pinchart
Hi Tomi,
Thank you for the patch.
On Tue, Dec 03, 2024 at 10:01:35AM +0200, Tomi Valkeinen wrote:
> From: Tomi Valkeinen
>
> Extend the Renesas DSI display bindings to support the r8a779h0 V4M.
>
> Signed-off-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
> ---
gpu: drm: tiny: replace of_graph_get_next_endpoint()
>
> drivers/gpu/drm/drm_of.c | 4 +++-
> drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c | 2 +-
> drivers/gpu/drm/tiny/arcpgu.c | 2 +-
> 3 files changed, 5 insertions(+), 3 deletions(-)
>
--
Regards,
Laurent Pinchart
@ int adv7533_parse_dt(struct device_node *np, struct
> adv7511 *adv)
> if (!adv->host_node)
> return -ENODEV;
>
> - of_node_put(adv->host_node);
> -
> adv->use_timing_gen = !of_property_read_bool(np,
> "adi,disable-timing-generator");
>
--
Regards,
Laurent Pinchart
drop the check here, as of_node_put()
is a no-op when called with a NULL pointer. Sorry about that.
> + of_node_put(adv7511->host_node);
>
> return ret;
> }
> @@ -1371,6 +1376,9 @@ static void adv7511_remove(struct i2c_client *i2c)
> {
> struct adv
On Wed, Nov 06, 2024 at 03:04:37PM +0200, Laurent Pinchart wrote:
> On Mon, Oct 14, 2024 at 05:56:40AM +, CK Hu (胡俊光) wrote:
> > Hi, Shu-hsiang:
> >
> > On Wed, 2024-10-09 at 19:15 +0800, Shu-hsiang Yang wrote:
> > > Add UAPI for MediaTek ISP platform, providi
On Mon, Nov 18, 2024 at 11:26:03AM +0200, Jani Nikula wrote:
> On Mon, 18 Nov 2024, Dmitry Baryshkov wrote:
> > On Mon, 18 Nov 2024 at 01:33, Laurent Pinchart wrote:
> >> On Mon, Nov 18, 2024 at 01:22:12AM +0200, Dmitry Baryshkov wrote:
> >> > On Sun, 17 Nov 2024 at
_0/mtk_cam-seninf-hw_phy_2_0.c
> create mode 100644
> drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_csi_phy_2_0/mtk_cam-seninf-mipi-rx-ana-cdphy-csi0a.h
> create mode 100644
> drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_csi_phy_2_0/mtk_cam-seninf-seninf1-csi2.h
> create mode 100644
> drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_csi_phy_2_0/mtk_cam-seninf-seninf1-mux.h
> create mode 100644
> drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_csi_phy_2_0/mtk_cam-seninf-seninf1.h
> create mode 100644
> drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_csi_phy_2_0/mtk_cam-seninf-tg1.h
> create mode 100644
> drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_csi_phy_2_0/mtk_cam-seninf-top-ctrl.h
> create mode 100644 include/uapi/linux/mtkisp_camsys.h
--
Regards,
Laurent Pinchart
On Mon, Nov 18, 2024 at 01:22:12AM +0200, Dmitry Baryshkov wrote:
> On Sun, 17 Nov 2024 at 22:54, Laurent Pinchart wrote:
> > On Fri, Nov 15, 2024 at 11:09:26PM +0200, Dmitry Baryshkov wrote:
> > > The mode_valid() callbacks of drm_encoder, drm_crtc and drm_bridge
> &g
ept const argument.
I would write "take a const argument" instead of "accept". Same in the
other patches.
>
> Signed-off-by: Dmitry Baryshkov
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 2 +-
> include/drm/drm_modeset_h
ept const argument.
>
> Signed-off-by: Dmitry Baryshkov
Assuming you've compile-tested all this,
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 8
> drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 2 +-
llback of drm_connector to accept const
> struct drm_display_mode argument.
>
> Signed-off-by: Dmitry Baryshkov
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/sti/sti_hda.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/dr
> - drm_mode_set_crtcinfo(mode, 0);
> + test_mode = drm_mode_duplicate(connector->dev, mode);
> + if (!test_mode)
> + goto fail;
> +
> + drm_mode_set_crtcinfo(test_mode, 0);
I wonder if things could be refactored further to avoid t
ept const argument.
>
> Signed-off-by: Dmitry Baryshkov
Reviewed-by: Laurent Pinchart
On a side note, there's only two I2C slave encoder drivers left... I
wonder if we could so something about them. The ch7006 and sil164
drivers seem to be used by nouveau only, could they be move
anes;
>
> - adv->host_node = of_graph_get_remote_node(np, 0, 0);
> - if (!adv->host_node)
> - return -ENODEV;
> -
> - of_node_put(adv->host_node);
> + host_node = of_graph_get_remote_node(np, 0, 0);
> + if (!host_node)
> + return ERR_PTR(-ENODEV);
>
> adv->use_timing_gen = !of_property_read_bool(np,
> "adi,disable-timing-generator");
> @@ -190,5 +190,5 @@ int adv7533_parse_dt(struct device_node *np, struct
> adv7511 *adv)
> adv->rgb = true;
> adv->embedded_sync = false;
>
> - return 0;
> + return host_node;
> }
--
Regards,
Laurent Pinchart
MIPI-DSI device and attach the MIPI-DSI device to
> > its host.
> >>> drm/panel/panel-himax-hx83102.c follows and runs
> > mipi_dsi_attach() at the end of probe hook.
> > 3. In its struct mipi_dsi_host_ops.attach hook, the MIPI-DSI host can
> > now add its component.
> >>> drm/mediatek/mtk_dsi.c calls component_add() in the attach callback.
> >
> > Could you elaborate on the "different structures" you mentioned?
>
> Yeah, you're right, sorry.
>
> > To clarify my point: the issue is that component_add() may return
> > -EPROBE_DEFER if the component (e.g. DSI encoder) is not ready,
> > causing the panel bridge to be removed. However, drm_bridge_remove()
> > is bound to MIPI-DSI host instead of panel bridge, which owns the
> > actual list_head object.
> >
> > This might be reproducible with other MIPI-DSI host + panel
> > combinations by forcibly returning -EPROBE_DEFER in the host attach
> > hook (verification with another device is needed), so the fix may be
> > required in drm/bridge/panel.c.
>
> Yeah, I think you're just hitting another bridge lifetime issue, and
> it's not the only one unfortunately. Tying the bridge structure lifetime
> itself to the device is wrong, it should be tied to the DRM device
> lifetime instead.
>
> But then, the discussion becomes that bridges typically probe outside of
> the "main" DRM device probe path, so you don't have access to the DRM
> device structure until attach at best.
>
> That's why I'm a bit skeptical about your patch. It might workaround
> your issue, but it doesn't actually solve the problem. I guess the best
> way about it would be to convert bridges to reference counting, with the
> device taking a reference at probe time when it allocates the structure
> (and giving it back at remove time), and the DRM device taking one when
> it's attached and one when it's detached.
+1, I was considering writing exactly the same while reading your
review until I reached this paragraph. devm_* is a nice dream, and maybe
APIs that simplify cleanup in a similar way can be implemented (possibly
based on cleanup.h), but behind the scene they will need to rely on a
sound reference-counting base.
> It's much more involved than just another helper though :/
--
Regards,
Laurent Pinchart
Hi Christophe,
On Wed, Nov 13, 2024 at 10:19:24PM +0100, Christophe JAILLET wrote:
> Le 12/11/2024 à 23:43, Laurent Pinchart a écrit :
> > On Tue, Nov 12, 2024 at 10:12:25PM +0100, Christophe JAILLET wrote:
> >> 'struct i2c_device_id' is not modified in these drivers
[] = {
sound/soc/codecs/cs42l51-i2c.c:static struct i2c_device_id cs42l51_i2c_id[] = {
:-)
Reviewed-by: Laurent Pinchart
> 6 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/chipone-icn6211.c
> b/drivers/gpu/drm/bridge/chipone-icn6211.c
>
On Tue, Nov 12, 2024 at 10:44:29AM -0700, Shuah Khan wrote:
> On 11/11/24 22:18, Laurent Pinchart wrote:
> > On Mon, Nov 11, 2024 at 05:35:11PM -0700, Shuah Khan wrote:
> >> On 11/11/24 15:35, Laurent Pinchart wrote:
> >>> On Mon, Nov 11, 2024 at 02:50:45PM -0700, Shu
On Tue, Nov 12, 2024 at 09:41:58AM -0500, Sean Anderson wrote:
> On 11/12/24 00:27, Laurent Pinchart wrote:
> > Hi Dan,
> >
> > Thank you for the patch.
> >
> > On Mon, Nov 11, 2024 at 12:06:10PM +0300, Dan Carpenter wrote:
> >> We added some locking to
oblem correctly would be too much yak shaving :-S
>
> Keep the change isolated to DPI output.
>
> Signed-off-by: Marek Vasut
> ---
> Cc: Andrzej Hajda
> Cc: David Airlie
> Cc: Jernej Skrabec
> Cc: Jonas Karlman
> Cc: Laurent Pinchart
> Cc: Maarten Lankhorst
>
p_dp: Add locking")
> Signed-off-by: Dan Carpenter
Reviewed-by: Laurent Pinchart
Sean, how about replacing all the mutex_lock()/mutex_unlock() calls
you've added in a7d5eeaa57d7 with guards ?
> ---
> drivers/gpu/drm/xlnx/zynqmp_dp.c | 3 +--
> 1 file changed, 1 inserti
On Mon, Nov 11, 2024 at 05:35:11PM -0700, Shuah Khan wrote:
> On 11/11/24 15:35, Laurent Pinchart wrote:
> > On Mon, Nov 11, 2024 at 02:50:45PM -0700, Shuah Khan wrote:
> >> On 11/11/24 13:07, Simona Vetter wrote:
> >>> On Fri, Nov 08, 2024 at 09:18:53AM -0700, Shuah
ith the power to actually stand up
> > to problematic behavior.
>
> This scenario seems to be based on the assumption that the CoC's first
> go to action is seeking public apology. This is not the case. The CoC works
> towards reaching an understanding between the parties behind the scenes.
>
> As mentioned earlier public apologies and bans are actions taken when
> the CoC deems they are absolutely necessary. Bans are instituted only
> when the TAB agrees with 2/3 vote.
>
> > Note that I don't see this as a nack, just a heads up that there's a
> > potential conflict. I'm not worried though since Dave and me know pretty
> > much everyone involved in both CoC teams. I'm sure if this ever becomes a
> > real issue we can bridge things and figure out a solution.
>
> Thank you for you feedback and input. The CoC relies on the trust and respect
> from the community to the work it needs to do to ensure kernel community stays
> healthy as it continues its development work.
--
Regards,
Laurent Pinchart
err_probe(dev, -EPROBE_DEFER,
> > "failed to find dsi host\n");
> > @@ -181,8 +182,6 @@ int adv7533_parse_dt(struct device_node *np, struct
> > adv7511 *adv)
> > if (!adv->host_node)
> > return -ENODEV;
> >
> > - of_node_put(adv->host_node);
> > -
> > adv->use_timing_gen = !of_property_read_bool(np,
> >
> > "adi,disable-timing-generator");
--
Regards,
Laurent Pinchart
df
No need for a line break, you can write
[1]
https://www.analog.com/media/en/technical-documentation/data-sheets/ADV7535.pdf
>
> Fixes: 1e4d58cd7f88 ("drm/bridge: adv7533: Create a MIPI DSI device")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Biju Das
Reviewed-by: La
y a Closes: tag.
With those fixed,
Reviewed-by: Laurent Pinchart
> Cc: sta...@vger.kernel.org
> Signed-off-by: Biju Das
> ---
> Changes in v3:
> - Updated commit header and description
> - Updated fixes tag
> - Dropped single lane support
> Changes in v2:
> - Ad
gt; > +#define V4L2_CID_MTK_CAM_CAMSYS_HW_MODE
> > (V4L2_CID_USER_MTK_CAM_BASE + 21)
> > +
>
> Please give introduction of how to use these user space interface.
I'm very, very *not* thrilled by all this. It looks like a big pile of
hacks really. Every single param
On Wed, Nov 06, 2024 at 10:20:43AM +, Biju Das wrote:
> Hi Laurent Pinchart,
>
> Thanks for the feedback.
>
> > -Original Message-
> > From: Laurent Pinchart
> > Sent: 05 November 2024 16:06
> > Subject: Re: [PATCH v2 2/2] drm:
from Sakari,
> before Laurent's email. I am sorry if I rushed it in.
My review didn't exactly come quickly, so I won't blame anyone. The risk
of conflict in this file in v6.13 is very low so it should be fine. In
the unlikely case we have an issue, we'll figure it out.
--
Regards,
Laurent Pinchart
"adi,disable-timing-generator");
>
> + if (adv->use_timing_gen && num_lanes == 1)
> + return -EINVAL;
> +
> /* TODO: Check if these need to be parsed by DT or not */
> adv->rgb = true;
> adv->embedded_sync = false;
--
Regards,
Laurent Pinchart
181,8 +182,6 @@ int adv7533_parse_dt(struct device_node *np, struct
> adv7511 *adv)
> if (!adv->host_node)
> return -ENODEV;
>
> - of_node_put(adv->host_node);
> -
> adv->use_timing_gen = !of_property_read_bool(np,
> "adi,disable-timing-generator");
>
--
Regards,
Laurent Pinchart
serialized in seven
> > -time slots per pixel clock, on three (18-bit) or four (24-bit)
> > +time slots per pixel clock, on three (18-bit) or four (24-bit) or five
> > (30-bit)
s/ or four/, four/
with that,
Reviewed-by: Laurent Pinchart
> > differential data pairs at
On Tue, Nov 05, 2024 at 09:15:03AM +0100, Herve Codina wrote:
> On Mon, 28 Oct 2024 16:09:13 +0200 Laurent Pinchart wrote:
> > On Mon, Oct 28, 2024 at 02:55:47PM +0100, Maxime Ripard wrote:
> > > On Mon, Oct 28, 2024 at 03:28:58PM +0200, Laurent Pinchart wrote:
> > > &
ob Herring (Arm)
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/ite-it66121.c | 2 +-
> drivers/gpu/drm/bridge/sii902x.c | 2 +-
> drivers/gpu/drm/drm_panel.c | 2 +-
> drivers/gpu/drm/msm/dsi/dsi_host.c | 2 +-
> 4 files changed, 4 insertions(+), 4 delet
On Fri, Nov 01, 2024 at 12:27:15PM +0200, Dmitry Baryshkov wrote:
> On Fri, 1 Nov 2024 at 11:20, Laurent Pinchart wrote:
> > On Fri, Nov 01, 2024 at 11:49:07AM +0800, Sui Jingfeng wrote:
> > > On 2024/11/1 00:23, Johan Hovold wrote:
> > > > On Thu, Oct 31, 2024 at
dev.of_node' is same for all its instance.
> While other display bridges seems don't has such limitations.
Brainstorming a bit, I wonder if we could create a swnode for the
auxiliary device, instead of reusing the parent's OF node. This would
require switching the DRM OF-based APIs to fwnode, but that's easy and
mostly a mechanical change.
--
Regards,
Laurent Pinchart
st: 1
> > > > + - const: 2
> > > > + - const: 3
> > > > + - const: 4
> > >
> > > Why are they indexed starting from 1?
> >
> > Not sure, git grep -r data-lanes Documentation/devicetree/bindings/
> > Most start from 1. Not sure latest DT team's intention.
>
> They usually start from 1, because just before the property comes
> 'clock-lanes = <0>'. Otherwise in most of the cases the lanes are
> indexed from 0.
I'm not sure what the rule is for DSI, but for CSI we number data lanes
starting at 1 regardless of whether or not the clock lane is
configurable. Consistency help for driver implementations.
> > > > +
> > > > required:
> > > >- port@0
> > > >- port@1
--
Regards,
Laurent Pinchart
nce counter.
>
> HPD handling is traditionally belongs to connector, create standalone
> driver like this one *abuse* to both Maxime's simple bridge driver and
> Laurent's display-connector bridge driver or drm_bridge_connector or
> whatever. Why those work can't satisfy you? At least, their drivers
> are able to passing the mode setting states to the next bridge.
>
> Basically those AUX drivers implementation abusing the definition of
> bridge, abusing the definition of connector and abusing the DT.
> Its just manually populate instances across drivers.
--
Regards,
Laurent Pinchart
using the dev_name() of the "parent" sounds
> > > pretty good and seems like it addresses everyone's concerns. Was there
> > > a part of the conversation where someone pointed out problems with it
> > > that I missed? Is the next step to post a patch implementing that?
> > > It'll change sysfs paths and dev names for everyone using AUX bus, but
> > > presumably that's OK?
> >
> > It also requires changing in the way the auxiliary_match_id() works.
> > Currently matching is done using modname + ID.
>
> Right, so just using the parent's name instead of modname won't work,
> as the former is not a fixed string.
>
> > So, maybe using MODNAME.NAME.parent-name.ID is better (e.g.
> > ti_sn65dsi86.gpio.2-002d.1). It will still require changes to the
> > match_id function, but they won't be that intrusive (one just has to
> > skip two parts of the name instead of skipping just one).
>
> IMHO this is becoming too complex. What if the parent's name contains
> a period?
>
> So just using ida_alloc() in the caller seems like the most
> straight-forward solution.
Why would we duplicate that in every user, when it should really be the
responsibility of the bus ? We need a better solution.
--
Regards,
Laurent Pinchart
On Mon, Oct 28, 2024 at 02:55:47PM +0100, Maxime Ripard wrote:
> On Mon, Oct 28, 2024 at 03:28:58PM +0200, Laurent Pinchart wrote:
> > On Mon, Oct 28, 2024 at 01:21:45PM +0100, Maxime Ripard wrote:
> > > On Mon, Oct 28, 2024 at 01:28:57PM +0200, Laurent Pinchart wrote:
> >
On Mon, Oct 28, 2024 at 01:21:45PM +0100, Maxime Ripard wrote:
> On Mon, Oct 28, 2024 at 01:28:57PM +0200, Laurent Pinchart wrote:
> > On Mon, Oct 28, 2024 at 09:13:31AM +0100, Herve Codina wrote:
> > > On Sun, 27 Oct 2024 18:23:50 +0200 Laurent Pinchart wrote:
> > >
&g
On Mon, Oct 28, 2024 at 09:13:31AM +0100, Herve Codina wrote:
> Hi Laurent,
>
> On Sun, 27 Oct 2024 18:23:50 +0200
> Laurent Pinchart wrote:
>
> [...]
> > > +static int sn65dsi83_reset_pipeline(struct sn65dsi83 *sn65dsi83)
> > > +{
> > > + s
_WORK(&ctx->reset_work, sn65dsi83_reset_work);
> + INIT_DELAYED_WORK(&ctx->monitor_work, sn65dsi83_monitor_work);
>
> if (dev->of_node) {
> model = (enum sn65dsi83_model)(uintptr_t)
> @@ -710,6 +830,14 @@ static int sn65dsi83_probe(struct i2c_client *client)
> if (IS_ERR(ctx->regmap))
> return dev_err_probe(dev, PTR_ERR(ctx->regmap), "failed to get
> regmap\n");
>
> + if (client->irq) {
> + ret = devm_request_threaded_irq(ctx->dev, client->irq, NULL,
> sn65dsi83_irq,
> + IRQF_ONESHOT,
> dev_name(ctx->dev), ctx);
> + if (ret)
> + return dev_err_probe(dev, ret, "failed to request
> irq\n");
> + ctx->use_irq = true;
> + }
> +
> dev_set_drvdata(dev, ctx);
> i2c_set_clientdata(client, ctx);
>
--
Regards,
Laurent Pinchart
nterrupts property.
>
> Signed-off-by: Herve Codina
Reviewed-by: Laurent Pinchart
> ---
> .../devicetree/bindings/display/bridge/ti,sn65dsi83.yaml | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git
> a/Documentation/devicetree/bindings/display/bridge/ti,sn
> On Sun, Oct 20, 2024 at 05:36:29PM +0300, Laurent Pinchart wrote:
> > > > > On Fri, Oct 18, 2024 at 04:31:21PM +0200, Greg KH wrote:
> > > > > > On Fri, Oct 18, 2024 at 05:25:22PM +0300, Laurent Pinchart wrote:
> > > > > > > On Fri, Oct 18, 2024
On Fri, Oct 18, 2024 at 04:31:21PM +0200, Greg KH wrote:
> On Fri, Oct 18, 2024 at 05:25:22PM +0300, Laurent Pinchart wrote:
> > On Fri, Oct 18, 2024 at 04:09:26PM +0200, Greg KH wrote:
> > > On Fri, Oct 18, 2024 at 03:36:48PM +0200, Geert Uytterhoeven wrote:
> > >
Hi Greg,
On Fri, Oct 18, 2024 at 04:09:26PM +0200, Greg KH wrote:
> On Fri, Oct 18, 2024 at 03:36:48PM +0200, Geert Uytterhoeven wrote:
> > On Fri, Oct 18, 2024 at 3:10 PM Laurent Pinchart wrote:
> > > On Fri, Oct 18, 2024 at 09:45:52AM +0200, Geert Uytterhoeven wrote:
&
p;client->dev;
> @@ -1903,6 +1916,17 @@ static int ti_sn65dsi86_probe(struct i2c_client
> *client)
> pdata = devm_kzalloc(dev, sizeof(struct ti_sn65dsi86), GFP_KERNEL);
> if (!pdata)
> return -ENOMEM;
> +
> + ret = ida_alloc(&ti_sn65dsi86_ida, GFP_KERNEL);
> + if (ret < 0)
> + return ret;
> +
> + pdata->id = ret;
> +
> + ret = devm_add_action_or_reset(dev, ti_sn65dsi86_devm_ida_free, pdata);
> + if (ret)
> + return ret;
> +
> dev_set_drvdata(dev, pdata);
> pdata->dev = dev;
>
--
Regards,
Laurent Pinchart
esktop.org/event/6/contributions/395/).
Here are the raw notes from the workshop.
XDC 2024 - Buffer allocation workshop
=
Attendees:
- Erico Nunes
- James Jones
- Laurent Pinchart
- Nicolas Dufresne
- Yunxiang (Teddy) Li
Relevant content:
- XDC 20
Hi Ulf,
On Tue, Oct 08, 2024 at 12:08:24AM +0200, Ulf Hansson wrote:
> On Mon, 7 Oct 2024 at 20:49, Laurent Pinchart wrote:
> > On Fri, Oct 04, 2024 at 04:38:36PM +0200, Ulf Hansson wrote:
> > > On Fri, 4 Oct 2024 at 11:41, Sakari Ailus wrote:
> > > >
> > >
6-shared.c | 2 +-
> > sound/soc/codecs/cs35l56.c| 2 +-
> > sound/soc/codecs/cs42l42-sdw.c| 2 +-
> > sound/soc/codecs/cs42l42.c| 4 +-
> > sound/soc/codecs/cs42l43-jack.c | 10 +-
> > sound/soc/codecs/cs42l43.c| 4 +-
> > sound/soc/codecs/hda.c| 6 +-
> > sound/soc/codecs/madera.c | 6 +-
> > sound/soc/codecs/max98363.c | 2 +-
> > sound/soc/codecs/max98373-sdw.c | 2 +-
> > sound/soc/codecs/rt1017-sdca-sdw.c| 2 +-
> > sound/soc/codecs/rt1308-sdw.c | 2 +-
> > sound/soc/codecs/rt1316-sdw.c | 2 +-
> > sound/soc/codecs/rt1318-sdw.c | 2 +-
> > sound/soc/codecs/rt1320-sdw.c | 2 +-
> > sound/soc/codecs/rt5682-sdw.c | 2 +-
> > sound/soc/codecs/rt700.c | 4 +-
> > sound/soc/codecs/rt711-sdca.c | 4 +-
> > sound/soc/codecs/rt711.c | 4 +-
> > sound/soc/codecs/rt712-sdca-dmic.c| 2 +-
> > sound/soc/codecs/rt712-sdca.c | 4 +-
> > sound/soc/codecs/rt715-sdca.c | 2 +-
> > sound/soc/codecs/rt715.c | 2 +-
> > sound/soc/codecs/rt722-sdca.c | 4 +-
> > sound/soc/codecs/wcd-mbhc-v2.c| 4 +-
> > sound/soc/codecs/wsa881x.c| 2 +-
> > sound/soc/codecs/wsa884x.c| 2 +-
> > sound/soc/intel/atom/sst/sst_pvt.c| 2 +-
> > sound/soc/intel/avs/core.c| 2 +-
> > sound/soc/intel/avs/debugfs.c | 4 +-
> > sound/soc/intel/avs/pcm.c | 2 +-
> > sound/soc/intel/catpt/pcm.c | 12 +-
> > sound/soc/intel/catpt/sysfs.c | 2 +-
> > sound/soc/soc-component.c | 2 +-
> > sound/soc/sof/control.c | 2 +-
> > sound/soc/sof/debug.c | 2 +-
> > sound/soc/sof/ipc3-dtrace.c | 2 +-
> > sound/soc/sof/ipc4-loader.c | 2 +-
> > sound/soc/sof/pcm.c | 2 +-
> > sound/soc/sof/sof-client-ipc-flood-test.c | 2 +-
> > .../soc/sof/sof-client-ipc-kernel-injector.c | 2 +-
> > sound/soc/sof/sof-client-ipc-msg-injector.c | 2 +-
> > sound/soc/sof/sof-client-probes.c | 6 +-
> > sound/x86/intel_hdmi_audio.c | 6 +-
> > 373 files changed, 1076 insertions(+), 1076 deletions(-)
--
Regards,
Laurent Pinchart
1 - 100 of 1983 matches
Mail list logo
