Linux on ARM based TI OMAP SoCs
 help / color / mirror / Atom feed
From: Gary Thomas <gary@mlbassoc.com>
To: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: "linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>
Subject: Re: OMAP3530 vs DM3730
Date: Wed, 25 Jan 2012 05:24:56 -0700	[thread overview]
Message-ID: <4F1FF498.4050700@mlbassoc.com> (raw)
In-Reply-To: <1327489626.1858.34.camel@deskari>

On 2012-01-25 04:07, Tomi Valkeinen wrote:
> On Mon, 2012-01-23 at 06:46 -0700, Gary Thomas wrote:
>> On 2012-01-22 22:06, Hiremath, Vaibhav wrote:
>>> On Sat, Jan 21, 2012 at 21:46:38, Gary Thomas wrote:
>>>> 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();
>>           }
>> }
>
> I think this commit fixes the crash:
> c3dc6a7afb47735b82a4c0061e814454a649dbfc
>
> Your changes above seems to be ok for omap3.
>
>> 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 =).

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.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

      reply	other threads:[~2012-01-25 12:24 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-21 16:16 DSS: OMAP3530 vs DM3730 Gary Thomas
2012-01-23  5:06 ` Hiremath, Vaibhav
2012-01-23 13:46   ` Gary Thomas
2012-01-25 11:07     ` Tomi Valkeinen
2012-01-25 12:24       ` Gary Thomas [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F1FF498.4050700@mlbassoc.com \
    --to=gary@mlbassoc.com \
    --cc=linux-omap@vger.kernel.org \
    --cc=tomi.valkeinen@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox