X5: Itching to create a patch that shuts the LCD off when backlight is off.

[jhMikeS]

I've read a request on another thread about shutting down the LCD panel when the backlight is off. Some code is in place already to facilitate this and I almost know how to procede on the X5 (the only player I have right now). Is it even worth it?

I'm new to just about EVERYTHING as far as what each file is for in rockbox, cygwin, UNIX shell, the utilities used for building rockbox (cvs, gcc, etc.), little familiarity with the MCF5249 and HC66773R but I believe I'm making progress in my knowledge.

The MFC5249 User's manual is quite daunting at 450 pages and the HD667733R at 133 pages too. I just need a little help!

I do have some questions (better asked on IRC?):
The LCD command register and data register are listed in the twiki as 0x20008000 and 0x20008002 repectively but the driver writes to 0xF0008000 and 0xF0008002. Why this descrepancy?

How is the mapping of the LCD chip to CPU memory addresses accomplished? Is it hardwired on the board or done in the software somewhere? Which lines? Knowing this would help my understanding of the CPU greatly.

Which interface does the LCD driver use? I know it's 18-bit but serial or parallel?

I still need to get my setup completed and learn how build the sources for the X5 port but the wiki is down and I'm left with cached pages on Google which is slowing me down a lot.

Not quite entirely related:
Will full 18-bit color ever be supported? The driver expands colors from 5-6-5 to 6-6-6 before writing them to the gram. It appears that color values would have to be longs and not ints and that would mean changing a lot of code (not that I wouldn't take it on). I've been warned about changing everything!

[Llorean]

Yes, your best bet is to ask in the IRC channel.

The only one of these I *might* be able to answer is relating to the 16/18 issue. I do believe 16 bit is used even on 18-bit targets simply because it's faster. 18 bit is possible, if I understand correctly, but would be considerably slower.

Oh, and shutting the LCD off won't gain *much* since all the drawing calculations have to be done anyway to keep the screen updated, as the various threads don't know the whole screen's state.

[jhMikeS]

All the code for writing to gram would be skipped while the display is off though. There's quite a bit of writing going from the screen buffer to gram. You're saying this extra step doesn't consume much power? Additionally , how 'bout shutting the chip down entirely when (sleep or standby) not in use? The powerup sequence doesn't appear to take too long.

As far as full color support goes, I seriously wouldn't mind *gasp* wasting the memory and just using 32 bits per pixel for simplicity and speed. The memory requirement would only be doubled. It can also be dithered easily enough if someone wants super high quality.

[Llorean]

Well, tests on another color player showed that shutting off the screen entirely, but leaving the drawing routines as-is, didn't affect things significantly (if I recall.) There was some increase in battery life, but not as much as was hoped.
Though to be honest, at the time they were hoping for a LOT. And I don't really recall hard numbers as to the actual improvement.

As for doubling the memory used by the screen, you'd also have to double the memory available for the WPS buffer. I can't really see 18-bit color offering a major improvement for the while playing screen or for the menuing system. Maybe for image-viewing though. But that's just me.

[jhMikeS]

It can certainly be tried-out and would be educational for me. For the X5 it looks like some rather simple changes to the lcd and backlight files.

A parallel API to use full native color depth for image viewing (and maybe eventually video) might be worth working on.  Only one additional function call that expects 24 or 32 bit pixel data (with optional dithering) should be needed to start out. How about lcd_blit_ex? It could be used concurrently with existing functions when extra color quality is desired.

I'll get set up on IRC and not get too much heavier here.

[Llorean]

Sounds like a good idea. I would personally suggest talking to Amiconn in IRC (when he's around) about the improved bit depths. He's either likely to be able to answer your questions, or point you in the right direction for who to discuss it with.

[Bagder]

The X5 LCD can't display 18bit colors, only 16bit.

[RaeNye]

The MFC5249 User's manual is quite daunting at 450 pages and the HD667733R at 133 pages too. I just need a little help!

Actually X5 uses the SCF5250. Not that I could find any difference except for IRAM size / clock speed.
The important part of the LCD specs is the set of commands.

The LCD command register and data register are listed in the twiki as 0x20008000 and 0x20008002 repectively but the driver writes to 0xF0008000 and 0xF0008002. Why this descrepancy?

The default value of CS2 (a "segment" register) is 0x20000000, also used by the OF. RB uses 0xF0000000, hence all memory addresses in this area (LCD, IDE, USBOTG) are rebased.

How is the mapping of the LCD chip to CPU memory addresses accomplished? Is it hardwired on the board or done in the software somewhere? Which lines? Knowing this would help my understanding of the CPU greatly.

RB sets CS2 in crt0.S. The offset 0x8000 is probably hardwired. You care not.

Which interface does the LCD driver use? I know it's 18-bit but serial or parallel?

The interface used, probably hardwired, is two memory mapped registers (LCD_CMD and LCD_DATA), addressed using "stupid 16-bit to 18-bit mode". This means you have to read/write the high 8 bits as 9 bits and then separately the low 8 bits as 9 bits, rendering IO twice as slow.
RB uses a look-up table to ease this a bit.

LCD commands tend to look like "write XXX to LCD_CMD, then read/write YYY from/to LCD_DATA". Note that when copying framebuffer to the LCD you only need to issue the write command once and afterwards you just keep writing the data.

Also, you should check out the HWM (sp?) mode that allows 4 aligned LCD writes to be done in parallel. It probably requires changing the direction the framebuffer is stored, but maybe it's faster.

As far as full color support goes, I seriously wouldn't mind *gasp* wasting the memory and just using 32 bits per pixel for simplicity and speed. The memory requirement would only be doubled. It can also be dithered easily enough if someone wants super high quality.

Currently the framebuffer takes 0xF000 bytes out of the available 0x20000 bytes in IRAM. You would have to either get it out of IRAM (-33% performance IIRC) or get everything else out.

I've read a request on another thread about shutting down the LCD panel when the backlight is off. ... Is it even worth it?

I think this should come with a more global device standby scheme, e.g.,

• backlight is off after 5 seconds w/o keypresses (actually I want a fade-out
• HDD is spun down after 10 seconds of no IO activity
• LCD is off after 1 minute of no button activity
• TLV320 is off after 20 seconds of no playback/record activity
• etc.

Even if not such implemented,  I want LCD to be shut down gracefully on player shutdown. It's The Right Thing^TM to do and might extend its life.

Feel free to ask more, I might be nice enough to answer ,
R.

[jhMikeS]

You're right. Things are making more sense now. I'm looking at the data sheet now and it says the 18 bit color is hardware dithered to 16-bit 565 if the DIT bit is set to "1".

I knew it! The 262,144 colors is a scam!

Is the chip interface hardwired for 18-bit or can 16-bit be used instead without modding? That probably would have been done already.

Image viewing/video could still be improved a little using the hard dithering anyway.

[jhMikeS]

RaeNye, thanks. You ansered some important things while I was replying to Badger.

The default value of CS2 (a "segment" register) is 0x20000000, also used by the OF. RB uses 0xF0000000, hence all memory addresses in this area (LCD, IDE, USBOTG) are rebased.

Can you tell what pins are involved in the addressing? That would help me understand the CPU better in general as far as hooking up external devices. I do care so! 

backlight is off after 5 seconds w/o keypresses (actually I want a fade-out )

Why is there no backlight dimming? That thing eats power and it doesn't need to be fullbright when looking at the WPS or browsing.

Also, you should check out the HWM (sp?) mode that allows 4 aligned LCD writes to be done in parallel. It probably requires changing the direction the framebuffer is stored, but maybe it's faster.

The lcd_x5.c is easy to understand in general. I'm curious about that burst RAM write stuff. It says you have to write four words (goes into registers) and writes that to GRAM while you write the next four words.

I want LCD to be shut down gracefully on player shutdown.

Yeah, I don't see the recommended power down sequence being observed anywhere in the driver.

I'm off to sleep now. Hopefully I can get on IRC and ask lots of questions later.  I just don't want to frustrate the gurus too much.   

[RaeNye]

Can you tell what pins are involved in the addressing? That would help me understand the CPU better in general as far as hooking up external devices. I do care so!  Grin

Sorry, now you actually have to read the whole specs .

The lcd_x5.c is easy to understand in general. I'm curious about that burst RAM write stuff. It says you have to write four words (goes into registers) and writes that to GRAM while you write the next four words.

That's what I meant. Alignment and other restrictions might kill us though.

Why is there no backlight dimming? That thing eats power and it doesn't need to be fullbright when looking at the WPS or browsing.

If you mean contrast/brightness control, checkout FS #5474.
I was talking about gradually dimming the backlight instead of just cancelling backlight altogether when 5 seconds have elasped.

[infamis]

damn RaeNye you've come a long way...props

In fact, I tried to open the firmware in IDA, but I don't really know which segments to create. Huh

I do see functions and data (e.g., strings, CRC-16 lookup tables, ...) but I cannot resolve absolute addresses.

I saw http://www.rockbox.org/twiki/bin/view/Main/IaudioPort#Original_firmware_information, but I just don't understand what exactly is considered ROM, RAM, "ports", etc. (what are IRAM and GPIO anyway?)

[RaeNye]

LOL.
But I really did learn much about embedded platforms from RB.

[jhMikeS]

I basically finished the patch last night however I want it tweaked to prevent backlight flicker on power off. I'm doing that now.

It does two main things:
1) Shuts the LCD down gracefully.
2) Shuts the LCD off and puts it in standy mode when the backlight goes off and of course restarts it when the backlight is turned back on.

I'll post when I'm basically happy with it. 

[nicolinux]

It's a good idea I think.

Thanks !