Skip to content

L
linux
Switch branch/tag
  1. 05 May, 2014 2 commits
  3. 26 Apr, 2014 1 commit
  5. 25 Apr, 2014 7 commits
    • Suman Anna's avatar
      ARM: dts: AM3517: Disable absent IPs inherited from OMAP3 · 4c051603
      Suman Anna authored 
      AM3517 inherits OMAP3 dts file, but does not have all the IPs
that are present on OMAP3. This patch disables the following
absent IPs for AM3517: Mailbox, IVA, MMU_ISP, MPU_IVA SmartReflex.

A label had to be added for IVA node in omap3.dtsi to be able to
get a reference to the node for disabling.

Otherwise we get the following warnings during booting:
platform iva.2: Cannot lookup hwmod 'iva'
platform 48094000.mailbox: Cannot lookup hwmod 'mailbox'
platform 480bd400.mmu: Cannot lookup hwmod 'mmu_isp'
platform 480c9000.smartreflex: Cannot lookup hwmod 'smartreflex_mpu_iva'
Signed-off-by: default avatarSuman Anna <s-anna@ti.com>
[tony@atomide.com: updated description for the warnings]
Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      4c051603
    • Suman Anna's avatar
      ARM: dts: OMAP2: Fix interrupts for OMAP2420 mailbox · 4fe5bd5d
      Suman Anna authored 
      The mailbox module is capable of generating two interrupts
to MPU in OMAP2420, compared to one in OMAP2430. The second
interrupt is to handle interrupts from the additional IVA
processor present only on OMAP2420.

Move the current common mailbox DT node into the SoC
specific files to allow the above differentiation. Also,
added back the interrupt-names on OMAP2420, that were
previously defined in hwmod data.

This fixes regression caused by the recent dropping of
hwmod data in favor for defining it in the .dts files.
Signed-off-by: default avatarSuman Anna <s-anna@ti.com>
[tony@atomide.com: updated description]
Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      4fe5bd5d
    • Suman Anna's avatar
      ARM: dts: OMAP5: Add mailbox dt node to fix boot warning · 84d89c31
      Suman Anna authored 
      Add the mailbox device DT node for OMAP5 SoC. The OMAP5 mailbox
IP is identical to that used in OMAP4.

The OMAP5 hwmod data no longer publishes the module address space,
so this patch fixes the WARN_ON backtrace associated with the
following trace during the kernel boot:
"omap_hwmod: mailbox: doesn't have mpu register target base".

Otherwise we get a warning like this:

WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2538 _init+0x1c0/0x3dc()
omap_hwmod: mailbox: doesn't have mpu register target base
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.15.0-rc2-00001-gb5e85a0 #45
[<c0015724>] (unwind_backtrace) from [<c00120f4>] (show_stack+0x10/0x14)
[<c00120f4>] (show_stack) from [<c05a1ccc>] (dump_stack+0x78/0x94)
[<c05a1ccc>] (dump_stack) from [<c0042a74>] (warn_slowpath_common+0x6c/0x8c)
[<c0042a74>] (warn_slowpath_common) from [<c0042b28>] (warn_slowpath_fmt+0x30/0x40)
[<c0042b28>] (warn_slowpath_fmt) from [<c0803b40>] (_init+0x1c0/0x3dc)
[<c0803b40>] (_init) from [<c0029c8c>] (omap_hwmod_for_each+0x34/0x5c)
[<c0029c8c>] (omap_hwmod_for_each) from [<c08042b0>] (__omap_hwmod_setup_all+0x24/0x40)
[<c08042b0>] (__omap_hwmod_setup_all) from [<c00088b8>] (do_one_initcall+0x34/0x160)
[<c00088b8>] (do_one_initcall) from [<c07f7bf4>] (kernel_init_freeable+0xfc/0x1c8)
[<c07f7bf4>] (kernel_init_freeable) from [<c059c4f4>] (kernel_init+0x8/0xe4)
[<c059c4f4>] (kernel_init) from [<c000eaa8>] (ret_from_fork+0x14/0x2c)
Signed-off-by: default avatarSuman Anna <s-anna@ti.com>
[tony@atomide.com: updated description to for the warning]
Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      84d89c31
    • Joel Fernandes's avatar
      ARM: OMAP5: Switch to THUMB mode if needed on secondary CPU · da0159fd
      Joel Fernandes authored 
      On my DRA7 system, when the kernel is built in Thumb-2 mode, the secondary CPU
(Cortex A15) fails to come up causing SMP boot on second CPU to timeout. This
seems to be because the CPU is in ARM mode once the ROM hands over control to
the kernel.  Switch to Thumb-2 mode if required once the kernel is control of
secondary CPU. On OMAP4 on the other hand, it appears to be in Thumb-2 mode on
entry so this is not required and SMP boot works as is.

Also corrected a spurious '+' and updated copyright information.

Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Nishanth Menon <nm@ti.com>
Tested-by: default avatarNishanth Menon <nm@ti.com>
Acked-by: default avatarSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: default avatarJoel Fernandes <joelf@ti.com>
Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      da0159fd
    • Dave Gerlach's avatar
      ARM: dts: am437x-gp-evm: Do not reset gpio5 · 1ff3859e
      Dave Gerlach authored 
      Do not reset GPIO5 at boot-up because GPIO5_7 is used
on AM437x GP-EVM to control VTT regulators on DDR3.
Without this some GP-EVM boards will fail to boot because
of DDR3 corruption.
Reported-by: default avatarNishanth Menon <nm@ti.com>
Tested-by: default avatarNishanth Menon <nm@ti.com>
Signed-off-by: default avatarDave Gerlach <d-gerlach@ti.com>
Signed-off-by: default avatarLokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      1ff3859e
    • Javier Martinez Canillas's avatar
      ARM: dts: omap3-igep0020: use SMSC9221 timings · ef139e13
      Javier Martinez Canillas authored 
      The IGEPv2 board has a SMSC LAN9221i ethernet chip and not a
SMSC LAN911x connected to the GPMC. Each chip needs different
timings in order to operate correctly so is wrong to include
omap-gpmc-smsc911x.dtsi instead of omap-gpmc-smsc9221.dtsi.
Signed-off-by: default avatarJavier Martinez Canillas <javier.martinez@collabora.co.uk>
[tony@atomide.com: this is needed to avoid potential memory corruption]
Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      ef139e13
    • Arnd Bergmann's avatar
      Merge tag 'zynq-dt-fixes-for-3.15' of git://git.xilinx.com/linux-xlnx into fixes · 76e7745e
      Arnd Bergmann authored 
      arm: Xilinx Zynq DT fixes for v3.15

- Enable Zynq I2c
- Fix cpufreq DT binding

* tag 'zynq-dt-fixes-for-3.15' of git://git.xilinx.com/linux-xlnx:
  ARM: zynq: dt: Add I2C nodes to Zynq device tree
  ARM: zynq: DT: Add 'clock-latency' property
Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      76e7745e
  7. 24 Apr, 2014 20 commits
  9. 23 Apr, 2014 4 commits
    • Tony Lindgren's avatar
      ARM: dts: Fix GPMC timings for LAN9220 · dcf21919
      Tony Lindgren authored 
      I've noticed occasional random oopsing on my gateway
machine since I upgraded it to use device tree based
booting. As this machine has worked reliably before
that for a few years, pretty much the only difference
was narrowed down to the GPMC timings. Turns out that
for legacy based booting we are using bootloader timings
for GPMC for smsc911x. With device tree we are passing
the timings in the .dts file, and the device tree
timings are not quite suitable for LAN9920.

Enabling DEBUG in gpmc.c I noticed that the device tree
configured timings are different from the the known
working bootloader timings. So let's fix the timings to
match the bootloader timings when looked at the gpmc
dmesg output with DEBUG enabled.

The changes were done by multiplying the bootloader
tick values by six to get the nanosecond value for
device tree. This is not generic from the device point
of view as the calculations should be based on the device
timings. Anyways, further improvments can be done based
on the timings documentation for LAN9220. But let's first
get things to a known good working state.

Note that we still need to change the timings also for
sb-t35 also as it has two LAN9220 instances on GPMC and
we can currently include the generic timings only once.

Also note that any boards that have LAN9221 instead of
LAN9220 should be updated to use omap-gpmc-smsc9221.dtsi
instead of omap-gpmc-smsc911x.dtsi. The LAN9221 timings
are different from LAN9220 timings.

Cc: Christoph Fritz <chf.fritz@googlemail.com>
Cc: Dmitry Lifshitz <lifshitz@compulab.co.il>
Cc: Javier Martinez Canillas <javier@dowhile0.org>
Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      dcf21919
    • Tony Lindgren's avatar
      ARM: dts: Fix GPMC Ethernet timings for omap cm-t sbc-t boards for device tree · de9949a4
      Tony Lindgren authored 
      Looks like we have wrong GPMC timings we have for the cm-t and
sbc-t boards. This can cause occasional strange errors with at
least doing an rsync of large files or doing apt-get dist-upgrade.

Let's fix the issue in two phases. First let's simplify cm-t and
sbc-t to use the shared omap-gpmc-smsc911x.dtsi to avoid fixing
the issue in multiple places. Then we can fix the timings in
a single place with a follow-up patch.

Cc: Dmitry Lifshitz <lifshitz@compulab.co.il>
Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      de9949a4
    • Tony Lindgren's avatar
      ARM: dts: Fix bad OTG muxing for cm-t boards · 20f670dc
      Tony Lindgren authored 
      Looks like the OTG pins are off by 2 and we get this:

pinctrl-single 48002030.pinmux: pin 480021a0.0 already requested by 49020000.serial; cannot claim for 480ab000.usb_otg_hs
pinctrl-single 48002030.pinmux: pin-184 (480ab000.usb_otg_hs) status -22
pinctrl-single 48002030.pinmux: could not request pin 184 (480021a0.0) from group pinmux_hsusb0_pins  on device pinctrl-single
musb-omap2430 480ab000.usb_otg_hs: Error applying setting, reverse things back

That's probably because the TRM lists the values as
32-bit registers so every second needs 2 added to the
address. The OTG pin start range must start from
0x21a2, not 0x21a0.

Cc: Dmitry Lifshitz <lifshitz@compulab.co.il>
Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      20f670dc
    • Tony Lindgren's avatar
      ARM: OMAP2+: Fix GPMC remap for devices using an offset · fb677ef7
      Tony Lindgren authored 
      At least the smc91x driver expects the device to be at 0x300
offset from bus base address. This does not work currently
for GPMC when booted in device tree mode as it attempts to
remap the the allocated GPMC partition to the address
configured by the device tree plus the device offset.

Note that this works just fine when booted with legacy mode.

Let's fix the issue by just ignoring any device specific
offset while remapping. And let's make sure the remap
address confirms to the GPMC 16MB minimum granularity
as listed in the TRM for GPMC_CONFIG7 BASEADDRESS bits.

Otherwise we can get something like this:

omap-gpmc 6e000000.gpmc: cannot remap GPMC CS 1 to 0x01000300

Cc: Pekon Gupta <pekon@ti.com>
Reviewed-by: default avatarJavier Martinez Canillas <javier@dowhile0.org>
Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      fb677ef7
  11. 22 Apr, 2014 3 commits
  13. 20 Apr, 2014 3 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7