Signed-off-by: NDaniel Mack <daniel@caiaq.de>
Signed-off-by: NEric Miao <eric.miao@marvell.com>

clk_add_alias is commonly called for platform devices that are not yet
registered in the device tree. Thus the clock alias is associated with
NULL device name. Fix this by passing the device name instead of just
device pointer.
Signed-off-by: NDmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Signed-off-by: NEric Miao <eric.miao@marvell.com>

Signed-off-by: NDaniel Mack <daniel@caiaq.de>
Signed-off-by: NEric Miao <eric.miao@marvell.com>

Some broken bootloaders will leave the DMA channel state unclean, which
we should really initialize correctly here.
Signed-off-by: NEric 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: NEric Miao <eric.miao@marvell.com>

This currently happens for 'drivers/input/touch/mainstone-wm97xx.c'.
Signed-off-by: NEric Miao <eric.miao@marvell.com>

After commit 8c3abc7d
("[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: NMike Rapoport <mike@compulab.co.il>
Signed-off-by: NEric Miao <eric.miao@marvell.com>

arch/arm/mach-pxa/pxa300.c:94: error: 'CKEN_MMC3' undeclared here (not in a function)
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

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: NRussell King <rmk+kernel@arm.linux.org.uk>

Adds MFP configuration for supported e750 hardware.
Signed-off-by: NIan Molton <ian@mnementh.co.uk>

Signed-off-by: NYong Yao <yaoyong@marvell.com>
Signed-off-by: NEric Miao <eric.miao@marvell.com>
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>

Signed-off-by: NYong Yao <yaoyong@marvell.com>
Signed-off-by: NEric Miao <eric.miao@marvell.com>
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>

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: NEric Miao <eric.miao@marvell.com>
Cc: Rodolfo Giometti <giometti@linux.it>
Signed-off-by: NEric 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: NEric Miao <eric.miao@marvell.com>
Signed-off-by: NEric 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: NEric Miao <eric.miao@marvell.com>
Signed-off-by: NEric 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: NEric Miao <eric.miao@marvell.com>
Signed-off-by: NEric 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: NEric Miao <eric.miao@marvell.com>
Signed-off-by: NEric 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: NEric Miao <eric.miao@marvell.com>
Acked-by: NNicolas Pitre <nico@marvell.com>

Signed-off-by: NEric Miao <eric.miao@marvell.com>

Signed-off-by: NEric Miao <eric.miao@marvell.com>

Signed-off-by: NEric Miao <eric.miao@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: NJonathan Cameron <jic23@cam.ac.uk>
Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NEric Miao <eric.miao@marvell.com>

I2C platform data setups.
Signed-off-by: NDaniel Ribeiro <drwyrm@gmail.com>
Signed-off-by: NStefan Schmidt <stefan@datenfreihafen.org>
Signed-off-by: NEric Miao <eric.miao@marvell.com>

Matrix and single key setups for all phones.
Signed-off-by: NDaniel Ribeiro <drwyrm@gmail.com>
Signed-off-by: NStefan Schmidt <stefan@datenfreihafen.org>
Signed-off-by: NAntonio Ospite <ospite@studenti.unina.it>
Signed-off-by: NEric Miao <eric.miao@marvell.com>

Pin configs for different generations and phones.
Signed-off-by: NDaniel Ribeiro <drwyrm@gmail.com>
Signed-off-by: NStefan Schmidt <stefan@datenfreihafen.org>
Signed-off-by: NEric Miao <eric.miao@marvell.com>

Our bootloader now supports ATAGS_MEM
Signed-off-by: NDaniel Ribeiro <drwyrm@gmail.com>
Signed-off-by: NStefan Schmidt <stefan@datenfreihafen.org>
Signed-off-by: NEric Miao <eric.miao@marvell.com>

Signed-off-by: NJaya Kumar <jayakumar.lkml@gmail.com>
Cc: Andre Puschmann <andre.puschmann@imms.de>
Signed-off-by: NEric 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: NEric 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: NEric Miao <eric.miao@marvell.com>

Signed-off-by: NEric Miao <eric.miao@marvell.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: Ian Molton <spyro@f2s.com>
Cc: pHilipp Zabel <philipp.zabel@gmail.com>
Cc: Marek Vasut <marek.vasut@gmail.com>
Cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: Juergen Schindele <linux@schindele.name>
Acked-by: NStefan Schmidt <stefan@datenfreihafen.org>
Acked-by: NMarc Zyngier <maz@misterjones.org>
Acked-by: NMike Rapoport <mike@compulab.co.il>
Acked-by: NJaya Kumar <jayakumar.lkml@gmail.com>

Signed-off-by: NEric 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: NIan Molton <spyro@f2s.com>
Acked-by: NSamuel Ortiz <sameo@openedhand.com>
Acked-by: NEric Miao <eric.y.miao@gmail.com>

Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Fix kernel-doc notation to use correct syntax.  Even though this should be
moved to where the function is actually implemented...
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NRussell 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: NRusty 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: NRussell 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: NJaya Kumar <jayakumar.lkml@gmail.com>
Signed-off-by: NRussell 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: NAnton Vorontsov <cbouatmailru@gmail.com>
Signed-off-by: NMilan Plzik <milan.plzik@gmail.com>
Signed-off-by: NEric Miao <eric.miao@marvell.com>

Add mapping for system ROM using physmap-flash mapping.
Signed-off-by: NDmitry Baryshkov <dbaryshkov@gmail.com>
Signed-off-by: NEric Miao <eric.miao@marvell.com>

Add mapping for system ROM using physmap-flash mapping.
Signed-off-by: NDmitry Baryshkov <dbaryshkov@gmail.com>
Signed-off-by: NEric Miao <eric.miao@marvell.com>