RE: RFBI worked example
With further experimentation it appears that I can call the omap_rfbi_update() from the call back, but as the callback is in interrupt context this could be dangerous. I would love to see an example of this elsewhere. static void framedone_callback(void *data) { int r; u16 dw, dh; struct omap_dss_device *dssdev = (struct omap_dss_device *)data; /* Start the next update, triggered on the external H/VSync signals */ dssdev-driver-get_resolution(dssdev, dw, dh); r = omap_rfbi_update(dssdev, 0, 0, dw, dh, framedone_callback, dssdev); if (r 0) printk(omap_rfbi_update FAILED); } static int generic_panel_power_on(struct omap_dss_device *dssdev) { int r; u16 dw, dh; r = omapdss_rfbi_display_enable(dssdev); if (r 0) goto err0; /* Setup external HSYNC/VSYNC triggering */ r = omap_rfbi_setup_te(OMAP_DSS_RFBI_TE_MODE_2, 400, /* HSYNS pulse 4uS */ 10, /* VSYNC pulse 1ms */ 0, 0, /* H/VSYNC not inverted */ 0); if (r 0) goto err1; /* Enable external triggering */ r = omap_rfbi_enable_te(1, 0); if (r 0) goto err1; #if 0 /* At a guess I do not think we need to do the prepare_update * if we are updating the whole area */ r = omap_rfbi_prepare_update(dssdev, ???); if (r 0) goto err1; #endif /* Start the first update, triggered on the external H/VSync siganls. * The callback (FRAMEDONE interrupt context) will re-arm this * update once more. */ dssdev-driver-get_resolution(dssdev, dw, dh); r = omap_rfbi_update(dssdev, 0, 0, dw, dh, framedone_callback, dssdev); if (r 0) goto err1; if (dssdev-platform_enable) { r = dssdev-platform_enable(dssdev); if (r) goto err1; } return 0; err1: omap_rfbi_enable_te(0, 0); omapdss_dpi_display_disable(dssdev); err0: return r; } -Original Message- From: Ben Tucker [mailto:btuc...@mpcdata.com] Sent: 06 January 2011 15:32 To: 'linux-omap@vger.kernel.org' Cc: 'tomi.valkei...@nokia.com' Subject: RFBI worked example Hi, I am trying to setup an OMAP3530 based system for RFBI video output using external triggering. Looking at the omap dss2 source code (and also searching around) I cannot find any worked example of how to use the rfbi driver. I know that RFBI has worked in the past for a Nokia N800 device. Can you dig out any source code that shows how to use the RFBI driver? In particular I need to see how the omap_rfbi_prepare_update() and omap_rfbi_update() calls operate with their callback. I am thinking that I should simply call omap_rfbi_update() in a thread and wait for the completion call back after each call. I want to confirm that this is the correct way to run the driver. Thanks, Ben Ben Tucker Senior Software Engineer MPC Data Limited e-mail: btuc...@mpc-data.co.uk web: www.mpc-data.co.uk tel: +44 (0) 1225 710600 fax: +44 (0) 1225 710601 ddi: +44 (0) 1225 710660 MPC Data Limited is a company registered in England and Wales with company number 05507446 Registered Address: County Gate, County Way, Trowbridge, Wiltshire, BA14 7FJ VAT no: 850625238 The information in this email and in the attached documents is confidential and may be legally privileged. Any unauthorized review, copying, disclosure or distribution is prohibited and may be unlawful. It is intended solely for the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. When addressed to our clients any opinions or advice contained in this email is subject to the terms and conditions expressed in the governing contract. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: RFBI worked example
On Fri, 2011-01-07 at 14:18 +, ext Ben Tucker wrote: With further experimentation it appears that I can call the omap_rfbi_update() from the call back, but as the callback is in interrupt context this could be dangerous. I would love to see an example of this elsewhere. Did you get it working enough to get an image on the panel? It's been long since I've touched the rfbi code, and I honestly don't know the state of it, but basically it should work similarly as DSI command mode: The panel driver issues an update when the user space has requested it via OMAPFB_UPDATE_WINDOW. So it's not meant to be triggered automatically. If you really want to update the display automatically (which you shouldn't, as the point with panels with their own framebuffer is to update only when necessary), you can do it either directly as you do, or via workqueue or thread. I don't know right away if calling omap_rfbi_update() from interrupt context is dangerous, but it might well be so you should check if carefully. Also, remember that you may need to stop updates somehow when the panel is blanked or the driver is unloaded. static void framedone_callback(void *data) { int r; u16 dw, dh; struct omap_dss_device *dssdev = (struct omap_dss_device *)data; /* Start the next update, triggered on the external H/VSync signals */ dssdev-driver-get_resolution(dssdev, dw, dh); r = omap_rfbi_update(dssdev, 0, 0, dw, dh, framedone_callback, dssdev); if (r 0) printk(omap_rfbi_update FAILED); } static int generic_panel_power_on(struct omap_dss_device *dssdev) { int r; u16 dw, dh; r = omapdss_rfbi_display_enable(dssdev); if (r 0) goto err0; /* Setup external HSYNC/VSYNC triggering */ r = omap_rfbi_setup_te(OMAP_DSS_RFBI_TE_MODE_2, 400, /* HSYNS pulse 4uS */ 10, /* VSYNC pulse 1ms */ 0, 0, /* H/VSYNC not inverted */ 0); if (r 0) goto err1; /* Enable external triggering */ r = omap_rfbi_enable_te(1, 0); if (r 0) goto err1; #if 0 /* At a guess I do not think we need to do the prepare_update * if we are updating the whole area */ I'm not sure if it's ok not to call it every time, but you should at least call it once to be sure everything is configured properly. Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: RFBI worked example
-Original Message- From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com] Sent: 07 January 2011 15:14 To: ext Ben Tucker Cc: linux-omap@vger.kernel.org Subject: RE: RFBI worked example On Fri, 2011-01-07 at 14:18 +, ext Ben Tucker wrote: With further experimentation it appears that I can call the omap_rfbi_update() from the call back, but as the callback is in interrupt context this could be dangerous. I would love to see an example of this elsewhere. Did you get it working enough to get an image on the panel? The panel in this case is under development so (it's actually an FPGA) so we have some way to go before we have an image. It's been long since I've touched the rfbi code, and I honestly don't know the state of it, but basically it should work similarly as DSI command mode: It appears to be working. As a test I tried using internal triggering with my panel code (below). Pixel data appears to flow out of the port (the RFBI_PIXEL_CNT register is decrementing). The panel driver issues an update when the user space has requested it via OMAPFB_UPDATE_WINDOW. So it's not meant to be triggered automatically. OK, that helps my understanding. If you really want to update the display automatically (which you shouldn't, as the point with panels with their own framebuffer is to update only when necessary), you can do it either directly as you do, or via workqueue or thread. The primary reason for using RFBI in this design is to allow the RFB to control the H/VSync's and thus the delivery of pixel data. This is not the traditional RFBI design. I am concerned that a thread or workqueue may introduce an unacceptable delay between FRAMEDONE and re-arming the DSS/RFBI for the next frame. I guess it depends on the rate that the panel requests frames. I don't know right away if calling omap_rfbi_update() from interrupt context is dangerous, but it might well be so you should check if carefully. OK, thankyou. I will check. Also, remember that you may need to stop updates somehow when the panel is blanked or the driver is unloaded. I *think* this is OK because the FRAMEDONE interrupt is deregistered in omapdss_rfbi_display_disable(). static void framedone_callback(void *data) { int r; u16 dw, dh; struct omap_dss_device *dssdev = (struct omap_dss_device *)data; /* Start the next update, triggered on the external H/VSync signals */ dssdev-driver-get_resolution(dssdev, dw, dh); r = omap_rfbi_update(dssdev, 0, 0, dw, dh, framedone_callback, dssdev); if (r 0) printk(omap_rfbi_update FAILED); } static int generic_panel_power_on(struct omap_dss_device *dssdev) { int r; u16 dw, dh; r = omapdss_rfbi_display_enable(dssdev); if (r 0) goto err0; /* Setup external HSYNC/VSYNC triggering */ r = omap_rfbi_setup_te(OMAP_DSS_RFBI_TE_MODE_2, 400, /* HSYNS pulse 4uS */ 10, /* VSYNC pulse 1ms */ 0, 0, /* H/VSYNC not inverted */ 0); if (r 0) goto err1; /* Enable external triggering */ r = omap_rfbi_enable_te(1, 0); if (r 0) goto err1; #if 0 /* At a guess I do not think we need to do the prepare_update * if we are updating the whole area */ I'm not sure if it's ok not to call it every time, but you should at least call it once to be sure everything is configured properly. Thanks. I will add this call. Tomi Ben -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html