summaryrefslogtreecommitdiffstats
path: root/drivers/video/pxafb.h
Commit message (Collapse)AuthorAgeFilesLines
* video: move fbdev to drivers/video/fbdevTomi Valkeinen2014-04-171-200/+0
| | | | | | | | | | | | | | | | | | | | The drivers/video directory is a mess. It contains generic video related files, directories for backlight, console, linux logo, lots of fbdev device drivers, fbdev framework files. Make some order into the chaos by creating drivers/video/fbdev directory, and move all fbdev related files there. No functionality is changed, although I guess it is possible that some subtle Makefile build order related issue could be created by this patch. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Rob Clark <robdclark@gmail.com> Acked-by: Jingoo Han <jg1.han@samsung.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* ARM: pxafb: rework pxafb overlay memory managementVasily Khoruzhick2011-03-161-1/+2
| | | | | | | | | | | | | | | | | | | PXAFB overlay memory management is something messy: - it allocates memory dynamically on open/release, and it results in memory allocation failure after ~1h of uptime (system does not have 115k of physically contiguous memory) - in release callback it tries to free memory even if it was not allocated. Also driver touches FDADR1 on main plane reconfiguration, and it can cause problems if overlay1 is enabled. This patch attempts to fix those issues. Patch is based on Russell King's work. Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com> Signed-off-by: Eric Miao <eric.y.miao@gmail.com>
* [ARM] pxafb: add support for overlay1 and overlay2 as framebuffer devicesEric Miao2008-12-291-0/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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)>
* [ARM] pxafb: cleanup of the timing checking codeEric Miao2008-12-291-0/+6
| | | | | Signed-off-by: Eric Miao <eric.miao@marvell.com> Signed-off-by: Eric Miao <ycmiao@ycmiao-hp520.(none)>
* [ARM] pxafb: add support for FBIOPAN_DISPLAY by dma brachingEric Miao2008-12-291-3/+6
| | | | | | | | | | | | | | | 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)>
* [ARM] pxafb: allow video memory size to be configurableEric Miao2008-12-291-13/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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)>
* [ARM] pxafb: make {backlight,lcd}_power() members of struct pxafb_infoEric Miao2008-12-021-0/+3
| | | | | | | instead of holding them as static pointers. Signed-off-by: Daniel Mack <daniel@caiaq.de> Signed-off-by: Eric Miao <eric.miao@marvell.com>
* pxafb: convert ctrlr_sem in a mutexMatthias Kaehlcke2008-07-241-1/+1
| | | | | | | | | | | The semaphore ctrlr_sem is used as a mutex. Convert it to the mutex API. Signed-off-by: Matthias Kaehlcke <matthias@kaehlcke.net> Cc: Daniel Mack <daniel@caiaq.de> Cc: Eric Miao <eric.miao@marvell.com> Cc: Russell King <rmk@arm.linux.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* pxafb: preliminary smart panel interface supportEric Miao2008-04-301-0/+12
| | | | | | | | | Signed-off-by: Daniel Mack <daniel@caiaq.de> Signed-off-by: Eric Miao <eric.miao@marvell.com> Cc: "Antonino A. Daplas" <adaplas@pol.net> Cc: Russell King <rmk@arm.linux.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* pxafb: move parallel LCD timing setup into dedicate functionEric Miao2008-04-301-8/+0
| | | | | | | | | | | | | | | | the new_regs stuff has been removed, and all the setup (modification to those fbi->reg_*) is protected with IRQ disabled * disable IRQ is too heavy here, provided that no IRQ context will touch the fbi->reg_* and the only possible contending place is in the CPUFREQ_POSTCHANGE (task context), a mutex will be better, leave this for future improvement Signed-off-by: eric miao <eric.miao@marvell.com> Cc: "Antonino A. Daplas" <adaplas@pol.net> Cc: Russell King <rmk@arm.linux.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* pxafb: use completion for LCD disable wait codeEric Miao2008-04-301-0/+2
| | | | | | | | Signed-off-by: eric miao <eric.miao@marvell.com> Cc: "Antonino A. Daplas" <adaplas@pol.net> Cc: Russell King <rmk@arm.linux.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* pxafb: introduce "struct pxafb_dma_buff" for palette and dma descriptorseric miao2008-04-301-12/+34
| | | | | | | | | | | | | Use structure and array for palette buffer and dma descriptors to: 1. better organize code for future expansion like overlays 2. separate palette and dma descriptors from frame buffer Signed-off-by: eric miao <eric.miao@marvell.com> Cc: "Antonino A. Daplas" <adaplas@pol.net> Cc: Russell King <rmk@arm.linux.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* pxafb: convert fb driver to use ioremap() and __raw_{readl, writel}eric miao2008-04-301-0/+2
| | | | | | | | | | | | | | | | | | This is part of the effort moving peripheral registers outside of pxa-regs.h, and using ioremap() make it possible the same IP can be re-used on different processors with different registers space As a result, the fixed mapping in pxa_map_io() is removed. The regs-lcd.h can actually moved to where closer to pxafb.c but some of its bit definitions are directly used by various platform code, though this is not a good style. Signed-off-by: eric miao <eric.miao@marvell.com> Cc: "Antonino A. Daplas" <adaplas@pol.net> Cc: Russell King <rmk@arm.linux.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* pxafb: Add support for other palette formatsHans J. Koch2007-10-161-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | This patch adds support for the other three palette formats possible with the PXA LCD controller. This is required on boards where an LCD is connected with all its 18 bits. With this patch, it's possible to use an 8-bit mode with 18-bit palette entries. This used to be possible in 2.4 kernels but disappeared in 2.6. With current kernels, you can only get wrong colours out of an LCD connected this way. Users can choose the palette format by doing something like this in their board definition: static struct pxafb_mach_info my_fb_info = { [...] .lccr3 = LCCR3_OutEnH | LCCR3_PixFlEdg | LCCR3_PDFOR_3, .lccr4 = LCCR4_PAL_FOR_2, [...] }; Signed-off-by: Hans J. Koch <hjk@linutronix.de> Signed-off-by: Antonino Daplas <adaplas@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* [ARM] pxa: update pxafb to use clk supportRussell King2007-10-121-0/+1
| | | | Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* [ARM] 3848/1: pxafb: Add option of fixing video modes and spitz QVGA mode ↵Richard Purdie2006-10-021-4/+0
| | | | | | | | | | | | | | | | | | | support Add the ability to have pxafb use only certain fixed video modes (selected on a per platform basis). This is useful on production hardware such as the Zaurus cxx00 models where the valid modes are known in advance and any other modes could result in hardware damage. Following this, add support for the cxx00 QVGA mode. Mode information is passed to the lcd_power call to allowing the panel drivers to configure the display hardware accordingly (corgi_lcd already contains the functionality for the cxx00 panel). This mirrors the setup already used by w100fb. Signed-off-by: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* [ARM] pxafb: Remove #if DEBUG, convert DPRINTK to pr_debugRussell King2005-09-291-9/+0
| | | | | | | | | | | | | | Fix warning: drivers/video/pxafb.h:119:5: warning: "DEBUG" is not defined by removing the whole #if DEBUG #define DPRINTK(fmt, args...) printk...etc... #else #define DPRINTK(fmt, args...) #endif stuff - we have pr_debug() for this. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* [PATCH] pxafb: Add hsync time reporting hookRichard Purdie2005-09-091-0/+2
| | | | | | | | | | | To solve touchscreen interference problems devices like the Sharp Zaurus SL-C3000 need to know the length of the horitzontal sync pulses. This patch adds a hook to pxafb so the touchscreen driver can function correctly. Signed-Off-By: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Antonino Daplas <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds2005-04-161-0/+129
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
OpenPOWER on IntegriCloud