RE: RFBI worked example

RE: RFBI worked example

[Ben Tucker]

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,
                           4000000,     /* HSYNS pulse 4uS */
                           1000000000,  /* 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:btucker@mpcdata.com]
Sent: 06 January 2011 15:32
To: 'linux-omap@vger.kernel.org'
Cc: 'tomi.valkeinen@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: <btucker@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.

RE: RFBI worked example

[Tomi Valkeinen]

On Fri, 2011-01-07 at 14:18 +0000, 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,
>                            4000000,     /* HSYNS pulse 4uS */
>                            1000000000,  /* 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

RE: RFBI worked example

[Ben Tucker]

> -----Original Message-----
> From: Tomi Valkeinen [mailto:tomi.valkeinen@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 +0000, 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,
> >                            4000000,     /* HSYNS pulse 4uS */
> >                            1000000000,  /* 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

OMAP DSS Enable clocks in dss_setup_partial_planes

[Ben Tucker]

>From 086e3454c8f154cd90a4669899f2179f16ef32cd Mon Sep 17 00:00:00 2001
From: Ben Tucker <btucker@mpc-data.co.uk>
Date: Thu, 13 Jan 2011 12:56:45 +0000
Subject: [PATCH] OMAP DSS Enable clocks in dss_setup_partial_planes
 Enable the interface clocks while calling
 configure_dispc().

---
 drivers/video/omap2/dss/manager.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/video/omap2/dss/manager.c
b/drivers/video/omap2/dss/manager.c
index 545e9b9..cb90dac 100644
--- a/drivers/video/omap2/dss/manager.c
+++ b/drivers/video/omap2/dss/manager.c
@@ -1106,7 +1106,9 @@ void dss_setup_partial_planes(struct omap_dss_device
*dssdev,
        mc->w = w;
        mc->h = h;

+       dss_clk_enable(DSS_CLK_ICK | DSS_CLK_FCK1);
        configure_dispc();
+       dss_clk_disable(DSS_CLK_ICK | DSS_CLK_FCK1);

        mc->do_manual_update = false;

--
1.7.3.2

Re: OMAP DSS Enable clocks in dss_setup_partial_planes

[Tomi Valkeinen]

Hi,

On Tue, 2011-01-11 at 17:41 +0000, ext Ben Tucker wrote:
> From 086e3454c8f154cd90a4669899f2179f16ef32cd Mon Sep 17 00:00:00 2001
> From: Ben Tucker <btucker@mpc-data.co.uk>
> Date: Thu, 13 Jan 2011 12:56:45 +0000
> Subject: [PATCH] OMAP DSS Enable clocks in dss_setup_partial_planes
>  Enable the interface clocks while calling
>  configure_dispc().

This description doesn't really tell anything which isn't selfevident
from the code below. Please check
http://who-t.blogspot.com/2009/12/on-commit-messages.html

But I presume this is about RFBI. If so, correct place to enable the
clocks would be in rfbi.c.

 Tomi

> ---
>  drivers/video/omap2/dss/manager.c |    2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/video/omap2/dss/manager.c
> b/drivers/video/omap2/dss/manager.c
> index 545e9b9..cb90dac 100644
> --- a/drivers/video/omap2/dss/manager.c
> +++ b/drivers/video/omap2/dss/manager.c
> @@ -1106,7 +1106,9 @@ void dss_setup_partial_planes(struct omap_dss_device
> *dssdev,
>         mc->w = w;
>         mc->h = h;
> 
> +       dss_clk_enable(DSS_CLK_ICK | DSS_CLK_FCK1);
>         configure_dispc();
> +       dss_clk_disable(DSS_CLK_ICK | DSS_CLK_FCK1);
> 
>         mc->do_manual_update = false;
> 
> --
> 1.7.3.2
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: OMAP DSS Enable clocks in dss_setup_partial_planes

[Ben Tucker]

> -----Original Message-----
> From: Tomi Valkeinen [mailto:tomi.valkeinen@nokia.com]
> Sent: 12 January 2011 09:14
> To: ext Ben Tucker
> Cc: linux-omap@vger.kernel.org
> Subject: Re: OMAP DSS Enable clocks in dss_setup_partial_planes
>
> Hi,
>
> On Tue, 2011-01-11 at 17:41 +0000, ext Ben Tucker wrote:
> > From 086e3454c8f154cd90a4669899f2179f16ef32cd Mon Sep 17 00:00:00
> 2001
> > From: Ben Tucker <btucker@mpc-data.co.uk>
> > Date: Thu, 13 Jan 2011 12:56:45 +0000
> > Subject: [PATCH] OMAP DSS Enable clocks in dss_setup_partial_planes
> >  Enable the interface clocks while calling>
> >  >  configure_dispc().
>
> This description doesn't really tell anything which isn't selfevident
> from the code below. Please check
> http://who-t.blogspot.com/2009/12/on-commit-messages.html
>
> But I presume this is about RFBI. If so, correct place to enable the
> clocks would be in rfbi.c.
>
>  Tomi
>

Apologies for the commit message. Updated patch below.

Are you sure the code to enable clocks should be placed in rfbi.c? The DSI
code (dsi.c) uses dss_setup_partial_planes() in the same way as rfbi.c and
there is no clock enable code there. Also omap_dss_mgr_apply() within
manager.c enables clocks for the configure_dispc() call.

	Ben


>From fac7afefc4f80c3045ce73bb34e24a037ed26edc Mon Sep 17 00:00:00 2001
From: Ben Tucker <btucker@mpc-data.co.uk>
Date: Sat, 15 Jan 2011 07:18:49 +0000
Subject: [PATCH] OMAP2,3: DSS2: Enable clocks in dss_setup_partial_planes

Fix a deadly bus halt when using RFBI or DSI interfaced panels
due to access to the OMAP DSS subsystem while interface and
peripheral clocks are disabled.
Resolved by enabling the clocks while calling the
configure_dispc() in dss_setup_partial_planes().
---
 drivers/video/omap2/dss/manager.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/video/omap2/dss/manager.c
b/drivers/video/omap2/dss/manager.c
index 545e9b9..cb90dac 100644
--- a/drivers/video/omap2/dss/manager.c
+++ b/drivers/video/omap2/dss/manager.c
@@ -1106,7 +1106,9 @@ void dss_setup_partial_planes(struct omap_dss_device
*dssdev,
        mc->w = w;
        mc->h = h;

+       dss_clk_enable(DSS_CLK_ICK | DSS_CLK_FCK1);
        configure_dispc();
+       dss_clk_disable(DSS_CLK_ICK | DSS_CLK_FCK1);

        mc->do_manual_update = false;

--
1.7.3.2

RE: OMAP DSS Enable clocks in dss_setup_partial_planes

[Tomi Valkeinen]

On Wed, 2011-01-12 at 11:20 +0000, ext Ben Tucker wrote:
> > -----Original Message-----
> > From: Tomi Valkeinen [mailto:tomi.valkeinen@nokia.com]
> > Sent: 12 January 2011 09:14
> > To: ext Ben Tucker
> > Cc: linux-omap@vger.kernel.org
> > Subject: Re: OMAP DSS Enable clocks in dss_setup_partial_planes
> >
> > Hi,
> >
> > On Tue, 2011-01-11 at 17:41 +0000, ext Ben Tucker wrote:
> > > From 086e3454c8f154cd90a4669899f2179f16ef32cd Mon Sep 17 00:00:00
> > 2001
> > > From: Ben Tucker <btucker@mpc-data.co.uk>
> > > Date: Thu, 13 Jan 2011 12:56:45 +0000
> > > Subject: [PATCH] OMAP DSS Enable clocks in dss_setup_partial_planes
> > >  Enable the interface clocks while calling>
> > >  >  configure_dispc().
> >
> > This description doesn't really tell anything which isn't selfevident
> > from the code below. Please check
> > http://who-t.blogspot.com/2009/12/on-commit-messages.html
> >
> > But I presume this is about RFBI. If so, correct place to enable the
> > clocks would be in rfbi.c.
> >
> >  Tomi
> >
> 
> Apologies for the commit message. Updated patch below.
> 
> Are you sure the code to enable clocks should be placed in rfbi.c? The DSI
> code (dsi.c) uses dss_setup_partial_planes() in the same way as rfbi.c and
> there is no clock enable code there. Also omap_dss_mgr_apply() within
> manager.c enables clocks for the configure_dispc() call.

Usually the user should enable the clocks, in this case rfbi.c. DSI
handles this so that the clocks are always enabled when the display is
enabled. This could be easier for RFBI also, but due to legacy reasons
RFBI currently tries to keep clocks disabled except when its actually
doing something.

As for omap_dss_mgr_apply(), that function is also a "user" in this
case. Apply is called from outside DSS driver, usually from omapfb.

If the clk_enable/disable calls would be in the lower levels, this would
mean a) greater overhead from clk_enable/disable calls and b) context
saves and restores, as the DSS HW could go into OFF mode when the clocks
are disabled.

 Tomi

RE: OMAP DSS Enable clocks in dss_setup_partial_planes

[Taneja, Archit]

Hi,

I am not sure if this is needed. All calls within configure_dispc()
ensure that clocks are enabled before a register write.

The functions which read/write to registers and don't enable/disable
clocks have names which start with a "_"(for most cases).

Regards,
Archit

linux-omap-owner@vger.kernel.org wrote:
> From 086e3454c8f154cd90a4669899f2179f16ef32cd Mon Sep 17 00:00:00
> 2001 From: Ben Tucker <btucker@mpc-data.co.uk>
> Date: Thu, 13 Jan 2011 12:56:45 +0000
> Subject: [PATCH] OMAP DSS Enable clocks in
> dss_setup_partial_planes  Enable the interface clocks while
> calling  configure_dispc().
> 
> ---
>  drivers/video/omap2/dss/manager.c |    2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/video/omap2/dss/manager.c
> b/drivers/video/omap2/dss/manager.c
> index 545e9b9..cb90dac 100644
> --- a/drivers/video/omap2/dss/manager.c
> +++ b/drivers/video/omap2/dss/manager.c
> @@ -1106,7 +1106,9 @@ void dss_setup_partial_planes(struct
>         omap_dss_device *dssdev, mc->w = w;
>         mc->h = h;
> 
> +       dss_clk_enable(DSS_CLK_ICK | DSS_CLK_FCK1);        
> configure_dispc(); +       dss_clk_disable(DSS_CLK_ICK |
> DSS_CLK_FCK1); 
> 
>         mc->do_manual_update = false;
> 
> --
> 1.7.3.2

RFBI worked example

[Ben Tucker]

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: <btucker@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.