PXA and StrongARM1100 traditionally map their I/O space 1:1 into virtual
memory, using a per-bus io_offset that matches the base address of the
ioremap mapping.

In order for PXA to work in a multiplatform config, this needs to
change so I/O space starts at PCI_IOBASE (0xfee00000). Since the pcmcia
soc_common support is shared with StrongARM1100, both have to change at
the same time. The affected machines are:

 - Anything with a PCMCIA slot now uses pci_remap_iospace, which
   is made available to PCMCIA configurations as well, rather than
   just PCI. The first PCMCIA slot now starts at port number 0x10000.

 - The Zeus and Viper platforms have PC/104-style ISA buses,
   which have a static mapping for both I/O and memory space at
   0xf1000000, which can no longer work. It does not appear to have
   any in-tree users, so moving it to port number 0 makes them
   behave like a traditional PC.

 - SA1100 does support ISA slots in theory, but all machines that
   originally enabled this appear to have been removed from the tree
   ages ago, and the I/O space is never mapped anywhere.

 - The Nanoengine machine has support for PCI slots, but looks
   like this never included I/O space, the resources only define the
   location for memory and config space.

With this, the definitions of __io() and IO_SPACE_LIMIT can be simplified,
as the only remaining cases are the generic PCI_IOBASE and the custom
inb()/outb() macros on RiscPC.  S3C24xx still has a custom inb()/outb()
in this here, but this is already removed in another branch.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Using MTD-XIP does not work on multiplatform kernels because
it requires SoC specific register accesses to be done from
low-level flash handling functions in RAM while the rest of the
kernel sits in flash.

I found no evidence of anyone still actually using this feature,
so remove it from PXA to avoid spending a lot of time on
actually making it work.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

None of the headers are included from outside of the mach-pxa
directory, so move them all in there.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

On a kernel that includes both ARMv4 and XScale support,
the copypage function fails to build with invalid
instructions.

Since these are only called on an actual XScale processor,
annotate the assembly with the correct .arch directive.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

There are two drivers in arch/arm/plat-pxa: mfp and ssp. Both
of them should ideally not be needed at all, as there are
proper subsystems to replace them.

OTOH, they are self-contained and can simply be normal
SoC drivers, so move them over there to eliminate one more
of the plat-* directories.

Acked-by: Robert Jarzmik <robert.jarzmik@free.fr> (mach-pxa)
Acked-by: Lubomir Rintel <lkundrak@v3.sk> (mach-mmp)
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

In a multiplatform kernel that includes both pxa and mmp, we get a link
failure from the clash of two pxa_register_device functions.

Rename the one in mach-mmp to mmp_register_device, along with with the
rename of pxa_device_desc.
Acked-by: NLubomir Rintel <lkundrak@v3.sk>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

There are two tavorevb boards in the kernel, one using a PXA930 chip in
mach-pxa, and one using the later PXA910 chip in mach-mmp.  They use the
same board number, which is generally a bad idea, and in a multiplatform
kernel, we can end up with funny link errors like this one resulting
from two boards gettting controlled by the same Kconfig symbol:

arch/arm/mach-mmp/tavorevb.o: In function `tavorevb_init':
tavorevb.c:(.init.text+0x4c): undefined reference to `pxa910_device_uart1'
tavorevb.c:(.init.text+0x50): undefined reference to `pxa910_device_gpio'
tavorevb.o:(.arch.info.init+0x54): undefined reference to `pxa910_init_irq'
tavorevb.o:(.arch.info.init+0x58): undefined reference to `pxa910_timer_init'

The mach-pxa TavorEVB seems much more complete than the mach-mmp one
that supports only uart, gpio and ethernet. Further, I could find no
information about the board on the internet aside from references to
the Linux kernel, so I assume this was never available outside of Marvell
and can be removed entirely.

There is a third board named TavorEVB in the Kconfig description,
but this refers to the "TTC_DKB" machine. The two are clearly
related, so I change the Kconfig description to just list both
names.

Cc: Lubomir Rintel <lkundrak@v3.sk>
Reviewed-by: NLubomir Rintel <lkundrak@v3.sk>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

The sa1111.h header defines some constants using the bitfield
macros, but those are only used on sa1100, not on pxa, and the
users include the bitfield header through mach/hardware.h.
Acked-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

The clock register definitions are now used (almost) exclusively in the
clk driver, and that relies on no other mach/*.h header files any more.

Remove the dependency on mach/pxa*-regs.h by addressing the registers
as offsets from a void __iomem * pointer, which is either passed from
a board file, or (for the moment) ioremapped at boot time from a hardcoded
address in case of DT (this should be moved into the DT of course).

Cc: linux-clk@vger.kernel.org
Acked-by: NStephen Boyd <sboyd@kernel.org>
Acked-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

The get_sdram_rows() and get_memclkdiv() helpers need smemc
register that are separate from the clk registers, move
them out of the clk driver, and use an extern declaration
instead.

Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: linux-clk@vger.kernel.org
Link: https://lore.kernel.org/lkml/87pnielzo4.fsf@belgarion.home/Signed-off-by: NArnd Bergmann <arnd@arndb.de>

The driver needs some low-level register access for setting
the core and bus frequencies. These registers are owned
by the clk driver, so move the low-level access into that
driver with a slightly higher-level interface and avoid
any machine header file dependencies.

Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Stephen Boyd <sboyd@kernel.org>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Cc: linux-clk@vger.kernel.org
Cc: linux-pm@vger.kernel.org
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

get_clk_frequency_khz() is not a proper name for a global function,
and there is only one caller.

Convert viper to use the properly namespaced
pxa25x_get_clk_frequency_khz() and remove the other references.
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Acked-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Cc: linux-pm@vger.kernel.org
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Rather than poking at the smemc registers directly from the
pcmcia/pxa2xx_base driver, move those bits into machine file
to have a cleaner interface.

Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Link: https://lore.kernel.org/lkml/87d0egjzxk.fsf@belgarion.home/Signed-off-by: NArnd Bergmann <arnd@arndb.de>

To avoid dereferencing hardwired constant pointers from a global header
file, change the driver to use devm_platform_ioremap_resource for getting
an __iomem pointer, and then using readl/writel on that.

Each pointer dereference gets changed by a search&replace, which leads
to a few overlong lines, but seems less risky than trying to clean up
the code at the same time.
Acked-by: NMark Brown <broonie@kernel.org>
Acked-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Cc: alsa-devel@alsa-project.org
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

To avoid dereferencing hardwired constant pointers from a global header
file, change the driver to use devm_platform_ioremap_resource for getting
an __iomem pointer, and then using readl/writel on that.

Each pointer dereference gets changed by a search&replace, which leads
to a few overlong lines, but seems less risky than trying to clean up
the code at the same time.

Cc: alsa-devel@alsa-project.org
Acked-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

The driver currently takes the hardwired FIFO address from
a header file that we want to eliminate. Change it to use
the mmio resource instead and stop including the here.
Acked-by: NMark Brown <broonie@kernel.org>
Cc: alsa-devel@alsa-project.org
Acked-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Now that we are using oneshot threaded IRQ this method is not used anymore.
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
[arnd: add the db1300 change as well]
Cc: Manuel Lauss <manuel.lauss@gmail.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Instead of manually disabling and enabling interrupts and scheduling work
to access the device, let's use threaded oneshot interrupt handler. It
simplifies things.
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

To avoid a dependency on the pxa platform header files with
hardcoded registers, change the driver to call a wrapper
in the pxa2xx-ac97-lib that encapsulates all the other
ac97 stuff.
Acked-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Acked-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Cc: linux-input@vger.kernel.org
Cc: alsa-devel@alsa-project.org
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

The two drivers are almost identical and can work on a variety
of hardware in principle. The mainstone driver supports additional
hardware, and the zylonite driver has a few cleanup patches.

Sync the two by adding the zylonite changes into the mainstone
one, and checking for the zylonite board to order to keep the
default behavior (interrupt enabled) there.
Acked-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: linux-input@vger.kernel.org
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

There are two different ways of flushing the ac97 queue
in this driver, selected by a compile time option.

Change this to a runtime selection to make it work when both
are enabled.
Acked-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Acked-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Cc: linux-input@vger.kernel.org
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

The mach/mfp.h header is only used by this one driver
for hardcoded gpio numbers. Change that to use a lookup
table instead.

Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: linux-input@vger.kernel.org
Acked-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

This driver hardcodes gpio numbers without a header file.
Use lookup tables instead.

Cc: Marek Vasut <marek.vasut@gmail.com>
Acked-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Acked-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Cc: linux-input@vger.kernel.org
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

The magician audio driver creates a codec device and gets
data from a board specific header file, both of which is
a bit suspicious. Move these into the board file itself,
using a gpio lookup table.
Acked-by: NMark Brown <broonie@kernel.org>
Acked-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Cc: alsa-devel@alsa-project.org
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

The audio device is allocated by the audio driver, and it uses a gpio
number from the mach/z2.h header file.

Change it to use a gpio lookup table for the device allocated by the
driver to keep the header file local to the machine.
Acked-by: NMark Brown <broonie@kernel.org>
Cc: alsa-devel@alsa-project.org
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Acked-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

The three eseries machines have very similar drivers for audio, all
using the mach/eseries-gpio.h header for finding the gpio numbers.

Change these to use gpio descriptors to avoid the header file
dependency.

I convert the _OFF gpio numbers into GPIO_ACTIVE_LOW ones for
consistency here.
Acked-by: NMark Brown <broonie@kernel.org>
Acked-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Cc: alsa-devel@alsa-project.org
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

The audio driver should not use a hardwired gpio number
from the header. Change it to use a lookup table.
Acked-by: NMark Brown <broonie@kernel.org>
Cc: alsa-devel@alsa-project.org
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Lubbock is the only machine that has three IRQs for the UDC.
These are currently hardcoded in the driver based on a
machine header file.

Change this to use platform device resources as we use for
the generic IRQ anyway.

Cc: Felipe Balbi <balbi@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-usb@vger.kernel.org
Acked-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

The audio driver should not use a hardwired gpio number
from the header. Change it to use a lookup table.

Cc: Philipp Zabel <philipp.zabel@gmail.com>
Cc: Paul Parsons <lost.distance@yahoo.com>
Acked-by: NMark Brown <broonie@kernel.org>
Acked-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Cc: alsa-devel@alsa-project.org
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

The audio driver should not use a hardwired gpio number
from the header. Change it to use a lookup table.
Acked-by: NMark Brown <broonie@kernel.org>
Cc: alsa-devel@alsa-project.org
Acked-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

The poodle audio driver shows its age by using a custom
gpio api for the "locomo" support chip.

In a perfect world, this would get converted to use gpiolib
and a gpio lookup table.

As the world is not perfect, just pass all the required data
in a custom platform_data structure. to avoid the globally
visible mach/poodle.h header.
Acked-by: NMark Brown <broonie@kernel.org>
Acked-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Cc: alsa-devel@alsa-project.org
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

The Tosa device (Sharp SL-6000) has a mishmash driver set-up
for the Toshiba TC6393xb MFD that includes a battery charger
and touchscreen and has some kind of relationship to the SoC
sound driver for the AC97 codec. Other devices define a chip
like this but seem only half-implemented, not really handling
battery charging etc.

This patch switches the Toshiba MFD device to provide GPIO
descriptors to the battery charger and SoC codec. As a result
some descriptors need to be moved out of the Tosa boardfile
and new one added: all SoC GPIO resources to these drivers
now comes from the main boardfile, while the MFD provide
GPIOs for its portions.

As a result we can request one GPIO from our own GPIO chip
and drop two hairy callbacks into the board file.

This platform badly needs to have its drivers split up and
converted to device tree probing to handle this quite complex
relationship in an orderly manner. I just do my best in solving
the GPIO descriptor part of the puzzle. Please don't ask me
to fix everything that is wrong with these driver to todays
standards, I am just trying to fix one aspect. I do try to
use modern devres resource management and handle deferred
probe using new functions where appropriate.

Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Cc: Dirk Opfer <dirk@opfer-online.de>
Cc: Robert Jarzmik <robert.jarzmik@free.fr>
Cc: Daniel Mack <daniel@zonque.org>
Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
Cc: Lee Jones <lee.jones@linaro.org>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Reviewed-by: NDmitry Baryshkov <dbaryshkov@gmail.com>
Acked-by: NMark Brown <broonie@kernel.org>
Acked-by: NSebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

From inspection I found a couple of GPIO lookups that are
listed with device "gpio-pxa", but actually have a number
from a different gpio controller.

Try to rectify that here, with a guess of what the actual
device name is.
Acked-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Cc: stable@vger.kernel.org
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

The palmld header is almost unused in drivers, the only
remaining thing now is the PATA device address, which should
really be passed as a resource.

Cc: linux-ide@vger.kernel.org
Acked-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Acked-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: NDamien Le Moal <damien.lemoal@opensource.wdc.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Drivers should not rely on the contents of this file, so
move it into the platform directory directly.

Cc: Philipp Zabel <philipp.zabel@gmail.com>
Cc: Paul Parsons <lost.distance@yahoo.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/lkml/87mudkmx8g.fsf@belgarion.home/

The drivers/pcmcia/pxa2xx_*.c are essentially part of the
board files, but for historic reasons located in drivers/pcmcia.

Move them into the same place as the actual board file to avoid
lots of machine header inclusions.

Cc: Marek Vasut <marek.vasut@gmail.com>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: Jonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

The pxa2xx-ac97-lib code is the last driver to use mach/irqs.h
for PXA. Almost everything already passes the interrupt as
a resource, so use it from there.

The one exception is the mxm8x10 machine, which apparently has
a resource-less device. Replacing it with the correct one
enables the driver here as well.

Cc: alsa-devel@alsa-project.org
Acked-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Rather than relying on machine specific headers to
pass down the reboot status and the register locations,
use resources and platform_data.

Aside from this, keep the changes to a minimum.

Cc: Wim Van Sebroeck <wim@linux-watchdog.org>
Cc: linux-watchdog@vger.kernel.org
Acked-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Only the pxafb driver uses this header, so move it into the
same directory. The SMART_* macros are required by some
platform data definitions and can go into the
linux/platform_data/video-pxafb.h header.
Acked-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Cc: dri-devel@lists.freedesktop.org
Cc: linux-fbdev@vger.kernel.org
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

This is a basically a platform_data file, so move it out of
the mach/* header directory.

Cc: Marek Vasut <marek.vasut@gmail.com>
Cc: Tomas Cech <sleep_walker@suse.com>
Cc: Sergey Lapin <slapin@ossfans.org>
Acked-by: NMark Brown <broonie@kernel.org>
Acked-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Cc: alsa-devel@alsa-project.org
Signed-off-by: NArnd Bergmann <arnd@arndb.de>