- Speed auto detection is launched when an accessory is inserted,
so the user doesn't need to modify settings to use accessories
that operates at different speeds (or when the same accessory is
unplugged and plugged again).
- UART controller is disabled when no accessory is inserted, not
much powersave but everything counts.
Change-Id: If20c3617c2a87b6277fd7e0270031030c44fa953
PMU interrupts are used to detect USB Vbus, wall adaptor, accessories
and holdswitch. A thread is needed to poll the PMU throught I2C, ATM
it does nothing but showing the state of the inputs on the HW debug
menu, funcionallity for each individual input will be added in next
patches.
Change-Id: If93bf2044d1052729237a7fd1431c8493e09f1c7
Do not rely on a bootloader initializing the HW, RB initializes
and configures GPIO, I2C, and PMU at startup.
Change-Id: If7f856b1f345f63de584aa4e4fc22d130cd66c80
Low level functions that do not depend on Rockbox kernel,
intended to be used by the bootloader, dualboot-installer,
RB drivers or other .dfu tools.
Change-Id: If80214d26e505265ace19d9704f1e1300f98b2f4
When the bootloader starts, most of HW never has been initialized.
This patch includes all code needed to perform the preliminary
initialization on SYSCON, GPIO, i2c, and MIU.
The code is based on emCORE and OF reverse engineering, ported to
C for readability.
Change-Id: I9ecf2c3e8b1b636241a211dbba8735137accd05c
This patch optimizes UDMA timings to increase write transfer rate on
ATA bus, these transfers are clocked by HCLK, tDVS+tDVH is modified to
decrease Tcyctyp (typical write cycle period). This is not overclocking,
we meet the ATA standar, the settings used by OF are not well optimized
for each UDMA mode, we will never know but probably this was due some
documentation issue.
ATA_UDMA_TIME register is documented on s3c6400 datasheet, information
included in s5l8700 datasheet is wrong or not valid for s5l8702.
From ATA specs, (Minimum, Maximum) values in nanoseconds:
UDMA 0 UDMA 1 UDMA 2 UDMA 3 UDMA 4
tACKENV (20, 70) (20, 70) (20, 70) (20, 55) (20, 55)
tRP (160, --) (125, --) (100, --) (100, --) (100, --)
tSS (50, --) (50, --) (50, --) (50, --) (50, --)
tDVS (70, --) (48, --) (31, --) (20, --) (6.7, --)
tDVH (6.2, --) (6.2, --) (6.2, --) (6.2, --) (6.2, --)
tDVS+tDVH (120, --) (80, --) (60, --) (45, --) (30, --)
Tcyc = tDVS+tDVH
WR[bytes/s] = 1/Tcyc[s] * 2[bytes]
On Classic (boosted):
HClk = 108 MHz. -> T = ~9.26 ns.
Old values (used by OF):
UDMA ATA_UDMA_TIME tACK tRP tSS tDVS tDVH Tcyc WR(MB/s)
0 0x5071152 27.8 166.7 55.6 74.1 55.6 129.7 15.4
1 0x3050a52 27.8 101.8 55.6 55.6 37 92.6 21.6
2 0x3030a52 27.8 101.8 55.6 37 37 74 27
3 0x2020a52 27.8 101.8 55.6 27.8 27.8 55.6 36
4 0x2010a52 27.8 101.8 55.6 18.5 27.8 46.3 43.2
New values:
UDMA ATA_UDMA_TIME tACK tRP tSS tDVS tDVH Tcyc WR(MB/s)
0 0x4071152 27.8 166.7 55.6 74.1 46.3 120.4 16.6
1 0x2050d52 27.8 129.6 55.6 55.6 27.8 83.4 24
2 0x2030a52 27.8 101.8 55.6 37 27.8 64.8 30.9
3 0x1020a52 27.8 101.8 55.6 27.8 18.5 46.3 43.2
4 0x1010a52 27.8 101.8 55.6 18.5 18.5 37 54
To verify that the settings are correct, a write-to-cache test was
performed using emCORE, the measured transfer rate (WRm) is compared
against the theoric transfer rate (WR) at 108 Mhz for the old and
the new UDMA4 settings (iPod 160, HDD Toshiba MK1634GAL):
UDMA ATA_UDMA_TIME Tcyc(ns) WR(MB/s) WRm(MB/s) RDm(MB/s)
4 0x2010a52 46.3 43.2 42.9 59.8
4 0x1010a52 37 54 53.5 59.8
Notes:
- The new UDMA4 settings increases ~25% the ATA transfer rate for
cached-writes. The real HDD write speed is limited by the internal
transfer rate (depends on cilinder, for the MK1634GAL it is 276 to
573 Mbits/s). Sequential write benchmark using diskdump on USB are
~8% faster.
- Read transfers are clocked by the device, it depends on UDMA mode
selected and are not affected by HClk or ATA_UDMA_TIME settings.
Read-from-cache tests results (RDm) using HClk=108 and HClk=54 for
UDMA4 are 59.8 MB/s on MK1634GAL.
- Minimum HClk is limited by tACKENV specs, using current settings
it is 54 MHz for UDMA4,UDMA3 and 43 MHz for UDMA2,UDMA1,UDMA0.
Change-Id: I61d67060410752518a59e1ff08072b21747ca997
When the bootloader starts only IRAM is available, the first task is to
ask the PMU to verify if the iPod has previously been hibernated by OF.
Due to memory limitations, the kernel cannot be used on this stage.
This patch modifies I2C and PMU low level functions to not to depend
on kernel (removes mutexes, and uses HW timer instead of current_tick),
actual kernel functions are modified to be 'mutexed' wrappers of the new
functions.
Change-Id: I7cef9e95dedaf176dc0659315f3dc33166d5b116
- Small rework on the UC8702 UART controller to make it compatible with
other s5l870x SOCs. Files moved and renamed, many conditional code
added to deal with capabilities and 'features' of the different CPUs.
- A couple of optimizacions that should not affect the functionality.
Change-Id: I705169f7e8b18d5d1da642f81ffc31c4089780a6
This should allow FireWire charging to work on these devices.
It also adds charging state detection on the iPod Classic.
(cherry picked from commit fa86fec4fb089b47f5c2c3b1f2f3dbc97551895b)
On Classic (and probably Nano 2G), it seems that the 100/500mA limit
applies only to USB chargers, when FW is connected it supplies all the
power (even if USB is also connected) and USB current limit does not
affect to FW charging, therefore the limit is only set when USB is
connected.
Change-Id: I7c6bab1b6a0f295367999c45faeda6085c3fb091
Signed-off-by: Cástor Muñoz <cmvidal@gmail.com>
Read/write buffers who are aligned to 16 were not re-aligned to 32 as
it should be. Althrough USB storage and buffering are always passing
buffers aligned to 32, a few unaligned buffers are being received from
other tasks, so this patch could solve some rare random issues.
Also fixes DMA configuration for HDDs that support any MDMA mode but
only UDMA0 (probably will never happen).
Change-Id: I00219ae434205681c69293fc563e0526224c9adf
- Add description for attributes supported by Samsung HS081HA (80Gb)
and HS161JQ (CEATA 160Gb).
- Show error code when ata_read_smart() fails.
Change-Id: I618cc4f37d139fc90f596e2cf3a751346b27deb6
Reverts commit ead38dbc9d
It was introduced as a temporal workaround to avoid the endless restart
loop when battery is low, but really it is useless. The bootloader should
ensure that there is enough power to launch Rockbox even in the worst
scenario.
Change-Id: Iabebed40c9241af915c16c3c6c4d3c6deef7680e
Configures uncached memory region and adds some defines for misc HW,
for compability with the bootloader and other future use, current
functionality should not be affected.
Change-Id: I390e79bea1aef5b10dfbc72ad327d7fe438ec6f5
This is a rewrite of the clocking section, the resulting system
frequencies are the same as the current git version.
This pàtch uses fixed FClk and just one register is written to switch
all system frequencies, it needs less steps than the current git
version to reach the desired frequency, so it is faster and safer.
Includes functions to step-up/down over a table of predefined set of
frequencies.
The major difference is that Vcore is decreased from 1050 to 1000 mV.
See clocking-s5l8702.h for more information.
Change-Id: I58ac6634e1996adbe1c0c0918a7ce94ad1917d8e
Adds ata_read_smart() function to storage ATA driver, current
SMART data can be displayed and optionally written to hard
disk using System->Debug menu.
Change-Id: Ie8817bb311d5d956df2f0fbfaf554e2d53e89a93
This patch limits the drawn USB current to 100/500mA, instead of
the actual 200/1000mA settings. It also initializes other USB power
related GPIOs.
Solves some USB disconnect issues: FS#12990, FS#12956. I am using a
powered USB HUB with no problems (Vusb=5.05V unloaded), but there
are lots of USB disconnects when using the motherboard USB ports
(Vusb=4.91V), this patch solves all my issues.
Actually, it seems that the USB current drain is limited to 1000mA,
when a load peak occurs most USB2 ports deliver more than 500mA, as
current consumption increases the USB voltage decreases, an excesive
voltage drop produces USB disconnections. Limiting USB current drain
to 500mA also limits the voltage drop, preventing subsequent USB
failures.
Anyway, to minimize voltage drop, it is recommended to use quality
cables and preferably connect to USB ports with higher Vusb.
Change-Id: I1b931aa18ec93bfd1214e475a72e42893eff52f6
- polling/IRQ modes for Tx/Rx (TODO?: DMA)
- fine adjust for Tx/Rx bitrates
- auto bauding using HW circuitry
- status and stats in debug screen
Change-Id: I8650957063bc6d274d92eba2779d93ae73453fb6
This patch has been tested on iPod 80 and 160slim, actually
it works but some updates must be done to the final version:
- unlimitted input buffer
- decrease CHUNK_SIZE
- use non-cached addresses instead of discard d-cache ???
Capture hardware versions:
Ver iPod models capture support
--- ----------- ---------------
0 80/160fat dock line-in
1 120/160slim dock line-in + jack mic
HW version 1 includes an amplifier for the jack plug mic.
Capture HW detection only tested on iPod 80 and 160slim.
CODEC power:
AFAIK, OF powers CS42L55 at VA=2.4V for capture (1.8V for
playback) and turns on the ADC charge pump. CODEC datasheet
recommmends to disable the charge pump for VA>2.1V.
CS42L55 DS, s4.13 (Required Initialization Settings): for
VA>2.1V, some adjustments "must" be done using undocummented
"control port compensation" registers. OF does not modifies
these registers when VA=2.4V.
This patch configures capture HW in the same way as OF does.
TODO:
- ADC full scale voltage depends on VA, perform tests to find
clipping levels for VA=1.8V and VA=2.4V
Change-Id: I7e20fd3ecaa83b1c58d5c746f5153fe5c3891d75
This patch uses the new pl080 DMA driver for I2S playback and LCD
update. I have tried to be as fiel as possible to the current
behaviour, algorithms and configurations are the same, but using
the new driver. Other modifications:
Playback:
- CHUNK_SIZE is decreased from 42988 to 8188 bytes, it does not
affect normal playback (block size 1024), was tested using
metronome (block size 46080). This change is needed because the
new code commits d-cache range instead of commiting the whole
d-cache, maximum time spent commiting the range should be
limited, CHUNK_SIZE can be decreased even more if necessary.
- pcm_play_dma_start() calls pcm_play_dma_stop() to stop the
channel when it is running (metronome replays the tick sound
without stopping the channel).
- pcm_play_dma_get_peak_buffer(): same as actual SVN function but
returns samples count instead of bytes count.
TODO: AFAIK, actually this function is not used in RB. Not tested,
but probably this function will fail because it returns pointers
to the internal double buffer.
LCD update:
- suppresses lcd_wakeup semaphore and uses yield()
Change-Id: I79b8aa47a941e0dd91847150618f3f7f676c26ef
Motivation:
This driver began as a set of functions to help to test and
experiment with different DMA configurations. It is cumbersome,
time consuming, and leads to mistakes to handle LLIs and DMA
registers dispersed along the code.
Later, i decided to adapt an old DMA queue driver written in the
past for a similar (scatter-gather) controller, all task/queue
code is based on the old driver.
Finally, some cleaning and dmac_ch_get_info() function was added
to complete RB needs.
Description:
- Generic, can be used by other targets including the same
controller. Not difficult to adapt for other similar
controllers if necesary.
- Easy to experiment and compare results using different
setups and/or queue algorithms:
Multi-controller and fully configurable from an unique place.
All task and LLI management is done by the driver, user only
has to (statically) allocate them.
- Two queue modes:
QUEUE_NORMAL: each task in the queue is launched using a new
DMA transfer once previous task is finished.
QUEUE_LINK: when a task is queued, it is linked with the last
queued task, creating a single continuous DMA transfer. New
tasks must be queued while the channel is running, otherwise
the continuous DMA transfer will be broken.
On Classic, QUEUE_LINK mode is needed for I2S continuous
transfers, QUEUE_NORMAL is used for LCD and could be useful
in the future for I2C or UART (non-blocking serial debug) if
necessary.
- Robust DMA transfer progress info (peak meter), needs final
testing, see below.
Technical details about DMA progress:
There are comments in the code related to the method actually
used (sequence method), it reads progress without halting the
DMA transfer. Althought the datasheet does not recommend to do
that, the sequence method seems to be robust, I ran tests calling
dmac_ch_get_info() millions of times and the results were always
as expected (tests done at 2:1 CPU/AHB clock ratio, no other
ratios were tried but probably sequence method will work for any
typical ratio).
This controller allows to halt the transfer and drain the DMAC
FIFO, DMA requests are ignored when the DMA channel is halted.
This method is not suitable for playback because FIFO is never
drained to I2S peripheral (who raises the DMA requests). This
method probably works for capture, the FIFO is drained to memory
before halting.
Another way is to disable (stop) the playback channel. When the
channel is disabled, all FIFO data is lost. It is unknown how much
the FIFO was filled when it was cleared, SRCADDR counter includes
the lost data, therefore the only useful information is LINK and
COUNT, that is the same information disponible when using the
sequence method. At this point we must procced in the same way as
in sequence method, in addition the playback channel should be
relaunched (configure + start) after calculating real SRCADDR.
The stop+relaunch method should work, it is a bit complicated,
and not valid for all peripheral FIFO configurations (depending
on stream rate). Moreover, due to the way the COUNT register is
implemented in HW, I suspect that this method will fail when
source and destination bus widths doesn't match. And more
important, it is not easy to garantize that no sample is lost
here or there, using the sequence method we can always be sure
that playback is ok.
Change-Id: Ib12a1e2992e2b6da4fc68431128c793a21b4b540
This patch implements a simple API to use the external interrupt
hardware present on s5l8702 (GPIO interrupt controller). This
GPIOIC has been fully tested using emcore apps.
Code is based on openiBoot project, there are a few modifications
to optimize space considering we will only use two or three external
interrupts. The API compiles and works, but has been never used,
therefore probably will need some changes to the final version.
External interrupts are necessary for jack remote+mic controller
(see iAP Interface Specifiction: Headphone Remote and Mic System),
this controller is located at I2C bus address 0x72, there is a IRQ
line for remote button press/release events routed to GPIO E6. At
this moment, the functionallity of this controller has been
extensively tested using emcore, getting a lot of information about
how it works. Microphone is already working on RB, jack accessory
detection and button events are work in progress.
PMU IRQ line is also routed to GPIO F3, it signals many events:
holdswitch, usb plug, wall adapter, low battery... The use of PMU
interrupts is the orthodox way of doing things, at this moment
there is no work done in this direction, there are a lot of PMU
events and i think it is a matter of discursion what to do and how.
Change-Id: Icc2e48965e664ca56c9518d84a81c9d9fdd31736
Optimizes YUV to RGB conversion using ARMv5 multiply-accumulate
intructions for operations and data tables for saturation.
This first patch set includes the three versions i have developed.
Although iPod Classic need to use the latest version to reach 30fps,
old versions may serve other targets.
All versions are based on current SVN algorithm (round->scale->add)
using the same coefficients, so output results are identical.
Version history:
ARMv4:
- use all available registers to calculate four pixels within each
loop iteration.
- avoid LDR interlocks.
ARMv5TE:
- use ARMv5TE+ 1-cycle multiply-accumulate instructions.
ARMv5TE_WST:
- use data tables (256 bytes) for RBG565 saturation.
Benchmarks results using iPod Classic (ARM926EJ 216Mhz):
size test_fps (1) mpegplayer (2)
bytes YUV YUV1/4 average min/max
----- ----------- ------------------
SVN-20141107 528 27.8 110.0 11035 10864/13397
ARMv4 480 28.8 114.0 9767 9586/12126
ARMv5TE 468 29.7 117.5 8751 8584/11118
ARMv5TE_WST 544 33.6 133.0 6355 6316/6403
(1) boosted
(2) play full elephants_dream_320x240.mpg file (15693 frames) using
mpegplayer, patched RB measures YUV to RGB565 frame conversion
time (microseconds)
Compared against the WST version, the ARMV5TE version w/o cached
saturation tables is slower, but it is smaller and i have doubts
about the power consumption.
Change-Id: I2b6a81804636658d85a1bb104ccb2055e77ac120
Reviewed-on: http://gerrit.rockbox.org/1034
Reviewed-by: Cástor Muñoz <cmvidal@gmail.com>
Tested: Cástor Muñoz <cmvidal@gmail.com>
Use 32 bytes for cache line length (arm926ej-s), this prevents
misalignments of ATA storage buffer which in some builds could
cause weird faults.
Change-Id: I88dc595d251315620ec49b0251ddc039ff47181e
Reviewed-on: http://gerrit.rockbox.org/1031
Reviewed-by: Marcin Bukat <marcin.bukat@gmail.com>
This improves compatibility with various HDD and CF/SD card mods.
It should also reduce power consumption while the drive is powered down.
Change-Id: I4b22c59b5d9ae2daea2ec5892e348e7e1934ca3e
Reviewed-on: http://gerrit.rockbox.org/897
Tested: Franklin Wei <frankhwei536@gmail.com>
Tested: Nial Shui <nialv7@gmail.com>
Tested: Michael Sparmann <theseven@gmx.net>
Reviewed-by: Marcin Bukat <marcin.bukat@gmail.com>
This patch redoes the filesystem code from the FAT driver up to the
clipboard code in onplay.c.
Not every aspect of this is finished therefore it is still "WIP". I
don't wish to do too much at once (haha!). What is left to do is get
dircache back in the sim and find an implementation for the dircache
indicies in the tagcache and playlist code or do something else that
has the same benefit. Leaving these out for now does not make anything
unusable. All the basics are done.
Phone app code should probably get vetted (and app path handling
just plain rewritten as environment expansions); the SDL app and
Android run well.
Main things addressed:
1) Thread safety: There is none right now in the trunk code. Most of
what currently works is luck when multiple threads are involved or
multiple descriptors to the same file are open.
2) POSIX compliance: Many of the functions behave nothing like their
counterparts on a host system. This leads to inconsistent code or very
different behavior from native to hosted. One huge offender was
rename(). Going point by point would fill a book.
3) Actual running RAM usage: Many targets will use less RAM and less
stack space (some more RAM because I upped the number of cache buffers
for large memory). There's very little memory lying fallow in rarely-used
areas (see 'Key core changes' below). Also, all targets may open the same
number of directory streams whereas before those with less than 8MB RAM
were limited to 8, not 12 implying those targets will save slightly
less.
4) Performance: The test_disk plugin shows markedly improved performance,
particularly in the area of (uncached) directory scanning, due partly to
more optimal directory reading and to a better sector cache algorithm.
Uncached times tend to be better while there is a bit of a slowdown in
dircache due to it being a bit heavier of an implementation. It's not
noticeable by a human as far as I can say.
Key core changes:
1) Files and directories share core code and data structures.
2) The filesystem code knows which descriptors refer to same file.
This ensures that changes from one stream are appropriately reflected
in every open descriptor for that file (fileobj_mgr.c).
3) File and directory cache buffers are borrowed from the main sector
cache. This means that when they are not in use by a file, they are not
wasted, but used for the cache. Most of the time, only a few of them
are needed. It also means that adding more file and directory handles
is less expensive. All one must do in ensure a large enough cache to
borrow from.
4) Relative path components are supported and the namespace is unified.
It does not support full relative paths to an implied current directory;
what is does support is use of "." and "..". Adding the former would
not be very difficult. The namespace is unified in the sense that
volumes may be specified several times along with relative parts, e.g.:
"/<0>/foo/../../<1>/bar" :<=> "/<1>/bar".
5) Stack usage is down due to sharing of data, static allocation and
less duplication of strings on the stack. This requires more
serialization than I would like but since the number of threads is
limited to a low number, the tradoff in favor of the stack seems
reasonable.
6) Separates and heirarchicalizes (sic) the SIM and APP filesystem
code. SIM path and volume handling is just like the target. Some
aspects of the APP file code get more straightforward (e.g. no path
hashing is needed).
Dircache:
Deserves its own section. Dircache is new but pays homage to the old.
The old one was not compatible and so it, since it got redone, does
all the stuff it always should have done such as:
1) It may be update and used at any time during the build process.
No longer has one to wait for it to finish building to do basic file
management (create, remove, rename, etc.).
2) It does not need to be either fully scanned or completely disabled;
it can be incomplete (i.e. overfilled, missing paths), still be
of benefit and be correct.
3) Handles mounting and dismounting of individual volumes which means
a full rebuild is not needed just because you pop a new SD card in the
slot. Now, because it reuses its freed entry data, may rebuild only
that volume.
4) Much more fundamental to the file code. When it is built, it is
the keeper of the master file list whether enabled or not ("disabled"
is just a state of the cache). Its must always to ready to be started
and bind all streams opened prior to being enabled.
5) Maintains any short filenames in OEM format which means that it does
not need to be rebuilt when changing the default codepage.
Miscellaneous Compatibility:
1) Update any other code that would otherwise not work such as the
hotswap mounting code in various card drivers.
2) File management: Clipboard needed updating because of the behavioral
changes. Still needs a little more work on some finer points.
3) Remove now-obsolete functionality such as the mutex's "no preempt"
flag (which was only for the prior FAT driver).
4) struct dirinfo uses time_t rather than raw FAT directory entry
time fields. I plan to follow up on genericizing everything there
(i.e. no FAT attributes).
5) unicode.c needed some redoing so that the file code does not try
try to load codepages during a scan, which is actually a problem with
the current code. The default codepage, if any is required, is now
kept in RAM separarately (bufalloced) from codepages specified to
iso_decode() (which must not be bufalloced because the conversion
may be done by playback threads).
Brings with it some additional reusable core code:
1) Revised file functions: Reusable code that does things such as
safe path concatenation and parsing without buffer limitations or
data duplication. Variants that copy or alter the input path may be
based off these.
To do:
1) Put dircache functionality back in the sim. Treating it internally
as a different kind of file system seems the best approach at this
time.
2) Restore use of dircache indexes in the playlist and database or
something effectively the same. Since the cache doesn't have to be
complete in order to be used, not getting a hit on the cache doesn't
unambiguously say if the path exists or not.
Change-Id: Ia30f3082a136253e3a0eae0784e3091d138915c8
Reviewed-on: http://gerrit.rockbox.org/566
Reviewed-by: Michael Sevakis <jethead71@rockbox.org>
Tested: Michael Sevakis <jethead71@rockbox.org>
