Eric Miao [Tue, 23 Dec 2008 09:49:43 +0000 (17:49 +0800)]
[ARM] pxafb: add support for overlay1 and overlay2 as framebuffer devices
PXA27x and later processors support overlay1 and overlay2 on-top of the
base framebuffer (although under-neath the base is also possible). They
support palette and no-palette RGB formats, as well as YUV formats (only
available on overlay2). These overlays have dedicated DMA channels and
behave in a similar way as a framebuffer.
This heavily simplified and re-structured work is based on the original
pxafb_overlay.c (which is pending for mainline merge for a long time).
The major problems with this pxafb_overlay.c are (if you are interested
in the history):
1. heavily redundant (the control logics for overlay1 and overlay2 are
actually identical except for some small operations, which are now
abstracted into a 'pxafb_layer_ops' structure)
2. a lot of useless and un-tested code (two workarounds which are now
fixed on mature silicons)
3. cursorfb is actually useless, hardware cursor should not be used
this way, and the code was actually un-tested for a long time.
The code in this patch should be self-explanatory, I tried to add minimum
comments. As said, this is basically simplified, there are several things
still on the pending list:
1. palette mode is un-supported and un-tested (although re-using the
palette code of the base framebuffer is actually very easy now with
previous clean-up patches)
2. fb_pan_display for overlay(s) is un-supported
3. the base framebuffer can actually be abstracted by 'pxafb_layer' as
well, which will help further re-use of the code and keep a better
and consistent structure. (This is the reason I named it 'pxafb_layer'
instead of 'pxafb_overlay' or something alike)
See Documentation/fb/pxafb.txt for additional usage information.
Signed-off-by: Eric Miao <eric.miao@marvell.com> Cc: Rodolfo Giometti <giometti@linux.it> Signed-off-by: Eric Miao <ycmiao@ycmiao-hp520.(none)>
Eric Miao [Thu, 18 Dec 2008 14:36:26 +0000 (22:36 +0800)]
[ARM] pxafb: cleanup of the color format manipulation code
1. introduce var_to_depth() to calculate the color depth including the
transparency bit
2. the conversion from 'fb_var_screeninfo' to LCCR3 BPP bits can be re-
used by overlays (in OVLxC1), thus an individual pxafb_var_to_bpp()
has been separated out.
3. pxafb_setmode() should really set the color bitfields correctly at
begining, introduce a pxafb_set_pixfmt() for this
4. allow user apps to specify color formats within fb_var_screeninfo,
and checking of this in pxafb_check_var() has been simplified as
below:
a) pxafb_var_to_bpp() should pass - which means a basically correct
bits_per_pixel and color depth setting
b) the RGBT bitfields are then forced into supported values by
pxafb_set_pixfmt()
Signed-off-by: Eric Miao <eric.miao@marvell.com> Signed-off-by: Eric Miao <ycmiao@ycmiao-hp520.(none)>
Eric Miao [Wed, 17 Dec 2008 06:56:54 +0000 (14:56 +0800)]
[ARM] pxafb: allow pxafb_set_par() to start from arbitrary yoffset
Note the var->yres_virtual is only re-calculated from the fix.smem_len
when text mode acceleration is enabled (which is default), this is due
to the issue as Russell suggested below:
Previous experience of doing this with the X server and acornfb is that
it causes all sorts of problems - it seems to force the X server into
assuming that the framebuffer should be panned no matter what settings
you ask it for.
The recommended workaround (implemented in acornfb) is to only do these
kinds of adjustments if text mode acceleration is enabled. IIRC, the X
server should be disabling text mode acceleration when it maps the
framebuffer. I seem to remember that there are X servers which forget
to do that though.
Signed-off-by: Eric Miao <eric.miao@marvell.com> Signed-off-by: Eric Miao <ycmiao@ycmiao-hp520.(none)>
Eric Miao [Tue, 16 Dec 2008 03:54:34 +0000 (11:54 +0800)]
[ARM] pxafb: allow video memory size to be configurable
The amount of video memory size is decided according to the following
order:
1. <xres> x <yres> x <bits_per_pixel> by default, which is the backward
compatible way
2. size specified in platform data
3. size specified in module parameter 'options' string or specified in
kernel boot command line (see updated Documentation/fb/pxafb.txt)
And now since the memory is allocated from system memory, the pxafb_mmap
can be removed and the default fb_mmap() should be working all right.
Also, since we now have introduced the 'struct pxafb_dma_buff' for DMA
descriptors and palettes, the allocation can be separated cleanly.
NOTE: the LCD DMA actually supports chained transfer (i.e. page-based
transfers), to simplify the logic and keep the performance (with less
TLB misses when accessing from memory mapped user space), the memory
is allocated by alloc_pages_*() to ensures it's physical contiguous.
Signed-off-by: Eric Miao <eric.miao@marvell.com> Signed-off-by: Eric Miao <ycmiao@ycmiao-hp520.(none)>
Eric Miao [Thu, 18 Dec 2008 03:10:32 +0000 (11:10 +0800)]
[ARM] rtc-sa1100: don't assume CLOCK_TICK_RATE to be a constant
As Nicolas and Russell pointed out, CLOCK_TICK_RATE is no more
a constant on PXA when multiple processors and platforms are
selected, change TIMER_FREQ in rtc-sa1100.c into a variable.
Since the code to decide the clock tick rate is re-used from
timer.c, introduce a common get_clock_tick_rate() for this.
Signed-off-by: Eric Miao <eric.miao@marvell.com> Acked-by: Nicolas Pitre <nico@marvell.com>
Ben Dooks [Thu, 18 Dec 2008 11:26:54 +0000 (12:26 +0100)]
[ARM] 5349/1: VFP: Add PM code to save and restore current VFP state
When CONFIG_PM is selected, the VFP code does not have any handler
installed to deal with either saving the VFP state of the current
task, nor does it do anything to try and restore the VFP after a
resume.
On resume, the VFP will have been reset and the co-processor access
control registers are in an indeterminate state (very probably the
CP10 and CP11 the VFP uses will have been disabled by the ARM core
reset). When this happens, resume will break as soon as it tries to
unfreeze the tasks and restart scheduling.
Add a sys device to allow us to hook the suspend call to save the
current thread state if the thread is using VFP and a resume hook
which restores the CP10/CP11 access and ensures the VFP is disabled
so that the lazy swapping will take place on next access.
Signed-off-by: Ben Dooks <ben-linux@fluff.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Ben Dooks [Sun, 14 Dec 2008 22:50:26 +0000 (22:50 +0000)]
[ARM] S3C24A0: Remove duplicate <mach/io.h> file
The commit 39263db7986bf15c753f6847699107bdf5a2e318 added
a default <mach/io.h> implementation which is shared if
needed between all the s3c implementations. Remove the
s3c24a0 version which is the same as this.
Ben Dooks [Tue, 4 Nov 2008 15:29:09 +0000 (15:29 +0000)]
[ARM] S3C24XX: Add fourth UART definition for S3C2443
Add the fourth UART definition for the S3C2443, and at the
same time fixup the problems caused by the enlarging of the
UART array in the previous commits.
Fix the usage of CONFIG_SERIAL_SAMSUNG_UARTS in several places
in the kernel where it had been missed. This finishes fixing a
long standing issue where S3C2443 and S3C64XX could not use the
4th UART
Jonathan Cameron [Fri, 12 Dec 2008 20:43:09 +0000 (20:43 +0000)]
[ARM] pxa: initial support for the Imote2 platform
Changes made as suggested by Eric Miao (including fix to map_io
silly mistake!).
Originally designed by Intel, now sold by Crossbow (www.xbow.com).
Very little actually on board. The patch includes sensors and
similar as found on commonly occurring daughter boards.
Some of the drivers are not in mainline as yet as they are either
part of the IIO subsystem or need a lot of work before submission.
What is the position wrt to putting them in i2c board configs etc?
Support for these boards has been maintained outside the kernel
for a long time, but now that there is a good da9030 pmic driver
available the last major hurdle no longer exists.
All comments welcomed.
The Imote2's big brother (stargate2) will follow once any problems
with this one have been cleaned up and a few bits and bobs have
been added to the da903x driver. Hopefully the cc2420 driver will
get cleaned up and submitted in the not too distant future as
well.
Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Eric Miao <eric.miao@marvell.com>
Stefan Schmidt [Mon, 8 Dec 2008 14:58:10 +0000 (15:58 +0100)]
[ARM] pxa/ezx: I2C configuration
I2C platform data setups.
Signed-off-by: Daniel Ribeiro <drwyrm@gmail.com> Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org> Signed-off-by: Eric Miao <eric.miao@marvell.com>
Stefan Schmidt [Mon, 8 Dec 2008 14:58:09 +0000 (15:58 +0100)]
[ARM] pxa/ezx: Keypad configuration
Matrix and single key setups for all phones.
Signed-off-by: Daniel Ribeiro <drwyrm@gmail.com> Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org> Signed-off-by: Antonio Ospite <ospite@studenti.unina.it> Signed-off-by: Eric Miao <eric.miao@marvell.com>
Stefan Schmidt [Mon, 8 Dec 2008 14:58:08 +0000 (15:58 +0100)]
[ARM] pxa/ezx: GPIO configuration
Pin configs for different generations and phones.
Signed-off-by: Daniel Ribeiro <drwyrm@gmail.com> Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org> Signed-off-by: Eric Miao <eric.miao@marvell.com>
Stefan Schmidt [Mon, 8 Dec 2008 14:58:07 +0000 (15:58 +0100)]
[ARM] pxa/ezx: Remove two memory banks fixup
Our bootloader now supports ATAGS_MEM
Signed-off-by: Daniel Ribeiro <drwyrm@gmail.com> Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org> Signed-off-by: Eric Miao <eric.miao@marvell.com>
Eric Miao [Mon, 8 Dec 2008 10:51:01 +0000 (18:51 +0800)]
[ARM] pxafb: avoid the racing condition in pxafb_smart_thread
fbi->state change shall really be protected by fbi->ctrlr_lock, where
the change is sheltered. There is a possibility that pxafb_smart_thread
will start update the LCD panel when fbi->state == C_ENABLE, while
all other initialization isn't done.
Eric Miao [Mon, 8 Dec 2008 10:46:00 +0000 (18:46 +0800)]
[ARM] pxafb: allow insertion of delay to the smart panel command sequence
Some smart panel requires a delay between command sequences, while PXA
LCD controller didn't provide such one, let's emulate this by software.
A software delay marker can be inserted into the command sequence, once
pxafb_smart_queue() detects this, it flushes the previous commands and
delay for a specified number of milliseconds.
Juergen Beisert [Tue, 16 Dec 2008 10:44:07 +0000 (11:44 +0100)]
i.MX Framebuffer: Use readl/writel instead of direct pointer deref
This patch prepares the current i.MX1 framebuffer driver for usage in the
whole i.MX family. It switches to readl/writel for register accesses.
Also it moves the register definitions to the driver where they belong.
Acked-by: Krzysztof Helt <krzysztof.h1@poczta.fm> Signed-off-by: Juergen Beisert <j.beisert@pengutronix.de> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Sascha Hauer [Tue, 16 Dec 2008 10:44:07 +0000 (11:44 +0100)]
i.MX Framebuffer: remove gpio setup function
Remove the gpio mux setup function from i.MX framebuffer driver.
This function is platform specific and thus should be done by
the board setup. As there are currently no in-kernel users
of this driver we do not break anything.
Acked-by: Krzysztof Helt <krzysztof.h1@poczta.fm> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Sascha Hauer [Sun, 23 Nov 2008 16:31:46 +0000 (17:31 +0100)]
pcm038: add driver for static ram
The pcm038 module (phyCORE-i.MX27) comes with a 512 KiB static RAM which
can be battery buffered. Add mtd_ram support and configure the chip select
line, to which the sram is attached.
Signed-off-by: Luotao Fu <l.fu@pengutronix.de> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
projects / linux-2.6-omap-h63xx.git / log