* tag 'imx25-iomux-ds' of git://git.pengutronix.de/git/imx/linux-2.6:
iomux-mx25.h slew rate adjusted for LCD __LD pins
(update to v3.3-rc6)
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
For some reason (sadly i don't identifying the patch right now)
two LCD data lines configured PAD_CTL_SRE_SLOW (wrong slew rate)
since Kernel 3.1. MX25_PAD_GPIO_E__LD16 and MX25_PAD_GPIO_F__LD17
This results in an fauly behaviour and strange color effects.
To ensure that all LCD data pins configured with the proper slew rate,
this patch changes to IOMUX define of all LCD __LDxx pins to PAD_CTL_SRE_FAST.
This problem may affect other mx25 platforms like mx25pdk. Sadly i can't test
it. Of course this problem shouldn't occur when you done your LCD muxing
correctly in the bootloader.
Best regards,
Torsten
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
All callers (board-mityomapl138.c and board-da850-evm.c) use it in
__init functions only.
This fixes:
WARNING: vmlinux.o(.text+0xd664): Section mismatch in reference from the function da850_register_pm() to the function .init.text:da8xx_get_mem_ctlr()
The function da850_register_pm() references
the function __init da8xx_get_mem_ctlr().
This is often because da850_register_pm lacks a __init
annotation or the annotation of da8xx_get_mem_ctlr is wrong.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
This fixes:
arch/arm/mach-davinci/cpufreq.c: In function davinci_target:
arch/arm/mach-davinci/cpufreq.c:98: warning: passing argument 2 of dev_printk from incompatible pointer type
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
* 'fixes-non-critical-part3' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
ARM: OMAP2+: Fix build for omap4 only builds with missing include of linux/bug.h
ARM: OMAP2+: Fix section warnings for hsmmc_init_one
Two fixes are queued up. The first is an additional fix for the OMAP
initialization order issue and the second patch fixes a possible section
mismatch which can lead to a kernel crash in the AMD IOMMU driver when
suspend/resume is used and the compiler has not inlined the
iommu_set_device_table function.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJPWgA/AAoJECvwRC2XARrj7voQAN6evWicqjRDiXQgEC3muQFU
OrA/Jz/i7+pHEYXcsTt0xHLb8juZNJAdkJjToB+oz7i/7D+TYRmJe+QRNkVmw7Ld
d3DbUSUi9B3agvGblosKV3DYM8By1vTn9Gy2GNatW1yPuo5o4FHK2ePC5sn8Z/8z
qwTZZnmvqluz7frNiw6Y3bNOqLd46z+9thUOoKmRn/fo3vKCOOVvb85yu1m/uqy6
Dmpn6ep0w53jK29ZTKWcL8PW0YrLTEfszhMcVshFT+Y7GVSGnSxwgSh1fnZm/WL6
z11L57dI0+7RS/z+cw+ko7ymIloV2v4ABRArMPIoLgbIQT0lidDNSqOQnPvWaBek
MwdLL8W64lt2h4T7bLhDNRSDggWCX+EJYlk87O4hJYt4n57c3yT55z2+BGdoFivZ
tzPshNWN4KVDMZCU6sTvzvz6eErwvro5wlVM2WxDVfXTxn6UTblP5uIQDGb2zVA9
G95kK/OlK/s+giwOSOKxtR62livKEAuJ2Croa5LsdJnLdCo6ipvIz9cuAG6eij2W
tulJQUN3FZr288iUAOPQ9xj6hWYM9RXqoYBxAHAvgYgGuirj9E6hjk/fL0y6XGQk
jcg0bCdJjh2RzsLZR0eeslybtlrvUsBWYCPYCAAmRjUYHwZ6s822aO7qh0VnrFuQ
csH09+3B0twvJ+ZRJibN
=PZDd
-----END PGP SIGNATURE-----
Merge tag 'iommu-fixes-v3.3-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu
Pull two IOMMU fixes from Joerg Roedel:
"The first is an additional fix for the OMAP initialization order issue
and the second patch fixes a possible section mismatch which can lead
to a kernel crash in the AMD IOMMU driver when suspend/resume is used
and the compiler has not inlined the iommu_set_device_table function."
* tag 'iommu-fixes-v3.3-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu:
x86/amd: iommu_set_device_table() must not be __init
ARM: OMAP: fix iommu, not mailbox
One samsung build fix due to a mis-applied patch, and a small set of OMAP fixes.
This should be the last from arm-soc for 3.3, hopefully.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJPWQktAAoJEIwa5zzehBx3OK4P/i3+nTB2WW8i8ll8pTHybSAj
YuQGOtsvJDCkZQ6tIgMahNH/Pr2Q2gFe6cjP/akbWWCfUvOl36ZAl9NYY8eexoco
ZGkMEXfhgtAsVepzEF1/64lwOgrh+AikzlL0q0tA2FmClcAejwFE7ht6zPcwFgJj
9lmR201/6OLc+qkmvrKRbmpO+eYZUVuQ4cOEMOxebXZN/tn5S/R2QWC3+PkUMbWz
7bngLHjO97legI0SGzfaKOx/02y/4hIDSybIPDOKDuXi1jUJlkrmnP09sQQLYdKN
uxu56mn+vUPCIGNwmE1/ufSneM8pZEAHaRkUjFOrxtsdGKVsxFz1vyJ3OAQHd8FU
WU+fKOew/Jf+jRpApydKWJ0yOdyTZIVqncvWpFs1RlmAVKPE96M8IL9oUZaV8rgJ
c9XUCvDFF0OuZQyMoacSzbVfcAy9SE/f7fNXLUpI9rEriYfY5waCXcQrYGwjRtmD
j2iY0pyaU72i7mtTbcsInPZ/bZ7gO+D1MmFl9WzduLWDJoGHJVcUyC1+YrJjoGF3
ggplns12qTtdgfiqTKV2I5qf2nHHbk8kmhII1fkYPZwdG2enKhV+r5Oth3zKPVXF
oOD8YnjACuad05YdkpzQL2DSaiGtPVAXHP4xMN9ktNPSJHwx19HNDiTKex6oxcZf
Dki+FinbRiFYUP/O91Xe
=PLTM
-----END PGP SIGNATURE-----
Merge tag 'fixes-urgent' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull last minute fixes from Olof Johansson:
"One samsung build fix due to a mis-applied patch, and a small set of
OMAP fixes. This should be the last from arm-soc for 3.3, hopefully."
* tag 'fixes-urgent' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
ARM: S3C2440: Fixed build error for s3c244x
ARM: OMAP2+: Fix module build errors with CONFIG_OMAP4_ERRATA_I688
ARM: OMAP: id: Add missing break statement in omap3xxx_check_revision
ARM: OMAP2+: Remove apply_uV constraints for fixed regulator
ARM: OMAP: irqs: Fix NR_IRQS value to handle PRCM interrupts
Fixes up a duplicate #include, adds an empty implementation of
of_find_compatible_node() and make git ignore .dtb files. And fix
up bus name on OF described PHYs. Nothing exciting here.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJPWPvsAAoJEEFnBt12D9kB8QsP/2e6jv7CQ/wUhihzw126Y8yi
4HLG3ByJ382/c3LXg3juC+WfMvlpqEa0yqhikFKgIsm7cNbv7PkPS583pujdSXo0
IRykiT3Q9+XbO7L+9C88miYIQT8+IT/AjIjfuRwlP4gLPNUJhknpYhYOc09YzwOp
zhheeGVyeyTay+beQXip8gOEq2dYEl4IKsItagCBZfkDvj3Y8yDwTlP7f2j0FYZi
uODa3NFKE4uc0U2chtro0Vt87TRfbnIQ93SbvEWyQBWMEbPqT3l1Q94AeFGubCLj
RX910WvurCE4evzo2ZJzXPt9gPEyGIgtMGbjh+cENfT5/wNB2HWk1ftKnss5yEjp
WmcbwWKwXPwRPc5EpRdgabBCRgouCZghtcnJpkoXKSwbEt/nj3no8GOZXQnv+rSL
Ga0BSk1jJYC9DRpaIrLvdxXZF7vy1nug8fgU9ALi2R0gTmN+k6tHlLh60EWMSCBF
YCXv3fUd9IVJfOYsu4qMk0Pu40pW9rDc698Nxiep7C0iNhlddq8fiHTwB3DdoinC
iYmz+wEdDDp/68qY/mguXXtr5GAFSz1PUOwSJkh2zW6LnBDEv1djfhoA+5gwZX2v
I1IwfNHMn/XAEuhOFWMo9CejB0rDoBhigwucH8EilbIdBYVCCEtYaubO/Gq6HmId
h7hx9sWjrwF9HY0N9EHX
=/fxH
-----END PGP SIGNATURE-----
Merge tag 'devicetree-for-linus' of git://git.secretlab.ca/git/linux-2.6
Pull minor devicetree bug fixes and documentation updates from Grant Likely:
"Fixes up a duplicate #include, adds an empty implementation of
of_find_compatible_node() and make git ignore .dtb files. And fix up
bus name on OF described PHYs. Nothing exciting here."
* tag 'devicetree-for-linus' of git://git.secretlab.ca/git/linux-2.6:
doc: dt: Fix broken reference in gpio-leds documentation
of/mdio: fix fixed link bus name
of/fdt.c: asm/setup.h included twice
of: add picochip vendor prefix
dt: add empty of_find_compatible_node function
ARM: devicetree: Add .dtb files to arch/arm/boot/.gitignore
Found few more with randconfig generated .configs:
In file included from arch/arm/mach-omap2/prm-regbits-34xx.h:17,
from arch/arm/mach-omap2/vc.c:18:
arch/arm/mach-omap2/prm2xxx_3xxx.h: In function ‘omap2_prm_read_mod_reg’:
arch/arm/mach-omap2/prm2xxx_3xxx.h:239: error: implicit declaration of function ‘WARN’
In file included from arch/arm/mach-omap2/powerdomain44xx.c:22:
arch/arm/mach-omap2/prm2xxx_3xxx.h: In function ‘omap2_prm_read_mod_reg’:
arch/arm/mach-omap2/prm2xxx_3xxx.h:239: error: implicit declaration of function ‘WARN’
This is because omap2_prm functions are currently just stubs for
omap4 only builds.
Signed-off-by: Tony Lindgren <tony@atomide.com>
Fixed following:
arch/arm/mach-s3c2440/s3c244x.c: In function 's3c244x_restart':
arch/arm/mach-s3c2440/s3c244x.c:209: error: expected declaration or statement at end of input
make[1]: *** [arch/arm/mach-s3c24xx/s3c244x.o] Error 1
make: *** [arch/arm/mach-s3c24xx] Error 2
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
Otherwise we can get the following error depending on
the compiler:
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xafe0):
Section mismatch in reference from the function omap_hsmmc_init_one()
to the function .init.text:omap_hsmmc_pdata_init()
The function omap_hsmmc_init_one() references
the function __init omap_hsmmc_pdata_init().
This is often because omap_hsmmc_init_one lacks a __init
annotation or the annotation of omap_hsmmc_pdata_init is wrong.
Signed-off-by: Tony Lindgren <tony@atomide.com>
Otherwise we can get the following if bug.h is not included from kernel.h:
arch/arm/mach-omap2/powerdomain-common.c:
In function 'omap2_pwrdm_get_mem_bank_onstate_mask':
arch/arm/mach-omap2/powerdomain-common.c:64:3: error:
implicit declaration of function 'WARN_ON' [-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
* 'fixes-non-critical' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
Revert "ARM: OMAP2+: Fix multiple randconfig errors with SOC_OMAP and SOC_OMAP_NOOP"
Pull ARM updates from Russell King.
* 'fixes' of git://git.linaro.org/people/rmk/linux-arm:
ARM: 7358/1: perf: add PMU hotplug notifier
ARM: 7357/1: perf: fix overflow handling for xscale2 PMUs
ARM: 7356/1: perf: check that we have an event in the PMU IRQ handlers
ARM: 7355/1: perf: clear overflow flag when disabling counter on ARMv7 PMU
ARM: 7354/1: perf: limit sample_period to half max_period in non-sampling mode
ARM: ecard: ensure fake vma vm_flags is setup
ARM: 7346/1: errata: fix PL310 erratum #753970 workaround selection
ARM: 7345/1: errata: update workaround for A9 erratum #743622
ARM: 7348/1: arm/spear600: fix one-shot timer
ARM: 7339/1: amba/serial.h: Include types.h for resolving dependency of type bool
When a CPU is taken out of reset, either cold booted or hotplugged in,
some of its PMU registers can contain UNKNOWN values.
This patch adds a hotplug notifier to ARM core perf code so that upon
CPU restart the PMU unit is reset and becomes ready to use again.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
xscale2 PMUs indicate overflow not via the PMU control register, but by
a separate overflow FLAG register instead.
This patch fixes the xscale2 PMU code to use this register to detect
to overflow and ensures that we clear any pending overflow when
disabling a counter.
Cc: <stable@vger.kernel.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The PMU IRQ handlers in perf assume that if a counter has overflowed
then perf must be responsible. In the paranoid world of crazy hardware,
this could be false, so check that we do have a valid event before
attempting to dereference NULL in the interrupt path.
Cc: <stable@vger.kernel.org>
Signed-off-by: Ming Lei <tom.leiming@gmail.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
When disabling a counter on an ARMv7 PMU, we should also clear the
overflow flag in case an overflow occurred whilst stopping the counter.
This prevents a spurious overflow being picked up later and leading to
either false accounting or a NULL dereference.
Cc: <stable@vger.kernel.org>
Reported-by: Ming Lei <tom.leiming@gmail.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
On ARM, the PMU does not stop counting after an overflow and therefore
IRQ latency affects the new counter value read by the kernel. This is
significant for non-sampling runs where it is possible for the new value
to overtake the previous one, causing the delta to be out by up to
max_period events.
Commit a737823d ("ARM: 6835/1: perf: ensure overflows aren't missed due
to IRQ latency") attempted to fix this problem by allowing interrupt
handlers to pass an overflow flag to the event update function, causing
the overflow calculation to assume that the counter passed through zero
when going from prev to new. Unfortunately, this doesn't work when
overflow occurs on the perf_task_tick path because we have the flag
cleared and end up computing a large negative delta.
This patch removes the overflow flag from armpmu_event_update and
instead limits the sample_period to half of the max_period for
non-sampling profiling runs.
Cc: <stable@vger.kernel.org>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
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>
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>
* '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>
Failure is reported on hx4700 with kernel v3.3-rc1.
__mfp_validate: GPIO20 is invalid pin
__mfp_validate: GPIO21 is invalid pin
__mfp_validate: GPIO15 is invalid pin
__mfp_validate: GPIO78 is invalid pin
__mfp_validate: GPIO79 is invalid pin
__mfp_validate: GPIO80 is invalid pin
__mfp_validate: GPIO33 is invalid pin
__mfp_validate: GPIO48 is invalid pin
__mfp_validate: GPIO49 is invalid pin
__mfp_validate: GPIO50 is invalid pin
Since pxa_last_gpio is used in mfp-pxa2xx driver. But it's only
updated in pxa-gpio driver that run after mfp-pxa2xx driver.
So update the pxa_last_gpio first in mfp-pxa2xx driver.
Reported-by: Paul Parsons <lost.distance@yahoo.com>
Signed-off-by: Haojian Zhuang <haojian.zhuang@gmail.com>
Both reboot (via reboot(RB_AUTOBOOT)) and suspend freeze on hx4700.
Registration of pxa_gpio_syscore_ops is moved into pxa-gpio driver,
but it still exists in arch-pxa directory. It resulsts failure on
reboot and suspend.
Now remove the registration code in arch-pxa.
Reported-by: Paul Parsons <lost.distance@yahoo.com>
Signed-off-by: Haojian Zhuang <haojian.zhuang@gmail.com>
gpio-pxa driver is shared among arch-pxa and arch-mmp. Clock is the
essential component on pxa3xx/pxa95x and arch-mmp. So we need to
define dummy clock in pxa25x/pxa27x instead.
This regression was introduced by the commit "ARM: pxa: add dummy
clock for sa1100-rtc", id a55b5adaf4.
Reported-by: Jonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: Paul Parsons <lost.distance@yahoo.com>
Tested-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Haojian Zhuang <haojian.zhuang@marvell.com>
Fix the following warning:
WARNING: vmlinux.o(.text+0x1286c): Section mismatch in reference
from the function omap1_init_early() to the function .init.text:omap1_clk_init()
The function omap1_init_early() references
the function __init omap1_clk_init().
This is often because omap1_init_early lacks a __init
annotation or the annotation of omap1_clk_init is wrong.
Signed-off-by: Tony Lindgren <tony@atomide.com>
Correct spelling "resulotion" to "resolution" in
arch/arm/mach-omap1/lcd_dma.c
Signed-off-by: Masanari Iida <standby24x7@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
The definition cpu_is_omap4430() always returns 0 even when CONFIG_ARCH_OMAP4
is enabled. This macro should be removed and the macro cpu_is_omap443x() should
be used where needed for OMAP4430 devices.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
arch/arm/mach-omap2/: included some headers tiwce:
- arch/arm/mach-omap2/board-ldp.c: 'linux/gpio.h'
- arch/arm/mach-omap2/io.c: 'common.h'
- arch/arm/mach-omap2/omap_hwmod_44xx_data.c: 'plat/i2c.h'
Remove the duplicates.
Signed-off-by: Danny Kukawka <danny.kukawka@bisect.de>
Signed-off-by: Tony Lindgren <tony@atomide.com>
arch/arm/plat-omap/clock.c: included 'linux/debugfs.h' twice,
remove the duplicate.
Signed-off-by: Danny Kukawka <danny.kukawka@bisect.de>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Cleanup: don't build mach-omap2/hwspinlock.c if the OMAP hwspinlock
driver isn't configured.
This will both shorten build time and avoid registering a device
which isn't needed.
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
If platform data is provided by the caller gpio_pendown is put into
unused static ads7846_config structure and effectively has no effect.
Of course caller can set gpio_pendown field in platform data himself
but it seems natural to do this in ads7846_init to remove duplication.
Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
Signed-off-by: Ilya Yanok <yanok@emcraft.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
It turned out wrong OMAP HSUSB port was configured on pandora,
but still managed to work somehow. This was noticed after enabling
in-kernel mux, where USB muxing was causing other devices not to work,
because hsusb1 pins (instead of hsusb2) were wrongly remuxed, which
are used for other things on pandora.
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Update SRAM start & size for am33xx SoC's.
Note: cpu_is_34xx() is true for am33xx also. Doing
cpu_is_am33xx() check after cpu_is_34xx() will not
achieve what we want due to the above reason.
Hence cpu_is_am33xx() is done before cpu_is_34xx()
Signed-off-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
Signed-off-by: Afzal Mohammed <afzal@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Determine SoC type, i.e. whether GP or HS
Note: cpu_is_34xx() is true for am33xx also. Doing
cpu_is_am33xx() check after cpu_is_34xx() will not
achieve what we want due to the above reason.
Hence cpu_is_am33xx() is done before cpu_is_34xx()
Signed-off-by: Afzal Mohammed <afzal@ti.com>
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
To be able to compile kernel/drivers/mtd/nand/omap2.ko as module, that
two symbols need to be exported. Otherwise, I get following error
message
ERROR: "gpmc_calculate_ecc" [drivers/mtd/nand/omap2.ko] undefined!
ERROR: "gpmc_enable_hwecc" [drivers/mtd/nand/omap2.ko] undefined!
Signed-off-by: Bernhard Walle <walle@corscience.de>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Since omap_dm_timer_write_reg/__omap_dm_timer_write is now modified
to use timer->func_base OCP_CFG should not use this wrapper anymore.
Instead use __raw_writel() directly and use timer->io_base instead
to write to OCP_CFG.
The timer->sys_stat is valid only if timer->revision is 1. In the
context restore function make this correction.
Save the contexts and loss count when timer is stopped.
Also, disable the clock. Else, clock usecount would become imbalanced.
Signed-off-by: Tarun Kanti DebBarma <tarun.kanti@ti.com>
Tested-by: Omar Ramirez Luna <omar.ramirez@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
This reverts commit c295fb633e.
This makes existing .config files bloated by selecting in all
omaps as noted by Russell King - ARM Linux <linux@arm.linux.org.uk>.
Signed-off-by: Tony Lindgren <tony@atomide.com>
Our TLB ops want to check the vma vm_flags to find out whether the
mapping is executable. However, we leave this uninitialized in
ecard.c. Initialize it with an appropriate value.
Reported-by: Al Viro <viro@ftp.linux.org.uk>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Arnd Bergmann