Implement atomic_inc_not_zero and atomic64_inc_not_zero. At the
moment we use atomic*_add_unless which requires us to put 0 and
1 constants into registers. We can also avoid a subtract by
saving the original value in a second temporary.
This removes 3 instructions from fget:
- c0000000001b63c0: 39 00 00 00 li r8,0
- c0000000001b63c4: 39 40 00 01 li r10,1
...
- c0000000001b63e8: 7c 0a 00 50 subf r0,r10,r0
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Add a kconfig option NEED_MACH_IO_H to conditionally include mach/io.h.
Basing this on CONFIG_PCI and CONFIG_ISA doesn't quite work. Most ISA
platforms don't need mach/io.h, but ebsa110 does. Most PCI platforms need
mach/io.h for now, but ks8695 doesn't which means i/o accesses are broken.
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Acked-by: Nicolas Pitre <nico@linaro.org>
In preparation to remove mach/io.h, add explicit include of mach/dove.h
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Acked-by: Nicolas Pitre <nico@linaro.org>
These variables are just needed in pci.c and io.c, so move them out of
io.h in preparation to remove io.h.
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Cc: Russell King <linux@arm.linux.org.uk>
Now that all custom ioremap/iounmap users are converted to runtime hook,
remove the compile time defines.
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Nicolas Pitre <nico@linaro.org>
Convert ebsa110 platforms to use run-time ioremap hook instead of the
compile time hook.
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Cc: Russell King <linux@arm.linux.org.uk>
Convert ixp4xx platforms to use run-time ioremap hook instead of the
compile time hook.
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Cc: Imre Kaloz <kaloz@openwrt.org>
Cc: Krzysztof Halasa <khc@pm.waw.pl>
Convert iop13xx platforms to use run-time ioremap hook instead of the
compile time hook. The custom ioremap is still needed for 64-bit address
handling.
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Cc: Russell King <linux@arm.linux.org.uk>
Convert i.MX platforms to use the common run-time ioremap hook instead of
the imx specific hook.
Also, move addr_in_module out of io.h.
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Cc: Sascha Hauer <kernel@pengutronix.de>
We have compile time over-ride of ioremap and iounmap, but an run-time
override is needed for multi-platform builds. This adds an extra function
pointer check, but ioremap is not peformance critical. The option for
compile time selection remains.
The caller variant is used here to provide correct caller information as
ARM can only support level 0 for __builtin_return_address.
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Cc: Russell King <linux@arm.linux.org.uk>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Nicolas Pitre <nico@linaro.org>
It turns out that test-compiling this file on x86-64 doesn't really
help, because much of it is x86-32-specific. And so I hadn't noticed
the slightly over-eager removal of the 'r' from 'addr' variable despite
thinking I had tested it.
Signed-off-by: Linus "oopsie" Torvalds <torvalds@linux-foundation.org>
commit e4b0b2cbbb (ARM: OMAP2+: gpmc-smsc911x: add required smsc911x
regulators) added regulators which are registered during
gpmc_smsc911x_init(). However, some platforms (OMAP3/Overo) have more
than one instance of the SMSC911x and result in attempting to register
the same regulator more than once which causes a panic().
Fix this by only registering the regulator when the platform_data id
field is zero, indicating its the first instance.
Cc: Matt Porter <mporter@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Several users of "find_vma_prev()" were not in fact interested in the
previous vma if there was no primary vma to be found either. And in
those cases, we're much better off just using the regular "find_vma()",
and then "prev" can be looked up by just checking vma->vm_prev.
The find_vma_prev() semantics are fairly subtle (see Mikulas' recent
commit 83cd904d27: "mm: fix find_vma_prev"), and the whole "return
prev by reference" means that it generates worse code too.
Thus this "let's avoid using this inconvenient and clearly too subtle
interface when we don't really have to" patch.
Cc: Mikulas Patocka <mpatocka@redhat.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
When using the SMPS regulators to scale voltages, the regulator
framework may pass a minimum voltage that is not an exact OPP voltage.
For the VC/VP controlled voltage domains, we must ensure that the
voltage requested is the exact voltage from the OPP table. This is
especially critical when using SR.
To fix, voltdm_scale() uses the target voltage passed to walk through
the OPP voltages until it finds a voltage that is >= one of the OPP
voltages.
Cc: Tero Kristo <t-kristo@ti.com>
Cc: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
VDD1 is used for MPU voltage, VDD2 is for IVA and VDD3 is for CORE.
These are needed by DVFS. This patch also adds external controller
support for these regulators, the default I2C control channel can't
be used to modify the voltages for these regulators on TWL6030.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
VDD1 and VDD2 now use voltage processor for controlling the regulators.
This is done by passing additional voltdm data during the regulator init.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
VDD1 and VDD2 are the core voltage regulators on OMAP3. VDD1 is used
to control MPU/IVA voltage, and VDD2 is used for CORE. These regulators
are needed by DVFS.
Voltage ranges for VDD1 and VDD2 are taken from twl4030/twl5030 data manuals:
- SWCS019L : TWL4030 ES3.1 Data Manual rev L
- SWCS030E : TWL5030 ES1.2 Data Manual rev E
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
OMAP3 uses the default settings for VDD1 channel, otherwise the settings will
overlap with VDD2 and attempting to modify VDD1 voltage will actually change
VDD2 voltage.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
commit 2f34ce81b8
(OMAP3: PM: Adding voltage driver support.)
introduced runtime computation of waittime to handle all potential
sys clocks available.
In the voltage processor, the SPMSUpdateWait is calculated based on
the slew rate and the voltage step (SMPSUpdateWait = slew rate *
Voltage Step). After the voltage processor receives the SMPS_Ack
signal, the Voltage Controller will wait for SMPSUpdateWait clock
cycles for the voltage to settle to the new value. For all
practical purposes, the waittime parameter is the OMAP hardware
translation of what the slew rate on the PMIC is.
As an example, with TPS62361 on OMAP4460,
step_size = 10000
slew_rate = 32000
sys_clk_rate = 38400
Our current computation results in the following:
= ((step_size / slew_rate) * sys_clk_rate) / 1000
= ((10000 / 32000) * 38400 / 1000
= 0
Fix the same using DIV_ROUND_UP as an extra wait clock cycle
is better than lesser clock cycle. For the above example, this
translates to:
= (10000 * 38400) / (1000 * 32000)
= 12
Acked-by: Jon Hunter <jon-hunter@ti.com>
[nm@ti.com: slightly better implementation]
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Yuan Jiangli <jlyuan@motorola.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
This compatible value will be used to distinguish some special features of APM821XX EMAC: no half duplex mode support, configuring jumbo frame.
Signed-off-by: Duc Dang <dhdang@apm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When CONFIG_HOTPLUG_CPU=n, there are unused functions in wakeupgen:
arch/arm/mach-omap2/omap-wakeupgen.c:181: warning: 'wakeupgen_irqmask_all' defined but not used
Fix this by moving all the functions only used when CONFIG_HOTPLUG_CPU=y
together and wrapping in an #ifdef.
No functional changes.
Reported-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Fix the below warning by making omap2_init_processor_devices() __init.
It is called by an __init function and calls only __init functions, so
it should also be init.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0x183c): Section mismatch in reference from the function omap2_init_processor_devices() to the function .init.text:_init_omap_device()
The function omap2_init_processor_devices() references
the function __init _init_omap_device().
This is often because omap2_init_processor_devices lacks a __init
annotation or the annotation of _init_omap_device is wrong.
Reported-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Otherwise we get:
arch/arm/mach-omap2/board-n8x0.c:39:12: warning:
'slot1_cover_open' defined but not used [-Wunused-variable]
arch/arm/mach-omap2/board-n8x0.c:40:12: warning:
'slot2_cover_open' defined but not used [-Wunused-variable]
arch/arm/mach-omap2/board-n8x0.c:41:23: warning:
'mmc_device' defined but not used [-Wunused-variable]
Reported-by: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Otherwise we get the following warning:
arch/arm/mach-omap2/io.c:53:24: warning:
'omap24xx_io_desc' defined but not used [-Wunused-variable]
Reported-by: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Pull arm-soc bug fixes from Arnd Bergmann:
"Here are all the fixes I got after sending the last pull request.
These fix mostly regressions on exynos, at91, pxa and ep93xx.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>"
* tag 'fixes-3.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
ARM: ep93xx: convert vision_ep9307 to MULTI_IRQ_HANDLER
ARM: EXYNOS: fix touchscreen IRQ setup on Universal C210 board
ARM: pxa: fix invalid mfp pin issue
ARM: pxa: remove duplicated registeration on pxa-gpio
ARM: pxa: add dummy clock for pxa25x and pxa27x
ARM: S3C24XX: DMA resume regression fix
ARM: S3C24XX: Fix restart on S3C2442
ARM: SAMSUNG: Fix memory size for hsotg
ARM: at91/dma: DMA controller registering with DT support
ARM: at91/dma: remove platform data from DMA controller
* 'fixes' of git://github.com/hzhuang1/linux: (3 commits)
ARM: pxa: fix invalid mfp pin issue
ARM: pxa: remove duplicated registeration on pxa-gpio
ARM: pxa: add dummy clock for pxa25x and pxa27x
Includes an update to v3.3-rc6
As done for the other ep93xx machines in:
commit 9a6879bd90
ARM: ep93xx: convert to MULTI_IRQ_HANDLER
Now that there is a generic IRQ handler for multiple VIC devices use it
for vision_ep9307 to help building multi platform kernels.
Signed-off-by: Hartley Sweeten <hsweeten@visionengravers.com>
Acked-by: Ryan Mallon <rmallon@gmail.com>
Reviewed-by: Jamie Iles <jamie@jamieiles.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
A few more ASoC updates, the main one is the move of the audmux driver
from arch/arm into sound/soc. There's also some general driver specific
tweaks and fixes.
This patch adds s3c_fb_driverdata s3c_fb_data_exynos5 for EXYNOS5
and adds extended timing control setting.
EXYNOS5 FIMD needs extended setting for video timing control.
Additional bits are added to VIDTCON2, VIDWxxADD2, VIDOSDxA and
VIDOSDxB registers in order to set timing value for lager resolution.
Also, address offset of VIDTCONx registers is changed from 0x0
to 0x20000, thus variable type should be changed to int type
to handle the address offset of VIDTCONx registers for EXYNOS5 FIMD.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
