On Tue, Apr 20, 2021 at 05:19:52PM +0200, Neil Armstrong wrote:
> On 20/04/2021 17:13, Hans Verkuil wrote:
> > On 16/04/2021 13:38, Neil Armstrong wrote:
> >> On 16/04/2021 11:58, Laurent Pinchart wrote:
> >>> Hi Neil,
> >>>
> >>> On Fri,
Hi Jacopo,
On Fri, Apr 16, 2021 at 09:43:07AM +0200, Jacopo Mondi wrote:
> On Thu, Apr 15, 2021 at 10:14:05PM +0300, Laurent Pinchart wrote:
> > > > > + /* GPIO values default to high */
> > > > > + priv->gpio_state =
in() instead
>
> Cc: Hyun Kwon
> Cc: Laurent Pinchart
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Michal Simek
> Cc: Philipp Zabel
> Cc: dri-de...@lists.freedesktop.org
> Cc: linux-arm-ker...@lists.infradead.org
> Signed-off-by: Lee Jones
Reviewed-by: Laurent
isp_layer_id instead
>
> Cc: Hyun Kwon
> Cc: Laurent Pinchart
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Michal Simek
> Cc: dri-de...@lists.freedesktop.org
> Cc: linux-arm-ker...@lists.infradead.org
> Signed-off-by: Lee Jones
Reviewed-by: Laurent Pinchart
> ---
/bridge/synopsys/dw-hdmi.c | 2 +-
> drivers/gpu/drm/meson/meson_dw_hdmi.c | 1 +
> include/drm/bridge/dw_hdmi.h | 2 ++
> 3 files changed, 4 insertions(+), 1 deletion(-)
>
--
Regards,
Laurent Pinchart
ret = max9286_register_gpio(priv);
> + ret = max9286_parse_gpios(priv);
> if (ret)
> goto err_powerdown;
>
> - priv->regulator = devm_regulator_get(>dev, "poc");
> - if (IS_ERR(priv->regulator)) {
> - if (PTR_ERR(priv->regulator) != -EPROBE_DEFER)
> - dev_err(>dev,
> - "Unable to get PoC regulator (%ld)\n",
> - PTR_ERR(priv->regulator));
> - ret = PTR_ERR(priv->regulator);
> - goto err_powerdown;
> - }
> -
> ret = max9286_parse_dt(priv);
> if (ret)
> goto err_powerdown;
> @@ -1326,7 +1393,7 @@ static int max9286_remove(struct i2c_client *client)
>
> max9286_v4l2_unregister(priv);
>
> - regulator_disable(priv->regulator);
> + max9286_poc_enable(priv, false);
>
> gpiod_set_value_cansleep(priv->gpiod_pwdn, 0);
>
--
Regards,
Laurent Pinchart
Hi Jacopo,
On Thu, Apr 15, 2021 at 08:58:48AM +0200, Jacopo Mondi wrote:
> On Thu, Apr 15, 2021 at 03:00:56AM +0300, Laurent Pinchart wrote:
> > On Wed, Apr 14, 2021 at 03:51:25PM +0200, Jacopo Mondi wrote:
> > > The 'maxim,gpio-poc' property is used when the remote camera
>
On Thu, Apr 15, 2021 at 06:47:48PM +0200, Geert Uytterhoeven wrote:
> On Thu, Apr 15, 2021 at 4:47 PM Laurent Pinchart wrote:
> > On Thu, Apr 15, 2021 at 02:25:59PM +0200, Jacopo Mondi wrote:
> > > Declare port@0 in the csi40 device node and leave it un-connected.
> >
the hardware level, so including it here sounds good.
The DT binding even makes the port mandatory :-)
Reviewed-by: Laurent Pinchart
> ---
> arch/arm64/boot/dts/renesas/r8a77970.dtsi | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a7797
y.
>
> Signed-off-by: Jacopo Mondi
Tested by applying and verifying that `git show -b` shows an empty diff.
Reviewed-by: Laurent Pinchart
> ---
> .../bindings/media/i2c/maxim,max9286.yaml | 214 +-
> 1 file changed, 107 insertions(+), 107 deletions(-
Hi Doug,
On Wed, Apr 14, 2021 at 06:19:13PM -0700, Doug Anderson wrote:
> On Sun, Apr 4, 2021 at 5:50 PM Laurent Pinchart wrote:
> > On Fri, Apr 02, 2021 at 03:28:35PM -0700, Douglas Anderson wrote:
> > > The drm_bridge_chain_pre_enable() is not t
Hi Doug,
On Wed, Apr 14, 2021 at 06:22:57PM -0700, Doug Anderson wrote:
> On Wed, Apr 14, 2021 at 5:58 PM Laurent Pinchart wrote:
> > On Fri, Apr 02, 2021 at 03:28:46PM -0700, Douglas Anderson wrote:
> > > Unpreparing and re-preparing a panel can be a really heavy
>
ehavior selectively.
> - In order for this to work we now have a hard dependency on
> "PM". From memory this is a legit thing to assume these days and we
> don't have to find some fallback to keep working if someone wants to
> build their system without "PM".
So
seems also correct,
> >
> > Right, so I could put the
> > "drm_bridge_chain_pre_enable(>bridge)" into the
> > ti_sn_aux_transfer() function. I talked about that a little bit "after
> > the cut" in my post where I said:
> >
> >> - If everyone loves the "runtime PM" in the panel driver then we
> >> could, in theory, put the pre-enable chaining straight in the "aux
> >> transfer" function.
> >
> > The reason for the dependence on "runtime PM" in the panel driver is
> > that we are doing DDC over AUX and it breaks the EDID reading into
> > lots of chunks so if we did the powering up and powering down there it
> > would be crazy slow without the delayed poweroff.
>
> OK, it resembles to me DSI-controlled panel - to query/configure panel
> panel driver asks DSI-host to transfer some bytes to the panel and/or
> back via DSI-bus.
>
> In case of eDP panels we could do similar thing to read edid - we call
> drm_panel_get_modes - it calls drm_panel_funcs.get_modes callback and it
> decides (based on DT) if it should fill modes according to hardcoded
> info into the driver or to ask the physical panel via DP-controller -
> this way all the players (the panel, AUX/DDC device) will know what to
> power-up.
>
> I guess there is missing pieces - there is no DP bus :), I am not sure
> if there is straight way to access panel's aux/ddc from the panel
> driver, maybe somehow via drm_connector ???
If the SN65DSI86 has to call drm_panel_get_modes(), which will then call
back into the SN65DSI86 driver to perform the EDID read, it seems to me
that the panel driver shouldn't be involved at all.
DRM bridges have "recently" gained new operations to retrieve EDID, and
there's a helper (drm_bridge_connector) that creates a connector for a
chain of bridges, delegating connector operations to the appropriate
bridge in the chain. This seems a better way forward to me (but I'm
biased, as I've authored that code :-)).
> Of course this only my idea - to be discussed with others.
--
Regards,
Laurent Pinchart
configure_i2c(priv, false);
>
> - ret = max9286_register_gpio(priv);
> + ret = max9286_parse_gpios(priv);
> if (ret)
> goto err_powerdown;
>
> - priv->regulator = devm_regulator_get(>dev, "poc");
> - if (IS_ERR(priv->regulator)) {
> - if (PTR_ERR(priv->regulator) != -EPROBE_DEFER)
> - dev_err(>dev,
> - "Unable to get PoC regulator (%ld)\n",
> - PTR_ERR(priv->regulator));
> - ret = PTR_ERR(priv->regulator);
> - goto err_powerdown;
> - }
> -
> ret = max9286_parse_dt(priv);
> if (ret)
> goto err_powerdown;
> @@ -1326,7 +1393,7 @@ static int max9286_remove(struct i2c_client *client)
>
> max9286_v4l2_unregister(priv);
>
> - regulator_disable(priv->regulator);
> + max9286_poc_enable(priv, false);
>
> gpiod_set_value_cansleep(priv->gpiod_pwdn, 0);
>
--
Regards,
Laurent Pinchart
+ port {
> + fakra_con2: endpoint {
> + remote-endpoint =
> <_in2>;
> + };
> + };
> + };
> + };
> +#endif
> +
> +#ifdef EAGLE_USE_CAMERA_3
> + i2c@3 {
> + status = "okay";
> +
> + camera@54 {
> + compatible = EAGLE_CAMERA_MODEL;
> + reg = <0x54>, <0x64>;
> +
> + port {
> + fakra_con3: endpoint {
> + remote-endpoint =
> <_in3>;
> + };
> + };
> + };
> + };
> +#endif
> + };
> +};
> +#endif
--
Regards,
Laurent Pinchart
; status = "okay";
> };
> +
> +/* FAKRA Overlay */
> +#include "eagle-gmsl.dtsi"
--
Regards,
Laurent Pinchart
ncluded
> after these definitions.
>
> Signed-off-by: Kieran Bingham
> Signed-off-by: Jacopo Mondi
Reviewed-by: Laurent Pinchart
> ---
> .../arm64/boot/dts/renesas/r8a77970-eagle.dts | 119 ++
> 1 file changed, 119 insertions(+)
>
> diff --git a/arch/arm64/boo
; + port@4 {
> +reg = <4>;
> + };
> + };
> +
> + i2c-mux {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +};
> + };
> };
It's customary to indent DT examples with 4 spaces. The existing
examples use two spaces, so maybe a patch on top of this would be useful
to increase readability ?
Reviewed-by: Laurent Pinchart
--
Regards,
Laurent Pinchart
tion on the control channel
> more reliable.
>
> Reviewed-by: Kieran Bingham
> Signed-off-by: Jacopo Mondi
Reviewed-by: Laurent Pinchart
> ---
> drivers/media/i2c/rdacm20.c | 14 +-
> 1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/dri
853b3b4b ("media: i2c: Add driver for RDACM21 camera module")
> Signed-off-by: Jacopo Mondi
Reviewed-by: Laurent Pinchart
> ---
> drivers/media/i2c/rdacm21.c | 46 ++---
> 1 file changed, 32 insertions(+), 14 deletions(-)
>
>
subject line,
Reviewed-by: Laurent Pinchart
> ---
> drivers/media/i2c/rdacm21.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/i2c/rdacm21.c b/drivers/media/i2c/rdacm21.c
> index 553e3f03752b..6be8ce130e78 100644
> --- a/drivers/me
about hot plug detection
> >>> events.
> >>
> >> It's implemented in the IRQ handler with the
> >> IT66121_INT_STATUS1_HPD_STATUS event.
> >
> > I didn't even get that far :)
> >
> > Either way, the HPD support should be exposed in drm_bridge_funcs
> > (.hpd_enable, .hpd_disable (and possibly .hpd_notify)) and
> > drm_bridge.ops (DRM_BRIDGE_OP_HPD).
>
> Indeed I forgot these calls in the NO_CONNECTOR implementation...
For new bridges, you should no implement connector creation, only the
DRM_BRIDGE_ATTACH_NO_CONNECTOR case should be supported.
--
Regards,
Laurent Pinchart
33-supply = <_vcn33_wifi_reg>;
> > +vcn18-supply = <_vcn18_reg>;
> > + vrf12-supply = <_vrf12_reg>;
> > +reset-gpios = < 160 1 /* GPIO_ACTIVE_LOW */>;
> > +interrupt-parent = <>;
> > +interrupts = <4 8 /* IRQ_TYPE_LEVEL_LOW */>;
> > +reg = <0x4c>;
> > +
> > +ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + port@0 {
> > +reg = <0>;
> > +it66121_in: endpoint {
> > + bus-width = <12>;
> > + remote-endpoint = <_out>;
> > +};
> > + };
> > +
> > + port@1 {
> > +reg = <1>;
> > +hdmi_conn_out: endpoint {
> > + remote-endpoint = <_conn_in>;
> > +};
> > + };
> > +};
> > + };
> > +};
--
Regards,
Laurent Pinchart
quot;;
> + pinctrl-0 = <_pins_default>;
> +vcn33-supply = <_vcn33_wifi_reg>;
> +vcn18-supply = <_vcn18_reg>;
> +vrf12-supply = <_vrf12_reg>;
> +reset-gpios = < 160 1 /* GPIO_ACTIVE_LOW */>;
You can #inclu
than "VIDEO"
> mode.
> +TNR will be enabled in "VIDEO" mode and bypassed by "STILL" mode. ImgU is
> +running at “VIDEO” mode by default, the user can use v4l2 control
> +V4L2_CID_INTEL_IPU3_MODE (currently defined in
> +drivers/staging/media/ipu3/incl
Hi Aline,
On Mon, Apr 12, 2021 at 10:58:45AM -0300, ascordeiro wrote:
> Em seg, 2021-04-12 às 16:40 +0300, Laurent Pinchart escreveu:
> > While testing on a device isn't a requirement as you can't be expected
> > to have the necessary hardware, changes are expected to be at le
gt; + iss_print_register(iss, HL_IRQENABLE_SET(5));
> + iss_print_register(iss, HL_IRQENABLE_CLR(5));
> + iss_print_register(iss, CTRL);
> + iss_print_register(iss, CLKCTRL);
> + iss_print_register(iss, CLKSTAT);
>
> dev_dbg(iss->dev, "---\n");
> }
--
Regards,
Laurent Pinchart
> + * shall not call drm_bridge_hpd_cb() when a change in the output
>* connection status occurs.
>*
>* This callback is optional and shall only be implemented by bridges
> @@ -878,8 +878,8 @@ void drm_bridge_hpd_enable(struct drm_bridge *bridge,
> enum drm_connector_status status),
> void *data);
> void drm_bridge_hpd_disable(struct drm_bridge *bridge);
> -void drm_bridge_hpd_notify(struct drm_bridge *bridge,
> -enum drm_connector_status status);
> +void drm_bridge_hpd_cb(struct drm_bridge *bridge,
> +enum drm_connector_status status);
>
> #ifdef CONFIG_DRM_PANEL_BRIDGE
> struct drm_bridge *drm_panel_bridge_add(struct drm_panel *panel);
--
Regards,
Laurent Pinchart
t; - Putting an error message in the logs if we fall back.
> - Putting a comment in saying what's going on.
>
> Signed-off-by: Douglas Anderson
Reviewed-by: Laurent Pinchart
> ---
>
> (no changes since v1)
>
> drivers/gpu/drm/bridge/ti-sn65dsi86.c | 7 +++
> 1
're
> in no worse shape than they were before the (fairly recent) commit
> 58074b08c04a ("drm/bridge: ti-sn65dsi86: Read EDID blob over DDC").
>
> Signed-off-by: Douglas Anderson
Reviewed-by: Laurent Pinchart
> ---
>
> (no changes since v1)
>
> drivers/gpu/
on for us
> to call it again.
>
> Signed-off-by: Douglas Anderson
> Reviewed-by: Andrzej Hajda
Reviewed-by: Laurent Pinchart
This looks like a widespread issue, would you be able to send a patch to
address all the other drivers ?
> ---
>
> (no changes since v1)
>
&g
wed-by: Andrzej Hajda
Reviewed-by: Laurent Pinchart
> ---
>
> (no changes since v1)
>
> drivers/gpu/drm/bridge/ti-sn65dsi86.c | 12
> 1 file changed, 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> b/drivers/gpu/drm/
() to make sure things are powered on (and then off again)
> when reading the EDID.
>
> Signed-off-by: Douglas Anderson
> Reviewed-by: Andrzej Hajda
Reviewed-by: Laurent Pinchart
> ---
>
> (no changes since v1)
>
> drivers/gpu/drm/bridge/ti-sn65dsi86.c | 4 ++--
>
ve us closer to
> a proper remove.
>
> Signed-off-by: Douglas Anderson
> Reviewed-by: Andrzej Hajda
Reviewed-by: Laurent Pinchart
> ---
>
> Changes in v3:
> - Removed "NOTES" from commit message.
>
> drivers/gpu/drm/bridge/ti-sn65dsi86.c | 15 ---
Hi Doug,
Thank you for the patch.
On Fri, Apr 02, 2021 at 03:28:37PM -0700, Douglas Anderson wrote:
> A random comment inside a function had "/**" in front of it. That
> doesn't make sense. Remove.
>
> Signed-off-by: Douglas Anderson
> Reviewed-by: Andrzej Hajda
Revi
e)
> list_for_each_entry_reverse(iter, >bridge_chain, chain_node) {
> if (iter->funcs->pre_enable)
> iter->funcs->pre_enable(iter);
> +
> + if (iter == bridge)
> + break;
This looks good as i
/linux/phy/phy-mipi-dphy.h | 13 +
> > 11 files changed, 1754 insertions(+), 70 deletions(-)
> > create mode 100644 Documentation/devicetree/bindings/media/ti,csi2rx.yaml
> > delete mode 100644 Documentation/devicetree/bindings/phy/cdns,dphy.txt
> > create mode 100644 Documentation/devicetree/bindings/phy/cdns,dphy.yaml
> > create mode 100644 drivers/media/platform/ti-vpe/ti-csi2rx.c
--
Regards,
Laurent Pinchart
i2rx->source_subdev, core, s_power, false);
> + if (ret && ret != -ENOIOCTLCMD)
> + dev_warn(csi2rx->dev, "Couldn't power off subdev\n");
> +
> if (csi2rx->dphy) {
> writel(0, csi2rx->base + CSI2RX_DPHY_LANE_CTRL_REG);
>
--
Regards,
Laurent Pinchart
On Fri, Apr 02, 2021 at 01:01:22PM +0300, Laurent Pinchart wrote:
> On Thu, Apr 01, 2021 at 10:52:01AM -0500, Rob Herring wrote:
> > On Tue, Mar 30, 2021 at 11:03:44PM +0530, Pratyush Yadav wrote:
> > > TI's J721E uses the Cadence CSI2RX and DPHY peripherals to facilitate
> &
> + .enum_mbus_code = csi2rx_enum_mbus_code,
> + .get_fmt= csi2rx_get_fmt,
> + .set_fmt= csi2rx_set_fmt,
> + .enum_frame_size = csi2rx_enum_frame_size,
> + .enum_frame_interval = csi2rx_enum_frame_interval,
> };
>
> static const struct v4l2_subdev_ops csi2rx_subdev_ops = {
> .video = _video_ops,
> + .pad= _pad_ops,
> };
>
> static int csi2rx_async_bound(struct v4l2_async_notifier *notifier,
--
Regards,
Laurent Pinchart
+ }
> +
> + return 0;
> +}
> +
> static const struct phy_ops cdns_dphy_ops = {
> .configure = cdns_dphy_configure,
> .validate = cdns_dphy_validate,
> .power_on = cdns_dphy_power_on,
> .power_off = cdns_dphy_power_off,
> + .set_mode = cdns_dphy_set_mode,
> };
>
> static int cdns_dphy_probe(struct platform_device *pdev)
--
Regards,
Laurent Pinchart
cdns,dphy.yaml
> +++ b/Documentation/devicetree/bindings/phy/cdns,dphy.yaml
> @@ -30,6 +30,9 @@ properties:
>"#phy-cells":
> const: 0
>
> + power-domains:
> +maxItems: 1
> +
Would it be useful to add power-domains to the example ?
Reviewed-by: Lau
ot;#phy-cells"
>
> additionalProperties: false
--
Regards,
Laurent Pinchart
- reg
> + - clocks
> + - clock-names
> + - "#phy-cells"
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +
> +dphy0: dphy@fd0e{
This is copied verbatim from the existing description, but while at it,
I'd rename the node from dphy
, to show how it's supposed to be used.
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - dmas
> > + - dma-names
> > + - power-domains
> > + - "#address-cells"
> > + - "#size-cells"
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > +#include
> > +
> > +ti_csi2rx0: ticsi2rx {
> > +compatible = "ti,csi2rx";
> > +dmas = <_udmap 0x4940>;
> > +dma-names = "rx0";
> > +reg = <0x0 0x450 0x0 0x1000>;
> > +power-domains = <_pds 26 TI_SCI_PD_EXCLUSIVE>;
> > +#address-cells = <2>;
> > +#size-cells = <2>;
> > +};
--
Regards,
Laurent Pinchart
On Fri, Apr 02, 2021 at 12:01:35PM +0300, Laurent Pinchart wrote:
> Hi Mauro,
>
> Thank you for the patch.
>
> On Thu, Apr 01, 2021 at 02:17:44PM +0200, Mauro Carvalho Chehab wrote:
> > The file name: Documentation/devicetree/bindings/media/i2c/rdacm2x-gmsl.yaml
&
uot;)
> Signed-off-by: Mauro Carvalho Chehab
> ---
> MAINTAINERS | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 1644b6e9697c..b405ee71f730 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -15258,7 +15258,
.atomic_check()"
> interface to detect Content Protection property change.
> (https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2674580)
Please note that upstream review happens on mailing lists, not in
gerrit. Internal reviews for Chrome OS development are certainly fine
there, but that will not mean the patch will then be accepted upstream
as-is, it will still need to go through the upstream review process,
without any shortcut. I strongly recommend using an upstream-first
strategy, with public review.
> > > > > +
> > > > > if (ctx->pdata.is_dpi)
> > > > > ret = anx7625_dpi_config(ctx);
> > > > > else
> >
> > /snip
--
Regards,
Laurent Pinchart
n the name. E.g. the DSS on J7 is
> > "ti,j721e-dss".
> >
> > This driver implements the legacy video API. I think it would be better
> > (and easier to maintain) to only implement the media-controller API,
> > unless you specifically need to support the legacy API for existing
> > userspace.
>
> We just went through a major rework with CAL to make it media controller
> compatible in order to be able to handle CSI2 virtual channels.
> I think as this is a new driver/IP which perform the same type of service
> it makes sense to make use the more current API instead of the legacy one.
+2 :-)
--
Regards,
Laurent Pinchart
Hi Krzysztof,
On Tue, Mar 30, 2021 at 11:17:54AM +0200, Krzysztof Hałasa wrote:
> Laurent Pinchart writes:
>
> >> + reg:
> >> +description: I2C bus address of the sensor device
> >
> > You can drop this, it's implicit for I2C devices.
>
>
Hi Doug,
On Mon, Mar 29, 2021 at 07:57:05PM -0700, Doug Anderson wrote:
> On Tue, Mar 16, 2021 at 5:44 PM Doug Anderson wrote:
> > On Tue, Mar 16, 2021 at 2:46 PM Laurent Pinchart wrote:
> > > On Mon, Mar 15, 2021 at 09:25:37AM -0700, Doug Anderson wrote:
> > > > O
n... :-)
Reviewed-by: Laurent Pinchart
But you need to make sure this patch will get backported to stable along
2/3, probably by adding a fixes tag. Or squashing it with 2/3, up to
you.
> ---
> drivers/gpu/drm/mediatek/mtk_hdmi.c | 19 ++-
> 1 file changed, 14 insertions(+), 5 d
s = {
> + .mode_valid = mtk_hdmi_bridge_mode_valid,
> .atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
> .atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
> .atomic_reset = drm_atomic_helper_bridge_reset,
> @@ -1454,6 +1408,8
l
> not have direct access to the connector.
> The atomic version '.atomic_enable' allows accessing the
> current connector from the state.
> This patch switches the bridge to the atomic version to
> prepare access to the connector in later patches.
>
> Signed-off-by: Dafna Hirschfel
Hi Hans,
On Sat, Mar 27, 2021 at 11:05:01AM +0100, Hans Verkuil wrote:
> On 21/10/2020 23:43, Laurent Pinchart wrote:
> > On Wed, Oct 21, 2020 at 02:53:27PM +0100, Fabrizio Castro wrote:
> >> Dear All,
> >>
> >> this series is to add DRIF support for the r8a779
gt; . Since it's not "simple" anymore it
> will now take funcs/name arguments as well.
>
> Signed-off-by: Paul Cercueil
Reviewed-by: Laurent Pinchart
> ---
> include/drm/drm_encoder.h | 18 ++
> 1 file changed, 18 insertions(+)
>
> dif
Hi Wan,
Thank you for the patch.
On Thu, Mar 25, 2021 at 07:10:24PM +0800, Wan Jiabing wrote:
> struct dss_device has been declared. Remove the duplicate.
> And sort these forward declarations alphabetically.
>
> Signed-off-by: Wan Jiabing
Reviewed-by: Laurent Pinchart
Tomi, I a
,8 @@ struct v4l2_plane {
> * @m: union of @offset, @userptr, @planes and @fd
> * @length: size in bytes of the buffer (NOT its payload) for single-plane
> * buffers (when type != *_MPLANE); number of elements in the
> - * planes array for multi-plane buffers
> + * planes array for multi-plane buffers. Filled by userspace for
> + * USERPTR and by the driver for DMABUF and MMAP.
> * @reserved2: drivers and applications must zero this field
> * @request_fd: fd of the request that this buffer should use
> * @reserved:for backwards compatibility with applications that do
> not know
--
Regards,
Laurent Pinchart
uct dss_device;
> struct omap_drm_private;
> struct omap_dss_device;
> struct dispc_device;
> -struct dss_device;
> struct dss_lcd_mgr_config;
> struct snd_aes_iec958;
> struct snd_cea_861_aud_if;
While at it, could you sort these forward declarations alphabetically,
so that duplicates are easier to see ?
--
Regards,
Laurent Pinchart
ocumented bindings, but
> doing so would just duplicate other examples. So let's just remove the
> example.
>
> Cc: Mauro Carvalho Chehab
> Cc: Sakari Ailus
> Cc: Laurent Pinchart
> Cc: linux-me...@vger.kernel.org
> Signed-off-by: Rob Herring
Reviewed-by: Laurent Pi
Hi Bhaskar,
Thank you for the patch.
On Wed, Mar 24, 2021 at 06:51:00PM +0530, Bhaskar Chowdhury wrote:
>
> s/cariers/carriers/
>
> Signed-off-by: Bhaskar Chowdhury
Reviewed-by: Laurent Pinchart
> ---
> include/media/media-entity.h | 2 +-
> 1 file changed, 1 ins
Hi Rob,
On Wed, Mar 24, 2021 at 11:20:19AM +0100, Robert Foss wrote:
> Add myself as co-maintainer of DRM Bridge Drivers. Repository
> commit access has already been granted.
>
> https://gitlab.freedesktop.org/freedesktop/freedesktop/-/issues/338
>
> Cc: Neil Armstrong
>
Hi Jagan,
On Wed, Mar 24, 2021 at 03:19:10PM +0530, Jagan Teki wrote:
> On Wed, Mar 24, 2021 at 3:09 PM Laurent Pinchart wrote:
> > On Wed, Mar 24, 2021 at 02:44:57PM +0530, Jagan Teki wrote:
> > > On Wed, Mar 24, 2021 at 8:18 AM Samuel Holland wrote:
> > > > On 3/2
On Wed, Mar 24, 2021 at 10:39:52AM +0100, Daniel Vetter wrote:
> On Wed, Mar 24, 2021 at 04:15:37AM +0200, Laurent Pinchart wrote:
> > On Wed, Jan 20, 2021 at 06:38:03PM +0100, Daniel Vetter wrote:
> > > On Wed, Jan 20, 2021 at 6:12 PM Paul Cercueil wrote:
> > > >
Hi Jagan,
On Wed, Mar 24, 2021 at 02:44:57PM +0530, Jagan Teki wrote:
> On Wed, Mar 24, 2021 at 8:18 AM Samuel Holland wrote:
> > On 3/23/21 5:53 PM, Laurent Pinchart wrote:
> > > On Mon, Mar 22, 2021 at 07:31:49PM +0530, Jagan Teki wrote:
> > >
e any read/write operation to it
> will fix this issue. And for symmetry, move zynqmp_dp_reset() call from
> zynqmp_dp_phy_exit() to zynqmp_dp_remove().
>
> Signed-off-by: Quanyang Wang
Reviewed-by: Laurent Pinchart
> ---
>
> V2:
> According to Laurent's
is absent we'll be wasting power
> powering hpd when we don't use it on trogdor boards. We didn't notice
> this before because the kernel driver blindly disables hpd, but that
> won't be true for much longer.
>
> Cc: Laurent Pinchart
> Cc: Douglas Anderson
> Fixes: 7ec3e6730
adds code to handle the
> same.
>
> Signed-off-by: Manish Narani
This looks good to me.
Reviewed-by: Laurent Pinchart
However, it would be really nice to make clock handling dynamic, to only
enable clocks that are needed by active PHYs. Keeping them enabled at
all times will waste pow
ic: Add support for OSD mode")
> Cc: # v5.8+
> Signed-off-by: Paul Cercueil
> Acked-by: Daniel Vetter
I don't have much knowledge about this platform, but the change looks
reasonable to me.
Acked-by: Laurent Pinchart
> ---
> drivers/gpu/drm/ingenic/ingenic-drm-drv.c
lain_simple_encoder_alloc()
> >> drm/ingenic: Register devm action to cleanup encoders
> >> drm/ingenic: Fix non-OSD mode
> >>
> >> drivers/gpu/drm/bridge/panel.c| 12 +++
> >> drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 26 +++
> >> include/drm/drm_simple_kms_helper.h | 17 +++
> >> 3 files changed, 42 insertions(+), 13 deletions(-)
> >>
--
Regards,
Laurent Pinchart
+
> Signed-off-by: Paul Cercueil
Reviewed-by: Laurent Pinchart
> ---
>
> Notes:
> Use the V1 of this patch to fix v5.11 and older kernels. This V3 only
> applies on the current drm-misc-next branch.
>
> drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 15 ++-
he simple KMS helper
won't have to select it just for this.
> #endif /* __LINUX_DRM_SIMPLE_KMS_HELPER_H */
--
Regards,
Laurent Pinchart
y if it was created
>
> v3: Add FIXME
>
> Fixes: 13dfc0540a57 ("drm/bridge: Refactor out the panel wrapper from the
> lvds-encoder bridge.")
> Cc: # 4.12+
> Cc: Andrzej Hajda
> Cc: Neil Armstrong
> Cc: Laurent Pinchart
> Cc: Jonas Karlman
> Cc: Je
ssues is
probably fine, as yak-shaving in this area would definitely not be
reasonable.
> > >> v2: Cleanup connector only if it was created
> > >>
> > >> Fixes: 13dfc0540a57 ("drm/bridge: Refactor out the panel wrapper from
> > >> the lvds-encoder b
4
>
> struct sun6i_dsi {
> + struct drm_bridge bridge;
> struct drm_connectorconnector;
> struct drm_encoder encoder;
The drm_encoder should be dropped from this driver, the encoder should
be created by the main display driver.
> struct mipi_dsi_hosthost;
> @@ -38,6 +39,11 @@ static inline struct sun6i_dsi *host_to_sun6i_dsi(struct
> mipi_dsi_host *host)
> return container_of(host, struct sun6i_dsi, host);
> };
>
> +static inline struct sun6i_dsi *bridge_to_sun6i_dsi(struct drm_bridge
> *bridge)
> +{
> + return container_of(bridge, struct sun6i_dsi, bridge);
> +}
> +
> static inline struct sun6i_dsi *connector_to_sun6i_dsi(struct drm_connector
> *connector)
> {
> return container_of(connector, struct sun6i_dsi, connector);
--
Regards,
Laurent Pinchart
;
> static const struct component_ops sun6i_dsi_ops = {
> diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
> b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
> index c863900ae3b4..370ecb356a63 100644
> --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
> +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
> @@ -29,8 +29,8 @@ struct sun6i_dsi {
>
> struct device *dev;
> struct mipi_dsi_device *device;
> - struct drm_device *drm;
> struct drm_panel*panel;
> + struct drm_bridge *panel_bridge;
> };
>
> static inline struct sun6i_dsi *host_to_sun6i_dsi(struct mipi_dsi_host *host)
--
Regards,
Laurent Pinchart
me will replace with bridge
> parameter once bridge supported.
>
> Signed-off-by: Jagan Teki
Looks good, there should be no functional change.
Reviewed-by: Laurent Pinchart
> ---
> Changes for v4, v3:
> - none
>
> drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 11 --
Hi Doug,
On Tue, Mar 23, 2021 at 12:07:27PM -0700, Doug Anderson wrote:
> On Mon, Mar 22, 2021 at 8:17 PM Stephen Boyd wrote:
> >
> > Quoting Laurent Pinchart (2021-03-17 17:20:43)
> > > Hi Stephen,
> > >
> > > Reviving a bit of an old thread, for a
d neither does
display-connector.c, so that may be what we should start with.
> I see that td_mode_valid() in
> drivers/gpu/drm/bridge/tc358775.c stores away the bpc from the incoming
> drm_display_info pointer but I'm not sure that is correct because can't
> that be called for various and not necessarily the one we're using?
You're right, .mode_valid() shouldn't do that.
--
Regards,
Laurent Pinchart
dress-cells = <1>;
> #size-cells = <0>;
> @@ -81,6 +135,8 @@ examples:
> reg = <0>;
> anx7625_in: endpoint {
> remote-endpoint = <_dsi>;
> +bus-type = <5>;
> +data-lanes = <0 1 2 3>;
> };
> };
>
--
Regards,
Laurent Pinchart
ne:
/*
* Don't skip enabling clock if there is an IOCTL_SET_PLL_FRAC_MODE
* request that has been sent to ATF.
*/
> + if (zynqmp_pll_is_enabled(hw) && (!clk->set_pll_mode))
> return 0;
>
> + clk->set_pll_mode
call zynqmp_dp_reset(dp, true) here ? Or rather, call
it in the error path at the end of the function, with a goto label.
For symmetry, should we also move the zynqmp_dp_reset() call from
zynqmp_dp_phy_exit() to zynqmp_dp_remove() ?
--
Regards,
Laurent Pinchart
timeout
> characterized in the chip manual.
>
> Reviewed-by: Kieran Bingham
> Reviewed-by: Laurent Pinchart
> Signed-off-by: Jacopo Mondi
> ---
> drivers/media/i2c/rdacm20.c | 29 +
> 1 file changed, 17 insertions(+), 12 deletions(-)
>
> di
plemented with a label and a goto.
>
> Replace it with a more compact for() loop.
>
> No functional changes intended.
>
> Reviewed-by: Kieran Bingham
> Reviewed-by: Laurent Pinchart
> Signed-off-by: Jacopo Mondi
> ---
> drivers/media/i2c/rdacm20.c | 29
tion on the control channel
> more reliable.
>
> Reviewed-by: Kieran Bingham
> Signed-off-by: Jacopo Mondi
Reviewed-by: Laurent Pinchart
> ---
> drivers/media/i2c/rdacm20.c | 14 +-
> 1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/dri
ENODEV;
> }
> @@ -359,6 +375,8 @@ static int ov490_initialize(struct rdacm21_device *dev)
> unsigned int i;
> int ret;
>
> + ov10640_power_up(dev);
On top of this series, error handling of OV490 writes would make sense.
> +
> /*
>* Read OV490 Id to test communications. Give it up to 40msec to
>* exit from reset.
> @@ -396,7 +414,7 @@ static int ov490_initialize(struct rdacm21_device *dev)
> return -ENODEV;
> }
>
> - ret = ov10640_initialize(dev);
> + ret = ov10640_check_id(dev);
> if (ret)
> return ret;
>
--
Regards,
Laurent Pinchart
> Perhaps possible to update the comment a little, but nothing that matters.
The commit message and comment should match the code, especially given
that I'm not sure here which of the two is actually incorrect. I suspect
the sleep is actually in the wrong location.
> Reviewed-by: Kieran Bingham
>
>
> > ret = max9271_configure_gmsl_link(>serializer);
> > if (ret)
> >
--
Regards,
Laurent Pinchart
call subdev init()
>|>|
> init() {
> access camera registers()
> }
>|<---
> }
>
&
ould be considered to allow the devices along the pipeline to
> + * probe and register in the media graph and to defer any operation that
> + * require actual access to the communication bus to their init() function
> + * implementation.
> *
> * @load_fw: load firmware.
> *
--
Regards,
Laurent Pinchart
get_new_plane_state(state,
>
> plane);
> struct drm_crtc *crtc = new_state->crtc;
--
Regards,
Laurent Pinchart
uot;);
> - return PTR_ERR(phy);
> + ret = PTR_ERR(phy);
> + goto err_clk_put;
> }
>
> gtr_phy->phy = phy;
> @@ -962,9 +998,16 @@ static int xpsgtr_probe(struct platform_device *pdev)
> provider = devm_of_phy_provider_register(>dev, xpsgtr_xlate);
> if (IS_ERR(provider)) {
> dev_err(>dev, "registering provider failed\n");
> - return PTR_ERR(provider);
> + ret = PTR_ERR(provider);
> + goto err_clk_put;
> }
> return 0;
> +
> +err_clk_put:
> + for (i = 0; i < ARRAY_SIZE(gtr_dev->clk); i++)
> + clk_disable_unprepare(gtr_dev->clk[i]);
> +
> + return ret;
> }
>
> static const struct of_device_id xpsgtr_of_match[] = {
--
Regards,
Laurent Pinchart
0x8080300a
> > > #define OV490_VER0x8080300b
> > > #define OV490_PID_TIMEOUT20
> > > -#define OV490_OUTPUT_EN_TIMEOUT 300
> > > +#define OV490_OUTPUT_EN_TIMEOUT 600
> > >
> > > #define OV490_GPIO0 BIT(0)
> > > #define OV490_SPWDN0 BIT(0)
--
Regards,
Laurent Pinchart
om schema:
Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml
This is caused by the fact that reg-names is correctly limited to two
elements, but then expects the second element to be "j721e-intg". The
example is good, so it's the bindings that need to be fixed.
> clocks = <_clock>;
> phys = <_phy>;
> phy-names = "dpphy";
--
Regards,
Laurent Pinchart
k.
>
> To be on the safe side, always clear the entire ioctl buffer before
> calling the conversion handler functions that are meant to initialize
> them.
>
> Signed-off-by: Arnd Bergmann
Reviewed-by: Laurent Pinchart
> ---
> drivers/media/v4l2-core/v4l2-ioctl.c |
Tested-by: Hans Verkuil
> Signed-off-by: Arnd Bergmann
v4l2_event vs. v4l2_event32 vs. v4l2_event_time32 vs.
v4l2_event32_time32 is a bit confusing. Do I understand correctly that
the code below runs for the non-compat path, thus native userspace
(32-bit on 32-bit machines, 64-bit on 64-bit ma
> Reviewed-by: Laurent Pinchart
> Cc: Jonas Karlman
> Cc: Jernej Skrabec
> Cc: Sean Paul
> Acked-by: Sam Ravnborg
> Signed-off-by: Stephen Boyd
> ---
> drivers/gpu/drm/bridge/ti-sn65dsi86.c | 20
> 1 file changed, 20 insertions(+)
>
> diff --git
Hi Jacopo,
On Wed, Mar 17, 2021 at 11:14:12AM +0100, Jacopo Mondi wrote:
> On Tue, Mar 16, 2021 at 12:15:16AM +0200, Laurent Pinchart wrote:
> > On Mon, Mar 15, 2021 at 05:30:25PM +0100, Jacopo Mondi wrote:
> > > The MAX9286 GMSL deserializer features gpio contr
Hi Doug,
On Mon, Mar 15, 2021 at 09:25:37AM -0700, Doug Anderson wrote:
> On Sat, Mar 13, 2021 at 1:17 PM Laurent Pinchart wrote:
> > On Thu, Mar 04, 2021 at 03:52:01PM -0800, Douglas Anderson wrote:
> > > In commit 58074b08c04a ("drm/bridge: ti-sn65dsi86: Read EDID b
Hi Rob,
On Tue, Mar 16, 2021 at 03:09:10PM -0600, Rob Herring wrote:
> On Tue, Mar 16, 2021 at 2:48 PM Laurent Pinchart wrote:
> > On Tue, Mar 16, 2021 at 01:51:00PM -0600, Rob Herring wrote:
> > > The example in video-interfaces.yaml managed to use a bunch of
> > >
1 - 100 of 4490 matches
Mail list logo
