[Letux-kernel] jz4780 read out LCDC setup for HDMI

Maarten ter Huurne maarten at treewalker.org
Sat Jun 6 12:46:20 CEST 2020

On Saturday, 6 June 2020 11:54:22 CEST Paul Boddie wrote:
> On Saturday 6. June 2020 02.15.29 Maarten ter Huurne wrote:
> > On the JZ4770 we found that end-of-frame interrupts would occur when
> > the DMA descriptor had been processed instead of when the transfer
> > ends. We put a dummy black line in a second DMA descriptor chained
> > after the first one and used that to detect the end of the frame.
> This kind of chaining arrangement reminds me of my PIC32 VGA signal
> generation experiment where I had to manually generate the black
> level after each display line. :-)
> But with regard to the JZ4780, the manual says this about the LCD
> command register:
> "When EOFINT = 1, the DMAC sets the end of frame bit (LCDSTATE.EOF)
> after fetching the last word in the frame buffer. In dual-panel mode,
> LCDSTATE.EOF is set only when both channels reach the end of frame
> and both frame descriptors have EOFINT set."
> So, this is the documented behaviour, at least (and maybe it is also
> described in this way in any JZ4770 manual). I suppose that if there
> is a delay between this final transfer and delivering the data to the
> display, it will make some kind of difference. Maybe if it causes
> problems, the OSD end-of-frame interrupts can be used instead.

No, the behavior we saw was that it generated the end-of-frame interrupt 
way before it fetched all the data to display. When we used the end-of-
frame interrupt for page flipping, we'd see the page being overpainted 
by the application, a sign that scanout was still reading from the 
framebuffer even though end-of-frame had been signalled.

> It would also be interesting to know what your experiences have been
> with the OSD functionality. It seems that this is always on in the
> JZ4780, and it also seems that the foreground planes must be
> configured regardless of whether they will be used, as noted in my
> earlier message.

I haven't used the OSD, but Paul recently did some tests with it (on 
JZ4770, I think) and got a test image showing overlaid above the 

> It doesn't seem to be necessary to use 64-word burst transfers:
> 16-word transfers also worked. Maybe this is advisible for
> performance or stability, however.

I would assume that longer bursts have less overhead, but since they 
keep the bus occupied for longer they may negatively affect latency of 
other subsystems, like the CPU trying to fill a cache line.

Something I noticed the other day is that JZ4770 components on the AHB0 
bus (like LCDC) have their own custom DMA controllers, while components 
on the AHB2 bus use the generic DMA controller. Which makes sense, but I 
didn't realize before that this is the pattern that determines which 
components have their own DMA.


More information about the Letux-kernel mailing list