Hi Kieran,
On Wed, Apr 24, 2019 at 09:15:22AM +0100, Kieran Bingham wrote:
> On 06/03/2019 23:23, Laurent Pinchart wrote:
> > The DRM_BUS_FLAG_PIXDATA_(POS|NEG)EDGE and
> > DRM_BUS_FLAG_SYNC_(POS|NEG)EDGE flags are deprecated in favour of the
> > new DRM_BUS_FLAG_PIXDATA_(D
k board. I expect them
to work on E3 as well, but I don't have access to an Ebisu board to test
this.
Laurent Pinchart (10):
drm: bridge: Add dual_link field to the drm_bridge_timings structure
dt-bindings: display: bridge: thc63lvd1024: Document dual-link
operation
drm: bridge: thc6
The THC63LVD1024 LVDS decoder can operate in two modes, single-link or
dual-link. In dual-link mode both input ports are used to carry even-
and odd-numbered pixels separately. Document this in the DT bindings,
along with the related rules governing port and usage.
Signed-off-by: Laurent Pinchart
Enable and connect the second LVDS encoder to the second LVDS input of
the THC63LVD1024 for dual-link LVDS operation. This requires changing
the default settings of SW45 and SW47 to OFF and ON respectively.
Signed-off-by: Laurent Pinchart
---
.../arm64/boot/dts/renesas/r8a77995-draak.dts | 21
the
pipeline, locate the companion encoder, and control it directly through
its bridge operations.
Signed-off-by: Laurent Pinchart
Reviewed-by: Jacopo Mondi
---
drivers/gpu/drm/rcar-du/rcar_lvds.c | 104
drivers/gpu/drm/rcar-du/rcar_lvds.h | 5 ++
2 files changed
Add the new renesas,companion property to the LVDS0 node to point to the
companion LVDS encoder LVDS1.
Signed-off-by: Laurent Pinchart
---
arch/arm64/boot/dts/renesas/r8a77990.dtsi | 2 ++
arch/arm64/boot/dts/renesas/r8a77995.dtsi | 2 ++
2 files changed, 4 insertions(+)
diff --git a/arch
only
describes the relationship between the master and companion LVDS
encoders.
Signed-off-by: Laurent Pinchart
---
Changes since v1:
- Fixed typo
---
.../devicetree/bindings/display/bridge/renesas,lvds.txt | 6 ++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devic
this indicates that even-
+* and odd-numbered pixels are received on separate links.
+*/
+ bool dual_link;
};
/**
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/ma
Enable and connect the second LVDS encoder to the second LVDS input of
the THC63LVD1024 for dual-link LVDS operation. This requires changing
the default settings of SW45 and SW47 to OFF and ON respectively.
Signed-off-by: Laurent Pinchart
---
.../arm64/boot/dts/renesas/r8a77990-ebisu.dts | 21
Set a drm_bridge_timings in the drm_bridge, and use it to report the
input bus mode (single-link or dual-link). The other fields of the
timings structure are kept to 0 as they do not apply to LVDS buses.
Signed-off-by: Laurent Pinchart
---
Changes since v1:
- Ignore disabled remote device
In dual-link LVDS mode, the LVDS1 encoder is used as a companion for
LVDS0, and both encoders transmit data from DU0. The LVDS1 output of DU1
can't be used in that case, don't create an encoder and connector for
it.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du
The DRM core and DU driver guarantee that the LVDS bridge will not be
double-enabled or double-disabled. Remove the corresponding unnecessary
checks.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_lvds.c | 19 ---
1 file changed, 19 deletions(-)
diff --git a
Hi Geert,
On Sun, May 12, 2019 at 10:55:20AM +0200, Geert Uytterhoeven wrote:
> On Sat, May 11, 2019 at 11:07 PM Laurent Pinchart wrote:
> > On the receiving side, the THC63LVD1024 LVDS-to-parallel bridge has two
> > LVDS inputs and two parallel outputs. It can operate in four diff
Hi Geert,
On Sun, May 12, 2019 at 10:58:54AM +0200, Geert Uytterhoeven wrote:
> On Sat, May 11, 2019 at 11:07 PM Laurent Pinchart wrote:
> > The THC63LVD1024 LVDS decoder can operate in two modes, single-link or
> > dual-link. In dual-link mode both input ports are used to carry ev
If a mode set is in progress we can be called with the CRTC disabled.
> - * We thus need to first get and setup the CRTC in order to configure
> - * planes. We must *not* put the CRTC in .atomic_flush(), as it must be
> - * kept awake until the .atomic_enab
you have to introduce another operation in-between. I would explain
this in the commit message.
> + }
> +
> + return 0;
As this function and the next one are called in a context that can never
fail, and as the functions never return a failure, I would make them
void.
Reviewed-by
ven if it should work. How about writing it as
#define for_each_rcdu_group(__rcdu, __group, __i) \
for ((__i) = 0, (__group) = &(__rcdu)->groups[0]; \
(__i) < DIV_ROUND_UP((__rcdu)->num_crtcs, 2); \
__i++, __group++)
Apart f
e have more than one CRTC in this group pre-associate
> + * the low-order planes with CRTC 0 and the high-order planes
> + * with CRTC 1 to minimize flicker occurring when the
> + * association is changed.
> + */
> + rgrp->dptsr_planes = rgrp->num_crtcs > 1
> +
pstate, i) {
> + struct rcar_du_group *rgrp = to_rcar_group(obj);
> + struct rcar_du_group_state *old_state, *new_state;
> +
> + old_state = to_rcar_group_state(old_pstate);
> + new_state = to_rcar_group_s
Hi Sean,
In the subject line, s/-/)/
On Wed, May 08, 2019 at 06:33:27PM +0200, Daniel Vetter wrote:
> On Wed, May 08, 2019 at 12:09:07PM -0400, Sean Paul wrote:
> > From: Laurent Pinchart
> >
> > Add functions to the atomic core to retrieve the old and new connectors
&
hich tree is this against ? The patch applies on neither drm-next nor
drm-misc-next.
While at it, could you you reorder the other header alphabetically to
make this kind of issue easier to notice ?
>
> struct panel_bridge {
> struct drm_bridge bridge;
--
Regards,
Laurent Pin
hdmi = dev_get_drvdata(dev);
> +
> + return dw_hdmi_resume(hdmi->hdmi);
> +}
> +
> +const struct dev_pm_ops dw_hdmi_rockchip_pm = {
Missing static keyword ?
Apart from this,
Reviewed-by: Laurent Pinchart
> + SET_SYSTEM_SLEEP_PM_OPS(dw_hdmi_rockchip_suspend,
>
vice *pdev,
>struct drm_encoder *encoder,
>const struct dw_hdmi_plat_data *plat_data);
>
> +int dw_hdmi_suspend(struct dw_hdmi *hdmi);
> +int dw_hdmi_resume(struct dw_hdmi *hdmi);
> +
> void dw_hdmi_setup_rx_se
Hi Sean,
On Mon, May 13, 2019 at 10:38:58AM -0400, Sean Paul wrote:
> On Sat, May 11, 2019 at 3:12 PM Laurent Pinchart wrote:
> > On Thu, May 02, 2019 at 03:49:46PM -0400, Sean Paul wrote:
> >> From: Sean Paul
> >>
> >> Everyone who implements connecto
Hi Daniel,
On Mon, May 13, 2019 at 04:47:47PM +0200, Daniel Vetter wrote:
> On Sat, May 11, 2019 at 10:12:02PM +0300, Laurent Pinchart wrote:
> > On Thu, May 02, 2019 at 03:49:46PM -0400, Sean Paul wrote:
> >> From: Sean Paul
> >>
> >> Everyone w
Hi Sabyasachi,
On Thu, May 16, 2019 at 06:45:04PM +0530, Sabyasachi Gupta wrote:
> On Tue, May 14, 2019 at 1:05 PM Laurent Pinchart wrote:
> > On Tue, May 14, 2019 at 01:01:41PM +0530, Sabyasachi Gupta wrote:
> > > Remove drm/drm_panel.h which is included more than once
> &g
Hello Sabyasachi,
Thank you for the patch.
On Thu, May 16, 2019 at 08:55:56PM +0530, Sabyasachi Gupta wrote:
> Remove duplicate header which is included twice
>
> Signed-off-by: Sabyasachi Gupta
Reviewed-by: Laurent Pinchart
> ---
> v2: rebased the code against drm -next a
> it is not included in the object file itself leading to compiler
> warnings for missing prototypes.
>
> Include the header as appropriate.
>
> Signed-off-by: Kieran Bingham
Reviewed-by: Laurent Pinchart
And applied to my tree.
> ---
> drivers/gpu/drm/rcar-du
t; Include the header as appropriate.
> >
> > Signed-off-by: Kieran Bingham
> [...]
>
> MBR, Sergei
--
Regards,
Laurent Pinchart
he most general files first
> - Sort individual blocks of include files
>
> Signed-off-by: Sam Ravnborg
> Cc: Andrzej Hajda
> Cc: Laurent Pinchart
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Peter Senna Tschudin
> Cc: Martin Donnelly
> Cc: Martyn Welch
> --
> Cc: Andrzej Hajda
> Cc: Laurent Pinchart
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Peter Senna Tschudin
> Cc: Martin Donnelly
> Cc: Martyn Welch
> ---
> include/drm/bridge/dw_mipi_dsi.h | 8
> 1 file changed, 8 insertions(+)
>
> diff --git
f include files
> - Remove duplicated header file
>
> v2:
> - Be consistent in the order of the include blocks (Laurent)
>
> Signed-off-by: Sam Ravnborg
> Cc: Andrzej Hajda
> Cc: Laurent Pinchart
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Peter Senna Tsc
value bits 7:0 of the G or Y component
> > + * DB[5]: CRC value bits 15:8 of the G or Y component
> > + * DB[6]: CRC value bits 7:0 of the B or Cb component
> > + * DB[7]: CRC value bits 15:8 of the B or Cb component
> > + * DB[8] - DB[31]: Reserved
> > + * VSC SDP Pay
ed-off-by: Icenowy Zheng
> Signed-off-by: Vasily Khoruzhick
> Reviewed-by: Rob Herring
> Signed-off-by: Torsten Duwe
Reviewed-by: Laurent Pinchart
> ---
> .../bindings/display/bridge/anx6345.txt | 56 +++
> 1 file changed, 56 insertions(+)
> create mod
;edid);
mutex_cleanup(&anx6345->lock);
> +
> + return 0;
> +}
> +
> +static const struct i2c_device_id anx6345_id[] = {
> + { "anx6345", 0 },
> + { /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(i2c, anx6345_id);
> +
> +st
ht(c) 2017 Icenowy Zheng
> > + *
> > + * Based on analogix-anx78xx.c, which is:
> > + * Copyright(c) 2016, Analogix Semiconductor. All rights reserved.
>
> If this was simple code movement, then the original copyright still applies.
> A different copyright notice should not be used. I suppose the same applies
> to the module author.
And likely to patch 2/6 too.
--
Regards,
Laurent Pinchart
turn err;
> +
> + err = anx_aux_wait(map_dptx);
> + if (err)
> + return err;
> +
> + msg->reply = DP_AUX_I2C_REPLY_ACK;
> +
> + if ((msg->size > 0) && (msg->request & DP_AUX_I2C_READ)) {
> + /* Read values from data buffer */
> + err = regmap_bulk_read(map_dptx,
> +SP_DP_BUF_DATA0_REG, buffer,
> +msg->size);
> + if (err)
> + return err;
> + }
> +
> + err = anx_clear_bits(map_dptx, SP_DP_AUX_CH_CTRL2_REG, SP_ADDR_ONLY);
> + if (err)
> + return err;
> +
> + return msg->size;
> +}
> +EXPORT_SYMBOL(anx_aux_transfer);
As the code license is GPL and the analogic DP core core is exported
with EXPORT_SYMBOL_GPL, should it be the case here too ?
> +
> +MODULE_DESCRIPTION("Analogix DisplayPort Transmitter common code");
> +MODULE_AUTHOR("Icenowy Zheng ");
> +MODULE_LICENSE("GPL v2");
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h
> b/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h
> index bc0831b127bf..c2ca854613a0 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h
> +++ b/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h
> @@ -245,4 +245,6 @@
> /* DP AUX Buffer Data Registers */
> #define SP_DP_BUF_DATA0_REG 0xf0
>
> +ssize_t anx_aux_transfer(struct regmap *map_dptx, struct drm_dp_aux_msg
> *msg);
The name is a bit generic, should it be anx_dp_aux_transfer() ?
> +
> #endif
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Hi Jacopo,
On Tue, May 28, 2019 at 11:28:47AM +0200, Jacopo Mondi wrote:
> On Sun, May 12, 2019 at 12:06:56AM +0300, Laurent Pinchart wrote:
> > Add a new optional renesas,companion property to point to the companion
> > LVDS encoder. This is used to support dual-link operation
Hi Jacopo,
On Tue, May 28, 2019 at 11:35:50AM +0200, Jacopo Mondi wrote:
> Hi Laurent,
> a small note.
>
> On Sun, May 12, 2019 at 12:06:58AM +0300, Laurent Pinchart wrote:
> > In dual-link mode the LVDS0 encoder transmits even-numbered pixels, and
> > sends odd-numb
k board. I expect them
to work on E3 as well, but I don't have access to an Ebisu board to test
this.
Laurent Pinchart (10):
drm: bridge: Add dual_link field to the drm_bridge_timings structure
dt-bindings: display: bridge: thc63lvd1024: Document dual-link
operation
drm: bridge: thc6
. For LVDS buses, this indicates that even-
+* and odd-numbered pixels are received on separate links.
+*/
+ bool dual_link;
};
/**
--
Regards,
Laurent Pinchart
The THC63LVD1024 LVDS decoder can operate in two modes, single-link or
dual-link. In dual-link mode both input ports are used to carry even-
and odd-numbered pixels separately. Document this in the DT bindings,
along with the related rules governing port and usage.
Signed-off-by: Laurent Pinchart
The DRM core and DU driver guarantee that the LVDS bridge will not be
double-enabled or double-disabled. Remove the corresponding unnecessary
checks.
Signed-off-by: Laurent Pinchart
Reviewed-by: Jacopo Mondi
Tested-by: Jacopo Mondi
---
drivers/gpu/drm/rcar-du/rcar_lvds.c | 19
Add the new renesas,companion property to the LVDS0 node to point to the
companion LVDS encoder LVDS1.
Signed-off-by: Laurent Pinchart
Reviewed-by: Jacopo Mondi
Tested-by: Jacopo Mondi
---
arch/arm64/boot/dts/renesas/r8a77990.dtsi | 2 ++
arch/arm64/boot/dts/renesas/r8a77995.dtsi | 2 ++
2
the
pipeline, locate the companion encoder, and control it directly through
its bridge operations.
Signed-off-by: Laurent Pinchart
Reviewed-by: Jacopo Mondi
Tested-by: Jacopo Mondi
---
Changes since v2:
- Fail probe if the companion controller can't be found or is invalid
---
drivers/gp
Enable and connect the second LVDS encoder to the second LVDS input of
the THC63LVD1024 for dual-link LVDS operation. This requires changing
the default settings of SW45 and SW47 to OFF and ON respectively.
Signed-off-by: Laurent Pinchart
Tested-by: Jacopo Mondi
---
.../arm64/boot/dts/renesas
In dual-link LVDS mode, the LVDS1 encoder is used as a companion for
LVDS0, and both encoders transmit data from DU0. The LVDS1 output of DU1
can't be used in that case, don't create an encoder and connector for
it.
Signed-off-by: Laurent Pinchart
Reviewed-by: Jacopo Mondi
Tested-
only
describes the relationship between the master and companion LVDS
encoders.
Signed-off-by: Laurent Pinchart
Reviewed-by: Jacopo Mondi
Tested-by: Jacopo Mondi
---
Changes since v2:
- Clarify when the companion property is required or not allowed
Changes since v1:
- Fixed
Set a drm_bridge_timings in the drm_bridge, and use it to report the
input bus mode (single-link or dual-link). The other fields of the
timings structure are kept to 0 as they do not apply to LVDS buses.
Signed-off-by: Laurent Pinchart
Reviewed-by: Jacopo Mondi
Tested-by: Jacopo Mondi
Enable and connect the second LVDS encoder to the second LVDS input of
the THC63LVD1024 for dual-link LVDS operation. This requires changing
the default settings of SW45 and SW47 to OFF and ON respectively.
Signed-off-by: Laurent Pinchart
Tested-by: Jacopo Mondi
---
.../arm64/boot/dts/renesas
Hi Sam,
On Tue, May 28, 2019 at 06:37:30PM +0200, Sam Ravnborg wrote:
> On Tue, May 28, 2019 at 05:12:28PM +0300, Laurent Pinchart wrote:
> > Add a new optional renesas,companion property to point to the companion
> > LVDS encoder. This is used to support dual-link operation
Hi Sam,
On Tue, May 28, 2019 at 06:42:13PM +0200, Sam Ravnborg wrote:
> On Tue, May 28, 2019 at 05:12:31PM +0300, Laurent Pinchart wrote:
> > In dual-link LVDS mode, the LVDS1 encoder is used as a companion for
> > LVDS0, and both encoders transmit data from DU0. The LVDS1 output o
ings
> dt-bindings: display: renesas: lvds: Document r8a774a1 bindings
> drm: rcar-du: Add R8A774A1 support
> drm: rcar-du: lvds: Add r8a774a1 support
For the whole series,
Reviewed-by: Laurent Pinchart
I've taken it to my tree and will submit a pull request.
> .../bindings/d
Hi Jacopo,
On Thu, Apr 04, 2019 at 06:00:49PM +0200, Jacopo Mondi wrote:
> On Thu, Mar 28, 2019 at 09:07:16AM +0200, Laurent Pinchart wrote:
> > The V4L2 API is missing the 16-bit RGB formats for the RGBA, RGBX,
> > ABGR, XBGR, BGRA and BGRX component orders. Add them, using th
09:07:18AM +0200, Laurent Pinchart wrote:
> > Add support for the V4L2_PIX_FMT_BGRA32, V4L2_PIX_FMT_BGRX32,
> > V4L2_PIX_FMT_RGBA32 and V4L2_PIX_FMT_RGBX32 formats to the VSP driver.
> >
> > Signed-off-by: Laurent Pinchart
> > ---
> > drivers/media/platform/vsp1/vs
Hi Jacopo,
On Thu, Apr 04, 2019 at 05:57:39PM +0200, Jacopo Mondi wrote:
> On Thu, Mar 28, 2019 at 09:07:17AM +0200, Laurent Pinchart wrote:
> > The V4L2 API is missing the 16-bit RGB555 formats for the RGBA, RGBX,
> > ABGR, XBGR, BGRA and BGRX component orders. Add them, using th
The V4L2 API is missing the 16-bit RGB555 formats for the RGBA, RGBX,
ABGR, XBGR, BGRA and BGRX component orders. Add them, using the same
4CCs as DRM.
Signed-off-by: Laurent Pinchart
---
Changes since v1:
- Fixed the BGRA555 and BGRX555 formats
---
.../media/uapi/v4l/pixfmt-packed-rgb.rst
Hi Dave,
On Thu, Mar 28, 2019 at 09:07:14AM +0200, Laurent Pinchart wrote:
> Hello,
>
> This patch series adds support for 16 missing RGB formats to the DU
> driver. To do is, the formats are first added to the VSP1 driver.
> Patches 1/9 to 3/9 define those formats in the V4L2 A
\n");
> return -EBUSY;
> }
>
> + if (value & AUX_TIMEOUT) {
> + dev_err(tc->dev, "aux access timeout!\n");
> + return -ETIMEDOUT;
> + }
> +
This changes the priority between er
to ? DP_TRAINING_LANE0_SET isn't
defined in Linus' or Dave's master branches.
> + if (ret < 0)
> + goto err_dpcd_write;
> +
I can't comment on this as I don't have access to the device
documentation :-(
> ret = tc
. Could it be related to
video sources that already provide X3.230-1994 encoded data ? In any
case this shouldn't be driven by the sink but by the source, so
Reviewed-by: Laurent Pinchart
Andrey, as this feature was present in the initial driver version that
you authored, do you have more info
inen
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/tc358767.c | 13 -
> 1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/tc358767.c
> b/drivers/gpu/drm/bridge/tc358767.c
> index 163c594fa6ac..8e53073f0e3
Hi Tomi,
Thank you for the patch.
On Tue, Mar 26, 2019 at 12:31:29PM +0200, Tomi Valkeinen wrote:
> swing and preemp fields are not used. Remove them.
>
> Signed-off-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/tc358767.c | 2 --
>
raining but that needs lurking
> > into the code.
>
> Good point, the desc is a bit unclear. The reason is that we're setting
> up only AUX here, so anything related to the data-lanes is don't-care.
And also because the tc_aux_link_setup() function is called at probe
;mode);
> + if (ret)
> + goto err;
> +
> + /* Set M/N */
> + ret = tc_stream_clock_calc(tc);
> + if (ret)
> + goto err;
> +
Assuming this change will have a purpose further down in the
f (ret)
> - goto err;
> + ret = tc_set_video_mode(tc, tc->mode);
> + if (ret)
> + goto err;
Let's return ret directly and remove the err label.
With these issues addressed,
Reviewed-by: Laurent Pinchart
>
> - /*
390,8 +1392,6 @@ static int tc_remove(struct i2c_client *client)
> drm_bridge_remove(&tc->bridge);
> drm_dp_aux_unregister(&tc->aux);
>
> - tc_pxl_pll_dis(tc);
> -
> return 0;
> }
>
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
comment to the code to point this out.
This makes me a bit uneasy about the rework, as the
tc_main_link_enable() function doesn't enable the link (it doesn't set
the DP_EN bit in DP0CTL), and stream disabling separately from link
disabling is broken. Is this fixable ?
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
e lots of other issues. I don't think we should protect against one
particular issue that is supposed never to happen and then consider that
we're safe.
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
rivers/gpu/drm/bridge/tc358767.c
> @@ -872,7 +872,6 @@ static int tc_main_link_enable(struct tc_data *tc)
> if (tc->link.base.num_lanes == 2)
> dp_phy_ctrl |= PHY_2LANE;
> tc_write(DP_PHY_CTRL, dp_phy_ctrl);
> - msleep(100);
>
> /* PLL s
ning Pattern, set AutoCorrect Mode = 1 */
> - tc_write(DP0_SRCCTRL, tc_srcctrl(tc) | DP0_SRCCTRL_AUTOCORRECT);
> -
> /* Wait */
> timeout = 100;
> do {
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
v_err(dev, "0x0203 LANE2_3_STATUS 0x%02x\n",
> tmp[1]);
> + dev_err(dev, "0x0204 LANE_ALIGN_STATUS_UPDATED: 0x%02x\n",
> tmp[2]);
> + dev_err(dev, "0x0205 SINK_STATUS: 0x%02x\n",
> tmp[3]);
> + dev_err(dev, "0x0206 ADJUST_REQUEST_LANE0_1:0x%02x\n",
> tmp[4]);
> + dev_err(dev, "0x0207 ADJUST_REQUEST_LANE2_3:0x%02x\n",
> tmp[5]);
> + goto err;
> }
>
> return 0;
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
1 and 2.
> +
> + /* Set DPCD 0x102 for Training Pattern 2 */
> + tc_write(DP0_SNKLTCTRL, DP_LINK_SCRAMBLING_DISABLE |
> DP_TRAINING_PATTERN_2);
> +
> + tc_write(DP0_SRCCTRL, tc_srcctrl(tc) | DP0_SRCCTRL_SCRMBLDIS |
> DP0_SRCCTRL_AUTOCORRECT |
> +
> u32 error;
>
> - /* display mode should be set at this point */
> - if (!tc->mode)
> - return -EINVAL;
> -
> dev_dbg(tc->dev, "link enable\n");
>
> tc_write(DP0CTL, 0);
--
Regards,
Laurent Pinchart
_
_valid instead.
>
> Signed-off-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/tc358767.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/tc358767.c
> b/drivers/gpu/drm/bridge/tc35876
needed when the connector has
more than one encoder, which can't be the case here.
Reviewed-by: Laurent Pinchart
> Signed-off-by: Tomi Valkeinen
> ---
> drivers/gpu/drm/bridge/tc358767.c | 9 -
> 1 file changed, 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridg
iple intermediate modes,
*yet* :-) I don't know when we will need intermediate modes and bridge
states, but we'll get there.
I think this patch is safe, and I agree with Tomi that it minimizes the
impact on the driver.
> there is .mode as requested by userspace and .adjusted_mode with
> twisted semantic, with recent improvements[1].
>
> [1]: https://www.kernel.org/doc/html/latest/gpu/drm-kms.html
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
r formats from the
> >>> other subsystem, and to have a single, unique place where this is
> >>> centralized.
> >>
> >> What I think could work as middle ground:
> >> - Put drm_format stuff into a separate .ko
> >> - Add a MAINTAINERS entry to make sure all things fourcc are cross
> >> posted to both drm and v4l lists. Easy on the drm side, since it's all
> >> separate files. Not sure it's so convenient for v4l uapi.
> >> - Add a conversion library that tries to best-effort map between drm
> >> and v4l formats. On the drm side that most likely means you need
> >> offsets for planes, and modifiers too (since those are implied in some
> >> v4l fourcc). Emphasis on "best effort" i.e. only support as much as
> >> the drivers that use this library need.
> >> - Add drm_fourcc as-needed by these drivers that want to use a unified
> >> format space.
> >>
> >> Forcing this unification on everyone otoh is imo way too much.
> >
> > v4l2 is starting to converge with DRM, and we're using the DRM API
> > pretty much untouched for that library, so I'm not really sure how
> > anyone is hurt by that unification.
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
ff. If sharing means we need
> to split the drm_fourcc code and library out of drm trees, I'm not
> sure that's a good idea. We're already super liberal with merging
> anything through driver trees with acks, and integrating them quickly
> into drm-next. This would still be workable if v4l sends regular pull
> requests to drm-next (every 1-2 weeks, like the other big gpu trees
> do). If we can only sync up once per merge window with a shared
> boutique tree for formats only, life is going to be painful.
That should be solved by the proposal above, maintaining the shared
library in the DRM tree. We would need to be careful there, and ideally
maintain that in a separate branch that could be merged in both DRM and
V4L2 without having to merge most of the other subsystem's pending
changes at the same time, but I think it's doable without any big issue.
> > If it's shared code, then it should be shared, and every client
> > framework put on an equal footing.
> >
> > > > - Develop the same library from within v4l2. That is really a poor
> > > > solution, since the information would be greatly duplicated
> > > > between the two, and in terms of maintainance, code, and binary
> > > > size that would be duplicated too.
> > >
> > > It's essentially what we decided to do for drm years back.
> >
> > And it was probably the right solution back then, but I'm really not
> > convinced it's still the right thing to do today.
> >
> > > > Having it shared allows to easily share, and discover formats from the
> > > > other subsystem, and to have a single, unique place where this is
> > > > centralized.
> > >
> > > What I think could work as middle ground:
> > > - Put drm_format stuff into a separate .ko
> > > - Add a MAINTAINERS entry to make sure all things fourcc are cross
> > > posted to both drm and v4l lists. Easy on the drm side, since it's all
> > > separate files. Not sure it's so convenient for v4l uapi.
> > > - Add a conversion library that tries to best-effort map between drm
> > > and v4l formats. On the drm side that most likely means you need
> > > offsets for planes, and modifiers too (since those are implied in some
> > > v4l fourcc). Emphasis on "best effort" i.e. only support as much as
> > > the drivers that use this library need.
> > > - Add drm_fourcc as-needed by these drivers that want to use a unified
> > > format space.
> > >
> > > Forcing this unification on everyone otoh is imo way too much.
> >
> > v4l2 is starting to converge with DRM, and we're using the DRM API
> > pretty much untouched for that library, so I'm not really sure how
> > anyone is hurt by that unification.
>
> It might make sense to regularly pull v4l updates into drm-next then
> anyway. That would also remove the need to have the format library
> somewhere else.
Are you saying it should the live in V4L2 ? ;-)
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
two different items we call
4CC, the macro name (FOO in your example here), and the numerical value.
If a numerical value already exists in DRM or V4L2 for a given pixel
format, it should be used, period. The macro name, however, could be
changed, as many of them carry historical mistakes.
> We
; + i2s-data-lanes = < 0 1 2 >;
This doesn't have the sil, prefix documented above. As stated in a
previous review, I wouldn't add a vendor prefix to this property as it
isn't vendor-specific, but I would then document it in a separate file
for common I2S propertie
Hi Jyri,
On Tue, Mar 19, 2019 at 04:38:45PM +0200, Jyri Sarha wrote:
> On 17/03/2019 18:16, Laurent Pinchart wrote:
> > On Thu, Mar 14, 2019 at 01:27:51PM +0200, Jyri Sarha wrote:
> >> The sii902x chip family supports also HDMI audio. Add binding for
> >> describing
> > Fixes: 264fce6cc2c1 ("drm/bridge: dw-hdmi: Add SCDC and TMDS Scrambling
> > support")
> > Signed-off-by: Jonas Karlman
>
> I've looked that up and yeah, hdmi->ddc seems the right thing to use
> as it points either to the external i2c or the inte
Hi Jacopo,
On Tue, Apr 23, 2019 at 03:21:53PM +0200, Jacopo Mondi wrote:
> On Thu, Apr 18, 2019 at 09:06:45AM +0300, Laurent Pinchart wrote:
> > On Thu, Apr 04, 2019 at 07:39:05PM +0200, Jacopo Mondi wrote:
> >> HI Laurent,
> >> if you help me out understanding the bi
Hi Jacopo,
On Tue, Apr 23, 2019 at 03:55:08PM +0200, Jacopo Mondi wrote:
> On Thu, Mar 28, 2019 at 09:07:20AM +0200, Laurent Pinchart wrote:
> > Add support for the V4L2_PIX_FMT_RGBA555, V4L2_PIX_FMT_RGBX555,
> > V4L2_PIX_FMT_ABGR555, V4L2_PIX_FMT_XBGR555, V4L2_PIX_
Hi Andrey,
On Tue, Apr 23, 2019 at 11:19:17AM +0300, Andrey Gusakov wrote:
> On Sun, Apr 21, 2019 at 12:14 AM Laurent Pinchart wrote:
> > On Tue, Mar 26, 2019 at 12:31:27PM +0200, Tomi Valkeinen wrote:
> >> DP always uses ANSI 8B10B encoding. Some monitors (old?) may not have
&
Hi Daniel,
On Tue, Apr 23, 2019 at 09:25:54AM +0200, Daniel Vetter wrote:
> On Sun, Apr 21, 2019 at 01:59:04AM +0300, Laurent Pinchart wrote:
> > On Thu, Apr 18, 2019 at 12:07:44PM +0200, Daniel Vetter wrote:
> >> On Thu, Apr 18, 2019 at 11:02 AM Maxime Ripard wrote:
> >&g
Hi Daniel,
On Tue, Apr 23, 2019 at 09:59:37AM +0100, Daniel Stone wrote:
> On Tue, 23 Apr 2019 at 08:26, Daniel Vetter wrote:
> > On Sun, Apr 21, 2019 at 01:59:04AM +0300, Laurent Pinchart wrote:
> >>>>> - drm fourcc code doesn't actually define the drm_format_
Hi Jacopo,
Thank you for the patch.
On Tue, Apr 23, 2019 at 06:56:00PM +0200, Jacopo Mondi wrote:
> On Tue, Apr 23, 2019 at 05:46:51PM +0300, Laurent Pinchart wrote:
> > On Tue, Apr 23, 2019 at 03:55:08PM +0200, Jacopo Mondi wrote:
> >> On Thu, Mar 28, 2019 at 09:07:20AM +0200
ane is in stop state. Fix
> this by waiting for the mask of PHY STATUS bits corresponding to the
> active lanes to be set.
>
> Signed-off-by: Matt Redfearn
I don't have access to the datasheet, but the change makes sense.
Reviewed-by: Laurent Pinchart
> ---
>
> driv
inter, we should NULL check it
> before blindy calling it.
>
> Signed-off-by: Matt Redfearn
Reviewed-by: Laurent Pinchart
> ---
>
> drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/dr
ster(&dsi->dsi_host);
> if (ret) {
> dev_err(dev, "Failed to register MIPI host: %d\n", ret);
> + dw_mipi_dsi_debugfs_remove(dsi);
> return ERR_PTR(ret);
> }
>
> @@ -1029,6 +1083,7 @@ static void __dw_mipi_dsi_remove(struct dw_mipi_dsi
> *dsi)
> mipi_dsi_host_unregister(&dsi->dsi_host);
>
> pm_runtime_disable(dsi->dev);
> + dw_mipi_dsi_debugfs_remove(dsi);
> }
>
> void dw_mipi_dsi_set_slave(struct dw_mipi_dsi *dsi, struct dw_mipi_dsi
> *slave)
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
DSI
> drm_bridge it will go on to call post_disable on all other bridges in
> the chain, in addition to us calling them here. Is it an issue to call
> it multiple times?
It depends on the panel implementation, but in general it's not a good
idea. It may happen to work, but could break at any time in the future.
> >>if (dsi->slave) {
> >>dw_mipi_dsi_disable(dsi->slave);
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Thu, Apr 25, 2019 at 08:59:15PM +0300, Laurent Pinchart wrote:
> On Thu, Apr 25, 2019 at 12:39:27PM +, Matt Redfearn wrote:
> > On 25/04/2019 13:13, Andrzej Hajda wrote:
> >> On 24.04.2019 16:22, Matt Redfearn wrote:
> >>> The DRM documentation states th
Hi Tomi,
On Fri, Apr 26, 2019 at 05:14:17PM +0300, Tomi Valkeinen wrote:
> On 20/04/2019 23:30, Laurent Pinchart wrote:
> > On Tue, Mar 26, 2019 at 12:31:26PM +0200, Tomi Valkeinen wrote:
> >> We need to reset DPCD voltage-swing & pre-emphasis before starting the
> >&
. It's not even using DT yet :-/
I'd prefer dropping the fbdev driver too, but that would require porting
the SH boards to the DRM driver, and implement DT support for the ARM
board. I don't think anyone is willing to invest time in this, so I'm
fine dropping this driver as the
Hi Biju,
Thank you for the patch.
On Tue, Jan 22, 2019 at 03:25:46PM +, Biju Das wrote:
> Document the RZ/G1N (R8A7744) LVDS bindings.
>
> Signed-off-by: Biju Das
Reviewed-by: Laurent Pinchart
and taken in my tree.
> ---
> Documentation/devicetree/bindings/display
Hi Biju,
Thank you for the patch.
On Tue, Jan 22, 2019 at 03:25:47PM +, Biju Das wrote:
> The LVDS encoders on RZ/G1N SoC is similar to RZ/G1M. Add support for
> RZ/G1N (R8A7744) SoC to the LVDS encoder driver.
>
> Signed-off-by: Biju Das
Reviewed-by: Laurent Pinchart
and
Hi Biju,
Thank you for the patch.
On Tue, Jan 22, 2019 at 03:25:48PM +, Biju Das wrote:
> Add du node to r8a7744 SoC DT. Boards that want to enable the DU
> need to specify the output topology.
>
> Signed-off-by: Biju Das
Reviewed-by: Laurent Pinchart
I expect Simon to
c96f2 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
> @@ -12,6 +12,7 @@
> #include
>
> #include
> +#include
>
> #define RCAR_HDMI_PHY_OPMODE_PLLCFG 0x06/* Mode of operation and PLL
> dividers */
>
801 - 900 of 9324 matches
Mail list logo
