[Letux-kernel] [PATCH 00/20] A bunch of JZ4730 fixups for letux-kernel

[Paul Boddie]

On Thursday, 14 January 2021 09:55:54 CET H. Nikolaus Schaller wrote:
> >
> >> Incidentally, related to something I noted before, the JZ4740 employs a
> >> two- descriptor arrangement to support display modes that use a palette,
> >> albeit using one DMA channel. However, dual-panel support involves two
> >> DMA channels, but with the all constant churn, the code that supported
> >> this is probably long since forgotten in Linux, hence the "unknown
> >> reason" for that second channel.
> > 
> > Ok, it may indeed be the palette. If I remember the 2.6.24 code there was
> > some setup for a palette descriptor.
> 
> Looks as if it is quite clearly described:
> 
> 	Registers LCDSA0 and LCDSA1, corresponding to DMA channels 0 and 1, contain
> the physical address of frame buffer or palette buffer in external memory.

It is important to distinguish between channels and descriptors here. LCDSA0 
and LCDSA1 are each channel's source address, populated by the LCDDA0 and 
LCDDA1 registers which define each channel's (initial) descriptor addresses.

However, each channel can employ chained descriptors (or maybe one of them 
can, at least), and this is where the palette descriptor is introduced. A 
channel providing a low pixel depth framebuffer with a palette will have the 
palette descriptor chained to the framebuffer descriptor, and the channel will 
jump between the descriptors when refreshing the display.

This is where the "next" member of the descriptor becomes pertinent: with only 
one framebuffer descriptor, the next member just contains the physical address 
of that descriptor, meaning that the same descriptor is used all the time; 
with a palette descriptor as well, the next members reference the other 
descriptor in the arrangement.

> This means we need one descriptor for the frame buffer DMA and the other one
> for the Palette. There we must obviously set the CMD.PAL bit.

Yes, but only where we are using a low pixel depth mode (8bpp or less).

> The first descriptor is not initialized, so it is neither a valid frame
> buffer nor a palette buffer... Having the first initialized and the second
> not seems to be ok. So it *might* also help to set the CMD.PAL bit for the
> first buffer...

If we were to provide a descriptor for the first channel/buffer with the 
palette bit set (if this is what you have in mind), then we would also need to 
chain this descriptor to a framebuffer descriptor. But then, we might as well 
just provide a single valid framebuffer descriptor for the first channel and 
ignore the second channel.

Using the second channel and not enabling the first was just a quick 
suggestion that doesn't change that much of the driver code, because that is 
likely not to be appreciated. However, we may not have any choice: the second 
channel may only be available to provide output for a second panel, as I 
discuss below.

> Now, assuming that we simply can ignore the first channel and use the second
> one only is obviously wrong...

There may be reasons why or when the first channel has to be used, such as a 
particular set of pins being wired to carry the signal from the first channel.

I admit I didn't consider this too much when I wrote my message, but looking 
at the manual I see that largely the same set of pins will be involved 
regardless of whether there is one TFT/active matrix panel or two STN/passive 
matrix panels connected. But with TFT selected by the software, the peripheral 
will be wanting a signal provided by the first channel.

> BTW: we are on the right track. I have removed xinit from my init scripts
> and tty* from the cmdline and now I can get a login: with no vblank
> timeouts.
> 
> And if I run my script that patches some values from the 2.6.24 kernel I now
> get a blinking cursor :)
> 
> So there is only a minor diff in the setup now.
> 
> I need a little time to manually do all devmem2 commands of my patch script
> to see which one makes the panel work.
> 
> So we are almost there :)

Well, it's nice to see some further progress. Of course, all of this would be 
easier if the driver just set up the first channel normally where OSD is not 
available, but I suppose that this is what our patches will end up doing.

Paul