Hi Geert,
On Mon, Jan 16, 2023 at 11:24:10AM +0100, Geert Uytterhoeven wrote:
> On Sat, Jan 14, 2023 at 4:26 PM Laurent Pinchart wrote:
> > Geert, could you please take this in your tree for v6.3 ? The two
> > patches that the DT changes depend on have been merged in v6.2.
>
NERS | 1 +
> drivers/gpu/drm/panel/panel-lvds.c| 1 +
> 4 files changed, 163 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/panel/panel-dual-lvds.yaml
--
Regards,
Laurent Pinchart
Tony, could you take this patch in your tree for v6.3 ? The two patches
that it depends on have both been merged in v6.2.
On Thu, Jun 16, 2022 at 01:14:08AM +0300, Laurent Pinchart wrote:
> Now that a header exists with macros for the media interface bus-type
> values, replace hard
Hugues, Maxime, Alexandre, could one of you take this patch in your tree
for v6.3 ? The two patches that it depends on have both been merged in
v6.2.
On Thu, Jun 16, 2022 at 01:14:10AM +0300, Laurent Pinchart wrote:
> Now that a header exists with macros for the media interface bus-type
>
Shawn, could you please take this in your tree for v6.3 ? The two
patches that the DT changes depend on have been merged in v6.2.
On Thu, Jun 16, 2022 at 01:14:07AM +0300, Laurent Pinchart wrote:
> Now that a header exists with macros for the media interface bus-type
> values, replace hard
Geert, could you please take this in your tree for v6.3 ? The two
patches that the DT changes depend on have been merged in v6.2.
On Thu, Jun 16, 2022 at 01:14:09AM +0300, Laurent Pinchart wrote:
> Now that a header exists with macros for the media interface bus-type
> values, replace hard
a/platform/renesas/Makefile |1 -
> drivers/media/platform/renesas/sh_vou.c | 1375 ---
You can also emove include/media/drv-intf/sh_vou.sh. With that, and the
corresponding MAINTAINERS entry dropped,
Reviewed-by: Laurent Pinchart
> 3 files changed, 1385 deletions(
On Fri, Jan 13, 2023 at 09:46:49AM +0200, Laurent Pinchart wrote:
> Hi Christoph,
>
> Thank you for the patch.
>
> On Fri, Jan 13, 2023 at 07:23:18AM +0100, Christoph Hellwig wrote:
> > This driver depends on ARM && ARCH_SHMOBILE, but ARCH_SHMOBILE can only b
igned-off-by: Christoph Hellwig
No objection from me.
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/Kconfig | 2 -
> drivers/gpu/drm/Makefile | 1 -
> drivers/gpu/drm/shmobile/Kconfig | 12 -
> drivers/gpu/d
Hi Aradhya,
Thank you for the patch.
On Tue, Jan 03, 2023 at 12:16:13PM +0530, Aradhya Bhatia wrote:
> Add document vendor prefix for Lincoln Technology Solutions
> (lincolntech).
>
> Signed-off-by: Aradhya Bhatia
Reviewed-by: Laurent Pinchart
> ---
> Documentation/d
Hi Aradhya,
Thank you for the patch.
On Tue, Jan 03, 2023 at 12:16:12PM +0530, Aradhya Bhatia wrote:
> Add document vendor prefix for Microtips Technology USA (microtips).
>
> Signed-off-by: Aradhya Bhatia
Reviewed-by: Laurent Pinchart
> ---
> Documentation/devicetree/
port@1 {
> + reg = <1>;
> + dual-lvds-even-pixels;
> + lcd_in1: endpoint {
> +remote-endpoint = <_out1>;
> + };
> +};
> + };
> +};
> +
> +...
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 7f86d02cb427..c13f24293ab1 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6595,6 +6595,7 @@ T: git git://anongit.freedesktop.org/drm/drm-misc
> S: Maintained
> F: drivers/gpu/drm/panel/panel-lvds.c
> F: Documentation/devicetree/bindings/display/lvds.yaml
> +F: Documentation/devicetree/bindings/display/panel/panel-dual-lvds.yaml
> F: Documentation/devicetree/bindings/display/panel/panel-lvds.yaml
>
> DRM DRIVER FOR MANTIX MLAF057WE51 PANELS
--
Regards,
Laurent Pinchart
RCH_RENESAS || COMPILE_TEST
> > > default DRM_RCAR_DU
> > > help
> > > Enable support for the R-Car Display Unit embedded LVDS encoders.
> > > @@ -45,6 +47,7 @@ config DRM_RCAR_LVDS
> > > config DRM_RCAR_USE_MIPI_DSI
> > > bool "R-Car DU MIPI DSI Encoder Support"
> > > depends on DRM_BRIDGE && OF
> > > + depends on ARCH_RENESAS || COMPILE_TEST
> > > default DRM_RCAR_DU
> > > help
> > > Enable support for the R-Car Display Unit embedded MIPI DSI
> > > encoders.
--
Regards,
Laurent Pinchart
ot;
> depends on DRM_BRIDGE && OF
> + depends on ARCH_RENESAS || COMPILE_TEST
> default DRM_RCAR_DU
> help
> Enable support for the R-Car Display Unit embedded MIPI DSI encoders.
--
Regards,
Laurent Pinchart
21E.
> + */
> + writel(DSI_WRAP_DPI_0_EN, dsi->j721e_regs + DSI_WRAP_DPI_CONTROL);
> +}
> +
> +static void cdns_dsi_j721e_disable(struct cdns_dsi *dsi)
> +{
> + /* Put everything to defaults */
> + writel(0, dsi->j721e_regs + DSI_WRAP_DPI_CONTROL);
> +}
> +
> +const struct dsi_platform_ops dsi_ti_j721e_ops = {
> + .init = cdns_dsi_j721e_init,
> + .enable = cdns_dsi_j721e_enable,
> + .disable = cdns_dsi_j721e_disable,
> +};
> diff --git a/drivers/gpu/drm/bridge/cadence/cdns-dsi-j721e.h
> b/drivers/gpu/drm/bridge/cadence/cdns-dsi-j721e.h
> new file mode 100644
> index ..fd251c1a268b
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/cadence/cdns-dsi-j721e.h
> @@ -0,0 +1,16 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * TI j721e Cadence DSI wrapper
> + *
> + * Copyright (C) 2022 Texas Instruments Incorporated - http://www.ti.com/
> + * Author: Rahul T R
> + */
> +
> +#ifndef CDNS_DSI_J721E_H
__ prefix for header guard ?
> +#define CDNS_DSI_J721E_H
> +
> +#include "cdns-dsi-core.h"
> +
> +extern const struct dsi_platform_ops dsi_ti_j721e_ops;
> +
> +#endif /* !CDNS_DSI_J721E_H */
--
Regards,
Laurent Pinchart
0xf8
> +#define MAX_LINE_LIMIT(x)((x) << 16)
> +#define EXACT_BURST_LIMIT(x) (x)
> +
> +#define TVG_CTL 0xfc
> +#define TVG_STRIPE_SIZE(x) ((x) << 5)
> +#define TVG_MODE_MASKGENMASK(4, 3)
adence/Makefile
> +++ b/drivers/gpu/drm/bridge/cadence/Makefile
> @@ -2,3 +2,5 @@
> obj-$(CONFIG_DRM_CDNS_MHDP8546) += cdns-mhdp8546.o
> cdns-mhdp8546-y := cdns-mhdp8546-core.o cdns-mhdp8546-hdcp.o
> cdns-mhdp8546-$(CONFIG_DRM_CDNS_MHDP8546_J721E) += cdns-mhdp8546-j721e.o
> +
Hi Rahul,
Thank you for the patch.
On Mon, Jan 02, 2023 at 03:39:39PM +0530, Rahul T R wrote:
> Add compatible to support dsi bridge on j721e
>
> Signed-off-by: Rahul T R
> Reviewed-by: Rob Herring
Reviewed-by: Laurent Pinchart
> ---
> .../bindings/display/bridge/cdns
ts DPI to DSI
> +
> +properties:
> + compatible:
> +enum:
> + - cdns,dsi
> +
> + reg:
> +maxItems: 1
> +
> + clocks:
> +items:
> + - description: PSM clock, used by the IP
> + - description: sys clock, used by the IP
> +
> +
never access the pointer in
> that case.
>
> Fixes: 5ea6b1702781 ("drm/panel: Add prepare_prev_first flag to drm_panel")
> Reported-by: kernel test robot
> Reported-by: Dan Carpenter
> Signed-off-by: Maxime Ripard
Reviewed-by: Laurent Pinchart
> ---
> drivers/
atform/renesas/vsp1/vsp1_rpf.c| 64 +-
> .../media/platform/renesas/vsp1/vsp1_video.c | 4 +-
> .../media/platform/renesas/vsp1/vsp1_wpf.c| 4 +-
> drivers/media/v4l2-core/v4l2-ioctl.c | 6 +
> include/uapi/linux/videodev2.h| 11 +
> 15 files changed, 447 insertions(+), 20 deletions(-)
--
Regards,
Laurent Pinchart
Hi Tomi,
Thank you for the patch.
On Wed, Dec 21, 2022 at 11:24:46AM +0200, Tomi Valkeinen wrote:
> Add new pixel formats: RGBX1010102, RGBA1010102, ARGB2101010, Y210 and
> Y212.
>
> Signed-off-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
> ---
> .../media/pla
esent the model correctly. V3U and V4H can still be
> differentiated, if needed, with the VI6_IP_VERSION_SOC_xxx.
>
> Also mark VI6_IP_VERSION_MODEL_VSPD_GEN4 as gen 4 in vsp1_device_info,
> and update the code to correctly match for gen 4.
>
> Signed-off-by: Tomi Valkeine
Hi Tomi,
Thank you for the patch.
On Wed, Dec 21, 2022 at 11:24:43AM +0200, Tomi Valkeinen wrote:
> Add Y210, Y212 and Y216 formats.
>
> Signed-off-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
> ---
> .../media/v4l/pixfmt-packed-yuv.rst | 49 +++
; + -
> +
> +.. raw:: latex
> +
> +\endgroup
> +
> +
> Deprecated RGB Formats
> ==
>
> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
> b/drivers/media/v4l2-core/v4l2-ioctl.c
> index fddba75d9074..875b9a95e3c8 100644
> --- a/dri
Hi Tomi,
Thank you for the patch.
On Wed, Dec 21, 2022 at 11:24:48AM +0200, Tomi Valkeinen wrote:
> Add new pixel formats: RGBX1010102, RGBA1010102, ARGB2101010, Y210 and
Reviewed-by: Laurent Pinchart
> Y212.
>
> Signed-off-by: Tomi Valkeinen
> ---
> drivers/gpu/drm/rca
Hi Tomi,
On Wed, Dec 21, 2022 at 09:48:10AM +0200, Tomi Valkeinen wrote:
> On 19/12/2022 23:01, Laurent Pinchart wrote:
> > On Mon, Dec 19, 2022 at 04:01:35PM +0200, Tomi Valkeinen wrote:
> >> V3U is actually gen4, not gen3. The same IP is also used in the
> >&
Hi Tomi,
On Tue, Dec 20, 2022 at 04:12:29PM +0200, Tomi Valkeinen wrote:
> On 19/12/2022 21:10, Laurent Pinchart wrote:
> > On Mon, Dec 19, 2022 at 04:01:33PM +0200, Tomi Valkeinen wrote:
> >> Add XBGR2101010, ABGR2101010 and BGRA1010102 formats.
> >>
> &g
Hi Sakari,
On Tue, Dec 20, 2022 at 11:36:35AM +0200, Sakari Ailus wrote:
> On Mon, Dec 19, 2022 at 11:47:04PM +0200, Laurent Pinchart wrote:
> > On Mon, Dec 19, 2022 at 04:01:39PM +0200, Tomi Valkeinen wrote:
> > > Add new pixel formats: RGBX1010102, RGBA1010102, AR
Hi Hans,
On Tue, Dec 20, 2022 at 10:26:35AM +0100, Hans Verkuil wrote:
> On 20/12/2022 10:18, Laurent Pinchart wrote:
> > On Tue, Dec 20, 2022 at 10:01:04AM +0100, Hans Verkuil wrote:
> >> On 19/12/2022 22:47, Laurent Pinchart wrote:
> >>> Hi Tomi,
>
Hello,
On Tue, Dec 20, 2022 at 10:01:04AM +0100, Hans Verkuil wrote:
> On 19/12/2022 22:47, Laurent Pinchart wrote:
> > Hi Tomi,
> >
> > (CC'ing Sakari and Hans)
> >
> > Thank you for the patch.
> >
> > On Mon, Dec 19, 2022 at 04:01:39PM +0200, Tom
}
>
> plane->vsp = vsp;
> plane->index = i;
>
> ret = drm_universal_plane_init(>ddev, >plane,
> crtcs, _du_vsp_plane_funcs,
> -rcar_du_vsp_formats,
> -ARRAY_SIZE(rcar_du_vsp_formats),
> +formats, num_formats,
> NULL, type, NULL);
> if (ret < 0)
> return ret;
--
Regards,
Laurent Pinchart
Hi Tomi,
Thank you for the patch.
On Mon, Dec 19, 2022 at 04:01:38PM +0200, Tomi Valkeinen wrote:
> V3U is actually gen 4 IP, like in V4H. Bumb up V3U gen in the
> rcar_du_r8a779a0_info.
With the typo reporting by Kieran fixed,
Conditionally-Reviewed-by: Laurent Pinchart
> S
VI6_RPF_EXT_INFMT0_IPBD_Y_10 |
> + VI6_RPF_EXT_INFMT0_IPBD_C_10;
> + ext_infmt1 = 0x0;
> + ext_infmt2 = 0x0;
> + break;
> +
> + default:
> + ext_infmt0 = 0;
> + ext_infmt1 = 0;
> + ext_infmt2 = 0;
> + break;
> + }
> +
> + vsp1_rpf_write(rpf, dlb, VI6_RPF_EXT_INFMT0, ext_infmt0);
> + vsp1_rpf_write(rpf, dlb, VI6_RPF_EXT_INFMT1, ext_infmt1);
> + vsp1_rpf_write(rpf, dlb, VI6_RPF_EXT_INFMT2, ext_infmt2);
> + }
> +
> /* Output location. */
> if (pipe->brx) {
> const struct v4l2_rect *compose;
--
Regards,
Laurent Pinchart
Hi Tomi,
Thank you for the patch.
On Mon, Dec 19, 2022 at 04:01:36PM +0200, Tomi Valkeinen wrote:
> Add VI6_IP_VERSION_SOC_V4H so that we can identify V4H SoC.
>
> Signed-off-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
> ---
> drivers/media/platform/renesas/vsp1/vsp1_re
4,7 @@ static void lif_configure_stream(struct vsp1_entity
> *entity,
> break;
>
> case VI6_IP_VERSION_MODEL_VSPD_GEN3:
> + case VI6_IP_VERSION_MODEL_VSPD_GEN4:
While this doesn't cause any functional change, it doesn't fall into the
renaming explained i
2-bit YUYV Packed"; break;
> + case V4L2_PIX_FMT_Y216: descr = "16-bit YUYV Packed"; break;
While the names will not play nicely with future formats that would swap
the order of the Y, U and V components, they match the formats defined
by DRM, which I think is more importan
ideodev2.h b/include/uapi/linux/videodev2.h
> index 29da1f4b4578..877fd61693b8 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -576,6 +576,9 @@ struct v4l2_pix_format {
> #define V4L2_PIX_FMT_RGBX32 v4l2_fourcc('X', 'B', '2', '4') /* 32
> RGBX-8-8-8-8 */
> #define V4L2_PIX_FMT_ARGB32 v4l2_fourcc('B', 'A', '2', '4') /* 32
> ARGB-8-8-8-8 */
> #define V4L2_PIX_FMT_XRGB32 v4l2_fourcc('B', 'X', '2', '4') /* 32
> XRGB-8-8-8-8 */
> +#define V4L2_PIX_FMT_XBGR2101010 v4l2_fourcc('R', 'X', '3', '0') /* 32
> XBGR-2-10-10-10 */
> +#define V4L2_PIX_FMT_ABGR2101010 v4l2_fourcc('R', 'A', '3', '0') /* 32
> ABGR-2-10-10-10 */
> +#define V4L2_PIX_FMT_BGRA1010102 v4l2_fourcc('A', 'R', '3', '0') /* 32
> BGRA-10-10-10-2 */
>
> /* Grey formats */
> #define V4L2_PIX_FMT_GREYv4l2_fourcc('G', 'R', 'E', 'Y') /* 8
> Greyscale */
--
Regards,
Laurent Pinchart
Hi Tomi,
Thank you for the patch.
On Fri, Sep 16, 2022 at 11:22:06AM +0300, Tomi Valkeinen wrote:
> Fix doc related warnings seen with W=1: the function names have changed
> but the docs have not been changed accordingly.
>
> Signed-off-by: Tomi Valkeinen
Reviewed-by: Laur
On Mon, Dec 12, 2022 at 12:49:26PM +0100, Frieder Schrempf wrote:
> On 12.12.22 10:32, Laurent Pinchart wrote:
> > On Mon, Dec 12, 2022 at 10:09:45AM +0100, Frieder Schrempf wrote:
> >> On 09.12.22 15:49, Marek Vasut wrote:
> >>> On 12/9/22 14:38, Alexander Ste
;> Given the following time chart:
> >>>>>> vcc set EN
> >>>>>>
> >>>>>> enable GPIO PAD
> >>>>>>
> >>>>>> | |<-- t_raise -->|
> >>>>>> |
> >>>>>> | <-- t_vcc_gpio --> | |
> >>>>>> | <-- t_enable_delay --> |
> >>>>>>
> >>>>>> t_raise is the time from changing the GPIO output at the expander until
> >>>>>> voltage on the EN (input) pad from the bridge has reached high voltage
> >>>>>> level. This is an electrical characteristic I can not change and have
> >>>>>> to
> >>>>>> take into account.
> >>>>>> t_vcc_gpio is the time from enabling supply voltage to enabling the
> >>>>>> bridge
> >>>>>> (removing from reset). Minimum t_vcc_gpio is something which can be
> >>>>>> addressed by the regulator and is no problem so far. But there is no
> >>>>>> upper bound to it.
> >>>>>
> >>>>> What exactly is your EN signal rise time (should be ns or so)? Can you
> >>>>> look at that with a scope , maybe even with relation to the VCC
> >>>>> regulator
> >>>>> ?
> >>>>
> >>>> I checked EN rise time using a scope, it's ~110ms. I not an expert in
> >>>> hardware but on the mainboard there is some capacitor attached to this
> >>>> line, which increased the time, independent from the internal pull-up.
> >>>
> >>> This does seem like a hardware bug right there, can you double-check
> >>> this with the hardware engineer ?
> >>
> >> Yep, checked with hardware engineer. An 470nF is attached, together with an
> >> open drain output and only the internal pull-up. So yes ~113ms rising time
> >> until 0.7 x VCC.
> >
> > I don't suppose you can have that capacitor reduced or better yet, some
> > external pull up added, can you ?
>
> Actually our HW engineers have implemented a similar RC circuit to
> provide a hardware delay for the EN signal. I think this is due to a
> design note in the datasheet (see chapter 7.4.1) and therefore it's
> probably widely spread.
RC delay circuits are very common when tying a control signal to a power
rail. I'm surprise to see it recommended (with such a large time
constant) when the EN signal is actively controlled. It makes sense if
the SN65DSI83 supply comes up before the GPIO can be actively driven low
(for instance if the supply isn't manually controllable but tied to an
always-on power rail), in other cases it's quite counter-productive (I
really hope the EN input has a Schmitt trigger).
--
Regards,
Laurent Pinchart
t; (removing from reset). Minimum t_vcc_gpio is something which can be
> > > addressed by the regulator and is no problem so far. But there is no
> > > upper bound to it.
> >
> > What exactly is your EN signal rise time (should be ns or so)? Can you
> > look at that with a scope , maybe even with relation to the VCC regulator ?
>
> I checked EN rise time using a scope, it's ~110ms. I not an expert in
> hardware
> but on the mainboard there is some capacitor attached to this line, which
> increased the time, independent from the internal pull-up.
This is board-specific, and not a property of the SND65DSI83. If the
same circuit was attached to any control input of any chip, you would
need to modify the corresponding driver in a similar way. I don't think
this is right.
How about adding ramp-up (and ramp-down I suppose) delay DT properties
to the GPIO provider instead ? This wouldn't scale very well if all GPIO
providers had to be patched, but with some luck it may be possible to
handle that in the GPIO core ?
Another option would be to add a "GPIO delay" node in DT, between the
GPIO provider and consumer. It could be handled with a small driver that
forwards the GPIO calls with a delay.
> > The DSI84 EN pin already has a built-in pullup per DSI84 datasheet (see
> > Table 5-1. Pin Functions), so that should make the signal rise fast,
> > certainly not for seconds.
>
> Here it is >100ms, so the current waiting time is far too less. This results
> in errors regarding PLL lock failure.
--
Regards,
Laurent Pinchart
se of it to propagate
> > failing hardware accesses.
> >
> > Signed-off-by: Uwe Kleine-König
Reviewed-by: Laurent Pinchart
> > ---
> > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 8
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff
ime Ripard
Reviewed-by: Laurent Pinchart
> ---
> .../userspace-api/media/v4l/subdev-formats.rst | 37
> ++
> include/uapi/linux/media-bus-format.h | 3 +-
> 2 files changed, 39 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/
Hi Paul,
On Tue, Nov 29, 2022 at 09:05:49PM +, Paul Cercueil wrote:
> Le mardi 29 novembre 2022 à 21:43 +0200, Laurent Pinchart a écrit :
> > On Tue, Nov 29, 2022 at 07:19:33PM +, Paul Cercueil wrote:
> > > Use the DEFINE_SIMPLE_DEV_PM_OPS() and pm_sleep_ptr(
atch.
>
> Signed-off-by: Paul Cercueil
> Reviewed-by: Kieran Bingham
Reviewed-by: Laurent Pinchart
> ---
> Cc: Laurent Pinchart
> Cc: Kieran Bingham
> Cc: linux-renesas-...@vger.kernel.org
> ---
> drivers/gpu/drm/shmobile/shmob_drm_drv.c | 9 +++--
> 1 file change
atch.
>
> Signed-off-by: Paul Cercueil
> Reviewed-by: Kieran Bingham
Reviewed-by: Laurent Pinchart
Will you get this whole series merged in one go in drm-misc, or do you
expect me to take this patch in my tree ? I'd prefer the first option if
possible (less work for me :-)).
> ---
&g
> Am Di., 29. Nov. 2022 um 13:38 Uhr schrieb Laurent Pinchart <
> laurent.pinch...@ideasonboard.com>:
>
> > Hi Maxime and Joerg,
> >
> > Thank you for the patch.
> >
> > On Thu, Oct 20, 2022 at 10:30:47AM +0200, Maxime Ripard wrote:
> > >
p_info.m) | CLOCKSET2_N(setup_info.n)
> - | CLOCKSET2_VCO_CNTRL(setup_info.vco_cntrl);
> - clockset3 = CLOCKSET3_PROP_CNTRL(setup_info.prop_cntrl)
> - | CLOCKSET3_INT_CNTRL(0)
> - | CLOCKSET3_CPBIAS_CNTRL(0x10)
> - | CLOC
On Tue, Nov 29, 2022 at 02:23:04PM +0200, Laurent Pinchart wrote:
> Hi Maxime and Chris,
>
> Thank you for the patch.
>
> On Thu, Oct 20, 2022 at 10:30:45AM +0200, Maxime Ripard wrote:
> > From: Chris Morgan
> >
> > Add the MEDIA_BUS_FMT_RGB565_1X24_C
MT_RGB444_2X8_PADHI_LE0x1002
> @@ -49,6 +49,7 @@
> #define MEDIA_BUS_FMT_BGR666_1X180x1023
> #define MEDIA_BUS_FMT_RGB666_1X180x1009
> #define MEDIA_BUS_FMT_RBG888_1X240x100e
> +#define MEDIA_BUS_FMT_BGR666_1X24_CPADHI 0x1024
> #define MEDIA_BUS_FMT_RGB666_1X24_CPADHI 0x1015
> #define MEDIA_BUS_FMT_RGB666_1X7X3_SPWG 0x1010
> #define MEDIA_BUS_FMT_BGR888_1X240x1013
>
--
Regards,
Laurent Pinchart
ime Ripard
Reviewed-by: Laurent Pinchart
> ---
> .../userspace-api/media/v4l/subdev-formats.rst | 37
> ++
> include/uapi/linux/media-bus-format.h | 3 +-
> 2 files changed, 39 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/
rgan
> Signed-off-by: Maxime Ripard
Reviewed-by: Laurent Pinchart
> ---
> .../userspace-api/media/v4l/subdev-formats.rst | 37
> ++
> include/uapi/linux/media-bus-format.h | 3 +-
> 2 files changed, 39 insertions(+), 1 deletion(-)
>
>
Hi Tomi,
On Tue, Nov 29, 2022 at 01:30:04PM +0200, Tomi Valkeinen wrote:
> On 29/11/2022 03:49, Laurent Pinchart wrote:
> > On Wed, Nov 23, 2022 at 08:59:46AM +0200, Tomi Valkeinen wrote:
> >> Add DSI support for r8a779g0. The main differences to r8a779a0 are in
> >&
r to require all drivers to handle
writeback connectors explicitly everywhere (Daniel and Dave may want to
chime in here), I can be overruled, like anybody else.
> > This series is
> > Acked-by: Harry Wentland
> >
> >> Cc: Arun R Murthy
> >> Cc: Dave Air
/r8a779g0-cpg-mssr.c | 14 +
> drivers/gpu/drm/rcar-du/rcar_du_drv.c | 22 +
> drivers/gpu/drm/rcar-du/rcar_du_group.c | 2 +-
> drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c | 484 ++
> drivers/gpu/drm/rcar-du/rcar_mipi_dsi_regs.h | 6 +-
> 9 files changed, 649 insertions(+), 108 deletions(-)
>
--
Regards,
Laurent Pinchart
A0(__ffs(setup_info.vclk_divider));
> + break;
> +
> + case RCAR_DSI_R8A779G0:
> + vclkset |= VCLKSET_DIV_R8A779G0(__ffs(setup_info.vclk_divider)
> - 1);
> + break;
> +
> + default:
> + return -ENODEV;
> + }
>
> rcar_mipi_dsi_write(dsi, VCLKSET, vclkset);
>
> @@ -841,8 +1098,25 @@ static int rcar_mipi_dsi_remove(struct platform_device
> *pdev)
> return 0;
> }
>
> +static const struct rcar_mipi_dsi_device_info r8a779a0_data = {
> + .model = RCAR_DSI_R8A779A0,
> + .clk_cfg = dsi_clk_cfg_r8a779a0,
> + .clockset2_m_offset = 2,
> + .clockset2_n_offset = 1,
> +
Extra blank line.
> +};
> +
> +static const struct rcar_mipi_dsi_device_info r8a779g0_data = {
> + .model = RCAR_DSI_R8A779G0,
> + .clk_cfg = dsi_clk_cfg_r8a779g0,
> + .clockset2_m_offset = 0,
> + .clockset2_n_offset = 1,
You could possibly drop clockset2_n_offset as it's identical for the two
variants, and there's no indication it would be different in another
version of the IP core.
> +
Here too.
> +};
> +
> static const struct of_device_id rcar_mipi_dsi_of_table[] = {
> - { .compatible = "renesas,r8a779a0-dsi-csi2-tx" },
> + { .compatible = "renesas,r8a779a0-dsi-csi2-tx", .data = _data
> },
> + { .compatible = "renesas,r8a779g0-dsi-csi2-tx", .data = _data
> },
> { }
> };
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_mipi_dsi_regs.h
> b/drivers/gpu/drm/rcar-du/rcar_mipi_dsi_regs.h
> index 2eaca54636f3..608851340acf 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_mipi_dsi_regs.h
> +++ b/drivers/gpu/drm/rcar-du/rcar_mipi_dsi_regs.h
> @@ -122,7 +122,8 @@
> #define VCLKSET_CKEN (1 << 16)
> #define VCLKSET_COLOR_RGB(0 << 8)
> #define VCLKSET_COLOR_YCC(1 << 8)
> -#define VCLKSET_DIV(x) (((x) & 0x3) << 4)
> +#define VCLKSET_DIV_R8A779A0(x) (((x) & 0x3) << 4)
> +#define VCLKSET_DIV_R8A779G0(x) (((x) & 0x7) << 4)
> #define VCLKSET_BPP_16 (0 << 2)
> #define VCLKSET_BPP_18 (1 << 2)
> #define VCLKSET_BPP_18L (2 << 2)
> @@ -166,6 +167,9 @@
> #define PHTW_CWEN(1 << 8)
> #define PHTW_TESTDIN_CODE(x) (((x) & 0xff) << 0)
>
> +#define PHTR 0x1038
> +#define PHTR_TEST(1 << 16)
> +
> #define PHTC 0x103c
> #define PHTC_TESTCLR (1 << 0)
>
--
Regards,
Laurent Pinchart
s to come in other platforms.
> >
> > It could be refactored then when we have more visibility.
>
> Yes, it's not so nice. And afaiu some of these values should really be
> solved dynamically in the code. But the docs list these tables and don't
> explain how to come up with those values, so... I think having these
> tables is the safest way.
We could drop the cpbias_cntrl, gmp_cntrl and int_cntrl fields and set
them based on the IP version.
> >> @@ -427,8 +671,21 @@ static int rcar_mipi_dsi_startup(struct rcar_mipi_dsi
> >> *dsi,
> >> dev_warn(dsi->dev, "unsupported format");
> >> return -EINVAL;
> >> }
> >> - vclkset |= VCLKSET_COLOR_RGB | VCLKSET_DIV(setup_info.div)
> >> - | VCLKSET_LANE(dsi->lanes - 1);
> >> +
> >> + vclkset |= VCLKSET_COLOR_RGB | VCLKSET_LANE(dsi->lanes - 1);
> >> +
> >> + switch (dsi->info->model) {
> >> + case RCAR_DSI_R8A779A0:
> >> + vclkset |=
> >> VCLKSET_DIV_R8A779A0(__ffs(setup_info.vclk_divider));
> >> + break;
> >> +
> >> + case RCAR_DSI_R8A779G0:
> >> + vclkset |=
> >> VCLKSET_DIV_R8A779G0(__ffs(setup_info.vclk_divider) - 1);
> >
> > Why is this a -1 here ? Seems an odd difference compared to the A0.
>
> You need to ask the HW designers =). That's how the register is on G0.
> Field value of 0 means divided by 2.
--
Regards,
Laurent Pinchart
polarity = CHA_HSYNC_POLARITY;
> - if (mode->flags & DRM_MODE_FLAG_PVSYNC)
> + if (mode->flags & DRM_MODE_FLAG_NVSYNC)
> vsync_polarity = CHA_VSYNC_POLARITY;
>
> ti_sn65dsi86_write_u16(pdata, SN_CHA_ACTIVE_LINE_LENGTH_LOW_REG,
--
Regards,
Laurent Pinchart
ruct drm_connector_list_iter *iter)
> {
> - iter->dev = dev;
> - iter->conn = NULL;
> - lock_acquire_shared_recursive(_list_iter_dep_map, 0, 1, NULL,
> _RET_IP_);
> + drm_connector_list_iter_filter_begin(dev, iter, NULL, NULL);
> }
> EXPORT_SYMBOL(drm_connector_lis
ce/mm/memory.c#L2518
> > >
> > > More importantly, it does uncondtionally set VM_PFNMAP, so clearing
> > > that does not make much sense.
> > >
> > > Patch motived by discussions around enforcing VM_PFNMAP semantics for
> > > all dma-buf users, where
ed to test gen >= 3
instead of gen == 3. That seems to be the only problematic location. It
could thus fairly easily be done in v2, but we can also delay it.
> Aside from that, Which may need more work to handle correctly:
>
> Reviewed-by:
igned-off-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
> ---
> .../dts/renesas/r8a779g0-white-hawk-cpu.dtsi | 94 +++
> 1 file changed, 94 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a779g0-white-hawk-cpu.dtsi
> b/arch/arm64/boot/dts/renesas/
t; + reg = <1>;
> > + };
> > + };
> > + };
> > +
> > + dsi1: dsi-encoder@fed9 {
> > + compatible = "renesas,r8a779g0-dsi-csi2-tx";
> > +
DEF_MOD("hscif2", 516,R8A779G0_CLK_SASYNCPERD1),
> > @@ -193,6 +203,10 @@ static const struct mssr_mod_clk r8a779g0_mod_clks[]
> > __initconst = {
> > DEF_MOD("tmu3", 716,R8A779G0_CLK_SASYNCPERD2),
> > DEF_MO
might be SoC-specific?
> If not, perhaps the time is ripe for a family-specific compatible value?
That's hard to tell, I have little visibility into what surprises other
SoCs will bring :-S
> >to four data lanes.
> >
> > properties:
> >compatible:
> >
Hi Tomi,
Thank you for the patch.
On Thu, Nov 17, 2022 at 02:25:40PM +0200, Tomi Valkeinen wrote:
> From: Tomi Valkeinen
>
> Extend the Renesas DU display bindings to support the r8a779g0 V4H.
>
> Signed-off-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
> --
(+), 1 deletion(-)
--
Regards,
Laurent Pinchart
rcar-du: Add RZ/G2L DSI driver")
> Reported-by: kernel test robot
> Signed-off-by: Biju Das
Reviewed-by: Laurent Pinchart
> ---
> Ref:
> *
> https://lore.kernel.org/linux-renesas-soc/os0pr01mb592298e75153a52245d789d486...@os0pr01mb5922.jpnprd01.prod.outlook.com/T/#u
&
Hi Sakari,
On Mon, Nov 21, 2022 at 10:54:01AM +, Sakari Ailus wrote:
> On Sat, Nov 19, 2022 at 09:15:04PM +0200, Laurent Pinchart wrote:
> > On Fri, Nov 18, 2022 at 06:23:38PM +0900, Paul Elder wrote:
> > > On Sun, Jul 17, 2022 at 06:54:00AM +, Sakari Ailus wr
Hello,
On Fri, Nov 18, 2022 at 06:23:38PM +0900, Paul Elder wrote:
> Hi Sakari,
>
> Gentle ping.
>
> On Sun, Jul 17, 2022 at 06:54:00AM +, Sakari Ailus wrote:
> > Folks,
> >
> > > Laurent Pinchart (6):
> > > dt-bindings: media: Add macros for
On Fri, Nov 18, 2022 at 11:35:48PM +0100, Uwe Kleine-König wrote:
> From: Uwe Kleine-König
>
> .probe_new() doesn't get the i2c_device_id * parameter, so determine
> that explicitly in the probe function.
>
> Signed-off-by: Uwe Kleine-König
Reviewed-by: Laurent Pinchart
&g
On Fri, Nov 18, 2022 at 11:35:51PM +0100, Uwe Kleine-König wrote:
> From: Uwe Kleine-König
>
> The probe function doesn't make use of the i2c_device_id * parameter so it
> can be trivially converted.
>
> Signed-off-by: Uwe Kleine-König
Reviewed-by: Laurent Pinchart
> -
On Fri, Nov 18, 2022 at 11:35:49PM +0100, Uwe Kleine-König wrote:
> From: Uwe Kleine-König
>
> The probe function doesn't make use of the i2c_device_id * parameter so it
> can be trivially converted.
>
> Signed-off-by: Uwe Kleine-König
Reviewed-by: Laurent Pinchart
> -
On Fri, Nov 18, 2022 at 11:35:50PM +0100, Uwe Kleine-König wrote:
> From: Uwe Kleine-König
>
> The probe function doesn't make use of the i2c_device_id * parameter so it
> can be trivially converted.
>
> Signed-off-by: Uwe Kleine-König
Reviewed-by: Laurent Pinchart
> -
On Fri, Nov 18, 2022 at 11:36:09PM +0100, Uwe Kleine-König wrote:
> From: Uwe Kleine-König
>
> .probe_new() doesn't get the i2c_device_id * parameter, so determine
> that explicitly in the probe function.
>
> Signed-off-by: Uwe Kleine-König
Reviewed-by: Laurent Pinchart
&g
On Fri, Nov 18, 2022 at 11:35:58PM +0100, Uwe Kleine-König wrote:
> From: Uwe Kleine-König
>
> The probe function doesn't make use of the i2c_device_id * parameter so it
> can be trivially converted.
>
> Signed-off-by: Uwe Kleine-König
Reviewed-by: Laurent Pinchart
> -
On Fri, Nov 18, 2022 at 11:35:56PM +0100, Uwe Kleine-König wrote:
> From: Uwe Kleine-König
>
> The probe function doesn't make use of the i2c_device_id * parameter so it
> can be trivially converted.
>
> Signed-off-by: Uwe Kleine-König
Reviewed-by: Laurent Pinchart
> -
On Fri, Nov 18, 2022 at 11:36:11PM +0100, Uwe Kleine-König wrote:
> From: Uwe Kleine-König
>
> The probe function doesn't make use of the i2c_device_id * parameter so it
> can be trivially converted.
>
> Signed-off-by: Uwe Kleine-König
Reviewed-by: Laurent Pinchart
> -
On Fri, Nov 18, 2022 at 11:35:59PM +0100, Uwe Kleine-König wrote:
> From: Uwe Kleine-König
>
> The probe function doesn't make use of the i2c_device_id * parameter so it
> can be trivially converted.
>
> Signed-off-by: Uwe Kleine-König
Reviewed-by: Laurent Pinchart
> -
On Fri, Nov 18, 2022 at 11:36:02PM +0100, Uwe Kleine-König wrote:
> From: Uwe Kleine-König
>
> .probe_new() doesn't get the i2c_device_id * parameter, so determine
> that explicitly in the probe function.
>
> Signed-off-by: Uwe Kleine-König
Reviewed-by: Laurent Pinchart
&g
On Fri, Nov 18, 2022 at 11:36:08PM +0100, Uwe Kleine-König wrote:
> From: Uwe Kleine-König
>
> The probe function doesn't make use of the i2c_device_id * parameter so it
> can be trivially converted.
>
> Signed-off-by: Uwe Kleine-König
Reviewed-by: Laurent Pinchart
> -
On Fri, Nov 18, 2022 at 11:36:06PM +0100, Uwe Kleine-König wrote:
> From: Uwe Kleine-König
>
> The probe function doesn't make use of the i2c_device_id * parameter so it
> can be trivially converted.
>
> Signed-off-by: Uwe Kleine-König
Reviewed-by: Laurent Pinchart
> -
On Fri, Nov 18, 2022 at 11:36:07PM +0100, Uwe Kleine-König wrote:
> From: Uwe Kleine-König
>
> The probe function doesn't make use of the i2c_device_id * parameter so it
> can be trivially converted.
>
> Signed-off-by: Uwe Kleine-König
Reviewed-by: Laurent Pinchart
> -
On Fri, Nov 18, 2022 at 11:36:04PM +0100, Uwe Kleine-König wrote:
> From: Uwe Kleine-König
>
> The probe function doesn't make use of the i2c_device_id * parameter so it
> can be trivially converted.
>
> Signed-off-by: Uwe Kleine-König
Reviewed-by: Laurent Pinchart
> -
On Fri, Nov 18, 2022 at 11:36:01PM +0100, Uwe Kleine-König wrote:
> From: Uwe Kleine-König
>
> The probe function doesn't make use of the i2c_device_id * parameter so it
> can be trivially converted.
>
> Signed-off-by: Uwe Kleine-König
Reviewed-by: Laurent Pinchart
> -
On Fri, Nov 18, 2022 at 11:36:10PM +0100, Uwe Kleine-König wrote:
> From: Uwe Kleine-König
>
> The probe function doesn't make use of the i2c_device_id * parameter so it
> can be trivially converted.
>
> Signed-off-by: Uwe Kleine-König
Reviewed-by: Laurent Pinchart
> -
On Fri, Nov 18, 2022 at 11:36:03PM +0100, Uwe Kleine-König wrote:
> From: Uwe Kleine-König
>
> The probe function doesn't make use of the i2c_device_id * parameter so it
> can be trivially converted.
>
> Signed-off-by: Uwe Kleine-König
Reviewed-by: Laurent Pinchart
> -
On Fri, Nov 18, 2022 at 11:35:55PM +0100, Uwe Kleine-König wrote:
> From: Uwe Kleine-König
>
> The probe function doesn't make use of the i2c_device_id * parameter so it
> can be trivially converted.
>
> Signed-off-by: Uwe Kleine-König
Reviewed-by: Laurent Pinchart
> -
On Fri, Nov 18, 2022 at 11:35:52PM +0100, Uwe Kleine-König wrote:
> From: Uwe Kleine-König
>
> The probe function doesn't make use of the i2c_device_id * parameter so it
> can be trivially converted.
>
> Signed-off-by: Uwe Kleine-König
Reviewed-by: Laurent Pinchart
> -
On Fri, Nov 18, 2022 at 11:36:00PM +0100, Uwe Kleine-König wrote:
> From: Uwe Kleine-König
>
> The probe function doesn't make use of the i2c_device_id * parameter so it
> can be trivially converted.
>
> Signed-off-by: Uwe Kleine-König
Reviewed-by: Laurent Pinchart
&g
On Fri, Nov 18, 2022 at 11:36:05PM +0100, Uwe Kleine-König wrote:
> From: Uwe Kleine-König
>
> The probe function doesn't make use of the i2c_device_id * parameter so it
> can be trivially converted.
>
> Signed-off-by: Uwe Kleine-König
Reviewed-by: Laurent Pinchart
> -
On Fri, Nov 18, 2022 at 11:35:57PM +0100, Uwe Kleine-König wrote:
> From: Uwe Kleine-König
>
> The probe function doesn't make use of the i2c_device_id * parameter so it
> can be trivially converted.
>
> Signed-off-by: Uwe Kleine-König
Reviewed-by: Laurent Pinchart
> -
On Fri, Nov 18, 2022 at 11:35:54PM +0100, Uwe Kleine-König wrote:
> From: Uwe Kleine-König
>
> The probe function doesn't make use of the i2c_device_id * parameter so it
> can be trivially converted.
>
> Signed-off-by: Uwe Kleine-König
Reviewed-by: Laurent Pinchart
> -
On Fri, Nov 18, 2022 at 11:35:53PM +0100, Uwe Kleine-König wrote:
> From: Uwe Kleine-König
>
> The probe function doesn't make use of the i2c_device_id * parameter so it
> can be trivially converted.
>
> Signed-off-by: Uwe Kleine-König
Reviewed-by: Laurent Pinchart
> -
Hi Geert,
On Mon, Nov 14, 2022 at 10:05:58AM +0100, Geert Uytterhoeven wrote:
> On Sun, Oct 2, 2022 at 12:06 AM Laurent Pinchart wrote:
> > When the R-Car MIPI DSI driver was added, it was a standalone encoder
> > driver without any dependency to or from the R-Car DU
Laurent Pinchart (1):
drm: rcar-du: Drop leftovers dependencies from Kconfig
Nathan Huckleberry (1):
drm: xlnx: Fix return type of zynqmp_dp_bridge_mode_valid
.../bindings/display/bridge/renesas,dsi.yaml | 182 +
drivers/gpu/drm/rcar-du/Kconfig| 10
dependency fix
Laurent Pinchart (1):
drm: rcar-du: Fix Kconfig dependency between RCAR_DU and RCAR_MIPI_DSI
drivers/gpu/drm/rcar-du/Kconfig | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
--
Regards
f zynqmp_dp_bridge_mode_valid should be changed from
> int to enum drm_mode_status.
>
> Reported-by: Dan Carpenter
> Link: https://github.com/ClangBuiltLinux/linux/issues/1703
> Link: https://github.com/ClangBuiltLinux/linux/issues/1750
> Signed-off-by: Nathan Huckleberry
> Reviewed-by
s a v6.1 fix.
> Fixes: 957fe62d7d15 ("drm: rcar-du: Fix DSI enable & disable sequence")
> Signed-off-by: Randy Dunlap
> Cc: Tomi Valkeinen
> Cc: Laurent Pinchart
> Cc: Kieran Bingham
> Cc: LUU HOAI
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-renesas-.
501 - 600 of 9018 matches
Mail list logo
