Add DT binding document for TI SN65DSI83 DSI to LVDS bridge.
Signed-off-by: Marek Vasut marex@denx.de Cc: Douglas Anderson dianders@chromium.org Cc: Laurent Pinchart laurent.pinchart@ideasonboard.com Cc: Linus Walleij linus.walleij@linaro.org Cc: Sam Ravnborg sam@ravnborg.org Cc: Stephen Boyd swboyd@chromium.org Cc: devicetree@vger.kernel.org To: dri-devel@lists.freedesktop.org --- .../bindings/display/bridge/ti,sn65dsi83.yaml | 128 ++++++++++++++++++ 1 file changed, 128 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml
diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml new file mode 100644 index 000000000000..77e1bafd8cd8 --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml @@ -0,0 +1,128 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/bridge/ti,sn65dsi83.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: SN65DSI83 DSI to LVDS bridge chip + +maintainers: + - Marek Vasut marex@denx.de + +description: | + The Texas Instruments SN65DSI83 bridge takes MIPI DSI in and outputs LVDS. + https://www.ti.com/general/docs/lit/getliterature.tsp?genericPartNumber=sn65... + +properties: + compatible: + const: ti,sn65dsi83 + + reg: + const: 0x2d + + enable-gpios: + maxItems: 1 + description: GPIO specifier for bridge_en pin (active high). + + ports: + type: object + additionalProperties: false + + properties: + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + + port@0: + type: object + additionalProperties: false + + description: + Video port for MIPI DSI input + + properties: + reg: + const: 0 + + endpoint: + type: object + additionalProperties: false + properties: + remote-endpoint: true + data-lanes: + description: array of physical DSI data lane indexes. + + required: + - reg + + port@1: + type: object + additionalProperties: false + + description: + Video port for LVDS output (panel or bridge). + + properties: + reg: + const: 1 + + endpoint: + type: object + additionalProperties: false + properties: + remote-endpoint: true + + required: + - reg + + required: + - "#address-cells" + - "#size-cells" + - port@0 + - port@1 + +required: + - compatible + - reg + - enable-gpios + - ports + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + bridge@2d { + compatible = "ti,sn65dsi83"; + reg = <0x2d>; + + enable-gpios = <&gpio2 1 GPIO_ACTIVE_HIGH>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + endpoint { + remote-endpoint = <&dsi0_out>; + data-lanes = <1 2 3 4>; + }; + }; + + port@1 { + reg = <1>; + endpoint { + remote-endpoint = <&panel_in_lvds>; + }; + }; + }; + }; + };
Add driver for TI SN65DSI83 Single-Channel DSI to Single-Link LVDS bridge. The driver operates the chip over I2C bus. Currently the LVDS clock are always derived from DSI clock lane, which is the usual mode of operation, support for clock from external oscillator is not implemented, but it is easy to add if ever needed. Only RGB888 pixel format is implemented, the LVDS666 is not supported, but could be added if needed.
Signed-off-by: Marek Vasut marex@denx.de Cc: Douglas Anderson dianders@chromium.org Cc: Laurent Pinchart laurent.pinchart@ideasonboard.com Cc: Linus Walleij linus.walleij@linaro.org Cc: Philippe Schenker philippe.schenker@toradex.com Cc: Sam Ravnborg sam@ravnborg.org Cc: Stephen Boyd swboyd@chromium.org Cc: Valentin Raevsky valentin@compulab.co.il To: dri-devel@lists.freedesktop.org --- drivers/gpu/drm/bridge/Kconfig | 10 + drivers/gpu/drm/bridge/Makefile | 1 + drivers/gpu/drm/bridge/ti-sn65dsi83.c | 535 ++++++++++++++++++++++++++ 3 files changed, 546 insertions(+) create mode 100644 drivers/gpu/drm/bridge/ti-sn65dsi83.c
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index cc401786962a..5e4f674e3fdb 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -234,6 +234,16 @@ config DRM_TI_TFP410 help Texas Instruments TFP410 DVI/HDMI Transmitter driver
+config DRM_TI_SN65DSI83 + tristate "TI SN65DSI83 DSI to LVDS bridge" + depends on OF + select DRM_KMS_HELPER + select REGMAP_I2C + select DRM_PANEL + select DRM_MIPI_DSI + help + Texas Instruments SN65DSI83 DSI to LVDS Bridge driver + config DRM_TI_SN65DSI86 tristate "TI SN65DSI86 DSI to eDP bridge" depends on OF diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile index 21ea8fe09992..e11415db0a31 100644 --- a/drivers/gpu/drm/bridge/Makefile +++ b/drivers/gpu/drm/bridge/Makefile @@ -21,6 +21,7 @@ obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o obj-$(CONFIG_DRM_TOSHIBA_TC358768) += tc358768.o obj-$(CONFIG_DRM_TOSHIBA_TC358775) += tc358775.o obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/ +obj-$(CONFIG_DRM_TI_SN65DSI83) += ti-sn65dsi83.o obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o obj-$(CONFIG_DRM_TI_TPD12S015) += ti-tpd12s015.o diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c b/drivers/gpu/drm/bridge/ti-sn65dsi83.c new file mode 100644 index 000000000000..79c023ba3dce --- /dev/null +++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c @@ -0,0 +1,535 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (C) 2021 Marek Vasut marex@denx.de + * + * Based on previous work of: + * Valentin Raevsky valentin@compulab.co.il + * Philippe Schenker philippe.schenker@toradex.com + */ + +#include <linux/bits.h> +#include <linux/clk.h> +#include <linux/gpio/consumer.h> +#include <linux/i2c.h> +#include <linux/module.h> +#include <linux/of_graph.h> +#include <linux/regmap.h> + +#include <drm/drm_atomic_helper.h> +#include <drm/drm_bridge.h> +#include <drm/drm_mipi_dsi.h> +#include <drm/drm_of.h> +#include <drm/drm_panel.h> +#include <drm/drm_print.h> +#include <drm/drm_probe_helper.h> + +/* ID registers */ +#define REG_ID(n) (0x00 + (n)) +/* Reset and clock registers */ +#define REG_RC_RESET 0x09 +#define REG_RC_RESET_SOFT_RESET BIT(0) +#define REG_RC_LVDS_PLL 0x0a +#define REG_RC_LVDS_PLL_PLL_EN_STAT BIT(7) +#define REG_RC_LVDS_PLL_LVDS_CLK_RANGE(n) (((n) & 0x7) << 1) +#define REG_RC_LVDS_PLL_HS_CLK_SRC_DPHY BIT(0) +#define REG_RC_DSI_CLK 0x0b +#define REG_RC_DSI_CLK_DSI_CLK_DIVIDER(n) (((n) & 0x1f) << 3) +#define REG_RC_DSI_CLK_REFCLK_MULTIPLIER(n) ((n) & 0x3) +#define REG_RC_PLL_EN 0x0d +#define REG_RC_PLL_EN_PLL_EN BIT(0) +/* DSI registers */ +#define REG_DSI_LANE 0x10 +#define REG_DSI_LANE_RESERVED BIT(5) +#define REG_DSI_LANE_CHA_DSI_LANES(n) (((n) & 0x3) << 3) +#define REG_DSI_LANE_SOT_ERR_TOL_DIS BIT(0) +#define REG_DSI_EQ 0x11 +#define REG_DSI_EQ_CHA_DSI_DATA_EQ(n) (((n) & 0x3) << 6) +#define REG_DSI_EQ_CHA_DSI_CLK_EQ(n) (((n) & 0x3) << 2) +#define REG_DSI_CLK 0x12 +#define REG_DSI_CLK_CHA_DSI_CLK_RANGE(n) ((n) & 0xff) +/* LVDS registers */ +#define REG_LVDS_FMT 0x18 +#define REG_LVDS_FMT_DE_NEG_POLARITY BIT(7) +#define REG_LVDS_FMT_HS_NEG_POLARITY BIT(6) +#define REG_LVDS_FMT_VS_NEG_POLARITY BIT(5) +#define REG_LVDS_FMT_RESERVED BIT(4) /* Set to 1 */ +#define REG_LVDS_FMT_CHA_24BPP_MODE BIT(3) +#define REG_LVDS_FMT_CHA_24BPP_FORMAT1 BIT(1) +#define REG_LVDS_VCOM 0x19 +#define REG_LVDS_VCOM_CHA_LVDS_VOCM BIT(6) +#define REG_LVDS_VCOM_CHA_LVDS_VOD_SWING(n) (((n) & 0x3) << 2) +#define REG_LVDS_LANE 0x1a +#define REG_LVDS_LANE_CHA_REVERSE_LVDS BIT(5) +#define REG_LVDS_LANE_CHA_LVDS_TERM BIT(1) +#define REG_LVDS_CM 0x1b +#define REG_LVDS_CM_CHA_LVDS_CM_ADJUST(n) ((n) & 0x3) +/* Video registers */ +#define REG_VID_CHA_ACTIVE_LINE_LENGTH_LOW 0x20 +#define REG_VID_CHA_ACTIVE_LINE_LENGTH_HIGH 0x21 +#define REG_VID_CHA_VERTICAL_DISPLAY_SIZE_LOW 0x24 +#define REG_VID_CHA_VERTICAL_DISPLAY_SIZE_HIGH 0x25 +#define REG_VID_CHA_SYNC_DELAY_LOW 0x28 +#define REG_VID_CHA_SYNC_DELAY_HIGH 0x29 +#define REG_VID_CHA_HSYNC_PULSE_WIDTH_LOW 0x2c +#define REG_VID_CHA_HSYNC_PULSE_WIDTH_HIGH 0x2d +#define REG_VID_CHA_VSYNC_PULSE_WIDTH_LOW 0x30 +#define REG_VID_CHA_VSYNC_PULSE_WIDTH_HIGH 0x31 +#define REG_VID_CHA_HORIZONTAL_BACK_PORCH 0x34 +#define REG_VID_CHA_VERTICAL_BACK_PORCH 0x36 +#define REG_VID_CHA_HORIZONTAL_FRONT_PORCH 0x38 +#define REG_VID_CHA_VERTICAL_FRONT_PORCH 0x3a +#define REG_VID_CHA_TEST_PATTERN 0x3c +/* IRQ registers */ +#define REG_IRQ_GLOBAL 0xe0 +#define REG_IRQ_GLOBAL_IRQ_EN BIT(0) +#define REG_IRQ_EN 0xe1 +#define REG_IRQ_EN_CHA_SYNCH_ERR_EN BIT(7) +#define REG_IRQ_EN_CHA_CRC_ERR_EN BIT(6) +#define REG_IRQ_EN_CHA_UNC_ECC_ERR_EN BIT(5) +#define REG_IRQ_EN_CHA_COR_ECC_ERR_EN BIT(4) +#define REG_IRQ_EN_CHA_LLP_ERR_EN BIT(3) +#define REG_IRQ_EN_CHA_SOT_BIT_ERR_EN BIT(2) +#define REG_IRQ_EN_CHA_PLL_UNLOCK_EN BIT(0) +#define REG_IRQ_STAT 0xe5 +#define REG_IRQ_STAT_CHA_SYNCH_ERR BIT(7) +#define REG_IRQ_STAT_CHA_CRC_ERR BIT(6) +#define REG_IRQ_STAT_CHA_UNC_ECC_ERR BIT(5) +#define REG_IRQ_STAT_CHA_COR_ECC_ERR BIT(4) +#define REG_IRQ_STAT_CHA_LLP_ERR BIT(3) +#define REG_IRQ_STAT_CHA_SOT_BIT_ERR BIT(2) +#define REG_IRQ_STAT_CHA_PLL_UNLOCK BIT(0) + +struct sn65dsi83 { + struct drm_bridge bridge; + struct drm_display_mode mode; + struct device *dev; + struct regmap *regmap; + struct device_node *host_node; + struct mipi_dsi_device *dsi; + struct drm_bridge *panel_bridge; + struct gpio_desc *enable_gpio; + int dsi_lanes; +}; + +static const struct regmap_range sn65dsi83_readable_ranges[] = { + regmap_reg_range(REG_ID(0), REG_ID(8)), + regmap_reg_range(REG_RC_LVDS_PLL, REG_RC_DSI_CLK), + regmap_reg_range(REG_RC_PLL_EN, REG_RC_PLL_EN), + regmap_reg_range(REG_DSI_LANE, REG_DSI_CLK), + regmap_reg_range(REG_LVDS_FMT, REG_LVDS_CM), + regmap_reg_range(REG_VID_CHA_ACTIVE_LINE_LENGTH_LOW, + REG_VID_CHA_ACTIVE_LINE_LENGTH_HIGH), + regmap_reg_range(REG_VID_CHA_VERTICAL_DISPLAY_SIZE_LOW, + REG_VID_CHA_VERTICAL_DISPLAY_SIZE_HIGH), + regmap_reg_range(REG_VID_CHA_SYNC_DELAY_LOW, + REG_VID_CHA_SYNC_DELAY_HIGH), + regmap_reg_range(REG_VID_CHA_HSYNC_PULSE_WIDTH_LOW, + REG_VID_CHA_HSYNC_PULSE_WIDTH_HIGH), + regmap_reg_range(REG_VID_CHA_VSYNC_PULSE_WIDTH_LOW, + REG_VID_CHA_VSYNC_PULSE_WIDTH_HIGH), + regmap_reg_range(REG_VID_CHA_HORIZONTAL_BACK_PORCH, + REG_VID_CHA_HORIZONTAL_BACK_PORCH), + regmap_reg_range(REG_VID_CHA_VERTICAL_BACK_PORCH, + REG_VID_CHA_VERTICAL_BACK_PORCH), + regmap_reg_range(REG_VID_CHA_HORIZONTAL_FRONT_PORCH, + REG_VID_CHA_HORIZONTAL_FRONT_PORCH), + regmap_reg_range(REG_VID_CHA_VERTICAL_FRONT_PORCH, + REG_VID_CHA_VERTICAL_FRONT_PORCH), + regmap_reg_range(REG_VID_CHA_TEST_PATTERN, REG_VID_CHA_TEST_PATTERN), + regmap_reg_range(REG_IRQ_GLOBAL, REG_IRQ_EN), + regmap_reg_range(REG_IRQ_STAT, REG_IRQ_STAT), +}; + +static const struct regmap_access_table sn65dsi83_readable_table = { + .yes_ranges = sn65dsi83_readable_ranges, + .n_yes_ranges = ARRAY_SIZE(sn65dsi83_readable_ranges), +}; + +static const struct regmap_range sn65dsi83_writeable_ranges[] = { + regmap_reg_range(REG_RC_RESET, REG_RC_DSI_CLK), + regmap_reg_range(REG_RC_PLL_EN, REG_RC_PLL_EN), + regmap_reg_range(REG_DSI_LANE, REG_DSI_CLK), + regmap_reg_range(REG_LVDS_FMT, REG_LVDS_CM), + regmap_reg_range(REG_VID_CHA_ACTIVE_LINE_LENGTH_LOW, + REG_VID_CHA_ACTIVE_LINE_LENGTH_HIGH), + regmap_reg_range(REG_VID_CHA_VERTICAL_DISPLAY_SIZE_LOW, + REG_VID_CHA_VERTICAL_DISPLAY_SIZE_HIGH), + regmap_reg_range(REG_VID_CHA_SYNC_DELAY_LOW, + REG_VID_CHA_SYNC_DELAY_HIGH), + regmap_reg_range(REG_VID_CHA_HSYNC_PULSE_WIDTH_LOW, + REG_VID_CHA_HSYNC_PULSE_WIDTH_HIGH), + regmap_reg_range(REG_VID_CHA_VSYNC_PULSE_WIDTH_LOW, + REG_VID_CHA_VSYNC_PULSE_WIDTH_HIGH), + regmap_reg_range(REG_VID_CHA_HORIZONTAL_BACK_PORCH, + REG_VID_CHA_HORIZONTAL_BACK_PORCH), + regmap_reg_range(REG_VID_CHA_VERTICAL_BACK_PORCH, + REG_VID_CHA_VERTICAL_BACK_PORCH), + regmap_reg_range(REG_VID_CHA_HORIZONTAL_FRONT_PORCH, + REG_VID_CHA_HORIZONTAL_FRONT_PORCH), + regmap_reg_range(REG_VID_CHA_VERTICAL_FRONT_PORCH, + REG_VID_CHA_VERTICAL_FRONT_PORCH), + regmap_reg_range(REG_VID_CHA_TEST_PATTERN, REG_VID_CHA_TEST_PATTERN), + regmap_reg_range(REG_IRQ_GLOBAL, REG_IRQ_EN), + regmap_reg_range(REG_IRQ_STAT, REG_IRQ_STAT), +}; + +static const struct regmap_access_table sn65dsi83_writeable_table = { + .yes_ranges = sn65dsi83_writeable_ranges, + .n_yes_ranges = ARRAY_SIZE(sn65dsi83_writeable_ranges), +}; + +static const struct regmap_range sn65dsi83_volatile_ranges[] = { + regmap_reg_range(REG_RC_LVDS_PLL, REG_RC_LVDS_PLL), + regmap_reg_range(REG_IRQ_STAT, REG_IRQ_STAT), +}; + +static const struct regmap_access_table sn65dsi83_volatile_table = { + .yes_ranges = sn65dsi83_volatile_ranges, + .n_yes_ranges = ARRAY_SIZE(sn65dsi83_volatile_ranges), +}; + +static const struct regmap_config sn65dsi83_regmap_config = { + .reg_bits = 8, + .val_bits = 8, + .rd_table = &sn65dsi83_readable_table, + .wr_table = &sn65dsi83_writeable_table, + .volatile_table = &sn65dsi83_volatile_table, + .cache_type = REGCACHE_RBTREE, + .max_register = REG_IRQ_STAT, +}; + +static struct sn65dsi83 *bridge_to_sn65dsi83(struct drm_bridge *bridge) +{ + return container_of(bridge, struct sn65dsi83, bridge); +} + +static int sn65dsi83_attach(struct drm_bridge *bridge, + enum drm_bridge_attach_flags flags) +{ + struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge); + struct device *dev = ctx->dev; + struct mipi_dsi_device *dsi; + struct mipi_dsi_host *host; + int ret = 0; + + const struct mipi_dsi_device_info info = { + .type = "sn65dsi83", + .channel = 0, + .node = NULL, + }; + + host = of_find_mipi_dsi_host_by_node(ctx->host_node); + if (!host) { + dev_err(dev, "failed to find dsi host\n"); + return -EPROBE_DEFER; + } + + dsi = mipi_dsi_device_register_full(host, &info); + if (IS_ERR(dsi)) { + ret = PTR_ERR(dsi); + dev_err(dev, "failed to create dsi device, ret=%i\n", ret); + goto err_dsi_device; + } + + ctx->dsi = dsi; + + dsi->lanes = ctx->dsi_lanes; + dsi->format = MIPI_DSI_FMT_RGB888; + dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST; + + ret = mipi_dsi_attach(dsi); + if (ret < 0) { + dev_err(dev, "failed to attach dsi to host\n"); + goto err_dsi_attach; + } + + return drm_bridge_attach(bridge->encoder, ctx->panel_bridge, + &ctx->bridge, flags); + +err_dsi_attach: + mipi_dsi_device_unregister(dsi); +err_dsi_device: + return ret; +} + +static void sn65dsi83_pre_enable(struct drm_bridge *bridge) +{ + struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge); + + /* + * Reset the chip, pull EN line low for t_reset=10ms, + * then high for t_en=1ms. + */ + gpiod_set_value(ctx->enable_gpio, 0); + usleep_range(10000, 11000); + gpiod_set_value(ctx->enable_gpio, 1); + usleep_range(1000, 1100); +} + +static u8 sn65dsi83_get_lvds_range(struct sn65dsi83 *ctx) +{ + /* + * The encoding of the LVDS_CLK_RANGE is as follows: + * 000 - 25 MHz <= LVDS_CLK < 37.5 MHz + * 001 - 37.5 MHz <= LVDS_CLK < 62.5 MHz + * 010 - 62.5 MHz <= LVDS_CLK < 87.5 MHz + * 011 - 87.5 MHz <= LVDS_CLK < 112.5 MHz + * 100 - 112.5 MHz <= LVDS_CLK < 137.5 MHz + * 101 - 137.5 MHz <= LVDS_CLK <= 154 MHz + * which is a range of 12.5MHz..162.5MHz in 50MHz steps, except that + * the ends of the ranges are clamped to the supported range. Since + * sn65dsi83_mode_valid() already filters the valid modes and limits + * the clock to 25..154 MHz, the range calculation can be simplified + * as follows: + */ + return (ctx->mode.clock - 12500) / 25000; +} + +static u8 sn65dsi83_get_dsi_range(struct sn65dsi83 *ctx) +{ + /* + * The encoding of the CHA_DSI_CLK_RANGE is as follows: + * 0x00 through 0x07 - Reserved + * 0x08 - 40 <= DSI_CLK < 45 MHz + * 0x09 - 45 <= DSI_CLK < 50 MHz + * ... + * 0x63 - 495 <= DSI_CLK < 500 MHz + * 0x64 - 500 MHz + * 0x65 through 0xFF - Reserved + * which is DSI clock in 5 MHz steps, clamped to 40..500 MHz. + * The DSI clock are calculated as: + * DSI_CLK = mode clock * bpp / dsi_data_lanes / 2 + * the 2 is there because the bus is DDR. + */ + return clamp((unsigned int)ctx->mode.clock * + mipi_dsi_pixel_format_to_bpp(ctx->dsi->format) / + ctx->dsi_lanes / 2, 40000U, 500000U) / 5000U; +} + +static u8 sn65dsi83_get_dsi_div(struct sn65dsi83 *ctx) +{ + /* The divider is (DSI_CLK / LVDS_CLK) - 1, which really is: */ + return (mipi_dsi_pixel_format_to_bpp(ctx->dsi->format) / + ctx->dsi_lanes / 2) - 1; +} + +static void sn65dsi83_enable(struct drm_bridge *bridge) +{ + struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge); + u16 val; + + /* Clear reset, disable PLL */ + regmap_write(ctx->regmap, 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); + regmap_write(ctx->regmap, REG_DSI_CLK, + REG_DSI_CLK_CHA_DSI_CLK_RANGE(sn65dsi83_get_dsi_range(ctx))); + regmap_write(ctx->regmap, REG_RC_DSI_CLK, + REG_RC_DSI_CLK_DSI_CLK_DIVIDER(sn65dsi83_get_dsi_div(ctx))); + + /* Set number of DSI lanes, keep reserved bits. */ + regmap_write(ctx->regmap, REG_DSI_LANE, + REG_DSI_LANE_RESERVED | + REG_DSI_LANE_CHA_DSI_LANES(~(ctx->dsi_lanes - 1))); + /* No equalization. */ + regmap_write(ctx->regmap, REG_DSI_EQ, 0x00); + + /* RGB888 is the only format supported so far. */ + regmap_write(ctx->regmap, REG_LVDS_FMT, + (ctx->mode.flags & DRM_MODE_FLAG_NHSYNC ? + REG_LVDS_FMT_HS_NEG_POLARITY : 0) | + (ctx->mode.flags & DRM_MODE_FLAG_NVSYNC ? + REG_LVDS_FMT_VS_NEG_POLARITY : 0) | + REG_LVDS_FMT_RESERVED | + REG_LVDS_FMT_CHA_24BPP_MODE); + regmap_write(ctx->regmap, REG_LVDS_VCOM, 0x00); + regmap_write(ctx->regmap, REG_LVDS_LANE, REG_LVDS_LANE_CHA_LVDS_TERM); + regmap_write(ctx->regmap, REG_LVDS_CM, 0x00); + + regmap_bulk_write(ctx->regmap, REG_VID_CHA_ACTIVE_LINE_LENGTH_LOW, + &ctx->mode.hdisplay, 2); + regmap_bulk_write(ctx->regmap, REG_VID_CHA_VERTICAL_DISPLAY_SIZE_LOW, + &ctx->mode.vdisplay, 2); + val = 32 + 1; /* 32 + 1 pixel clock to ensure proper operation */ + regmap_bulk_write(ctx->regmap, REG_VID_CHA_SYNC_DELAY_LOW, &val, 2); + val = ctx->mode.hsync_end - ctx->mode.hsync_start; + regmap_bulk_write(ctx->regmap, REG_VID_CHA_HSYNC_PULSE_WIDTH_LOW, + &val, 2); + val = ctx->mode.vsync_end - ctx->mode.vsync_start; + regmap_bulk_write(ctx->regmap, REG_VID_CHA_VSYNC_PULSE_WIDTH_LOW, + &val, 2); + regmap_write(ctx->regmap, REG_VID_CHA_HORIZONTAL_BACK_PORCH, + ctx->mode.htotal - ctx->mode.hsync_end); + regmap_write(ctx->regmap, REG_VID_CHA_VERTICAL_BACK_PORCH, + ctx->mode.vtotal - ctx->mode.vsync_end); + regmap_write(ctx->regmap, REG_VID_CHA_HORIZONTAL_FRONT_PORCH, + ctx->mode.hsync_start - ctx->mode.hdisplay); + regmap_write(ctx->regmap, REG_VID_CHA_VERTICAL_FRONT_PORCH, + ctx->mode.vsync_start - ctx->mode.vdisplay); + regmap_write(ctx->regmap, REG_VID_CHA_TEST_PATTERN, 0x00); + + /* Enable PLL */ + regmap_write(ctx->regmap, REG_RC_PLL_EN, REG_RC_PLL_EN_PLL_EN); + /* Trigger reset after CSR register update. */ + regmap_write(ctx->regmap, REG_RC_RESET, REG_RC_RESET_SOFT_RESET); +} + +static void sn65dsi83_disable(struct drm_bridge *bridge) +{ + struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge); + + /* Clear reset, disable PLL */ + regmap_write(ctx->regmap, REG_RC_RESET, 0x00); + regmap_write(ctx->regmap, REG_RC_PLL_EN, 0x00); +} + +static void sn65dsi83_post_disable(struct drm_bridge *bridge) +{ + struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge); + + /* Put the chip in reset, pull EN line low. */ + gpiod_set_value(ctx->enable_gpio, 0); +} + +static enum drm_mode_status +sn65dsi83_mode_valid(struct drm_bridge *bridge, + const struct drm_display_info *info, + const struct drm_display_mode *mode) +{ + /* LVDS output clock range 25..154 MHz */ + if (mode->clock < 25000) + return MODE_CLOCK_LOW; + if (mode->clock > 154000) + return MODE_CLOCK_HIGH; + + return MODE_OK; +} + +static void sn65dsi83_mode_set(struct drm_bridge *bridge, + const struct drm_display_mode *mode, + const struct drm_display_mode *adj) +{ + struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge); + + ctx->mode = *mode; +} + +static const struct drm_bridge_funcs sn65dsi83_funcs = { + .attach = sn65dsi83_attach, + .pre_enable = sn65dsi83_pre_enable, + .enable = sn65dsi83_enable, + .disable = sn65dsi83_disable, + .post_disable = sn65dsi83_post_disable, + .mode_valid = sn65dsi83_mode_valid, + .mode_set = sn65dsi83_mode_set, +}; + +static int sn65dsi83_parse_dt(struct sn65dsi83 *ctx) +{ + struct drm_bridge *panel_bridge; + struct device *dev = ctx->dev; + struct device_node *endpoint; + struct drm_panel *panel; + int ret; + + endpoint = of_graph_get_endpoint_by_regs(dev->of_node, 0, 0); + ctx->dsi_lanes = of_property_count_u32_elems(endpoint, "data-lanes"); + ctx->host_node = of_graph_get_remote_port_parent(endpoint); + of_node_put(endpoint); + of_node_put(ctx->host_node); + + if (ctx->dsi_lanes < 0 || ctx->dsi_lanes > 4) + return -EINVAL; + if (!ctx->host_node) + return -ENODEV; + + ret = drm_of_find_panel_or_bridge(dev->of_node, 1, 0, &panel, &panel_bridge); + if (ret < 0) + return ret; + if (panel) { + panel_bridge = devm_drm_panel_bridge_add(dev, panel); + if (IS_ERR(panel_bridge)) + return PTR_ERR(panel_bridge); + } + + ctx->panel_bridge = panel_bridge; + + return 0; +} + +static int sn65dsi83_probe(struct i2c_client *client, + const struct i2c_device_id *id) +{ + struct device *dev = &client->dev; + struct sn65dsi83 *ctx; + int ret; + + ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL); + if (!ctx) + return -ENOMEM; + + ctx->dev = dev; + + ctx->enable_gpio = devm_gpiod_get(ctx->dev, "enable", GPIOD_OUT_LOW); + if (IS_ERR(ctx->enable_gpio)) + return PTR_ERR(ctx->enable_gpio); + + ret = sn65dsi83_parse_dt(ctx); + if (ret) + return ret; + + ctx->regmap = devm_regmap_init_i2c(client, &sn65dsi83_regmap_config); + if (IS_ERR(ctx->regmap)) + return PTR_ERR(ctx->regmap); + + dev_set_drvdata(dev, ctx); + i2c_set_clientdata(client, ctx); + + ctx->bridge.funcs = &sn65dsi83_funcs; + ctx->bridge.of_node = dev->of_node; + drm_bridge_add(&ctx->bridge); + + return 0; +} + +static int sn65dsi83_remove(struct i2c_client *client) +{ + struct sn65dsi83 *ctx = i2c_get_clientdata(client); + + mipi_dsi_detach(ctx->dsi); + mipi_dsi_device_unregister(ctx->dsi); + drm_bridge_remove(&ctx->bridge); + + return 0; +} + +static struct i2c_device_id sn65dsi83_id[] = { + { "ti,sn65dsi83", 0 }, + {}, +}; +MODULE_DEVICE_TABLE(i2c, sn65dsi83_id); + +static const struct of_device_id sn65dsi83_match_table[] = { + { .compatible = "ti,sn65dsi83" }, + {}, +}; +MODULE_DEVICE_TABLE(of, sn65dsi83_match_table); + +static struct i2c_driver sn65dsi83_driver = { + .probe = sn65dsi83_probe, + .remove = sn65dsi83_remove, + .id_table = sn65dsi83_id, + .driver = { + .name = "sn65dsi83", + .of_match_table = sn65dsi83_match_table, + }, +}; +module_i2c_driver(sn65dsi83_driver); + +MODULE_AUTHOR("Marek Vasut marex@denx.de"); +MODULE_DESCRIPTION("TI SN65DSI83 DSI to LVDS bridge driver"); +MODULE_LICENSE("GPL v2");
Hi,
On Sat, Jan 30, 2021 at 10:10 AM Marek Vasut marex@denx.de wrote:
Add driver for TI SN65DSI83 Single-Channel DSI to Single-Link LVDS bridge. The driver operates the chip over I2C bus. Currently the LVDS clock are always derived from DSI clock lane, which is the usual mode of operation, support for clock from external oscillator is not implemented, but it is easy to add if ever needed. Only RGB888 pixel format is implemented, the LVDS666 is not supported, but could be added if needed.
Signed-off-by: Marek Vasut marex@denx.de Cc: Douglas Anderson dianders@chromium.org Cc: Laurent Pinchart laurent.pinchart@ideasonboard.com Cc: Linus Walleij linus.walleij@linaro.org Cc: Philippe Schenker philippe.schenker@toradex.com Cc: Sam Ravnborg sam@ravnborg.org Cc: Stephen Boyd swboyd@chromium.org Cc: Valentin Raevsky valentin@compulab.co.il To: dri-devel@lists.freedesktop.org
drivers/gpu/drm/bridge/Kconfig | 10 + drivers/gpu/drm/bridge/Makefile | 1 + drivers/gpu/drm/bridge/ti-sn65dsi83.c | 535 ++++++++++++++++++++++++++ 3 files changed, 546 insertions(+)
I shouldn't be the main reviewer because, as I've said elsewhere, I'm a DRM noob and know almost nothing about LVDS or MIPI. :-P ...but I've hacked a bunch on the sn65dsi86 driver and lots of others have helped me with reviews, so I'll give it a shot...
create mode 100644 drivers/gpu/drm/bridge/ti-sn65dsi83.c
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index cc401786962a..5e4f674e3fdb 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -234,6 +234,16 @@ config DRM_TI_TFP410 help Texas Instruments TFP410 DVI/HDMI Transmitter driver
+config DRM_TI_SN65DSI83
tristate "TI SN65DSI83 DSI to LVDS bridge"depends on OFselect DRM_KMS_HELPERselect REGMAP_I2Cselect DRM_PANELselect DRM_MIPI_DSIhelpTexas Instruments SN65DSI83 DSI to LVDS Bridge driverconfig DRM_TI_SN65DSI86 tristate "TI SN65DSI86 DSI to eDP bridge" depends on OF diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile index 21ea8fe09992..e11415db0a31 100644 --- a/drivers/gpu/drm/bridge/Makefile +++ b/drivers/gpu/drm/bridge/Makefile @@ -21,6 +21,7 @@ obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o obj-$(CONFIG_DRM_TOSHIBA_TC358768) += tc358768.o obj-$(CONFIG_DRM_TOSHIBA_TC358775) += tc358775.o obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/ +obj-$(CONFIG_DRM_TI_SN65DSI83) += ti-sn65dsi83.o obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o obj-$(CONFIG_DRM_TI_TPD12S015) += ti-tpd12s015.o diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c b/drivers/gpu/drm/bridge/ti-sn65dsi83.c new file mode 100644 index 000000000000..79c023ba3dce --- /dev/null +++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c @@ -0,0 +1,535 @@ +// SPDX-License-Identifier: GPL-2.0 +/*
- Copyright (C) 2021 Marek Vasut marex@denx.de
- Based on previous work of:
- Valentin Raevsky valentin@compulab.co.il
- Philippe Schenker philippe.schenker@toradex.com
- */
+#include <linux/bits.h> +#include <linux/clk.h> +#include <linux/gpio/consumer.h> +#include <linux/i2c.h> +#include <linux/module.h> +#include <linux/of_graph.h> +#include <linux/regmap.h>
+#include <drm/drm_atomic_helper.h> +#include <drm/drm_bridge.h> +#include <drm/drm_mipi_dsi.h> +#include <drm/drm_of.h> +#include <drm/drm_panel.h> +#include <drm/drm_print.h> +#include <drm/drm_probe_helper.h>
+/* ID registers */ +#define REG_ID(n) (0x00 + (n)) +/* Reset and clock registers */ +#define REG_RC_RESET 0x09 +#define REG_RC_RESET_SOFT_RESET BIT(0) +#define REG_RC_LVDS_PLL 0x0a +#define REG_RC_LVDS_PLL_PLL_EN_STAT BIT(7) +#define REG_RC_LVDS_PLL_LVDS_CLK_RANGE(n) (((n) & 0x7) << 1) +#define REG_RC_LVDS_PLL_HS_CLK_SRC_DPHY BIT(0) +#define REG_RC_DSI_CLK 0x0b +#define REG_RC_DSI_CLK_DSI_CLK_DIVIDER(n) (((n) & 0x1f) << 3) +#define REG_RC_DSI_CLK_REFCLK_MULTIPLIER(n) ((n) & 0x3) +#define REG_RC_PLL_EN 0x0d +#define REG_RC_PLL_EN_PLL_EN BIT(0) +/* DSI registers */ +#define REG_DSI_LANE 0x10 +#define REG_DSI_LANE_RESERVED BIT(5) +#define REG_DSI_LANE_CHA_DSI_LANES(n) (((n) & 0x3) << 3) +#define REG_DSI_LANE_SOT_ERR_TOL_DIS BIT(0) +#define REG_DSI_EQ 0x11 +#define REG_DSI_EQ_CHA_DSI_DATA_EQ(n) (((n) & 0x3) << 6) +#define REG_DSI_EQ_CHA_DSI_CLK_EQ(n) (((n) & 0x3) << 2) +#define REG_DSI_CLK 0x12 +#define REG_DSI_CLK_CHA_DSI_CLK_RANGE(n) ((n) & 0xff) +/* LVDS registers */ +#define REG_LVDS_FMT 0x18 +#define REG_LVDS_FMT_DE_NEG_POLARITY BIT(7) +#define REG_LVDS_FMT_HS_NEG_POLARITY BIT(6) +#define REG_LVDS_FMT_VS_NEG_POLARITY BIT(5) +#define REG_LVDS_FMT_RESERVED BIT(4) /* Set to 1 */ +#define REG_LVDS_FMT_CHA_24BPP_MODE BIT(3) +#define REG_LVDS_FMT_CHA_24BPP_FORMAT1 BIT(1) +#define REG_LVDS_VCOM 0x19 +#define REG_LVDS_VCOM_CHA_LVDS_VOCM BIT(6) +#define REG_LVDS_VCOM_CHA_LVDS_VOD_SWING(n) (((n) & 0x3) << 2) +#define REG_LVDS_LANE 0x1a +#define REG_LVDS_LANE_CHA_REVERSE_LVDS BIT(5) +#define REG_LVDS_LANE_CHA_LVDS_TERM BIT(1) +#define REG_LVDS_CM 0x1b +#define REG_LVDS_CM_CHA_LVDS_CM_ADJUST(n) ((n) & 0x3) +/* Video registers */ +#define REG_VID_CHA_ACTIVE_LINE_LENGTH_LOW 0x20 +#define REG_VID_CHA_ACTIVE_LINE_LENGTH_HIGH 0x21 +#define REG_VID_CHA_VERTICAL_DISPLAY_SIZE_LOW 0x24 +#define REG_VID_CHA_VERTICAL_DISPLAY_SIZE_HIGH 0x25 +#define REG_VID_CHA_SYNC_DELAY_LOW 0x28 +#define REG_VID_CHA_SYNC_DELAY_HIGH 0x29 +#define REG_VID_CHA_HSYNC_PULSE_WIDTH_LOW 0x2c +#define REG_VID_CHA_HSYNC_PULSE_WIDTH_HIGH 0x2d +#define REG_VID_CHA_VSYNC_PULSE_WIDTH_LOW 0x30 +#define REG_VID_CHA_VSYNC_PULSE_WIDTH_HIGH 0x31 +#define REG_VID_CHA_HORIZONTAL_BACK_PORCH 0x34 +#define REG_VID_CHA_VERTICAL_BACK_PORCH 0x36 +#define REG_VID_CHA_HORIZONTAL_FRONT_PORCH 0x38 +#define REG_VID_CHA_VERTICAL_FRONT_PORCH 0x3a +#define REG_VID_CHA_TEST_PATTERN 0x3c +/* IRQ registers */ +#define REG_IRQ_GLOBAL 0xe0 +#define REG_IRQ_GLOBAL_IRQ_EN BIT(0) +#define REG_IRQ_EN 0xe1 +#define REG_IRQ_EN_CHA_SYNCH_ERR_EN BIT(7) +#define REG_IRQ_EN_CHA_CRC_ERR_EN BIT(6) +#define REG_IRQ_EN_CHA_UNC_ECC_ERR_EN BIT(5) +#define REG_IRQ_EN_CHA_COR_ECC_ERR_EN BIT(4) +#define REG_IRQ_EN_CHA_LLP_ERR_EN BIT(3) +#define REG_IRQ_EN_CHA_SOT_BIT_ERR_EN BIT(2) +#define REG_IRQ_EN_CHA_PLL_UNLOCK_EN BIT(0) +#define REG_IRQ_STAT 0xe5 +#define REG_IRQ_STAT_CHA_SYNCH_ERR BIT(7) +#define REG_IRQ_STAT_CHA_CRC_ERR BIT(6) +#define REG_IRQ_STAT_CHA_UNC_ECC_ERR BIT(5) +#define REG_IRQ_STAT_CHA_COR_ECC_ERR BIT(4) +#define REG_IRQ_STAT_CHA_LLP_ERR BIT(3) +#define REG_IRQ_STAT_CHA_SOT_BIT_ERR BIT(2) +#define REG_IRQ_STAT_CHA_PLL_UNLOCK BIT(0)
+struct sn65dsi83 {
struct drm_bridge bridge;struct drm_display_mode mode;struct device *dev;struct regmap *regmap;struct device_node *host_node;struct mipi_dsi_device *dsi;struct drm_bridge *panel_bridge;struct gpio_desc *enable_gpio;int dsi_lanes;+};
+static const struct regmap_range sn65dsi83_readable_ranges[] = {
regmap_reg_range(REG_ID(0), REG_ID(8)),regmap_reg_range(REG_RC_LVDS_PLL, REG_RC_DSI_CLK),regmap_reg_range(REG_RC_PLL_EN, REG_RC_PLL_EN),regmap_reg_range(REG_DSI_LANE, REG_DSI_CLK),regmap_reg_range(REG_LVDS_FMT, REG_LVDS_CM),regmap_reg_range(REG_VID_CHA_ACTIVE_LINE_LENGTH_LOW,REG_VID_CHA_ACTIVE_LINE_LENGTH_HIGH),regmap_reg_range(REG_VID_CHA_VERTICAL_DISPLAY_SIZE_LOW,REG_VID_CHA_VERTICAL_DISPLAY_SIZE_HIGH),regmap_reg_range(REG_VID_CHA_SYNC_DELAY_LOW,REG_VID_CHA_SYNC_DELAY_HIGH),regmap_reg_range(REG_VID_CHA_HSYNC_PULSE_WIDTH_LOW,REG_VID_CHA_HSYNC_PULSE_WIDTH_HIGH),regmap_reg_range(REG_VID_CHA_VSYNC_PULSE_WIDTH_LOW,REG_VID_CHA_VSYNC_PULSE_WIDTH_HIGH),regmap_reg_range(REG_VID_CHA_HORIZONTAL_BACK_PORCH,REG_VID_CHA_HORIZONTAL_BACK_PORCH),regmap_reg_range(REG_VID_CHA_VERTICAL_BACK_PORCH,REG_VID_CHA_VERTICAL_BACK_PORCH),regmap_reg_range(REG_VID_CHA_HORIZONTAL_FRONT_PORCH,REG_VID_CHA_HORIZONTAL_FRONT_PORCH),regmap_reg_range(REG_VID_CHA_VERTICAL_FRONT_PORCH,REG_VID_CHA_VERTICAL_FRONT_PORCH),regmap_reg_range(REG_VID_CHA_TEST_PATTERN, REG_VID_CHA_TEST_PATTERN),regmap_reg_range(REG_IRQ_GLOBAL, REG_IRQ_EN),regmap_reg_range(REG_IRQ_STAT, REG_IRQ_STAT),+};
+static const struct regmap_access_table sn65dsi83_readable_table = {
.yes_ranges = sn65dsi83_readable_ranges,.n_yes_ranges = ARRAY_SIZE(sn65dsi83_readable_ranges),+};
+static const struct regmap_range sn65dsi83_writeable_ranges[] = {
regmap_reg_range(REG_RC_RESET, REG_RC_DSI_CLK),regmap_reg_range(REG_RC_PLL_EN, REG_RC_PLL_EN),regmap_reg_range(REG_DSI_LANE, REG_DSI_CLK),regmap_reg_range(REG_LVDS_FMT, REG_LVDS_CM),regmap_reg_range(REG_VID_CHA_ACTIVE_LINE_LENGTH_LOW,REG_VID_CHA_ACTIVE_LINE_LENGTH_HIGH),regmap_reg_range(REG_VID_CHA_VERTICAL_DISPLAY_SIZE_LOW,REG_VID_CHA_VERTICAL_DISPLAY_SIZE_HIGH),regmap_reg_range(REG_VID_CHA_SYNC_DELAY_LOW,REG_VID_CHA_SYNC_DELAY_HIGH),regmap_reg_range(REG_VID_CHA_HSYNC_PULSE_WIDTH_LOW,REG_VID_CHA_HSYNC_PULSE_WIDTH_HIGH),regmap_reg_range(REG_VID_CHA_VSYNC_PULSE_WIDTH_LOW,REG_VID_CHA_VSYNC_PULSE_WIDTH_HIGH),regmap_reg_range(REG_VID_CHA_HORIZONTAL_BACK_PORCH,REG_VID_CHA_HORIZONTAL_BACK_PORCH),regmap_reg_range(REG_VID_CHA_VERTICAL_BACK_PORCH,REG_VID_CHA_VERTICAL_BACK_PORCH),regmap_reg_range(REG_VID_CHA_HORIZONTAL_FRONT_PORCH,REG_VID_CHA_HORIZONTAL_FRONT_PORCH),regmap_reg_range(REG_VID_CHA_VERTICAL_FRONT_PORCH,REG_VID_CHA_VERTICAL_FRONT_PORCH),regmap_reg_range(REG_VID_CHA_TEST_PATTERN, REG_VID_CHA_TEST_PATTERN),regmap_reg_range(REG_IRQ_GLOBAL, REG_IRQ_EN),regmap_reg_range(REG_IRQ_STAT, REG_IRQ_STAT),+};
+static const struct regmap_access_table sn65dsi83_writeable_table = {
.yes_ranges = sn65dsi83_writeable_ranges,.n_yes_ranges = ARRAY_SIZE(sn65dsi83_writeable_ranges),+};
+static const struct regmap_range sn65dsi83_volatile_ranges[] = {
regmap_reg_range(REG_RC_LVDS_PLL, REG_RC_LVDS_PLL),
Why is REG_RC_LVDS_PLL volatile?
regmap_reg_range(REG_IRQ_STAT, REG_IRQ_STAT),
Do you need to list REG_RC_RESET as volatile? Specifically you need to make sure it's not cached...
+};
+static const struct regmap_access_table sn65dsi83_volatile_table = {
.yes_ranges = sn65dsi83_volatile_ranges,.n_yes_ranges = ARRAY_SIZE(sn65dsi83_volatile_ranges),+};
+static const struct regmap_config sn65dsi83_regmap_config = {
.reg_bits = 8,.val_bits = 8,.rd_table = &sn65dsi83_readable_table,.wr_table = &sn65dsi83_writeable_table,.volatile_table = &sn65dsi83_volatile_table,.cache_type = REGCACHE_RBTREE,.max_register = REG_IRQ_STAT,+};
I'm curious how much the "readable" and "writable" sections get you. In theory only the "volatile" should really matter, right?
+static struct sn65dsi83 *bridge_to_sn65dsi83(struct drm_bridge *bridge) +{
return container_of(bridge, struct sn65dsi83, bridge);+}
+static int sn65dsi83_attach(struct drm_bridge *bridge,
enum drm_bridge_attach_flags flags)+{
struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge);struct device *dev = ctx->dev;struct mipi_dsi_device *dsi;struct mipi_dsi_host *host;int ret = 0;const struct mipi_dsi_device_info info = {.type = "sn65dsi83",.channel = 0,.node = NULL,};host = of_find_mipi_dsi_host_by_node(ctx->host_node);if (!host) {dev_err(dev, "failed to find dsi host\n");
I notice that the sn65dsi86 driver usually uses DRM_ERROR instead of dev_err().
return -EPROBE_DEFER;}dsi = mipi_dsi_device_register_full(host, &info);if (IS_ERR(dsi)) {ret = PTR_ERR(dsi);dev_err(dev, "failed to create dsi device, ret=%i\n", ret);goto err_dsi_device;
Why not just "return ret" and get rid of the "err_dsi_device" label?
}ctx->dsi = dsi;dsi->lanes = ctx->dsi_lanes;dsi->format = MIPI_DSI_FMT_RGB888;dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST;ret = mipi_dsi_attach(dsi);if (ret < 0) {dev_err(dev, "failed to attach dsi to host\n");goto err_dsi_attach;}return drm_bridge_attach(bridge->encoder, ctx->panel_bridge,&ctx->bridge, flags);+err_dsi_attach:
mipi_dsi_device_unregister(dsi);+err_dsi_device:
return ret;+}
+static void sn65dsi83_pre_enable(struct drm_bridge *bridge) +{
struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge);/** Reset the chip, pull EN line low for t_reset=10ms,* then high for t_en=1ms.*/gpiod_set_value(ctx->enable_gpio, 0);
Why not use the "cansleep" version to give some flexibility?
usleep_range(10000, 11000);
It seems like it would be worth it to read the enable_gpio first? If it was already 0 maybe you can skip the 10 ms delay? I would imagine that most of the time the bridge would already be disabled to start?
gpiod_set_value(ctx->enable_gpio, 1);usleep_range(1000, 1100);
This fully resets the chip, right? So you need to invalidate your regmap cache?
+}
+static u8 sn65dsi83_get_lvds_range(struct sn65dsi83 *ctx) +{
/** The encoding of the LVDS_CLK_RANGE is as follows:* 000 - 25 MHz <= LVDS_CLK < 37.5 MHz* 001 - 37.5 MHz <= LVDS_CLK < 62.5 MHz* 010 - 62.5 MHz <= LVDS_CLK < 87.5 MHz* 011 - 87.5 MHz <= LVDS_CLK < 112.5 MHz* 100 - 112.5 MHz <= LVDS_CLK < 137.5 MHz* 101 - 137.5 MHz <= LVDS_CLK <= 154 MHz* which is a range of 12.5MHz..162.5MHz in 50MHz steps, except that* the ends of the ranges are clamped to the supported range. Since* sn65dsi83_mode_valid() already filters the valid modes and limits* the clock to 25..154 MHz, the range calculation can be simplified* as follows:*/return (ctx->mode.clock - 12500) / 25000;+}
+static u8 sn65dsi83_get_dsi_range(struct sn65dsi83 *ctx) +{
/** The encoding of the CHA_DSI_CLK_RANGE is as follows:* 0x00 through 0x07 - Reserved* 0x08 - 40 <= DSI_CLK < 45 MHz* 0x09 - 45 <= DSI_CLK < 50 MHz* ...* 0x63 - 495 <= DSI_CLK < 500 MHz* 0x64 - 500 MHz* 0x65 through 0xFF - Reserved* which is DSI clock in 5 MHz steps, clamped to 40..500 MHz.* The DSI clock are calculated as:* DSI_CLK = mode clock * bpp / dsi_data_lanes / 2* the 2 is there because the bus is DDR.*/return clamp((unsigned int)ctx->mode.clock *mipi_dsi_pixel_format_to_bpp(ctx->dsi->format) /ctx->dsi_lanes / 2, 40000U, 500000U) / 5000U;+}
+static u8 sn65dsi83_get_dsi_div(struct sn65dsi83 *ctx) +{
/* The divider is (DSI_CLK / LVDS_CLK) - 1, which really is: */return (mipi_dsi_pixel_format_to_bpp(ctx->dsi->format) /ctx->dsi_lanes / 2) - 1;+}
+static void sn65dsi83_enable(struct drm_bridge *bridge) +{
struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge);u16 val;/* Clear reset, disable PLL */regmap_write(ctx->regmap, REG_RC_RESET, 0x00);
I don't think you need to clear reset, do you? The doc says "This bit automatically clears when set to 1 and returns 0s when read." Maybe was needed because you forgot to list this register as volatile?
regmap_write(ctx->regmap, REG_RC_PLL_EN, 0x00);
Probably you don't need this? It's the default and in pre-enable you just reset the chip. Maybe it was needed since you don't flush the cache in pre-enable?
/* 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);regmap_write(ctx->regmap, REG_DSI_CLK,REG_DSI_CLK_CHA_DSI_CLK_RANGE(sn65dsi83_get_dsi_range(ctx)));regmap_write(ctx->regmap, REG_RC_DSI_CLK,REG_RC_DSI_CLK_DSI_CLK_DIVIDER(sn65dsi83_get_dsi_div(ctx)));/* Set number of DSI lanes, keep reserved bits. */regmap_write(ctx->regmap, REG_DSI_LANE,REG_DSI_LANE_RESERVED |REG_DSI_LANE_CHA_DSI_LANES(~(ctx->dsi_lanes - 1)));/* No equalization. */regmap_write(ctx->regmap, REG_DSI_EQ, 0x00);/* RGB888 is the only format supported so far. */regmap_write(ctx->regmap, REG_LVDS_FMT,(ctx->mode.flags & DRM_MODE_FLAG_NHSYNC ?REG_LVDS_FMT_HS_NEG_POLARITY : 0) |(ctx->mode.flags & DRM_MODE_FLAG_NVSYNC ?REG_LVDS_FMT_VS_NEG_POLARITY : 0) |REG_LVDS_FMT_RESERVED |REG_LVDS_FMT_CHA_24BPP_MODE);regmap_write(ctx->regmap, REG_LVDS_VCOM, 0x00);regmap_write(ctx->regmap, REG_LVDS_LANE, REG_LVDS_LANE_CHA_LVDS_TERM);regmap_write(ctx->regmap, REG_LVDS_CM, 0x00);regmap_bulk_write(ctx->regmap, REG_VID_CHA_ACTIVE_LINE_LENGTH_LOW,&ctx->mode.hdisplay, 2);regmap_bulk_write(ctx->regmap, REG_VID_CHA_VERTICAL_DISPLAY_SIZE_LOW,&ctx->mode.vdisplay, 2);val = 32 + 1; /* 32 + 1 pixel clock to ensure proper operation */regmap_bulk_write(ctx->regmap, REG_VID_CHA_SYNC_DELAY_LOW, &val, 2);val = ctx->mode.hsync_end - ctx->mode.hsync_start;regmap_bulk_write(ctx->regmap, REG_VID_CHA_HSYNC_PULSE_WIDTH_LOW,&val, 2);val = ctx->mode.vsync_end - ctx->mode.vsync_start;regmap_bulk_write(ctx->regmap, REG_VID_CHA_VSYNC_PULSE_WIDTH_LOW,&val, 2);regmap_write(ctx->regmap, REG_VID_CHA_HORIZONTAL_BACK_PORCH,ctx->mode.htotal - ctx->mode.hsync_end);regmap_write(ctx->regmap, REG_VID_CHA_VERTICAL_BACK_PORCH,ctx->mode.vtotal - ctx->mode.vsync_end);regmap_write(ctx->regmap, REG_VID_CHA_HORIZONTAL_FRONT_PORCH,ctx->mode.hsync_start - ctx->mode.hdisplay);regmap_write(ctx->regmap, REG_VID_CHA_VERTICAL_FRONT_PORCH,ctx->mode.vsync_start - ctx->mode.vdisplay);regmap_write(ctx->regmap, REG_VID_CHA_TEST_PATTERN, 0x00);/* Enable PLL */regmap_write(ctx->regmap, REG_RC_PLL_EN, REG_RC_PLL_EN_PLL_EN);
After you turn on the PLL, I think you should be waiting for "PLL_EN_STAT" to show that the PLL is actually enabled and then delaying 3ms, right?
/* Trigger reset after CSR register update. */regmap_write(ctx->regmap, REG_RC_RESET, REG_RC_RESET_SOFT_RESET);+}
+static void sn65dsi83_disable(struct drm_bridge *bridge) +{
struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge);/* Clear reset, disable PLL */regmap_write(ctx->regmap, REG_RC_RESET, 0x00);
I don't think you need this--it self-clears.
regmap_write(ctx->regmap, REG_RC_PLL_EN, 0x00);+}
+static void sn65dsi83_post_disable(struct drm_bridge *bridge) +{
struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge);/* Put the chip in reset, pull EN line low. */gpiod_set_value(ctx->enable_gpio, 0);+}
+static enum drm_mode_status +sn65dsi83_mode_valid(struct drm_bridge *bridge,
const struct drm_display_info *info,const struct drm_display_mode *mode)+{
/* LVDS output clock range 25..154 MHz */if (mode->clock < 25000)return MODE_CLOCK_LOW;if (mode->clock > 154000)return MODE_CLOCK_HIGH;return MODE_OK;+}
+static void sn65dsi83_mode_set(struct drm_bridge *bridge,
const struct drm_display_mode *mode,const struct drm_display_mode *adj)+{
struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge);ctx->mode = *mode;
IIRC you should be using adj, not mode. If something earlier in the chain tweaked it then adj will be more correct.
+}
+static const struct drm_bridge_funcs sn65dsi83_funcs = {
.attach = sn65dsi83_attach,.pre_enable = sn65dsi83_pre_enable,.enable = sn65dsi83_enable,.disable = sn65dsi83_disable,.post_disable = sn65dsi83_post_disable,.mode_valid = sn65dsi83_mode_valid,.mode_set = sn65dsi83_mode_set,+};
+static int sn65dsi83_parse_dt(struct sn65dsi83 *ctx) +{
struct drm_bridge *panel_bridge;struct device *dev = ctx->dev;struct device_node *endpoint;struct drm_panel *panel;int ret;endpoint = of_graph_get_endpoint_by_regs(dev->of_node, 0, 0);ctx->dsi_lanes = of_property_count_u32_elems(endpoint, "data-lanes");ctx->host_node = of_graph_get_remote_port_parent(endpoint);of_node_put(endpoint);of_node_put(ctx->host_node);
It seems odd that you're storing "ctx->host_node" permanently in your structures but you're also calling of_node_put() on it. Are you positive that's correct? I think you need to do the of_node_put() in the remove function and probably in the error handling of this function (or use devm to handle it).
if (ctx->dsi_lanes < 0 || ctx->dsi_lanes > 4)return -EINVAL;
Should be dsi_lanes <= 0, right?
-Doug
On 2/4/21 6:15 PM, Doug Anderson wrote:
Hi,
[...]
+static const struct regmap_range sn65dsi83_volatile_ranges[] = {
regmap_reg_range(REG_RC_LVDS_PLL, REG_RC_LVDS_PLL),Why is REG_RC_LVDS_PLL volatile?
See register 0xa bit 7, PLL_EN_STAT .
regmap_reg_range(REG_IRQ_STAT, REG_IRQ_STAT),Do you need to list REG_RC_RESET as volatile? Specifically you need to make sure it's not cached...
Isn't volatile table exactly for this purpose -- to make sure the reg is not cached ?
+};
+static const struct regmap_access_table sn65dsi83_volatile_table = {
.yes_ranges = sn65dsi83_volatile_ranges,.n_yes_ranges = ARRAY_SIZE(sn65dsi83_volatile_ranges),+};
+static const struct regmap_config sn65dsi83_regmap_config = {
.reg_bits = 8,.val_bits = 8,.rd_table = &sn65dsi83_readable_table,.wr_table = &sn65dsi83_writeable_table,.volatile_table = &sn65dsi83_volatile_table,.cache_type = REGCACHE_RBTREE,.max_register = REG_IRQ_STAT,+};
I'm curious how much the "readable" and "writable" sections get you. In theory only the "volatile" should really matter, right?
They are useful when dumping the regs from debugfs regmap registers .
+static struct sn65dsi83 *bridge_to_sn65dsi83(struct drm_bridge *bridge) +{
return container_of(bridge, struct sn65dsi83, bridge);+}
+static int sn65dsi83_attach(struct drm_bridge *bridge,
enum drm_bridge_attach_flags flags)+{
struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge);struct device *dev = ctx->dev;struct mipi_dsi_device *dsi;struct mipi_dsi_host *host;int ret = 0;const struct mipi_dsi_device_info info = {.type = "sn65dsi83",.channel = 0,.node = NULL,};host = of_find_mipi_dsi_host_by_node(ctx->host_node);if (!host) {dev_err(dev, "failed to find dsi host\n");I notice that the sn65dsi86 driver usually uses DRM_ERROR instead of dev_err().
I guess you want DRM maintainers to comment on this one. I think simple dev_err() is clear in what it does, DRM_ERROR seems like another level of indirection.
return -EPROBE_DEFER;}dsi = mipi_dsi_device_register_full(host, &info);if (IS_ERR(dsi)) {ret = PTR_ERR(dsi);dev_err(dev, "failed to create dsi device, ret=%i\n", ret);goto err_dsi_device;Why not just "return ret" and get rid of the "err_dsi_device" label?
Oh, right, or even dev_err_probe().
[...]
+static void sn65dsi83_pre_enable(struct drm_bridge *bridge) +{
struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge);/** Reset the chip, pull EN line low for t_reset=10ms,* then high for t_en=1ms.*/gpiod_set_value(ctx->enable_gpio, 0);Why not use the "cansleep" version to give some flexibility?
Does that make a difference in non-interrupt context ?
usleep_range(10000, 11000);It seems like it would be worth it to read the enable_gpio first? If it was already 0 maybe you can skip the 10 ms delay? I would imagine that most of the time the bridge would already be disabled to start?
How do you guarantee the GPIO was LO for 10 mS here? You can sample that it is LO, but you won't know how long it was LO before this code was executed.
gpiod_set_value(ctx->enable_gpio, 1);usleep_range(1000, 1100);This fully resets the chip, right? So you need to invalidate your regmap cache?
Right
+}
[...]
+static void sn65dsi83_enable(struct drm_bridge *bridge) +{
struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge);u16 val;/* Clear reset, disable PLL */regmap_write(ctx->regmap, REG_RC_RESET, 0x00);I don't think you need to clear reset, do you? The doc says "This bit automatically clears when set to 1 and returns 0s when read." Maybe was needed because you forgot to list this register as volatile?
I need to check this one.
regmap_write(ctx->regmap, REG_RC_PLL_EN, 0x00);Probably you don't need this? It's the default and in pre-enable you just reset the chip. Maybe it was needed since you don't flush the cache in pre-enable?
Have a look at the Example Script in the DSI83 datasheet, this PLL part is needed.
/* 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);regmap_write(ctx->regmap, REG_DSI_CLK,REG_DSI_CLK_CHA_DSI_CLK_RANGE(sn65dsi83_get_dsi_range(ctx)));regmap_write(ctx->regmap, REG_RC_DSI_CLK,REG_RC_DSI_CLK_DSI_CLK_DIVIDER(sn65dsi83_get_dsi_div(ctx)));/* Set number of DSI lanes, keep reserved bits. */regmap_write(ctx->regmap, REG_DSI_LANE,REG_DSI_LANE_RESERVED |REG_DSI_LANE_CHA_DSI_LANES(~(ctx->dsi_lanes - 1)));/* No equalization. */regmap_write(ctx->regmap, REG_DSI_EQ, 0x00);/* RGB888 is the only format supported so far. */regmap_write(ctx->regmap, REG_LVDS_FMT,(ctx->mode.flags & DRM_MODE_FLAG_NHSYNC ?REG_LVDS_FMT_HS_NEG_POLARITY : 0) |(ctx->mode.flags & DRM_MODE_FLAG_NVSYNC ?REG_LVDS_FMT_VS_NEG_POLARITY : 0) |REG_LVDS_FMT_RESERVED |REG_LVDS_FMT_CHA_24BPP_MODE);regmap_write(ctx->regmap, REG_LVDS_VCOM, 0x00);regmap_write(ctx->regmap, REG_LVDS_LANE, REG_LVDS_LANE_CHA_LVDS_TERM);regmap_write(ctx->regmap, REG_LVDS_CM, 0x00);regmap_bulk_write(ctx->regmap, REG_VID_CHA_ACTIVE_LINE_LENGTH_LOW,&ctx->mode.hdisplay, 2);regmap_bulk_write(ctx->regmap, REG_VID_CHA_VERTICAL_DISPLAY_SIZE_LOW,&ctx->mode.vdisplay, 2);val = 32 + 1; /* 32 + 1 pixel clock to ensure proper operation */regmap_bulk_write(ctx->regmap, REG_VID_CHA_SYNC_DELAY_LOW, &val, 2);val = ctx->mode.hsync_end - ctx->mode.hsync_start;regmap_bulk_write(ctx->regmap, REG_VID_CHA_HSYNC_PULSE_WIDTH_LOW,&val, 2);val = ctx->mode.vsync_end - ctx->mode.vsync_start;regmap_bulk_write(ctx->regmap, REG_VID_CHA_VSYNC_PULSE_WIDTH_LOW,&val, 2);regmap_write(ctx->regmap, REG_VID_CHA_HORIZONTAL_BACK_PORCH,ctx->mode.htotal - ctx->mode.hsync_end);regmap_write(ctx->regmap, REG_VID_CHA_VERTICAL_BACK_PORCH,ctx->mode.vtotal - ctx->mode.vsync_end);regmap_write(ctx->regmap, REG_VID_CHA_HORIZONTAL_FRONT_PORCH,ctx->mode.hsync_start - ctx->mode.hdisplay);regmap_write(ctx->regmap, REG_VID_CHA_VERTICAL_FRONT_PORCH,ctx->mode.vsync_start - ctx->mode.vdisplay);regmap_write(ctx->regmap, REG_VID_CHA_TEST_PATTERN, 0x00);/* Enable PLL */regmap_write(ctx->regmap, REG_RC_PLL_EN, REG_RC_PLL_EN_PLL_EN);After you turn on the PLL, I think you should be waiting for "PLL_EN_STAT" to show that the PLL is actually enabled and then delaying 3ms, right?
Yes
/* Trigger reset after CSR register update. */regmap_write(ctx->regmap, REG_RC_RESET, REG_RC_RESET_SOFT_RESET);+}
+static void sn65dsi83_disable(struct drm_bridge *bridge) +{
struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge);/* Clear reset, disable PLL */regmap_write(ctx->regmap, REG_RC_RESET, 0x00);I don't think you need this--it self-clears.
regmap_write(ctx->regmap, REG_RC_PLL_EN, 0x00);+}
+static void sn65dsi83_post_disable(struct drm_bridge *bridge) +{
struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge);/* Put the chip in reset, pull EN line low. */gpiod_set_value(ctx->enable_gpio, 0);+}
+static enum drm_mode_status +sn65dsi83_mode_valid(struct drm_bridge *bridge,
const struct drm_display_info *info,const struct drm_display_mode *mode)+{
/* LVDS output clock range 25..154 MHz */if (mode->clock < 25000)return MODE_CLOCK_LOW;if (mode->clock > 154000)return MODE_CLOCK_HIGH;return MODE_OK;+}
+static void sn65dsi83_mode_set(struct drm_bridge *bridge,
const struct drm_display_mode *mode,const struct drm_display_mode *adj)+{
struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge);ctx->mode = *mode;IIRC you should be using adj, not mode. If something earlier in the chain tweaked it then adj will be more correct.
OK
[...]
Hi,
On Thu, Feb 4, 2021 at 10:41 AM Marek Vasut marex@denx.de wrote:
+static const struct regmap_range sn65dsi83_volatile_ranges[] = {
regmap_reg_range(REG_RC_LVDS_PLL, REG_RC_LVDS_PLL),Why is REG_RC_LVDS_PLL volatile?
See register 0xa bit 7, PLL_EN_STAT .
Wow, I looked at it a few times and still didn't see it. OK, fair enough.
regmap_reg_range(REG_IRQ_STAT, REG_IRQ_STAT),Do you need to list REG_RC_RESET as volatile? Specifically you need to make sure it's not cached...
Isn't volatile table exactly for this purpose -- to make sure the reg is not cached ?
Sorry, I was unclear I guess. I'm suggesting that you add REG_RC_RESET to the list of volatile ones since I don't see it there.
+static const struct regmap_config sn65dsi83_regmap_config = {
.reg_bits = 8,.val_bits = 8,.rd_table = &sn65dsi83_readable_table,.wr_table = &sn65dsi83_writeable_table,.volatile_table = &sn65dsi83_volatile_table,.cache_type = REGCACHE_RBTREE,.max_register = REG_IRQ_STAT,+};
I'm curious how much the "readable" and "writable" sections get you. In theory only the "volatile" should really matter, right?
They are useful when dumping the regs from debugfs regmap registers .
OK, fair enough. When I thought about doing this on sn65dsi86, it came to be that a better way might be something like:
#define ACC_RO BIT(0) #define ACC_RW BIT(1) #define ACC_W1C BIT(2) #define ACC_WO BIT(3)
u8 reg_acceess[] = { [0x00] = ACC_RO, [0x01] = ACC_RO, ... [0x0a] = ACC_RO | ACC_RW, [0x0b] = ACC_RW, [0x0d] = ACC_RW ... };
The above maps really nicely to the public datasheet and is easy to validate. Then you can just look up in that array in a constant time lookup. In other words, "readable" if either RO or RW is set. "writable" if any of RW, W1C, or WO is set. Everything that's not RW is volatile (technically you could differentiate between RO things that are hardcoded and ones that aren't, but you probably don't need to).
Anyway, feel free to ignore... What you have is fine too.
+static void sn65dsi83_pre_enable(struct drm_bridge *bridge) +{
struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge);/** Reset the chip, pull EN line low for t_reset=10ms,* then high for t_en=1ms.*/gpiod_set_value(ctx->enable_gpio, 0);Why not use the "cansleep" version to give some flexibility?
Does that make a difference in non-interrupt context ?
As I understand it:
* If a client calls gpiod_set_value() then the underlying GPIO can only be one that doesn't sleep.
* If a client calls gpiod_set_value_cansleep() then the underlying GPIO can be either one that does or doesn't sleep.
* A client is only allowed to call gpiod_set_value_cansleep() if it's not in interrupt context.
You are definitely not in an interrupt context (right?), so calling the "cansleep" version has no downsides but allows board designers to hook up an enable that can sleep.
usleep_range(10000, 11000);It seems like it would be worth it to read the enable_gpio first? If it was already 0 maybe you can skip the 10 ms delay? I would imagine that most of the time the bridge would already be disabled to start?
How do you guarantee the GPIO was LO for 10 mS here? You can sample that it is LO, but you won't know how long it was LO before this code was executed.
Ah, true. I guess the best we could do would be keep track of the GPIO ourselves so that if we were the one to last turn it off we could avoid the delay.
regmap_write(ctx->regmap, REG_RC_PLL_EN, 0x00);Probably you don't need this? It's the default and in pre-enable you just reset the chip. Maybe it was needed since you don't flush the cache in pre-enable?
Have a look at the Example Script in the DSI83 datasheet, this PLL part is needed.
I think that script is written without the assumption that you have just reset the chip using the enable GPIO. If you have just reset with the enable GPIO it shouldn't be needed.
On 2/4/21 10:10 PM, Doug Anderson wrote:
Hi,
Hi,
[...]
regmap_reg_range(REG_IRQ_STAT, REG_IRQ_STAT),Do you need to list REG_RC_RESET as volatile? Specifically you need to make sure it's not cached...
Isn't volatile table exactly for this purpose -- to make sure the reg is not cached ?
Sorry, I was unclear I guess. I'm suggesting that you add REG_RC_RESET to the list of volatile ones since I don't see it there.
Ah, yes, it should.
+static const struct regmap_config sn65dsi83_regmap_config = {
.reg_bits = 8,.val_bits = 8,.rd_table = &sn65dsi83_readable_table,.wr_table = &sn65dsi83_writeable_table,.volatile_table = &sn65dsi83_volatile_table,.cache_type = REGCACHE_RBTREE,.max_register = REG_IRQ_STAT,+};
I'm curious how much the "readable" and "writable" sections get you. In theory only the "volatile" should really matter, right?
They are useful when dumping the regs from debugfs regmap registers .
OK, fair enough. When I thought about doing this on sn65dsi86, it came to be that a better way might be something like:
#define ACC_RO BIT(0) #define ACC_RW BIT(1) #define ACC_W1C BIT(2) #define ACC_WO BIT(3)
u8 reg_acceess[] = { [0x00] = ACC_RO, [0x01] = ACC_RO, ... [0x0a] = ACC_RO | ACC_RW, [0x0b] = ACC_RW, [0x0d] = ACC_RW ... };
The above maps really nicely to the public datasheet and is easy to validate. Then you can just look up in that array in a constant time lookup. In other words, "readable" if either RO or RW is set. "writable" if any of RW, W1C, or WO is set. Everything that's not RW is volatile (technically you could differentiate between RO things that are hardcoded and ones that aren't, but you probably don't need to).
Anyway, feel free to ignore... What you have is fine too.
It might make sense to implement some more generic support for this ^ into the regmap core ? This seems to be a rather common pattern.
+static void sn65dsi83_pre_enable(struct drm_bridge *bridge) +{
struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge);/** Reset the chip, pull EN line low for t_reset=10ms,* then high for t_en=1ms.*/gpiod_set_value(ctx->enable_gpio, 0);Why not use the "cansleep" version to give some flexibility?
Does that make a difference in non-interrupt context ?
As I understand it:
- If a client calls gpiod_set_value() then the underlying GPIO can
only be one that doesn't sleep.
- If a client calls gpiod_set_value_cansleep() then the underlying
GPIO can be either one that does or doesn't sleep.
- A client is only allowed to call gpiod_set_value_cansleep() if it's
not in interrupt context.
You are definitely not in an interrupt context (right?), so calling the "cansleep" version has no downsides but allows board designers to hook up an enable that can sleep.
Linus, can you please confirm this ? I find this hard to believe, since there are plenty of places in the kernel which use gpiod_set_value() without the _cansleep, are those problematic then ?
usleep_range(10000, 11000);It seems like it would be worth it to read the enable_gpio first? If it was already 0 maybe you can skip the 10 ms delay? I would imagine that most of the time the bridge would already be disabled to start?
How do you guarantee the GPIO was LO for 10 mS here? You can sample that it is LO, but you won't know how long it was LO before this code was executed.
Ah, true. I guess the best we could do would be keep track of the GPIO ourselves so that if we were the one to last turn it off we could avoid the delay.
Does the extra complexity outweigh the benefit of saving those 10mS ?
regmap_write(ctx->regmap, REG_RC_PLL_EN, 0x00);Probably you don't need this? It's the default and in pre-enable you just reset the chip. Maybe it was needed since you don't flush the cache in pre-enable?
Have a look at the Example Script in the DSI83 datasheet, this PLL part is needed.
I think that script is written without the assumption that you have just reset the chip using the enable GPIO. If you have just reset with the enable GPIO it shouldn't be needed.
I don't think it hurts anything, so let's keep it.
On Thu, Feb 4, 2021 at 11:05 PM Marek Vasut marex@denx.de wrote:
On 2/4/21 10:10 PM, Doug Anderson wrote:
/** Reset the chip, pull EN line low for t_reset=10ms,* then high for t_en=1ms.*/gpiod_set_value(ctx->enable_gpio, 0);Why not use the "cansleep" version to give some flexibility?
Does that make a difference in non-interrupt context ?
As I understand it:
- If a client calls gpiod_set_value() then the underlying GPIO can
only be one that doesn't sleep.
- If a client calls gpiod_set_value_cansleep() then the underlying
GPIO can be either one that does or doesn't sleep.
- A client is only allowed to call gpiod_set_value_cansleep() if it's
not in interrupt context.
You are definitely not in an interrupt context (right?), so calling the "cansleep" version has no downsides but allows board designers to hook up an enable that can sleep.
Linus, can you please confirm this ? I find this hard to believe, since there are plenty of places in the kernel which use gpiod_set_value() without the _cansleep, are those problematic then ?
The function looks like so:
void gpiod_set_value(struct gpio_desc *desc, int value) { VALIDATE_DESC_VOID(desc); /* Should be using gpiod_set_value_cansleep() */ WARN_ON(desc->gdev->chip->can_sleep); gpiod_set_value_nocheck(desc, value); }
So if the chip has set ->can_sleep (i,e, this GPIO is on something like an I2C bus) then a warning will appear.
The warning only really appear if you have a driver that was previously only used on a gpiochip with "fast" (write a register) GPIOs and somebody start to use the same driver with a GPIO on e.g. an I2C bus, which will define ->can_sleep.
The simple solution to the warning is to switch to the _cansleep() variant but really it is a sign to check that this is not being called in atomic context and just check that the driver overall will survive sleeping context here.
In a way _cansleep() is just syntactic sugar.
In this driver, you can use _cansleep() if you like but not using it mostly works too, if used with SoC-type GPIOs. Whoever uses the driver with a GPIO on an I2C chip or similar gets to fix it.
Yours, Linus Walleij
On 2/12/21 9:43 AM, Linus Walleij wrote:
On Thu, Feb 4, 2021 at 11:05 PM Marek Vasut marex@denx.de wrote:
On 2/4/21 10:10 PM, Doug Anderson wrote:
/** Reset the chip, pull EN line low for t_reset=10ms,* then high for t_en=1ms.*/gpiod_set_value(ctx->enable_gpio, 0);Why not use the "cansleep" version to give some flexibility?
Does that make a difference in non-interrupt context ?
As I understand it:
- If a client calls gpiod_set_value() then the underlying GPIO can
only be one that doesn't sleep.
- If a client calls gpiod_set_value_cansleep() then the underlying
GPIO can be either one that does or doesn't sleep.
- A client is only allowed to call gpiod_set_value_cansleep() if it's
not in interrupt context.
You are definitely not in an interrupt context (right?), so calling the "cansleep" version has no downsides but allows board designers to hook up an enable that can sleep.
Linus, can you please confirm this ? I find this hard to believe, since there are plenty of places in the kernel which use gpiod_set_value() without the _cansleep, are those problematic then ?
The function looks like so:
void gpiod_set_value(struct gpio_desc *desc, int value) { VALIDATE_DESC_VOID(desc); /* Should be using gpiod_set_value_cansleep() */ WARN_ON(desc->gdev->chip->can_sleep); gpiod_set_value_nocheck(desc, value); }
So if the chip has set ->can_sleep (i,e, this GPIO is on something like an I2C bus) then a warning will appear.
The warning only really appear if you have a driver that was previously only used on a gpiochip with "fast" (write a register) GPIOs and somebody start to use the same driver with a GPIO on e.g. an I2C bus, which will define ->can_sleep.
The simple solution to the warning is to switch to the _cansleep() variant but really it is a sign to check that this is not being called in atomic context and just check that the driver overall will survive sleeping context here.
In a way _cansleep() is just syntactic sugar.
In this driver, you can use _cansleep() if you like but not using it mostly works too, if used with SoC-type GPIOs. Whoever uses the driver with a GPIO on an I2C chip or similar gets to fix it.
Nice, I'm gonna archive this, this explanation is very clear, thanks.
On Sat, Jan 30, 2021 at 7:10 PM Marek Vasut marex@denx.de wrote:
Add DT binding document for TI SN65DSI83 DSI to LVDS bridge.
Signed-off-by: Marek Vasut marex@denx.de Cc: Douglas Anderson dianders@chromium.org Cc: Laurent Pinchart laurent.pinchart@ideasonboard.com Cc: Linus Walleij linus.walleij@linaro.org Cc: Sam Ravnborg sam@ravnborg.org Cc: Stephen Boyd swboyd@chromium.org Cc: devicetree@vger.kernel.org To: dri-devel@lists.freedesktop.org
This looks correct to me. Reviewed-by: Linus Walleij linus.walleij@linaro.org
Yours, Linus Walleij
Hi,
On Sat, Jan 30, 2021 at 10:10 AM Marek Vasut marex@denx.de wrote:
Add DT binding document for TI SN65DSI83 DSI to LVDS bridge.
Signed-off-by: Marek Vasut marex@denx.de Cc: Douglas Anderson dianders@chromium.org Cc: Laurent Pinchart laurent.pinchart@ideasonboard.com Cc: Linus Walleij linus.walleij@linaro.org Cc: Sam Ravnborg sam@ravnborg.org Cc: Stephen Boyd swboyd@chromium.org Cc: devicetree@vger.kernel.org To: dri-devel@lists.freedesktop.org
.../bindings/display/bridge/ti,sn65dsi83.yaml | 128 ++++++++++++++++++ 1 file changed, 128 insertions(+)
I'll preface by saying that I'm nowhere near an expert on any of this stuff. I've done a bunch of hacking on the sn65dsi86 driver but mostly I'm a DRM noob and don't have any super expertise in MIPI or LVDS.
create mode 100644 Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml
diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml new file mode 100644 index 000000000000..77e1bafd8cd8 --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml @@ -0,0 +1,128 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/bridge/ti,sn65dsi83.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml#
+title: SN65DSI83 DSI to LVDS bridge chip
+maintainers:
- Marek Vasut marex@denx.de
+description: |
- The Texas Instruments SN65DSI83 bridge takes MIPI DSI in and outputs LVDS.
- https://www.ti.com/general/docs/lit/getliterature.tsp?genericPartNumber=sn65...
+properties:
- compatible:
- const: ti,sn65dsi83
- reg:
- const: 0x2d
- enable-gpios:
- maxItems: 1
- description: GPIO specifier for bridge_en pin (active high).
I see two regulators: vcc and vcore. Shouldn't those be listed?
I also see an interrupt pin on the datasheet. Probably should be listed too even if the chip can be made to work fine without hooking it up. It can just be optional, right?
It wouldn't hurt to list the refclk here too even if the code doesn't use it. From sn65dsi86 it was handy that the bindings already had all this type of stuff so that when we added the feature we didn't have to go back to the bindings.
- ports:
- type: object
- additionalProperties: false
- properties:
"#address-cells":const: 1"#size-cells":const: 0port@0:type: objectadditionalProperties: falsedescription:Video port for MIPI DSI inputproperties:reg:const: 0endpoint:type: objectadditionalProperties: falseproperties:remote-endpoint: truedata-lanes:description: array of physical DSI data lane indexes.
The chip doesn't allow for arbitrary remapping here, right? So you're just using this as the official way to specify the number of lanes? I guess the only valid values are:
<0> <0 1> <0 1 2> <0 1 2 3>
In sn65dsi86 we attempted to enforce that a valid option was selected for the output lanes. Could you do something similar? If nothing else adding a description of the valid options would be good.
required:- regport@1:type: objectadditionalProperties: falsedescription:Video port for LVDS output (panel or bridge).properties:reg:const: 1endpoint:type: objectadditionalProperties: falseproperties:remote-endpoint: true
Worth adding the data-lanes here too? I guess this part allows you two different orders for the LVDS outputs?
required:- reg- required:
- "#address-cells"- "#size-cells"- port@0- port@1+required:
- compatible
- reg
- enable-gpios
- ports
+additionalProperties: false
+examples:
- |
- #include <dt-bindings/gpio/gpio.h>
- i2c {
#address-cells = <1>;#size-cells = <0>;bridge@2d {compatible = "ti,sn65dsi83";reg = <0x2d>;enable-gpios = <&gpio2 1 GPIO_ACTIVE_HIGH>;ports {#address-cells = <1>;#size-cells = <0>;port@0 {reg = <0>;endpoint {remote-endpoint = <&dsi0_out>;data-lanes = <1 2 3 4>;
Should the above be <0 1 2 3>?
};};port@1 {reg = <1>;endpoint {remote-endpoint = <&panel_in_lvds>;};};};};- };
-- 2.29.2
On 2/4/21 6:15 PM, Doug Anderson wrote:
Hi,
[...]
+properties:
- compatible:
- const: ti,sn65dsi83
- reg:
- const: 0x2d
- enable-gpios:
- maxItems: 1
- description: GPIO specifier for bridge_en pin (active high).
I see two regulators: vcc and vcore. Shouldn't those be listed?
Those are not implemented and not tested, so if someone needs them later on, they can be added then.
I also see an interrupt pin on the datasheet. Probably should be listed too even if the chip can be made to work fine without hooking it up. It can just be optional, right?
It is optional and again completely untested, so it can be added later if needed.
It wouldn't hurt to list the refclk here too even if the code doesn't use it. From sn65dsi86 it was handy that the bindings already had all this type of stuff so that when we added the feature we didn't have to go back to the bindings.
In my case, the refclock are derived from the DSI link.
- ports:
- type: object
- additionalProperties: false
- properties:
"#address-cells":const: 1"#size-cells":const: 0port@0:type: objectadditionalProperties: falsedescription:Video port for MIPI DSI inputproperties:reg:const: 0endpoint:type: objectadditionalProperties: falseproperties:remote-endpoint: truedata-lanes:description: array of physical DSI data lane indexes.The chip doesn't allow for arbitrary remapping here, right? So you're just using this as the official way to specify the number of lanes? I guess the only valid values are:
<0> <0 1> <0 1 2> <0 1 2 3>
Shouldn't that be <1 2 3 4> ?
In sn65dsi86 we attempted to enforce that a valid option was selected for the output lanes. Could you do something similar? If nothing else adding a description of the valid options would be good.
I saw the binding, but I was under the impressions the DSI86 can do lane reordering, isn't that the case ? Maybe I misunderstood it.
But yes, if you have a suggestion how to make a non-cryptic list of those four lane mapping options, please do share this info.
required:- regport@1:type: objectadditionalProperties: falsedescription:Video port for LVDS output (panel or bridge).properties:reg:const: 1endpoint:type: objectadditionalProperties: falseproperties:remote-endpoint: trueWorth adding the data-lanes here too? I guess this part allows you two different orders for the LVDS outputs?
I don't really want to add any properties which I cannot test and then end up with DT bindings which would become poor ABI in the future.
required:- reg- required:
- "#address-cells"- "#size-cells"- port@0- port@1+required:
- compatible
- reg
- enable-gpios
- ports
+additionalProperties: false
+examples:
- |
- #include <dt-bindings/gpio/gpio.h>
- i2c {
#address-cells = <1>;#size-cells = <0>;bridge@2d {compatible = "ti,sn65dsi83";reg = <0x2d>;enable-gpios = <&gpio2 1 GPIO_ACTIVE_HIGH>;ports {#address-cells = <1>;#size-cells = <0>;port@0 {reg = <0>;endpoint {remote-endpoint = <&dsi0_out>;data-lanes = <1 2 3 4>;Should the above be <0 1 2 3>?
Well, git grep data-lanes seems to indicate some count from 1, some from 0 .
Hi,
On Thu, Feb 4, 2021 at 10:09 AM Marek Vasut marex@denx.de wrote:
On 2/4/21 6:15 PM, Doug Anderson wrote:
Hi,
[...]
+properties:
- compatible:
- const: ti,sn65dsi83
- reg:
- const: 0x2d
- enable-gpios:
- maxItems: 1
- description: GPIO specifier for bridge_en pin (active high).
I see two regulators: vcc and vcore. Shouldn't those be listed?
Those are not implemented and not tested, so if someone needs them later on, they can be added then.
Sure. I guess it can go either way. For the regulator it'd the kind of thing that's super easy to add support for and hard to mess up.
endpoint:type: objectadditionalProperties: falseproperties:remote-endpoint: truedata-lanes:description: array of physical DSI data lane indexes.The chip doesn't allow for arbitrary remapping here, right? So you're just using this as the official way to specify the number of lanes? I guess the only valid values are:
<0> <0 1> <0 1 2> <0 1 2 3>
Shouldn't that be <1 2 3 4> ?
The data manual refers to the channels starting at 0, so if it's arbitrary that seems a better way to go?
In sn65dsi86 we attempted to enforce that a valid option was selected for the output lanes. Could you do something similar? If nothing else adding a description of the valid options would be good.
I saw the binding, but I was under the impressions the DSI86 can do lane reordering, isn't that the case ? Maybe I misunderstood it.
DSI86 can reorder the output lanes quite flexibly. It can't reorder the input lanes, though.
But yes, if you have a suggestion how to make a non-cryptic list of those four lane mapping options, please do share this info.
I doubt I can write this correctly without a whole lot of futzing / messing, but maybe something like:
data-lanes: oneOf: - items: - 0 - items: - 0 - 1 - items: - 0 - 1 - 2 - items: - 0 - 1 - 2 - 3
On 2/4/21 7:38 PM, Doug Anderson wrote:
Hi,
Hi,
[...]
+properties:
- compatible:
- const: ti,sn65dsi83
- reg:
- const: 0x2d
- enable-gpios:
- maxItems: 1
- description: GPIO specifier for bridge_en pin (active high).
I see two regulators: vcc and vcore. Shouldn't those be listed?
Those are not implemented and not tested, so if someone needs them later on, they can be added then.
Sure. I guess it can go either way. For the regulator it'd the kind of thing that's super easy to add support for and hard to mess up.
If someone can test those regulators (I might be able to, in next revision of hardware, we'll see), then this can be added.
endpoint:type: objectadditionalProperties: falseproperties:remote-endpoint: truedata-lanes:description: array of physical DSI data lane indexes.The chip doesn't allow for arbitrary remapping here, right? So you're just using this as the official way to specify the number of lanes? I guess the only valid values are:
<0> <0 1> <0 1 2> <0 1 2 3>
Shouldn't that be <1 2 3 4> ?
The data manual refers to the channels starting at 0, so if it's arbitrary that seems a better way to go?
Either way is OK, but before I change this, I would like some confirmation this enumeration really is arbitrary.
In sn65dsi86 we attempted to enforce that a valid option was selected for the output lanes. Could you do something similar? If nothing else adding a description of the valid options would be good.
I saw the binding, but I was under the impressions the DSI86 can do lane reordering, isn't that the case ? Maybe I misunderstood it.
DSI86 can reorder the output lanes quite flexibly. It can't reorder the input lanes, though.
The eDP ones ? OK
But yes, if you have a suggestion how to make a non-cryptic list of those four lane mapping options, please do share this info.
I doubt I can write this correctly without a whole lot of futzing / messing, but maybe something like:
data-lanes: oneOf: - items: - 0 - items: - 0 - 1 - items: - 0 - 1 - 2 - items: - 0 - 1 - 2 - 3
I was hoping for some better syntax. Maybe there is one ?
On Sat, Jan 30, 2021 at 07:10:13PM +0100, Marek Vasut wrote:
Add DT binding document for TI SN65DSI83 DSI to LVDS bridge.
Signed-off-by: Marek Vasut marex@denx.de Cc: Douglas Anderson dianders@chromium.org Cc: Laurent Pinchart laurent.pinchart@ideasonboard.com Cc: Linus Walleij linus.walleij@linaro.org Cc: Sam Ravnborg sam@ravnborg.org Cc: Stephen Boyd swboyd@chromium.org Cc: devicetree@vger.kernel.org To: dri-devel@lists.freedesktop.org
.../bindings/display/bridge/ti,sn65dsi83.yaml | 128 ++++++++++++++++++ 1 file changed, 128 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml
diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml new file mode 100644 index 000000000000..77e1bafd8cd8 --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml @@ -0,0 +1,128 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/bridge/ti,sn65dsi83.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml#
+title: SN65DSI83 DSI to LVDS bridge chip
+maintainers:
- Marek Vasut marex@denx.de
+description: |
- The Texas Instruments SN65DSI83 bridge takes MIPI DSI in and outputs LVDS.
- https://www.ti.com/general/docs/lit/getliterature.tsp?genericPartNumber=sn65...
+properties:
- compatible:
- const: ti,sn65dsi83
- reg:
- const: 0x2d
- enable-gpios:
- maxItems: 1
- description: GPIO specifier for bridge_en pin (active high).
- ports:
- type: object
- additionalProperties: false
- properties:
"#address-cells":const: 1"#size-cells":const: 0port@0:type: objectadditionalProperties: falsedescription:Video port for MIPI DSI inputproperties:reg:const: 0endpoint:type: objectadditionalProperties: falseproperties:remote-endpoint: truedata-lanes:description: array of physical DSI data lane indexes.
This all needs to use graph.yaml and video-interfaces.yaml. The latter is in the media tree. See examples there for what to do. It will have to wait for rc1 to apply to drm-misc.
For data-lanes, you need to specify how many lanes are valid. If there's only 1 possible setting (in the h/w, not driver), then it doesn't need to be in DT.
I agree with Doug on adding the regulators. Hard to get wrong in the binding. You or someone can add them to the driver when you can test.
required:- regport@1:type: objectadditionalProperties: falsedescription:Video port for LVDS output (panel or bridge).properties:reg:const: 1endpoint:type: objectadditionalProperties: falseproperties:remote-endpoint: truerequired:- reg- required:
- "#address-cells"- "#size-cells"- port@0- port@1+required:
- compatible
- reg
- enable-gpios
- ports
+additionalProperties: false
+examples:
- |
- #include <dt-bindings/gpio/gpio.h>
- i2c {
#address-cells = <1>;#size-cells = <0>;bridge@2d {compatible = "ti,sn65dsi83";reg = <0x2d>;enable-gpios = <&gpio2 1 GPIO_ACTIVE_HIGH>;ports {#address-cells = <1>;#size-cells = <0>;port@0 {reg = <0>;endpoint {remote-endpoint = <&dsi0_out>;data-lanes = <1 2 3 4>;};};port@1 {reg = <1>;endpoint {remote-endpoint = <&panel_in_lvds>;};};};};- };
-- 2.29.2
dri-devel@lists.freedesktop.org
-
Doug Anderson -
Linus Walleij -
Marek Vasut -
Rob Herring