Some broken bootloaders will leave the DMA channel state unclean, which
we should really initialize correctly here.
Signed-off-by: Eric Miao <eric.miao@marvell.com>
The only exclusive definitions are SSCR0_SCR and SSCR0_SerClkDiv(), loosen
that exclusive #ifdef .. #else .. #endif to allow other definitions to be
visible when slected multiple processors. This helps to pass the building
of pxa-ssp.c.
Signed-off-by: Eric Miao <eric.miao@marvell.com>
After commit 8c3abc7d90
("[ARM] pxa: convert to clkdev and match clocks by struct device where possible")
get_clk in pxa3xx_nand fails with -ENOENT.
Apparently, clk_get in pxamci will also fail for MCI2 on PXA310.
The 'clk_find' and therefore 'clk_get' require driver to supply
both 'dev_id' and 'con_id' if they are not NULL in the 'strcut clk_lookup',
but neither pxa3xx_nand nor pxamci supply 'con_id'.
This patch sets 'con_id' to NULL in NAND clock and MCI2 clock registration.
Signed-off-by: Mike Rapoport <mike@compulab.co.il>
Signed-off-by: Eric Miao <eric.miao@marvell.com>
arch/arm/mach-at91/at91cap9.c:337: error: 'NR_AIC_IRQS' undeclared here (not in a function)
arch/arm/mach-at91/at91rm9200.c:301: error: 'NR_AIC_IRQS' undeclared here (not in a function)
arch/arm/mach-at91/at91sam9260.c:351: error: 'NR_AIC_IRQS' undeclared here (not in a function)
arch/arm/mach-at91/at91sam9261.c:287: error: 'NR_AIC_IRQS' undeclared here (not in a function)
arch/arm/mach-at91/at91sam9263.c:312: error: 'NR_AIC_IRQS' undeclared here (not in a function)
arch/arm/mach-at91/at91sam9rl.c:304: error: 'NR_AIC_IRQS' undeclared here (not in a function)
arch/arm/mach-h720x/h7202-eval.c:38: error: implicit declaration of function 'IRQ_CHAINED_GPIOB'
arch/arm/mach-ks8695/devices.c:46: error: 'KS8695_IRQ_WAN_RX_STATUS' undeclared here (not in a function)
arch/arm/mach-msm/devices.c:28: error: 'INT_UART1' undeclared here (not in a function)
arch/arm/mach-mx2/devices.c:233: error: 'MXC_GPIO_IRQ_START' undeclared here (not in a function)
arch/arm/mach-mx3/devices.c:128: error: 'MXC_GPIO_IRQ_START' undeclared here (not in a function)
arch/arm/mach-omap1/mcbsp.c:140: error: 'INT_730_McBSP1RX' undeclared here (not in a function)
arch/arm/mach-omap1/mcbsp.c:165: error: 'INT_McBSP1RX' undeclared here (not in a function)
arch/arm/mach-omap1/mcbsp.c:200: error: 'INT_McBSP1RX' undeclared here (not in a function)
arch/arm/mach-omap2/board-apollon.c:286: error: implicit declaration of function 'omap_set_gpio_direction'
arch/arm/mach-omap2/mcbsp.c:154: error: 'INT_24XX_MCBSP1_IRQ_RX' undeclared here (not in a function)
arch/arm/mach-omap2/mcbsp.c:181: error: 'INT_24XX_MCBSP1_IRQ_RX' undeclared here (not in a function)
arch/arm/mach-pxa/e350.c:36: error: 'IRQ_BOARD_START' undeclared here (not in a function)
arch/arm/plat-s3c/dev-i2c0.c:32: error: 'IRQ_IIC' undeclared here (not in a function)
...
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
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)>
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)>
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)>
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)>
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)>
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>
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>
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>
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>
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>
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>
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.
Signed-off-by: Eric Miao <eric.miao@marvell.com>
For smart panels (LCD panel with internal framebuffer), the following
LCCR3 register bits have different meanings than the parallel one:
LCCR3_PCP - controls the L_PCLK_WR polarity
LCCR3_HSP - controls the L_LCLK_A0 polarity
LCCR3_VSP - controls the L_FCLK_RD polarity
To keep minimum change to the original parallel timing, the .lcd_conn
flags and 'pxafb_mode_info.sync' are re-used to reflect this:
LCD_PCLK_EDGE_{RISE,FALL} - configures LCCR3_PCP
sync & FB_SYNC_{HOR,VERT}_HIGH_ACT - configures LCCR3_{HSP,VSP}
Signed-off-by: Eric Miao <eric.miao@marvell.com>
This patchset provides support for the TMIO based IO controller used in the
Toshiba e-series PDAs.
Signed-off-by: Ian Molton <spyro@f2s.com>
Acked-by: Samuel Ortiz <sameo@openedhand.com>
Acked-by: Eric Miao <eric.y.miao@gmail.com>
Fix kernel-doc notation to use correct syntax. Even though this should be
moved to where the function is actually implemented...
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Impact: change calling convention of existing clock_event APIs
struct clock_event_timer's cpumask field gets changed to take pointer,
as does the ->broadcast function.
Another single-patch change. For safety, we BUG_ON() in
clockevents_register_device() if it's not set.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Cc: Ingo Molnar <mingo@elte.hu>
drivers/built-in.o: In function `pci_set_consistent_dma_mask':
hid-quirks.c:(.text+0x2664): multiple definition of `pci_set_consistent_dma_mask'
drivers/built-in.o: In function `pci_set_dma_mask':
hid-quirks.c:(.text+0x42c4): multiple definition of `pci_set_dma_mask'
because drivers/pci/pci.c was not seeing the definition disabling these
functions.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The gpio setup for AM200 specific GPIO pins should be done in the AM200
code rather than in generic gumstix code.
Signed-off-by: Jaya Kumar <jayakumar.lkml@gmail.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
This patch adds HP iPAQ h5000's (h5400, h5500) basic definitions.
Kernel will able to boot, work via serial console, mount filesystems
placed on flashes and run USB gadgets (g_ether by default).
Other device drivers (frame buffer, LCD, touchscreen, backlight,
bluetooth, w1/battery, ...) are depend on SAMCOP and MediaQ
SoCs/MFDs, drivers to which will be submitted too, after massive
cleanups.
This machine will be used as "real user" for these new drivers.
This is an updated version of the patch, which contains fixes proposed on
linux-arm-kernel mailing list.
Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
Signed-off-by: Milan Plzik <milan.plzik@gmail.com>
Signed-off-by: Eric Miao <eric.miao@marvell.com>
Add mapping for system ROM using physmap-flash mapping.
Signed-off-by: Dmitry Baryshkov <dbaryshkov@gmail.com>
Signed-off-by: Eric Miao <eric.miao@marvell.com>
Add mapping for system ROM using physmap-flash mapping.
Signed-off-by: Dmitry Baryshkov <dbaryshkov@gmail.com>
Signed-off-by: Eric Miao <eric.miao@marvell.com>
Add mapping for system ROM using physmap-flash mapping.
Signed-off-by: Dmitry Baryshkov <dbaryshkov@gmail.com>
Signed-off-by: Eric Miao <eric.miao@marvell.com>
Add mapping for system ROM using physmap-flash mapping.
Signed-off-by: Dmitry Baryshkov <dbaryshkov@gmail.com>
Signed-off-by: Eric Miao <eric.miao@marvell.com>
Add platform data necessary to support tmiofb on tosa.
Signed-off-by: Dmitry Baryshkov <dbaryshkov@gmail.com>
Signed-off-by: Eric Miao <eric.miao@marvell.com>
Take advantage of the newly created wm97xx battery driver
and remove useless code in mioa701 board code. Add also the
ac connection detect capability after the matching gpio was
discovered.
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Eric Miao <eric.miao@marvell.com>
The charger enable gpio is straight (1 means draw from USB
Vbus, 0 mean do not draw). The USB Vbus sensing is inverted
(1 means no Vbus voltage sensed, 0 means Vbus voltage
present).
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Eric Miao <eric.miao@marvell.com>
Change the halt and reboot method from gpio based to "jump
to ROM IPL beginning". This gives control back to IPL, which
without PowerOn key pressed, will put the device into deep
sleep until PowerOn is pressed for 1 second.
But this has the benefit of keeping the RTC registers across
reboots, which is good for OS change.
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Eric Miao <eric.miao@marvell.com>
Add GPIO configuration and platform specific declarations
to make Mitac Mio A701 camera chip work. The chip is a
Micron MT9M111 CMOS sensor, based on PXA QIF interface and
I2C bus for sensor control.
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Eric Miao <eric.miao@marvell.com>
Since mioa701 board has migrated to the mfp architecture,
low power gpio setup is now correctly handled even when gpio
led driver is not loaded, and leds and vibrator don't stay
activated in suspend mode (especially vibrator).
Remove the not needed anymore dependency.
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Eric Miao <eric.miao@marvell.com>
Add IO memory and IRQ ressources for pxa based SoC to be
able to use the new rtc-pxa driver.
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Eric Miao <eric.miao@marvell.com>
This patch implements Eric Miao's idea to detect the correct value of
sdram_rows by inspecting the MDCNFG register settings.
It is only tested on two pxa27x devices with 64MB RAM (magician and
hx4700) so far.
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
Signed-off-by: Eric Miao <eric.miao@marvell.com>
Following the removal of the "->policy" usage for PXA255 in patch
459fc208ab (cpufreq: remove
policy->governor setting in drivers initialization), this patch
introduces an option (called "pxa255_turbo_table") to select either
the "run" or "turbo" frequency table.
It also cures the runtime warning that was printed each time the
frequency was changed.
Got rid of all references to CPUFREQ_POLICY_* for pxa255, and sticked
with the run/turbo thing.
Tested on an Arcom/Eurotech Viper.
Signed-off-by: Marc Zyngier <maz@misterjones.org>
Acked-by: Dominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: Eric Miao <eric.miao@marvell.com>
GPIO3/GPIO4 are a bit special on pxa27x, since it depends on PCFR/PI2C_EN
bit, add their definitions here with comments.
Signed-off-by: Eric Miao <eric.miao@marvell.com>
Acked-by: Stefan Schmidt <stefan@datenfreihafen.org>
Eric Miao