- 29 Dec, 2008 12 commits
-
-
Russell King authored
Merge branch 'for-rmk' of git://git.kernel.org/pub/scm/linux/kernel/git/ycmiao/pxa-linux-2.6 into devel
-
Eric Miao authored
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 authored
Signed-off-by:
Eric Miao <eric.miao@marvell.com> Signed-off-by:
Eric Miao <ycmiao@ycmiao-hp520.(none)>
-
Eric Miao authored
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 authored
Add the palette format support for LCCR4_PAL_FOR_3, and fix the issue of LCCR4 being never assigned. Also remove the useless pxafb_set_truecolor(). Signed-off-by:
Eric Miao <eric.miao@marvell.com> Signed-off-by:
Eric Miao <ycmiao@ycmiao-hp520.(none)>
-
Eric Miao authored
dma branching is enabled by extending the current setup_frame_dma() function to allow a 2nd set of frame/palette dma descriptors to be used. As a result, pxafb_dma_buff.dma_desc[], pxafb_dma_buff.pal_desc[] and pxafb_info.fdadr[] are doubled. This allows maximum re-use of the current dma setup code, although the pxafb_info.fdadr[xx] for FBRx register values looks a bit odd. Signed-off-by:
Eric Miao <eric.miao@marvell.com> Signed-off-by:
Eric Miao <ycmiao@ycmiao-hp520.(none)>
-
Eric Miao authored
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 authored
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 authored
Signed-off-by:
Eric Miao <eric.miao@marvell.com>
-
Eric Miao authored
See description of commit: [ARM] rtc-sa1100: don't assume CLOCK_TICK_RATE to be a constant for additional information. Signed-off-by:
Eric Miao <eric.miao@marvell.com>
-
Eric Miao authored
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>
-
Eric Miao authored
Signed-off-by:
Eric Miao <eric.miao@marvell.com>
-
- 25 Dec, 2008 2 commits
-
-
-
Ian Molton authored
Signed-off-by:
Ian Molton <ian@mnementh.co.uk>
-
- 23 Dec, 2008 2 commits
-
-
wanzongshun authored
The patch is for w90p910 platform default config. Signed-off-by:
Wan ZongShun <mcuos.com@gmail.com> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk>
-
Russell King authored
Merge branch 'for-rmk' of git://git.kernel.org/pub/scm/linux/kernel/git/ycmiao/pxa-linux-2.6 into devel Conflicts: arch/arm/mach-pxa/am200epd.c arch/arm/mach-pxa/ezx.c
-
- 21 Dec, 2008 1 commit
-
-
Russell King authored
This avoids non-Samsung builds being asked about Samsung specific configuration options. Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk>
-
- 20 Dec, 2008 5 commits
-
-
git://git.marvell.com/orionRussell King authored
-
Lennert Buytenhek authored
Signed-off-by:
Lennert Buytenhek <buytenh@marvell.com> Signed-off-by:
Nicolas Pitre <nico@marvell.com>
-
Lennert Buytenhek authored
Signed-off-by:
Lennert Buytenhek <buytenh@marvell.com> Signed-off-by:
Nicolas Pitre <nico@marvell.com>
-
Lennert Buytenhek authored
Split off Orion GPIO IRQ handling code into plat-orion/. Signed-off-by:
Lennert Buytenhek <buytenh@marvell.com> Signed-off-by:
Nicolas Pitre <nico@marvell.com>
-
Lennert Buytenhek authored
Split off Orion GPIO handling code into plat-orion/, and add support for multiple sets of (32) GPIO pins. Signed-off-by:
Lennert Buytenhek <buytenh@marvell.com> Signed-off-by:
Nicolas Pitre <nico@marvell.com>
-
- 19 Dec, 2008 1 commit
-
-
- 18 Dec, 2008 17 commits
-
-
Russell King authored
as per 0560cf5aSigned-off-by:
Russell King <rmk+kernel@arm.linux.org.uk>
-
-
-
Ben Dooks authored
Select CPU_V6 with the S3C64XX series. Signed-off-by:
Ben Dooks <ben-linux@fluff.org>
-
Ben Dooks authored
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 authored
As per Russell King's last review comment, find and remove all unnecessary includes of <linux/delay.h> in the files that do not need them. Signed-off-by:
Ben Dooks <ben-linux@fluff.org>
-
Ben Dooks authored
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. Signed-off-by:
Ben Dooks <ben-linux@fluff.org>
-
Ben Dooks authored
As noted by Russell King, do not print any warnings if the uinfo or tty fields are not set when a CPU frequency change is sent. Signed-off-by:
Ben Dooks <ben-linux@fluff.org>
-
Ben Dooks authored
The changes for ARM highmem support have removed the need for the __virt_to_bus and __bus_to_virt macros, so remove them from this build. Signed-off-by:
Ben Dooks <ben-linux@fluff.org>
-
Ben Dooks authored
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. Signed-off-by:
Ben Dooks <ben-linux@fluff.org>
-
Ben Dooks authored
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 Signed-off-by:
Ben Dooks <ben-linux@fluff.org>
-
Ben Dooks authored
Update the serial driver to handle the 4 ports of the S3C2443 and S364XX series. Signed-off-by:
Ben Dooks <ben-linux@fluff.org>
-
Ben Dooks authored
Conflicts: arch/arm/mach-s3c2440/mach-at2440evb.c
-
Sascha Hauer authored
Instead of including other header files, define PHYS_OFFSET directly Signed-off-by:
Sascha Hauer <s.hauer@pengutronix.de>
-
Sascha Hauer authored
Instead of including other header files, define CLOCK_TICK_RATE directly Signed-off-by:
Sascha Hauer <s.hauer@pengutronix.de>
-
Sascha Hauer authored
This patch removes the inclusion of mach/hardware.h from mach/irqs.h and switches to more meaningful names for the irq related macros. Signed-off-by:
Sascha Hauer <s.hauer@pengutronix.de>
-
Sascha Hauer authored
This patch adds a missing call to local_irq_restore() and fixes some compiler warnings about unused variables for MX1. Signed-off-by:
Sascha Hauer <s.hauer@pengutronix.de>
-