ANEL_DSI_CM=m
> +CONFIG_DRM_PANEL_DSI_CM=m
Is thi the right location, have you regenerated the defconfig from a
.config, or just renamed the option ? With the location fixed if needed,
Reviewed-by: Laurent Pinchart
> CONFIG_DRM_TILCDC=m
> CONFIG_DRM_PA
Hi Tomi,
Thank you for the patch.
On Thu, Nov 05, 2020 at 02:03:30PM +0200, Tomi Valkeinen wrote:
> The functions in display.c are not used, so drop the file.
>
> Signed-off-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/omapdrm/Makefile |
config(struct omap_dss_device
> *dssdev,
> dssdev->dss->mgr_ops->set_lcd_config(dssdev->dss->mgr_ops_priv,
>dssdev->dispc_channel, config);
> }
> -EXPORT_SYMBOL(dss_mgr_set_lcd_config);
>
> int dss_mgr_enabl
Hi Tomi,
Thank you for the patch.
On Thu, Nov 05, 2020 at 02:03:31PM +0200, Tomi Valkeinen wrote:
> dssdev->owner is set, but never used. We can drop the field.
>
> Signed-off-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/omapdrm/dss/dpi.c
dispc_ops and use direct
> calls to dispc.
>
> Signed-off-by: Tomi Valkeinen
Acked-by: Laurent Pinchart
> ---
> drivers/gpu/drm/omapdrm/dss/base.c| 6 --
> drivers/gpu/drm/omapdrm/dss/dispc.c | 101 +++---
> drivers/gpu/d
Hi Tomi,
Thank you for the patch.
On Thu, Nov 05, 2020 at 02:03:33PM +0200, Tomi Valkeinen wrote:
> dss_mgr_ops was needed with the multi-module architecture, but is no
> longer needed. We can thus remove it and use direct calls.
>
> Signed-off-by: Tomi Valkeinen
Acked-by: Laur
scription: |
> + phandle to an 'endpoint' subnode of a remote device node.
> +$ref: /schemas/types.yaml#/definitions/phandle
> +
> +required:
> + - remote-endpoint
As noted elsewhere, this shouldn't be required.
Sho
Hi Rob,
Thank you for the patch.
On Mon, Nov 02, 2020 at 02:36:55PM -0600, Rob Herring wrote:
> Now that we have a graph schema, reference it from the usb-connector
> schema.
>
> Signed-off-by: Rob Herring
Reviewed-by: Laurent Pinchart
> ---
> v3: new patch
>
>
Hi Rob,
Thank you for the patch.
On Mon, Nov 02, 2020 at 02:36:56PM -0600, Rob Herring wrote:
> Now that we have a graph schema, reference it from the common panel
> schema.
>
> Cc: Thierry Reding
> Cc: Sam Ravnborg
> Cc: Laurent Pinchart
> Signed-off-by: Rob Herring
Hi Rob,
On Wed, Nov 11, 2020 at 08:25:40AM -0600, Rob Herring wrote:
> On Wed, Nov 11, 2020 at 8:00 AM Laurent Pinchart wrote:
> > On Mon, Nov 02, 2020 at 02:36:54PM -0600, Rob Herring wrote:
> > > From: Sameer Pujar
> > >
> > > Convert device tree binding
Hi Tomi,
On Wed, Nov 11, 2020 at 05:34:52PM +0200, Tomi Valkeinen wrote:
> On 09/11/2020 12:10, Laurent Pinchart wrote:
> > On Thu, Nov 05, 2020 at 02:03:07PM +0200, Tomi Valkeinen wrote:
> >> From: Sebastian Reichel
> >>
> >> This moves the panel re
Hi Rob,
On Wed, Nov 11, 2020 at 05:03:26PM -0600, Rob Herring wrote:
> On Wed, Nov 11, 2020 at 8:27 AM Laurent Pinchart wrote:
> > On Wed, Nov 11, 2020 at 08:25:40AM -0600, Rob Herring wrote:
> > > On Wed, Nov 11, 2020 at 8:00 AM Laurent Pinchart wrote:
> > > > On M
Hi Tomi,
On Thu, Nov 12, 2020 at 10:08:21AM +0200, Tomi Valkeinen wrote:
> On 11/11/2020 17:58, Laurent Pinchart wrote:
>
> >>>> diff --git a/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
> >>>> b/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
> >&
Thierry Reding
> Cc: Sam Ravnborg
> Cc: Laurent Pinchart
> Cc: Maxime Ripard
> Cc: Maarten Lankhorst
> Cc: Thomas Zimmermann
> Signed-off-by: Rob Herring
> ---
> graph.yaml is in the dtschema repo, so this can go into drm-misc and
> hopefully anythin
ernej Skrabec
> S: Maintained
> T: git git://anongit.freedesktop.org/drm/drm-misc
> +F: Documentation/devicetree/bindings/display/bridge/
> F: drivers/gpu/drm/bridge/
>
> DRM DRIVERS FOR EXYNOS
--
Regards,
Laurent Pinchart
fundamentally the DT excerpt Jagan provided is
> correct. If the bridge supports DCS, there's no reason to use the OF
> graph in the first place: the bridge node will be a child node of the
> MIPI-DSI controller (and there's no obligation to use the OF-graph for a
> MIPI-DSI controller).
>
> I believe port@0 should be made optional (or downright removed if
> MIPI-DCS in the only control bus).
I think we should make ports mandatory in all cases actually.
The DT parent-child hierarchy is meant to model control relations
between devices, so a DSI device controlled through DCS should be a
child of the DSI controller. No disagreement there.
The OF graph is meant to model data connections. While a DSI device
controlled through DCS will use the same DSI link for data transfer, the
two concepts are different. We have taken shortcuts and decided to not
use OF graph for some DSI devices (not necessarily as a well thought
decision, it was sometimes just not considered). This has led to
different issues that we're having to deal with today, making it more
difficult to develop generic code. Going forward, I think new bindings
should always use OF graph to model the data connection.
--
Regards,
Laurent Pinchart
Hi Maxime,
On Thu, Mar 10, 2022 at 11:57:38AM +0100, Maxime Ripard wrote:
> On Thu, Mar 10, 2022 at 12:42:12PM +0200, Laurent Pinchart wrote:
> > On Tue, Mar 08, 2022 at 01:51:40PM +0100, Maxime Ripard wrote:
> > > On Tue, Mar 08, 2022 at 11:29:59AM +0100, Marek Vasut wrote:
&g
Hi Kieran,
Thank you for the patch.
On Thu, Mar 10, 2022 at 03:22:25PM +, Kieran Bingham wrote:
> From: Laurent Pinchart
>
> Despite the SN65DSI86 being an eDP bridge, on some systems its output is
> routed to a DisplayPort connector. Enable DisplayPort mode when the next
&g
Hi Kieran,
Thank you for the patch.
On Thu, Mar 10, 2022 at 03:22:26PM +, Kieran Bingham wrote:
> From: Laurent Pinchart
>
> Implement the bridge connector-related .get_edid() operation, and report
> the related bridge capabilities and type.
>
> Signed-off-by: Laurent
description: Number of DSI data lanes connected to the DSI host.
> $ref: /schemas/types.yaml#/definitions/uint32
--
Regards,
Laurent Pinchart
ling mode only for now.
Don't we support IRQ mode too now ?
> The implementation is limited to the bridge operations, as the connector
> operations are legacy and new users should use
> DRM_BRIDGE_ATTACH_NO_CONNECTOR.
>
> Signed-off-by: Laurent Pinchart
> Signed-off-by:
<< drm_crtc_index(&rcrtc->crtc);
> + wb_conn->encoder = kzalloc(sizeof(struct drm_encoder), GFP_KERNEL);
Where is this freed ?
> + wb_conn->encoder->possible_crtcs = 1 << drm_crtc_index(&rcrtc->crtc);
> drm_connector_helper_add(&wb_conn->base,
>&rcar_du_wb_conn_helper_funcs);
>
--
Regards,
Laurent Pinchart
*
> > +* For some vendor drivers, the hardware resources are shared
> > between
> > +* writeback encoder and rest of the display pipeline.
> > +* To accommodate such cases, encoder is a handle to the real
> > encoder
> > +* hardware.
> > +*
> > +* For current existing writeback users, this shall continue to be
> > the
> > +* embedded encoder for the writeback connector.
> > +*
> > */
> > - struct drm_encoder encoder;
> > + struct drm_encoder *encoder;
> >
> > /**
> > * @pixel_formats_blob_ptr:
--
Regards,
Laurent Pinchart
Hi Abhinav
On Fri, Mar 11, 2022 at 09:47:17AM -0800, Abhinav Kumar wrote:
> On 3/10/2022 11:28 PM, Laurent Pinchart wrote:
> > On Thu, Mar 10, 2022 at 05:49:59PM -0800, Abhinav Kumar wrote:
> >> Make changes to rcar_du driver to start using drm_encoder pointer
> >>
DRM framework requirements. The users of the
>* @drm_writeback_connector control the behaviour of the @encoder
>* by passing the @enc_funcs parameter to drm_writeback_connector_init()
>* function.
> + *
> + * For some vendor drivers, the hardware resources are shared between
> + * writeback encoder and rest of the display pipeline.
> + * To accommodate such cases, encoder is a handle to the real encoder
> + * 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
> + * a real encoder is not provided by the vendor drm drivers.
> + * @encoder will be assigned to this for those cases.
>*/
> - struct drm_encoder encoder;
> + struct drm_encoder internal_encoder;
None of this belong here.
>
> /**
>* @pixel_formats_blob_ptr:
> @@ -150,7 +166,7 @@ int drm_writeback_connector_init(struct drm_device *dev,
>struct drm_writeback_connector *wb_connector,
>const struct drm_connector_funcs *con_funcs,
>const struct drm_encoder_helper_funcs
> *enc_helper_funcs,
> - const u32 *formats, int n_formats);
> + const u32 *formats, int n_formats, uint32_t
> possible_crtcs);
>
> int drm_writeback_set_fb(struct drm_connector_state *conn_state,
>struct drm_framebuffer *fb);
--
Regards,
Laurent Pinchart
5216c27fc0ad..a412a1da950f 100644
> --- a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.yaml
> +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.yaml
> @@ -39,7 +39,6 @@ properties:
>Video port for MIPI DPI output (panel or connector).
>
> required:
> - - port@0
>- port@1
>
> required:
--
Regards,
Laurent Pinchart
Hi Maxime,
On Thu, Mar 24, 2022 at 09:18:19AM +0100, Maxime Ripard wrote:
> On Wed, Mar 23, 2022 at 10:38:19PM +0200, Laurent Pinchart wrote:
> > Hi Maxime,
> >
> > (CC'ing Sakari)
> >
> > Thank you for the patch.
> >
> > On Wed, Mar
Hi Maxime,
On Thu, Mar 24, 2022 at 03:23:24PM +0100, Maxime Ripard wrote:
> On Thu, Mar 24, 2022 at 03:43:42PM +0200, Laurent Pinchart wrote:
> > On Thu, Mar 24, 2022 at 09:18:19AM +0100, Maxime Ripard wrote:
> > > On Wed, Mar 23, 2022 at 10:38:19PM +0200, Laurent Pinchart
py(&mode, E, S)
> + drm_mode_copy(&mode, E)
> )
>
> @@
> struct drm_display_mode *mode;
> @@
> - &*mode
> + mode
>
> Cc: Andrzej Hajda
> Cc: Neil Armstrong
> Cc: Robert Foss
> Cc: Laurent Pinchart
> Cc: Jonas Karlman
> Cc: Jernej
Signed-off-by: Marek Vasut
> Cc: Christoph Fritz
> Cc: Laurent Pinchart
> Cc: Maxime Ripard
> Cc: Sam Ravnborg
> Cc: Thomas Zimmermann
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/panel/panel-simple.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Hi Stephen,
(CC'ing Jean-Michel)
On Fri, Feb 18, 2022 at 06:24:08PM -0800, Stephen Boyd wrote:
> Quoting Laurent Pinchart (2022-02-14 01:45:56)
> > Hi Maxime and Stephen,
> >
> > We have recently posted a driver for the BCM2711 Unicam CSI-2 receiver
> > (see [
truct rcar_lvds *lvds)
> > {
> > int ret;
> >
> > - ret = drm_of_find_panel_or_bridge(lvds->dev->of_node, 1, 0,
> > - &lvds->panel, &lvds->next_bridge);
>
> I guess lvds->panel can be removed from the rcar_lvds struct as well?
It's used in rcar_lvds_get_lvds_mode() though, so this patch introduces
a regression.
--
Regards,
Laurent Pinchart
by requesting
>* a restart of the group. See rcar_du_plane_atomic_update() for a more
>* detailed explanation.
> - *
> - * TODO: Check whether this is still needed on Gen3.
>*/
> crtc->group->need_restart = true;
>
--
Regards,
Laurent Pinchart
insertions(+), 11 deletions(-)
--
Regards,
Laurent Pinchart
The VSP1 sink selection through register DEFR8 is only available on Gen2
hardware. Skip it on Gen3.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_plane.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
b
On Gen3 hardware enabling a VSP plane doesn't change any register that
requires DRES to take effect. Avoid a group restart in that case.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_plane.c | 6 ++
drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 9 -
2 files ch
;< pll->pll_e)
> + output = (fin * pll->pll_n / pll->pll_m >> pll->pll_e)
> / div7 / pll->div;
> error = (long)(output - target) * 1 / (long)target;
>
--
Regards,
Laurent Pinchart
o pre_enable or after
> + * post_disable, the exact state of the lanes is undefined at this point. The
> + * DSI host should initialise the interface, transmit the data, and then
> disable
> + * the interface again.
> + *
> + * Ultra Low Power State (ULPS) is not explicitly support
iter);
> - if (WARN_ON(!old_bridge_state))
> - return;
> + drm_atomic_bridge_call_pre_enable(iter, old_state);
>
> - iter->funcs->atomic_pre_enable(iter, old_bridge_state);
> - } else if (iter->funcs->pre_enable) {
> - iter->funcs->pre_enable(iter);
> - }
> + if (iter->ops & DRM_BRIDGE_OP_UPSTREAM_FIRST)
> + iter = limit;
>
> if (iter == bridge)
> break;
> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> index f27b4060faa2..523ec9d8f3f8 100644
> --- a/include/drm/drm_bridge.h
> +++ b/include/drm/drm_bridge.h
> @@ -725,6 +725,14 @@ enum drm_bridge_ops {
>* this flag shall implement the &drm_bridge_funcs->get_modes callback.
>*/
> DRM_BRIDGE_OP_MODES = BIT(3),
> + /**
> + * @DRM_BRIDGE_OP_UPSTREAM_FIRST: The bridge can requires
s/can //
> + * that the upstream node pre_enable is called before its pre_enable,
s/node/bridge/ ?
> + * and conversely for post_disables. This is most frequently a
s/post_disables/post_disable/
Bonus points if you use the correct markup to link to those operations.
> + * requirement for DSI devices which need the host to be initialised
> + * before them.
> + */
> + DRM_BRIDGE_OP_UPSTREAM_FIRST = BIT(4),
> };
>
> /**
--
Regards,
Laurent Pinchart
/2021-December/333908.html
> > [4]
> > https://lists.freedesktop.org/archives/dri-devel/2021-October/328476.html
> > [5]
> > https://lists.freedesktop.org/archives/dri-devel/2021-October/325853.html
> > [6]
> > https://lists.freedesktop.org/archives/dri-devel/2022-February/341852.html
> > [7] https://github.com/6by9/linux/tree/drm-misc-next-vc4_dsi
> > [8] https://github.com/6by9/linux/tree/rpi-5.15.y-sn65dsi83
> >
> >
> > Dave Stevenson (2):
> >drm: Introduce DRM_BRIDGE_OP_UPSTREAM_FIRST to alter bridge init order
> >drm/bridge: Document the expected behaviour of DSI host controllers
> >
> > Documentation/gpu/drm-kms-helpers.rst | 7 +
> > drivers/gpu/drm/drm_bridge.c | 235
> > ++
> > include/drm/drm_bridge.h | 8 ++
> > 3 files changed, 225 insertions(+), 25 deletions(-)
--
Regards,
Laurent Pinchart
Hi Dmitry,
On Tue, Feb 22, 2022 at 06:32:50AM +0300, Dmitry Baryshkov wrote:
> On Thu, 10 Feb 2022 at 07:59, Laurent Pinchart wrote:
> > On Wed, Feb 09, 2022 at 05:40:29PM -0800, Abhinav Kumar wrote:
> > > Hi Laurent
> > >
> > > Gentle reminder on this.
> &
Hi Kieran,
On Tue, Feb 22, 2022 at 12:58:25PM +, Kieran Bingham wrote:
> Quoting Laurent Pinchart (2021-11-29 22:28:13)
> > When the CMM is enabled, an offset of 25 pixels must be subtracted from
> > the HDS (horizontal display start) and HDE (horizontal display end)
> &g
his be solved in the runtime
PM framework instead ? pm_runtime_disable() could disable auto-suspend.
If there are legitimate use cases for disabling runtime PM temporarily
without disabling auto-suspend, then a new function designed
specifically for remove() that would take care of cleaning everything up
could be another option.
> Reviewed-by: Linus Walleij
--
Regards,
Laurent Pinchart
Hi Doug,
On Wed, Feb 23, 2022 at 07:43:27AM -0800, Doug Anderson wrote:
> On Tue, Feb 22, 2022 at 9:08 PM Laurent Pinchart wrote:
> > On Tue, Feb 22, 2022 at 11:44:54PM +0100, Linus Walleij wrote:
> > > On Tue, Feb 22, 2022 at 11:19 PM Douglas Anderson wrote:
> > > &g
Hello,
On Wed, Feb 23, 2022 at 04:17:22PM +, Kieran Bingham wrote:
> Quoting Laurent Pinchart (2021-12-29 23:44:29)
> > On Sat, Dec 25, 2021 at 09:31:51AM +0300, Nikita Yushchenko wrote:
> > > Hotplug events reported by bridge drivers over drm_bridge_hpd_notify()
> &
er layout compared to all previous LCDIF
> variants. The new LCDIFv3 also supports 36bit address space. However,
> except for the complete bit reshuffling, this is still LCDIF and it still
> works like one.
>
> Signed-off-by: Marek Vasut
> Cc: Alexander Stein
> Cc: Laurent Pinchart
DRM_CLIENT_CAP_WRITEBACK_CONNECTORS
capability to get the writeback connectors exposed by the kernel, but
more than that, a large refactoring is then often needed to chase all
code paths that assume a connector is a connector.
I'm afraid the same applies to the kernel. Drivers that don&#
Hi Rob,
On Sat, Feb 26, 2022 at 10:27:59AM -0800, Rob Clark wrote:
> On Wed, Feb 2, 2022 at 7:41 AM Jani Nikula wrote:
> > On Wed, 02 Feb 2022, Laurent Pinchart wrote:
> > > On Wed, Feb 02, 2022 at 03:15:03PM +0200, Jani Nikula wrote:
> > >> On Wed, 02 Fe
Hi Dmitry,
On Mon, Feb 28, 2022 at 11:07:41AM +0300, Dmitry Baryshkov wrote:
> On Mon, 28 Feb 2022 at 11:00, Laurent Pinchart wrote:
> > On Sat, Feb 26, 2022 at 05:10:06AM +, Kandpal, Suraj wrote:
> > > Hi Abhinav,
> > >
> > > > Based on the discus
Hi Jani,
On Mon, Feb 28, 2022 at 02:09:15PM +0200, Jani Nikula wrote:
> On Mon, 28 Feb 2022, Laurent Pinchart wrote:
> > On Sat, Feb 26, 2022 at 10:27:59AM -0800, Rob Clark wrote:
> >> On Wed, Feb 2, 2022 at 7:41 AM Jani Nikula wrote:
> >> > On Wed, 02 Feb 2022, Laure
Hello,
On Mon, Feb 28, 2022 at 02:28:27PM +0200, Laurent Pinchart wrote:
> On Mon, Feb 28, 2022 at 02:09:15PM +0200, Jani Nikula wrote:
> > On Mon, 28 Feb 2022, Laurent Pinchart wrote:
> > > On Sat, Feb 26, 2022 at 10:27:59AM -0800, Rob Clark wrote:
> > >> On We
braham I
> Cc: Vinod Koul
> Cc: Sebastian Reichel
> Cc: Bjorn Andersson
> Cc: Mathieu Poirier
> Cc: Mark Brown
> Cc: Greg Kroah-Hartman
> Cc: Laurent Pinchart
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-in..
Hi Abhinav,
On Wed, Mar 02, 2022 at 10:28:03AM -0800, Abhinav Kumar wrote:
> On 2/28/2022 5:42 AM, Laurent Pinchart wrote:
> > On Mon, Feb 28, 2022 at 02:28:27PM +0200, Laurent Pinchart wrote:
> >> On Mon, Feb 28, 2022 at 02:09:15PM +0200, Jani Nikula wrote:
> >>>
On Wed, Mar 02, 2022 at 06:00:08PM +0100, Geert Uytterhoeven wrote:
> On Wed, Dec 29, 2021 at 5:47 PM Laurent Pinchart wrote:
> > On Fri, Dec 24, 2021 at 08:23:09AM +0300, Nikita Yushchenko wrote:
> > > Document the R-Car M3-W+ (R8A77961) SoC in the R-Car LVDS enco
A77961) SoC
- R-Car DU misc fixes and cleanups
--------
Laurent Pinchart (3):
drm: rcar-du: Drop LVDS device tree backward compatibility
drm: rcar-du: Don't select VSP1 sink on Gen3
drm: rcar-du: Don't restart gro
On Thu, Mar 03, 2022 at 11:14:24AM +0200, Laurent Pinchart wrote:
> On Wed, Mar 02, 2022 at 06:00:08PM +0100, Geert Uytterhoeven wrote:
> > On Wed, Dec 29, 2021 at 5:47 PM Laurent Pinchart wrote:
> > > On Fri, Dec 24, 2021 at 08:23:09AM +0300, Nikita Yushchenko wrote:
> > &
n't have any background about why they are different other than what
> looks to be intentionally making the two things incompatible.
I think it was done for DRM purpose, to prevent signals meant for a
panel to be connected to a device that could capture video from a DP
source.
> ...so
goto unregister_bridge;
> + if (!platform->pdata.is_dpi) {
> + ret = anx7625_attach_dsi(platform);
> + if (ret) {
> + DRM_DEV_ERROR(dev, "Fail to attach to dsi : %d\n", ret);
> + goto unregister_bridge;
> + }
> }
>
> DRM_DEV_DEBUG_DRIVER(dev, "probe done\n");
> diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.h
> b/drivers/gpu/drm/bridge/analogix/anx7625.h
> index 6dcf64c703f9..3ef1d8f4e575 100644
> --- a/drivers/gpu/drm/bridge/analogix/anx7625.h
> +++ b/drivers/gpu/drm/bridge/analogix/anx7625.h
> @@ -141,12 +141,20 @@
> #define HORIZONTAL_BACK_PORCH_H 0x22 /* Bit[7:4] are reserved */
>
> / END of I2C Address 0x72 */
> +
> +/***/
> +/* Register definition of device address 0x7a */
> +#define DP_TX_SWING_REG_CNT 0x14
> +#define DP_TX_LANE0_SWING_REG0 0x00
> +#define DP_TX_LANE1_SWING_REG0 0x14
> +/ END of I2C Address 0x7a */
> +
> /***/
> /* Register definition of device address 0x7e */
>
> #define I2C_ADDR_7E_FLASH_CONTROLLER 0x7E
>
> -#define FLASH_LOAD_STA 0x05
> +#define FLASH_LOAD_STA 0x05
> #define FLASH_LOAD_STA_CHK BIT(7)
>
> #define XTAL_FRQ_SEL0x3F
> @@ -349,12 +357,20 @@ struct s_edid_data {
>
> /* Display End */
>
> +#define MAX_LANES_SUPPORT4
> +
> struct anx7625_platform_data {
> struct gpio_desc *gpio_p_on;
> struct gpio_desc *gpio_reset;
> struct regulator_bulk_data supplies[3];
> struct drm_bridge *panel_bridge;
> int intp_irq;
> + int is_dpi;
> + int mipi_lanes;
> + int dp_lane0_swing_reg_cnt;
> + int lane0_reg_data[DP_TX_SWING_REG_CNT];
> + int dp_lane1_swing_reg_cnt;
> + int lane1_reg_data[DP_TX_SWING_REG_CNT];
> u32 low_power_mode;
> struct device_node *mipi_host_node;
> };
--
Regards,
Laurent Pinchart
. Let's discuss this in [1],
I'll update this series and rebase it on v5.18-rc1 once released based
on the outcome of the discussion.
[1] https://lore.kernel.org/all/yitruicikyxs3...@pendragon.ideasonboard.com/
Laurent Pinchart (3):
dt-bindings: media: Add macros for video interface bus
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 v1:
- Rename PARALLEL to BT601
---
.../devicetree/bindings/display
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 v1:
- Dual-license under GPL-2.0-only or
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 +++-
arch/arm/boot/dts/omap3-n900
On Sun, Mar 06, 2022 at 07:39:03PM +0200, Laurent Pinchart wrote:
> 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.
>
>
Hello Xin,
On Mon, Mar 07, 2022 at 11:22:48AM +0800, Xin Ji wrote:
> On Sun, Mar 06, 2022 at 07:13:30PM +0200, Laurent Pinchart wrote:
> > Hello Xin,
> >
> > (Question for Rob below, and I'm afraid this is urgent as we need to
> > merge a fix in v5.17).
> &
Hello Xin,
On Mon, Mar 07, 2022 at 12:32:49PM +0800, Xin Ji wrote:
> On Mon, Mar 07, 2022 at 05:30:09AM +0200, Laurent Pinchart wrote:
> > On Mon, Mar 07, 2022 at 11:22:48AM +0800, Xin Ji wrote:
> > > On Sun, Mar 06, 2022 at 07:13:30PM +0200, Laurent Pinchart wrote:
Hello Xin,
On Mon, Mar 07, 2022 at 01:09:45PM +0800, Xin Ji wrote:
> On Mon, Mar 07, 2022 at 06:47:44AM +0200, Laurent Pinchart wrote:
> > On Mon, Mar 07, 2022 at 12:32:49PM +0800, Xin Ji wrote:
> > > On Mon, Mar 07, 2022 at 05:30:09AM +0200, Laurent Pinchart wrote:
> >
dts: mt8183: jacuzzi: Fix bus properties in anx's DSI
> endpoint"
If this is enough to avoid the wrong bus-type becoming an ABI, even if
the corresponding driver support isn't reverted, then, for the whole
series,
Reviewed-by: Laurent Pinchart
> .../display/bridge/anal
process.
We may end up using those values, but I think it should be discussed and
not rushed in v5.17 if possible.
> > > -default: 1
> > > -
> > > - data-lanes: true
> > > + Video port for MIPI DSI input.
> > >
> >
6_16 from_fraction() then,
but then the same logic should possibly be replicated to ensure optimal
precision. I wonder if it wouldn't be best to simply use
drm_fixp_from_fraction() and shift the result right by 16 bits.
> +{
> + return (mult << 16) / div;
> +}
> +
> #endif
--
Regards,
Laurent Pinchart
clock in DT.
>
> Is this acceptable? or is there further issues there?
Could we handle that on the driver side, like we do for H1 by not
setting RCAR_DU_FEATURE_CRTC_IRQ_CLOCK ? We would probably need to split
that flag in two, as there are two interrupts.
It's a bit annoying not knowing what the MSTP bits do exactly, we've
modelled them as gates for the functional clock, but maybe in cases like
this one the mapping isn't fully correct, I'm not sure.
> > And what about DU_DOTCLKIN?
>
> This thread has already discussed this with Laurent, and I concur -
> There doesn't appear to be any relevant reference to DU_DOTCLKIN on the
> DU side.
--
Regards,
Laurent Pinchart
r helpers if it's better..? If the behaviour changes this goes
> from a trivial cleanup to a much more invasive changeset. I don't own
> half of the hardware here.
But except for msm which may need testing, all other drivers use the
existing FRAC_16_16() macro with constant arguments, so it shouldn't be
difficult to ensure that the new function gives the same results.
--
Regards,
Laurent Pinchart
sure about
> bridges added to bridge chain - you need to inspect all opses to ensure
> it can be done safely.
>
> And the main issue: Daniel does not like it :)
Neither do I :-) Could it be handled with two DRM connectors that are
mutually exclusive ?
--
Regards,
Laurent Pinchart
n
> > case data-mapping is not present, do nothing, since there are still
> > legacy bindings which do not specify this property.
> >
> > Reviewed-by: Laurent Pinchart
> > Signed-off-by: Marek Vasut
> > Cc: Laurent Pinchart
> > Cc: Sam Ravnborg
> > To:
dev_err(drm->dev, "Unknown media bus format %d\n", bus_format);
> + dev_err(drm->dev, "Unknown media bus format 0x%x\n",
> bus_format);
I may have gone for 0x%04x as current media bus formats all hold in 16
bits, but it's not big deal.
Reviewed-by: Laurent Pinchart
> break;
> }
>
--
Regards,
Laurent Pinchart
65dsi83_remove(struct i2c_client *client)
> mipi_dsi_device_unregister(ctx->dsi);
> drm_bridge_remove(&ctx->bridge);
> of_node_put(ctx->host_node);
> + regulator_disable(ctx->vcc);
>
> return 0;
> }
--
Regards,
Laurent Pinchart
l should happen at probe time, way before
the bridge is attached. Doing otherwise is a step in the wrong direction
in my opinion, and something we'll end up regretting when we'll feel the
pain it inflicts.
> return ret;
> }
> EXPORT_SYMBOL(drm_bridge_attach);
--
Regards,
Laurent Pinchart
Hi Alexander,
On Wed, Oct 13, 2021 at 08:59:22AM +, Alexander Stein wrote:
> On Tue, Oct 12, 2021 at 10:43 +0200, Laurent Pinchart wrote:
> > On Tue, Oct 12, 2021 at 08:48:43AM +0200, Alexander Stein wrote:
> > > VCC needs to be enabled before releasing the enable GPIO.
>
supply property even though it was
> working fine for them before.
>
> You handle that nicely in the code, but you can't make that new property
> required.
We can't make it required in the driver, but can't we make it required
in the bindings ? This indicates that all new DTs need to set the
property. We also need to mass-patch the in-tree DTs to avoid validation
failures, but apart from that, I don't see any issue.
--
Regards,
Laurent Pinchart
is still open, but this one is needed as a bug fix regardless of
> the rest.
This looks a bit complicated, but at the same time probably as clean as
it can get with the existing Kconfig grammar. I don't believe the needs
of the rcar-du driver are really exotic, so better support for this
Hi Maxime,
On Thu, Oct 14, 2021 at 09:41:10AM +0200, Maxime Ripard wrote:
> On Wed, Oct 13, 2021 at 12:37:47PM +0300, Laurent Pinchart wrote:
> > On Wed, Oct 13, 2021 at 09:47:22AM +0200, Maxime Ripard wrote:
> > > On Tue, Oct 12, 2021 at 08:48:42AM +0200, Alexander Stein wrote:
eam. That's why fix example by using only 4 cells
> instead of 5.
>
> Fixes: e7c7970a678d ("dt-bindings: display: xlnx: Add ZynqMP DP subsystem
> bindings")
> Signed-off-by: Michal Simek
Reviewed-by: Laurent Pinchart
> ---
>
> .../devicetree/binding
a_equal(old_conn_state,
> conn_state))
> + crtc_state->mode_changed = true;
> +
> + return 0;
> +}
> +
> +static const struct drm_bridge_funcs meson_encoder_hdmi_bridge_funcs = {
> + .attach = meson_encoder_hdmi_attach,
> + .enable = meson_encoder_hdmi_enable,
> + .disable = meson_encoder_hdmi_disable,
> + .mode_valid = meson_encoder_hdmi_mode_valid,
> + .atomic_enable = meson_encoder_hdmi_atomic_enable,
> + .atomic_get_input_bus_fmts = meson_encoder_hdmi_get_inp_bus_fmts,
> + .atomic_check = meson_encoder_hdmi_atomic_check,
> + .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,
> +};
> +
> +int meson_encoder_hdmi_init(struct meson_drm *priv)
> +{
> + struct meson_encoder_hdmi *meson_encoder_hdmi;
> + struct device_node *remote;
> + int ret;
> +
> + meson_encoder_hdmi = devm_kzalloc(priv->dev,
> sizeof(*meson_encoder_hdmi), GFP_KERNEL);
> + if (!meson_encoder_hdmi)
> + return -ENOMEM;
> +
> + /* HDMI Transceiver Bridge */
> + remote = of_graph_get_remote_node(priv->dev->of_node, 1, 0);
> + if (!remote) {
> + dev_err(priv->dev, "HDMI transceiver device is disabled");
> + return 0;
> + }
> +
> + meson_encoder_hdmi->next_bridge = of_drm_find_bridge(remote);
> + if (!meson_encoder_hdmi->next_bridge) {
> + dev_err(priv->dev, "Failed to find HDMI transceiver bridge\n");
> + return -EPROBE_DEFER;
> + }
> +
> + /* HDMI Encoder Bridge */
> + meson_encoder_hdmi->bridge.funcs = &meson_encoder_hdmi_bridge_funcs;
> + meson_encoder_hdmi->bridge.of_node = priv->dev->of_node;
> + meson_encoder_hdmi->bridge.type = DRM_MODE_CONNECTOR_HDMIA;
> +
> + drm_bridge_add(&meson_encoder_hdmi->bridge);
> +
> + meson_encoder_hdmi->priv = priv;
> +
> + /* Encoder */
> + ret = drm_simple_encoder_init(priv->drm, &meson_encoder_hdmi->encoder,
> + DRM_MODE_ENCODER_TMDS);
Ideally this should be moved one level up, as the bridge side shouldn't
care about drm_encoder. Creating the encoder, attaching to the bridge
and creating the connector using the drm bridge connector helper all
belong together in the display controller driver outside of bridge code,
and once all encoders have been converted to the new model, it can be
done unconditionally without caring about the type of bridge.
This can be done on top of this series.
> + if (ret) {
> + dev_err(priv->dev, "Failed to init HDMI encoder: %d\n", ret);
> + return ret;
> + }
> +
> + meson_encoder_hdmi->encoder.possible_crtcs = BIT(0);
> +
> + /* Attach HDMI Encoder Bridge to Encoder */
> + ret = drm_bridge_attach(&meson_encoder_hdmi->encoder,
> &meson_encoder_hdmi->bridge, NULL, 0);
> + if (ret) {
> + dev_err(priv->dev, "Failed to attach bridge: %d\n", ret);
> + return ret;
> + }
> +
> + /*
> + * We should have now in place:
> + * encoder->[hdmi encoder bridge]->[dw-hdmi bridge]->[dw-hdmi connector]
> + */
> +
> + dev_dbg(priv->dev, "HDMI encoder initialized\n");
> +
> + return 0;
> +}
> diff --git a/drivers/gpu/drm/meson/meson_encoder_hdmi.h
> b/drivers/gpu/drm/meson/meson_encoder_hdmi.h
> new file mode 100644
> index ..ed19494f0956
> --- /dev/null
> +++ b/drivers/gpu/drm/meson/meson_encoder_hdmi.h
> @@ -0,0 +1,12 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +/*
> + * Copyright (C) 2021 BayLibre, SAS
> + * Author: Neil Armstrong
> + */
> +
> +#ifndef __MESON_ENCODER_HDMI_H
> +#define __MESON_ENCODER_HDMI_H
> +
> +int meson_encoder_hdmi_init(struct meson_drm *priv);
> +
> +#endif /* __MESON_ENCODER_HDMI_H */
--
Regards,
Laurent Pinchart
Hi Maxime,
On Mon, Oct 18, 2021 at 05:20:13PM +0200, Maxime Ripard wrote:
> On Sat, Oct 16, 2021 at 05:34:59AM +0300, Laurent Pinchart wrote:
> > On Thu, Oct 14, 2021 at 09:41:10AM +0200, Maxime Ripard wrote:
> > > On Wed, Oct 13, 2021 at 12:37:47PM +0300, Laurent Pinchart wro
by display timings but rather the same as used by
> media, to define the pixel data sampling edge.
>
> Signed-off-by: Marek Vasut
> Cc: Laurent Pinchart
> Cc: Rob Herring
> Cc: Sam Ravnborg
> Cc: devicet...@vger.kernel.org
> To: dri-devel@lists.freedesktop.org
> -
Hi Marek,
On Mon, Oct 18, 2021 at 09:47:13PM +0200, Marek Vasut wrote:
> On 10/18/21 8:08 PM, Laurent Pinchart wrote:
>
> [...]
>
> >> diff --git
> >> a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
> >> b/Documentation/devicetree/
Hi Marek,
On Tue, Oct 19, 2021 at 12:18:11AM +0200, Marek Vasut wrote:
> On 10/18/21 9:57 PM, Laurent Pinchart wrote:
>
> Hi,
>
> >>>> diff --git
> >>>> a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
> >>>> b/Documen
Hi Maxime,
On Tue, Oct 19, 2021 at 09:37:28AM +0200, Maxime Ripard wrote:
> On Mon, Oct 18, 2021 at 08:48:52PM +0300, Laurent Pinchart wrote:
> > On Mon, Oct 18, 2021 at 05:20:13PM +0200, Maxime Ripard wrote:
> > > On Sat, Oct 16, 2021 at 05:34:59AM +0300, Laurent Pinchart wro
; @@ -74,7 +74,7 @@ static inline int of_graph_get_endpoint_count(const struct
> device_node *np)
> }
>
> static inline struct device_node *of_graph_get_port_by_id(
> - struct device_node *node, u32 id)
> + const struct device_node *node, u32 id)
> {
> return NULL;
> }
--
Regards,
Laurent Pinchart
else if (bridge->funcs->post_disable) {
> - bridge->funcs->post_disable(bridge);
> + iter->funcs->atomic_post_disable(iter,
> + old_bridge_state);
> + } else if (iter->funcs->post_disable) {
> + iter->funcs->post_disable(iter);
> }
> +
> + if (iter == bridge)
> + break;
> }
> }
> EXPORT_SYMBOL(drm_atomic_bridge_chain_post_disable);
--
Regards,
Laurent Pinchart
Hi Maxime,
On Thu, Oct 21, 2021 at 09:48:43AM +0200, Maxime Ripard wrote:
> On Tue, Oct 19, 2021 at 03:02:13PM +0300, Laurent Pinchart wrote:
> > On Wed, Sep 29, 2021 at 10:42:28AM +0200, Maxime Ripard wrote:
> > > of_graph_get_port_by_id doesn't modify the device_node po
ve a dual-link LVDS
> + output.
Should this be expanded to indicate that the property shall be set in
both TCON instances ?
Reviewed-by: Laurent Pinchart
> +
>ports:
> $ref: /schemas/graph.yaml#/properties/ports
>
--
Regards,
Laurent Pinchart
> Cc: Jitao Shi
> Cc: Enric Balletbo i Serra
> Cc: Philip Chen
> Cc: Andrzej Hajda
> Cc: Neil Armstrong
> Cc: Robert Foss
> Cc: Laurent Pinchart
> Cc: Jonas Karlman
> Cc: Jernej Skrabec
> ---
> drivers/gpu/drm/bridge/parade-ps8640.c | 14 --
> 1
default
implementations of some operations, without any dependency on other
components. The atomic state helpers fall in this category, they
implement .atomic_* operations of the drm_*_funcs structures, not
drm_*_helper_funcs. It could make sense to move them to the DRM core.
--
Regards,
Laurent Pinchart
Hi Sam,
On Fri, Oct 22, 2021 at 09:32:08PM +0200, Sam Ravnborg wrote:
> On Fri, Oct 22, 2021 at 09:42:37PM +0300, Laurent Pinchart wrote:
> > On Fri, Oct 22, 2021 at 07:13:58PM +0200, Sam Ravnborg wrote:
> > > Hi Laurent,
> > >
> > > > From a quick l
idge, &encoder->bridge_chain, chain_node) {
> >> - if (bridge->funcs->atomic_post_disable) {
> >> + list_for_each_entry_reverse(iter, &encoder->bridge_chain, chain_node) {
> >> + if (iter->funcs->atomic_post_disable) {
> >>struct drm_bridge_state *old_bridge_state;
> >>
> >>old_bridge_state =
> >>drm_atomic_get_old_bridge_state(old_state,
> >> - bridge);
> >> + iter);
> >>if (WARN_ON(!old_bridge_state))
> >>return;
> >>
> >> - bridge->funcs->atomic_post_disable(bridge,
> >> - old_bridge_state);
> >> - } else if (bridge->funcs->post_disable) {
> >> - bridge->funcs->post_disable(bridge);
> >> + iter->funcs->atomic_post_disable(iter,
> >> + old_bridge_state);
> >> + } else if (iter->funcs->post_disable) {
> >> + iter->funcs->post_disable(iter);
> >>}
> >> +
> >> + if (iter == bridge)
> >> + break;
> >
> > I cannot see why this is needed, we are at the end of the list here
> > anyway.
> >
> >>}
> >> }
> >> EXPORT_SYMBOL(drm_atomic_bridge_chain_post_disable);
--
Regards,
Laurent Pinchart
NS_DSI
> config DRM_CHIPONE_ICN6211
> tristate "Chipone ICN6211 MIPI-DSI/RGB Converter bridge"
> depends on OF
> + select DRM_KMS_HELPER
> select DRM_MIPI_DSI
> select DRM_PANEL_BRIDGE
> help
--
Regards,
Laurent Pinchart
nd "depends" usually lead to be results. DRM_KMS_HELPER
is a symbol that is mostly selected (I think there are a handful of
occurrences of "depends", which should probably be fixed).
> but most similar devices in this Kconfig file select DRM_KMS_HELPER.
> Is there something different about DRM_CHIPONE_ICN6211 that I have missed?
There isn't anything fundamentally different, but because DRM_KMS_HELPER
is meant to be selected and not depended on, I think we should fix that
for DRM_PANEL_BRIDGE, and it will fix the issue with
DRM_CHIPONE_ICN6211. The dependency on the KMS helpers come from
drm_panel_bridge.c, not from chipone-icn6211.c as far as I can tell, so
it would also be more correct.
--
Regards,
Laurent Pinchart
> config DRM_CHIPONE_ICN6211
> tristate "Chipone ICN6211 MIPI-DSI/RGB Converter bridge"
> depends on OF
> + depends on DRM_KMS_HELPER
With spaces replaced by tabs for indentation,
Reviewed-by: Laurent Pinchart
> select DRM_MIPI_DSI
> select DRM_PANEL_BRIDGE
> help
--
Regards,
Laurent Pinchart
Hi Andrzej,
On Mon, Oct 25, 2021 at 10:11:47PM +0200, Andrzej Hajda wrote:
> On 25.10.2021 13:21, Laurent Pinchart wrote:
> > On Mon, Oct 25, 2021 at 01:00:10PM +0200, Andrzej Hajda wrote:
> >> On 21.10.2021 22:21, Sam Ravnborg wrote:
> >>> On Thu, Oct 21, 202
On Tue, Oct 19, 2021 at 04:39:05PM +0200, Marek Vasut wrote:
> On 10/19/21 8:49 AM, Laurent Pinchart wrote:
> > Hi Marek,
>
> Hi,
>
> >>>>>> diff --git
> >>>>>> a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
>
401 - 500 of 9324 matches
Mail list logo
