Skip to contentSkip to conversation

DSS: OMAP3530 vs DM3730

DISCUSSION Gary Thomas 3 participants 5 messages Jan 21, 2012 – Jan 25, 2012

lore
Share & tools
lore
#0 lore raw

I'm running the public 3.0 kernel on my boards. I have some boards which can have either OMAP3530 or DM3730 (newer boards have the newer part, but everything else is the same).

On the OMAP3530, I can enable the graphics overlay on the TV (S-Video) output via the attached script. On the DM3730 boards, this crashes the kernel hard :-(

This same operation seems to be fixed on the 3.2 (public) kernel, but it's difficult for me to upgrade to that kernel for some other reasons.

Does anyone have an idea why this might happen? where to look to isolate the bug(s)?

I tried to back-port the 3.2 DSS code into my 3.0 kernel, but my simple attempt was pretty much a failure... If I can, I'd like to figure out how to just fix the 3.0 code, rather than the full-scale import of the 3.2 code.

Thanks for any ideas/pointers

Signature · 4 lines
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

#! /bin/sh

#
# This script will put the TV (S-Video) into graphics mode,

# mapped onto /dev/fb2
#

ovl0=/sys/devices/platform/omapdss/overlay0
ovl1=/sys/devices/platform/omapdss/overlay1
ovl2=/sys/devices/platform/omapdss/overlay2

mgr0=/sys/devices/platform/omapdss/manager0
mgr1=/sys/devices/platform/omapdss/manager1

lcd=/sys/devices/platform/omapdss/display0
tv=/sys/devices/platform/omapdss/display1

fb0=/sys/class/graphics/fb0
fb1=/sys/class/graphics/fb1
fb2=/sys/class/graphics/fb2

#MODE=${MODE:-ntsc}
MODE=${MODE:-pal}
echo "0" > $tv/enabled
echo ${MODE} >$tv/timings

w=`cat $tv/timings | cut -d "," -f 2 | cut -d "/" -f 1`
h=`cat $tv/timings | cut -d "," -f 3 | cut -d "/" -f 1`

echo "... Setting ${MODE} mode, Width = ${w}, Height = ${h}"

echo "0" > $ovl2/enabled
echo "2" > $fb2/overlays

echo "$w,$h" > $ovl2/output_size
echo "tv" > $ovl2/manager

mem=$((w*h*4))
echo $mem > $fb2/size

echo "1" > $ovl2/enabled
echo "1" > $tv/enabled

fbset -fb /dev/fb2 -nonstd 1

#1 lore raw

RE: OMAP3530 vs DM3730

Quoted 8 lines · Gary Thomas

I'm running the public 3.0 kernel on my boards. I have some boards which can have either OMAP3530 or DM3730 (newer boards have the newer part, but everything else is the same).

On the OMAP3530, I can enable the graphics overlay on the TV (S-Video) output via the attached script. On the DM3730 boards, this crashes the kernel hard :-(

Can you share the kernel crash log here?

Thanks,
Vaibhav

Quoted 19 lines

This same operation seems to be fixed on the 3.2 (public) kernel, but it's difficult for me to upgrade to that kernel for some other reasons.

Does anyone have an idea why this might happen? where to look to isolate the bug(s)?

I tried to back-port the 3.2 DSS code into my 3.0 kernel, but my simple attempt was pretty much a failure... If I can, I'd like to figure out how to just fix the 3.0 code, rather than the full-scale import of the 3.2 code.

Thanks for any ideas/pointers

Signature · 4 lines
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------
#2 lore raw

Re: OMAP3530 vs DM3730

Quoted 10 lines · Vaibhav
Quoted 8 lines · Gary Thomas

I'm running the public 3.0 kernel on my boards. I have some boards which can have either OMAP3530 or DM3730 (newer boards have the newer part, but everything else is the same).

On the OMAP3530, I can enable the graphics overlay on the TV (S-Video) output via the attached script. On the DM3730 boards, this crashes the kernel hard :-(

Can you share the kernel crash log here?

Sadly, no, as it just locks up tight. At this point, I can only reset manually. I've tried sifting through the dmesg log (_log_buf) in U-Boot, but I don't see any tell-tale trace of why it crashes.

Further investigation shows that it's not really a problem between 3530 and 3730, sorry. I thought I had a 3530 system where it worked, but trying it again today, it also fails. It seems to always fail when I enable fb2 as an overlay using the TV as the manager.

I know this worked as far back as 2.6.28 and it works again in 3.2. I've isolated where the kernel fails to the function dispc_pclk_rate(). This function is quite different in 3.2 than 3.0, so I back-stitched it like this:

unsigned long dispc_pclk_rate(enum omap_channel channel)

{
        unsigned long r;

        if (dispc_mgr_is_lcd(channel)) {
                int pcd;
                u32 l;

                l = dispc_read_reg(DISPC_DIVISORo(channel));
                pcd = FLD_GET(l, 7, 0);
                r = dispc_lclk_rate(channel);

                return r / pcd;
        } else {
                unsigned long venc_get_pixel_clock(void);
                return venc_get_pixel_clock();
        }
}

The kernel no longer crashes hard, but now I get these error messages printed when I enable the overlay:
omapdss DISPC error: GFX_FIFO_UNDERFLOW, disabling GFX omapdss DISPC error: GO bit not down for channel 1 omapdss DISPC error: VID2_FIFO_UNDERFLOW, disabling VID2 omapdss DISPC error: SYNC_LOST_DIGIT, disabling TV

Is there any hope of getting this operation to work in 3.0?

Quoted 12 lines
Quoted 12 lines

This same operation seems to be fixed on the 3.2 (public) kernel, but it's difficult for me to upgrade to that kernel for some other reasons.

Does anyone have an idea why this might happen? where to look to isolate the bug(s)?

I tried to back-port the 3.2 DSS code into my 3.0 kernel, but my simple attempt was pretty much a failure... If I can, I'd like to figure out how to just fix the 3.0 code, rather than the full-scale import of the 3.2 code.

Thanks for any ideas/pointers

Signature · 4 lines
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------
#3 lore raw

Re: OMAP3530 vs DM3730

Quoted 36 lines · Gary Thomas
Quoted 10 lines · Vaibhav
Quoted 8 lines · Gary Thomas

I'm running the public 3.0 kernel on my boards. I have some boards which can have either OMAP3530 or DM3730 (newer boards have the newer part, but everything else is the same).

On the OMAP3530, I can enable the graphics overlay on the TV (S-Video) output via the attached script. On the DM3730 boards, this crashes the kernel hard :-(

Can you share the kernel crash log here?

Sadly, no, as it just locks up tight. At this point, I can only reset manually. I've tried sifting through the dmesg log (_log_buf) in U-Boot, but I don't see any tell-tale trace of why it crashes.

Further investigation shows that it's not really a problem between 3530 and 3730, sorry. I thought I had a 3530 system where it worked, but trying it again today, it also fails. It seems to always fail when I enable fb2 as an overlay using the TV as the manager.

I know this worked as far back as 2.6.28 and it works again in 3.2. I've isolated where the kernel fails to the function dispc_pclk_rate(). This function is quite different in 3.2 than 3.0, so I back-stitched it like this:

unsigned long dispc_pclk_rate(enum omap_channel channel)

{
         unsigned long r;

         if (dispc_mgr_is_lcd(channel)) {
                 int pcd;
                 u32 l;

                 l = dispc_read_reg(DISPC_DIVISORo(channel));
                 pcd = FLD_GET(l, 7, 0);
Quoted 8 lines
                 r = dispc_lclk_rate(channel);

                 return r / pcd;
         } else {
                 unsigned long venc_get_pixel_clock(void);
                 return venc_get_pixel_clock();
         }
}

I think this commit fixes the crash:
c3dc6a7afb47735b82a4c0061e814454a649dbfc

Your changes above seems to be ok for omap3.

Quoted 6 lines

The kernel no longer crashes hard, but now I get these error messages printed when I enable the overlay:
omapdss DISPC error: GFX_FIFO_UNDERFLOW, disabling GFX omapdss DISPC error: GO bit not down for channel 1 omapdss DISPC error: VID2_FIFO_UNDERFLOW, disabling VID2 omapdss DISPC error: SYNC_LOST_DIGIT, disabling TV

So does everything work if you use the LCD? And the problems only appear when you enable the tv-output?

You could try a bit more step-by-step approach in your script. First enable GFX overlay on the LCD, and resize it so that it fits to both LCD and TV. See that it works ok. Then enable the TV-out. Then move the GFX overlay to the TV. etc.

Also, if you have your test setup working on newer kernel, and it doesn't work on older, you could get dumps of the dss registers and compare those. (debugfs/omapdss/dispc and venc).

Hmm. Actually, your script is missing something: it doesn't set the input_size, i.e. the framebuffer size for fb2. You should set it before enabling the overlay (fbset -xres $w -vxres $w -yres $h -vyres $h).

I haven't tested tv-out for a while, but I could give it a try on BeagleBoard. Although I don't have an s-video cable, but I guess it's enough if I don't see the underflows =).

Tomi

#4 lore raw

Re: OMAP3530 vs DM3730

Quoted 70 lines · Tomi Valkeinen
Quoted 36 lines · Gary Thomas
Quoted 10 lines · Vaibhav
Quoted 8 lines · Gary Thomas

I'm running the public 3.0 kernel on my boards. I have some boards which can have either OMAP3530 or DM3730 (newer boards have the newer part, but everything else is the same).

On the OMAP3530, I can enable the graphics overlay on the TV (S-Video) output via the attached script. On the DM3730 boards, this crashes the kernel hard :-(

Can you share the kernel crash log here?

Sadly, no, as it just locks up tight. At this point, I can only reset manually. I've tried sifting through the dmesg log (_log_buf) in U-Boot, but I don't see any tell-tale trace of why it crashes.

Further investigation shows that it's not really a problem between 3530 and 3730, sorry. I thought I had a 3530 system where it worked, but trying it again today, it also fails. It seems to always fail when I enable fb2 as an overlay using the TV as the manager.

I know this worked as far back as 2.6.28 and it works again in 3.2. I've isolated where the kernel fails to the function dispc_pclk_rate(). This function is quite different in 3.2 than 3.0, so I back-stitched it like this:

unsigned long dispc_pclk_rate(enum omap_channel channel)

{
          unsigned long r;

          if (dispc_mgr_is_lcd(channel)) {
                  int pcd;
                  u32 l;

                  l = dispc_read_reg(DISPC_DIVISORo(channel));
                  pcd = FLD_GET(l, 7, 0);
Quoted 8 lines
                  r = dispc_lclk_rate(channel);

                  return r / pcd;
          } else {
                  unsigned long venc_get_pixel_clock(void);
                  return venc_get_pixel_clock();
          }
}

I think this commit fixes the crash:
c3dc6a7afb47735b82a4c0061e814454a649dbfc

Your changes above seems to be ok for omap3.

Quoted 6 lines

The kernel no longer crashes hard, but now I get these error messages printed when I enable the overlay:
omapdss DISPC error: GFX_FIFO_UNDERFLOW, disabling GFX omapdss DISPC error: GO bit not down for channel 1 omapdss DISPC error: VID2_FIFO_UNDERFLOW, disabling VID2 omapdss DISPC error: SYNC_LOST_DIGIT, disabling TV

So does everything work if you use the LCD? And the problems only appear when you enable the tv-output?

You could try a bit more step-by-step approach in your script. First enable GFX overlay on the LCD, and resize it so that it fits to both LCD and TV. See that it works ok. Then enable the TV-out. Then move the GFX overlay to the TV. etc.

Also, if you have your test setup working on newer kernel, and it doesn't work on older, you could get dumps of the dss registers and compare those. (debugfs/omapdss/dispc and venc).

Quoted 7 lines

Hmm. Actually, your script is missing something: it doesn't set the input_size, i.e. the framebuffer size for fb2. You should set it before enabling the overlay (fbset -xres $w -vxres $w -yres $h -vyres $h).

I haven't tested tv-out for a while, but I could give it a try on BeagleBoard. Although I don't have an s-video cable, but I guess it's enough if I don't see the underflows =).

Thanks, I played around with this a bit and found an error in the script I was running. I have some systems which have only TV, so their kernels only expose one display(*). My other systems have both LCD and TV. I was trying the [TV only] script on a system with both which led to the underflow errors. When I use the right script on the right machine, it's working fine.

Sorry for the noise

(*) The choice to expose only valid displays was done to minimize the possible confusion for our [less sophisticated] users.

Signature · 4 lines
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------