Hi all,
I'm using a Freescale Sabre SD card with the quad-core i.MX6 processor. I want to use LVDS channels in "separate" mode.
I modified the uboot and the kernel in order to set video mode according to LVDS display panel’s spec.
UBOOT:
I properly changed the board file (in this case "board/freescale/mx6q_sabresd/mx6q_sabresd.c").
1) I added a new "fb_videomode" struct:
static struct fb_videomode lvds_wxga = {
"WXGA", 60, 1280, 768, 14641, 40, 40, 10, 2, 80, 10,
0,
FB_VMODE_NONINTERLACED,
FB_MODE_IS_DETAILED,
};
2) I modified "ipuv3_fb_init" function (called into "lcd_enable" routine):
ret = ipuv3_fb_init(&lvds_wxga, di, IPU_PIX_FMT_RGB666, DI_PCLK_LDB, 65000000);
3) I modified "panel_info_init":
void panel_info_init(void)
{
panel_info.vl_bpix = LCD_BPP;
panel_info.vl_col = lvds_wxga.xres;
panel_info.vl_row = lvds_wxga.yres;
panel_info.cmap = colormap;
}
KERNEL:
1) I added a video mode in struct fb_videomode in drivers/video/mxc/ldb.c according to the new LVDS display panel’s spec:
......
{
"DS-LDB-WXGA", 60, 1280, 768, 14641,
40, 40,
10, 2,
80, 10,
0,
FB_VMODE_NONINTERLACED,
FB_MODE_IS_DETAILED,},
{
.......
2) I modified struct ipuv3_fb_platform_data in arch/arm/mach-imx6/board-mx6q_sabresd.c according to new configuration:
static struct ipuv3_fb_platform_data sabresd_fb_data[] = {
{ /*fb0*/
.disp_dev = "hdmi",
.interface_pix_fmt = IPU_PIX_FMT_RGB32,
.mode_str = "1920x1080M@60",
.default_bpp = 32,
.int_clk = false,
}, {
.disp_dev = "ldb",
.interface_pix_fmt = IPU_PIX_FMT_RGB666,
.mode_str = "DS-LDB-WXGA",
.default_bpp = 16,
.int_clk = false,
}, {
.disp_dev = "ldb",
.interface_pix_fmt = IPU_PIX_FMT_RGB666,
.mode_str = "DS-LDB-WXGA",
.default_bpp = 16,
.int_clk = false,
},
};
The problem is the following: both when Linux starts or when the board has finished playing a movie (using Gstreamer) on the LVDS1 channel, latter is no longer controlled (see attached file).
Using an oscilloscope I could verify that LVDS1 channel signals (Link0-, Link0+, Link1-, Link1+ etc.) disappear.
Instead LVDS0 channel works fine.
Can anyone help me figure out the exact cause of the problem?
What are the changes required to solve that issue?
Thanks a lot,
Igor
解決済! 解決策の投稿を見る。
Hi
I observed that when using Display 1, the blanking signal is followed inmediatelly by an unblanking one.
The above was only true for Display 1. for display 2 the unblanking signal was never sent.
Inspecting the code I found that the unblanking message was only sent when using channel23 (MEM_BG_SYNC) which is used for background plane in display1.
So what I did was to enable the unblankig for the display 2 which uses channel 27 (MEM_DC_SYNC)
This is the patch and it seems to be working
diff --git a/drivers/media/video/mxc/output/mxc_vout.c b/drivers/media/video/mxc/output/mxc_vout.c
index ec789ec..c3ec188 100644
--- a/drivers/media/video/mxc/output/mxc_vout.c
+++ b/drivers/media/video/mxc/output/mxc_vout.c
@@ -1759,7 +1759,7 @@ static void release_disp_output(struct mxc_vout_output *vout)
pos.y = 0;
set_window_position(vout, &pos);
- if (get_ipu_channel(fbi) == MEM_BG_SYNC) {
+ if (get_ipu_channel(fbi) == MEM_BG_SYNC || get_ipu_channel(fbi) == MEM_DC_SYNC) {
console_lock();
fbi->fix.smem_start = vout->disp_bufs[0];
fbi->flags |= FBINFO_MISC_USEREVENT;
Hi
I observed that when using Display 1, the blanking signal is followed inmediatelly by an unblanking one.
The above was only true for Display 1. for display 2 the unblanking signal was never sent.
Inspecting the code I found that the unblanking message was only sent when using channel23 (MEM_BG_SYNC) which is used for background plane in display1.
So what I did was to enable the unblankig for the display 2 which uses channel 27 (MEM_DC_SYNC)
This is the patch and it seems to be working
diff --git a/drivers/media/video/mxc/output/mxc_vout.c b/drivers/media/video/mxc/output/mxc_vout.c
index ec789ec..c3ec188 100644
--- a/drivers/media/video/mxc/output/mxc_vout.c
+++ b/drivers/media/video/mxc/output/mxc_vout.c
@@ -1759,7 +1759,7 @@ static void release_disp_output(struct mxc_vout_output *vout)
pos.y = 0;
set_window_position(vout, &pos);
- if (get_ipu_channel(fbi) == MEM_BG_SYNC) {
+ if (get_ipu_channel(fbi) == MEM_BG_SYNC || get_ipu_channel(fbi) == MEM_DC_SYNC) {
console_lock();
fbi->fix.smem_start = vout->disp_bufs[0];
fbi->flags |= FBINFO_MISC_USEREVENT;
we are currently investigating the root cause. I will post any update in this thread and also on Gstreamer and Xorg, which is another thread reporting the same issue.
Leo
Hi Leo. Thanks a lot.
I think there could be an issue in the function called "release_disp_output" (file: /drivers/media/video/mxc/output/mxc_vout.c).
In that function, the syncs of the screen are restored (FB_BLANK_UNBLANK) only if an IPU logical channel is set to "MEM_BG_SYNC", otherwise they are disabled (FB_BLANK_POWERDOWN).
The other problem is the screen resolution of the LVDS1 display (see the vertical bar to the right in the picture).
I think this problem is due to the bootloader: latter does not initialize the LVDS1 channel.
Unfortunately, the uboot initializes only one of the two LVDS channels (in that case LVDS0).
I can not figure out how to initialize both channels.
Do you think I should contact DENX for some advice?
Igor
For the fb0, I saw you still define it as hdmi. As you don't use the hdmi, have you try to replace it by LVDS?
Hi Jimmy,
Thanks for the reply!
I use hdmi channel for the desktop of Ubuntu. I'm experimenting... :smileygrin:
Igor