dt-bindings: display: bridge: lvds-codec: Document LVDS data mapping select
Subsystems (4)
PATCH v6 1/2 dt-bindings: display: bridge: lvds-codec: Document LVDS data mapping select
Decoder input LVDS format is a property of the decoder chip or even its strapping. Add DT property data-mapping the same way lvds-panel does, to define the LVDS data mapping.
To: [email protected]
---
V2: - Use allOf
- Move the data-mapping to endpoint
V3: - Rebase on V2 submitted a while ago, reinstate changelog
- Drop the allOf and un-rebase on previous pclk patch
V4: - port@1, remove $ref: /schemas/graph.yaml#/properties/port and
add $ref: /schemas/graph.yaml#/$defs/port-base
V5: - Move the data-mapping property to port@0 , decoder LVDS input
- Add RB from Laurent
V6: - No change
--- .../bindings/display/bridge/lvds-codec.yaml | 33 ++++++++++++++++++- 1 file changed, 32 insertions(+), 1 deletion(-)
Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml +32 -1
@@ -49,11 +49,26 @@ properties: properties: port@0: - $ref: /schemas/graph.yaml#/properties/port + $ref: /schemas/graph.yaml#/$defs/port-base description: | For LVDS encoders, port 0 is the parallel input For LVDS decoders, port 0 is the LVDS input + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + + properties: + data-mapping: + enum: + - jeida-18 + - jeida-24 + - vesa-24 + description: | + The color signals mapping order. See details in + Documentation/devicetree/bindings/display/panel/lvds.yaml + port@1: $ref: /schemas/graph.yaml#/properties/port description: |
@@ -71,6 +86,22 @@ properties: power-supply: true +if: + not: + properties: + compatible: + contains: + const: lvds-decoder +then: + properties: + ports: + properties: + port@0: + properties: + endpoint: + properties: + data-mapping: false + required: - compatible - ports
Signature · 1 line
2.33.0
PATCH v6 2/2 drm/bridge: lvds-codec: Add support for LVDS data mapping select
Decoder input LVDS format is a property of the decoder chip or even its strapping. Handle data-mapping the same way lvds-panel does. In case data-mapping is not present, do nothing, since there are still legacy bindings which do not specify this property.
To: [email protected]
---
V2: - Move the data-mapping to endpoint
V3: - Rebase on V2 submitted a while ago, reinstate changelog
- Use .atomic_get_input_bus_fmts for the decoder, separate funcs for encoder
V4: - No change
V5: - Move the data-mapping property to port@0 , decoder LVDS input
- Add RB from Laurent
V6: - Turn missing data-mapping into warning, since the driver does
continue in legacy probing mode without it.
--- drivers/gpu/drm/bridge/lvds-codec.c | 76 ++++++++++++++++++++++++++++- 1 file changed, 75 insertions(+), 1 deletion(-)
drivers/gpu/drm/bridge/lvds-codec.c +75 -1
@@ -12,6 +12,7 @@#include <linux/platform_device.h> #include <linux/regulator/consumer.h> +#include <drm/drm_atomic_helper.h> #include <drm/drm_bridge.h> #include <drm/drm_panel.h>
@@ -22,6 +23,7 @@ struct lvds_codec {struct regulator *vcc;struct gpio_desc *powerdown_gpio;u32 connector_type; +unsigned int bus_format; };static inline struct lvds_codec *to_lvds_codec (struct drm_bridge *bridge)
@@ -74,12 +76,50 @@ static const struct drm_bridge_funcs funcs = { .disable = lvds_codec_disable, }; +#define MAX_INPUT_SEL_FORMATS 1 +static u32 * +lvds_codec_atomic_get_input_bus_fmts (struct drm_bridge *bridge, +struct drm_bridge_state *bridge_state, +struct drm_crtc_state *crtc_state, +struct drm_connector_state *conn_state, +u32 output_fmt, +unsigned int *num_input_fmts) +{ +struct lvds_codec *lvds_codec =to_lvds_codec (bridge); +u32 *input_fmts; + + *num_input_fmts =0 ; + + input_fmts =kcalloc (MAX_INPUT_SEL_FORMATS ,sizeof (*input_fmts), +GFP_KERNEL ); +if (!input_fmts) +return NULL ; + + input_fmts[0 ] = lvds_codec->bus_format; + *num_input_fmts =MAX_INPUT_SEL_FORMATS ; + +return input_fmts; +} + +static const struct drm_bridge_funcs funcs_decoder = { + .attach = lvds_codec_attach, + .enable = lvds_codec_enable, + .disable = lvds_codec_disable, + .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, + .atomic_get_input_bus_fmts = lvds_codec_atomic_get_input_bus_fmts, +}; +static int lvds_codec_probe (struct platform_device *pdev) {struct device *dev = &pdev->dev;struct device_node *panel_node; +struct device_node *bus_node;struct drm_panel *panel;struct lvds_codec *lvds_codec; +const char *mapping; +int ret; lvds_codec =devm_kzalloc (dev,sizeof (*lvds_codec),GFP_KERNEL );if (!lvds_codec)
@@ -119,13 +159,47 @@ static int lvds_codec_probe(struct platform_device *pdev)if (IS_ERR (lvds_codec->panel_bridge))return PTR_ERR (lvds_codec->panel_bridge); + lvds_codec->bridge.funcs = &funcs; + +/* +* Decoder input LVDS format is a property of the decoder chip or even +* its strapping. Handle data-mapping the same way lvds-panel does. In +* case data-mapping is not present, do nothing, since there are still +* legacy bindings which do not specify this property. +*/ +if (lvds_codec->connector_type !=DRM_MODE_CONNECTOR_LVDS ) { + bus_node =of_graph_get_endpoint_by_regs (dev->of_node,0 ,0 ); +if (!bus_node) { +dev_dbg (dev,"bus DT node not found\n" ); +return -ENXIO ; + } + + ret =of_property_read_string (bus_node,"data-mapping" , + &mapping); +of_node_put (bus_node); +if (ret <0 ) { +dev_warn (dev,"missing 'data-mapping' DT property\n" ); + }else { +if (!strcmp (mapping,"jeida-18" )) { + lvds_codec->bus_format =MEDIA_BUS_FMT_RGB666_1X7X3_SPWG ; + }else if (!strcmp (mapping,"jeida-24" )) { + lvds_codec->bus_format =MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA ; + }else if (!strcmp (mapping,"vesa-24" )) { + lvds_codec->bus_format =MEDIA_BUS_FMT_RGB888_1X7X4_SPWG ; + }else { +dev_err (dev,"invalid 'data-mapping' DT property\n" ); +return -EINVAL ; + } + lvds_codec->bridge.funcs = &funcs_decoder; + } + } +/* * The panel_bridge bridge is attached to the panel's of_node, * but we need a bridge attached to our of_node for our user * to look up. */ lvds_codec->bridge.of_node = dev->of_node; - lvds_codec->bridge.funcs = &funcs;drm_bridge_add (&lvds_codec->bridge);platform_set_drvdata (pdev, lvds_codec);
Signature · 1 line
2.33.0
Re: [PATCH v6 2/2] drm/bridge: lvds-codec: Add support for LVDS data mapping select
Hi Marek,
Quoted 9 lines · Marek Vasut
Decoder input LVDS format is a property of the decoder chip or even its strapping. Handle data-mapping the same way lvds-panel does. In case data-mapping is not present, do nothing, since there are still legacy bindings which do not specify this property.
Reviewed-by Laurent Pinchart <[email protected]>Signed-off-by Marek Vasut <[email protected]>Cc Laurent Pinchart <[email protected]>Cc Sam Ravnborg <[email protected]>
Quoted 10 lines
To: [email protected]
---
V2: - Move the data-mapping to endpoint
V3: - Rebase on V2 submitted a while ago, reinstate changelog
- Use .atomic_get_input_bus_fmts for the decoder, separate funcs for encoder
V4: - No change
V5: - Move the data-mapping property to port@0 , decoder LVDS input
- Add RB from Laurent
V6: - Turn missing data-mapping into warning, since the driver does
continue in legacy probing mode without it.
I assume you will apply the patches.
Sam
Re: [PATCH v6 2/2] drm/bridge: lvds-codec: Add support for LVDS data mapping select
Quoted 23 lines · Sam Ravnborg
Hi Marek,
Quoted 9 lines · Marek Vasut
Decoder input LVDS format is a property of the decoder chip or even its strapping. Handle data-mapping the same way lvds-panel does. In case data-mapping is not present, do nothing, since there are still legacy bindings which do not specify this property.
Reviewed-by Laurent Pinchart <[email protected]>Signed-off-by Marek Vasut <[email protected]>Cc Laurent Pinchart <[email protected]>Cc Sam Ravnborg <[email protected]>Reviewed-by Sam Ravnborg <[email protected]>Quoted 10 lines
To: [email protected]
---
V2: - Move the data-mapping to endpoint
V3: - Rebase on V2 submitted a while ago, reinstate changelog
- Use .atomic_get_input_bus_fmts for the decoder, separate funcs for encoder
V4: - No change
V5: - Move the data-mapping property to port@0 , decoder LVDS input
- Add RB from Laurent
V6: - Turn missing data-mapping into warning, since the driver does
continue in legacy probing mode without it.
Quoted 1 line
I assume you will apply the patches.
I did not find your name in https://people.freedesktop.org/~seanpaul/whomisc.html
so I went ahead and applied the patches.
Sam
Re: [PATCH v6 2/2] drm/bridge: lvds-codec: Add support for LVDS data mapping select
Quoted 24 lines · Sam Ravnborg
Quoted 23 lines · Sam Ravnborg
Hi Marek,
Quoted 9 lines · Marek Vasut
Decoder input LVDS format is a property of the decoder chip or even its strapping. Handle data-mapping the same way lvds-panel does. In case data-mapping is not present, do nothing, since there are still legacy bindings which do not specify this property.
Reviewed-by Laurent Pinchart <[email protected]>Signed-off-by Marek Vasut <[email protected]>Cc Laurent Pinchart <[email protected]>Cc Sam Ravnborg <[email protected]>Reviewed-by Sam Ravnborg <[email protected]>Quoted 10 lines
To: [email protected]
---
V2: - Move the data-mapping to endpoint
V3: - Rebase on V2 submitted a while ago, reinstate changelog
- Use .atomic_get_input_bus_fmts for the decoder, separate funcs for encoder
V4: - No change
V5: - Move the data-mapping property to port@0 , decoder LVDS input
- Add RB from Laurent
V6: - Turn missing data-mapping into warning, since the driver does
continue in legacy probing mode without it.
Quoted 4 lines
Quoted 1 line
I assume you will apply the patches.
I did not find your name in https://people.freedesktop.org/~seanpaul/whomisc.html
so I went ahead and applied the patches.
Thank you
Re: [PATCH v6 2/2] drm/bridge: lvds-codec: Add support for LVDS data mapping select
In reply to Sam RavnborgQuoted 23 lines · Sam Ravnborg
Hi Marek,
Quoted 9 lines · Marek Vasut
Decoder input LVDS format is a property of the decoder chip or even its strapping. Handle data-mapping the same way lvds-panel does. In case data-mapping is not present, do nothing, since there are still legacy bindings which do not specify this property.
Reviewed-by Laurent Pinchart <[email protected]>Signed-off-by Marek Vasut <[email protected]>Cc Laurent Pinchart <[email protected]>Cc Sam Ravnborg <[email protected]>Reviewed-by Sam Ravnborg <[email protected]>Quoted 10 lines
To: [email protected]
---
V2: - Move the data-mapping to endpoint
V3: - Rebase on V2 submitted a while ago, reinstate changelog
- Use .atomic_get_input_bus_fmts for the decoder, separate funcs for encoder
V4: - No change
V5: - Move the data-mapping property to port@0 , decoder LVDS input
- Add RB from Laurent
V6: - Turn missing data-mapping into warning, since the driver does
continue in legacy probing mode without it.
Quoted 1 line
I assume you will apply the patches.
I can't, I'm still waiting for my drm-misc access.