|Age||Commit message (Collapse)||Author||Files||Lines|
Free malloc in checkwps too
I'm currently running up against the limitations of the lcd_draw functions
I want these functions to be able to be used on any size buffer not
just buffers with a stride matching the underlying device
[DONE] allow the framebuffer to be decoupled from the device framebuffer
[DONE need examples] allow for some simple blit like transformations
[DONE] remove the device framebuffer from the plugin api
[DONE}ditto remote framebuffer
[DONE] remove _viewport_get_framebuffer you can call struct *vp = lcd_set_viewport(NULL) and vp->buffer->fb_ptr
while remote lcds may compile (and work in the sim) its not been tested on targets
[FIXED] backdrops need work to be screen agnostic
[FIXED] screen statusbar is not being combined into the main viewport correctly yet
[FIXED] screen elements are displayed incorrectly after switch to void*
[FIXED] core didn't restore proper viewport on splash etc.
[NEEDS TESTING] remote lcd garbled data
[FIXED] osd lib garbled screen on bmp_part
[FIXED] grey_set_vp needs to return old viewport like lcd_set_viewport
[FIXED] Viewport update now handles viewports with differing buffers/strides by copying to the main buffer
[FIXED] splash on top of WPS leaves old framebuffer data (doesn't redraw)
[UPDATE] refined this a bit more to have clear_viewport set the clean bit and have skin_render do its own screen clear
scrolling viewports no longer trigger wps refresh
also fixed a bug where guisyncyesno was displaying and then disappearing
[ADDED!] New LCD macros that allow you to create properly size frame buffers in you desired size without wasting bytes
(LCD_ and LCD_REMOTE_)
LCD_STRIDE(w, h) same as STRIDE_MAIN
LCD_FBSTRIDE(w, h) returns target specific stride for a buffer W x H
LCD_NBELEMS(w, h) returns the number of fb_data sized elemenst needed for a buffer W x H
LCD_NATIVE_STRIDE(s) conversion between rockbox native vertical and lcd native stride (2bitH)
test_viewports.c has an example of usage
[FIXED!!] 2bit targets don't respect non-native strides
[FIXED] Few define snags
The right thing here probably to just not bother at all, as this
bootloader can't launch rockbox yet anyway.
(we were trying to foward-declare functions from within static
initializer context. GCC no longer accepts this)
Replaced them with warnings until they are fixed *PROPERLY*
Allow IPod 3rd generation to recognize when USB is connected and reboot into disk mode.
This problem is listed at the bottom of the Ipod status page https://www.rockbox.org/wiki/IpodStatus
They confirmed it worked in the original ticket.
Prevents the rtc from breaking on power removal
(found using -Os with gcc494 on the nano2g)
If we come up and the RTC is in a reset state, we need to release that
before trying to initialze anything else. (See IMX23RM 23.8.1 and 39.3.10)
(The serial portions of the patch were already present, this just pulls
in the tuner enablements)
(They show up when building with gcc494)
For reasons that are still unclear, the 'ncbss' region was overlapping
the "audiobuffer" when linked with 2.21, but okay with 2.20.
Fixed it by making the audiobuffer explcitly use the current position
instead of relying on it being implicit.
With this change, portalplayer-based targets generate working binaries
when built with binutils 2.21 or newer.
This bug also theoretically affects imx233/imx31 targets as they
also have NOCACHE_BASE games in their linker scripts, but I lack
access to one to test with.
This patch doesn't implement them just defines them
User reported LCD screen corruption via forum in 3.14 and 3.15
turning backlight off and back on seems to fix the issue
It's even missing a config header file. Just shoot it in the head.
The pp502x cache init code tries to flush the cache by reading
a block of DRAM. Change the starting point from 0x0 to 0x1000
so the compiler doesn't helpfully insert an undefined instruction
to deliberately crash the target.
(This behavior is intentional on the part of GCC, and was triggered
by using -Os with my experimental 4.9.4 toolchain)
This patch cleans up the sd driver for the V1 sansas
powersave implemented for the sd interface
7442742 ("iPod Classic: disable IRAM1") was causing subsequent ipod6g
bootloader builds to result in a completely black screen upon
installation, with recovery only possible with a reflash through DFU
IRAM1 is re-enabled for bootloader only.
use sleep setting to keep transflective LCD active without backlight
Taken from the xvortex fork (Roman Stolyarov)
Ported, rebased, and cleaned up by myself.
On Classic, IRAM1 (second 128Kb of a total of 256KB available IRAM) is
slower than DRAM. Codecs that actually are using regions of IRAM1 runs
faster when DRAM is used, so IRAM1 is disabled and only IRAM0 remains
enabled: 48KB for core and 80KB for codecs/plugins.
The next test_codec results shows how decode time is decreased:
file boosted unboosted
*.ra ~1.5% ~0.5%
*.mpc ~21% ~4.5%
*.ogg ~0.5% ~0%
nero_he*.m4a ~8% ~1%
nero*.m4a ~25% ~7%
wmapro*.wma ~4.5% ~0%
wma*.wma ~25% ~7%
In addition there is a small power save when IRAM1 HW is disabled.
This reverts commit 6f0320a9535bc1aa81d83fa879ac14d5ee603658.
This reverts commit 568b81202ebd24a3f7e9efe0558b5f6beed05b44.
Some devices seem to have trouble accessing the storage at lower voltages.
Allow user to select cpu undervolt
There have been quite a few issues across the SANSA AMS line related
to CPU undervolting while most players show greatly increased runtime
Rather than constanly upping the voltage we now have a
setting with a safe value for all players and the option for lower voltages
I plan to add a few other options here later such as disk
timings and maybe some other clocks/experimental settings
Added: Disk Low speed option for AS3525v2 devices cuts
frequency to 12 MHz from 24 MHz
Added: Disk Low speed option for AS3525v1 devices cuts
frequency to 15.5 MHz from 31 MHz
Added: I2c Low Speed AS3525 devices, should be bigger improvement for v1 devices
Fixed: Debug menu for AS3525v2 No SDSLOT frequency,
Showed IDE freq though it is unused
Added: DBOP and SSP underclocking affects display on v1/v2 respectively
Fixed: debug menu now has SSP frequency, and SSP_CPSR
Update: made settings menu more generic
Update: cleaned up code
Added: Clip v1 & Fuze v1 didn't have HAVE_ADJUSTABLE_CPU_VOLTAGE.
not sure why but, waiting on testing to confirm
Added: C200v2 and E200v2 devices and HAVE_ADJUSTABLE_CPU_VOLTAGE.
Fixed: v1 devices don't like display timing set lower (dbop)
v1 devices don't have a divider set for ssp (causes divide by 0)
Fixed: ClipZip display lags with Max SSP divider changed from 0xFE to 0x32
Fixed: v1 devices didn't work properly with highspeed sd cards
Added code from http://gerrit.rockbox.org/r/#/c/1704/
Added powersave and IDE interface enable/disable
Added: V2 devices now have powersave enabled on sd interface
Update: cleaned up code, lang defines, added manual entries
Update ssp clock mechanism added calculated ssp divider to clipzip
Update turn display clock off when clip+ turns off display
Fixed: clipzip wrong register for SSP clock
TODO: add other players?
Saves 100+ bytes (50 of it in iram), saves a bit of power
Internal LCD clock decreased but with added efficiency of drawing routines
loses only around 2 Hz on the scanrate (~75Hz) while fps is slightly increased
Column offsets are now calculated outside the loops saving a few instructions
Passing a LCD_NOP command after lcd_update turns off Data/Cmd# gpio
saving a bit more power
Added a function lcd_write_cmd_triple() that allows 3 commands to be sent at once
when enabled with LCD_USE_FIFO_FOR_COMMANDS it sends them back to back without
checking FIFO status in between or sending to thhe D/C# Gpio.
Makes an assumption about the FIFO being large enough to
accept 3 commands after being emptied which should be the case on the
clipv1, clipv2, clipplus. I have only enabled it for the clip plus
as thats the only device I have to test it on.
On clip+ the SSP clock is now turned off when screen is off
On the clip zip most debug menu items get cut off and there is
no way to read most of the debug menu items.
This patch makes the menu button scroll the text 1 character
to the right with each press and the center (select) button
re-aligns the text
Adds SSP frequency(v2) & register
Adds SD slot frequency(v2)
I2c controller needs to be enabled in order to read CSPR0, CSPR1
registers function sets CGU_I2C_AUDIO_MASTER_CLOCK_ENABLE
and only clears if it wasn't previously enabled
Use divider set in register to calculate frequency rather than
hard coded divider
switching GPIOB in order to read GPIOD96)
(power button) is apparently unneeded
Also removes the sd_enable() function call. It was only used in
the debug screen on AMSv1 and not used at all on AMS v2.
For v1,obtain debug info in a struture passed to a dedicated
debug info function so that enabling and disabling the controller
Lcd_update rect was hanging during horizontal screen update x = 238 and width = 2
which was within the bounds of the screen, this seems to be a weird corner case
but more testing needs done.
Update_rect now properly bounded between 0 - screen w/h
--Cleaned up code
Pixels in x are now multiples of 4.
WORD_LENGTH=0 implies the input frame buffer is RGB 16 bits per pixel.
DATA_FORMAT_16_BIT field indicates if the pixels are in RGB 555 or RGB 565 format.
— BYTE_PACKING_FORMAT [3:0] should be 0x3 or 0xC if there is only one pixel per word.
— If there are two pixels per word, BYTE_PACKING_FORMAT [3:0] should be 0xF and
H_COUNT will be restricted to be a multiple of 2 pixels.
WORD_LENGTH=3 indicates that the input frame-buffer is RGB 24 bits per pixel (RGB 888). If
BYTE_PACKING_FORMAT [3:0] is 0x7, it indicates that there is only one pixel per 32-bit word
and there is no restriction on H_COUNT.
— If BYTE_PACKING_FORMAT [3:0] is 0xF, it indicates that the pixels are packed, i.e. there
are 4 pixels in 3 words or 12 bytes. In that case, H_COUNT must be a multiple of 4 pixels.
We are using 16 bits per pixel and byte_packing = 0xF but device crashes with multiple of 2 pixels
Behaviour can be verified with plugin - oscilloscope, Horizontal mode device hangs as indicator
reaches right of screen
Keymaps aren't tested, there may be room for improvement.
Windows now ignores the hidden flag, so just nullify the entries
to hide depending upon whether or not bootloader install mode is