simple multi-display support. IPU configuration?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

simple multi-display support. IPU configuration?

2,428 Views
Martin1z
Contributor III

Hi,

I am simply trying to setup two separate framebuffers: one HDMI and one single channel LVDS.

HDMI and LVDS are working properly, but enabling both is not working.

Here is my fb setup:

static struct fsl_mxc_hdmi_platform_data hdmi_data = {

  .init = hdmi_init,

};

static struct fsl_mxc_hdmi_core_platform_data hdmi_core_data = {

  .ipu_id = 0,

  .disp_id = 0,

};

static struct fsl_mxc_ldb_platform_data ldb_data = {

  .ipu_id = 1,

  .disp_id = 0,

  .ext_ref = 1,

  .mode = LDB_SIN0,

  .sec_ipu_id = 0,

  .sec_disp_id = 1,

};

static struct ipuv3_fb_platform_data fb_data[] = {

  { /* fb0 */

  .disp_dev = "hdmi",

  .interface_pix_fmt = IPU_PIX_FMT_RGB24,

  .mode_str = "1280x1024M@60",

  .default_bpp = 24,

  .int_clk = false,

  },

  { /* fb1 */

  .disp_dev = "ldb",

  .interface_pix_fmt = IPU_PIX_FMT_RGB666,

  .mode_str = "LDB-WVGA",

  .default_bpp = 16,

  .int_clk = false,

  },

In the sample above the ldb driver will be loaded correctly but the ldb_disp_setup() function will never be called.

There also is no change when using boot arguments to overwrite this default configuration.

Only fb0 is running properly. So when I swap both FB definitions above LDB is working and HDMI is down.

This has worked on 3.0.15 kernel properly by on 3.0.35 kernel I did not succeed yet. Any ideas?

Labels (1)
8 Replies

1,240 Views
Martin1z
Contributor III

Ok it is getting clearer. I suppose this was in intended behaviour (to save power?!).

By unblanking the framebuffer manually later, the ldb driver is initialized correctly with my preset mode.

echo 0 > /sys/class/graphics/fb2/blank

0 Kudos
Reply

1,240 Views
daiane_angolini
NXP Employee
NXP Employee

Sorry, I got confused. Did you get it working?

Have you tried the kernel command line from your board release notes?

1,240 Views
Martin1z
Contributor III

Yes I got it working.

My first fix was setting the next_blank option to FB_BLANK_UNBLANK on all framebuffers. Later I detected that it also working with the default ldb driver when unblanking the framebuffer later.

1,240 Views
soujanyak
Contributor I

I am trying to integrate LVDS display on LVDS0, i am not able to understand how to define the following structure

what does the following values mean

static struct fsl_mxc_ldb_platform_data ldb_data = {

           .ipu_id =

           .disp_id =

           .ext_ref =

           .mode =

           .sec_ipu_id =

           .sec_disp_id =

};

0 Kudos
Reply

1,240 Views
daiane_angolini
NXP Employee
NXP Employee

In order to integrate LVDS using another "hardware connector" I think you should take care of pinmux definition and usage.

The structure will be the same

0 Kudos
Reply

1,240 Views
soujanyak
Contributor I

Hello Daiane,

       Thanks a lot for the information, in addition to above, i have the following doubts :

(a)i am trying to use a 1920X1200 LVDS , and i am using only IPU0 , DI0 LVDS0 signals will that be sufficient?

(b)i am trying to connect a DLP Projector on RGB interface with primary display on LVDS0, so in the board<platform>.c , i am initializing the DLP platform data as below:

static struct fsl_mxc_lcd_platform_data lcdif_data = {

        .ipu_id = 0,

        .disp_id = 0,

        .default_ifmt = IPU_PIX_FMT_RGB888,

};

will the above structure take care that the contents from LVDS is shown on DLP? or anything have to be handled in Android surface flinger stack?

0 Kudos
Reply

1,240 Views
daiane_angolini
NXP Employee
NXP Employee

a) I don´t know the maximum resolution for LVDS display. For video playback it would be 1080p@24hz. Do you need video playback?

only IPU0 , DI0 LVDS0 would not be enough, I think, where is clock/pixclock? Take a look on already supported LVDS and follow it as example.


b) Please, take a look on Android User Guide and look for "dual display" I really think a surface flinger would be needed.

0 Kudos
Reply

1,240 Views
Martin1z
Contributor III

I think I have found one solution but I am still wondering if I am the first person faced with this problem?!

In the IPUs probe function (mxcfb_probe()) all fb devices except the first one will be initialized with the next_blank option FB_BLANK_POWERDOWN.

/* Unblank the primary fb only by default */

if (pdev->id == 0)

mxcfbi->cur_blank = mxcfbi->next_blank = FB_BLANK_UNBLANK;

else

mxcfbi->cur_blank = mxcfbi->next_blank = FB_BLANK_POWERDOWN;

When settings this to  FB_BLANK_UNBLANK for all framebuffer, all interfaces are initialized correctly.

Or is this still a problem in my configuration?!

I am using the latest kernel source (L3.0.35_12.09.01_GA).

0 Kudos
Reply