Is there lcd support for imx6dl in kernel 3.17?

Is there lcd support for imx6dl in kernel 3.17?

[Stefan]

[-- Attachment #1: Type: text/plain, Size: 313 bytes --]

video/mxc/mxc_lcdif.c is not part of mainline 3.17, and video/fbdev/mxsfb.c
is
just for imx6sl and older variants like imx28
Is there really no lcd support in 3.17 or am I just blind? ;)
If there really isn't - would you suggest to try editing mxsfb.c or to
bring mxc_lcdif.c and it's dependencies to 3.17?

[-- Attachment #2: Type: text/html, Size: 372 bytes --]

Re: Is there lcd support for imx6dl in kernel 3.17?

[Fabio Estevam]

On Mon, Nov 3, 2014 at 3:01 PM, Stefan <strawberryblack@googlemail.com> wrote:
> video/mxc/mxc_lcdif.c is not part of mainline 3.17, and video/fbdev/mxsfb.c
> is
> just for imx6sl and older variants like imx28
> Is there really no lcd support in 3.17 or am I just blind? ;)
> If there really isn't - would you suggest to try editing mxsfb.c or to bring
> mxc_lcdif.c and it's dependencies to 3.17?

There is support for parallel display in 3.17:
drivers/staging/imx-drm/parallel-display.c

Search for "fsl,imx-parallel-display" properties inside
arch/arm/boot/dts and you will see several examples of boards that use
it.

Re: Is there lcd support for imx6dl in kernel 3.17?

[Stefan]

[-- Attachment #1: Type: text/plain, Size: 2488 bytes --]

I'm trying to enable seiko_wvga on wandboard, but am quite puzzled about
the correct approach doing it.

What I tried, was to add a display node (claavga from imx51-babbage.dts
with few changes),
enable ldb, and add the pincontrolgroup pinctrl_ipu1_1, which was part of
imx6qdl.dtsi in linux-imx 3.10.17

The result in dmesg looks like it wasn't possible to find a display:

imx-parallel-display display@di0: adding component (ops imx_pd_ops)
imx-ldb 2000000.aips-bus:ldb@020e0008: adding component (ops imx_ldb_ops)
imx-ipuv3-crtc imx-ipuv3-crtc.0: adding component (ops ipu_crtc_ops)
imx-ipuv3-crtc imx-ipuv3-crtc.1: adding component (ops ipu_crtc_ops)
[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[drm] No driver support for vblank timestamp query.
imx-drm display-subsystem: bound imx-ipuv3-crtc.0 (ops ipu_crtc_ops)
imx-drm display-subsystem: bound imx-ipuv3-crtc.1 (ops ipu_crtc_ops)
imx-drm display-subsystem: No connectors reported connected with modes

Is this approach somehow in the correct direction or am I missing something
substantial?

Is lcdif meant to be outdated and parallel-display is the suggested
replacement?
Also is it supposed to work without a drm driver like etnaviv?

               display1: display@di0 {
                compatible = "fsl,imx-parallel-display";
                interface-pix-fmt = "rgb565";
                pinctrl-names = "default";
                pinctrl-0 = <&pinctrl_ipu1_1>;
                status = "ok";
                display-timings {
                        native-mode = <&timing1>;
                        timing1: claawvga {
                                clock-frequency = <27000000>;
                                hactive = <800>;
...
                                pixelclk-active = <0>;
                        };
                };

                port {
                        display1_in: endpoint {
                                remote-endpoint = <&ipu1_di0_lvds0>;
                        };
                };
        };



&ldb {
       status = "okay";
};


                pinctrl_ipu1_1: ipu1grp-1 {
                        fsl,pins = <
                                MX6QDL_PAD_DI0_DISP_CLK__IPU1_DI0_DISP_CLK
0x10
                                MX6QDL_PAD_DI0_PIN15__IPU1_DI0_PIN15
0x10
...
                                MX6QDL_PAD_DISP0_DAT23__IPU1_DISP0_DATA23
0x10
                        >;
                };

[-- Attachment #2: Type: text/html, Size: 3332 bytes --]

Re: Is there lcd support for imx6dl in kernel 3.17?

[Stefan]

[-- Attachment #1: Type: text/plain, Size: 1046 bytes --]

Ok, this was less confusing than expected.

Removed the ldb node again,
replaced ipu1_di0_lvds0 with ipu1_di0_disp0
and added

&ipu1_di0_disp0 {
        remote-endpoint =<&display1_in>;
};

After changing the timing,
it has a green colour fault, yet, but let's see..

                        timing1: claawvga {
                                clock-frequency = <32000000>;
                                hactive = <800>;
                                vactive = <480>;
                                hback-porch = <89>;
                                hfront-porch = <164>;
                                vback-porch = <23>;
                                vfront-porch = <10>;
                                hsync-len = <10>;
                                vsync-len = <10>;
                                hsync-active = <0>;
                                vsync-active = <0>;
                                de-active = <1>;
                                pixelclk-active = <0>;
                        };

[-- Attachment #2: Type: text/html, Size: 1842 bytes --]

Re: Is there lcd support for imx6dl in kernel 3.17?

[Fabio Estevam]

On Wed, Nov 5, 2014 at 6:44 PM, Stefan <strawberryblack@googlemail.com> wrote:
>
> Ok, this was less confusing than expected.
>
> Removed the ldb node again,
> replaced ipu1_di0_lvds0 with ipu1_di0_disp0
> and added
>
> &ipu1_di0_disp0 {
>         remote-endpoint =<&display1_in>;
> };
>
> After changing the timing,
> it has a green colour fault, yet, but let's see..

Try using
interface-pix-fmt = "rgb24";

Re: Is there lcd support for imx6dl in kernel 3.17?

[Stefan]

[-- Attachment #1: Type: text/plain, Size: 382 bytes --]

> Try using
> interface-pix-fmt = "rgb24";
With interface-pix-fmt = "bgr666"; colors are ok,
but there is some noise on the screen - looks like twinkling pixel faults.
This is just the case for images in framebuffer, not for console text.

When changing pixel clock in ipuv3-crtc.c to something <27000000 (about
26700000),
noise gets less but doesn't completely disappear.

[-- Attachment #2: Type: text/html, Size: 531 bytes --]

Re: Is there lcd support for imx6dl in kernel 3.17?

[Stefan]

> With interface-pix-fmt = "bgr666"; colors are ok,
> but there is some noise on the screen - looks like twinkling pixel faults.
> This is just the case for images in framebuffer, not for console text.

Reason is, that pixelclk-active is not used to set value of sig_cfg.clk_pol,
so it's rising instead of falling edge.

Used the following workaround:

--- a/drivers/staging/imx-drm/ipuv3-crtc.c
+++ b/drivers/staging/imx-drm/ipuv3-crtc.c
@@ -166,7 +166,9 @@
        sig_cfg.Vsync_pol = 1;

    sig_cfg.enable_pol = 1;
-   sig_cfg.clk_pol = 0;
+   sig_cfg.clk_pol = 0; /* rising edge */
+   if (mode->private_flags & DRM_MODE_FLAG_PCSYNC) /* falling edge  */
+       sig_cfg.clk_pol = 1;
    sig_cfg.width = mode->hdisplay;
    sig_cfg.height = mode->vdisplay;
    sig_cfg.pixel_fmt = out_pixel_fmt;
diff --git a/drivers/staging/imx-drm/parallel-display.c
b/drivers/staging/imx-drm/parallel-display.c
index 4ca61af..bf7eee4 100644
--- a/drivers/staging/imx-drm/parallel-display.c
+++ b/drivers/staging/imx-drm/parallel-display.c
@@ -26,6 +26,8 @@
 #include <drm/drm_panel.h>
 #include <linux/videodev2.h>
 #include <video/of_display_timing.h>
+#include <video/videomode.h>
+#include <video/of_videomode.h>

 #include "imx-drm.h"

@@ -80,11 +82,15 @@

    if (np) {
        struct drm_display_mode *mode = drm_mode_create(connector->dev);
+       struct videomode vm;
        if (!mode)
            return -EINVAL;
        of_get_drm_display_mode(np, &imxpd->mode, OF_USE_NATIVE_MODE);
        drm_mode_copy(mode, &imxpd->mode);
        mode->type |= DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED,
+       /* imxpd->mode.flags does not contain all flags from devicetree */
+       of_get_videomode(np, &vm, OF_USE_NATIVE_MODE);
+       mode->private_flags=vm.flags;
        drm_mode_probed_add(connector, mode);
        num_modes++;
    }

Re: Is there lcd support for imx6dl in kernel 3.17?

[Fabio Estevam]

On Thu, Nov 13, 2014 at 7:01 PM, Stefan <strawberryblack@googlemail.com> wrote:
>> With interface-pix-fmt = "bgr666"; colors are ok,
>> but there is some noise on the screen - looks like twinkling pixel faults.
>> This is just the case for images in framebuffer, not for console text.
>
> Reason is, that pixelclk-active is not used to set value of sig_cfg.clk_pol,
> so it's rising instead of falling edge.
>
> Used the following workaround:
>
> --- a/drivers/staging/imx-drm/ipuv3-crtc.c
> +++ b/drivers/staging/imx-drm/ipuv3-crtc.c
> @@ -166,7 +166,9 @@
>         sig_cfg.Vsync_pol = 1;
>
>     sig_cfg.enable_pol = 1;
> -   sig_cfg.clk_pol = 0;
> +   sig_cfg.clk_pol = 0; /* rising edge */
> +   if (mode->private_flags & DRM_MODE_FLAG_PCSYNC) /* falling edge  */
> +       sig_cfg.clk_pol = 1;
>     sig_cfg.width = mode->hdisplay;
>     sig_cfg.height = mode->vdisplay;
>     sig_cfg.pixel_fmt = out_pixel_fmt;
> diff --git a/drivers/staging/imx-drm/parallel-display.c
> b/drivers/staging/imx-drm/parallel-display.c
> index 4ca61af..bf7eee4 100644
> --- a/drivers/staging/imx-drm/parallel-display.c
> +++ b/drivers/staging/imx-drm/parallel-display.c
> @@ -26,6 +26,8 @@
>  #include <drm/drm_panel.h>
>  #include <linux/videodev2.h>
>  #include <video/of_display_timing.h>
> +#include <video/videomode.h>
> +#include <video/of_videomode.h>
>
>  #include "imx-drm.h"
>
> @@ -80,11 +82,15 @@
>
>     if (np) {
>         struct drm_display_mode *mode = drm_mode_create(connector->dev);
> +       struct videomode vm;
>         if (!mode)
>             return -EINVAL;
>         of_get_drm_display_mode(np, &imxpd->mode, OF_USE_NATIVE_MODE);
>         drm_mode_copy(mode, &imxpd->mode);
>         mode->type |= DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED,
> +       /* imxpd->mode.flags does not contain all flags from devicetree */
> +       of_get_videomode(np, &vm, OF_USE_NATIVE_MODE);
> +       mode->private_flags=vm.flags;
>         drm_mode_probed_add(connector, mode);
>         num_modes++;

It would be nice if you could submit this as a formal patch to the
devel@driverdev.osuosl.org list.

Thanks

Re: Is there lcd support for imx6dl in kernel 3.17?

[Gary Thomas]

On 2014-11-13 14:10, Fabio Estevam wrote:
> On Thu, Nov 13, 2014 at 7:01 PM, Stefan <strawberryblack@googlemail.com> wrote:
>>> With interface-pix-fmt = "bgr666"; colors are ok,
>>> but there is some noise on the screen - looks like twinkling pixel faults.
>>> This is just the case for images in framebuffer, not for console text.
>>
>> Reason is, that pixelclk-active is not used to set value of sig_cfg.clk_pol,
>> so it's rising instead of falling edge.
>>
>> Used the following workaround:
>>
>> --- a/drivers/staging/imx-drm/ipuv3-crtc.c
>> +++ b/drivers/staging/imx-drm/ipuv3-crtc.c
>> @@ -166,7 +166,9 @@
>>          sig_cfg.Vsync_pol = 1;
>>
>>      sig_cfg.enable_pol = 1;
>> -   sig_cfg.clk_pol = 0;
>> +   sig_cfg.clk_pol = 0; /* rising edge */
>> +   if (mode->private_flags & DRM_MODE_FLAG_PCSYNC) /* falling edge  */
>> +       sig_cfg.clk_pol = 1;
>>      sig_cfg.width = mode->hdisplay;
>>      sig_cfg.height = mode->vdisplay;
>>      sig_cfg.pixel_fmt = out_pixel_fmt;
>> diff --git a/drivers/staging/imx-drm/parallel-display.c
>> b/drivers/staging/imx-drm/parallel-display.c
>> index 4ca61af..bf7eee4 100644
>> --- a/drivers/staging/imx-drm/parallel-display.c
>> +++ b/drivers/staging/imx-drm/parallel-display.c
>> @@ -26,6 +26,8 @@
>>   #include <drm/drm_panel.h>
>>   #include <linux/videodev2.h>
>>   #include <video/of_display_timing.h>
>> +#include <video/videomode.h>
>> +#include <video/of_videomode.h>
>>
>>   #include "imx-drm.h"
>>
>> @@ -80,11 +82,15 @@
>>
>>      if (np) {
>>          struct drm_display_mode *mode = drm_mode_create(connector->dev);
>> +       struct videomode vm;
>>          if (!mode)
>>              return -EINVAL;
>>          of_get_drm_display_mode(np, &imxpd->mode, OF_USE_NATIVE_MODE);
>>          drm_mode_copy(mode, &imxpd->mode);
>>          mode->type |= DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED,
>> +       /* imxpd->mode.flags does not contain all flags from devicetree */
>> +       of_get_videomode(np, &vm, OF_USE_NATIVE_MODE);
>> +       mode->private_flags=vm.flags;
>>          drm_mode_probed_add(connector, mode);
>>          num_modes++;
>
> It would be nice if you could submit this as a formal patch to the
> devel@driverdev.osuosl.org list.

Stefan,

Could you also send (at least to me if you don't want to CC the list)
your final device tree that works with your LCD display?

Thanks

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: Is there lcd support for imx6dl in kernel 3.17?

[Stefan]

[-- Attachment #1: Type: text/plain, Size: 320 bytes --]

> Could you also send (at least to me if you don't want to CC the list)
> your final device tree that works with your LCD display?

Attached dtsi has a few not or not completely related nodes:
- enable_lcd: For setting the gpio, that powers on lcd to 1 ;)
- fusion7: fusion touchscreen driver (same as in 3.10.17)

[-- Attachment #2: imx6qdl-wandboard-fwbadapt.dtsi --]
[-- Type: application/octet-stream, Size: 4284 bytes --]


/ {
	enable_lcd {
		compatible = "enable-gpio-lcd";
		enable-gpios=<&gpio2 11 0>;
		pinctrl-names = "default";
		pinctrl-0 = <&pinctrl_lcd_enable>;
	};

	backlight_lcd {
		compatible = "pwm-backlight";
		pwms = <&pwm1 0 5000000>;
		brightness-levels = <0 4 8 16 32 64 128 255>;
		default-brightness-level = <7>;
		pinctrl-names = "default";
		pinctrl-0 = <&pinctrl_backlight>;
		enable-gpios=<&gpio4 20 0>;
	};

	display1: display@di0 {
		compatible = "fsl,imx-parallel-display";
		interface-pix-fmt = "bgr666";
		pinctrl-names = "default";
		pinctrl-0 = <&pinctrl_ipu1_1>;
		status = "ok";
		display-timings {
			native-mode = <&timing1>;
			timing1: seikowvga {
				clock-frequency = <32000000>;
				hactive = <800>;
				vactive = <480>;
				hback-porch = <89>;
				hfront-porch = <164>;
				vback-porch = <23>;
				vfront-porch = <10>;
				hsync-len = <10>;
				vsync-len = <10>;
				hsync-active = <0>;
				vsync-active = <0>;
				de-active = <1>;
				pixelclk-active = <0>;
			};
		};

		port {
			display1_in: endpoint {
				remote-endpoint = <&ipu1_di0_disp0>;
			};
		};
	};

};

&ipu1_di0_disp0 {
	remote-endpoint =<&display1_in>;
};

&i2c2 {
	fusion7: fusion7@10 {
		compatible = "touchrev,fusion7";
		reg = <0x10>; /* The reg property describes the address of the device's resources within the address space defined by its parent bus.  */
		pinctrl-0 = <&pinctrl_gpio>;
		pinctrl-names = "default";
		interrupt-parent = <&gpio4>;
		interrupts = <5 0>;
		reset-gpios=<&gpio7 8 0>; /*pin264  SD3_RST GPIO(7, 8)   gpio200   Touchscreen Reset  Output*/
		touch_xmax=<1499>;
		touch_ymax=<899>;
		flip_x=<0>;
		flip_y=<0>;
	};

};

&iomuxc {

	imx6qdl-wandboard {

		pinctrl_ipu1_1: ipu1grp-1 {
			fsl,pins = <
				MX6QDL_PAD_DI0_DISP_CLK__IPU1_DI0_DISP_CLK 0x10
				MX6QDL_PAD_DI0_PIN15__IPU1_DI0_PIN15       0x10
				MX6QDL_PAD_DI0_PIN2__IPU1_DI0_PIN02        0x10
				MX6QDL_PAD_DI0_PIN3__IPU1_DI0_PIN03        0x10
				MX6QDL_PAD_DISP0_DAT0__IPU1_DISP0_DATA00   0x10
				MX6QDL_PAD_DISP0_DAT1__IPU1_DISP0_DATA01   0x10
				MX6QDL_PAD_DISP0_DAT2__IPU1_DISP0_DATA02   0x10
				MX6QDL_PAD_DISP0_DAT3__IPU1_DISP0_DATA03   0x10
				MX6QDL_PAD_DISP0_DAT4__IPU1_DISP0_DATA04   0x10
				MX6QDL_PAD_DISP0_DAT5__IPU1_DISP0_DATA05   0x10
				MX6QDL_PAD_DISP0_DAT6__IPU1_DISP0_DATA06   0x10
				MX6QDL_PAD_DISP0_DAT7__IPU1_DISP0_DATA07   0x10
				MX6QDL_PAD_DISP0_DAT8__IPU1_DISP0_DATA08   0x10
				MX6QDL_PAD_DISP0_DAT9__IPU1_DISP0_DATA09   0x10
				MX6QDL_PAD_DISP0_DAT10__IPU1_DISP0_DATA10  0x10
				MX6QDL_PAD_DISP0_DAT11__IPU1_DISP0_DATA11  0x10
				MX6QDL_PAD_DISP0_DAT12__IPU1_DISP0_DATA12  0x10
				MX6QDL_PAD_DISP0_DAT13__IPU1_DISP0_DATA13  0x10
				MX6QDL_PAD_DISP0_DAT14__IPU1_DISP0_DATA14  0x10
				MX6QDL_PAD_DISP0_DAT15__IPU1_DISP0_DATA15  0x10
				MX6QDL_PAD_DISP0_DAT16__IPU1_DISP0_DATA16  0x10
				MX6QDL_PAD_DISP0_DAT17__IPU1_DISP0_DATA17  0x10
				MX6QDL_PAD_DISP0_DAT18__IPU1_DISP0_DATA18  0x10
				MX6QDL_PAD_DISP0_DAT19__IPU1_DISP0_DATA19  0x10
				MX6QDL_PAD_DISP0_DAT20__IPU1_DISP0_DATA20  0x10
				MX6QDL_PAD_DISP0_DAT21__IPU1_DISP0_DATA21  0x10
				MX6QDL_PAD_DISP0_DAT22__IPU1_DISP0_DATA22  0x10
				MX6QDL_PAD_DISP0_DAT23__IPU1_DISP0_DATA23  0x10
			>;
		};

			pinctrl_backlight: backlightgrp {
				fsl,pins = <
					MX6QDL_PAD_DI0_PIN4__GPIO4_IO20 0x1b880 /*pin 116*/
				>;

		};

			pinctrl_lcd_enable: lcdenablegrp {
				fsl,pins = <
					MX6QDL_PAD_SD4_DAT3__GPIO2_IO11 0x13059 /* pin 43 - power on LCD*/
				>;

		};
	};

	gpio {
		pinctrl_gpio: gpiogrp {
			fsl,pins = <
				MX6QDL_PAD_EIM_DA12__GPIO3_IO12   0x4001b0b0 /* GPIO3_12 EDM pin 255 */
				MX6QDL_PAD_EIM_DA11__GPIO3_IO11   0x4001b0b0 /* GPIO3_11 EDM pin 256 */
				MX6QDL_PAD_EIM_DA10__GPIO3_IO10   0x4001b0b0 /* GPIO3_10 EDM pin 257 */
				MX6QDL_PAD_EIM_D27__GPIO3_IO27    0x4001b0b0 /* GPIO3_27 EDM pin 258 */
				MX6QDL_PAD_EIM_D26__GPIO3_IO26    0x4001b0b0 /* GPIO3_26 EDM pin 259 */
				MX6QDL_PAD_EIM_BCLK__GPIO6_IO31   0x4001b0b0 /* GPIO6_31 EDM pin 260 */
				MX6QDL_PAD_EIM_DA8__GPIO3_IO08    0x4001b0b0 /* GPIO3_8  EDM pin 261 */
				MX6QDL_PAD_ENET_RX_ER__GPIO1_IO24 0x4001b0b0 /* GPIO1_24 EDM pin 262 */
				MX6QDL_PAD_GPIO_19__GPIO4_IO05    0x4001b0b0 /* GPIO4_5  EDM pin 263 */
				MX6QDL_PAD_SD3_RST__GPIO7_IO08    0x4001b0b0 /* GPIO7_8  EDM pin 264 */
			>;
		};
	};
};