Re: [PATCH] drm: mxsfb_crtc: Fix the framebuffer misplacement

[Breno Matheus Lima]

2017-02-02 19:26 GMT-02:00 Fabio Estevam :
>
> From: Fabio Estevam 
>
> Currently the framebuffer content is displayed with incorrect offsets
> in both the vertical and horizontal directions.
>
> The fbdev version of the driver does not show this problem. Breno Lima
> dumped the eLCDIF controller registers on both the drm and fbdev drivers
> and noticed that the VDCTRL3 register is configured incorrectly in the
> drm driver.
>
> The fbdev driver calculates the vertical and horizontal wait counts
> of the VDCTRL3 register by doing: back porch + sync length.
>
> Looking at the horizontal and vertical timing diagram from
> include/drm/drm_modes.h this value corresponds to:
>
> crtc_[hv]total - crtc_[hv]sync_start
>
> So fix the VDCTRL3 register setting accordingly so that the eLCDIF
> controller can properly show the framebuffer content in the correct
> position.
>
> Reported-by: Breno Lima 
> Signed-off-by: Fabio Estevam 
> ---
>  drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
> index e10a4ed..b56f86c 100644
> --- a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
> +++ b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
> @@ -184,8 +184,8 @@ static void mxsfb_crtc_mode_set_nofb(struct
mxsfb_drm_private *mxsfb)
>VDCTRL2_SET_HSYNC_PERIOD(m->crtc_htotal),
>mxsfb->base + LCDC_VDCTRL2);
>
> -   writel(SET_HOR_WAIT_CNT(m->crtc_hblank_end - m->crtc_hsync_end) |
> - SET_VERT_WAIT_CNT(m->crtc_vblank_end - m->crtc_vsync_end),
> +   writel(SET_HOR_WAIT_CNT(m->crtc_htotal - m->crtc_hsync_start) |
> +  SET_VERT_WAIT_CNT(m->crtc_vtotal - m->crtc_vsync_start),
>mxsfb->base + LCDC_VDCTRL3);
>
> writel(SET_DOTCLK_H_VALID_DATA_CNT(m->hdisplay),
> --
> 2.7.4
>

Tested-by: Breno Lima 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: mxsfb: Implement drm_panel handling

[Breno Matheus Lima]

Tested-by: Breno Lima <breno.l...@nxp.com>



From: Thierry Reding <thierry.red...@gmail.com>
Sent: Wednesday, February 1, 2017 3:22 PM
To: Fabio Estevam
Cc: airl...@linux.ie; ma...@denx.de; dri-devel@lists.freedesktop.org; Breno 
Matheus Lima
Subject: Re: [PATCH] drm: mxsfb: Implement drm_panel handling

On Wed, Feb 01, 2017 at 03:19:47PM -0200, Fabio Estevam wrote:
> Currently when the 'power-supply' regulator is passed via device tree
> it does not actually work since drm_panel_prepare()/drm_panel_enable()
> are never called.
>
> Quoting Thierry Reding: "It should really call drm_panel_prepare() and
> drm_panel_enable() while switching on the display pipeline and
> drm_panel_disable(), followed by drm_panel_unprepare() while switching
> off the display pipeline."
>
> So do as suggested, so that the 'power-supply' regulator can be functional.
>
> Reported-by: Breno Lima <breno.l...@nxp.com>
> Suggested-by: Thierry Reding <thierry.red...@gmail.com>
> Signed-off-by: Fabio Estevam <fabio.este...@nxp.com>
> ---
>  drivers/gpu/drm/mxsfb/mxsfb_drv.c | 4 
>  1 file changed, 4 insertions(+)

Reviewed-by: Thierry Reding <tred...@nvidia.com>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

drm: panel-simple: Problems to use Seiko 43WVF1G panel and DRM_MXS driver on the i.MX6SX SabreSD.

[Breno Matheus Lima]

Hi,

I'm trying to use the Seiko 43WVF1G panel (Datasheet link:
http://www.glyn.de/data/glyn/media/doc/43wvf1g-0.pdf) and the DRM_MXS
driver on
the i.MX6SX SabreSD. Applying the patch below removes the old
timing configuration on the dtsi and adds it to the panel-simple.c
I can get the display working, but the image is out of place. Another point
to
note is that it's necessary to set the reg_lcd_3v3 to regulator-always-on
otherwise the gpio3 27 does not get enabled.

The main two problems that I'm having at the moment are:

- Gpio3 27 is not being set by the driver, function
panel_simple_prepare(struct drm_panel *panel) is not being called.
- The image is displaced even when using the same timing values in
the datasheet.

I would like to know if I'm doing something wrong on my dtsi, or if
something
is missing on the panel-simple.c. I would appreciate any help.

Thanks!

diff --git a/arch/arm/boot/dts/imx6sx-sdb.dtsi
b/arch/arm/boot/dts/imx6sx-sdb.dtsi
index da81552..13fcce9 100644
--- a/arch/arm/boot/dts/imx6sx-sdb.dtsi
+++ b/arch/arm/boot/dts/imx6sx-sdb.dtsi
@@ -24,7 +24,7 @@
 reg = <0x8000 0x4000>;
 };

-backlight {
+backlight_display: backlight-display {
 compatible = "pwm-backlight";
 pwms = < 0 500>;
 brightness-levels = <0 4 8 16 32 64 128 255>;
@@ -104,6 +104,7 @@
 regulator-name = "lcd-3v3";
 gpio = < 27 0>;
 enable-active-high;
+regulator-always-on;
 };

 reg_peri_3v3: regulator@5 {
@@ -146,6 +147,19 @@
 mux-int-port = <2>;
 mux-ext-port = <6>;
 };
+
+panel {
+compatible = "seiko,43wvf1g", "simple-panel";
+backlight = <_display>;
+
+power-supply = <_lcd_3v3>;
+
+port {
+panel_in: endpoint {
+remote-endpoint = <_out>;
+};
+};
+};
 };

  {
@@ -215,33 +229,14 @@
  {
 pinctrl-names = "default";
 pinctrl-0 = <_lcd>;
-lcd-supply = <_lcd_3v3>;
-display = <>;
 status = "okay";

-display0: display0 {
-bits-per-pixel = <16>;
-bus-width = <24>;
-
-display-timings {
-native-mode = <>;
-timing0: timing0 {
-clock-frequency = <3350>;
-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{
+display_out: endpoint {
+remote-endpoint = <_in>;
 };
 };
+
 };

  {
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 06aaf79..8faefee 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -863,6 +863,31 @@ static const struct panel_desc hannstar_hsd070pww1 = {
 .bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
 };

+static const struct display_timing seiko_43wvf1g_timing = {
+.pixelclock = { 3350, 3350, 3350 },
+.hactive = { 800, 800, 800 },
+.hfront_porch = {  164, 164, 164 },
+.hback_porch = { 89, 89, 89 },
+.hsync_len = { 10, 10, 10 },
+.vactive = { 480, 480, 480 },
+.vfront_porch = { 10, 10, 10 },
+.vback_porch = { 23, 23, 23 },
+.vsync_len = { 10, 10, 10 },
+.flags = DISPLAY_FLAGS_DE_HIGH | DISPLAY_FLAGS_PIXDATA_NEGEDGE |
+DISPLAY_FLAGS_HSYNC_LOW | DISPLAY_FLAGS_VSYNC_LOW,
+};
+
+static const struct panel_desc seiko_43wvf1g = {
+.timings = _43wvf1g_timing,
+.num_timings = 1,
+.bpc = 8,
+.size = {
+.width = 93,
+.height = 57,
+},
+.bus_format = MEDIA_BUS_FMT_RGB888_1X24,
+};
+
 static const struct display_timing hannstar_hsd100pxn1_timing = {
 .pixelclock = { 5500, 6500, 7500 },
 .hactive = { 1024, 1024, 1024 },
@@ -1853,6 +1878,9 @@ static const struct of_device_id platform_of_match[]
= {
 .compatible = "samsung,ltn140at29-301",
 .data = _ltn140at29_301,
 }, {
+.compatible = "seiko,43wvf1g",
+.data = _43wvf1g,
+}, {
 .compatible = "sharp,lq101k1ly04",
 .data = _lq101k1ly04,
 }, {
--
2.7.4


--
Breno Matheus Lima
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: mxsfb: Fix crash when provided invalid DT bindings

[Breno Matheus Lima]

2017-01-28 15:01 GMT-02:00 Marek Vasut <ma...@denx.de>:
>
> The mxsfb driver will crash if the mxsfb DT node has a subnode,
> but the content of the subnode is not of-graph binding with an
> endpoint linking to panel. The crash was triggered by providing
> old-style panel bindings to the mxsfb driver instead of the new
> of-graph ones.
>
> The problem happens in mxsfb_create_output(), which is invoked
> from mxsfb_load(). The mxsfb_create_output() iterates over all
> mxsfb DT subnode endpoints and tries to bind a panel on each
> endpoint. If there is any problem binding the panel, that is,
> mxsfb->panel == NULL, this function will return an error code,
> otherwise success 0 is returned.
>
> If the subnodes do not specify of-graph binding with an endpoint,
> the iteration over endpoints in mxsfb_create_output() will have
> zero cycles and the function will immediatelly return 0, but the
> mxsfb->panel will remain NULL. This is propagated back into the
> mxsfb_load(), which does not detect any problem and expects that
> the mxsfb->panel is valid, thus calls mxsfb_panel_attach(). But
> since mxsfb->panel == NULL, mxsfb_panel_attach() is called with
> first argument NULL and this crashes the kernel.
>
> This patch fixes the problem by explicitly checking for valid
> mxsfb->panel at the end of the iteration in mxsfb_create_output().
>
> Signed-off-by: Marek Vasut <ma...@denx.de>
> Cc: Daniel Vetter <daniel.vet...@ffwll.ch>
> Cc: Dave Airlie <airl...@redhat.com>
> Cc: Stefan Agner <ste...@agner.ch>
> Cc: Breno Matheus Lima <brenomath...@gmail.com>

Tested-by: Breno Lima <breno.l...@nxp.com>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm: mxsfb: Kernel panic on 4.10.0-rc5

[Breno Matheus Lima]

2017-01-27 18:43 GMT-02:00 Marek Vasut <ma...@denx.de>:
>
> On 01/27/2017 09:40 PM, Marek Vasut wrote:
> > On 01/27/2017 05:04 PM, Breno Matheus Lima wrote:
> >> Hi,
> >
> > Hi,
> >
> >> I'm trying to use kernel 4.10.0-rc5 and DRM_MXS driver on a i.MX6SX
SabreSD
> >> Rev A, but it crashes during the boot, I'm also disabling the FB_MXS
driver
> >> to avoid any conflict. By using the driver FB_MXS the board boots
normally
> >> and the display is working as well.
> >
> > OK
> >
> >> I would like to know if is possible to use the DRM_MXS driver with the
> >> deprecated bindings as according to the documentation located at
> >> Documentation/devicetree/bindings/display/mxsfb.txt, or if is just
possible
> >> to
> >> use the DRM driver with the new bindings.
> >
> > No, the deprecated bindings are deprecated and DO NOT WORK with this
> > driver. Use the new of-graph stuff.
> >

Good to know

> >> Please find below the log:
> >>
> >> [1.076530] [drm] Initialized
> >> [1.086305] etnaviv gpu-subsystem: bound 180.gpu (ops gpu_ops)
> >> [1.092590] etnaviv-gpu 180.gpu: model: GC400, revision: 4645
> >> [1.098703] etnaviv-gpu 180.gpu: Need to move linear window on
> >> MC1.0, disabling TS
> >> [1.154691] [drm] Supports vblank timestamp caching Rev 2
(21.10.2013).
> >> [1.161425] [drm] No driver support for vblank timestamp query.
> >> [1.167799] OF: graph: no port node found in /soc/aips-bus@0220
> >> /spba-bus@0220/lcdif@0222
> >> [1.177132] Unable to handle kernel NULL pointer dereference at
virtual
> >> address 0004
> >
> > Try with this patch please:
> >
> > diff --git a/drivers/gpu/drm/mxsfb/mxsfb_out.c
> > b/drivers/gpu/drm/mxsfb/mxsfb_out.c
> > index fa8d17399407..b8e81422d4e2 100644
> > --- a/drivers/gpu/drm/mxsfb/mxsfb_out.c
> > +++ b/drivers/gpu/drm/mxsfb/mxsfb_out.c
> > @@ -112,6 +112,7 @@ static int mxsfb_attach_endpoint(struct drm_device
*drm,
> >
> >  int mxsfb_create_output(struct drm_device *drm)
> >  {
> > +   struct mxsfb_drm_private *mxsfb = drm->dev_private;
> > struct device_node *ep_np = NULL;
> > struct of_endpoint ep;
> > int ret;
> > @@ -127,5 +128,8 @@ int mxsfb_create_output(struct drm_device *drm)
> > }
> > }
> >
> > +   if (!mxsfb->panel)
> > +   return -EPROBE_DEFER;
> > +
> > return 0;
> >  }
> >
> Rationale behind the patch:
>
> IFF you use some odd bindings or your of-graph panel bindings are
> missing from the DT , THEN the for_each_endpoint_of_node() body
> is never executed, thus mxsfb->panel remains NULL and yet the
> function returns 0/success . mxsfb_load() therefore doesn't detect
> this failure and calls drm_panel_attach() with mxsfb->panel = NULL,
> thus the crash.
>

Thanks for the explanation, I'm going to try with this patch and figure out
how to implement it on imx6sx-sdb.dtsi.

> --
> Best regards,
> Marek Vasut

Best Regards,
Breno Matheus Lima
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

drm: mxsfb: Kernel panic on 4.10.0-rc5

[Breno Matheus Lima]

] [] (driver_register) from []
(__platform_driver_register+0x38/0x4c)
[1.547693]  r5:c0d45548 r4:e000
[1.551285] [] (__platform_driver_register) from []
(mxsfb_platform_driver_init+0x18/0x20)
[1.561298] [] (mxsfb_platform_driver_init) from []
(do_one_initcall+0x44/0x17c)
[1.570442] [] (do_one_initcall) from []
(kernel_init_freeable+0x128/0x1ec)
[1.579148]  r8:00ed r7:c0cf285c r6:c0d5f850 r5:c0e79000 r4:c0d71840
[1.585862] [] (kernel_init_freeable) from []
(kernel_init+0x10/0x11c)
[1.594134]  r10: r9: r8: r7:
r6: r5:c098078c
[1.601967]  r4:
[1.604513] [] (kernel_init) from []
(ret_from_fork+0x14/0x24)
[1.612087]  r5:c098078c r4:
[1.615672] Code: e89da800 e1a0c00d e92dd800 e24cb004 (e5903004)
[1.621859] ---[ end trace 862e67af8f858054 ]---
[1.626598] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x000b
[1.626598]
[1.635754] ---[ end Kernel panic - not syncing: Attempted to kill init!
exitcode=0x000b
[1.635754]
[1.971026] random: fast init done

Thanks

Best Regards,
--
Breno Matheus Lima
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel