From: Fabio Estevam fabio.estevam@nxp.com
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 breno.lima@nxp.com Signed-off-by: Fabio Estevam fabio.estevam@nxp.com --- 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),
2017-02-02 19:26 GMT-02:00 Fabio Estevam festevam@gmail.com:
From: Fabio Estevam fabio.estevam@nxp.com
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 breno.lima@nxp.com Signed-off-by: Fabio Estevam fabio.estevam@nxp.com
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 breno.lima@nxp.com
On 02/02/2017 10:26 PM, Fabio Estevam wrote:
From: Fabio Estevam fabio.estevam@nxp.com
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 breno.lima@nxp.com Signed-off-by: Fabio Estevam fabio.estevam@nxp.com
Tested-by: Marek Vasut marex@denx.de
On Tue, Feb 07, 2017 at 10:44:59PM +0100, Marek Vasut wrote:
On 02/02/2017 10:26 PM, Fabio Estevam wrote:
From: Fabio Estevam fabio.estevam@nxp.com
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 breno.lima@nxp.com Signed-off-by: Fabio Estevam fabio.estevam@nxp.com
Tested-by: Marek Vasut marex@denx.de
You're listed as maintainer in MAINTAINERS, replying with tested-by is super confusing. Did you pick this up and will do a pull request? Do you expect someone else to pick this up? -Daniel
On 02/07/2017 11:15 PM, Daniel Vetter wrote:
On Tue, Feb 07, 2017 at 10:44:59PM +0100, Marek Vasut wrote:
On 02/02/2017 10:26 PM, Fabio Estevam wrote:
From: Fabio Estevam fabio.estevam@nxp.com
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 breno.lima@nxp.com Signed-off-by: Fabio Estevam fabio.estevam@nxp.com
Tested-by: Marek Vasut marex@denx.de
You're listed as maintainer in MAINTAINERS, replying with tested-by is super confusing. Did you pick this up and will do a pull request?
No
Do you expect someone else to pick this up?
The last patches for mxsfb were picked by you, but if you expect me to pick the mxsfb patches through my own tree and then submit PR, I can do that.
On Tue, Feb 7, 2017 at 11:31 PM, Marek Vasut marex@denx.de wrote:
On 02/07/2017 11:15 PM, Daniel Vetter wrote:
On Tue, Feb 07, 2017 at 10:44:59PM +0100, Marek Vasut wrote:
On 02/02/2017 10:26 PM, Fabio Estevam wrote:
From: Fabio Estevam fabio.estevam@nxp.com
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 breno.lima@nxp.com Signed-off-by: Fabio Estevam fabio.estevam@nxp.com
Tested-by: Marek Vasut marex@denx.de
You're listed as maintainer in MAINTAINERS, replying with tested-by is super confusing. Did you pick this up and will do a pull request?
No
Do you expect someone else to pick this up?
The last patches for mxsfb were picked by you, but if you expect me to pick the mxsfb patches through my own tree and then submit PR, I can do that.
I apply trivial patches as a welcoming gesture for new folks, but that's generally about it. Anyway, if you expect drm-misc maintainers to pick up stuff then you need to tell us, otherwise the patch will be lost. But then if you want mxsfb maintained in drm-misc I'd say better to get commit rights and join the club :-) Just ping on #dri-devel on freenode. -Daniel
On 02/08/2017 08:17 AM, Daniel Vetter wrote:
On Tue, Feb 7, 2017 at 11:31 PM, Marek Vasut marex@denx.de wrote:
On 02/07/2017 11:15 PM, Daniel Vetter wrote:
On Tue, Feb 07, 2017 at 10:44:59PM +0100, Marek Vasut wrote:
On 02/02/2017 10:26 PM, Fabio Estevam wrote:
From: Fabio Estevam fabio.estevam@nxp.com
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 breno.lima@nxp.com Signed-off-by: Fabio Estevam fabio.estevam@nxp.com
Tested-by: Marek Vasut marex@denx.de
You're listed as maintainer in MAINTAINERS, replying with tested-by is super confusing. Did you pick this up and will do a pull request?
No
Do you expect someone else to pick this up?
The last patches for mxsfb were picked by you, but if you expect me to pick the mxsfb patches through my own tree and then submit PR, I can do that.
I apply trivial patches as a welcoming gesture for new folks, but that's generally about it. Anyway, if you expect drm-misc maintainers to pick up stuff then you need to tell us, otherwise the patch will be lost. But then if you want mxsfb maintained in drm-misc I'd say better to get commit rights and join the club :-) Just ping on #dri-devel on freenode.
Ha, I see. I'll ping you on dri-devel shortly.
-Daniel
dri-devel@lists.freedesktop.org
-
Breno Matheus Lima -
Daniel Vetter -
Fabio Estevam -
Marek Vasut