Dithering is a method of approximating a color from a mixture of other colors when the required color isn't available. It reduces color banding artifacts that can be observed when displaying gradients (e.g. grayscale gradients). This may occur when the image that needs to be displayed is 24-bit but the LCD panel is a lower bit depth and does not perform dithering on its own.
The TCON (LCD controller) found in Allwinner SoCs has hardware support for dithering on channel 0, the channel used to feed LCD panels. This series adds support for it.
Patch 1 reworks the mode set function for the CPU interface to pass the encoder object, so it can be passed to other helper functions.
Patch 2 renames the dithering related register macros to reflect the fact that dithering is only supported on channel 0.
Patch 3 adds support for dithering on all LCD panel output types.
Patch 4 adds support for Banana Pi's 7" DPI LCD panel.
Patch 5 adds a pinmux setting for RGB888 for the Allwinner A20 SoC. This change has been sent by others before.
Patch 6 provides an example for enabling the Banana Pi 7" DPI LCD panel on the Banana Pi M1+. This should not be merged. I will likely rework this into an overlay in the future.
Note that I was only able to test dithering with DPI, as I do not have other panel types. However the underlying concept and core code is the same, as are the drm objects accessed. Nevertheless I'm hoping Jonathan can test LVDS and Maxime can test MIPI DSI.
Also it seems pwm-backlight hardware is unusable at the moment. I'm not sure whether the pwm-backlight or sun4i-pwm driver is to blame. I had to manually poke the pwm registers so the LCD backlight wouldn't be completely black.
Regards ChenYu
Chen-Yu Tsai (5): drm/sun4i: tcon: Pass drm_encoder * into sun4i_tcon0_mode_set_cpu drm/sun4i: tcon: Rename Dithering related register macros drm/panel: simple: Add support for Banana Pi 7" S070WV20-CT16 panel ARM: dts: sun7i: add pinmux setting for RGB888 output for LCD0 [DO NOT MERGE] ARM: dts: sun7i: bananapi-m1-plus: Enable Bananapi 7" 800x480 RGB LCD panel
Jonathan Liu (1): drm/sun4i: tcon: Add dithering support for RGB565/RGB666 LCD panels
.../display/panel/bananapi,s070wv20-ct16.txt | 7 ++ .../boot/dts/sun7i-a20-bananapi-m1-plus.dts | 61 +++++++++++++++ arch/arm/boot/dts/sun7i-a20.dtsi | 11 +++ drivers/gpu/drm/panel/panel-simple.c | 25 ++++++ drivers/gpu/drm/sun4i/sun4i_tcon.c | 76 ++++++++++++++++--- drivers/gpu/drm/sun4i/sun4i_tcon.h | 27 ++++--- 6 files changed, 186 insertions(+), 21 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt
sun4i_tcon0_mode_set_cpu() currently accepts struct mipi_dsi_device * as its second parameter. This is derived from drm_encoder.
The DSI encoder is tied to the CPU interface mode of the TCON as a special case. In theory, if hardware were available, we could also support normal CPU interface modes. It is better to pass the generic encoder instead of the specialized mipi_dsi_device, and handle the differences inside the function.
Passing the encoder would also enable the function to pass it, or any other data structures related to it, to other functions expecting it. One such example would be dithering support that will be added in a later patch, which looks at properties tied to the connector to determine whether dithering should be enabled or not.
Signed-off-by: Chen-Yu Tsai wens@csie.org --- drivers/gpu/drm/sun4i/sun4i_tcon.c | 15 ++++++--------- 1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c index 08747fc3ee71..2bd53ef7d4b8 100644 --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c @@ -277,9 +277,12 @@ static void sun4i_tcon0_mode_set_common(struct sun4i_tcon *tcon, }
static void sun4i_tcon0_mode_set_cpu(struct sun4i_tcon *tcon, - struct mipi_dsi_device *device, + struct drm_encoder *encoder, const struct drm_display_mode *mode) { + /* TODO support normal CPU interface modes */ + struct sun6i_dsi *dsi = encoder_to_sun6i_dsi(encoder); + struct mipi_dsi_device *device = dsi->device; u8 bpp = mipi_dsi_pixel_format_to_bpp(device->format); u8 lanes = device->lanes; u32 block_space, start_delay; @@ -606,16 +609,10 @@ void sun4i_tcon_mode_set(struct sun4i_tcon *tcon, const struct drm_encoder *encoder, const struct drm_display_mode *mode) { - struct sun6i_dsi *dsi; - switch (encoder->encoder_type) { case DRM_MODE_ENCODER_DSI: - /* - * This is not really elegant, but it's the "cleaner" - * way I could think of... - */ - dsi = encoder_to_sun6i_dsi(encoder); - sun4i_tcon0_mode_set_cpu(tcon, dsi->device, mode); + /* DSI is tied to special case of CPU interface */ + sun4i_tcon0_mode_set_cpu(tcon, encoder, mode); break; case DRM_MODE_ENCODER_LVDS: sun4i_tcon0_mode_set_lvds(tcon, encoder, mode);
Dithering is only supported for TCON channel 0. Throughout the datasheet all the names associated with these register are prefixed "TCON0", instead of "TCON". The only exception is the control register "TCON_FRM_CTL_REG".
Rename the macros to reflect this.
Signed-off-by: Chen-Yu Tsai wens@csie.org --- drivers/gpu/drm/sun4i/sun4i_tcon.h | 27 +++++++++++++++------------ 1 file changed, 15 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.h b/drivers/gpu/drm/sun4i/sun4i_tcon.h index f6a071cd5a6f..3d492c8be1fc 100644 --- a/drivers/gpu/drm/sun4i/sun4i_tcon.h +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h @@ -37,18 +37,21 @@ #define SUN4I_TCON_GINT1_REG 0x8
#define SUN4I_TCON_FRM_CTL_REG 0x10 -#define SUN4I_TCON_FRM_CTL_EN BIT(31) - -#define SUN4I_TCON_FRM_SEED_PR_REG 0x14 -#define SUN4I_TCON_FRM_SEED_PG_REG 0x18 -#define SUN4I_TCON_FRM_SEED_PB_REG 0x1c -#define SUN4I_TCON_FRM_SEED_LR_REG 0x20 -#define SUN4I_TCON_FRM_SEED_LG_REG 0x24 -#define SUN4I_TCON_FRM_SEED_LB_REG 0x28 -#define SUN4I_TCON_FRM_TBL0_REG 0x2c -#define SUN4I_TCON_FRM_TBL1_REG 0x30 -#define SUN4I_TCON_FRM_TBL2_REG 0x34 -#define SUN4I_TCON_FRM_TBL3_REG 0x38 +#define SUN4I_TCON0_FRM_CTL_EN BIT(31) +#define SUN4I_TCON0_FRM_CTL_MODE_R BIT(6) +#define SUN4I_TCON0_FRM_CTL_MODE_G BIT(5) +#define SUN4I_TCON0_FRM_CTL_MODE_B BIT(4) + +#define SUN4I_TCON0_FRM_SEED_PR_REG 0x14 +#define SUN4I_TCON0_FRM_SEED_PG_REG 0x18 +#define SUN4I_TCON0_FRM_SEED_PB_REG 0x1c +#define SUN4I_TCON0_FRM_SEED_LR_REG 0x20 +#define SUN4I_TCON0_FRM_SEED_LG_REG 0x24 +#define SUN4I_TCON0_FRM_SEED_LB_REG 0x28 +#define SUN4I_TCON0_FRM_TBL0_REG 0x2c +#define SUN4I_TCON0_FRM_TBL1_REG 0x30 +#define SUN4I_TCON0_FRM_TBL2_REG 0x34 +#define SUN4I_TCON0_FRM_TBL3_REG 0x38
#define SUN4I_TCON0_CTL_REG 0x40 #define SUN4I_TCON0_CTL_TCON_ENABLE BIT(31)
From: Jonathan Liu net147@gmail.com
The hardware supports dithering on TCON channel 0 which is used for LCD panels.
Dithering is a method of approximating a color from a mixture of other colors when the required color isn't available. It reduces color banding artifacts that can be observed when displaying gradients (e.g. grayscale gradients). This may occur when the image that needs to be displayed is 24-bit but the LCD panel is a lower bit depth and does not perform dithering on its own.
Signed-off-by: Jonathan Liu net147@gmail.com [wens@csie.org: check display_info.bpc first; handle LVDS and MIPI DSI] Signed-off-by: Chen-Yu Tsai wens@csie.org ---
Hi Maxime,
The dithering parameters used here are different from the ones you used in your MIPI DSI series. You might want to check if it still works for you.
--- drivers/gpu/drm/sun4i/sun4i_tcon.c | 63 +++++++++++++++++++++++++++++- 1 file changed, 62 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c index 2bd53ef7d4b8..827518f4790e 100644 --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c @@ -12,6 +12,7 @@
#include <drm/drmP.h> #include <drm/drm_atomic_helper.h> +#include <drm/drm_connector.h> #include <drm/drm_crtc.h> #include <drm/drm_crtc_helper.h> #include <drm/drm_encoder.h> @@ -276,8 +277,59 @@ static void sun4i_tcon0_mode_set_common(struct sun4i_tcon *tcon, SUN4I_TCON0_BASIC0_Y(mode->crtc_vdisplay)); }
+static void sun4i_tcon0_mode_set_dithering(struct sun4i_tcon *tcon, + const struct drm_connector *connector) +{ + u32 bus_format = 0; + u32 val = 0; + + /* XXX Would this ever happen? */ + if (!connector) + return; + + /* + * FIXME: Undocumented bits + * + * The whole dithering process and these parameters are not + * explained in the vendor documents or BSP kernel code. + */ + regmap_write(tcon->regs, SUN4I_TCON0_FRM_SEED_PR_REG, 0x11111111); + regmap_write(tcon->regs, SUN4I_TCON0_FRM_SEED_PG_REG, 0x11111111); + regmap_write(tcon->regs, SUN4I_TCON0_FRM_SEED_PB_REG, 0x11111111); + regmap_write(tcon->regs, SUN4I_TCON0_FRM_SEED_LR_REG, 0x11111111); + regmap_write(tcon->regs, SUN4I_TCON0_FRM_SEED_LG_REG, 0x11111111); + regmap_write(tcon->regs, SUN4I_TCON0_FRM_SEED_LB_REG, 0x11111111); + regmap_write(tcon->regs, SUN4I_TCON0_FRM_TBL0_REG, 0x01010000); + regmap_write(tcon->regs, SUN4I_TCON0_FRM_TBL1_REG, 0x15151111); + regmap_write(tcon->regs, SUN4I_TCON0_FRM_TBL2_REG, 0x57575555); + regmap_write(tcon->regs, SUN4I_TCON0_FRM_TBL3_REG, 0x7f7f7777); + + /* Do dithering if panel only supports 6 bits per color */ + if (connector->display_info.bpc == 6) + val |= SUN4I_TCON0_FRM_CTL_EN; + + if (connector->display_info.num_bus_formats == 1) + bus_format = connector->display_info.bus_formats[0]; + + /* Check the connection format */ + switch (bus_format) { + case MEDIA_BUS_FMT_RGB565_1X16: + /* R and B components are only 5 bits deep */ + val |= SUN4I_TCON0_FRM_CTL_MODE_R; + val |= SUN4I_TCON0_FRM_CTL_MODE_B; + case MEDIA_BUS_FMT_RGB666_1X18: + case MEDIA_BUS_FMT_RGB666_1X7X3_SPWG: + /* Fall through: enable dithering */ + val |= SUN4I_TCON0_FRM_CTL_EN; + break; + } + + /* Write dithering settings */ + regmap_write(tcon->regs, SUN4I_TCON_FRM_CTL_REG, val); +} + static void sun4i_tcon0_mode_set_cpu(struct sun4i_tcon *tcon, - struct drm_encoder *encoder, + const struct drm_encoder *encoder, const struct drm_display_mode *mode) { /* TODO support normal CPU interface modes */ @@ -293,6 +345,9 @@ static void sun4i_tcon0_mode_set_cpu(struct sun4i_tcon *tcon,
sun4i_tcon0_mode_set_common(tcon, mode);
+ /* Set dithering if needed */ + sun4i_tcon0_mode_set_dithering(tcon, sun4i_tcon_get_connector(encoder)); + regmap_update_bits(tcon->regs, SUN4I_TCON0_CTL_REG, SUN4I_TCON0_CTL_IF_MASK, SUN4I_TCON0_CTL_IF_8080); @@ -358,6 +413,9 @@ static void sun4i_tcon0_mode_set_lvds(struct sun4i_tcon *tcon, tcon->dclk_max_div = 7; sun4i_tcon0_mode_set_common(tcon, mode);
+ /* Set dithering if needed */ + sun4i_tcon0_mode_set_dithering(tcon, sun4i_tcon_get_connector(encoder)); + /* Adjust clock delay */ clk_delay = sun4i_tcon_get_clk_delay(mode, 0); regmap_update_bits(tcon->regs, SUN4I_TCON0_CTL_REG, @@ -434,6 +492,9 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon *tcon, tcon->dclk_max_div = 127; sun4i_tcon0_mode_set_common(tcon, mode);
+ /* Set dithering if needed */ + sun4i_tcon0_mode_set_dithering(tcon, tcon->panel->connector); + /* Adjust clock delay */ clk_delay = sun4i_tcon_get_clk_delay(mode, 0); regmap_update_bits(tcon->regs, SUN4I_TCON0_CTL_REG,
Hi,
On Thu, Apr 19, 2018 at 05:32:22PM +0800, Chen-Yu Tsai wrote:
From: Jonathan Liu net147@gmail.com
The hardware supports dithering on TCON channel 0 which is used for LCD panels.
Dithering is a method of approximating a color from a mixture of other colors when the required color isn't available. It reduces color banding artifacts that can be observed when displaying gradients (e.g. grayscale gradients). This may occur when the image that needs to be displayed is 24-bit but the LCD panel is a lower bit depth and does not perform dithering on its own.
Signed-off-by: Jonathan Liu net147@gmail.com [wens@csie.org: check display_info.bpc first; handle LVDS and MIPI DSI] Signed-off-by: Chen-Yu Tsai wens@csie.org
Hi Maxime,
The dithering parameters used here are different from the ones you used in your MIPI DSI series. You might want to check if it still works for you.
drivers/gpu/drm/sun4i/sun4i_tcon.c | 63 +++++++++++++++++++++++++++++- 1 file changed, 62 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c index 2bd53ef7d4b8..827518f4790e 100644 --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c @@ -12,6 +12,7 @@
#include <drm/drmP.h> #include <drm/drm_atomic_helper.h> +#include <drm/drm_connector.h> #include <drm/drm_crtc.h> #include <drm/drm_crtc_helper.h> #include <drm/drm_encoder.h> @@ -276,8 +277,59 @@ static void sun4i_tcon0_mode_set_common(struct sun4i_tcon *tcon, SUN4I_TCON0_BASIC0_Y(mode->crtc_vdisplay)); }
+static void sun4i_tcon0_mode_set_dithering(struct sun4i_tcon *tcon,
const struct drm_connector *connector)
+{
- u32 bus_format = 0;
- u32 val = 0;
- /* XXX Would this ever happen? */
- if (!connector)
return;
- /*
* FIXME: Undocumented bits
*
* The whole dithering process and these parameters are not
* explained in the vendor documents or BSP kernel code.
*/
- regmap_write(tcon->regs, SUN4I_TCON0_FRM_SEED_PR_REG, 0x11111111);
- regmap_write(tcon->regs, SUN4I_TCON0_FRM_SEED_PG_REG, 0x11111111);
- regmap_write(tcon->regs, SUN4I_TCON0_FRM_SEED_PB_REG, 0x11111111);
- regmap_write(tcon->regs, SUN4I_TCON0_FRM_SEED_LR_REG, 0x11111111);
- regmap_write(tcon->regs, SUN4I_TCON0_FRM_SEED_LG_REG, 0x11111111);
- regmap_write(tcon->regs, SUN4I_TCON0_FRM_SEED_LB_REG, 0x11111111);
- regmap_write(tcon->regs, SUN4I_TCON0_FRM_TBL0_REG, 0x01010000);
- regmap_write(tcon->regs, SUN4I_TCON0_FRM_TBL1_REG, 0x15151111);
- regmap_write(tcon->regs, SUN4I_TCON0_FRM_TBL2_REG, 0x57575555);
- regmap_write(tcon->regs, SUN4I_TCON0_FRM_TBL3_REG, 0x7f7f7777);
- /* Do dithering if panel only supports 6 bits per color */
- if (connector->display_info.bpc == 6)
val |= SUN4I_TCON0_FRM_CTL_EN;
- if (connector->display_info.num_bus_formats == 1)
bus_format = connector->display_info.bus_formats[0];
- /* Check the connection format */
- switch (bus_format) {
- case MEDIA_BUS_FMT_RGB565_1X16:
/* R and B components are only 5 bits deep */
val |= SUN4I_TCON0_FRM_CTL_MODE_R;
val |= SUN4I_TCON0_FRM_CTL_MODE_B;
- case MEDIA_BUS_FMT_RGB666_1X18:
- case MEDIA_BUS_FMT_RGB666_1X7X3_SPWG:
/* Fall through: enable dithering */
val |= SUN4I_TCON0_FRM_CTL_EN;
break;
- }
- /* Write dithering settings */
- regmap_write(tcon->regs, SUN4I_TCON_FRM_CTL_REG, val);
+}
static void sun4i_tcon0_mode_set_cpu(struct sun4i_tcon *tcon,
struct drm_encoder *encoder,
const struct drm_encoder *encoder,
The whole serie looks good, but that should probbaly be part of the first patch?
Maxime
This panel is marketed as Banana Pi 7" LCD display. On the back is a sticker denoting the model name S070WV20-CT16.
This is a 7" 800x480 panel connected through a 24-bit RGB interface. However the panel only does 262k colors.
Signed-off-by: Chen-Yu Tsai wens@csie.org --- .../display/panel/bananapi,s070wv20-ct16.txt | 7 ++++++ drivers/gpu/drm/panel/panel-simple.c | 25 +++++++++++++++++++ 2 files changed, 32 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt
diff --git a/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt b/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt new file mode 100644 index 000000000000..2ec35ce36e9a --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt @@ -0,0 +1,7 @@ +Banana Pi 7" (S070WV20-CT16) TFT LCD Panel + +Required properties: +- compatible: should be "bananapi,s070wv20-ct16" + +This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c index cbf1ab404ee7..9bc037f74d6c 100644 --- a/drivers/gpu/drm/panel/panel-simple.c +++ b/drivers/gpu/drm/panel/panel-simple.c @@ -745,6 +745,28 @@ static const struct panel_desc avic_tm070ddh03 = { }, };
+static const struct drm_display_mode bananapi_s070wv20_ct16_mode = { + .clock = 30000, + .hdisplay = 800, + .hsync_start = 800 + 40, + .hsync_end = 800 + 40 + 48, + .htotal = 800 + 40 + 48 + 40, + .vdisplay = 480, + .vsync_start = 480 + 13, + .vsync_end = 480 + 13 + 3, + .vtotal = 480 + 13 + 3 + 29, +}; + +static const struct panel_desc bananapi_s070wv20_ct16 = { + .modes = &bananapi_s070wv20_ct16_mode, + .num_modes = 1, + .bpc = 6, + .size = { + .width = 154, + .height = 86, + }, +}; + static const struct drm_display_mode boe_nv101wxmn51_modes[] = { { .clock = 71900, @@ -2112,6 +2134,9 @@ static const struct of_device_id platform_of_match[] = { }, { .compatible = "avic,tm070ddh03", .data = &avic_tm070ddh03, + }, { + .compatible = "bananapi,s070wv20-ct16", + .data = &bananapi_s070wv20_ct16, }, { .compatible = "boe,nv101wxmn51", .data = &boe_nv101wxmn51,
Hi,
Il 19/04/2018 11:32, Chen-Yu Tsai ha scritto:
This panel is marketed as Banana Pi 7" LCD display. On the back is a sticker denoting the model name S070WV20-CT16.
Judging from the code, the real vendor should be CDTech. Take a look at their website: http://www.cdtech-lcd.com/en/standardscreen.html
I point you my patch for inserting another similar panel: https://patchwork.freedesktop.org/patch/211914/
Maybe it would make sense to use CDTech as the vendor, because maybe Bananapi resells only it. Or maybe it is a custom panel done for them, but the same is for other panels I've submitted patches. Micronova srl custom, but vendor is CDTech.
What do you think?
On Thu, Apr 19, 2018 at 8:31 PM, Giulio Benetti giulio.benetti@micronovasrl.com wrote:
Hi,
Il 19/04/2018 11:32, Chen-Yu Tsai ha scritto:
This panel is marketed as Banana Pi 7" LCD display. On the back is a sticker denoting the model name S070WV20-CT16.
Judging from the code, the real vendor should be CDTech. Take a look at their website: http://www.cdtech-lcd.com/en/standardscreen.html
I point you my patch for inserting another similar panel: https://patchwork.freedesktop.org/patch/211914/
Maybe it would make sense to use CDTech as the vendor, because maybe Bananapi resells only it. Or maybe it is a custom panel done for them, but the same is for other panels I've submitted patches. Micronova srl custom, but vendor is CDTech.
What do you think?
That might be true. But for people without access to the vendors, this is horribly hard to figure out. People are only going to look at whatever marking there is on the LCD panel, and whatever the seller says. This panel has the model number stickered on, but the PCB attached to it only has the Banana Pi logo.
And given it's a custom piece, probably OEM or ODM, the real manufacturer matters less. You don't mention "Foxconn" as the vendor of the iPhone, do you?
ChenYu
-- Giulio Benetti CTO
MICRONOVA SRL Sede: Via A. Niedda 3 - 35010 Vigonza (PD) Tel. 049/8931563 - Fax 049/8931346 Cod.Fiscale - P.IVA 02663420285 Capitale Sociale € 26.000 i.v. Iscritta al Reg. Imprese di Padova N. 02663420285 Numero R.E.A. 258642
This is a 7" 800x480 panel connected through a 24-bit RGB interface. However the panel only does 262k colors.
Signed-off-by: Chen-Yu Tsai wens@csie.org
.../display/panel/bananapi,s070wv20-ct16.txt | 7 ++++++ drivers/gpu/drm/panel/panel-simple.c | 25 +++++++++++++++++++ 2 files changed, 32 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt
diff --git a/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt b/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt new file mode 100644 index 000000000000..2ec35ce36e9a --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt @@ -0,0 +1,7 @@ +Banana Pi 7" (S070WV20-CT16) TFT LCD Panel
+Required properties: +- compatible: should be "bananapi,s070wv20-ct16"
+This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c index cbf1ab404ee7..9bc037f74d6c 100644 --- a/drivers/gpu/drm/panel/panel-simple.c +++ b/drivers/gpu/drm/panel/panel-simple.c @@ -745,6 +745,28 @@ static const struct panel_desc avic_tm070ddh03 = { }, }; +static const struct drm_display_mode bananapi_s070wv20_ct16_mode = {
.clock = 30000,
.hdisplay = 800,
.hsync_start = 800 + 40,
.hsync_end = 800 + 40 + 48,
.htotal = 800 + 40 + 48 + 40,
.vdisplay = 480,
.vsync_start = 480 + 13,
.vsync_end = 480 + 13 + 3,
.vtotal = 480 + 13 + 3 + 29,
+};
+static const struct panel_desc bananapi_s070wv20_ct16 = {
.modes = &bananapi_s070wv20_ct16_mode,
.num_modes = 1,
.bpc = 6,
.size = {
.width = 154,
.height = 86,
},
+};
- static const struct drm_display_mode boe_nv101wxmn51_modes[] = { { .clock = 71900,
@@ -2112,6 +2134,9 @@ static const struct of_device_id platform_of_match[] = { }, { .compatible = "avic,tm070ddh03", .data = &avic_tm070ddh03,
}, {
.compatible = "bananapi,s070wv20-ct16",
.data = &bananapi_s070wv20_ct16, }, { .compatible = "boe,nv101wxmn51", .data = &boe_nv101wxmn51,
Hi,
Il 19/04/2018 14:45, Chen-Yu Tsai ha scritto:
On Thu, Apr 19, 2018 at 8:31 PM, Giulio Benetti giulio.benetti@micronovasrl.com wrote:
Hi,
Il 19/04/2018 11:32, Chen-Yu Tsai ha scritto:
This panel is marketed as Banana Pi 7" LCD display. On the back is a sticker denoting the model name S070WV20-CT16.
Judging from the code, the real vendor should be CDTech. Take a look at their website: http://www.cdtech-lcd.com/en/standardscreen.html
I point you my patch for inserting another similar panel: https://patchwork.freedesktop.org/patch/211914/
Maybe it would make sense to use CDTech as the vendor, because maybe Bananapi resells only it. Or maybe it is a custom panel done for them, but the same is for other panels I've submitted patches. Micronova srl custom, but vendor is CDTech.
What do you think?
That might be true. But for people without access to the vendors, this is horribly hard to figure out. People are only going to look at whatever marking there is on the LCD panel, and whatever the seller says. This panel has the model number stickered on, but the PCB attached to it only has the Banana Pi logo.
Ah ok, my fault, I didn't see it has a PCB attached with Banana Pi logo. Also it makes a lot of sense what you say about people looking for display.
And given it's a custom piece, probably OEM or ODM, the real manufacturer matters less. You don't mention "Foxconn" as the vendor of the iPhone, do you?
:) that's right.
Best regards
On Thu, Apr 19, 2018 at 05:32:23PM +0800, Chen-Yu Tsai wrote:
This panel is marketed as Banana Pi 7" LCD display. On the back is a sticker denoting the model name S070WV20-CT16.
This is a 7" 800x480 panel connected through a 24-bit RGB interface. However the panel only does 262k colors.
Signed-off-by: Chen-Yu Tsai wens@csie.org
.../display/panel/bananapi,s070wv20-ct16.txt | 7 ++++++ drivers/gpu/drm/panel/panel-simple.c | 25 +++++++++++++++++++ 2 files changed, 32 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt
diff --git a/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt b/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt new file mode 100644 index 000000000000..2ec35ce36e9a --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt @@ -0,0 +1,7 @@ +Banana Pi 7" (S070WV20-CT16) TFT LCD Panel
+Required properties: +- compatible: should be "bananapi,s070wv20-ct16"
+This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory.
Does this panel have a power supply (or more than 1) or backlight? I can't know that by just refering to simple-panel.txt.
On Thu, Apr 19, 2018 at 3:02 PM, Chen-Yu Tsai wens@csie.org wrote:
This panel is marketed as Banana Pi 7" LCD display. On the back is a sticker denoting the model name S070WV20-CT16.
This is a 7" 800x480 panel connected through a 24-bit RGB interface. However the panel only does 262k colors.
Signed-off-by: Chen-Yu Tsai wens@csie.org
.../display/panel/bananapi,s070wv20-ct16.txt | 7 ++++++ drivers/gpu/drm/panel/panel-simple.c | 25 +++++++++++++++++++ 2 files changed, 32 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt
diff --git a/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt b/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt new file mode 100644 index 000000000000..2ec35ce36e9a --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt @@ -0,0 +1,7 @@ +Banana Pi 7" (S070WV20-CT16) TFT LCD Panel
+Required properties: +- compatible: should be "bananapi,s070wv20-ct16"
+This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c index cbf1ab404ee7..9bc037f74d6c 100644 --- a/drivers/gpu/drm/panel/panel-simple.c +++ b/drivers/gpu/drm/panel/panel-simple.c @@ -745,6 +745,28 @@ static const struct panel_desc avic_tm070ddh03 = { }, };
+static const struct drm_display_mode bananapi_s070wv20_ct16_mode = {
.clock = 30000,
.hdisplay = 800,
.hsync_start = 800 + 40,
.hsync_end = 800 + 40 + 48,
.htotal = 800 + 40 + 48 + 40,
.vdisplay = 480,
.vsync_start = 480 + 13,
.vsync_end = 480 + 13 + 3,
.vtotal = 480 + 13 + 3 + 29,
+};
+static const struct panel_desc bananapi_s070wv20_ct16 = {
.modes = &bananapi_s070wv20_ct16_mode,
.num_modes = 1,
.bpc = 6,
.size = {
.width = 154,
.height = 86,
},
+};
I think this parallel RGB interface right? I too have same display with DSI I'm sure these setting will not useful right? do we need to write separate panel driver for that?
On Mon, May 14, 2018 at 11:03 AM, Jagan Teki jagan@amarulasolutions.com wrote:
On Thu, Apr 19, 2018 at 3:02 PM, Chen-Yu Tsai wens@csie.org wrote:
This panel is marketed as Banana Pi 7" LCD display. On the back is a sticker denoting the model name S070WV20-CT16.
This is a 7" 800x480 panel connected through a 24-bit RGB interface. However the panel only does 262k colors.
Signed-off-by: Chen-Yu Tsai wens@csie.org
.../display/panel/bananapi,s070wv20-ct16.txt | 7 ++++++ drivers/gpu/drm/panel/panel-simple.c | 25 +++++++++++++++++++ 2 files changed, 32 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt
diff --git a/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt b/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt new file mode 100644 index 000000000000..2ec35ce36e9a --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt @@ -0,0 +1,7 @@ +Banana Pi 7" (S070WV20-CT16) TFT LCD Panel
+Required properties: +- compatible: should be "bananapi,s070wv20-ct16"
+This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c index cbf1ab404ee7..9bc037f74d6c 100644 --- a/drivers/gpu/drm/panel/panel-simple.c +++ b/drivers/gpu/drm/panel/panel-simple.c @@ -745,6 +745,28 @@ static const struct panel_desc avic_tm070ddh03 = { }, };
+static const struct drm_display_mode bananapi_s070wv20_ct16_mode = {
.clock = 30000,
.hdisplay = 800,
.hsync_start = 800 + 40,
.hsync_end = 800 + 40 + 48,
.htotal = 800 + 40 + 48 + 40,
.vdisplay = 480,
.vsync_start = 480 + 13,
.vsync_end = 480 + 13 + 3,
.vtotal = 480 + 13 + 3 + 29,
+};
+static const struct panel_desc bananapi_s070wv20_ct16 = {
.modes = &bananapi_s070wv20_ct16_mode,
.num_modes = 1,
.bpc = 6,
.size = {
.width = 154,
.height = 86,
},
+};
I think this parallel RGB interface right? I too have same display with DSI I'm sure these setting will not useful right? do we need to write separate panel driver for that?
AFAIK the DSI model is an RGB panel with a MIPI DSI bridge on the connector board. The model I have is dual interface.
ChenYu
On Wed, May 16, 2018 at 12:12 PM, Chen-Yu Tsai wens@csie.org wrote:
On Mon, May 14, 2018 at 11:03 AM, Jagan Teki jagan@amarulasolutions.com wrote:
On Thu, Apr 19, 2018 at 3:02 PM, Chen-Yu Tsai wens@csie.org wrote:
This panel is marketed as Banana Pi 7" LCD display. On the back is a sticker denoting the model name S070WV20-CT16.
This is a 7" 800x480 panel connected through a 24-bit RGB interface. However the panel only does 262k colors.
Signed-off-by: Chen-Yu Tsai wens@csie.org
.../display/panel/bananapi,s070wv20-ct16.txt | 7 ++++++ drivers/gpu/drm/panel/panel-simple.c | 25 +++++++++++++++++++ 2 files changed, 32 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt
diff --git a/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt b/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt new file mode 100644 index 000000000000..2ec35ce36e9a --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt @@ -0,0 +1,7 @@ +Banana Pi 7" (S070WV20-CT16) TFT LCD Panel
+Required properties: +- compatible: should be "bananapi,s070wv20-ct16"
+This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c index cbf1ab404ee7..9bc037f74d6c 100644 --- a/drivers/gpu/drm/panel/panel-simple.c +++ b/drivers/gpu/drm/panel/panel-simple.c @@ -745,6 +745,28 @@ static const struct panel_desc avic_tm070ddh03 = { }, };
+static const struct drm_display_mode bananapi_s070wv20_ct16_mode = {
.clock = 30000,
.hdisplay = 800,
.hsync_start = 800 + 40,
.hsync_end = 800 + 40 + 48,
.htotal = 800 + 40 + 48 + 40,
.vdisplay = 480,
.vsync_start = 480 + 13,
.vsync_end = 480 + 13 + 3,
.vtotal = 480 + 13 + 3 + 29,
+};
+static const struct panel_desc bananapi_s070wv20_ct16 = {
.modes = &bananapi_s070wv20_ct16_mode,
.num_modes = 1,
.bpc = 6,
.size = {
.width = 154,
.height = 86,
},
+};
I think this parallel RGB interface right? I too have same display with DSI I'm sure these setting will not useful right? do we need to write separate panel driver for that?
AFAIK the DSI model is an RGB panel with a MIPI DSI bridge on the connector board. The model I have is dual interface.
Yes, this is what I have [1] where same strip can use for both RGB and MIPI DSI. can bananapi,s070wv20-ct16 work for DSI interface as well?
[1] https://www.aliexpress.com/item/New-Arrival-Banana-Pro-Pi-7-inch-LCD-Display...
Jagan.
On Wed, May 16, 2018 at 12:20 AM, Jagan Teki jagan@amarulasolutions.com wrote:
On Wed, May 16, 2018 at 12:12 PM, Chen-Yu Tsai wens@csie.org wrote:
On Mon, May 14, 2018 at 11:03 AM, Jagan Teki jagan@amarulasolutions.com wrote:
On Thu, Apr 19, 2018 at 3:02 PM, Chen-Yu Tsai wens@csie.org wrote:
This panel is marketed as Banana Pi 7" LCD display. On the back is a sticker denoting the model name S070WV20-CT16.
This is a 7" 800x480 panel connected through a 24-bit RGB interface. However the panel only does 262k colors.
Signed-off-by: Chen-Yu Tsai wens@csie.org
.../display/panel/bananapi,s070wv20-ct16.txt | 7 ++++++ drivers/gpu/drm/panel/panel-simple.c | 25 +++++++++++++++++++ 2 files changed, 32 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt
diff --git a/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt b/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt new file mode 100644 index 000000000000..2ec35ce36e9a --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt @@ -0,0 +1,7 @@ +Banana Pi 7" (S070WV20-CT16) TFT LCD Panel
+Required properties: +- compatible: should be "bananapi,s070wv20-ct16"
+This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c index cbf1ab404ee7..9bc037f74d6c 100644 --- a/drivers/gpu/drm/panel/panel-simple.c +++ b/drivers/gpu/drm/panel/panel-simple.c @@ -745,6 +745,28 @@ static const struct panel_desc avic_tm070ddh03 = { }, };
+static const struct drm_display_mode bananapi_s070wv20_ct16_mode = {
.clock = 30000,
.hdisplay = 800,
.hsync_start = 800 + 40,
.hsync_end = 800 + 40 + 48,
.htotal = 800 + 40 + 48 + 40,
.vdisplay = 480,
.vsync_start = 480 + 13,
.vsync_end = 480 + 13 + 3,
.vtotal = 480 + 13 + 3 + 29,
+};
+static const struct panel_desc bananapi_s070wv20_ct16 = {
.modes = &bananapi_s070wv20_ct16_mode,
.num_modes = 1,
.bpc = 6,
.size = {
.width = 154,
.height = 86,
},
+};
I think this parallel RGB interface right? I too have same display with DSI I'm sure these setting will not useful right? do we need to write separate panel driver for that?
AFAIK the DSI model is an RGB panel with a MIPI DSI bridge on the connector board. The model I have is dual interface.
Yes, this is what I have [1] where same strip can use for both RGB and MIPI DSI. can bananapi,s070wv20-ct16 work for DSI interface as well?
In theory yes. You can use RGB with Banana Pi M1+ and DSI with Banana Pi M3. However, DSI on A83T is not supported yet, and I don't intend to spend my time writing a driver for the MIPI DSI bridge on that panel. The bridge IC is the one on top of the DSI FPC connector.
ChenYu
[1] https://www.aliexpress.com/item/New-Arrival-Banana-Pro-Pi-7-inch-LCD-Display...
Jagan.
On the A20, as well as many other Allwinner SoCs, the PD pingroup has the LCD0 RGB output functions.
Add a pinmux setting for RGB888 output from LCD0, so boards and tablets with parallel RGB LCD panels may reference it.
Signed-off-by: Chen-Yu Tsai wens@csie.org --- arch/arm/boot/dts/sun7i-a20.dtsi | 11 +++++++++++ 1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi index e529e4ff2174..e06c14649d22 100644 --- a/arch/arm/boot/dts/sun7i-a20.dtsi +++ b/arch/arm/boot/dts/sun7i-a20.dtsi @@ -920,6 +920,17 @@ pins = "PI20", "PI21"; function = "uart7"; }; + + lcd0_rgb888_pins: lcd0-rgb888-pins { + pins = "PD0", "PD1", "PD2", "PD3", "PD4", + "PD5", "PD6", "PD7", "PD8", "PD9", + "PD10", "PD11", "PD12", "PD13", + "PD14", "PD15", "PD16", "PD17", + "PD18", "PD19", "PD20", "PD21", + "PD22", "PD23", "PD24", "PD25", + "PD26", "PD27"; + function = "lcd0"; + }; };
timer@1c20c00 {
The BPI-M1+ has an FPC connector for connecting an RGB (parallel) or LVDS LCD panel. One of the compatible panels is a 7" 800x480 RGB panel from Bananapi. The backlight can be controlled by driving a PWM signal from the SoC at different duty cycles. The LCD enable pin does not seem to do anything, but it is nevertheless included for completeness. There is also a FT5306 capacitive touchscreen controller.
This should not be confused with the other 7" LCD that is LVDS based and has a resolution of 1024x600.
This patch enables all of the above for the BPI-M1+.
Signed-off-by: Chen-Yu Tsai wens@csie.org --- .../boot/dts/sun7i-a20-bananapi-m1-plus.dts | 61 +++++++++++++++++++ 1 file changed, 61 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts b/arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts index 763cb03033c4..58a923bfa6ef 100644 --- a/arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts +++ b/arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts @@ -47,6 +47,7 @@ #include "sunxi-common-regulators.dtsi" #include <dt-bindings/gpio/gpio.h> #include <dt-bindings/interrupt-controller/arm-gic.h> +#include <dt-bindings/pwm/pwm.h>
/ { model = "Banana Pi BPI-M1-Plus"; @@ -71,6 +72,34 @@ }; };
+ lcd_backlight: lcd-backlight { + compatible = "pwm-backlight"; + pwms = <&pwm 0 20000 PWM_POLARITY_INVERTED>; /* 50 kHz */ + enable-gpios = <&pio 7 9 GPIO_ACTIVE_HIGH>; /* PH9 */ + brightness-levels = <0 10 20 30 40 50 60 70 80 90 100>; + default-brightness-level = <8>; + }; + + lcd_panel: lcd-panel { + compatible = "bananapi,s070wv20-ct16", "simple-panel"; + /* This doesn't do anything for this particular panel */ + enable-gpios = <&pio 7 12 GPIO_ACTIVE_HIGH>; /* PH12 */ + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + backlight = <&lcd_backlight>; + #address-cells = <1>; + #size-cells = <0>; + + lcd_panel_input: endpoint@0 { + reg = <0>; + remote-endpoint = <&tcon0_out_lcd>; + }; + }; + }; + leds { compatible = "gpio-leds"; pinctrl-names = "default"; @@ -173,6 +202,20 @@ status = "okay"; };
+&i2c3 { + pinctrl-names = "default"; + pinctrl-0 = <&i2c3_pins_a>; + status = "okay"; + + touchscreen@38 { + compatible = "edt,edt-ft5306", "edt,edt-ft5x06"; + reg = <0x38>; + interrupt-parent = <&pio>; + interrupts = <7 7 IRQ_TYPE_EDGE_FALLING>; /* PH7 */ + reset-gpios = <&pio 7 8 GPIO_ACTIVE_LOW>; /* PH8 */ + }; +}; + &ir0 { pinctrl-names = "default"; pinctrl-0 = <&ir0_rx_pins_a>; @@ -249,6 +292,12 @@ }; };
+&pwm { + pinctrl-names = "default"; + pinctrl-0 = <&pwm0_pins_a>; + status = "okay"; +}; + ®_dcdc2 { regulator-always-on; regulator-min-microvolt = <1000000>; @@ -278,6 +327,18 @@ status = "okay"; };
+&tcon0 { + pinctrl-names = "default"; + pinctrl-0 = <&lcd0_rgb888_pins>; +}; + +&tcon0_out { + tcon0_out_lcd: endpoint@0 { + reg = <0>; + remote-endpoint = <&lcd_panel_input>; + }; +}; + &uart0 { pinctrl-names = "default"; pinctrl-0 = <&uart0_pins_a>;
On Thu, Apr 19, 2018 at 3:02 PM, Chen-Yu Tsai wens@csie.org wrote:
Dithering is a method of approximating a color from a mixture of other colors when the required color isn't available. It reduces color banding artifacts that can be observed when displaying gradients (e.g. grayscale gradients). This may occur when the image that needs to be displayed is 24-bit but the LCD panel is a lower bit depth and does not perform dithering on its own.
The TCON (LCD controller) found in Allwinner SoCs has hardware support for dithering on channel 0, the channel used to feed LCD panels. This series adds support for it.
Patch 1 reworks the mode set function for the CPU interface to pass the encoder object, so it can be passed to other helper functions.
Patch 2 renames the dithering related register macros to reflect the fact that dithering is only supported on channel 0.
Patch 3 adds support for dithering on all LCD panel output types.
Patch 4 adds support for Banana Pi's 7" DPI LCD panel.
Patch 5 adds a pinmux setting for RGB888 for the Allwinner A20 SoC. This change has been sent by others before.
Patch 6 provides an example for enabling the Banana Pi 7" DPI LCD panel on the Banana Pi M1+. This should not be merged. I will likely rework this into an overlay in the future.
Note that I was only able to test dithering with DPI, as I do not have other panel types. However the underlying concept and core code is the same, as are the drm objects accessed. Nevertheless I'm hoping Jonathan can test LVDS and Maxime can test MIPI DSI.
Also it seems pwm-backlight hardware is unusable at the moment. I'm not sure whether the pwm-backlight or sun4i-pwm driver is to blame. I had to manually poke the pwm registers so the LCD backlight wouldn't be completely black.
Regards ChenYu
Chen-Yu Tsai (5): drm/sun4i: tcon: Pass drm_encoder * into sun4i_tcon0_mode_set_cpu drm/sun4i: tcon: Rename Dithering related register macros drm/panel: simple: Add support for Banana Pi 7" S070WV20-CT16 panel ARM: dts: sun7i: add pinmux setting for RGB888 output for LCD0 [DO NOT MERGE] ARM: dts: sun7i: bananapi-m1-plus: Enable Bananapi 7" 800x480 RGB LCD panel
Jonathan Liu (1): drm/sun4i: tcon: Add dithering support for RGB565/RGB666 LCD panels
Do you have any working branch to test this, I can't see drm probing on linux-next, I even enabled de on dts which is missing.
Jagan.
dri-devel@lists.freedesktop.org