Target that have a touchpad/touchscreen should disable it while
being locked (In order to avoid LCD to drain battery power due to
"key locked" constant reporting messages. If they a have a keylock
button this was already handled at driver level. If not (e.g. fuze+),
they will have to implement a switch at driver level that action.c
can operate on softlock.
This patch does the following for any target having a touchpad
or a touchscreen and no HAS_BUTTON_HOLD (ie any softlock target)
1) it implements the code to call button_enable_touch(bool en) in
action.c.
2) button_enable_touch is implemented in button.c and call
either touchpad_enable or touchscreen_enable
3) those two function are implemented respectively in touchscreen.c
and a new touchpad.c file. They provide a generic way to silents touch's
device and call a function at driver level where target specific code
can be implemented if possible/needed (for power saving for instance).
Those function name are touchpad_enable_device and touchscreen_enable_device
4) we implement an empty function at driver level of targets that need it
to have them still being able to compiled.
Change-Id: I9ead78a25bd33466a8533f5b9f259b395cb5ce49
Reviewed-on: http://gerrit.rockbox.org/569
Reviewed-by: Thomas Martitz <kugel@rockbox.org>
Reviewed-by: Amaury Pouly <amaury.pouly@gmail.com>
- take advantage of the new rmi power function implemented to:
1) lower usual power_mode to low_power as it seems to be enough and might save
some battery
2) implement a system that lower that state to very_low_power
after 1 minute of inactivity.
3) implement touchdev_enable(bool) that can be use later to disable the
touchpad when needed
4) improve the debug screen report of the current power state and
changing the power state using volume keys
Change-Id: I0b372696d4b2bef5360c778d0500870fd9badee1
Reviewed-on: http://gerrit.rockbox.org/525
Reviewed-by: Amaury Pouly <amaury.pouly@gmail.com>
The lcd data line were not setup as input anymore, making register
reading plain broken and probably lead to bad lcd detection.
Change-Id: I281460f845537c58045f3893261ded5c9c6e53b5
Factorise pin setup, rewrite PIO code, add support for lcdif irq,
handle all the various differences between the stmps, drop yuv
blitting code since it already exists in the common lcd drivers.
Change-Id: Ifc40aed9b3b12f16611ce960602e46a5bc87ae53
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
The current pinctrl functions were a mess. Normalise the functions
names to make them shorter and clearer.
Change-Id: Iac6ff84625ef2b7610268e3a5802dc0088de3167
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 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
I successfully identified the STC/RDS pin as B2P27.
Strangely the OF uses polling instead of interrupts
but since they routed it, let's use it! On the fuze+
the fmradio i2c uses bit toggling so we can't read
the RDS data in the interrupt context. Instead we
defer the work to a thread.
Change-Id: Iedfa425320e6c91b4351b72e97c732696bdb2b73
Reviewed-on: http://gerrit.rockbox.org/236
Reviewed-by: Bertrik Sikken <bertrik@sikken.nl>
Reviewed-by: Amaury Pouly <amaury.pouly@gmail.com>
Past development has proved that one can mistakely use
the same pin for two uses without noticing. Since this
causes extremely hard to find bugs, the infrastructure
will allow to register pin uses and panic when a conflict
is detected. The pinctrl debug now shows the pin uses
when its support is compiled in.
Change-Id: Idb2d5235ce09207d77aa474d6f158e72b933761a
Rework code to be more useful:
- move battery channel init to lradc
- always init lradc from system (previously from adc)
- don't reserve channels for vddio, nmos or pmos
- implement external temperature sensing using current source
- use this for battery sensing on the Fuze+ (calibration needed)
Change-Id: I5f9a24b9243db7d1e6bdb16b84bc891e61d0c318
imx233: always divide physical channels by two for wider range
The Fuze+ OF monitors channel 2 but I'm unable to determine the meaning of it.
Print the value on the debug menu so that people can have a look at it.
Change-Id: I8a942febeafbce06014178abda12e38a16c26664
Only enable fmradio_i2c once with _init() called from system.
Move actual i2c init to system for consistency.
Move tuner power pin setup to power instead of fmradio.
Change-Id: Idb56bfba5803f71b5d049f174c48d2afb969a6ea
Change all lcd drivers to using a pointer to the static framebuffer
instead of directly accessing the static array. This will let us
later do fun things like dynamic framebuffer sizes (RaaA) or
ability to use different buffers for different layers (dynamic
skin backdrops!)
Change-Id: I0a4d58a9d7b55e6c932131b929e5d4c9f9414b06
The headphone volume register value reads differently in Line1 and DAC mode.
Since the volume is not set again when switching between playback and radio,
we need to remember the hp volume and reapply setting when changing the mode.
Change-Id: I8fbd344f78653c19d81a39dd3f680ec6885cb1ec
Now lcd_framebuffer is the only framebuffer in the system. We still use a ARM-buffered buffer
which serve as an intermediate buffer for copying, to accomodate the requirement of the controller.
We implement lcd_update_rect() properly using this new scheme (this requires two little quirks),
this allows to implement lcd_blit_yuv with the right semantic (bypasses the framebuffer). YUV to RGB
conversion is still done in software but the DCP CSC should be able to do that but the hardware rotation
scheme is not the same as our software so it will require some tricks.
Change-Id: I0752e9c2f1a705d2e6a6010084e1f150965d8370
