date(struct device *dev, unsigned
> int pipe_index,
> rpf->mem.addr[1] = cfg->mem[1];
> rpf->mem.addr[2] = cfg->mem[2];
>
> + rpf->format.flags = (cfg->premult) ? V4L2_PIX_FMT_FLAG_PREMUL_ALPHA : 0;
I'll drop the parentheses when applying.
Revi
CONFIG_DRM_RCAR_MIPI_DSI)
> +void rcar_mipi_dsi_atomic_early_enable(struct drm_bridge *bridge,
> +struct drm_atomic_state *state);
> +void rcar_mipi_dsi_atomic_late_disable(struct drm_bridge *bridge);
It would be nice to have a naming scheme consistent with rcar_lvds.h.
That would mean rcar_mipi_dsi_clk_{enable,disable}(), or renaming the
LVDS functions to match whatever name would be picked here.
We could name the functions pre_enable/post_disable to show what they
should really be, if it wasn't for the DRM atomic helpers calling the
bridge operations at the wrong time.
> +#else
> +static inline void
> +rcar_mipi_dsi_atomic_early_enable(struct drm_bridge *bridge,
> + struct drm_atomic_state *state)
> +{
> +}
> +
> +void rcar_mipi_dsi_atomic_late_disable(struct drm_bridge *bridge)
> +{
> +}
> +#endif /* CONFIG_DRM_RCAR_MIPI_DSI */
> +
> +#endif /* __RCAR_MIPI_DSI_H__ */
--
Regards,
Laurent Pinchart
/* No blending. ALP and EOR are not supported */
> + pnmr &= ~(PnMR_SPIM_ALP | PnMR_SPIM_EOR);
> + }
> +
> + pnmr |= PnMR_SPIM_TP_OFF;
I'd combine this with the initial pnmr assignment. I can handle this
when applying, no need to resubmit.
Reviewed-by: Laurent Pinc
Hi Tomi,
Thank you for the patch.
On Wed, Aug 17, 2022 at 04:28:01PM +0300, Tomi Valkeinen wrote:
> From: Tomi Valkeinen
>
> rcar_du_regs.h is not needed by rcar_du_drv.c so drop the include.
>
> Signed-off-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
> ---
> dr
+
> +#define DRM_FORMAT_MOD_SYNA_V4H3P8 \
> + DRM_FORMAT_MOD_SYNA_MTR_LINEAR_2D(1, 3, 8, 0)
> +
> +#define DRM_FORMAT_MOD_SYNA_V4H1_COMPRESSED \
> + DRM_FORMAT_MOD_SYNA_MTR_LINEAR_2D(1, 1, 0, 1)
> +
> +#define DRM_FORMAT_MOD_SYNA_V4H3P8_COMPRESSED \
> + DRM_FORMAT_MOD_SYNA_MTR_LINEAR_2D(1, 3, 8, 1)
> +
> #if defined(__cplusplus)
> }
> #endif
--
Regards,
Laurent Pinchart
ormat {
> >> #define V4L2_PIX_FMT_NV12MT_16X16 v4l2_fourcc('V', 'M', '1', '2') /* 12
> >> Y/CbCr 4:2:0 16x16 tiles */
> >> #define V4L2_PIX_FMT_NV12M_8L128 v4l2_fourcc('N', 'A', '1', '2') /*
> >> Y/CbCr 4:2:0 8x128 tiles */
> >> #define V4L2_PIX_FMT_NV12M_10BE_8L128 v4l2_fourcc_be('N', 'T', '1', '2')
> >> /* Y/CbCr 4:2:0 10-bit 8x128 tiles */
> >> +#define V4L2_PIX_FMT_NV12M_V4H1C v4l2_fourcc('S', 'Y', '1', '2') /* 12
> >> Y/CbCr 4:2:0 tiles */
> >> +#define V4L2_PIX_FMT_NV12M_10_V4H3P8C v4l2_fourcc('S', 'Y', '1', '0')
> >> /* 12 Y/CbCr 4:2:0 10-bits tiles */
> >>
> >> /* Bayer formats - see http://www.siliconimaging.com/RGB%20Bayer.htm */
> >> #define V4L2_PIX_FMT_SBGGR8 v4l2_fourcc('B', 'A', '8', '1') /* 8
> >> BGBG.. GRGR.. */
--
Regards,
Laurent Pinchart
v4l2-ioctl.c | 2 ++
> include/uapi/drm/drm_fourcc.h | 49 +++
> include/uapi/linux/videodev2.h| 2 ++
> 4 files changed, 54 insertions(+)
--
Regards,
Laurent Pinchart
Link:
> https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=v6a6g1ouzcprm...@mail.gmail.com/
> Signed-off-by: Wolfram Sang
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/amd/amdgpu/atom.c | 2 +-
> drivers/gpu/drm/amd/pm/legacy-dpm/legacy_dpm.c
Hi Stephan,
On Mon, Aug 15, 2022 at 01:58:55PM -0700, Stephen Boyd wrote:
> Quoting Laurent Pinchart (2022-08-15 11:52:36)
> > On Mon, Aug 15, 2022 at 05:33:06PM +0100, Mark Brown wrote:
> > > On Mon, Aug 15, 2022 at 06:54:45PM +0300, Laurent Pinchart wrote:
> > >
Hi Mark,
On Mon, Aug 15, 2022 at 05:33:06PM +0100, Mark Brown wrote:
> On Mon, Aug 15, 2022 at 06:54:45PM +0300, Laurent Pinchart wrote:
>
> > - With devres, you don't have full control over the order in which
> > resources will be released, which means that you can't contr
hey
> should be sent as incremental updates against current git, existing
> patches will not be replaced.
>
> Please add any relevant lists and maintainers to the CCs when replying
> to this mail.
--
Regards,
Laurent Pinchart
dsi->lanes) {
> - mipi_dsi_detach(dsi);
> - dsi->lanes = lanes;
> - ret = mipi_dsi_attach(dsi);
> - if (ret)
> - dev_err(>dev, "failed to change host lanes\n");
> - }
> + /*
> + * number of lanes cannot be changed after initialization
> + * as per section 6.1 of the DSI specification. Hence filter
> + * out the modes which shall need different number of lanes
> + * than what was configured in the device tree.
> + */
> + if (lanes != dsi->lanes)
> + return MODE_BAD;
> +
> + return MODE_OK;
> }
>
> int adv7533_patch_registers(struct adv7511 *adv)
--
Regards,
Laurent Pinchart
nborg
> Signed-off-by: Danilo Krummrich
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/arm/hdlcd_drv.c | 1 -
> drivers/gpu/drm/arm/malidp_drv.c| 1 -
> drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 1 -
> drivers/gpu/drm/fs
e with it.
> Signed-off-by: Takanari Hayama
Reviewed-by: Laurent Pinchart
but I expect this patch to change based on my suggestions for 2/3.
> ---
> drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/drivers/gpu/
tion of the plane (from 0 to number of planes minus 1)
> + * @blend_mode: Pixel blend mode of the plane
> */
> struct vsp1_du_atomic_config {
> u32 pixelformat;
> @@ -60,6 +73,7 @@ struct vsp1_du_atomic_config {
> struct v4l2_rect dst;
> unsigned int alpha;
> unsigned int zpos;
> + enum vsp1_du_blend_mode blend_mode;
> };
>
> /**
--
Regards,
Laurent Pinchart
7 @@ vsp1_video_set_format(struct file *file, void *fh, struct
v4l2_format *format)
video->rwpf->format = format->fmt.pix_mp;
video->rwpf->fmtinfo = info;
+ video->rwpf->pixel_alpha = info->alpha;
done:
mutex_unlock(>lock);
I've tested that
Hi Marek,
On Thu, Jul 21, 2022 at 02:24:57PM +0200, Marek Vasut wrote:
> On 7/21/22 07:41, Laurent Pinchart wrote:
> > On Thu, Jul 21, 2022 at 05:03:27AM +0200, Marek Vasut wrote:
> >> Densitron is a manufacturer of LCD panels.
> >> https://www.densitron.com
> >
t;drm/bridge_connector: enable HPD by default if
> supported")
> Signed-off-by: Laurentiu Palcu
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/imx/dcss/dcss-kms.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/imx/dcss/dcss-kms.c
>
Hi Marek,
Thank you for the patch.
On Thu, Jul 21, 2022 at 05:03:27AM +0200, Marek Vasut wrote:
> Densitron is a manufacturer of LCD panels.
> https://www.densitron.com
>
> Signed-off-by: Marek Vasut
> Cc: Guido Günther
> Cc: Jagan Teki
> Cc: Laurent Pinchart
> Cc:
Hi Sakari,
On Sat, Jul 16, 2022 at 12:28:45PM +0300, Sakari Ailus wrote:
> On Thu, Jun 16, 2022 at 01:14:06AM +0300, Laurent Pinchart wrote:
> > Now that a header exists with macros for the media interface bus-type
> > values, replace hardcoding numerical constants with th
Biju Das (1):
drm: rcar-du: Add num_rpf to struct rcar_du_device_info
Kieran Bingham (1):
drm: rcar-du: Extend CMM HDSE documentation
LUU HOAI (1):
drm: rcar-du: Fix Alpha blending issue on Gen3
Laurent Pinchart (2):
drm: rcar-du
Hi Geert,
Thank you for the patch.
On Mon, Jul 11, 2022 at 05:56:41PM +0200, Geert Uytterhoeven wrote:
> These are unused since commit edcef53685edf5fb ("modetest: Add test
> pattern support for missing RGB formats").
>
> Signed-off-by: Geert Uytterhoeven
Reviewe
.
>
> Fixes: a94ee624292bff96 ("modetest: Add SMPTE test pattern")
> Signed-off-by: Geert Uytterhoeven
Reviewed-by: Laurent Pinchart
> ---
> tests/util/pattern.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/tests/util/pattern.c b
ivers/gpu/drm/vc4/vc4_gem.c | 12 +-
> > drivers/gpu/drm/vc4/vc4_irq.c | 2 +-
> > drivers/gpu/drm/vc4/vc4_plane.c | 14 +-
> > drivers/gpu/drm/vc4/vc4_render_cl.c | 40 +--
> > drivers/gpu/drm/vc4/vc4_txp.c | 8 +-
> > drivers/gpu/drm/vc4/vc4_v3d.c | 8 +-
> > drivers/gpu/drm/vc4/vc4_validate.c| 28 +-
> > drivers/gpu/drm/vc4/vc4_validate_shaders.c| 2 +-
> > drivers/gpu/drm/xlnx/Kconfig | 2 +-
> > drivers/gpu/drm/xlnx/zynqmp_disp.c| 8 +-
> > drivers/gpu/drm/xlnx/zynqmp_dpsub.c | 8 +-
> > ...rm_fb_cma_helper.h => drm_fb_dma_helper.h} | 10 +-
> > include/drm/drm_gem.h | 2 +-
> > ..._gem_cma_helper.h => drm_gem_dma_helper.h} | 158 -
> > 147 files changed, 899 insertions(+), 899 deletions(-)
> > rename drivers/gpu/drm/{drm_fb_cma_helper.c => drm_fb_dma_helper.c} (60%)
> > rename drivers/gpu/drm/{drm_gem_cma_helper.c => drm_gem_dma_helper.c}
> > (56%)
> > rename include/drm/{drm_fb_cma_helper.h => drm_fb_dma_helper.h} (56%)
> > rename include/drm/{drm_gem_cma_helper.h => drm_gem_dma_helper.h} (53%)
--
Regards,
Laurent Pinchart
pdata->dp_lanes = min(pdata->dp_lanes, max_dp_lanes);
> @@ -1047,8 +1054,9 @@ static void ti_sn_bridge_atomic_enable(struct
> drm_bridge *bridge,
> drm_dp_dpcd_writeb(>aux, DP_EDP_CONFIGURATION_SET,
> DP_ALTERNATE_SCRAMBLER_RESET_EN
idge */
> + /* Attach the next bridge, We never want the next bridge to *also*
> create a connector. */
s/bridge,/bridge./
I also would have wrapped this line.
Reviewed-by: Laurent Pinchart
> ret = drm_bridge_attach(bridge->encoder, pdata->next_bridge,
> -
j->paddr,
> attach->dmabuf->size);
> + DRM_DEBUG_PRIME("dma_addr = %pad, size = %zu\n", _obj->dma_addr,
> + attach->dmabuf->size);
The second line should be aligned left, just right of the opening
parenthesis.
Reviewed-by: Laurent Pinchart
>
> return _obj->base;
> }
[snip]
--
Regards,
Laurent Pinchart
Hi Danilo,
Thank you for the patch.
On Tue, Jul 05, 2022 at 11:26:13PM +0200, Danilo Krummrich wrote:
> Both, GEM and FB, CMA helpers were renamed to "GEM DMA" and "FB DMA",
> hence the task can be removed.
>
> Signed-off-by: Danilo Krummrich
e buffer
> * @dev: DRM device
> * @attach: DMA-BUF attachment
> * @sgt: Scatter/gather table of pinned pages
> *
> * This function imports a scatter/gather table using
> - * drm_gem_cma_prime_import_sg_table() and uses dma_buf_vmap() to get the
> kernel
> - * virtua
PL(drm_fb_cma_get_gem_addr);
> * in a plane's .atomic_update ensures that all the data in the backing
> * memory have been written to RAM.
> */
> -void drm_fb_cma_sync_non_coherent(struct drm_device *drm,
> +void drm_fb_dma_sync_non_coherent(struct drm_device *drm,
> struct drm_plane_
gpu/drm/vc4/vc4_drv.h | 18 +-
> > drivers/gpu/drm/vc4/vc4_gem.c | 4 +-
> > drivers/gpu/drm/vc4/vc4_plane.c | 10 +-
> > drivers/gpu/drm/vc4/vc4_render_cl.c | 26 +-
> > drivers/gpu/drm/vc4/vc4_txp.c | 6 +-
> > drivers/gpu/drm/vc4/vc4_v3d.c | 4 +-
> > drivers/gpu/drm/vc4/vc4_validate.c| 16 +-
> > drivers/gpu/drm/vc4/vc4_validate_shaders.c| 2 +-
> > drivers/gpu/drm/xlnx/Kconfig | 2 +-
> > drivers/gpu/drm/xlnx/zynqmp_disp.c| 4 +-
> > drivers/gpu/drm/xlnx/zynqmp_dpsub.c | 8 +-
> > ...rm_fb_cma_helper.h => drm_fb_dma_helper.h} | 10 +-
> > include/drm/drm_gem.h | 2 +-
> > ..._gem_cma_helper.h => drm_gem_dma_helper.h} | 154 -
> > 146 files changed, 777 insertions(+), 790 deletions(-)
> > rename drivers/gpu/drm/{drm_fb_cma_helper.c => drm_fb_dma_helper.c} (68%)
> > rename drivers/gpu/drm/{drm_gem_cma_helper.c => drm_gem_dma_helper.c}
> > (60%)
> > rename include/drm/{drm_fb_cma_helper.h => drm_fb_dma_helper.h} (56%)
> > rename include/drm/{drm_gem_cma_helper.h => drm_gem_dma_helper.h} (53%)
--
Regards,
Laurent Pinchart
Hi Rob,
On Mon, Jun 27, 2022 at 04:16:08PM -0600, Rob Herring wrote:
> On Thu, Jun 16, 2022 at 01:14:06AM +0300, Laurent Pinchart wrote:
> > Now that a header exists with macros for the media interface bus-type
> > values, replace hardcoding numerical constants with the correspon
On Fri, Jun 24, 2022 at 11:50:06PM +0200, Daniel Vetter wrote:
> On Sat, Jun 25, 2022 at 12:37:23AM +0300, Laurent Pinchart wrote:
> > Hi Daniel,
> >
> > On Fri, Jun 24, 2022 at 11:16:46PM +0200, Daniel Vetter wrote:
> > > On Thu, Jun 16, 2022 at 09:52:10PM
Hi Daniel,
On Fri, Jun 24, 2022 at 11:16:46PM +0200, Daniel Vetter wrote:
> On Thu, Jun 16, 2022 at 09:52:10PM +0300, Laurent Pinchart wrote:
> > Add FourCCs for two missing permutations of the packed YUV 4:4:4 color
>
> For a second I thought this 4:4:4 is the bit packing, b
ead from a register, not parsed from DT, so the message isn't
valid.
> + return -EINVAL;
> + }
> +
> + /*
> + * Used as a multiplication factor for HACT based on used
> + * DSI data type.
> + *
> + * e.g. for RGB666_L datatype and 192
e-endpoint = <_in>;
> +};
> + };
> +};
> +
> +panel@0 {
> + compatible = "auo,b101uan01";
> + reg = <0>;
> + port {
> +panel_in: endpoint {
> +remote-endpoint = <_dsi_out>;
> +};
> + };
> +};
Does this example validate (with `make dt_binding_check
DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/xlnx/xlnx,dsi-tx.yaml`)
without listing the panel node in the properties ?
> +};
> +
> +...
--
Regards,
Laurent Pinchart
nfig was missing some required dependencies so
> I never build tested it :/
>
> Cc: Hyun Kwon
> Cc: Laurent Pinchart
> Reported-by: Stephen Rothwell
> Fixes: 90bb087f6674 ("drm: Drop drm_blend.h from drm_crtc.h")
> Signed-off-by: Ville Syrjälä
Reviewed-
cking whether the backlight
> should be on at all, use backlight_get_brightness() which does all
> this and insulates this from future changes.
>
> Signed-off-by: Stephen Kitt
> Cc: Laurent Pinchart
> Cc: Kieran Bingham
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc:
uses DRM FourCCs
for pixel formats.
Signed-off-by: Laurent Pinchart
---
include/uapi/drm/drm_fourcc.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index f1972154a594..399d950c53e3 100644
--- a/include/uapi/drm/drm_fourcc.h
Now that a header exists with macros for the media interface bus-type
values, replace hardcoding numerical constants with the corresponding
macros in the DT sources.
Signed-off-by: Laurent Pinchart
---
arch/arm/boot/dts/r8a7742-iwg21d-q7-dbcm-ca.dts | 11 +++
.../dts/r8a7742
Now that a header exists with macros for the media interface bus-type
values, replace hardcoding numerical constants with the corresponding
macros in the DT sources.
Signed-off-by: Laurent Pinchart
---
arch/arm/boot/dts/stm32429i-eval.dts | 3 ++-
arch/arm/boot/dts/stm32mp157c-ev1.dts | 3
Now that a header exists with macros for the media interface bus-type
values, replace hardcoding numerical constants with the corresponding
macros in the DT sources.
Signed-off-by: Laurent Pinchart
---
arch/arm/boot/dts/omap3-n900.dts | 5 +++--
1 file changed, 3 insertions(+), 2 deletions
Now that a header exists with macros for the media interface bus-type
values, replace hardcoding numerical constants with the corresponding
macros in the DT sources.
Signed-off-by: Laurent Pinchart
---
arch/arm/boot/dts/imx6ul-14x14-evk.dtsi | 4 +++-
1 file changed, 3 insertions(+), 1 deletion
Now that a header exists with macros for the media interface bus-type
values, replace hardcoding numerical constants with the corresponding
macros in the DT binding examples.
Signed-off-by: Laurent Pinchart
---
Changes since v2:
- Go back to PARALLEL
Changes since v1:
- Rename PARALLEL
Add a new dt-bindings/media/video-interfaces.h header that defines
macros corresponding to the bus types from media/video-interfaces.yaml.
This allows avoiding hardcoded constants in device tree sources.
Signed-off-by: Laurent Pinchart
---
Changes since v2:
- Go back to PARALLEL
Changes since
doesn't actually describe what is usually referred
to as the parallel bus type. Patch 3/3 has been split in per-vendor
patches at the request of Alexandre Torgue.
Laurent Pinchart (6):
dt-bindings: media: Add macros for video interface bus types
dt-bindings: Use new video interface bus type
.atomic_get_input_bus_fmts = xlnx_dsi_bridge_get_input_bus_fmts,
> .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,
> };
[snip]
--
Regards,
Laurent Pinchart
(val, base + offset);
> > +}
> > +
> > +static inline u32 xlnx_dsi_readl(void __iomem *base, int offset)
> > +{
> > + return readl(base + offset);
> > +}
>
> When I see implementations like this I wonder if a regmap would be
> beneficial?
regmap often seems overkill to me when the driver only needs plain
32-bit mmio read/write, given the overhead it adds at runtime. Is it
just me ?
[snip]
--
Regards,
Laurent Pinchart
h .
> Add missing comma to drm_of_get_data_lanes_count_ep() .
>
> Fixes: fc801750b197 ("drm: of: Add drm_of_get_data_lanes_count and
> drm_of_get_data_lanes_ep")
> Reported-by: kernel test robot
> Signed-off-by: Marek Vasut
> Cc: Andrzej Hajda
> Cc: Laurent Pinch
Hi Liu,
On Fri, Jun 10, 2022 at 10:09:19AM +0800, Liu Ying wrote:
> On Thu, 2022-06-09 at 12:30 +0300, Laurent Pinchart wrote:
> > On Thu, Jun 09, 2022 at 02:49:23PM +0800, Liu Ying wrote:
> > > This patch adds a drm bridge driver for i.MX8qm/qxp display pixel
> > >
alpha channel as well.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
index 6b535abd799a..356861de17b0 100644
devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-link.yaml
> create mode 100644
> Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pxl2dpi.yaml
> create mode 100644 Documentation/devicetree/bindings/mfd/fsl,imx8qxp-csr.yaml
> create mode 100644 drivers/gpu/drm/bridge/imx/Kconfig
> create mode 100644 drivers/gpu/drm/bridge/imx/Makefile
> create mode 100644 drivers/gpu/drm/bridge/imx/imx-ldb-helper.c
> create mode 100644 drivers/gpu/drm/bridge/imx/imx-ldb-helper.h
> create mode 100644 drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c
> create mode 100644 drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c
> create mode 100644 drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c
> create mode 100644 drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c
> create mode 100644 drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c
--
Regards,
Laurent Pinchart
MST2_ENB;
> + pl->mst_vld_ctrl = IMX_SC_C_PXL_LINK_MST2_VLD;
> + pl->sync_ctrl = IMX_SC_C_SYNC_CTRL1;
> + }
> +
> + /* disable all controls to POR default */
> + ret = imx8qxp_pixel_link_disable_all_controls(pl);
> + if (ret)
> + return ret;
> +
> + pl->next_bridge = imx8qxp_pixel_link_find_next_bridge(pl);
> + if (IS_ERR(pl->next_bridge)) {
> + ret = PTR_ERR(pl->next_bridge);
> + if (ret != -EPROBE_DEFER)
> + DRM_DEV_ERROR(dev, "failed to find next bridge: %d\n",
> + ret);
> + return ret;
> + }
> +
> + platform_set_drvdata(pdev, pl);
> +
> + pl->bridge.driver_private = pl;
> + pl->bridge.funcs = _pixel_link_bridge_funcs;
> + pl->bridge.of_node = np;
> +
> + drm_bridge_add(>bridge);
> +
> + return ret;
> +}
> +
> +static int imx8qxp_pixel_link_bridge_remove(struct platform_device *pdev)
> +{
> + struct imx8qxp_pixel_link *pl = platform_get_drvdata(pdev);
> +
> + drm_bridge_remove(>bridge);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id imx8qxp_pixel_link_dt_ids[] = {
> + { .compatible = "fsl,imx8qm-dc-pixel-link", },
> + { .compatible = "fsl,imx8qxp-dc-pixel-link", },
> + { /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, imx8qxp_pixel_link_dt_ids);
> +
> +static struct platform_driver imx8qxp_pixel_link_bridge_driver = {
> + .probe = imx8qxp_pixel_link_bridge_probe,
> + .remove = imx8qxp_pixel_link_bridge_remove,
> + .driver = {
> + .of_match_table = imx8qxp_pixel_link_dt_ids,
> + .name = DRIVER_NAME,
> + },
> +};
> +module_platform_driver(imx8qxp_pixel_link_bridge_driver);
> +
> +MODULE_DESCRIPTION("i.MX8QXP/QM display pixel link bridge driver");
> +MODULE_AUTHOR("Liu Ying ");
> +MODULE_LICENSE("GPL v2");
> +MODULE_ALIAS("platform:" DRIVER_NAME);
--
Regards,
Laurent Pinchart
+dc0_pixel_combiner_ch0_dc0_pixel_link0: endpoint {
> +remote-endpoint =
> <_pixel_link0_dc0_pixel_combiner_ch0>;
> + };
> +};
> +};
> +
> +channel@1 {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +reg = <1>;
> +
> +port@0 {
> +reg = <0>;
> +
> +dc0_pixel_combiner_ch1_dc0_dpu_disp1: endpoint {
> +remote-endpoint =
> <_dpu_disp1_dc0_pixel_combiner_ch1>;
> +};
> +};
> +
> +port@1 {
> +reg = <1>;
> +
> +dc0_pixel_combiner_ch1_dc0_pixel_link1: endpoint {
> +remote-endpoint =
> <_pixel_link1_dc0_pixel_combiner_ch1>;
> +};
> +};
> +};
> +};
--
Regards,
Laurent Pinchart
this and insulates this from future changes.
> >
> > Signed-off-by: Stephen Kitt
> > Cc: Laurent Pinchart
> > Cc: Kieran Bingham
> > Cc: David Airlie
> > Cc: Daniel Vetter
> > Cc: dri-devel@lists.freedesktop.org
> > ---
> > drivers/gpu/drm
driver fails, mipi_dsi_driver_register
> should be reverted.
>
> Fixes: 1e4d58cd7f88 ("drm/bridge: adv7533: Create a MIPI DSI device")
> Signed-off-by: Jiasheng Jiang
Reviewed-by: Laurent Pinchart
> ---
> Changelog:
>
> v1 -> v2
>
> *Change 1. Add the mipi_dsi_driver_u
On Wed, Jun 01, 2022 at 04:45:01PM +0800, Jiasheng Jiang wrote:
> On Wed, Jun 01, 2022 at 02:52:00PM +0800, Laurent Pinchart wrote:
> >> static int __init adv7511_init(void)
> >> {
> >> - if (IS_ENABLED(CONFIG_DRM_MIPI_DSI))
> >> - mipi_dsi_driver
return ret;
> + }
>
> return i2c_add_driver(_driver);
While at it, should this then call mipi_dsi_driver_unregister() on
failure ?
> }
> --
> 2.25.1
>
--
Regards,
Laurent Pinchart
e example.
>
> Signed-off-by: Rob Herring
Reviewed-by: Laurent Pinchart
> ---
> .../devicetree/bindings/display/bridge/ingenic,jz4780-hdmi.yaml | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git
> a/Documentation/devicetree/bindings/display/bridge/ingenic,jz4780-hdmi.y
gt; + return ret;
> +
> + ret = clk_bulk_prepare_enable(num_clks, dsi->clks);
As this will become the only use of num_clks, I'd write
ret = clk_bulk_prepare_enable(ARRAY_SIZE(xdsi_clks), dsi->clks);
and drop the local variable. Same in remove().
Actually, shouldn't the driver implement runtime PM suspand and resume
handlers, and enable/disable clocks there ?
> + if (ret)
> + goto err_clk_put;
> +
> + platform_set_drvdata(pdev, dsi);
> + dsi->dsi_host.ops = _dsi_ops;
> + dsi->dsi_host.dev = dev;
> +
> + ret = mipi_dsi_host_register(>dsi_host);
> + if (ret) {
> + dev_err(dev, "Failed to register MIPI host: %d\n", ret);
> + goto err_clk_put;
> + }
> +
> + dsi->bridge.driver_private = dsi;
> + dsi->bridge.funcs = _dsi_bridge_funcs;
> +#ifdef CONFIG_OF
You depend on OF, so this isn't needed.
> + dsi->bridge.of_node = pdev->dev.of_node;
> +#endif
> +
> + drm_bridge_add(>bridge);
> +
> +err_clk_put:
> + clk_bulk_put(num_clks, dsi->clks);
> +
> + return ret;
> +}
> +
> +static int xlnx_dsi_remove(struct platform_device *pdev)
> +{
> + struct xlnx_dsi *dsi = platform_get_drvdata(pdev);
> + int num_clks = ARRAY_SIZE(xdsi_clks);
> +
> + mipi_dsi_host_unregister(>dsi_host);
> + clk_bulk_disable_unprepare(num_clks, dsi->clks);
> + clk_bulk_put(num_clks, dsi->clks);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id xlnx_dsi_of_match[] = {
> + { .compatible = "xlnx,dsi-tx-v2.0"},
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, xlnx_dsi_of_match);
> +
> +static struct platform_driver dsi_driver = {
> + .probe = xlnx_dsi_probe,
> + .remove = xlnx_dsi_remove,
> + .driver = {
> + .name = "xlnx-dsi",
> + .of_match_table = xlnx_dsi_of_match,
> + },
> +};
> +
> +module_platform_driver(dsi_driver);
> +
> +MODULE_AUTHOR("Venkateshwar Rao G ");
> +MODULE_DESCRIPTION("Xilinx MIPI DSI host controller driver");
> +MODULE_LICENSE("GPL");
--
Regards,
Laurent Pinchart
#address-cells = <1>;
> +reg = <0>;
> +mipi_dsi_in: endpoint@0 {
> +reg = <0>;
With a single endpoint you can drop the reg as well as the @0, and the
size and address cells in the parent.
> +remote-endpoint = <_disp_crtc>;
> +};
> +};
> +port@1 {
> +reg = <1>;
> +mipi_dsi_out: endpoint {
> +remote-endpoint = <_in>;
> +};
> +};
> +};
> +};
--
Regards,
Laurent Pinchart
disable = cdns_dsi_bridge_disable,
> + .pre_enable = cdns_dsi_bridge_pre_enable,
> .enable = cdns_dsi_bridge_enable,
> + .post_disable = cdns_dsi_bridge_post_disable,
> };
>
> static int cdns_dsi_attach(struct mipi_dsi_host *host,
--
Regards,
Laurent Pinchart
On Mon, May 02, 2022 at 09:28:45PM +0200, Javier Martinez Canillas wrote:
> On 5/2/22 20:36, Laurent Pinchart wrote:
> > On Mon, May 02, 2022 at 07:15:16PM +0200, Javier Martinez Canillas wrote:
> >> On 5/2/22 18:55, Javier Martinez Canillas wrote:
> >>
> >&g
b_helper->preferred_bpp = preferred_bpp;
> ...
> }
>
> [0]:
> https://elixir.bootlin.com/linux/v5.18-rc5/source/drivers/gpu/drm/drm_fb_helper.c#L2553
--
Regards,
Laurent Pinchart
Hi Javier,
On Mon, May 02, 2022 at 07:09:17PM +0200, Javier Martinez Canillas wrote:
> On 5/2/22 18:17, Laurent Pinchart wrote:
> > On Mon, May 02, 2022 at 05:39:00PM +0200, Javier Martinez Canillas wrote:
> >> Indicate to fbdev subsystem that the registered frame
>
> drm_WARN(dev, !dev->registered, "Device has not been registered.\n");
> @@ -2570,6 +2577,8 @@ void drm_fbdev_generic_setup(struct drm_device *dev,
> unsigned int options)
> preferred_bpp = 32;
> fb_helper->preferred_bpp =
ers
> for computing options bitfield values and getting the values respectively
>
> For now, only the DRM_FB_BPP option exists but other options can be added.
>
> Suggested-by: Thomas Zimmermann
> Signed-off-by: Javier Martinez Canillas
> Reviewed-by: Thomas Zimmermann
> Revi
>
> Passing the same value to the function is unnecessary. Let's cleanup that
> in the two drivers that do it.
This looks fine, so
Reviewed-by: Laurent Pinchart
but why do we have two different mechanisms to set the preferred depth ?
Could we get all drivers to set dev->mode_config.
nt options for the emulated framebuffer device registered.
> + *
> + * The options must be set using DRM_FB_SET_OPTION() and obtained using
> + * DRM_FB_GET_OPTION(). The options field are the following:
> + *
> + * * DRM_FB_BPP: bits per pixel for the device. If the field is not set,
> + * @dev->
Hi Maxime,
On Fri, Apr 29, 2022 at 05:46:45PM +0200, Maxime Ripard wrote:
> On Fri, Apr 29, 2022 at 01:17:26AM +0300, Laurent Pinchart wrote:
> > On Thu, Apr 28, 2022 at 02:09:42PM +0530, Jagan Teki wrote:
> > > On Wed, Apr 27, 2022 at 8:04 PM Maxime Ripard wrote:
> >
t; > > >
> > > > I really don't have a clear idea of which driver would need to be
> > > > switched
> > > > over though. Could someone (Jagan?) let me know where it would be
> > > > needed?
> > >
> > > sun6i_mipi_dsi
> >
> > It doesn't look like sun6i_mipi_dsi is using devm_drm_of_get_bridge at all?
>
> Correct, patch for this on the mailing list.
I've lost track of how we're solving the fallout of this for v5.18. I
have received a report that the original commit (80253168dbfd) also
broke the rcar-du driver. Could you please provide a git branch (based
on drm-fixes or drm-misc-fixes) with any patch that you plan to get
merged in v5.18, to let me test them locally ?
> > > exynos_drm_dsi
> >
> > If you reference 711c7adc4687, I don't see why we would need to switch
> > it back to the old behaviour. It wasn't iterating over its child node
> > before, so what does the switch to drm_of_get_bridge broke exactly?
>
> Exynos bindings have a child node (unlike OF-graph), the old code is
> checking panel and bridge individually so it broke once switch to
> devm_drm_of_get_bridge
--
Regards,
Laurent Pinchart
tform driver remove callbacks is
> ignored anyway. This prepares making i2c and platform remove callbacks
> return void, too.
>
> Signed-off-by: Uwe Kleine-König
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/ti-tfp410.c | 12 +++-
> 1 file chan
s/gpu/drm/i915/i915_pci.c | 7 +-
> > drivers/gpu/drm/i915/i915_reg.h | 139 +++
> > 15 files changed, 1742 insertions(+), 3 deletions(-) create mode 100644
> > drivers/gpu/drm/i915/display/intel_wb_connector.c
> > create mode 100644 drivers/gpu/drm/i915/display/intel_wb_connector.h
> > create mode 100644 drivers/gpu/drm/i915/display/intel_wd.c
> > create mode 100644 drivers/gpu/drm/i915/display/intel_wd.h
--
Regards,
Laurent Pinchart
ti/affine/hwd_affine_reg.h
> create mode 100644 drivers/soc/visconti/ipa_common.c
> create mode 100644 drivers/soc/visconti/ipa_common.h
> create mode 100644 drivers/soc/visconti/uapi/affine.h
> create mode 100644 drivers/soc/visconti/uapi/ipa.h
--
Regards,
Laurent Pinchart
On Tue, Apr 26, 2022 at 02:54:01PM +0200, Maxime Ripard wrote:
> On Tue, Apr 26, 2022 at 02:41:44PM +0200, Paul Kocialkowski wrote:
> > On Tue 26 Apr 22, 14:33, Laurent Pinchart wrote:
> > > On Tue, Apr 26, 2022 at 09:54:36AM +0200, Paul Kocialkowski wrote:
> > > >
ame_eq(remote, "port") ||
> + of_node_name_eq(remote, "ports"))
> + continue;
> +
> + if (!(of_node_name_eq(remote, "aux-bus") &&
> + of_get_child_by_name(remote, "panel")))
> + continue;
> +
> + goto of_find_panel_or_bridge;
> + }
> +
> /*
> * of_graph_get_remote_node() produces a noisy error message if port
> * node isn't found and the absence of the port is a legit case here,
> @@ -254,6 +273,8 @@ int drm_of_find_panel_or_bridge(const struct
> device_node *np,
> return -ENODEV;
>
> remote = of_graph_get_remote_node(np, port, endpoint);
> +
> +of_find_panel_or_bridge:
> if (!remote)
> return -ENODEV;
--
Regards,
Laurent Pinchart
oDSPR2= 0x 0003 and DSPR3= 0x 0001
>
> This patch set PnALPHAR register to 0 to avoid this issue.
>
> Signed-off-by: LUU HOAI
> Signed-off-by: Biju Das
Reviewed-by: Laurent Pinchart
> ---
> v1->v2:
> * Updated commit description
> * Updated the code comment
On Tue, Apr 26, 2022 at 05:11:41AM +0300, Dmitry Baryshkov wrote:
> On 26/04/2022 03:32, Laurent Pinchart wrote:
> > On Sun, Apr 24, 2022 at 05:32:06PM -0700, Abhinav Kumar wrote:
> >> Initialize dpu encoder and connector for writeback if the
> >> target
add one for the child node case, maybe:
> drm_of_find_child_panel_or_bridge.
>
> I really don't have a clear idea of which driver would need to be switched
> over though. Could someone (Jagan?) let me know where it would be needed?
>
> Are there cases where we could both expect of graph and child node?
> (i.e. does the new helper also need to try via of graph?)
I still think we should use OF graph uncondtionally, even in the DSI
case. We need to ensure backward-compatibility, but I'd like new
bindings (and thus new drivers) to always use OF graph.
--
Regards,
Laurent Pinchart
6 +718,21 @@ static int _dpu_kms_setup_displays(struct drm_device
> *dev,
> return rc;
> }
>
> + /* Since WB isn't a driver check the catalog before initializing */
> + if (dpu_kms->catalog->wb_count) {
> + for (i = 0; i < dpu_kms->catalog->wb_count; i++) {
> + if (dpu_kms->catalog->wb[i].id == WB_2) {
> + rc = _dpu_kms_initialize_writeback(dev, priv,
> dpu_kms,
> +
> dpu_kms->catalog->wb[i].format_list,
> +
> dpu_kms->catalog->wb[i].num_formats);
> + if (rc) {
> + DPU_ERROR("initialize_WB failed, rc =
> %d\n", rc);
> + return rc;
> + }
> + }
> + }
> + }
> +
> return rc;
> }
>
--
Regards,
Laurent Pinchart
On Mon, Apr 25, 2022 at 10:48:07AM -0700, Abhinav Kumar wrote:
> On 4/25/2022 10:32 AM, Laurent Pinchart wrote:
> > On Mon, Apr 25, 2022 at 01:50:43PM +0300, Dmitry Baryshkov wrote:
> >> On Sun, 24 Apr 2022 at 22:59, Laurent Pinchart wrote:
> >>> On Sun, Apr 24, 202
On Mon, Apr 25, 2022 at 01:50:43PM +0300, Dmitry Baryshkov wrote:
> On Sun, 24 Apr 2022 at 22:59, Laurent Pinchart wrote:
> > On Sun, Apr 24, 2022 at 11:23:20AM -0700, Abhinav Kumar wrote:
> > > On 4/24/2022 11:12 AM, Abhinav Kumar wrote:
> > > > On 4/24/2022 7
y the driver, issues related to alpha blending (such as
* incorrect colors or planes being invisible) may still occur if the PnALPHAR
* register has a stale value. Set the register to 0 to avoid this.
*/
> Here the issue they mentioned as "register is not initialized by reset"
>
> > > + rcar_du_plane_write(rgrp, index, PnALPHAR, 0x);
I'd write 0 instead of 0x to match the rest of the driver.
Would you mind sending a v2 with these changed and an expanded commit
message ?
> > > }
> > >
> > > static void rcar_du_plane_setup_format(struct rcar_du_group *rgrp,
--
Regards,
Laurent Pinchart
Suggested-by: Geert Uytterhoeven
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_cmm.c | 2 +-
drivers/gpu/drm/rcar-du/rcar_cmm.h | 2 +-
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 2 +-
drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 2 +-
drivers/gpu/drm
Hi Abhinav,
On Sun, Apr 24, 2022 at 11:23:20AM -0700, Abhinav Kumar wrote:
> On 4/24/2022 11:12 AM, Abhinav Kumar wrote:
> > On 4/24/2022 7:50 AM, Laurent Pinchart wrote:
> >> On Fri, Apr 22, 2022 at 04:06:38PM -0700, Abhinav Kumar wrote:
> >>> For some vendor d
l off them if we are planning to do.
>
> Laurent, please share your thoughts on this.
Geert has a point, the file names cause issues and don't add much value.
Would you like to send a patch to drop them all, to replace this one ? I
can also handle it myself if you prefer.
--
Regards,
Laurent Pinchart
e on Gen3.
Furthermore, is this really the right fix, shouldn't we instead avoid
enabling alpha-blending in PnMR on Gen3 ?
> + rcar_du_plane_write(rgrp, index, PnALPHAR, 0x);
> }
>
> static void rcar_du_plane_setup_format(struct rcar_du_group *rgrp,
--
Regards,
Laurent Pinchart
* hardware.
> + *
> + * For current existing writeback users, this shall continue to be the
> + * embedded encoder for the writeback connector.
> + */
> + struct drm_encoder *encoder;
> +
> + /**
> + * @internal_encoder: internal encoder used by writeback when
> + * drm_writeback_connector_init() is used.
> + * @encoder will be assigned to this for those cases
> + *
> + * This will be unused when drm_writeback_connector_init_with_encoder()
> + * is used.
>*/
> - struct drm_encoder encoder;
> + struct drm_encoder internal_encoder;
>
> /**
>* @pixel_formats_blob_ptr:
--
Regards,
Laurent Pinchart
r and its properties
> + * using the encoder which already assigned and initialized
That sounds a bit convoluted to me. How about
* drm_writeback_connector_init_with_encoder - Initialize a writeback connector
* with a custom encoder
Reviewed-by: Laurent Pinchart
> + *
> + * @dev: D
move parenthesis where not needed
> - use u32 instead of uint32_t for possible_crtcs
>
> Signed-off-by: Abhinav Kumar
> Acked-by: Liviu Dudau
> Reviewed-by: Dmitry Baryshkov
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c |
y invest some time to upstream it.
Absolutely ! I'm all for helping debugging.
> Thank you for your attention and feedback.
>
> [1] https://github.com/renesas-rcar/linux-bsp/commit/12ea79975a10f
> ("v4l: vsp1: Add underrun debug messege option")
--
Regards,
Laurent Pinchart
connector->funcs->reset(connector);
> > > + drm_connector_register(connector);
> > > + }
> >
> > Reviewed-by: Jagan Teki
>
> Fixed typos in commit message.
>
> Reviewed-by: Robert Foss
>
> Applied to drm-misc-next
Doesn't this open the door to various race conditions ?
Also, what happens if the panel bridge is detached and reattached ? If I
recall correctly, registering new connectors at runtime is at least
partly supported for DP MST, but I'm not sure about unregistration.
--
Regards,
Laurent Pinchart
M_BRIDGE_OP_HPD based on HPD interrupt availability, so that
> it will fall back to polling, if HPD is not available.
>
> Signed-off-by: Biju Das
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 6 --
> 1 file changed, 4 insertions(+
Alexander Stein
> Signed-off-by: Marek Vasut
> Cc: Alexander Stein
> Cc: Laurent Pinchart
> Cc: Lucas Stach
> Cc: Peng Fan
> Cc: Robby Cai
> Cc: Sam Ravnborg
> Cc: Stefan Agner
Reviewed-by: Laurent Pinchart
> ---
> V2: Add AB from Alexander
> ---
> driv
return 0;
>
> - return rcar_du_atomic_check_planes(dev, state);
> + return rcdu->info->fns->du_atomic_check_planes(dev, state);
> }
>
> static void rcar_du_atomic_commit_tail(struct drm_atomic_state *old_state)
> @@ -882,7 +882,7 @@ int rcar_du_modeset_init(struct rcar_du_device *rcdu)
> : 0;
>
> if (!rcar_du_has(rcdu, RCAR_DU_FEATURE_VSP1_SOURCE)) {
> - ret = rcar_du_planes_init(rgrp);
> + ret = rcdu->info->fns->du_planes_init(rgrp);
> if (ret < 0)
> return ret;
> }
> @@ -910,7 +910,7 @@ int rcar_du_modeset_init(struct rcar_du_device *rcdu)
>
> rgrp = >groups[hwindex / 2];
>
> - ret = rcar_du_crtc_create(rgrp, swindex++, hwindex);
> + ret = rcdu->info->fns->du_crtc_create(rgrp, swindex++, hwindex);
> if (ret < 0)
> return ret;
> }
--
Regards,
Laurent Pinchart
ev/null
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_common.c
> @@ -0,0 +1,30 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * rcar_du_common.c -- R-Car Display Unit Common
> + *
> + * Copyright (C) 2013-2022 Renesas Electronics Corporation
> + *
> + * Contact: Laurent Pinchart
* The Gen3 DU uses the VSP1 for memory access, and is limited
> - * to frame sizes of 8190x8190.
> - */
> - dev->mode_config.max_width = 8190;
> - dev->mode_config.max_height = 8190;
> - }
> + /*
> + * The Gen3 DU uses the VSP1 for memory access, and is limited
> + * to frame sizes of 8190x8190.
> + */
This comment doesn't make much sense here anymore, but I think it's
useful to keep the information. How about defining macros for the
maximum width and height on different platforms, and moving the comment
just before the macro definitions ?
> + dev->mode_config.max_width = rcdu->info->max_width;
> + dev->mode_config.max_height = rcdu->info->max_height;
>
> rcdu->num_crtcs = hweight8(rcdu->info->channels_mask);
>
--
Regards,
Laurent Pinchart
},
> + .num_rpf = 5,
> .dsi_clk_mask = BIT(1) | BIT(0),
> };
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> index 101f42df86ea..68c5de59d18d 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> +++ b/dr
port@3: false
> +
> + required:
> +- port@0
> +- port@1
> +
> + renesas,vsps:
> + maxItems: 1
> +
> + required:
> +- clock-names
> +- interrupts
> +- resets
> +- reset-names
> +- renesas,vsps
> +
> additionalProperties: false
>
> examples:
--
Regards,
Laurent Pinchart
TP BIT(16)
> +
> +/* Reset Status Register */
> +#define RSTSR 0x114
> +#define RSTSR_DL0DIR BIT(15)
> +#define RSTSR_DLSTPST(0xf << 8)
> +#define RSTSR_SWRSTV1BIT(4)
> +#define RSTSR_SWRSTIBBIT(3)
> +#define RSTSR_SWRSTAPB BIT(2)
> +#define RSTSR_SWRSTLPBIT(1)
> +#define RSTSR_SWRSTHSBIT(0)
> +
> +/* Clock Lane Stop Time Set Register */
> +#define CLSTPTSETR 0x314
> +#define CLSTPTSETR_CLKKPT(x) ((x) << 24)
> +#define CLSTPTSETR_CLKBFHT(x)((x) << 16)
> +#define CLSTPTSETR_CLKSTPT(x)((x) << 2)
> +
> +/* LP Transition Time Set Register */
> +#define LPTRNSTSETR 0x318
> +#define LPTRNSTSETR_GOLPBKT(x) ((x) << 0)
> +
> +/* Physical Lane Status Register */
> +#define PLSR 0x320
> +#define PLSR_CLHS2LP BIT(27)
> +#define PLSR_CLLP2HS BIT(26)
> +
> +/* Video-Input Channel 1 Set 0 Register */
> +#define VICH1SET0R 0x400
> +#define VICH1SET0R_VSEN BIT(12)
> +#define VICH1SET0R_HFPNOLP BIT(10)
> +#define VICH1SET0R_HBPNOLP BIT(9)
> +#define VICH1SET0R_HSANOLP BIT(8)
> +#define VICH1SET0R_VSTPAFT BIT(1)
> +#define VICH1SET0R_VSTARTBIT(0)
> +
> +/* Video-Input Channel 1 Set 1 Register */
> +#define VICH1SET1R 0x404
> +#define VICH1SET1R_DLY(x)(((x) & 0xfff) << 2)
> +
> +/* Video-Input Channel 1 Status Register */
> +#define VICH1SR 0x410
> +#define VICH1SR_VIRDYBIT(3)
> +#define VICH1SR_RUNNING BIT(2)
> +#define VICH1SR_STOP BIT(1)
> +#define VICH1SR_STARTBIT(0)
> +
> +/* Video-Input Channel 1 Pixel Packet Set Register */
> +#define VICH1PPSETR 0x420
> +#define VICH1PPSETR_DT_RGB18 (0x1e << 16)
> +#define VICH1PPSETR_DT_RGB18_LS (0x2e << 16)
> +#define VICH1PPSETR_DT_RGB24 (0x3e << 16)
> +#define VICH1PPSETR_TXESYNC_PULSEBIT(15)
> +#define VICH1PPSETR_VC(x)((x) << 22)
> +
> +/* Video-Input Channel 1 Vertical Size Set Register */
> +#define VICH1VSSETR 0x428
> +#define VICH1VSSETR_VACTIVE(x) (((x) & 0x7fff) << 16)
> +#define VICH1VSSETR_VSPOL_LOWBIT(15)
> +#define VICH1VSSETR_VSPOL_HIGH (0 << 15)
> +#define VICH1VSSETR_VSA(x) (((x) & 0xfff) << 0)
> +
> +/* Video-Input Channel 1 Vertical Porch Set Register */
> +#define VICH1VPSETR 0x42C
This is the only address written as an uppercase hex value.
> +#define VICH1VPSETR_VFP(x) (((x) & 0x1fff) << 16)
> +#define VICH1VPSETR_VBP(x) (((x) & 0x1fff) << 0)
> +
> +/* Video-Input Channel 1 Horizontal Size Set Register */
> +#define VICH1HSSETR 0x430
> +#define VICH1HSSETR_HACTIVE(x) (((x) & 0x7fff) << 16)
> +#define VICH1HSSETR_HSPOL_LOWBIT(15)
> +#define VICH1HSSETR_HSPOL_HIGH (0 << 15)
> +#define VICH1HSSETR_HSA(x) (((x) & 0xfff) << 0)
> +
> +/* Video-Input Channel 1 Horizontal Porch Set Register */
> +#define VICH1HPSETR 0x434
> +#define VICH1HPSETR_HFP(x) (((x) & 0x1fff) << 16)
> +#define VICH1HPSETR_HBP(x) (((x) & 0x1fff) << 0)
> +
> +#endif /* __RZG2L_MIPI_DSI_REGS_H__ */
--
Regards,
Laurent Pinchart
701 - 800 of 8956 matches
Mail list logo
