The current pwm interface is too low-level. Introduce a higher
level setup function which directly computes the parameters from
the required frequency.
Change-Id: Ie95c7522e9f42492fe872203f4cab46770a9649a
The clkctrl functions were becoming a mess. Normalise the names,
get rid of the xtal derived as special case and use the same
interface.
Change-Id: Ib954a8d30a6bd691914b5e0d97774ec9fc560c50
A number of pins on the imx233 are standard and manually calling
functions to acquire, set function/drive/output is painful. This
will become unmanageable when we will add support for the other
stmp chips.
Introduce the concept of virtual pin which is a way to completely
describe a virtual pin (virtual because pins are muxed).
Change-Id: I01b6e040945648e58e1d1abab06529c9571c5f10
The current pinctrl functions were a mess. Normalise the functions
names to make them shorter and clearer.
Change-Id: Iac6ff84625ef2b7610268e3a5802dc0088de3167
The SD SWITCH command has a result and can take a long time to
finish. Ignoring the answer and waiting an arbitrary time is
unreliable at best.
Change-Id: I1bfbb193952b96598f8bb056bac88220d4edf1fc
Register set selection is based on the value of the
IMX233_SUBTARGET value. The reg-select.h file (used by the
generated headers), does the selection based on this value as
follows:
- 3600 <= . < 3700: stmp3600 register set
- 3700 <= . < 3780: stmp3700 register set
- 3780 <= .: imx233 register set
Note that this selector relies on the name of the socs in the
register description to be respectively stmp3600, stmp3700 and
imx233.
Change-Id: I793b18e6c4f3fea85aa74f4c6be3affb0622c14e
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
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
The running count is only 16-bit wide, since the always tick
setting derives from the crystal clock at 24MHz the user timer
cannot be set lower than ~300Hz which is already too high.
Switch to the 32KHz crystal source to fix this.
Change-Id: Ie7775460b17ea7ab331738734e3d688ad5563857
Frequency scaling seems to be unstable and causes the device to
freeze. It is unclear why at the moment, perhaps we need to ramp
up the vddd voltage to avoid a false brownout ?
Change-Id: I7aaea9d7c213922a65250fe50775fb785d430226
This does not scale the EMI frequency and keep the processor
betweel 261MHz and 454MHz. It can still be improve. The auto-slow
divisor could still be change, 8 seems reasonable for now
Change-Id: I639bb3f6b7f8efedc7dc58d08127849156eeb1b6
Remove the old debug stuff about VDDx and add a clean api to
get/set the regulator (VDDD, VDDA, VDDIO, VDDMEM). This is useful
for proper frequency scaling.
Change-Id: Ia5a1a712fd66652a8ad9601ed00db31aba5a7561
Implement cache aligned transfer of more than one sectors. The
current code now transfers almost all data at once by moving
it within the buffer to make it cache aligned. This greatly
improves the performance of the transfers, especially in mass
storage mode.
Change-Id: Ic6e78773302f368426209f6fd6099089ea34cb16
Further merge drivers by using the same command and data functions.
No use one mutex per drive instead of a global sd lock. Fix the
RCA handling which was different between SD and MMC (shifted 16)
and thus confusing. Add MMC commands definition to the mmc.h
header similarly to the SD one. Change MMC handling a bit by
selecting/deselecting on each transfer like SD, which allows
for several MMC devices in theory and is more uniform.
Change-Id: I7024cb19c079553806138ead75b00640f1d2d95c
Merge sd and mmc drivers into a single sdmmc driver. This allows
some factoring of the code and simplify bug fixing. Also fix the
dma/cache related issue by doing all transfers via a correctly
aligned buffer. The current code is not smart enough to take
advantage of large user buffers currently but at least it is safe!
Change-Id: Ib0fd16dc7d52ef7bfe99fd586e03ecf08691edcd
There are tricky DMA/cache related issue on the imx233 which could
pop up with the old driver. The new one ensures that all dma
tranfers are cache safe by using an intermediate buffer.
Change-Id: I72060682d1c285c83ae16455cfdb62f372b5d687
Reduce DMA maximum transfer size since transfering 64Kb requires
to set a size of 0 and it's not worth adding checks everywhere
to handle this special case. Also add statistics about unaligned
transfer (wrt to cache). Update debug screen accordingly and
simplify it so it can fit smaller screens too.
Change-Id: I18391702f5e100a21f6f8d1ebab28d9f2bd8c66f
Implement PLL enabling/disable and unconditionally power the PLL
on startup. This is needed at least on the Zen X-Fi2.
Change-Id: Ib9ddfdeaf973cedded4b3586dd16aa95a61e78ba
Because DMA descriptors needs to be committed and discarded from
the cache, if they are not cache aligned and/or if their size
is not a multiple of cache ligne, nasty side effects could occur
with adjacents data. The same applies to DMA buffers which are
still potentially broken. Add a macro to ensure that these
constraints will not break by error in the future.
Change-Id: I1dd69a5a9c29796c156d953eaa57c0d281e79846
