Commit Graph

94 Commits

Author SHA1 Message Date
Stefan Agner afda768f88 ARM: OMAP2+: remove superfluous NULL pointer check
The NULL pointer check for superset->muxnames will always evaluate
true since muxnames is an array within struct omap_mux. Remove the
superfluous check to avoid warnings when using LLVM/clang.

Signed-off-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Tony Lindgren <tony@atomide.com>
2015-03-26 10:33:25 -07:00
Joe Perches 3d0cb73e9c arm: mach-omap2: Convert pr_warning to pr_warn
Use the more common pr_warn.

Other miscellanea:

o Realign arguments

Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
2014-09-18 09:53:57 -07:00
Daniel Walter 056610ac14 arch/arm/mach-omap2: replace strict_strto* with kstrto*
Replace obsolete strict_strto call with kstrto calls.
Simplify copy_from_user/strict_strto by using kstrto_from_user

Signed-off-by: Daniel Walter <dwalter@google.com>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-08-08 15:57:27 -07:00
David R. Piegdon c021f241f4 ARM: OMAP2+: Fix parser-bug in platform muxing code
Fix a parser-bug in the omap2 muxing code where muxtable-entries will be
wrongly selected if the requested muxname is a *prefix* of their
m0-entry and they have a matching mN-entry. Fix by additionally checking
that the length of the m0_entry is equal.

For example muxing of "dss_data2.dss_data2" on omap32xx will fail
because the prefix "dss_data2" will match the mux-entries "dss_data2" as
well as "dss_data20", with the suffix "dss_data2" matching m0 (for
dss_data2) and m4 (for dss_data20). Thus both are recognized as signal
path candidates:

Relevant muxentries from mux34xx.c:
        _OMAP3_MUXENTRY(DSS_DATA20, 90,
                "dss_data20", NULL, "mcspi3_somi", "dss_data2",
                "gpio_90", NULL, NULL, "safe_mode"),
        _OMAP3_MUXENTRY(DSS_DATA2, 72,
                "dss_data2", NULL, NULL, NULL,
                "gpio_72", NULL, NULL, "safe_mode"),

This will result in a failure to mux the pin at all:

 _omap_mux_get_by_name: Multiple signal paths (2) for dss_data2.dss_data2

Patch should apply to linus' latest master down to rather old linux-2.6
trees.

Signed-off-by: David R. Piegdon <lkml@p23q.org>
Cc: stable@vger.kernel.org
[tony@atomide.com: updated description to include full description]
Signed-off-by: Tony Lindgren <tony@atomide.com>
2014-06-17 01:05:43 -07:00
Victor Kamensky edfaf05c2f ARM: OMAP2+: raw read and write endian fix
All OMAP IP blocks expect LE data, but CPU may operate in BE mode.
Need to use endian neutral functions to read/write h/w registers.
I.e instead of __raw_read[lw] and __raw_write[lw] functions code
need to use read[lw]_relaxed and write[lw]_relaxed functions.
If the first simply reads/writes register, the second will byteswap
it if host operates in BE mode.

Changes are trivial sed like replacement of __raw_xxx functions
with xxx_relaxed variant.

Signed-off-by: Victor Kamensky <victor.kamensky@linaro.org>
Signed-off-by: Taras Kondratiuk <taras.kondratiuk@linaro.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
2014-05-08 07:09:53 -07:00
Tony Lindgren 30a69ef785 ARM: OMAP: Move DT wake-up event handling over to use pinctrl-single-omap
Now pinctrl-single-omap can handle the wake-up events for us now
as long as the events are configured in the .dts files.

Done in collaboration with Roger Quadros <rogerq@ti.com>.

Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Grygorii Strashko <grygorii.strashko@ti.com>
Cc: Prakash Manjunathappa <prakash.pm@ti.com>
Cc: Roger Quadros <rogerq@ti.com>
Cc: Haojian Zhuang <haojian.zhuang@linaro.org>
Cc: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Kevin Hilman <khilman@linaro.org>
Tested-by: Kevin Hilman <khilman@linaro.org>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
2013-10-10 15:46:30 -07:00
Ruslan Bilovol 39bb356ee6 ARM: OMAP2+: mux: correct wrong error messages
This is needed because the omap_mux_get_by_name()
function calls the _omap_mux_get_by_name subfunction
for each mux partition until needed mux is not found.
As a result, we get messages like
"Could not find signal XXX" for each partition
where this mux name does not exist.

This patch fixes wrong error message in
the _omap_mux_get_by_name() function moving it
to the omap_mux_get_by_name() one and as result
reduces noise in the kernel log.

My kernel log without this patch:
[...]
[    0.221801] omap_mux_init: Add partition: #2: wkup, flags: 3
[    0.222045] _omap_mux_get_by_name: Could not find signal fref_clk0_out.sys_drm_msecure
[    0.222137] _omap_mux_get_by_name: Could not find signal sys_nirq
[    0.222167] _omap_mux_get_by_name: Could not find signal sys_nirq
[    0.225006] _omap_mux_get_by_name: Could not find signal uart1_rx.uart1_rx
[    0.225006] _omap_mux_get_by_name: Could not find signal uart1_rx.uart1_rx
[    0.270111] _omap_mux_get_by_name: Could not find signal fref_clk4_out.fref_clk4_out
[    0.273406] twl: not initialized

[...]

My kernel log with this patch:
[...]
[    0.221771] omap_mux_init: Add partition: #2: wkup, flags: 3
[    0.222106] omap_mux_get_by_name: Could not find signal sys_nirq
[    0.224945] omap_mux_get_by_name: Could not find signal uart1_rx.uart1_rx
[    0.274536] twl: not initialized
[...]

Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
2013-03-04 11:37:31 -08:00
Felipe Balbi 0fa26ce9f3 ARM: OMAP2+: mux: fix debugfs file permission
OMAP's debugfs interface creates one file
for each signal in the mux table, such file
provides a read method but didn't provide
read permission. Fix it.

Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
2013-03-04 11:19:23 -08:00
Oleg Matcovschi 421e845099 OMAP2+: mux: Fixed gpio mux mode analysis
OMAP_MODE_GPIO() macro verified only OMAP_MUX_MODE4.
It is not correct for following platforms:
    2430 - gpio mux mode 3
    44xx - gpio mux mode 3
    54xx - gpio mux mode 6

Patch reserves first 3 bits in partition flags for storing gpio mux
mode in same format as stored in control pad register.
Modified OMAP_MODE_GPIO() macro to handle all possible cases of gpio mux mode.
Modified omap_mux_init() flags of omap34xx to include OMAP_MUX_GPIO_IN_MODE4.

Signed-off-by: Oleg Matcovschi <oleg.matcovschi@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-12-14 11:11:34 -08:00
Tony Lindgren e4c060db2c ARM: OMAP: Split plat/cpu.h into local soc.h for mach-omap1 and mach-omap2
We want to remove plat/cpu.h. To do this, let's first split
it to private soc.h to mach-omap1 and mach-omap2. We have to
keep plat/cpu.h around until the remaining drivers are fixed,
so let's include the local soc.h in plat/cpu.h and for drivers
still including plat/cpu.h.

Once the drivers are fixed not to include plat/cpu.h, we
can remove the file.

This is needed for the ARM common zImage support.

[tony@atomide.com: updated to not print a warning]
Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-10-18 16:23:46 -07:00
Tony Lindgren 2a296c8f89 ARM: OMAP: Make plat/omap_hwmod.h local to mach-omap2
Let's make omap_hwmod local to mach-omap2 for
ARM common zImage support.

Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-10-18 16:05:55 -07:00
Peter Senna Tschudin c09fcc438c arch/arm/mach-omap2: Remove unecessary semicolon
Found by http://coccinelle.lip6.fr/

Signed-off-by: Peter Senna Tschudin <peter.senna@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-10-08 18:09:30 -07:00
Olof Johansson a34a3b7264 Some uncontroversial OMAP clock, hwmod, and compiler warning fixes for 3.5-rc
-----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.12 (GNU/Linux)
 
 iQIcBAABAgAGBQJP474+AAoJEMePsQ0LvSpLASkP/1A8pu+UeYm13KjDqOCCg2lM
 SyKji76uiEPNRZ3OZcAqeZSs0Cs25gpPey3/9i2asL+xYYl6EHpep4YMCOuaVe5v
 a0xyuPH7H+MlfTTOvMVWOuUdSJQxKrom+BHYfNQNdi4ofGY+MpquYbeO6xg/MiYQ
 D3o6DCamosocPWB3UjXzAiYfrhqBxw6FiWDnL3IivIVboRfIkj3fy2DB1SXMPpx+
 zDYF2FCExqnWkLMYOK2rW80PAyJnXIi0ZyqjfyhXxgNvcVnjBApPNuSEsDI73bVF
 G2Ju3cfYS9VMDsVOo2rIyCR+cWrzVmpDJQDg++mAAQau7xUGgMSDsxneZhNlbedN
 mheAEhLmC1h7ddydxg7yXCRkHzlvLtBfpLTqZzbvuc55Fu7H9ZEW4/YDVHLdCid8
 iJoF6r42J9hlgjn31sKsMmCK+eeRjwHBqtOrjsf0nYyd54JEJuANKNaw+1q35Xh1
 YX+zwUQP1W+u7RPuq1fTY9GFv/ZRVR3/JotqaI+DwlT8baUanUjjank1gC3PoFps
 pPbePJOalPXRSyNAbgoykRdrFja7z3p2ZEfOq+WQAbvRmCNSsAvLwq9jYThXdIpi
 JTvuLp3qliMitFFeGEn/fpfZJBYkQloGPqQD1wNY+5s8S+kopQwduK6aexwjmxTa
 AZwSftW3lxmEBO9MJxQm
 =LDqr
 -----END PGP SIGNATURE-----

Merge tag 'omap-fixes-a-for-3.5rc' of git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into fixes

From Paul Walmsley (as per Tony Lindgren's request):
 "Some uncontroversial OMAP clock, hwmod, and compiler warning fixes for 3.5-rc"

* tag 'omap-fixes-a-for-3.5rc' of git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending:
  ARM: OMAP4: hwmod data: Force HDMI in no-idle while enabled
  ARM: OMAP2+: mux: fix sparse warning
  ARM: OMAP2+: CM: increase the module disable timeout
  ARM: OMAP4: clock data: add clockdomains for clocks used as main clocks
  ARM: OMAP4: hwmod data: fix 32k sync timer idle modes
  ARM: OMAP4+: hwmod: fix issue causing IPs not going back to Smart-Standby
  ARM: OMAP: PM: Lock clocks list while generating summary
2012-06-23 16:16:29 -07:00
Paul Walmsley 65e25976b7 ARM: OMAP2+: mux: fix sparse warning
Commit bbd707acee ("ARM: omap2: use
machine specific hook for late init") resulted in the addition of this
sparse warning:

arch/arm/mach-omap2/mux.c:791:12: warning: symbol 'omap_mux_late_init' was not declared. Should it be static?

Fix by including the header file containing the prototype.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Tony Lindgren <tony@atomide.com>
2012-06-21 18:08:47 -06:00
Govindraj.R 91930652a2 OMAP2+: UART: Add mechanism to probe uart pins and configure rx wakeup
The commit (bce492c0  ARM: OMAP2+: UART: Fix incorrect population of
default uart pads) removed default uart pads that where getting populated
and which was making rx pin wakeup capable. If uart pads were used in
different mode by any other module then it would fail since the default
pads took over all the uart pins forcefully. With removal of default pads
the rx_pad wakeup for console uart while waking up from off mode is broken.

Utilise the mux api available to probe the availability of mux pins
in uart mode and probe for availability of uart pin in mux mode0
if uart is available as uart pin itself then configure rx pin
as wakeup capable.

This patch itself doesn't cater to all boards. Boards using uart rx wakeup
mechanism should ensure the usage of omap_serial_init_port by configuring
required uart ports and pass necessary mux data, till then this probing of
uart pins can cater to enabling of rx pad wakeup to most of the boards.

This patch can also throw some boot warning from _omap_mux_get_by_name
if pin is requested for availability is not present while dynamically probing
the uart pins availability such boot warnings can be addressed only when board
files are patched with omap_serial_init_port calls passing the right pads
needed for a given port.

Discussion Threads for reference:
http://www.spinics.net/lists/linux-omap/msg69859.html
http://www.spinics.net/lists/linux-omap/msg68659.html

Cc: Felipe Balbi <balbi@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Russ Dill <russ.dill@gmail.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Ameya Palande <ameya.palande@ti.com>
Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
[tony@atomide.com: updated to fix compile when CONFIG_OMAP_MUX is not set]
Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-06-05 04:04:11 -07:00
Linus Torvalds f465d145d7 arm-soc: sweeping late_initcall cleanup
This is a patch series from Shawn Guo that moves from individual
 late_initcalls() to using a member in the machine structure to invoke
 a platform's late initcalls.
 
 This cleanup is a step in the move towards multiplatform kernels since
 it would reduce the need to check for compatible platforms in each and
 every initcall.
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.11 (GNU/Linux)
 
 iQIcBAABAgAGBQJPwHYJAAoJEIwa5zzehBx3PugP/2Wd6HN030iO5EhFBcBcrh5T
 WaJ4KfzK3tWev5QA3idvenVNhk5My1HQ+PLij7BLpjNqKCKlNK0k/K9wMI5X827T
 wkFFprdUcoMVrB1ZCjzwCk4/uTGWB5BMxoZ6mlBh1sZIR/yXo91t+wO971Uqr0ho
 Ky1oW9uaPZ6Eja00iDLkfJfygquA5+zNb0a29q19zWnHlRkH76jtqZgfDKy9I2nq
 virYZ4uhoPnY2g1JxhnaMNNC861CgfTDEtmtNjgeEbA6t9bbjqsZoQRhcYHZP4OM
 a4Iu8FOyIvAAzQzUglfAZ4Ar4uYTmVRnG39XFh4wK/8tJYt0hEQwFS26B0pYKx/5
 F76bwc4SqO7H9AWBF0WhyUbny5XmJcNwJjobm/oCeAvemTi3xA6BbubyfKMHPoIr
 dDSEqcAcMt9G6sS48h3Pm0caEYDVzxf202vdylz1JABiJZi1W/7v+NMdhujfotJh
 7IGehNRu0foPEsRIS9wsvD2TzSdQtDdjyFkGHd83XMc3JpvwmyePO6ynbbxrVnJJ
 HzlPnbLIk3VyqyVCqVXj21NKEY1dbsYPItketAwwzc1BUGcld0qvQY/t/UI4JQT6
 9vq77AwNjUhfomDdEWTp7aNx0whkY0R5KEY9jHjuu9WoE+xdPZbQKm589AJ6LA4U
 j6HPMzWKUHOKT6g10rCl
 =21h6
 -----END PGP SIGNATURE-----

Merge tag 'cleanup-initcall' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc

Pull sweeping late_initcall cleanup for arm-soc from Olof Johansson:
 "This is a patch series from Shawn Guo that moves from individual
  late_initcalls() to using a member in the machine structure to invoke
  a platform's late initcalls.

  This cleanup is a step in the move towards multiplatform kernels since
  it would reduce the need to check for compatible platforms in each and
  every initcall."

Fix up trivial conflicts in arch/arm/mach-{exynos/mach-universal_c210.c,
imx/mach-cpuimx51.c, omap2/board-generic.c} due to changes nearby (and,
in the case of cpuimx51.c the board support being deleted)

* tag 'cleanup-initcall' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
  ARM: ux500: use machine specific hook for late init
  ARM: tegra: use machine specific hook for late init
  ARM: shmobile: use machine specific hook for late init
  ARM: sa1100: use machine specific hook for late init
  ARM: s3c64xx: use machine specific hook for late init
  ARM: prima2: use machine specific hook for late init
  ARM: pnx4008: use machine specific hook for late init
  ARM: omap2: use machine specific hook for late init
  ARM: omap1: use machine specific hook for late init
  ARM: msm: use machine specific hook for late init
  ARM: imx: use machine specific hook for late init
  ARM: exynos: use machine specific hook for late init
  ARM: ep93xx: use machine specific hook for late init
  ARM: davinci: use machine specific hook for late init
  ARM: provide a late_initcall hook for platform initialization
2012-05-26 13:14:01 -07:00
Shawn Guo bbd707acee ARM: omap2: use machine specific hook for late init
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Acked-by: Tony Lindgren <tony@atomide.com>
2012-05-08 20:36:20 +08:00
Paul Walmsley eeb3711b89 ARM: OMAP2+: clean up some cppcheck warnings
Resolve some warnings identified by cppcheck in arch/arm/mach-omap2:

    [arch/arm/mach-omap2/usb-tusb6010.c:129]: (style) Checking if unsigned variable 'tmp' is less than zero.
    [arch/arm/mach-omap2/prm_common.c:241]: (error) Possible null pointer dereference: irq_setup - otherwise it is redundant to check if irq_setup is null at line 247
    [arch/arm/mach-omap2/pm34xx.c:790]: (style) Variable 'per_clkdm' is assigned a value that is never used
    [arch/arm/mach-omap2/pm34xx.c:790]: (style) Variable 'core_clkdm' is assigned a value that is never used
    [arch/arm/mach-omap2/pm24xx.c:185]: (style) Variable 'only_idle' is assigned a value that is never used
    [arch/arm/mach-omap2/mux.c:254]: (error) Possible null pointer dereference: mux
    [arch/arm/mach-omap2/mux.c:258]: (error) Possible null pointer dereference: mux
    [arch/arm/mach-omap2/gpmc-onenand.c:178]: (style) Variable 'tick_ns' is assigned a value that is never used
    [arch/arm/mach-omap2/gpio.c:56]: (error) Possible null pointer dereference: pdata - otherwise it is redundant to check if pdata is null at line 57
    [arch/arm/mach-omap2/devices.c:45]: (style) Variable 'l' is assigned a value that is never used
    [arch/arm/mach-omap2/board-omap3evm.c:641] -> [arch/arm/mach-omap2/board-omap3evm.c:639]: (style) Found duplicate branches for if and else.
    [arch/arm/mach-omap2/am35xx-emac.c:95]: (style) Variable 'regval' is assigned a value that is never used
    [arch/arm/mach-omap2/devices.c:74]: (style) Variable 'l' is assigned a value that is never used
    [arch/arm/mach-omap2/pm34xx.c:277]: (style) Variable 'per_prev_state' is assigned a value that is never used
    [arch/arm/plat-omap/dmtimer.c:352]: (error) Possible null pointer dereference: timer - otherwise it is redundant to check if timer is null at line 354
    [arch/arm/plat-omap/omap_device.c:478]: (style) Variable 'c' is assigned a value that is never used
    [arch/arm/plat-omap/usb.c:42]: (style) Variable 'status' is assigned a value that is never used
    [arch/arm/mach-omap1/clock.c:197]: (style) Variable 'dpll1_rate' is assigned a value that is never used
    [arch/arm/mach-omap1/lcd_dma.c:60]: (style) struct or union member 'lcd_dma_info::size' is never used
    [arch/arm/mach-omap1/pm.c:572]: (style) Variable 'entry' is assigned a value that is never used

Some of them are pretty good catches, such as gpio.c:56 and
usb-tusb6010.c:129.

Thanks to Jarkko Nikula for some comments on the sscanf() warnings.
It seems that the kernel sscanf() ignores the field width anyway for the
%d format, so those changes have been dropped from this second version.

Thanks to Daniel Marjamäki <daniel.marjamaki@gmail.com> for pointing
out that a variable was unnecessarily marked static in the
board-omap3evm.c change.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Jarkko Nikula <jarkko.nikula@bitmer.com>
Cc: Charulatha Varadarajan <charu@ti.com>
Cc: Daniel Marjamäki <daniel.marjamaki@gmail.com>
Cc: Tarun Kanti DebBarma <tarun.kanti@ti.com>
Reviewed-by: Charulatha Varadarajan <charu@ti.com> # for gpio.c
2012-04-17 15:50:47 -06:00
Linus Torvalds 0195c00244 Disintegrate and delete asm/system.h
-----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.12 (GNU/Linux)
 
 iQIVAwUAT3NKzROxKuMESys7AQKElw/+JyDxJSlj+g+nymkx8IVVuU8CsEwNLgRk
 8KEnRfLhGtkXFLSJYWO6jzGo16F8Uqli1PdMFte/wagSv0285/HZaKlkkBVHdJ/m
 u40oSjgT013bBh6MQ0Oaf8pFezFUiQB5zPOA9QGaLVGDLXCmgqUgd7exaD5wRIwB
 ZmyItjZeAVnDfk1R+ZiNYytHAi8A5wSB+eFDCIQYgyulA1Igd1UnRtx+dRKbvc/m
 rWQ6KWbZHIdvP1ksd8wHHkrlUD2pEeJ8glJLsZUhMm/5oMf/8RmOCvmo8rvE/qwl
 eDQ1h4cGYlfjobxXZMHqAN9m7Jg2bI946HZjdb7/7oCeO6VW3FwPZ/Ic75p+wp45
 HXJTItufERYk6QxShiOKvA+QexnYwY0IT5oRP4DrhdVB/X9cl2MoaZHC+RbYLQy+
 /5VNZKi38iK4F9AbFamS7kd0i5QszA/ZzEzKZ6VMuOp3W/fagpn4ZJT1LIA3m4A9
 Q0cj24mqeyCfjysu0TMbPtaN+Yjeu1o1OFRvM8XffbZsp5bNzuTDEvviJ2NXw4vK
 4qUHulhYSEWcu9YgAZXvEWDEM78FXCkg2v/CrZXH5tyc95kUkMPcgG+QZBB5wElR
 FaOKpiC/BuNIGEf02IZQ4nfDxE90QwnDeoYeV+FvNj9UEOopJ5z5bMPoTHxm4cCD
 NypQthI85pc=
 =G9mT
 -----END PGP SIGNATURE-----

Merge tag 'split-asm_system_h-for-linus-20120328' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-asm_system

Pull "Disintegrate and delete asm/system.h" from David Howells:
 "Here are a bunch of patches to disintegrate asm/system.h into a set of
  separate bits to relieve the problem of circular inclusion
  dependencies.

  I've built all the working defconfigs from all the arches that I can
  and made sure that they don't break.

  The reason for these patches is that I recently encountered a circular
  dependency problem that came about when I produced some patches to
  optimise get_order() by rewriting it to use ilog2().

  This uses bitops - and on the SH arch asm/bitops.h drags in
  asm-generic/get_order.h by a circuituous route involving asm/system.h.

  The main difficulty seems to be asm/system.h.  It holds a number of
  low level bits with no/few dependencies that are commonly used (eg.
  memory barriers) and a number of bits with more dependencies that
  aren't used in many places (eg.  switch_to()).

  These patches break asm/system.h up into the following core pieces:

    (1) asm/barrier.h

        Move memory barriers here.  This already done for MIPS and Alpha.

    (2) asm/switch_to.h

        Move switch_to() and related stuff here.

    (3) asm/exec.h

        Move arch_align_stack() here.  Other process execution related bits
        could perhaps go here from asm/processor.h.

    (4) asm/cmpxchg.h

        Move xchg() and cmpxchg() here as they're full word atomic ops and
        frequently used by atomic_xchg() and atomic_cmpxchg().

    (5) asm/bug.h

        Move die() and related bits.

    (6) asm/auxvec.h

        Move AT_VECTOR_SIZE_ARCH here.

  Other arch headers are created as needed on a per-arch basis."

Fixed up some conflicts from other header file cleanups and moving code
around that has happened in the meantime, so David's testing is somewhat
weakened by that.  We'll find out anything that got broken and fix it..

* tag 'split-asm_system_h-for-linus-20120328' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-asm_system: (38 commits)
  Delete all instances of asm/system.h
  Remove all #inclusions of asm/system.h
  Add #includes needed to permit the removal of asm/system.h
  Move all declarations of free_initmem() to linux/mm.h
  Disintegrate asm/system.h for OpenRISC
  Split arch_align_stack() out from asm-generic/system.h
  Split the switch_to() wrapper out of asm-generic/system.h
  Move the asm-generic/system.h xchg() implementation to asm-generic/cmpxchg.h
  Create asm-generic/barrier.h
  Make asm-generic/cmpxchg.h #include asm-generic/cmpxchg-local.h
  Disintegrate asm/system.h for Xtensa
  Disintegrate asm/system.h for Unicore32 [based on ver #3, changed by gxt]
  Disintegrate asm/system.h for Tile
  Disintegrate asm/system.h for Sparc
  Disintegrate asm/system.h for SH
  Disintegrate asm/system.h for Score
  Disintegrate asm/system.h for S390
  Disintegrate asm/system.h for PowerPC
  Disintegrate asm/system.h for PA-RISC
  Disintegrate asm/system.h for MN10300
  ...
2012-03-28 15:58:21 -07:00
David Howells 9f97da78bf Disintegrate asm/system.h for ARM
Disintegrate asm/system.h for ARM.

Signed-off-by: David Howells <dhowells@redhat.com>
cc: Russell King <linux@arm.linux.org.uk>
cc: linux-arm-kernel@lists.infradead.org
2012-03-28 18:30:01 +01:00
Tony Lindgren d1589f0912 ARM: OMAP2+: Mark omap_hsmmc_init and omap_mux related functions as __init
Now that omap hsmmc init is split into two functions, it's safe
to mark omap_hsmmc_init and omap_mux related functions to __init.

This basically reverts the following fixes for the case where
TWL was compiled as a module:

a98f77b (ARM: omap: fix section mismatch warning for sdp3430_twl_gpio_setup())
8930b4e (ARM: omap: fix section mismatch warnings in mux.c caused by hsmmc.c)

Additionally it fixes up the remaining section warnings for
all callers of omap_mux functions.

Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-02-24 13:04:10 -08:00
Tony Lindgren 97899e555b ARM: OMAP: Fix kernel panic with HSMMC when twl4030_gpio is a module
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>
2012-02-20 09:43:28 -08:00
Russell King 8930b4e3c3 ARM: omap: fix section mismatch warnings in mux.c caused by hsmmc.c
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>
2012-02-13 10:00:38 +00:00
Russell King 27d8d3bf06 ARM: omap: fix section mismatch warning in mux.c
WARNING: arch/arm/mach-omap2/built-in.o(.text+0x15a4): Section mismatch in reference from the function omap_mux_init_signals() to the function .init.text:omap_mux_init_signal()
The function omap_mux_init_signals() references
the function __init omap_mux_init_signal().
This is often because omap_mux_init_signals lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.

Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2012-02-13 10:00:36 +00:00
Tero Kristo 13a3fe52f7 ARM: OMAP2+: mux: add support for PAD wakeup interrupts
OMAP mux now parses active wakeup events from pad registers and calls
corresponding hwmod ISRs once a wakeup is detected. This is
accomplished by registering an interrupt handler for PRCM IO event,
which is raised every time the HW detects wakeups.

[paul@pwsan.com: This patch is a merge of Govindraj R's "ARM: OMAP2+:
hwmod: Add API to check IO PAD wakeup status" patch, Tero Kristo's
"ARM: OMAP2+: mux: add support for PAD wakeup interrupts" patch, and
part of Tero's "ARM: OMAP: mux: add support for selecting mpu_irq for
each wakeup pad" patch.]

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Cc: Govindraj.R <govindraj.raja@ti.com>
Tested-by: Kevin Hilman <khilman@ti.com>
Reviewed-by: Kevin Hilman <khilman@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
[paul@pwsan.com: reduced indentation level; renamed omap_hwmod function;
 improved function documentation; modified to iterate only through dynamic
 pads; modified to skip pads where idle mode doesn't enable wakeups; split
 patches]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-12-16 14:36:59 -07:00
Paul Walmsley 96dc19fd03 ARM: OMAP2+: mux: add wakeup-capable hwmod mux entries to dynamic list
omap_hwmod_mux() currently only iterates through the dynamic pad list.
This list currently only consists of pads with the
OMAP_DEVICE_MUX_REMUX flag set.

Subsequent patches in this series will cause hwmod mux entries with
the OMAP_DEVICE_MUX_WAKEUP flag set to be changed dynamically, to
control hwmod I/O ring wakeup.  For this to work correctly, hwmod mux
entries with the OMAP_DEVICE_MUX_WAKEUP flag set must also be added to
the dynamic pad list.  So this patch modifies omap_hwmod_mux_init() to
do so.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Tero Kristo <t-kristo@ti.com>
Cc: Govindraj R <govindraj.raja@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
2011-12-16 14:36:57 -07:00
Thomas Meyer dccb3b0eb6 arm: mach-omap2: mux: use kstrdup()
Use kstrdup rather than duplicating its implementation

The semantic patch that makes this output is available
in scripts/coccinelle/api/kstrdup.cocci.

More information about semantic patching is available at
http://coccinelle.lip6.fr/

Signed-off-by: Thomas Meyer <thomas@m3y3r.de>
Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-08-10 04:53:28 -07:00
Colin Cross d4ff6121b4 ARM: omap2+: mux: Allow board mux settings to be NULL
OMAP4 has two mux instances, and the board may not have settings
for one of them.  Allow the board file to pass NULL for an
instance's mux settings, which will initialize the mux instance
but skip writing board settings.

Signed-off-by: Colin Cross <ccross@android.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-06-01 02:25:04 -07:00
Govindraj.R 30ebad9d75 OMAP2+: mux: fix compilation warnings
Fix below compilation warnings.

arch/arm/mach-omap2/omap_hwmod.c: In function 'omap_hwmod_for_each':
arch/arm/mach-omap2/omap_hwmod.c:1631: warning: 'ret' may be used uninitialized in this function

arch/arm/mach-omap2/mux.c: In function 'omap_mux_get_gpio':
arch/arm/mach-omap2/mux.c:917: warning: 'm' may be used uninitialized in this function

Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-06-01 00:16:04 -07:00
Lucas De Marchi 25985edced Fix common misspellings
Fixes generated by 'codespell' and manually reviewed.

Signed-off-by: Lucas De Marchi <lucas.demarchi@profusion.mobi>
2011-03-31 11:26:23 -03:00
R Sricharan 86c79bf45f omap2+: mux: Remove the use of IDLE flag
Currently OMAP_DEVICE_PAD_IDLE flag is used to mux pins
dynamically. This can be simplified by using the enabled
state variable of each pad. This also fixes the issue of
the static pads not getting muxed after idling and
disable/enable state transitions.

Signed-off-by: sricharan <r.sricharan@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-03-11 11:32:25 -08:00
Tony Lindgren 029268e4c1 omap2+: Add separate list for dynamic pads to mux
This avoids going through the list unnecessarily when
idling devices for runtime PM.

Based on an earlier patch by sricharan <r.sricharan@ti.com>.

Signed-off-by: sricharan <r.sricharan@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-03-11 11:32:25 -08:00
Vasiliy Kulikov 9b12771ad2 mach-omap2: mux: world-writable debugfs files
Do not create mux debugfs files as world-writable.

Signed-off-by: Vasiliy Kulikov <segoon@openwall.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-02-04 12:08:06 -08:00
Aaro Koskinen 9d47e30901 arm: mach-omap2: mux: free allocated memory on error exit
Free allocated memory on error exit.

Signed-off-by: Aaro Koskinen <aaro.koskinen@nokia.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-02-01 15:51:36 -08:00
Felipe Balbi afb7d7099e arm: omap2: mux: fix compile warning
Commit 8419fdbaf2
(omap2+: Add omap_mux_get_by_name) introduced the following
compile warning:

arch/arm/mach-omap2/mux.c: In function '_omap_mux_get_by_name':
arch/arm/mach-omap2/mux.c:163:17: warning: 'found_mode' may be used
uninitialized in this function

Signed-off-by: Felipe Balbi <balbi@ti.com>
[tony@atomide.com: updated comments]
Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-01-27 16:22:55 -08:00
Aaro Koskinen 3083314238 arm: mach-omap2: mux: fix buffer overrun
memcpy() copies 8 bytes too much (omap_mux_entry vs. omap_mux). Correct
by replacing memcpy() with struct assignment, which is safer.

Signed-off-by: Aaro Koskinen <aaro.koskinen@nokia.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-01-06 19:58:28 -08:00
Tony Lindgren 8d9af88f55 omap2+: Allow hwmod state changes to mux pads based on the state changes
Allow hwmod state changes to mux pads based on the state changes.

By default, only enable and disable the pads. In some rare cases
dynamic remuxing for the idles states is needed, this can be done
by passing the enable, idle, and off pads from board-*.c file along
with OMAP_DEVICE_PAD_REMUX flag.

Thanks to Paul Walmsley <paul@booyaka.com> for the comments on the
hwmod related changes.

Signed-off-by: Tony Lindgren <tony@atomide.com>
2010-12-22 18:42:35 -08:00
Tony Lindgren 9796b323b5 omap2+: Add support for hwmod specific muxing of devices
This allows adding hwmod specific pads dynamically during the
platform device init.

Note that we don't currently have the hwmod specific signals
listed in the hwmod data, but struct omap_hwmod_mux_info will
make that possible if necessary.

Signed-off-by: Tony Lindgren <tony@atomide.com>
2010-12-22 18:42:35 -08:00
Tony Lindgren 8419fdbaf2 omap2+: Add omap_mux_get_by_name
Do this by splitting _omap_mux_init_signal as it already has most
of the necessary features.

Based on an earlier patch by Dan Murphy <dmurphy@ti.com>.

Cc: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
2010-12-22 18:42:35 -08:00
Dan Murphy 032a6424ae OMAP: mux: Add __func__ macro to pr_xxx macros
Removed mux: and added the __func__ macro to make debugging
easier.

Signed-off-by: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
2010-11-17 12:01:54 +01:00
Benoit Cousson 112485e9c5 OMAP: mux: Add support for control module split in several partitions
Starting on OMAP4, the pin mux configuration is located in two
different partitions of the control module (CODE_PAD and WKUP_PAD).
The first one is inside the core power domain whereas the second
one is inside the wakeup.
- Add the capability to add any number of partition during board init
time depending of Soc partitioning.
- Add some init flags as well in order to avoid explicit Soc version
check inside the mux core code.
- Add a comment with mux0 mode on top of omap_mux/board/<partition>
if the current mux mode is not the default one.

Thanks to Tony Lindgren <tony@atomide.com> for the following improvements:
- Add omap_mux_get for getting the partition data so platform level
device code can use it.
- Fix the rx51 board code to use the new API.
- Do not store the partition for each mux entry. Look up the partition
for debugfs instead.

Thanks to Dan Murphy <dmurphy@ti.com> for testing on OMAP4 and reporting
a couple of bugs.
Thanks to Anand Gadiyar <gadiyar@ti.com> for testing on OMAP3 zoom and
bug report.

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Tested-by: Murphy Dan <dmurphy@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Anand Gadiyar <gadiyar@ti.com>
2010-11-17 12:01:49 +01:00
Benoit Cousson 1cbb3a9a13 OMAP: mux: Replace printk with pr_xxx macros
Replace all the printk(KERN_XXX... with pr_xxx macros.

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
2010-11-17 12:01:49 +01:00
Paul Walmsley 4814ced511 OMAP: control: move plat-omap/control.h to mach-omap2/control.h
Only OMAP2+ platforms have the System Control Module (SCM) IP block.
In the past, we've kept the SCM header file in plat-omap.  This has
led to abuse - device drivers including it; includes being added that
create implicit dependencies on OMAP2+ builds; etc.

In response, move the SCM headers into mach-omap2/.

As part of this, remove the direct SCM access from the OMAP UDC
driver.  It was clearly broken.  The UDC code needs an indepth review for
use on OMAP2+ chips.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Cory Maccarrone <darkstar6262@gmail.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
2010-10-08 11:40:20 -06:00
Tony Lindgren 5a3b2f7a5a omap: Fix omap_mux_init_signal not to trash muxname
Otherwise the muxname passed to the function will get truncated.

Based on an earlier patch by rockefeller.lin@innocomm.com.

Reported-by: rockefeller.lin@innocomm.com
Signed-off-by: Tony Lindgren <tony@atomide.com>
2010-10-01 16:35:24 -07:00
Sanjeev Premi ca828760f9 omap2: fix assorted compiler warnings
This patch fixes these compiler warnings:

  CC      arch/arm/mach-omap2/mux.o
arch/arm/mach-omap2/mux.c: In function 'omap_mux_init_gpio':
arch/arm/mach-omap2/mux.c:90: warning: 'gpio_mux' may be used uninitial
ized in this function

  CC      arch/arm/plat-omap/gpio.o
arch/arm/plat-omap/gpio.c: In function 'omap2_gpio_resume_after_idle':
arch/arm/plat-omap/gpio.c:2152: warning: 'l' may be used uninitialized
in this function
arch/arm/plat-omap/gpio.c: In function 'omap2_gpio_prepare_for_idle':
arch/arm/plat-omap/gpio.c:2085: warning: 'l2' may be used uninitialized
in this function
arch/arm/plat-omap/gpio.c:2085: warning: 'l1' may be used uninitialized
in this function

  CC      arch/arm/mach-omap2/board-omap4panda.o
arch/arm/mach-omap2/board-omap4panda.c: In function 'omap4_panda_init':
arch/arm/mach-omap2/board-omap4panda.c:277: warning: unused variable 's
tatus'

Signed-off-by: Sanjeev Premi <premi@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
2010-09-23 18:27:18 -07:00
Grazvydas Ignotas 8a6f7e14fc omap: mux: fix multipath gpio handling
OMAP3530 CBB package can have GPIO126 muxed on 2 pins: mmc1_dat4 and
cam_strobe. This causes a problem with current multipath GPIO mux
handling, which muxes both pins as GPIO126 and makes the GPIO unusable.

Fix this by not muxing any pins if multipath GPIO is detected and
just print a warning instead. It's up to board files to set correct
mux using omap_mux_init_signal and pin name.

Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
2010-08-02 14:23:07 +03:00
Tony Lindgren c9d8230e31 omap: mux: Remove old mux code
All mach-omap2 omaps should now use the new mux code.

Signed-off-by: Tony Lindgren <tony@atomide.com>
2010-07-05 16:31:40 +03:00
Tony Lindgren ac3dbeefb8 omap: mux: Allow compiling in new mux code on all mach-omap2 systems
Allow compiling in new mux code on all mach-omap2 systems

Signed-off-by: Tony Lindgren <tony@atomide.com>
2010-07-05 16:31:36 +03:00
Tony Lindgren d5425be6eb omap: mux: Fix omap_mux_init_gpio for omap24xx
Looks like 24xx uses mode3 instead of mode4 for muxable GPIO pins.
This will be needed when 24xx mux code is converted to use the new
mux functions.

Signed-off-by: Tony Lindgren <tony@atomide.com>
2010-07-05 16:31:35 +03:00
Tejun Heo 5a0e3ad6af include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files.  percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.

percpu.h -> slab.h dependency is about to be removed.  Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability.  As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.

  http://userweb.kernel.org/~tj/misc/slabh-sweep.py

The script does the followings.

* Scan files for gfp and slab usages and update includes such that
  only the necessary includes are there.  ie. if only gfp is used,
  gfp.h, if slab is used, slab.h.

* When the script inserts a new include, it looks at the include
  blocks and try to put the new include such that its order conforms
  to its surrounding.  It's put in the include block which contains
  core kernel includes, in the same order that the rest are ordered -
  alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
  doesn't seem to be any matching order.

* If the script can't find a place to put a new include (mostly
  because the file doesn't have fitting include block), it prints out
  an error message indicating which .h file needs to be added to the
  file.

The conversion was done in the following steps.

1. The initial automatic conversion of all .c files updated slightly
   over 4000 files, deleting around 700 includes and adding ~480 gfp.h
   and ~3000 slab.h inclusions.  The script emitted errors for ~400
   files.

2. Each error was manually checked.  Some didn't need the inclusion,
   some needed manual addition while adding it to implementation .h or
   embedding .c file was more appropriate for others.  This step added
   inclusions to around 150 files.

3. The script was run again and the output was compared to the edits
   from #2 to make sure no file was left behind.

4. Several build tests were done and a couple of problems were fixed.
   e.g. lib/decompress_*.c used malloc/free() wrappers around slab
   APIs requiring slab.h to be added manually.

5. The script was run on all .h files but without automatically
   editing them as sprinkling gfp.h and slab.h inclusions around .h
   files could easily lead to inclusion dependency hell.  Most gfp.h
   inclusion directives were ignored as stuff from gfp.h was usually
   wildly available and often used in preprocessor macros.  Each
   slab.h inclusion directive was examined and added manually as
   necessary.

6. percpu.h was updated not to include slab.h.

7. Build test were done on the following configurations and failures
   were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
   distributed build env didn't work with gcov compiles) and a few
   more options had to be turned off depending on archs to make things
   build (like ipr on powerpc/64 which failed due to missing writeq).

   * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
   * powerpc and powerpc64 SMP allmodconfig
   * sparc and sparc64 SMP allmodconfig
   * ia64 SMP allmodconfig
   * s390 SMP allmodconfig
   * alpha SMP allmodconfig
   * um on x86_64 SMP allmodconfig

8. percpu.h modifications were reverted so that it could be applied as
   a separate patch and serve as bisection point.

Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.

Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-30 22:02:32 +09:00