linux.git/arch/arm/boot/dts, branch v3.12 Linux kernel source tree ARM: integrator: deactivate timer0 on the Integrator/CP 2013-10-13T21:07:21+00:00 Linus Walleij linus.walleij@linaro.org 2013-10-07T13:19:53+00:00 29114fd7db2fc82a34da8340d29b8fa413e03dca This fixes a long-standing Integrator/CP regression from commit 870e2928cf3368ca9b06bc925d0027b0a56bcd8e "ARM: integrator-cp: convert use CLKSRC_OF for timer init" When this code was introduced, the both aliases pointing the system to use timer1 as primary (clocksource) and timer2 as secondary (clockevent) was ignored, and the system would simply use the first two timers found as clocksource and clockevent. However this made the system timeline accelerate by a factor x25, as it turns out that the way the clocking actually works (totally undocumented and found after some trial-and-error) is that timer0 runs @ 25MHz and timer1 and timer2 runs @ 1MHz. Presumably this divider setting is a boot-on default and configurable albeit the way to configure it is not documented. So as a quick fix to the problem, let's mark timer0 as disabled, so the code will chose timer1 and timer2 as it used to. This also deletes the two aliases for the primary and secondary timer as they have been superceded by the auto-selection Cc: stable@vger.kernel.org Cc: Rob Herring <rob.herring@calxeda.com> Cc: Russell King <linux@arm.linux.org.uk> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Olof Johansson <olof@lixom.net> 
This fixes a long-standing Integrator/CP regression from
commit 870e2928cf3368ca9b06bc925d0027b0a56bcd8e
"ARM: integrator-cp: convert use CLKSRC_OF for timer init"

When this code was introduced, the both aliases pointing the
system to use timer1 as primary (clocksource) and timer2
as secondary (clockevent) was ignored, and the system would
simply use the first two timers found as clocksource and
clockevent.

However this made the system timeline accelerate by a
factor x25, as it turns out that the way the clocking
actually works (totally undocumented and found after some
trial-and-error) is that timer0 runs @ 25MHz and timer1
and timer2 runs @ 1MHz. Presumably this divider setting
is a boot-on default and configurable albeit the way to
configure it is not documented.

So as a quick fix to the problem, let's mark timer0 as
disabled, so the code will chose timer1 and timer2 as it
used to.

This also deletes the two aliases for the primary and
secondary timer as they have been superceded by the
auto-selection

Cc: stable@vger.kernel.org
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Olof Johansson <olof@lixom.net>
ARM: exynos: dts: Update 5250 arch timer node with clock frequency 2013-10-13T16:33:54+00:00 Yuvaraj Kumar C D yuvaraj.cd@gmail.com 2013-09-18T10:11:53+00:00 4d594dd3028ba8cdfcbd854bde3811a1ee4e36d7 Without the "clock-frequency" property in arch timer node, could able to see the below crash dump. [<c0014e28>] (unwind_backtrace+0x0/0xf4) from [<c0011808>] (show_stack+0x10/0x14) [<c0011808>] (show_stack+0x10/0x14) from [<c036ac1c>] (dump_stack+0x7c/0xb0) [<c036ac1c>] (dump_stack+0x7c/0xb0) from [<c01ab760>] (Ldiv0_64+0x8/0x18) [<c01ab760>] (Ldiv0_64+0x8/0x18) from [<c0062f60>] (clockevents_config.part.2+0x1c/0x74) [<c0062f60>] (clockevents_config.part.2+0x1c/0x74) from [<c0062fd8>] (clockevents_config_and_register+0x20/0x2c) [<c0062fd8>] (clockevents_config_and_register+0x20/0x2c) from [<c02b8e8c>] (arch_timer_setup+0xa8/0x134) [<c02b8e8c>] (arch_timer_setup+0xa8/0x134) from [<c04b47b4>] (arch_timer_init+0x1f4/0x24c) [<c04b47b4>] (arch_timer_init+0x1f4/0x24c) from [<c04b40d8>] (clocksource_of_init+0x34/0x58) [<c04b40d8>] (clocksource_of_init+0x34/0x58) from [<c049ed8c>] (time_init+0x20/0x2c) [<c049ed8c>] (time_init+0x20/0x2c) from [<c049b95c>] (start_kernel+0x1e0/0x39c) THis is because the Exynos u-boot, for example on the Chromebooks, doesn't set up the CNTFRQ register as expected by arch_timer. Instead, we have to specify the frequency in the device tree like this. Signed-off-by: Yuvaraj Kumar C D <yuvaraj.cd@samsung.com> [olof: Changed subject, added comment, elaborated on commit message] Signed-off-by: Olof Johansson <olof@lixom.net> 
Without the "clock-frequency" property in arch timer node, could able
to see the below crash dump.

[<c0014e28>] (unwind_backtrace+0x0/0xf4) from [<c0011808>] (show_stack+0x10/0x14)
[<c0011808>] (show_stack+0x10/0x14) from [<c036ac1c>] (dump_stack+0x7c/0xb0)
[<c036ac1c>] (dump_stack+0x7c/0xb0) from [<c01ab760>] (Ldiv0_64+0x8/0x18)
[<c01ab760>] (Ldiv0_64+0x8/0x18) from [<c0062f60>] (clockevents_config.part.2+0x1c/0x74)
[<c0062f60>] (clockevents_config.part.2+0x1c/0x74) from [<c0062fd8>] (clockevents_config_and_register+0x20/0x2c)
[<c0062fd8>] (clockevents_config_and_register+0x20/0x2c) from [<c02b8e8c>] (arch_timer_setup+0xa8/0x134)
[<c02b8e8c>] (arch_timer_setup+0xa8/0x134) from [<c04b47b4>] (arch_timer_init+0x1f4/0x24c)
[<c04b47b4>] (arch_timer_init+0x1f4/0x24c) from [<c04b40d8>] (clocksource_of_init+0x34/0x58)
[<c04b40d8>] (clocksource_of_init+0x34/0x58) from [<c049ed8c>] (time_init+0x20/0x2c)
[<c049ed8c>] (time_init+0x20/0x2c) from [<c049b95c>] (start_kernel+0x1e0/0x39c)

THis is because the Exynos u-boot, for example on the Chromebooks, doesn't set
up the CNTFRQ register as expected by arch_timer. Instead, we have to specify
the frequency in the device tree like this.

Signed-off-by: Yuvaraj Kumar C D <yuvaraj.cd@samsung.com>
[olof: Changed subject, added comment, elaborated on commit message]
Signed-off-by: Olof Johansson <olof@lixom.net>
Merge tag 'fixes-against-v3.12-rc3-take2' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes 2013-10-13T16:33:32+00:00 Olof Johansson olof@lixom.net 2013-10-13T16:33:32+00:00 98ead6e0011e66b8a3e14bc2f264460742ca79c1 From Tony Lindgren: Few fixes for omap3 related hangs and errors that people have noticed now that people are actually using the device tree based booting for omap3. Also one regression fix for timer compile for dra7xx when omap5 is not selected, and a LED regression fix for n900. * tag 'fixes-against-v3.12-rc3-take2' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap: ARM: OMAP2: RX-51: Add missing max_current to rx51_lp5523_led_config ARM: mach-omap2: board-generic: fix undefined symbol ARM: dts: Fix pinctrl mask for omap3 ARM: OMAP3: Fix hardware detection for omap3630 when booted with device tree ARM: OMAP2: gpmc-onenand: fix sync mode setup with DT Signed-off-by: Olof Johansson <olof@lixom.net> 
From Tony Lindgren:

Few fixes for omap3 related hangs and errors that people have
noticed now that people are actually using the device tree
based booting for omap3.

Also one regression fix for timer compile for dra7xx when
omap5 is not selected, and a LED regression fix for n900.

* tag 'fixes-against-v3.12-rc3-take2' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
  ARM: OMAP2: RX-51: Add missing max_current to rx51_lp5523_led_config
  ARM: mach-omap2: board-generic: fix undefined symbol
  ARM: dts: Fix pinctrl mask for omap3
  ARM: OMAP3: Fix hardware detection for omap3630 when booted with device tree
  ARM: OMAP2: gpmc-onenand: fix sync mode setup with DT

Signed-off-by: Olof Johansson <olof@lixom.net>
ARM: dts: Fix pinctrl mask for omap3 2013-10-08T17:37:29+00:00 Tony Lindgren tony@atomide.com 2013-10-07T17:22:01+00:00 d623a0e19dcbc4e44a8db047158815d7f8c2b839 The wake-up interrupt bit is available on omap3/4/5 processors unlike what we claim. Without fixing it we cannot use it on omap3 and the system configured for wake-up events will just hang on wake-up. Cc: Grygorii Strashko <grygorii.strashko@ti.com> Cc: Benoît Cousson <bcousson@baylibre.com> Cc: devicetree@vger.kernel.org Signed-off-by: Tony Lindgren <tony@atomide.com> 
The wake-up interrupt bit is available on omap3/4/5 processors
unlike what we claim. Without fixing it we cannot use it on
omap3 and the system configured for wake-up events will just
hang on wake-up.

Cc: Grygorii Strashko <grygorii.strashko@ti.com>
Cc: Benoît Cousson <bcousson@baylibre.com>
Cc: devicetree@vger.kernel.org
Signed-off-by: Tony Lindgren <tony@atomide.com>
ARM: OMAP3: Fix hardware detection for omap3630 when booted with device tree 2013-10-08T17:32:24+00:00 Nishanth Menon nm@ti.com 2013-10-07T20:43:49+00:00 016c12d2fb8584db392211bc6b0bdd6fcf7cfd97 SoC family definitions at the moment are reactive to board needs as a result, beagle-xm would matchup with ti,omap3 which invokes omap3430_init_early instead of omap3630_init_early. Obviously, this is the wrong behavior. With clock node dts conversion, we get the following warnings before system hangs as a result and 3630 based platforms fails to boot (uart4 clocks are only present in OMAP3630 and not present in OMAP3430): ... omap_hwmod: uart4: cannot clk_get main_clk uart4_fck omap_hwmod: uart4: cannot _init_clocks WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2434 _init+0x6c/0x80() omap_hwmod: uart4: couldn't init clocks ... WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2126 _enable+0x254/0x280() omap_hwmod: timer12: enabled state can only be entered from initialized, idle, or disabled state ... WARNING: CPU: 0 PID: 46 at arch/arm/mach-omap2/omap_hwmod.c:2224 _idle+0xd4/0xf8() omap_hwmod: timer12: idle state can only be entered from enabled state WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2126 _enable+0x254/0x280() omap_hwmod: uart4: enabled state can only be entered from initialized, idle, or disabled state So, add specific compatiblity for 3630 to allow match for Beagle-XM platform. Signed-off-by: Nishanth Menon <nm@ti.com> [tony@atomide.com: left out ti,omap343x, updated comments] Signed-off-by: Tony Lindgren <tony@atomide.com> 
SoC family definitions at the moment are reactive to board needs
as a result, beagle-xm would matchup with ti,omap3 which invokes
omap3430_init_early instead of omap3630_init_early. Obviously, this is
the wrong behavior.

With clock node dts conversion, we get the following warnings before
system hangs as a result and 3630 based platforms fails to boot
(uart4 clocks are only present in OMAP3630 and not present in
OMAP3430):

...
omap_hwmod: uart4: cannot clk_get main_clk uart4_fck
omap_hwmod: uart4: cannot _init_clocks

WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2434
_init+0x6c/0x80()
omap_hwmod: uart4: couldn't init clocks
...

WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2126
_enable+0x254/0x280()
omap_hwmod: timer12: enabled state can only be entered from
initialized, idle, or disabled state
...

WARNING: CPU: 0 PID: 46 at arch/arm/mach-omap2/omap_hwmod.c:2224
_idle+0xd4/0xf8()
omap_hwmod: timer12: idle state can only be entered from enabled state

WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2126
_enable+0x254/0x280()
omap_hwmod: uart4: enabled state can only be entered from
initialized, idle, or disabled state

So, add specific compatiblity for 3630 to allow match for Beagle-XM
platform.

Signed-off-by: Nishanth Menon <nm@ti.com>
[tony@atomide.com: left out ti,omap343x, updated comments]
Signed-off-by: Tony Lindgren <tony@atomide.com>
Merge tag 'fixes-3.12-2' of git://git.infradead.org/linux-mvebu into fixes 2013-10-03T03:55:05+00:00 Olof Johansson olof@lixom.net 2013-10-03T03:55:05+00:00 6a98b2ffc7cf8a84a18d8666185c29b7e0e631e9 From Jason Cooper: mvebu fixes for v3.12 (round 2) - mvebu - fix ReadyNAS 102 power button (needs to be active high) - fix ReadyNAS 102 automated rebooting (prevent hang) by add gpio-poweroff node - fix booting ReadyNAS 102 by adding MBus ranges and PCIe DT nodes - mvebu-mbus: prevent PCIe driver from continuing with corrupted resource * tag 'fixes-3.12-2' of git://git.infradead.org/linux-mvebu: bus: mvebu-mbus: Fix optional pcie-mem/io-aperture properties ARM: mvebu: add missing DT Mbus ranges and relocate PCIe DT nodes for RN102 ARM: mvebu: Add DT entry for ReadyNAS 102 to use gpio-poweroff driver ARM: mvebu: fix ReadyNAS 102 Power button GPIO to make it active high Signed-off-by: Olof Johansson <olof@lixom.net> 
From Jason Cooper:
mvebu fixes for v3.12 (round 2)

 - mvebu
    - fix ReadyNAS 102 power button (needs to be active high)
    - fix ReadyNAS 102 automated rebooting (prevent hang) by add gpio-poweroff
      node
    - fix booting ReadyNAS 102 by adding MBus ranges and PCIe DT nodes
    - mvebu-mbus: prevent PCIe driver from continuing with corrupted resource

* tag 'fixes-3.12-2' of git://git.infradead.org/linux-mvebu:
  bus: mvebu-mbus: Fix optional pcie-mem/io-aperture properties
  ARM: mvebu: add missing DT Mbus ranges and relocate PCIe DT nodes for RN102
  ARM: mvebu: Add DT entry for ReadyNAS 102 to use gpio-poweroff driver
  ARM: mvebu: fix ReadyNAS 102 Power button GPIO to make it active high

Signed-off-by: Olof Johansson <olof@lixom.net>
ARM: mvebu: add missing DT Mbus ranges and relocate PCIe DT nodes for RN102 2013-10-01T00:46:30+00:00 Arnaud Ebalard arno@natisbad.org 2013-09-30T22:19:16+00:00 b643f85814f69306b9a6e0df34a1c8acb97d3bbd When 5e12a613 and 0cd3754a were introduced, Netgear ReadyNAS 102 .dts file was queued for inclusion and missed the update to have Mbus (and then BootROM) ranges properties declared. It also missed the relocation of Armada 370/XP PCIe DT nodes introduced by 14fd8ed0 after de1af8d4. This patch fixes that which makes 3.12-rc3 bootable on the NAS. Signed-off-by: Arnaud Ebalard <arno@natisbad.org> Signed-off-by: Jason Cooper <jason@lakedaemon.net> 
When 5e12a613 and 0cd3754a were introduced, Netgear ReadyNAS 102 .dts
file was queued for inclusion and missed the update to have Mbus (and
then BootROM) ranges properties declared. It also missed the relocation
of Armada 370/XP PCIe DT nodes introduced by 14fd8ed0 after de1af8d4.
This patch fixes that which makes 3.12-rc3 bootable on the NAS.

Signed-off-by: Arnaud Ebalard <arno@natisbad.org>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
Merge tag 'renesas-fixes4-for-v3.12' of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas into fixes 2013-09-30T16:24:20+00:00 Olof Johansson olof@lixom.net 2013-09-30T16:24:20+00:00 f1bb7cd5a13b55c33ae560fef97dc3114cfa6bed From Simon Horman: Fourth Round of Renesas ARM based SoC fixes for v3.12 * Remove unused #gpio-ranges-cells DT property * Remove usage of deprecated #gpio-range-cells DT property from GPIO R-Car Property was deprecated in v3.11-rc2 * Correct ether pinctl naming for armadillo800eva board Regression introduced in v3.10-rc5 * Add Micrel KSZ8041 PHY fixup to lager board This resolves a problem that has been present since 3.11-rc2 * Update SDHI DT compatibility string to the <unit>-<soc> format This makes compatibility strings consistent across all renesas hardware which currently supports DT. The bindings which are being updated where intorodiced on a per-SoC basis starting in v3.8-rc7. They may have been internally consistent when originally added. * tag 'renesas-fixes4-for-v3.12' of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas: ARM: shmobile: Remove #gpio-ranges-cells DT property gpio: rcar: Remove #gpio-range-cells DT property usage ARM: shmobile: armadillo: fixup ether pinctrl naming ARM: shmobile: Lager: add Micrel KSZ8041 PHY fixup ARM: shmobile: update SDHI DT compatibility string to the <unit>-<soc> format Signed-off-by: Olof Johansson <olof@lixom.net> 
From Simon Horman:
Fourth Round of Renesas ARM based SoC fixes for v3.12

* Remove unused #gpio-ranges-cells DT property

* Remove usage of deprecated #gpio-range-cells DT property
  from GPIO R-Car

  Property was deprecated in v3.11-rc2

* Correct ether pinctl naming for armadillo800eva board

  Regression introduced in v3.10-rc5

* Add Micrel KSZ8041 PHY fixup to lager board

  This resolves a problem that has been present since 3.11-rc2

* Update SDHI DT compatibility string to the <unit>-<soc> format

  This makes compatibility strings consistent across all renesas
  hardware which currently supports DT.

  The bindings which are being updated where intorodiced on
  a per-SoC basis starting in v3.8-rc7. They may have
  been internally consistent when originally added.

* tag 'renesas-fixes4-for-v3.12' of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas:
  ARM: shmobile: Remove #gpio-ranges-cells DT property
  gpio: rcar: Remove #gpio-range-cells DT property usage
  ARM: shmobile: armadillo: fixup ether pinctrl naming
  ARM: shmobile: Lager: add Micrel KSZ8041 PHY fixup
  ARM: shmobile: update SDHI DT compatibility string to the <unit>-<soc> format

Signed-off-by: Olof Johansson <olof@lixom.net>
ARM: dts: sirf: fix interrupt and dma prop of VIP for prima2 and atlas6 2013-09-30T16:17:49+00:00 Renwei Wu Renwei.Wu@csr.com 2013-09-23T15:57:11+00:00 262bcc1d6f8a1b0077eaca00d0834c03573f1b92 the current dts is lacking interrupt and dma prop for video input processor of prima2 and atlas6, this patch fixes it. Signed-off-by: Renwei Wu <Renwei.Wu@csr.com> Signed-off-by: Barry Song <Baohua.Song@csr.com> Signed-off-by: Olof Johansson <olof@lixom.net> 
the current dts is lacking interrupt and dma prop for video input
processor of prima2 and atlas6, this patch fixes it.

Signed-off-by: Renwei Wu <Renwei.Wu@csr.com>
Signed-off-by: Barry Song <Baohua.Song@csr.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
ARM: dts: sirf: fix the ranges of peri-iobrg of prima2 2013-09-30T16:17:49+00:00 Barry Song Baohua.Song@csr.com 2013-09-23T16:04:18+00:00 9e85b9d1006738a45123ea3fe92ad74e5622ffbc we lost an address range <0x56000000 0x56000000 0x1b00000> for peri-iobg of prima2. Signed-off-by: Barry Song <Baohua.Song@csr.com> Signed-off-by: Olof Johansson <olof@lixom.net> 
we lost an address range <0x56000000 0x56000000 0x1b00000> for peri-iobg
of prima2.

Signed-off-by: Barry Song <Baohua.Song@csr.com>
Signed-off-by: Olof Johansson <olof@lixom.net>