Skip to content
  1. Dec 08, 2013
  3. Dec 06, 2013
    • Tony Lindgren's avatar
      ARM: dts: Fix booting for secure omaps · f2e2c9d9
      Tony Lindgren authored 
      

Commit 7ce93f31 (ARM: OMAP2+: Fix more missing data for omap3.dtsi file)
fixed missing device tree data for omaps, but did not account for some of the
hardware modules being inaccessible for secure omaps. This causes the
following error on secure omaps:

Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa0c5048
SMP ARM
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Tainted: G        W    3.13.0-rc2+ #446
task: ce057b40 ti: ce058000 task.ti: ce058000
PC is at omap_aes_dma_stop+0x24/0x3c
LR is at omap_aes_probe+0x1cc/0x584
   psr: 60000113
sp : ce059e20  ip : ce0b4ee0  fp : 00000000
r10: c0573ae8  r9 : c0749508  r8 : 00000000
r7 : ce0b4e00  r6 : 00000000  r5 : ce0b4e10  r4 : ce274890
r3 : fa0c5048  r2 : 00000048  r1 : 0000002c  r0 : ce274890
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: 10c5387d  Table: 80004019  DAC: 00000015
Process swapper/0 (pid: 1, stack limit = 0xce058248)
Stack: (0xce059e20 to 0xce05a000)
9e20: c0749508 0000a1ff 00000000 c016cd8c c06b5a06 ce2a45f0 ce2a4570 ce0b5fb0
9e40: 00000000 480c5000 480c504f c0abe4e4 00000200 00000000 00000000 00000000
9e60: ce0b4e10 ce0b4e10 c082da3c c082da3c c02b8c70 c077c610 c0749508 00000000
9e80: 00000000 c02b9e7c c02b9e64 ce0b4e10 00000000 c02b8b20 ce0b4e10 ce0b4e44
9ea0: c082da3c c02b8cd8 00000000 ce059eb8 c082da3c c02b7408 ce079edc ce0b1a34
9ec0: c082da3c c082da3c ce2a0280 00000000 c08158d8 c02b8358 c0663405 c0663405
9ee0: 00000073 c082da3c c079e4e8 c07ab3bc c0844340 c02b9334 00000000 00000006
9f00: c079e4e8 c0008920 c067f6bf c0ac7c6b 00000000 c0712e28 00000000 00000000
9f20: c0712e38 ce059f38 00000093 c0ac7c82 00000000 c0058994 00000000 c07130e8
9f40: c07127b8 00000093 00000006 00000006 00000001 00000006 00000006 c079e4e8
9f60: c07ab3bc c0844340 00000093 c0749508 c079e4f4 c0749c64 00000006 00000006
9f80: c0749508 00000000 00000000 c0517e2c 00000000 00000000 00000000 00000000
9fa0: 00000000 c0517e34 00000000 c000dfb8 00000000 00000000 00000000 00000000
9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 ffffffff ffffffff
(omap_aes_probe+0x1cc/0x584)
(platform_drv_probe+0x18/0x48)
(driver_probe_device+0xb0/0x200)
(__driver_attach+0x68/0x8c)
(bus_for_each_dev+0x50/0x88)
(bus_add_driver+0xcc/0x1c8)
(driver_register+0x9c/0xe0)
(do_one_initcall+0x98/0x140)
(kernel_init_freeable+0x16c/0x23c)
(kernel_init+0x8/0x100)
(ret_from_fork+0x14/0x3c)
Code: e1811002 e5932020 e590300c e0833002 (e593c000)

Let's fix the issue by adding omap34xx-hs.dtsi and omap36xx-hs.dtsi and make
n900, n9 and n950 to use them. This way we have the aes, sham and timer12
disabled for secure devices the same way legacy booting does based on the
omap34xx_gp_hwmod_ocp_ifs and omap36xx_gp_hwmod_ocp_ifs arrays in
omap_hwmod_3xxx_data.c.

Reported-by: default avatarSebastian Reichel <sre@debian.org>
Acked-By: default avatarSebastian Reichel <sre@debian.org>
Tested-by: default avatarAaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      f2e2c9d9
    • Nishanth Menon's avatar
      ARM: OMAP2+: Fix the machine entry for am3517 · caef4ee8
      Nishanth Menon authored 
      

The am3517 is wrongly booting as omap3 which means that the am3517
specific devices like Ethernet won't work when booted with device
tree. Now with the new devices defined in am3517.dtsi, let's use
that instead of the omap3.dtsi, and add a separate machine entry
for am3517 so am3517-evm can use it.

Signed-off-by: default avatarNishanth Menon <nm@ti.com>
[tony@atomide.com: updated comments and fixed build without omap3]
Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      caef4ee8
    • Tony Lindgren's avatar
      ARM: dts: Fix missing entries for am3517 · a0158185
      Tony Lindgren authored 
      

On am3517 there are some extra devices compared to omap3.dtsi that
we currently have not defined. Let's fix that by adding am3517.dtsi
file.

Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      a0158185
  5. Dec 03, 2013
  7. Dec 02, 2013
  9. Nov 26, 2013
  11. Nov 25, 2013
    • Aaro Koskinen's avatar
      ARM: OMAP2+: dts: add n8x0 onenand · 218077a3
      Aaro Koskinen authored 
      

Convert onenand to DT on n8x0 boards.

Signed-off-by: default avatarAaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      218077a3
    • Tony Lindgren's avatar
      ARM: dts: Add basic support for omap3 LDP zoom1 labrador · bd5fc6fa
      Tony Lindgren authored 
      Basic things like serial, Ethernet, MMC, NAND, DSS, touchscreen
and GPIO keys work.

For twl4030-keypad we're still missing the binding, but
support for that should be trivial to add once the driver
has been updated.

MUSB I'm pretty sure I got got to enumerate once, but I
suspect the battery charging somehow disrupts it and it's
not enumerating in general for some reason.

Patches are welcome to improve things if people are
still using this board.

For reference, here's some more info on this old board:
http://www.openomap.org/wiki/tiki-index.php?page=HardwareInfo



Cc: devicetree@vger.kernel.org
Cc: "Benoît Cousson" <bcousson@baylibre.com>
Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      bd5fc6fa
    • Tony Lindgren's avatar
      ARM: dts: Add basic Nokia N8X0 support · a900f516
      Tony Lindgren authored 
      

Add minimal device tree support for n8x0 boards so we
can make omap2 device tree only. Note that we still need
to initialize various platform data quirks to keep
things working until n8x0 drivers support device tree.

Here's a rough todo list for the people using n8x0:

1. Update menelaus for device tree and set up
   regulators at least for the MMC driver

2. Remove the MMC regulator platform data callback
   by using the Menlaus regulators directly in the
   driver passed from the .dts file

3. Update GPMC connected devices for onenand and
   tusb6010 for device tree

We're planning to remove all legacy platform data
for mach-omap2 over next few merge cycles, so if
people are still using n8x0, please fix the issues
above.

Cc: devicetree@vger.kernel.org
Cc: "Benoît Cousson" <bcousson@baylibre.com>
Tested-by: default avatarAaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      a900f516
    • Tony Lindgren's avatar
      ARM: dts: Add basic device tree support for omap2430 sdp · 04a25dfb
      Tony Lindgren authored 
      

I doubt that there are many people using 2430 sdp, but as
that's been historically an important acid test platform
for omap2+ related changes, let's add minimal device
tree support for it.

If anybody is using it beyond minimal boot testing, patches
for more complete device tree support are welcome.

Cc: devicetree@vger.kernel.org
Cc: "Benoît Cousson" <bcousson@baylibre.com>
Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      04a25dfb
    • Doug Anderson's avatar
      ARM: dts: Add max77686 RTC interrupt to cros5250-common · c61248af
      Doug Anderson authored 
      

Without the interrupt you'll get problems if you enable
CONFIG_RTC_DRV_MAX77686.  Setup the interrupt properly in the device
tree.

Signed-off-by: default avatarDoug Anderson <dianders@chromium.org>
Tested-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
Signed-off-by: default avatarOlof Johansson <olof@lixom.net>
Cc: stable@vger.kernel.org
      c61248af
    • Tony Lindgren's avatar
      ARM: OMAP2+: Fix eMMC on n900 with device tree · edd5eb4e
      Tony Lindgren authored 
      

Looks like we need to configure the regulators and use the pdata
quirk to make eMMC work with device tree.

It seems that mostly vaux3 is used, and only some earlier revisions
used vmmc2. This has been tested to work on devices where the
system_rev passed by the bootloader has versions 0x0010, 0x2101
and 0x2204.

Cc: devicetree@vger.kernel.org
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: default avatarSebastian Reichel <sre@debian.org>
[tony@atomide.com: updated with pinctrl changes and comments from Sebastian]
Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      edd5eb4e
    • Tony Lindgren's avatar
      ARM: OMAP2+: Fix more missing data for omap3.dtsi file · 7ce93f31
      Tony Lindgren authored 
      

After dropping the duplicate data in hwmod that now should come from
the .dts files, I noticed few more entries missing. Let's add these
as otherwise devices relying on these won't work.

Looks like the side tone entries are bundled into the mcbsp1 to 3,
so that may needs some special handling in the hwmod code as it's
currently trying to look up mcbsp2_sidetone and mcbsp3_sidetone
entries.

Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      7ce93f31
    • Thomas Petazzoni's avatar
      ARM: mvebu: re-enable PCIe on Armada 370 DB · 96039f73
      Thomas Petazzoni authored 
      

Commit 14fd8ed0 ("ARM: mvebu: Relocate Armada 370/XP PCIe
device tree nodes") relocated the PCIe controller DT nodes one level
up in the Device Tree, to reflect a more correct representation of the
hardware introduced by the mvebu-mbus Device Tree binding.

However, while most of the boards were properly adjusted accordingly,
the Armada 370 DB board was left unchanged, and therefore, PCIe is
seen as not enabled on this board. This patch fixes that by moving the
PCIe controller node one level-up in armada-370-db.dts.

Signed-off-by: default avatarThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: <stable@vger.kernel.org> # v3.12+
Fixes: 14fd8ed0 "ARM: mvebu: Relocate Armada 370/XP PCIe device tree nodes"
Signed-off-by: default avatarJason Cooper <jason@lakedaemon.net>
      96039f73
    • Gregory CLEMENT's avatar
      ARM: mvebu: use the virtual CPU registers to access coherency registers · b6dda00c
      Gregory CLEMENT authored 
      

The Armada XP provides a mechanism called "virtual CPU registers" or
"per-CPU register banking", to access the per-CPU registers of the
current CPU, without having to worry about finding on which CPU we're
running. CPU0 has its registers at 0x21800, CPU1 at 0x21900, CPU2 at
0x21A00 and CPU3 at 0x21B00. The virtual registers accessing the
current CPU registers are at 0x21000.

However, in the Device Tree node that provides the register addresses
for the coherency unit (which is responsible for ensuring coherency
between processors, and I/O coherency between processors and the
DMA-capable devices), a mistake was made: the CPU0-specific registers
were specified instead of the virtual CPU registers. This means that
the coherency barrier needed for I/O coherency was not behaving
properly when executed from a CPU different from CPU0. This patch
fixes that by using the virtual CPU registers.

Signed-off-by: default avatarGregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: default avatarThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: <stable@vger.kernel.org> # v3.8+
Fixes: e60304f8 "arm: mvebu: Add hardware I/O Coherency support"
Signed-off-by: default avatarJason Cooper <jason@lakedaemon.net>
      b6dda00c
  13. Nov 23, 2013
  15. Nov 18, 2013
  17. Nov 15, 2013
    • Tony Lindgren's avatar
      ARM: dts: Fix omap2 specific dtsi files by adding the missing entries · 467f4bd2
      Tony Lindgren authored 
      

Looks like we're missing few entries for omap2 and the drivers
have only worked because of the omap hwmod building the devices
for the missing entries.

Let's fix the missing entries so we don't need to rely on hwmod
for the basic data and can then later on remove the duplicate
data from hwmod. Otherwise device tree only drivers will not
work properly.

Cc: "Benoît Cousson" <bcousson@baylibre.com>
Cc: devicetree@vger.kernel.org
Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      467f4bd2
    • Tony Lindgren's avatar
      ARM: OMAP2+: Fix GPMC and simplify bootloader timings for 8250 and smc91x · fd4446f2
      Tony Lindgren authored 
      

Commit f2bf0e72 (ARM: OMAP2+: Add minimal 8250 support
for GPMC) added support for using bootloader timings for some
devices. Turns out we can do the same by looking at the compatible
flags of the child without adding a new function as smc91x has
a similar issue as 8250 with the bootloader timings.

And let's fix the 8250 naming, we should use the device type as
the name like uart instead of 8250 for zoom dts file.

Cc: "Benoît Cousson" <bcousson@baylibre.com>
Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      fd4446f2
  19. Nov 13, 2013
  21. Nov 11, 2013