All of lore.kernel.org
 help / color / mirror / Atom feed
From: Radek Dostal <radek.dostal@streamunlimited.com>
To: dri-devel@lists.freedesktop.org
Subject: Re: BUG Beaglebone HDMI output flickers
Date: Thu, 10 Mar 2016 11:41:33 +0100	[thread overview]
Message-ID: <56E14F5D.308@streamunlimited.com> (raw)
In-Reply-To: <56DFEA40.9060906@streamunlimited.com>

Dear All,

As the post above will be probably often found by google, I will post 
here also a temporary solution colleague of mine found to the flickering 
problem.

devmem2 0x4c000054 w 0x00FFFFF10

It is probably not ideal - there should be a way how to prioritize just 
the LCD transfers (according to the TI wiki), but the values there do 
not work. This fix just ensures that any "too old" command gets executed 
sooner than it would otherwise, maybe that is a good thing anyway.

However, I believe I understand all the various issues we've seen 
(although I could still be wrong - but this at least makes sense):

static image shift
   - here, the DMA for transferring data to LCD fifo is blocked for a 
short period of time once, but then it continues normally. This produces 
the fifo-underflow interrupt once, the data for display are few pixels 
late, but then all works normally so the image is just shifted (although 
not too visible in the photo, the "extra" pixels at top-left corner are 
black, and not white if the image was just wrapped).

full flickering
   - in this case, the memory load is so severe that the DMA is blocked 
too often and can't supply steady stream of data; producing 
fifo-underflow interrupts all over. The image still starts from the 
top-left corner as usual, but then the rest of the "pixel stream" 
contains some extra 0s so the testimage produces diagonal patterns (with 
varying error, hence the flickering).

So these 2 are the same issue, just with different outcome.

The problem is the DDR command prioritization logic in our memory 
controller, the memset() loop manages to starve the DMA data stream. The 
"fix" just tweaks the REG_PR_OLD_COUNT value - now if there is a DDR 
command in the memory controller fifo for too long, it will get executed 
(out of the prioritized ordering).

(I can probably also explain why it +- works with >2k buffers; but there 
I'm not fully sure yet.)

All this is based on this info:
http://processors.wiki.ti.com/index.php/DA8xx_LCDC_Linux_FB_FAQs

Thanks,
Radek
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

      reply	other threads:[~2016-03-10 10:41 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-09  9:17 BUG Beaglebone HDMI output flickers Radek Dostál
2016-03-10 10:41 ` Radek Dostal [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=56E14F5D.308@streamunlimited.com \
    --to=radek.dostal@streamunlimited.com \
    --cc=dri-devel@lists.freedesktop.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.