The build of bootloader with HAVE_ATA_DMA fails because of missing
commit_discard_dcache(). This seems to be bigger problem as
bootloader builds don't call cache_init() also which seems wrong.
but I know too little about the PP platform to judge.
For now use ATA DMA only in regular builds.
Change-Id: I82873cb1771f5a95ebfbef91ce26744e3abd743c
PP502x ATA DMA was disabled in 55fab77 because it caused various
instability on all targets using it. This instability is fixed in
583c948 via FS#12391. Here, ATA DMA is enabled for all PP502x targets
except nano1g and hdd6330. For nano1g, there may be other causes of
instability and more testing is needed. ATA DMA does not work on hdd6330.
Change-Id: I786b9edb19e74e6eb957ab205ea026f0969200ac
Reviewed-on: http://gerrit.rockbox.org/340
Tested-by: David Hooper <dave@beermex.com>
Tested-by: Boris Gjenero <boris.gjenero@gmail.com>
Reviewed-by: Szymon Dziok <b0hoon@o2.pl>
Tested-by: Szymon Dziok <b0hoon@o2.pl>
Reviewed-by: Marcin Bukat <marcin.bukat@gmail.com>
In commit_discard_idcache(), cache lines were marked as invalid. When
some cache lines are marked as invalid, memory corruption can occur.
This caused instability when using PP502x ATA DMA because of the many
more calls to that function. Here, commit_discard_idcache() is changed
to avoid the problem. Also, the cache is filled after being enabled to
to ensure there are never any cache lines that aren't marked as valid.
Change-Id: Ia26300acef6b0573c1f40299c496ee5cbda3dac8
Reviewed-on: http://gerrit.rockbox.org/339
Reviewed-by: Szymon Dziok <b0hoon@o2.pl>
Tested-by: Szymon Dziok <b0hoon@o2.pl>
Reviewed-by: Marcin Bukat <marcin.bukat@gmail.com>
The SD driver doesn't initialised drives at the beginning but
upon request to handle removable drives. Since means that the
init should call init_drive() and not init_sd_card() otherwise
the check for WINDOW flag is bypasses. This breaks the zenxfi3
bootloader and has been overlooked for some time.
Change-Id: I7325f7164d16d7e7e54eeb4645e98517a08e0836
Move to a table based approach (scales better) and distinguish
between upward changes (increase frequency) and downward changes
(decrease frequency). This provides a better ordering of
operations and in particular it allows to avoid changing the
regulator while running at low speed since it takes a long time !
This should result in a much smoother scaling.
Change-Id: Iad7e5b61277e215f31c07877fbbad07ddde1171f
For some reason it is the responsability of the driver to send
this event so do it. This might fix some non-updating screens.
Change-Id: Ib5fdc94bf266c3497a8ac4e89d0418c0e876ff9f
The lcd kind is always set to st7783 in case we can't read the ID
so don't bother handling impossible cases
Change-Id: I352fd43b26068b460e69190d37c4cd4627e1db9a
The flip and invert settings can potentially be reset to their
value accross a disable/enable cycle, so save the value of the
impacted registers and apply it after each enable. Also avoid
poking registers when the lcd is not on.
Change-Id: Ica98f166c060aade7eb205f5628b58aae692024f
When chaging the cpu and memory frequency we need to disable the
external memory interface (EMI) for a small time. This can
underflow the dma and cause some breakage. Hopefully the SSP
controller handles this gracefully by stopping the clock and the
I2C probably handles this naturally because the clock can be
streched anyway. However the LCDIF has a special setting for this
which needs to be enable, otherwise it will send garbage to the
LCD. No other block is known to suffer from this currently but
this issue might have more unexpected consequences.
Change-Id: Ide154cad87929f2bf6cc419ac1d2ff33e30eec66
The manual recommands to tweak the arm cache settings on frequency
changes. The meaning of these values is undocumented but 0 seems
to be a safe value for all frequencies whereas 3 seems to be valid
only for low frequencies (<=64MHz ?)
Change-Id: Iaa8db4af8191010789cf986b1139ff259d73e2ed
CPU frequency scaling is basically useless without scaling the
memory frequency. On the i.MX233, the EMI (external memory
interface) and DRAM blocks are responsable for the DDR settings.
This commits implements emi frequency scaling. Only some settings
are implemented and the timings values only apply to mDDR
(extracted from Sigmatel linux port) and have been checked to
work on the Fuze+ and Zen X-Fi2/3. This feature is still disabled
by default but I expected some battery life savings by boosting
higher to 454MHz and unboosting lower to 64MHz.
Note that changing the emi frequency is particularly tricky and
to avoid writing it entirely in assembly we rely on the compiler
to not use the stack except in the prolog and epilog (because
it's in dram which is disabled when doing the change) and to put
constant pools in iram which should always be true if the
compiler isn't completely dumb and since the code itself is put
in iram. If this proves to be insufficient, one can always switch
the stack to the irq stack since interrupts are disabled during
the change.
Change-Id: If6ef5357f7ff091130ca1063e48536c6028f23ba
pcm_dma_apply_settings(): sets the configured PCM frequency,
all native CS42L55 sample rates are available.
Change-Id: I2fcd5581457a669c3044516804cb64fb972218d0
Actually Rockbox does not use this mode, it is supported by
other iPods, so implemented on Classic as well.
Change-Id: Ia6578506df27a95a7f7522b3034b764631a8bb3a
Scale battery voltage ADC readings by 1023 instead of 1000,
using ADC1 (substractor) instead of ADC0 (multiplicator) to
get better resolution.
Percent charge/discharge tables are also modified to return
a similar value than the old ones.
Change-Id: I2951c75faa02f4302599ec24f9156cfd209c36eb
Fixes missing Settings - General Settings - System - Disk - Spindown
setting.
Change-Id: Iae686598dfd7ad4ca1faf8db9f1271e7808de752
Reviewed-on: http://gerrit.rockbox.org/376
Reviewed-by: Michael Giacomelli <giac2000@hotmail.com>
Tested-by: Michael Giacomelli <giac2000@hotmail.com>
On heavy storage operations (like database update), the ssp dma
irq can be fired around ~10000/sec.
Change-Id: I0e33df6258e051abd4fe110a0f408a19671cd8ad
Do low level power init in system_init(). This can be needed
since imx233 must be able to frequecy scale atfer system_init()
and kernel_init() and this is only possible if power system was
initialised.
Change-Id: I27c66ec0dccd60bda26a45be24683c0bfe72c6da
The current code uses the msec irq to collect statistics and
detect irq storms (debug). But this irq is triggered 1000 times
per sec and we don't need that accuracy. This commit removes the
msec irq and use the tick timer instead which is triggered only
100 times per second.
Change-Id: If14b9503c89a3af370ef322678f10e35fafb4b8a
The lcd driver does not wait for the refresh to be done to return
from lcd_update(). This means that changing a register is unsafe
if done in the middle of the redraw. This could happen when
disabling the lcd for example. Make sure it doesn't happen by
waiting for the lcdif to be ready.
Change-Id: I43ec62a637dd61c3b2a3a6e131c1a9e8035524b1
When changing the cpu frequency, it is important to make sure that
HBUS stays at a reasonable frequency otherwise the chip will
crash. Special care is needed about auto-slow and clk_p/clk_h
ratio on intermediate steps.
Change-Id: Ief9f68ddf286caabe75c879718dac5027ab1560f
Make sure DCDC is running at boot (it is disabled by default when
5V is present and we don't want to rely on the bootloader to
change this).
When changing the voltage on a regulator, it usually takes 2ms for
the voltage to stabilize. In DCDC mode, there is an irq to notify
about the event so use it ! This is especially important when
changing cpu frequency because increasing the cpu freq while the
voltage is rising is unreliable.
Change-Id: Icfe9ef3ee90156d1e17da0820d9041859f7f3bca
HBUS uses the same field for integer and fractional dividers, the
choice is made by a bit. Make sure both are changed together,
otherwise this could result in the wrong divider to be used and in
HBUS freq to be too low or too high (very bad).
Change-Id: I253d8eeee26c5038868b729c4f791511295a39f0
Use %x9(id) to draw an image in the whole current viewport using the
9 segment drawer (which draws the corners as normal and *tiles*
the middle segments to the needed width/height).
Future work is to make it scale instead of tile
Change-Id: Ic3ed1cad93f96091694801eb442e0da5a2401203
Some USB controllers like the one of the Rockchip 27xx handle some
requests in pure hardware. This is especially a problem for two
of them:
- SET ADDR which is used by our core to track the DEFAULT/ADDRESS
state and is required for the drivers to work properly
- SET CONFIG which is used by our core to initialise the drivers
by calling init_connection()
In these cases we need a way to notify the core that such requests
happened.
We do this by exporting two functions which directly notify the
core about these requests and perform the necessary init steps
required without doing the actual USB transfers. Special care is
needed because these functions could be called from an interrupt
handler. For this reason we still use the usb_queue and introduce
new IDs so that they are processed in order and safely.
No functional change is intended, both in the usbstack and on
targets without such quirks.
Change-Id: Ie42feffd4584e88bf37cff018b627f333dca1140
* Adds some additional niftyness like a floating popup display that
is implemented in an OSD library for use by other plugins.
* Speed changes are now gradual for both views and follow a curve
derived from some fiddling around to get a nice feel.
* Refined a few behavioral things overall.
It needs a bit of help from a direct PCM channel callback so it may
capture PCM for waveform display. Also need a few other core routines
to help out for the OSD.
Messes with some keymaps. Some targets need keymaps to access the
different views. Some devices can't support the additional view
because it requires a large buffer ( > 1 s) for samples.
If the plugin buffer is small, they can still use the popup display
since the plugin is also much smaller in that case.
Slow speed waveform needs some refining so it draws gradually like
a real oscilloscope but I'll stick with what it is, for the moment.
Change-Id: Ieb5b7922a2238264e9b19a58cb437739194eb036
Reviewed-on: http://gerrit.rockbox.org/245
Reviewed-by: Michael Sevakis <jethead71@rockbox.org>
Tested-by: Michael Sevakis <jethead71@rockbox.org>
Ideally someone will go through and make a graphic for the 6G, but as it looks nearly identical to the Video its not a huge deal.
Change-Id: If507c6d4f01eb0b1e5fc2f15f6a0e5a3195006c6
