Pull fbdev updates for 3.4 from Florian Tobias Schandinat:
- drivers for Samsung Exynos MIPI DSI and display port
- i740fb to support those old Intel chips
- large updates to OMAP, viafb and sh_mobile_lcdcfb
- some updates to s3c-fb and udlfb, few patches to others
Fix up conflicts in drivers/video/udlfb.c due to Key Sievers' fix making
it in twice.
* tag 'fbdev-updates-for-3.4' of git://github.com/schandinat/linux-2.6: (156 commits)
Revert "video:uvesafb: Fix oops that uvesafb try to execute NX-protected page"
OMAPDSS: register dss drivers in module init
video: pxafb: add clk_prepare/clk_unprepare calls
fbdev: bfin_adv7393fb: Drop needless include
fbdev: sh_mipi_dsi: add extra phyctrl for sh_mipi_dsi_info
fbdev: remove dependency of FB_SH_MOBILE_MERAM from FB_SH_MOBILE_LCDC
Revert "MAINTAINERS: add entry for exynos mipi display drivers"
fbdev: da8xx: add support for SP10Q010 display
fbdev: da8xx:: fix reporting of the display timing info
drivers/video/pvr2fb.c: ensure arguments to request_irq and free_irq are compatible
OMAPDSS: APPLY: fix clearing shadow dirty flag with manual update
fbdev: sh_mobile_meram: Implement system suspend/resume
fbdev: sh_mobile_meram: Remove unneeded sanity checks
fbdev: sh_mobile_meram: Don't perform update in register operation
arm: mach-shmobile: Constify sh_mobile_meram_cfg structures
fbdev: sh_mobile_lcdc: Don't store copy of platform data
fbdev: sh_mobile_meram: Remove unused sh_mobile_meram_icb_cfg fields
arm: mach-shmobile: Don't set MERAM ICB numbers in platform data
fbdev: sh_mobile_meram: Allocate ICBs automatically
fbdev: sh_mobile_meram: Use genalloc to manage MERAM allocation
...
Pull input subsystem updates from Dmitry Torokhov:
"- we finally merged driver for USB version of Synaptics touchpads
(I guess most commonly found in IBM/Lenovo keyboard/touchpad combo);
- a bunch of new drivers for embedded platforms (Cypress
touchscreens, DA9052 OnKey, MAX8997-haptic, Ilitek ILI210x
touchscreens, TI touchscreen);
- input core allows clients to specify desired clock source for
timestamps on input events (EVIOCSCLOCKID ioctl);
- input core allows querying state of all MT slots for given event
code via EVIOCGMTSLOTS ioctl;
- various driver fixes and improvements."
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: (45 commits)
Input: ili210x - add support for Ilitek ILI210x based touchscreens
Input: altera_ps2 - use of_match_ptr()
Input: synaptics_usb - switch to module_usb_driver()
Input: convert I2C drivers to use module_i2c_driver()
Input: convert SPI drivers to use module_spi_driver()
Input: omap4-keypad - move platform_data to <linux/platform_data>
Input: kxtj9 - who_am_i check value and initial data rate fixes
Input: add driver support for MAX8997-haptic
Input: tegra-kbc - revise device tree support
Input: of_keymap - add device tree bindings for simple key matrices
Input: wacom - fix physical size calculation for 3rd-gen Bamboo
Input: twl4030-vibra - really switch from #if to #ifdef
Input: hp680_ts_input - ensure arguments to request_irq and free_irq are compatible
Input: max8925_onkey - avoid accessing input device too early
Input: max8925_onkey - allow to be used as a wakeup source
Input: atmel-wm97xx - convert to dev_pm_ops
Input: atmel-wm97xx - set driver owner
Input: add cyttsp touchscreen maintainer entry
Input: cyttsp - remove useless checks in cyttsp_probe()
Input: usbtouchscreen - add support for Data Modul EasyTouch TP 72037
...
Pull updates of sound stuff from Takashi Iwai:
"Here is the first big update chunk of sound stuff for 3.4-rc1.
In the common sound infrastructure, there are a few changes for
dynamic PCM support (used in ASoC) and a few clean-ups. Majority of
changes are found, as usual, in HD-audio and ASoC.
Some highlights of HD-audio changes:
- All the long-standing static quirk codes for Realtek codec were
finally removed by fixing and extending the Realtek auto-parser.
- The mute-LED control is standardized over all HD-audio codec
drivers using the extended vmaster hook.
- The vmaster slave mixer elements are initialized to 0dB as default
so that the user won't be annoyed by the silent output after
updates, e.g. due to the additions of new elements.
- Other many fix-ups for the misc HD-audio devices.
In the ASoC side, this is a very active release, including a quite a
few framework enhancements. Some highlights:
- Support for widgets not associated with a CODEC, an important part
of the dynamic PCM framework.
- A library factoring out the common code shared by dmaengine based
DMA drivers contributed by Lars-Peter Clausen. This will save a
lot of code and make it much easier to deploy enhancements to
dmaengine.
- Support for binary controls, used for providing runtime
configuration of algorithm coefficients.
- A new DAPM widget type for regulator supplies allowing drivers for
devices that can power down unused supplies while active to do
without any per-driver code.
- DAPM widgets for DAIs, initially giving a speed boost for playback
startup and shutdown and also the basis for CODEC<->CODEC DAI link
support.
- Support for specifying the number of significant bits on audio
interfaces, useful for allowing applications to know how much
effort to put into generating data for a larger sample format.
- Conversion of the FSI driver used on some SH processors to
DMAEngine.
- Conversion of EP93xx drivers to DMAEngine.
- New CODEC drivers for Maxim MAX9768 and Wolfson Microelectronics
WM2200.
- Move audmux driver from arc/arm to sound/soc
- McBSP move from arch/ to sound/ and updates
Also, a few small updates and fixes for other drivers like au88x0,
ymfpci, USB 6fire, USB usx2yaudio are included."
* tag 'sound-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (446 commits)
ASoC: wm8994: Provide VMID mode control and fix default sequence
ASoC: wm8994: Add missing break in resume
ASoC: wm_hubs: Don't actively manage LINEOUT_VMID_BUF
ASoC: pxa-ssp: atomically set stream active masks
ASoC: fsl: p1022ds: tell the WM8776 codec driver that it's the master
ASoC: Samsung: Added to support mono recording
ALSA: hda - Fix build with CONFIG_PM=n
ALSA: au88x0 - Avoid possible Oops at unbinding
ALSA: usb-audio - Fix build error by consitification of rate list
ASoC: core: Fix obscure leak of runtime array
ALSA: pcm - Avoid GFP_ATOMIC in snd_pcm_link()
ALSA: pcm: Constify the list in snd_pcm_hw_constraint_list
ASoC: wm8996: Add 44.1kHz support
ALSA: hda - Fix build of patch_sigmatel.c without CONFIG_SND_HDA_POWER_SAVE
ASoC: mx27vis-aic32x4: Convert it to platform driver
ALSA: hda - fix printing of high HDMI sample rates
ALSA: ymfpci - Fix legacy registers on S3/S4 resume
ALSA: control - Fixe a trailing white space error
ALSA: hda - Add expose_enum_ctl flag to snd_hda_add_vmaster_hook()
ALSA: hda - Add "Mute-LED Mode" enum control
...
Pull irq_domain support for all architectures from Grant Likely:
"Generialize powerpc's irq_host as irq_domain
This branch takes the PowerPC irq_host infrastructure (reverse mapping
from Linux IRQ numbers to hardware irq numbering), generalizes it,
renames it to irq_domain, and makes it available to all architectures.
Originally the plan has been to create an all-new irq_domain
implementation which addresses some of the powerpc shortcomings such
as not handling 1:1 mappings well, but doing that proved to be far
more difficult and invasive than generalizing the working code and
refactoring it in-place. So, this branch rips out the 'new'
irq_domain and replaces it with the modified powerpc version (in a
fully bisectable way of course). It converts all users over to the
new API and makes irq_domain selectable on any architecture.
No architecture is forced to enable irq_domain, but the infrastructure
is required for doing OpenFirmware style irq translations. It will
even work on SPARC even though SPARC has it's own mechanism for
translating irqs at boot time. MIPS, microblaze, embedded x86 and c6x
are converted too.
The resulting irq_domain code is probably still too verbose and can be
optimized more, but that can be done incrementally and is a task for
follow-on patches."
* tag 'irqdomain-for-linus' of git://git.secretlab.ca/git/linux-2.6: (31 commits)
dt: fix twl4030 for non-dt compile on x86
mfd: twl-core: Add IRQ_DOMAIN dependency
devicetree: Add empty of_platform_populate() for !CONFIG_OF_ADDRESS (sparc)
irq_domain: Centralize definition of irq_dispose_mapping()
irq_domain/mips: Allow irq_domain on MIPS
irq_domain/x86: Convert x86 (embedded) to use common irq_domain
ppc-6xx: fix build failure in flipper-pic.c and hlwd-pic.c
irq_domain/microblaze: Convert microblaze to use irq_domains
irq_domain/powerpc: Replace custom xlate functions with library functions
irq_domain/powerpc: constify irq_domain_ops
irq_domain/c6x: Use library of xlate functions
irq_domain/c6x: constify irq_domain structures
irq_domain/c6x: Convert c6x to use generic irq_domain support.
irq_domain: constify irq_domain_ops
irq_domain: Create common xlate functions that device drivers can use
irq_domain: Remove irq_domain_add_simple()
irq_domain: Remove 'new' irq_domain in favour of the ppc one
mfd: twl-core.c: Fix the number of interrupts managed by twl4030
of/address: add empty static inlines for !CONFIG_OF
irq_domain: Add support for base irq and hwirq in legacy mappings
...
This patch allows us to drop the OMAP dependency from the OMAP4 keypad
driver.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Sourav Poddar <sourav.poddar@ti.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
The McBSP driver stack has been moved to ASoC. The CONFIG_OMAP_MCBSP will
be removed since the CONFIG_SND_OMAP_SOC_MCBSP will trigger to build the
McBSP (audio) drivers.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Liam Girdwood <lrg@ti.com>
On OMAP2/3 McBSP1 port has 6 pin setup, while on OMAP4 the port is McBSP4.
Implement the CLKR/FSR clock mux selection for OMAP4, and make sure that
we add the correct callback for the correct port across supported OMAP
versions.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Acked-by: Jarkko Nikula <jarkko.nikula@bitmer.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Liam Girdwood <lrg@ti.com>
The OMAP McBSP driver stack used to contain two different
drivers. One of them was used as kind low-level access to
the IP, while the other driver was the ASoC DAI driver.
There were global, shared structures, in different places,
the McBSP instances are reffered with id numbers (sometimes
0 based, in other cases 1 based id numbers).
Create one single driver for OMAP McBSP with name: omap-mcbsp.
Convert the old omap-mcbsp driver initially to be a library
for the omap-mcbsp DAI driver. With this change we can get rid
of all global variables, structures.
Further cleanup is coming...
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: Grazvydas Ignotas <notasas@gmail.com>
Tested-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Jarkko Nikula <jarkko.nikula@bitmer.com>
Signed-off-by: Liam Girdwood <lrg@ti.com>
Convert the plat-omap/mcbsp.c driver to be proper platform driver.
Remove the omap_mcbsp_init function call which was called from
mach-omap1/2/mcbsp.c to register the platform driver for the just
created platform device in the same function.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Tested-by: Grazvydas Ignotas <notasas@gmail.com>
Tested-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Acked-by: Jarkko Nikula <jarkko.nikula@bitmer.com>
Signed-off-by: Liam Girdwood <lrg@ti.com>
The cpu_is_omap4430() macro always return with 0. Use the correct
cpu_is_omap443x() to check for Panda revision.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Liam Girdwood <lrg@ti.com>
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
This has been a very active release for ASoC, as well as the usual raft
of bugfixes and driver updates there's quite a few framework enhancements.
Most are either small or are laying the groundwork for user visible
features (especially dynamic PCM), the most directly visible change is
the dmaengine library. There's also a bunch of regmap API enhancements
pulled into the tree so that either the framework or drivers can take
advantage of the new features.
Changes include:
- Support for widgets not associated with a CODEC, an important part of
the dynamic PCM framework.
- A library factoring out the common code shared by dmaengine based DMA
drivers contributed by Lars-Peter Clausen. This will save a lot of
code and make it much easier to deploy enhancements to dmaengine.
- Support for binary controls, used for providing runtime configuration
of algorithm coefficients.
- A new DAPM widget type for regulator supplies allowing drivers for
devices that can power down unused supplies while active to do without
any per-driver code.
- DAPM widgets for DAIs, initially giving a speed boost for playback
startup and shutdown and also the basis for CODEC<->CODEC DAI link
support.
- Support for specifying the number of significant bits on audio
interfaces, useful for allowing applications to know how much effort to
put into generating data for a larger sample format.
- Conversion of the FSI driver used on some SH processors to DMAEngine.
- New CODEC drivers for Maxim MAX9768 and Wolfson Microelectronics WM2200.
Add missing break statement in the function omap3xxx_check_revision.
The commit id 4390f5b2cb [ARM: OMAP: TI814X: Add cpu type macros
and detection support], removed the 'break' statement from the function
omap3xxx_check_revision(), resulting into wrong omap/cpu_revision
initialization for AM335x devices.
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
[tony@atomide.com: refreshed to apply after changes to cpu_rev]
Signed-off-by: Tony Lindgren <tony@atomide.com>
Arnd Bergmann says:
"Another set of arm-soc bug fixes on top of v3.3-rc5. The few larger
bits are all for devices that still need to get set up in board code.
Only three platforms are in this set of fixes: omap2+, pxa and lpc32xx."
* tag 'fixes-3.3-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (22 commits)
ARM: LPC32xx: serial.c: Fixed loop limit
ARM: LPC32xx: serial.c: HW bug workaround
ARM: LPC32xx: irq.c: Clear latched event
ARM: LPC32xx: Fix interrupt controller init
ARM: LPC32xx: Fix irq on GPI_28
ARM: OMAP2: fix mailbox init code
ARM: OMAP2+: gpmc-smsc911x: add required smsc911x regulators
ARM: OMAP1: Fix out-of-bounds array access for Innovator
OMAP3 EVM: remove out-of-bounds array access of gpio_leds
ARM: OMAP: Fix build error when mmc_omap is built as module
ARM: OMAP: Fix kernel panic with HSMMC when twl4030_gpio is a module
pxa/hx4700: add platform device and I2C info for AK4641 codec
arch/arm/mach-pxa/: included linux/gpio.h twice
arch/arm/mach-mmp/: some files include some headers twice
ARM: pxa: fix error handling in pxa2xx_drv_pcmcia_probe
ARM: pxa: fix including linux/gpio.h twice
ARM: pxa: fix mixed declarations and code in sharpsl_pm
ARM: pxa: fix wrong parsing gpio event on spitz
ARM: OMAP2+: usb-host: fix compile warning
ARM: OMAP4: Move the barrier memboclk_steal() as part of reserve callback
...
VUSB is a fixed regulator, so get rid of the apply_uV constraint
for it, which fixes the following error seen at boot on omap4
SDP and PANDA boards.
machine_constraints_voltage: VUSB: failed to apply 3300000uV constraint
twl_reg twl_reg.46: can't register VUSB, -22
twl_reg: probe of twl_reg.46 failed with error -22
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
IOMMU fixes for Linux 3.3-rc5
All the fixes are for the OMAP IOMMU driver. The first patch is the
biggest one. It fixes the calls of the function omap_find_iovm_area() in
the omap-iommu-debug module which expects a 'struct device' parameter
since commit fabdbca instead of an omap_iommu handle. The
omap-iommu-debug code still passed the handle to the function which
caused a crash.
The second patch fixes a NULL pointer dereference in the OMAP code and
the third patch makes sure that the omap-iommu is initialized before the
omap-isp driver, which relies on the iommu. The last patch is only a
workaround until defered probing is implemented.
* tag 'iommu-fixes-v3.3-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu:
ARM: OMAP: make iommu subsys_initcall to fix builtin omap3isp
iommu/omap: fix NULL pointer dereference
iommu/omap: fix erroneous omap-iommu-debug API calls
Fix this:
arch/arm/mach-omap2/mailbox.c: In function 'omap2_mbox_probe':
arch/arm/mach-omap2/mailbox.c:354: error: 'omap2_mboxes' undeclared (first use in this function)
arch/arm/mach-omap2/mailbox.c:354: error: (Each undeclared identifier is reported only once
arch/arm/mach-omap2/mailbox.c:354: error: for each function it appears in.)
Which happens on CONFIG_ARCH_OMAP2 && !CONFIG_SOC_OMAP2420, due to
missing omap2_mboxes declaration.
In addition, make sure we declare the right mailbox instances for 2430.
Reported-by: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Cc: Hiroshi Doyu <hdoyu@nvidia.com>
Cc: Omar Ramirez Luna <omar.ramirez@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
This fixes smsc911x support on platforms using gpmc_smsc911x_init().
Commit c7e963f688 (net/smsc911x: Add regulator support) added
the requirement that platforms provide vdd33a and vddvario supplies.
Signed-off-by: Matt Porter <mporter@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
A few more things this time around. The only thing warranting some
commentry is the modpost change, which allows folk building a Thumb2
enabled kernel to see section mismatch warnings. This is why many
weren't noticed with OMAP.
* 'fixes' of git://git.linaro.org/people/rmk/linux-arm:
ARM/audit: include audit header and fix audit arch
ARM: OMAP: fix voltage domain build errors with PM_OPP disabled
ARM/PCI: Remove ARM's duplicate definition of 'pcibios_max_latency'
ARM: 7336/1: smp_twd: Don't register CPUFREQ notifiers if local timers are not initialised
ARM: 7327/1: need to include asm/system.h in asm/processor.h
ARM: 7326/2: PL330: fix null pointer dereference in pl330_chan_ctrl()
ARM: 7164/3: PL330: Fix the size of the dst_cache_ctrl field
ARM: 7325/1: fix v7 boot with lockdep enabled
ARM: 7324/1: modpost: Fix section warnings for ARM for many compilers
ARM: 7323/1: Do not allow ARM_LPAE on pre-ARMv7 architectures
Otherwise we can get the following warning on some compilers:
arch/arm/mach-omap2/board-omap3evm.c:384:11:
warning: array subscript is above array bounds
The omap3evm BSP enables a GPIO LED on the twl4030 chip. However,
the static gpio_leds array doesn't have an entry for it. This is
most likely a copy-and-paste error, because it has been in there
since the first commit of the omap3evm BSP (53c5ec31).
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
[tony@atomide.com: updated comments with the warning]
Signed-off-by: Tony Lindgren <tony@atomide.com>
The voltage domain code wants the voltage tables, which are in the
opp*.c files. These files aren't built when PM_OPP is disabled,
causing the following build errors at link time:
twl-common.c:(.init.text+0x2e48): undefined reference to `omap34xx_vddmpu_volt_data'
twl-common.c:(.init.text+0x2e4c): undefined reference to `omap34xx_vddcore_volt_data'
twl-common.c:(.init.text+0x2e5c): undefined reference to `omap36xx_vddmpu_volt_data'
twl-common.c:(.init.text+0x2e60): undefined reference to `omap36xx_vddcore_volt_data'
twl-common.c:(.init.text+0x2830): undefined reference to `omap44xx_vdd_mpu_volt_data'
twl-common.c:(.init.text+0x283c): undefined reference to `omap44xx_vdd_iva_volt_data'
twl-common.c:(.init.text+0x2844): undefined reference to `omap44xx_vdd_core_volt_data'
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Otherwise we get the following error:
arch/arm/mach-omap2/built-in.o: In function `n8x0_mmc_callback':
twl-common.c:(.text+0x108a0): undefined reference to
`omap_mmc_notify_cover_event'
Fix this by warning about unusable MMC cover events.
The long term fix needs to change the MMC drivers to
register board specific callbacks directly with PMIC.
Reported-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Tony Lindgren <tony@atomide.com>
On some omaps twl4030_gpio has a callback to try to initialize
the MMC controller. If twl4030_gpio is compiled as a module,
bad things can happen because the callback function starts
calling functions that are supposed to be marked __init:
Kernel panic - not syncing: Attempted to kill the idle task!
twl4030_gpio twl4030_gpio: can't dispatch IRQs from modules
gpiochip_add: registered GPIOs 192 to 209 on device: twl4030
Unable to handle kernel paging request at virtual address b82a4c74
...
Additionally if this does not fail, warnings are produced
about trying to register the MMC multiple times.
Fix this by removing __init from omap_mux_get_by_name,
and add checks if omap2_hsmmc_init() is getting called more
than once.
Note that this will get fixed properly later on by splitting
omap2_hsmmc_init into two functions.
Reported-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Tony Lindgren <tony@atomide.com>
These are the bug fixes that have accumulated since 3.3-rc3 in arm-soc.
The majority of them are regression fixes for stuff that broke during
the merge 3.3 window.
The notable ones are:
* The at91 ata drivers both broke because of an earlier cleanup patch that
some other patches were based on. Jean-Christophe decided to remove
the legacy at91_ide driver and fix the new-style at91-pata driver while
keeping the cleanup patch. I almost rejected the patches for being too
late and too big but in the end decided to accept them because they
fix a regression.
* A patch fixing build breakage from the sysdev-to-device conversion
colliding with other changes touches a number of mach-s3c files.
* b0654037 "ARM: orion: Fix Orion5x GPIO regression from MPP cleanup"
is a mechanical change that unfortunately touches a lot of lines
that should up in the diffstat.
* tag 'fixes-3.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (28 commits)
ARM: at91: drop ide driver in favor of the pata one
pata/at91: use newly introduced SMC accessors
ARM: at91: add accessor to manage SMC
ARM: at91:rtc/rtc-at91sam9: ioremap register bank
ARM: at91: USB AT91 gadget registration for module
ep93xx: fix build of vision_ep93xx.c
ARM: OMAP2xxx: PM: fix OMAP2xxx-specific UART idle bug in v3.3
ARM: orion: Fix USB phy for orion5x.
ARM: orion: Fix Orion5x GPIO regression from MPP cleanup
ARM: EXYNOS: Add cpu-offset property in gic device tree node
ARM: EXYNOS: Bring exynos4-dt up to date
ARM: OMAP3: cm-t35: fix section mismatch warning
ARM: OMAP2: Fix the OMAP2 only build break seen with 2011+ ARM tool-chains
ARM: tegra: paz00: fix wrong UART port on mini-pcie plug
ARM: tegra: paz00: fix wrong SD1 power gpio
i2c: tegra: Add devexit_p() for remove
ARM: EXYNOS: Correct M-5MOLS sensor clock frequency on Universal C210 board
ARM: EXYNOS: Correct framebuffer window size on Nuri board
ARM: SAMSUNG: Fix missing api-change from subsys_interface change
ARM: EXYNOS: Fix "warning: initialization from incompatible pointer type"
...
irq_domain_add_simple() was a stop-gap measure until complete irq_domain
support was complete. This patch removes the irq_domain_add_simple()
interface.
This patch also drops the explicit irq_domain initialization performed
by the mach-versatile code because the versatile interrupt controller
already has irq_domain support built into it. This was a bug that was
hanging around quietly for a while, but with the full irq_domain which
actually verifies that irq_domain ranges are available it would cause
the registration to fail and the system wouldn't boot.
v4: Fixed number of irqs in mx5 gpio code
v2: Updated to pass in host_data pointer on irq_domain allocation.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Milton Miller <miltonm@bga.com>
Cc: Russell King <linux@arm.linux.org.uk>
Tested-by: Olof Johansson <olof@lixom.net>
when commit 3528c58 (OMAP: omap_device: when
building return platform_device instead of
omap_device) started returning a platform_device
instead of a omap_device pointer when building
a device, it failed to convert all users introducing
a compile warning when building
arch/arm/mach-omap2/usb-host.c.
This patch fixes that warning.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
arm_memblock_steal() is not suppose to be used outside ->reserve callback.
OMAP barrier errata code was using it outside reserve callback and hence
it was broken.
Move the allocation as part of ->reserve callback to fix the it.
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
OMAP4 cpuidle driver is reporting the state requested by governor
rather than the actually attempted one.
This is obviously misleading sysfs and powertop cpuidle statistics.
Fix it so that stats are reported correctly.
Reported-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
[khilman@ti.com: minor changelog edits]
Signed-off-by: Kevin Hilman <khilman@ti.com>
opp_find_freq_ceil and opp_get_voltage are documented as requiring
rcu_lock to be held. So hold it.
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Kevin Hilman <khilman@ti.com>
This set of changes are fixing various section mismatch warnings which
look to be completely valid. Primerily, those which are fixed are those
which can cause oopses by manipulation of driver binding via sysfs. For
example: calling code marked __init from driver probe __devinit
functions.
Some of these changes will be reworked at the next merge window when the
underlying reasons are sorted out. In the mean time, I think it's
important to have this fixed for correctness.
Also included in this set are fixes to various error messages in OMAP -
including making them gramatically correct, fixing a few spelling
errors, and more importantly, making them greppable by unwrapping them.
Tony Lindgren has acked all these patches, put them out for testing a
week ago, and I've tested them on the platforms I have.
* 'omap-fixes-warnings' of git://git.linaro.org/people/rmk/linux-arm:
ARM: omap: resolve nebulous 'Error setting wl12xx data'
ARM: omap: fix wrapped error messages in omap_hwmod.c
ARM: omap: fix section mismatch warnings in mux.c caused by hsmmc.c
ARM: omap: fix section mismatch warning for sdp3430_twl_gpio_setup()
ARM: omap: fix section mismatch error for omap_4430sdp_display_init()
ARM: omap: fix section mismatch warning for omap_secondary_startup()
ARM: omap: preemptively fix section mismatch in omap4_sdp4430_wifi_mux_init()
ARM: omap: fix section mismatch warning in mux.c
ARM: omap: fix section mismatch errors in TWL PMIC driver
ARM: omap: fix uninformative vc/i2c configuration error message
ARM: omap: fix vc.c PMIC error message
ARM: omap: fix prm44xx.c OMAP44XX_IRQ_PRCM build error
This pull request covers the major oopsing issues with OMAP, caused by
the lack of the TWL driver. Even when the TWL driver is not built in,
we shouldn't oops.
* 'omap-fixes-urgent' of git://git.linaro.org/people/rmk/linux-arm:
ARM: omap: fix broken twl-core dependencies and ifdefs
ARM: omap: fix oops in drivers/video/omap2/dss/dpi.c
ARM: omap: fix oops in arch/arm/mach-omap2/vp.c when pmic is not found
It's useful to print the error code when a called function fails so a
diagnosis of why it failed is possible. In this case, it fails because
we try to register some data for the wl12xx driver, but as the driver
is not configured, a stub function is used which simply returns -ENOSYS.
Let's do the simple thing for -rc and print the error code.
Also, the return code from platform_register_device() at each of these
sites was not being checked. Add some checking, and again print the
error code.
This should be fixed properly for the next merge window so we don't
issue error messages merely because a driver is not configured.
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
While trying to debug my OMAP platforms, they emitted this message:
omap_hwmod: %s: enabled state can only be entered from initialized, idle, or disabled state
The following backtrace said it was from a function called '_enable',
which didn't provide much clue. Grepping didn't find it either.
The message is wrapped, so unwrap the message so grep can find it. Do
the same for three other messages in this file.
Acked-by: Paul Walmsley <paul@pwsan.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The previous commit causes new section mismatch warnings:
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdb30): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_gpio()
The function omap_init_hsmmc() references
the function __init omap_mux_init_gpio().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_gpio is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdb4c): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_gpio()
The function omap_init_hsmmc() references
the function __init omap_mux_init_gpio().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_gpio is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdb60): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdb6c): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdb78): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdb90): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdb9c): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdba8): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdbc0): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdbcc): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdbd8): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdbf8): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc04): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc10): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc28): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc34): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc40): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc58): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc64): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc70): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc7c): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
Again, as for omap2_hsmmc_init(), these functions are callable at
runtime via the gpio-twl4030.c driver, and so these can't be marked
__init.
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xd0f0): Section mismatch in reference from the function sdp3430_twl_gpio_setup() to the function .init.text:omap2_hsmmc_init()
The function sdp3430_twl_gpio_setup() references
the function __init omap2_hsmmc_init().
This is often because sdp3430_twl_gpio_setup lacks a __init
annotation or the annotation of omap2_hsmmc_init is wrong.
sdp3430_twl_gpio_setup() is called via platform data from the
gpio-twl4030 module, which can be inserted and removed at runtime.
This makes sdp3430_twl_gpio_setup() callable at runtime, and prevents
it being marked with an __init annotation.
As it calls omap2_hsmmc_init() unconditionally, the only resolution to
this warning is to remove the __init markings from omap2_hsmmc_init()
and its called functions. This addresses the functions in hsmmc.c.
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xb798): Section mismatch in reference from the function omap_4430sdp_display_init() to the function .init.text:omap_display_init()
The function omap_4430sdp_display_init() references
the function __init omap_display_init().
This is often because omap_4430sdp_display_init lacks a __init
annotation or the annotation of omap_display_init is wrong.
Fix this by adding __init to omap_4430sdp_display_init().
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
WARNING: vmlinux.o(.text+0x1c664): Section mismatch in reference from the function omap_secondary_startup() to the function .cpuinit.text:secondary_startup()
The function omap_secondary_startup() references
the function __cpuinit secondary_startup().
This is often because omap_secondary_startup lacks a __cpuinit
annotation or the annotation of secondary_startup is wrong.
Unfortunately, fixing this causes a new warning which is harder to
solve:
WARNING: arch/arm/mach-omap2/built-in.o(.text+0x5328): Section mismatch in reference from the function omap4_hotplug_cpu() to the function .cpuinit.text:omap_secondary_startup()
The function omap4_hotplug_cpu() references
the function __cpuinit omap_secondary_startup().
This is often because omap4_hotplug_cpu lacks a __cpuinit
annotation or the annotation of omap_secondary_startup is wrong.
because omap4_hotplug_cpu() is used by power management code as well,
which may not end up using omap_secondary_startup().
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Found by review.
omap4_sdp4430_wifi_mux_init() is called by an __init marked function,
and only calls omap_mux_init_gpio() and omap_mux_init_signal() which
are both also an __init marked functions.
The only reason this doesn't issue a warning is because the compiler
inlines omap4_sdp4430_wifi_mux_init() into omap4_sdp4430_wifi_init().
So, lets add the __init annotation to ensure this remains safe should
the compiler choose not to inline.
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
