From: Marek Vasut
NXP's i.MX8MM has an LCDIF as well.
Signed-off-by: Marek Vasut
Reviewed-by: Laurent Pinchart
Signed-off-by: Laurent Pinchart
---
Changes since v1:
- Rebased on top of the YAML conversion
Cc: Fabio Estevam
Cc: Guido Günther
Cc: Lucas Stach
Cc: NXP Linux Team
Cc
e addition of the new properties on top ?
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
ridge_attach(encoder, bridge, NULL, 0);
> if (ret) {
> dev_err(dev, "Unable to attach bridge\n");
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
7 ("drm/bridge: Refactor out the panel wrapper from the
> lvds-encoder bridge.")
> Cc: # 4.12+
> Cc: Andrzej Hajda
> Cc: Neil Armstrong
> Cc: Laurent Pinchart
> Cc: Jonas Karlman
> Cc: Jernej Skrabec
> Signed-off-by: Paul Cercueil
> ---
> drivers/gpu/
gt; > > diff)
> > > > +{
> > > > + unsigned long next;
> > > > + int i;
> > > > +
> > > > + for (i = min; i <= max; i++) {
> > > > + next = start + diff;
> > > > + if (start <= clock && clock < next)
> > > > + return i;
> > > > +
> > > > + start += diff;
> > > > + }
> > > > +
> > > > + return -EINVAL;
> > > > +}
> > > > +
> > > > +static void sn65dsi_enable(struct drm_bridge *bridge)
> > > > +{
> > > > + struct sn65dsi *sn = bridge_to_sn65dsi(bridge);
> > > > + struct drm_display_mode *mode = bridge_to_mode(bridge);
> > > > + int bpp = mipi_dsi_pixel_format_to_bpp(sn->dsi->format);
> > > > + unsigned int lanes = sn->dsi->lanes;
> > > > + unsigned int pixel_clk = mode->clock * 1000;
> > > > + unsigned int dsi_clk = pixel_clk * bpp / (lanes * 2);
> > > > + unsigned int val;
> > > > +
> > > > + /* set SOFT_RESET bit */
> > > > + regmap_write(sn->regmap, SN65DSI_SOFT_RESET, SN65DSI_RESET_EN);
> > > > +
> > > > + msleep(10);
> > > > +
> > > > + /* set PLL_EN bit */
> > > > + regmap_write(sn->regmap, SN65DSI_CLK_PLL, 0x0);
> > > > +
> > > > + msleep(10);
> > > > +
> > > > + /* setup lvds clock */
> > > > + val = sn65dsi_get_clk_range(0, 5, pixel_clk, 2500,
> > > > 2500);
> > > > + if (val < 0) {
> > > > + DRM_DEV_ERROR(sn->dev, "invalid LVDS clock range %d\n",
> > > > val);
> > > > + return;
> > > > + }
> > > > +
> > > > + regmap_update_bits(sn->regmap, SN65DSI_LVDS_CLK,
> > > > + SN65DSI_LVDS_CLK_MASK,
> > > > + val << SN65DSI_LVDS_CLK_SHIFT);
> > > > +
> > > > + regmap_update_bits(sn->regmap, SN65DSI_LVDS_CLK,
> > > > + SN65DSI_LVDS_CLK_SRC_DSI,
> > > > + SN65DSI_LVDS_CLK_SRC_DSI);
> > > > +
> > > > + msleep(10);
> > > > +
> > > > + /* setup bridge clock divider */
> > > > + val = (dsi_clk / pixel_clk) - 1;
> > > > + regmap_update_bits(sn->regmap, SN65DSI_CLK_DIV,
> > > > + SN65DSI_CLK_DIV_MASK,
> > > > + val << SN65DSI_CLK_DIV_SHIFT);
> > > > + msleep(10);
> > > > +
> > > > + /* configure dsi */
> > > > + regmap_update_bits(sn->regmap, SN65DSI_DSI_CFG,
> > > > + SN65DSI_DSI_LANE_MASK,
> > > > + lanes << SN65DSI_DSI_LANE_SHIFT);
> > > > + msleep(10);
> > > > +
> > >
> > > Most of those, look like. I don't know why it does not work without.
> > > Where is mention in datasheet?
> > >
> > > > + /* dsi clock range */
> > > > + val = sn65dsi_get_clk_range(8, 100, dsi_clk, 4000, 500);
> > > > + if (val < 0) {
> > > > + DRM_DEV_ERROR(sn->dev, "invalid DSI clock range %d\n",
> > > > val);
> > > > + return;
> > > > + }
> > > > +
> > > > + regmap_write(sn->regmap, SN65DSI_DSI_CLK_RANGE, val);
> > > > +
> > > > + msleep(10);
> > > > +
> > > > + /* setup lvds channels */
> > > > + regmap_read(sn->regmap, SN65DSI_LVDS_MODE, &val);
> > > > + if (bpp == 24)
> > > > + val |= SN65DSI_LVDS_CHA_24BPP;
> > > > + regmap_write(sn->regmap, SN65DSI_LVDS_MODE, val);
> > > > +
> > > > + msleep(10);
> > > > +
> > > > + /* TODO Channel B required to set up for dual-link LVDS */
> > > > + sn65dsi_setup_channels(sn, mode);
> > > > +
> > >
> > > If you are supporting 84 this code can be drop.
> >
> > Right now the above function is setting up channel A for single-link
> > LVDS. 84 support Single and Dual link LVDS.
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
-
>
> Changes from v1:
> - Reintroduce the old_plane_state check in zynqmp_disp_crtc_atomic_disable
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 8
> drivers/gpu/drm/drm_simple_kms_helper.c | 4 +++-
> drivers/gpu/drm/mxsfb/mxsfb_k
Hi Maxime,
On Wed, Nov 18, 2020 at 06:48:05PM +0100, Maxime Ripard wrote:
> On Mon, Oct 12, 2020 at 02:00:30AM +0300, Laurent Pinchart wrote:
> > > -static int drm_of_lvds_get_remote_pixels_type(
> > > - const struct device_node *port_no
gt; >>>>>>> breaks the nice feature of DSI attach/detach callbacks and
> > >>>>>>> apparently
> > >>>>>>> can cause different issues depending on device bind order.
> > >>>>>>>
> > >>>
sion 10.2.0)
>
> Signed-off-by: Colin Ian King
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/tc358768.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/tc358768.c
> b/drivers/gpu/drm/bridge/tc358768.c
&
}
> + }
> + }
> +
> + sn->dsi_lanes = len / sizeof(u32);
> + if (sn->dsi_lanes < 1 || sn->dsi_lanes > 4)
> + return -EINVAL;
> +
> + sn->host_node = of_graph_get_remote_node(dev->of_node, 0, 0);
> +
Do you have a system with an HDMI panel that is always
connected, with the HPD signal of the dw-hdmi not connected ?
> Example:
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
of_find_panel_or_bridge(dev->of_node, 1, 0,
> > + &panel, &bridge);
> > + if (ret)
> > + return ERR_PTR(ret);
> > +
> > + if (panel) {
> > + bridge = drm_panel_bridge_add_typed(panel,
bridge_out_dsi: endpoint {
This label should be bridge_in_dsi.
> + remote-endpoint = <&dsi_out_bridge>;
> +};
> + };
> +
> + bridge_out: port@1 {
You can drop this label too.
> +reg = <1>;
> +
> +bridge_out_panel: endpoint {
> + remote-endpoint = <&panel_out_bridge>;
> +};
> + };
> +};
> + };
> +};
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
implement the &drm_bridge_funcs->get_modes callback.
>*/
> DRM_BRIDGE_OP_MODES = BIT(3),
> + /**
> + * @DRM_BRIDGE_OP_CEC: The bridge supports a CEC adapter.
> + * Bridges that set this flag shall implement the
> + * &drm_bridge_funcs->cec_init and &drm_bridge_funcs->cec_exit
> + * callbacks.
> + */
> + DRM_BRIDGE_OP_CEC = BIT(4),
> };
>
> /**
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
re_data *core,
> - struct hdmi_wp_data *wp);
> +struct hdmi_wp_data *wp, struct drm_connector *conn);
> void hdmi4_cec_uninit(struct hdmi_core_data *core);
> #else
> static inline void hdmi4_cec_set_phys_addr(struct hdmi_core_data *core, u16
> pa)
> @@ -41,8 +41
working with - when the drm_bridge is attached.
> Likewise, we unregister the AUX adapter on bridge detachment by adding a
> ti_sn_bridge_detach() callback.
>
> Signed-off-by: Lyude Paul
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/ti-sn65dsi86.c | 18 +
@name: user-visible name of this AUX channel and the I2C-over-AUX adapter
> * @ddc: I2C adapter that can be used for I2C-over-AUX communication
> * @dev: pointer to struct device that is the parent for this AUX channel
> + * @drm_dev: pointer to the &drm_device that owns thi
Hi Lyude,
Thank you for the patch.
On Fri, Feb 19, 2021 at 04:53:15PM -0500, Lyude Paul wrote:
> So that we can start using drm_dbg_*() in
> drm_dp_link_train_clock_recovery_delay().
>
> Signed-off-by: Lyude Paul
Reviewed-by: Laurent Pinchart
> ---
> drivers/
Hi Lyude,
Thank you for the patch.
On Fri, Feb 19, 2021 at 04:53:16PM -0500, Lyude Paul wrote:
> So that we can start using drm_dbg_*() for
> drm_dp_link_train_channel_eq_delay() and
> drm_dp_lttpr_link_train_channel_eq_delay().
>
> Signed-off-by: Lyude Paul
Reviewed-by: L
the flag names, e.g.
> MIPI_DSI_MODE_NO_EOT_PACKET.
>
> Signed-off-by: Nicolas Boichat
This looks good to me, it increases readability.
Reviewed-by: Laurent Pinchart
Please however see the end of the mail for a comment.
> ---
> I considered adding _DISABLE_ instead, but that&#
r to do so in the
operations themselves, for instance replacing
list_for_each_entry_reverse() with list_for_each_entry() in
drm_atomic_bridge_chain_pre_enable(). Still, this will likely break
drivers that depend on the existing order, so I don't think that's an
acceptable solution as-is.
Hi Jagan,
On Wed, Feb 24, 2021 at 06:07:43PM +0530, Jagan Teki wrote:
> On Mon, Feb 15, 2021 at 5:48 PM Laurent Pinchart wrote:
> > On Sun, Feb 14, 2021 at 11:22:10PM +0530, Jagan Teki wrote:
> > > ICN6211 is MIPI-DSI to RGB Convertor bridge from Chipone.
> > &
t; -reg-names = "mhdptx";
> +reg = <0xf0 0xfb00 0x0 0x100>,
> + <0x0 0x4f48000 0x0 0x74>;
> +reg-names = "mhdptx", "mhdptx-sapb";
> clocks = <&mhdp_clock>;
> phys = <&dp_phy>;
> phy-names = "dpphy";
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Hi Hans,
(CC'ing the DRM bridge maintainers and Daniel Vetter)
On Mon, Mar 01, 2021 at 11:56:28AM +0100, Hans Verkuil wrote:
> On 19/02/2021 13:02, Laurent Pinchart wrote:
> > On Thu, Feb 11, 2021 at 11:36:59AM +0100, Hans Verkuil wrote:
> >> Add bridge cec_init/exit
Hi Hans,
On Mon, Mar 01, 2021 at 12:07:56PM +0100, Hans Verkuil wrote:
> On 19/02/2021 13:07, Laurent Pinchart wrote:
> > On Thu, Feb 11, 2021 at 11:37:00AM +0100, Hans Verkuil wrote:
> >> Implement the new CEC bridge ops. This makes it possible to associate
> >&g
describe
the system, not configure it. A way for userspace to configure this
would be better.
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
ne".
> >
> > JFYI, the WARNING is now in v5.12-rc1, the fix isn't.
>
> Does this patch go through you to get into the DRM tree? Or do I need to
> re-send it to someone else?
I can send a pull request with this for the -fixes branch, but as
there's a single patch, maybe David or Daniel could pick it up ?
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Hi Jagan,
On Wed, Mar 03, 2021 at 08:08:35PM +0530, Jagan Teki wrote:
> On Wed, Feb 24, 2021 at 6:44 PM Laurent Pinchart wrote:
> > On Wed, Feb 24, 2021 at 06:07:43PM +0530, Jagan Teki wrote:
> > > On Mon, Feb 15, 2021 at 5:48 PM Laurent Pinchart wrote:
> > > > On S
roperties/port
> +description: USB port for the USB3 input.
> +
> + port@2:
> + $ref: /schemas/graph.yaml#/properties/port
> +description: USB Type-c connector, see connector/usb-connector.yaml.
> +
> +required:
> + - port@0
As all the ports exist at t
8;
> + u16 vendor, device, fw_version;
> + u8 buffer[4];
> + int ret;
> +
> + anx7688 = devm_kzalloc(dev, sizeof(*anx7688), GFP_KERNEL);
> + if (!anx7688)
> + return -ENOMEM;
> +
> + anx7688->client = client;
> + i2c_set_clientdata(client, anx7688);
Hi Dafna,
On Fri, Mar 05, 2021 at 04:14:03PM +0100, Dafna Hirschfeld wrote:
> On 05.03.21 15:34, Laurent Pinchart wrote:
> > On Fri, Mar 05, 2021 at 01:43:50PM +0100, Dafna Hirschfeld wrote:
> >> ANX7688 is a USB Type-C port controller with a MUX. It converts HDMI 2.0 to
&g
Hello,
This small patch series fixes two issues related to plane handling and
blending, and add global alpha support to the overlay plane. There isn't
much to say here, please refer to individual patches for details.
Laurent Pinchart (3):
drm: xlnx: zynqmp_dpsub: Fix plane ordering
drm:
on to userspace.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/xlnx/zynqmp_disp.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c
b/drivers/gpu/drm/xlnx/zynqmp_disp.c
index 148add0ca1d6..6296f6d5acbc 100644
--- a/drivers/gpu/drm
The top (graphics) plane has a global alpha setting. Expose it through
the plane's alpha property.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/xlnx/zynqmp_disp.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c
b/driver
To display the graphics layer, the global alpha needs to be enabled.
Enable it when the graphics plane is enabled (with full opacity), and
disable it otherwise.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/xlnx/zynqmp_disp.c | 9 -
1 file changed, 8 insertions(+), 1 deletion
ontext of an embedded system, it may be useful to select
which HDCP versions to offer based on different constraints at runtime.
This really seems like a system configuration parameter to me, not a
system description.
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
gt; + - 0
I count 32 bits here. Should these two 0 be replaced by spaces ? Same
for MEDIA_BUS_FMT_RGB888_1X30-CPADLO.
With this fixed,
Reviewed-by: Laurent Pinchart
> + - r\ :sub:`5`
> + - r\ :sub:`4`
> + - r\ :sub:`3`
> + - r\ :sub:`2`
> + -
onent are transmitted on a 30-bit
> input bus(10-bit per component) from a display controller or a 36-bit
> output bus(12-bit per component) to a pixel link.
>
> Reviewed-by: Robert Foss
> Signed-off-by: Liu Ying
Reviewed-by: Laurent Pinchart
> ---
> v4->v5:
> * Add R
ap, REG_RC_RESET, 0x00);
> >> + regmap_write(ctx->regmap, REG_RC_PLL_EN, 0x00);
> >> +
> >> + /* Reference clock derived from DSI link clock. */
> >> + regmap_write(ctx->regmap, REG_RC_LVDS_PLL,
> >> +
> >> REG_RC_LVDS_PLL_LVDS_CLK_RANGE(sn65dsi83_get_lvds_range(ctx)) |
> >> + REG_RC_LVDS_PLL_HS_CLK_SRC_DPHY);
> >
> > (Checkpatch whinge for "Alignment should match open parenthesis" on
> > several lines through this function)
>
> Do you have any extra checkpatch settings somewhere ?
> I get this on current next:
>
> linux-2.6$ ./scripts/checkpatch.pl -f drivers/gpu/drm/bridge/ti-sn65dsi83.c
> total: 0 errors, 0 warnings, 625 lines checked
>
> [...]
--
Regards,
Laurent Pinchart
st);
>
> static void drm_dp_aux_add(struct drm_dp_aux *aux)
> {
> mutex_lock(&dp_aux_lock);
> list_add_tail(&aux->list, &dp_aux_list);
> mutex_unlock(&dp_aux_lock);
> }
>
> static void drm_dp_aux_remove(struct drm_dp_aux *aux)
> {
> mutex_lock(&dp_aux_lock);
> list_del_init(&aux->list);
> mutex_unlock(&dp_aux_lock);
> }
>
> #ifdef CONFIG_OF
> struct drm_dp_aux *of_drm_find_dp_aux_by_node(struct device_node *np)
> {
> struct drm_dp_aux *aux;
> mutex_lock(&dp_aux_lock);
>
> list_for_each_entry(aux, &dp_aux_list, list) {
> if (aux->dev->of_node == np) {
> mutex_unlock(&dp_aux_lock);
> return aux;
> }
> }
>
> mutex_unlock(&dp_aux_lock);
> return NULL;
> }
> EXPORT_SYMBOL(of_drm_find_dp_aux_by_node);
> #endif
>
>
> int drm_dp_aux_init(struct drm_dp_aux *aux)
> {
> INIT_LIST_HEAD(&aux->list);
> ...
> }
>
> int drm_dp_aux_register(struct drm_dp_aux *aux)
> {
> ...
> drm_dp_aux_add(aux);
>
> return 0;
> }
>
> void drm_dp_aux_unregister(struct drm_dp_aux *aux)
> {
> drm_dp_aux_remove(aux);
> ...
> }
Overall this seems like a good approach, but there's one unanswered
question: what happens if drm_dp_aux_unregister() is called while a
panel holds a reference to it ? The drm_dp_aux instances likely need to
be reference-counted.
> > I guess an alternate way to solve this (I'm not totally sure whether
> > it's better or worse) would be to add a function that would walk up
> > the chain of parent bridges and ask them for a pointer to the aux bus.
> > I definitely haven't thought it all the way through, but I'd imagine
> > something like drm_bridge_chain_get_ddc_aux(). This is _probably_
> > better than adding the "ddc-aux-bus" property but it assumes that the
> > aux bus is provided by one of our parents. Hrm, looking at this
> > briefly, though, I'm not sure how to do it. It doesn't seem possible
> > to get the parent bridges from the panel structure. Even if you assume
> > that your parent is wrapping you with a panel_bridge it still doesn't
> > seem possible?
> >
> > This probably needs more drm-expertise.
--
Regards,
Laurent Pinchart
at it ?
Reviewed-by: Laurent Pinchart
> 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
> ---
> .../devicetree/bindings/display/panel/lvds.yaml | 12 +++
Hi Marek,
On Sun, May 16, 2021 at 01:49:11AM +0200, Marek Vasut wrote:
> On 5/15/21 11:48 PM, Laurent Pinchart wrote:
> > Hi Marek,
>
> Hi,
>
> > Thank you for the patch.
> >
> > On Sat, May 15, 2021 at 10:39:32PM +0200, Marek Vasut wrote:
> >> Add
Hi Marek,
Thank you for the patch.
On Tue, May 18, 2021 at 12:43:36AM +0200, Marek Vasut wrote:
> Add missing spaces to make the diagrams readable, no functional change.
>
> Signed-off-by: Marek Vasut
> Cc: Laurent Pinchart
> Cc: Rob Herring
> Cc: Sam Ravnb
DT property to the strapping case though, but I don't
have a real preference here, so I'm fine with this approach.
> Signed-off-by: Marek Vasut
> Cc: Laurent Pinchart
> Cc: Rob Herring
> Cc: Sam Ravnborg
> Cc: devicet...@vger.kernel.org
> To: dri-devel@lists.fre
nce there are still
> legacy bindings which do not specify this property.
>
> Signed-off-by: Marek Vasut
> Cc: Laurent Pinchart
> Cc: Sam Ravnborg
> To: dri-devel@lists.freedesktop.org
> ---
> drivers/gpu/drm/bridge/lvds-codec.c | 50 +
And another thing:
On Tue, May 18, 2021 at 02:02:24AM +0300, Laurent Pinchart wrote:
> On Sat, May 15, 2021 at 10:46:55PM +0200, Marek Vasut wrote:
> > Decoder input LVDS format is a property of the decoder chip or even
> > its strapping. Add DT property data-mapping the same
4 finally makes use of the drm_bridge_connector_init() helper.
The series has been tested on the Renesas R-Car Salvator-XS and Draak
boards with the VGA, HDMI and LVDS outputs.
Laurent Pinchart (4):
drm: bridge: dw-hdmi: Attach to next bridge if available
drm: rcar-du: lvds: Convert to DRM pane
bridge attach handler.
Signed-off-by: Laurent Pinchart
Reviewed-by: Neil Armstrong
---
Changes since v1:
- Make missing endpoint a fatal error
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 54 ++-
include/drm/bridge/dw_hdmi.h | 2 +
2 files changed, 55
Report the DT output port number in dw_hdmi_plat_data to connect to the
next bridge in the dw-hdmi driver.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
b/drivers/gpu/drm
Replace the manual panel handling with usage of the DRM panel bridge
helper. This simplifies the driver, and brings support for
DRM_BRIDGE_ATTACH_NO_CONNECTOR as an added bonus.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_lvds.c | 120 +++-
1 file
Use the drm_bridge_connector_init() helper to create a drm_connector for
each output, instead of relying on the bridge drivers doing so. Attach
the bridges with the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag to instruct
them not to create a connector.
Signed-off-by: Laurent Pinchart
Reviewed-by: Jacopo
sion.
> Acked-by: Paul Cercueil
> Signed-off-by: Quanyang Wang
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/xlnx/zynqmp_disp.c | 39 +-
> 1 file changed, 22 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/xlnx/zynqmp_d
NQMP_DISP_AV_BUF_PATTERN_GEN_SELECT0x100
Following my comment above, let's write this
#define ZYNQMP_DISP_AV_BUF_OUTPUT_LIVE 0
#define ZYNQMP_DISP_AV_BUF_OUTPUT_MEM 1
#define ZYNQMP_DISP_AV_BUF_OUTPUT_PATTERN 2
#define ZYNQMP_DISP_AV_BUF_OUTPUT_NONE 3
#define ZYNQMP_DISP_AV_BUF_OUTPUT_VID1(v) ((v) << 0)
#define ZYNQMP_DISP_AV_BUF_OUTPUT_VID1_MASK GENMASK(1, 0)
#define ZYNQMP_DISP_AV_BUF_OUTPUT_VID2(v) ((v) << 2)
#define ZYNQMP_DISP_AV_BUF_OUTPUT_VID2_MASK GENMASK(3, 2)
#define ZYNQMP_DISP_AV_BUF_OUTPUT_VID3(v) ((v) << 4)
#define ZYNQMP_DISP_AV_BUF_OUTPUT_VID3_MASK GENMASK(5, 4)
#define ZYNQMP_DISP_AV_BUF_OUTPUT_VID4(v) ((v) << 6)
#define ZYNQMP_DISP_AV_BUF_OUTPUT_VID4_MASK GENMASK(7, 6)
Or possibly better,
#define ZYNQMP_DISP_AV_BUF_OUTPUT_LIVE 0
#define ZYNQMP_DISP_AV_BUF_OUTPUT_MEM 1
#define ZYNQMP_DISP_AV_BUF_OUTPUT_PATTERN 2
#define ZYNQMP_DISP_AV_BUF_OUTPUT_NONE 3
#define ZYNQMP_DISP_AV_BUF_OUTPUT_VID(n, v) ((v) << ((n) * 2))
#define ZYNQMP_DISP_AV_BUF_OUTPUT_VID_MASK(n) GENMASK((n)+1, (n))
--
Regards,
Laurent Pinchart
From: Quanyang Wang
Add a new function zynqmp_disp_layer_is_video() to simplify the code
that judges if a layer is the video layer.
Acked-by: Paul Cercueil
Signed-off-by: Quanyang Wang
Reviewed-by: Laurent Pinchart
[Renamed is_layer_vid() to zynqmp_disp_layer_is_video()]]
Signed-off-by
-pointers to the zynqmp_disp in order to access fields
such as the device pointer for debug messages, and this isn't worth it.
Instead, merge those structures with the zynqmp_disp structure, and pass
the zynqmp_disp pointer to all internal functions.
Signed-off-by: Laurent Pinchart
---
dr
en the name "overlay").
Laurent Pinchart (3):
drm: xlnx: zynqmp_dpsub: Fix graphics layer blending
drm: xlnx: zynqmp_dpsub: Add global alpha support
drm: xlnx: zynqmp_dpsub: Expose plane ordering to userspace
drivers/gpu/drm/xlnx/zynqmp_disp.c | 18 +-
1 file changed
The graphics plane has a global alpha setting. Expose it through the
plane's alpha property.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/xlnx/zynqmp_disp.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c
b/drivers/gp
To display the graphics layer, the global alpha needs to be enabled.
Enable it when the graphics plane is enabled (with full opacity), and
disable it otherwise.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/xlnx/zynqmp_disp.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion
While the DPSUB has a fixed plane order, it still makes sense to expose
it to userspace to avoid hardcoding assumptions. Do so by adding an
immutable zpos property to planes.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/xlnx/zynqmp_disp.c | 1 +
1 file changed, 1 insertion(+)
diff --git
gt; Reported-by: Aaro Koskinen
> Fixes: 8bef8a6d5da81b909a190822b96805a47348146f ("drm/omap: sdi: Register a
> drm_bridge")
> Cc: sta...@vger.kernel.org # v5.7+
> Tested-by: Ivaylo Dimitrov
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/omapdrm/dss/sdi.c | 10
he omapdrm specific driver has been removed in
> 45f16c82db7e ("drm/omap: displays: Remove unused panel drivers").
>
> Reported-by: Jarkko Nikula
> Reported-by: Peter Ujfalusi
> Reported-by: Tony Lindgren
> Reported-by: Aaro Koskinen
> Reported-by: Ivaylo D
Hi Sebastian,
On Sun, Nov 29, 2020 at 01:53:31AM +0100, Sebastian Reichel wrote:
> On Sun, Nov 29, 2020 at 12:08:47AM +0200, Laurent Pinchart wrote:
> > On Fri, Nov 27, 2020 at 09:04:29PM +0100, Sebastian Reichel wrote:
> > > The probe routine acquires the reset GPIO using GPIOD
commented in his review of v1 that bus flags should be set
in atomic_check, even when they're static ? We're moving towards
removing timings->input_bus_flags, so this patch goes in the wrong
direction :-S
> }
>
> /**
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
hooks in the drm_bridge_funcs.
> Use helper functions for state management.
>
> Output format is expected to be MEDIA_BUS_FMT_FIXED
> Input format is the one selected by the bridge from DT properties.
>
> Signed-off-by: Nikhil Devshatwar
> Reviewed-by: Tomi Valkeine
ate->bus_format == MEDIA_BUS_FMT_FIXED) {
> +
> + dev_err(ddev->dev, "Bridge connected to the encoder did not
> specify media bus format\n");
> return -EINVAL;
> }
>
> - // XXX any cleaner way to set bus format and flags?
> - tcrtc_state->bus_format = di->bus_formats[0];
> - if (!bus_flags_set)
> - tcrtc_state->bus_flags = di->bus_flags;
> -
> return 0;
> }
>
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
My understanding is that currently, the format negotiation logic does
> not negotiate all the way till encoder, it stops only at the
> first_bridge.
Should we then implement a bridge in the tidss driver to model the
internal encoder, in order to support format negotiation all the way to
the tidss ?
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Hi Tomi,
On Mon, Nov 30, 2020 at 11:46:31AM +0200, Tomi Valkeinen wrote:
> On 30/11/2020 11:36, Laurent Pinchart wrote:
> > On Thu, Nov 19, 2020 at 09:31:29PM +0530, Nikhil Devshatwar wrote:
> >> bus_flags can be specified by a bridge in the timings.
> >> If the bridg
Hi Tomi,
Thank you for the patch.
On Tue, Nov 24, 2020 at 02:45:13PM +0200, Tomi Valkeinen wrote:
> Use the common MIPI_DCS_GET_ERROR_COUNT_ON_DSI define instead of
> driver's own.
>
> Signed-off-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/d
Hi Tomi,
Thank you for the patch.
On Tue, Nov 24, 2020 at 02:45:14PM +0200, Tomi Valkeinen wrote:
> Simplify the code by moving code from _dsicm_enable_te() into
> dsicm_power_on().
>
> Signed-off-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/pa
<&dss_clkctrl
> OMAP5_DSS_CORE_CLKCTRL 10>;
> clock-names = "fck", "sys_clk";
> +
> + #address-c
gt; Fix this by failing early on such cases.
>
> Signed-off-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/omapdrm/dss/pll.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/omapdrm/dss/pll.c
> b/drivers/gpu/drm
mi Valkeinen
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/omapdrm/dss/dsi.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c
> b/drivers/gpu/drm/omapdrm/dss/dsi.c
> index c3592c6db977..7fee9cf8782d 100644
>
gt; {
> struct panel_drv_data *ddata = dev_get_drvdata(&dev->dev);
> @@ -308,6 +328,10 @@ static int dsicm_power_on(struct panel_drv_data *ddata)
> if (r)
> goto err;
>
> + r = dsicm_set_update_window(ddata);
&
eds to
> be revisited later.
This is important information, could you capture it in a comment in the
code ?
Reviewed-by: Laurent Pinchart
> Signed-off-by: Tomi Valkeinen
> ---
> drivers/gpu/drm/omapdrm/dss/dsi.c | 41 +--
> 1 file changed, 12 insertions
Signed-off-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/omapdrm/dss/dsi.c | 49 ---
> 1 file changed, 13 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c
> b/drivers/gpu/drm/omapdrm/dss
tems: 1
> +
> + dp-pwr-supply:
> +description: Power supply for the DP_PWR pin
> +maxItems: 1
> +
> + port:
> +description: Connection to controller providing DP signals
Now that the OF graph schema has landed, could you add the corresponding
$ref ?
Revi
, "hpd",
>GPIOD_IN);
> if (IS_ERR(conn->hpd_gpio)) {
> @@ -223,6 +227,38 @@ static int display_connector_probe(struct
> platform_device *pdev)
> }
> }
>
> + /* Get the DP PWR for DP connector
u16 *red, u16 *green, u16 *blue,
> uint32_t size,
> struct drm_modeset_acquire_ctx *ctx);
> +int drm_atomic_helper_legacy_degamma_set(struct drm_crtc *crtc,
> + u16 *red, u16 *green, u16 *blue,
> + uint32_t size,
> + struct drm_modeset_acquire_ctx *ctx);
>
> /**
> * drm_atomic_crtc_for_each_plane - iterate over planes currently attached
> to CRTC
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
; degamma -> ctm -> out
>
> and the legacy ioctl will continue working as before.
>
> Signed-off-by: Tomi Valkeinen
> Reviewed-by: Pekka Paalanen
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/omapdrm/omap_crtc.c | 14 +++---
> 1 file changed, 7 inserti
ff-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/omapdrm/omap_crtc.c | 39 +++--
> 1 file changed, 37 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c
> b/drivers/gpu/drm/omapdrm/omap_crtc.c
Hi Tomi,
Thank you for the patch.
On Tue, Nov 03, 2020 at 10:03:09AM +0200, Tomi Valkeinen wrote:
> Drop "uapi/" and rearrange alphabetically.
>
> Signed-off-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/omapdrm/dss/omapdss.h | 8
== DRM_FORMAT_YUYV ||
> + formats[i] == DRM_FORMAT_UYVY ||
> + formats[i] == DRM_FORMAT_NV12)
> + return true;
> +
> + return false;
> +}
> +
> static const char *plane_id_to_name[] = {
> [OMAP_DSS_GFX] = "gfx",
> [OMAP
Hi Tomi,
On Mon, Nov 30, 2020 at 01:53:25PM +0200, Tomi Valkeinen wrote:
> On 30/11/2020 12:50, Laurent Pinchart wrote:
> > On Tue, Nov 03, 2020 at 10:03:10AM +0200, Tomi Valkeinen wrote:
> >> From: Jyri Sarha
> >>
> >> Adds support for COLOR_EN
Hi Tomi,
On Mon, Nov 30, 2020 at 12:04:27PM +0200, Tomi Valkeinen wrote:
> On 30/11/2020 12:02, Tomi Valkeinen wrote:
> > On 30/11/2020 11:47, Laurent Pinchart wrote:
> >
> >>>> Hasn't Boris commented in his review of v1 that bus flags should be set
> &
keinen
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/omapdrm/dss/dsi.c | 11 ---
> 1 file changed, 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c
> b/drivers/gpu/drm/omapdrm/dss/dsi.c
> index 63338324c564..fbf05097612f 100644
> ---
DSS_CLK_SRC_PLL1_1 :
> DSS_CLK_SRC_PLL2_1);
>
> @@ -4012,19 +4012,19 @@ static int dsi_display_init_dispc(struct dsi_data
> *dsi)
> dss_mgr_unregister_framedone_handler(&dsi->output,
> dsi_framedo
d state instead of reading it back from the
hardware, as it's (marginally) more efficient. In either case,
Reviewed-by: Laurent Pinchart
> WARN_ON(!dsi_bus_is_locked(dsi));
>
> dsi_vc_enable(dsi, vc, 0);
> @@ -2456,8 +2458,6 @@ static void dsi_vc_enable_hs(
er, if we use a different VC for video data, the VC is in LP mode.
> Fix this by always setting the LP/HS mode before starting a frame
> update.
>
> Signed-off-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/omapdrm/dss/dsi.c | 2 ++
> 1 file change
-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/omapdrm/dss/dsi.c | 12 +++-
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c
> b/drivers/gpu/drm/omapdrm/dss/dsi.c
> index 41d6231d6e31..0
DISPLAY_BRIGHTNESS,
> + level);
If !ddata->enabled, won't r be uninitialized ?
>
> mutex_unlock(&ddata->lock);
>
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
.xres = 864,
> + .yres = 480,
> + .refresh = 60,
> + .width_mm = 0,
> + .height_mm = 0,
> + .max_hs_rate = 3,
> + .max_lp_rate = 1000,
> +};
> +
> +static const struct dsic_panel_data himalaya_data = {
> + .xres = 480,
&g
#include
This could go to the patch that moves TE handling to the code.
> #include
> -#include
I'd keep module.h as you use macros it defines, and we shouldn't depend
in indirect includes.
Reviewed-by: Laurent Pinchart
> -#include
> -#include
&
tart_time;
> -#endif
> - int debug_read;
> - int debug_write;
> - struct {
> - struct dss_debugfs_entry *irqs;
> - struct dss_debugfs_entry *regs;
> - struct dss_debugfs_entry *clks;
> - } debugfs;
> -
> -#ifdef CONFIG_OMAP
Hi Tomi,
Thank you for the patch.
On Tue, Nov 24, 2020 at 02:45:30PM +0200, Tomi Valkeinen wrote:
> Clean up the code by inlining dsi_enable_video_outputs and
> dsi_disable_video_outputs functions.
>
> Signed-off-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
> ---
>
e WARN_ON() is needed
anymore ?
Reviewed-by: Laurent Pinchart
> Signed-off-by: Tomi Valkeinen
> ---
> drivers/gpu/drm/omapdrm/dss/dsi.c | 16 +++-
> 1 file changed, 3 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c
> b/dri
x27;d actually squash the two.
Reviewed-by: Laurent Pinchart
> Signed-off-by: Tomi Valkeinen
> ---
> drivers/gpu/drm/omapdrm/dss/dsi.c | 19 +++
> 1 file changed, 3 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c
> b/driver
isplay_enable which just enables the DSI interface).
> Rename them by dropping the "display".
>
> Signed-off-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/omapdrm/dss/dsi.c | 36 +++
> 1 file changed, 18 insertions(+
i_if_enable(dsi, 1);
> +
> + dsi_force_tx_stop_mode_io(dsi);
> +
> + /* start the DDR clock by sending a NULL packet */
> + if (dsi->vm_timings.ddr_clk_always_on)
> + dsi_vc_send_null(dsi, VC_CMD, dsi->dsidev->channel);
> +}
> +
> static int dsi_init
Hi Tomi,
Thank you for the patch.
On Tue, Nov 24, 2020 at 02:45:35PM +0200, Tomi Valkeinen wrote:
> Clean up the code by separating video-mode enable/disable code into
> functions of their own.
>
> Signed-off-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
> ---
> drive
always_on field which seems pretty useless.
>
> Signed-off-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/omapdrm/dss/dsi.c | 12 +---
> drivers/gpu/drm/omapdrm/dss/dsi.h | 2 --
> 2 files changed, 5 insertions(+), 9 deletions(-)
>
> d
201 - 300 of 9324 matches
Mail list logo
