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
Massage the way it interfaces a bit to make things more flexible.
The chroma_buf scheme on Sansa Connect and Creative ZVx calling the
lcd_write_yuv420_lines implementation in lcd-as-memframe.S with five params
with a chroma buffer that the function can't use wouldn't work anyway so just
have them use the stock implementation (really, how was that working?).
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@31335 a1c6a512-1295-4272-9138-f99709370657
fuze+: reset the controller for all lcd types, should fix the "CRT effet"
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@31234 a1c6a512-1295-4272-9138-f99709370657
- now identity map dram uncached and have a cached and buffered virtual alias
- rework dma to handle virtual to physical pointers conversion
- fix lcd frame pointer
- implement usb detection properly
- implement bootloader usb properly
- allow the bootloader to disable MMC windowing (useful for recovery)
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@30432 a1c6a512-1295-4272-9138-f99709370657
