• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 99 subscribers
  • Views 473 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

omap3 dss2 RFBI issues

Ioannis Gragopoulos
Intellectual 340 points
Other Parts Discussed in Thread: AM3715

Hi,

We are trying to use the RFBI in omap3. We have a custom made board with AM3715 processor and the kernel version is 3.7 from http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap.git.

We wrote a panel driver based on panel-n8x0.c and we have enabled the RFBI in kernel config. The driver didn't work in the first place. After a lot of digging in omapdss source files we finally succeeded to start the RFBI module and we show activity in the RFBI pads. The modifications we made in the rfbi.c file in order to start the module are the following:

In rfbi_config_lcd_manager function we added

struct dispc_clock_info dispc_cinfo;

mgr_config.clock_info.pck_div=dssdev->clocks.dispc.channel.pck_div;

mgr_config.clock_info.lck_div=dssdev->clocks.dispc.channel.lck_div;

dispc_cinfo.lck_div = dssdev->clocks.dispc.channel.lck_div;

dispc_cinfo.pck_div = dssdev->clocks.dispc.channel.pck_div;

dispc_mgr_set_clock_div(dssdev->output->manager->id, &dispc_cinfo);

and in rfbi_transfer_area function we added

dss_mgr_start_update(mgr);

Is the rfbi broken in omapdss framework? Can anybody confirm if this is the proper way to enable RFBI?

In order for the RFBI to operate, the panel driver must implement an update function that finally calls the rfbi_transfer_area function, which actually sends the data to the rfbi pads. As far as I have understand, this update function is called by the upper layers like the omapfb driver (auto update mode).

Does anybody knows if it is possible to operate RFBI without this update function? Can the RFBI operate continuously like the dpi (bypass mode) without software trigger? I mean that the dispc generates pixel data continuously and these data are fed in to the RFBI with pck speed. Is it related with the stall bit in the RFBI_CONTROL register? If we disable the stall bit we get a lot of vsync lost messages.

Thanks.

  • 0
    TI__Guru 65405 points

    Hi Ioannis,

    I have not information about any problems with the RFBI in omapdss framework.

    You could find useful information about your issue in the Technical reference manual chapter 7.5 Display Subsystem Basic Programming Model at the link below:

    http://www.ti.com/lit/ug/sprugn4r/sprugn4r.pdf

    BR

    Tsvetolin Shulev

  • 0
    Guru 31670 points

    Ioannis,

    I need to check the DSS registers to find the right setting for automatic refresh mode. But why do you need this? The very purpose of RFBI is to update the framebuffer whenever any blitting occurs.

  • 0 in reply to Cvetolin Shulev-XID
    Intellectual 340 points

    Hi Tsvetolin,

    thank you for your reply. I think that the rfbi is broken for the following reasons:

    The function dss_mgr_check_lcd_config in manager.c file returns error if pck_div or lck_dic have not been set correctly and in the rfbi.c these clocks are not set at all. This is the first error message when you try to enable the rfbi driver.

    The actual update of the screen is done from the rfbi_transfer_area function in the rfbi.c file. The update will not happen if the function dss_mgr_start_update is not called. The reason is that because the rfbi sets the stallbit in the RFBI_CONTROL register, the dss_write_regs returns without writing anything because of mgr_manual_update(mgr) condition (so the dipsc don't start). Te DSI driver, which I suppose has the same logic, calls the dss_mgr_start_update from the corresponding transfer_area function.

    Of course all the above is what I have understand from reading the source files since there is no detailed documentation for the DSS framework. Maybe I am completely wrong and I just don't start correctly the rfbi driver.

    Best Regards,

    Ioannis

  • 0 in reply to Renjith Thomas
    Intellectual 340 points

    Hi Renjith,

    Yes you are right. The purpose of RFBI is to update the display only when needed. My problem is who triggers this update. If you just enable the rfbi then the physical display is updated only once in the kernel boot phase. The only procedure I have found is in the omapfb driver which implements the auto update function. This function sets a workqueue with a periodic call (20Hz I think), so where is the "when needed" concept? There is no clever mechanism in this. I mean something to understand that the frame buffer contents have been changed and to trigger the update. Also in the omapdrm driver there is no support at all for manual update displays.

    Best Regards,

    Ioannis

  • 0 in reply to Ioannis Gragopoulos
    Guru 31670 points

    Ioannis,

    I'm not sure about the current implementation. If its periodically updating the buffer it is much lazier approach. I feel this has to be added to make it more efficient.