ARM: dts: dra7-evm: Fix typo in SMPS6 (VDD_GPU) max voltage

The max expected voltage for VDD_GPU, connected to SMPS6, is 1.25V.
Correct regulator max voltage constraint to meet this requirement.

Document reference: DRA74 Data Manual, SPRS857M - Dec 2012, Revised Oct 2014.

Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Ravikumar Kattekola <rk@ti.com>
ARM: dts: dra7-evm: Update SMPS7 (VDD_CORE) max voltage to match DM

As per the latest Data Manual, for newer samples,
the nominal voltage required for VDD_CORE at OPP_NOM can be upto 1.06V
which was 1.03V earlier.

Update the regulator max voltage constraint for SMPS7,
connected to VDD_CORE, to meet this requirement.

Document reference:
DRA74 Data Manual, SPRS857M - Dec 2012, Revised Oct 2014.
DRA72 Data Manual, SPRS906G - Dec 2012, revised Oct 2014.

Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Ravikumar Kattekola <rk@ti.com>
Merge branch 'platform-ti-linux-3.14.y' of git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree into ti-linux-3.14.y

TI-Feature: platform_base
TI-Tree: git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree.git
TI-Branch: platform-ti-linux-3.14.y

* 'platform-ti-linux-3.14.y' of git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree:
  ARM: dts: dra7-evm: Update SMPS7 (VDD_CORE) max voltage to match DM
  ARM: dts: dra7-evm: Fix typo in SMPS6 (VDD_GPU) max voltage

Signed-off-by: Dan Murphy <DMurphy@ti.com>
drivers: net : cpsw: Update Kconfig for CPSW

CPSW is present in AM33xx, AM43xx, DRA7xx.
Updating the Kconfig to depend on ARCH_OMAP2PLUS instead of listing
all SoC's.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
can: mark device as pm_runtime_irq_safe

When CONFIG_DEBUG_ATOMIC_SLEEP is enabled we get the below BUG trace
each time CAN interface is configured.

The problem is that networking core (rtnl_dump_ifinfo()) holds the
RCU read lock while calling  the CAN driver's c_can_get_berr_counter()
which calls pm_runtime_get_sync() which is not yet marked atomic safe.

The solution is to call pm_runtime_irq_safe() in the CAN driver.
At least for TI platforms that support CAN (AM33xx/AM43xx/DRA7) we are sure
that the runtime callbacks are IRQ safe. The CAN module's parent is OCP which
is most likely never runtime suspended due to other children like GPIO also
calling pm_runtime_irq_safe(). So we don't impact runtime power..

[   22.605856] BUG: sleeping function called from invalid context at drivers/base/power/runtime.c:953
[   22.615516] in_atomic(): 1, irqs_disabled(): 0, pid: 2279, name: ip
[   22.622231] CPU: 0 PID: 2279 Comm: ip Not tainted 3.14.25-02414-gc56aa19 #806
[   22.629854] Backtrace:
[   22.632498] [<c00121e4>] (dump_backtrace) from [<c00124e0>] (show_stack+0x18/0x1c)
[   22.640588]  r7:bf00147c r6:ecd8c018 r5:c0903514 r4:00000000
[   22.646652] [<c00124c8>] (show_stack) from [<c062c7b0>] (dump_stack+0x90/0xb8)
[   22.654382] [<c062c720>] (dump_stack) from [<c006b2a0>] (__might_sleep+0xd0/0x100)
[   22.662468]  r7:bf00147c r6:00000000 r5:00000004 r4:ecd8c000
[   22.668519] [<c006b1d0>] (__might_sleep) from [<c03b9ac0>] (__pm_runtime_resume+0x90/0xa0)
[   22.677358]  r4:ec96c210
[   22.680093] [<c03b9a30>] (__pm_runtime_resume) from [<bf0060e0>] (c_can_get_berr_counter+0x28/0x68 [c_can])
[   22.690495]  r7:bf00147c r6:00000000 r5:ecd8da9c r4:eccc2800
[   22.696561] [<bf0060b8>] (c_can_get_berr_counter [c_can]) from [<bf0006a4>] (can_fill_info+0x124/0x174 [can_dev])
[   22.707516]  r5:ece8a600 r4:eccc2800
[   22.711367] [<bf000580>] (can_fill_info [can_dev]) from [<c0570450>] (rtnl_fill_ifinfo+0x578/0x91c)
[   22.721028]  r6:ece8a600 r5:eb8c24b0 r4:eccc2800
[   22.725961] [<c056fed8>] (rtnl_fill_ifinfo) from [<c05711ec>] (rtnl_dump_ifinfo+0x10c/0x228)
[   22.734972]  r10:00000000 r9:ece8a600 r8:00000001 r7:00000000 r6:ecfd5234 r5:eccc2800
[   22.743340]  r4:00000000
[   22.746054] [<c05710e0>] (rtnl_dump_ifinfo) from [<c057c598>] (netlink_dump+0xa4/0x1d8)
[   22.754613]  r10:00000000 r9:ecfd5234 r8:ecf53c80 r7:ecd8dd24 r6:ecfd5234 r5:ece8a600
[   22.762983]  r4:ecfd5000
[   22.765684] [<c057c4f4>] (netlink_dump) from [<c057d56c>] (__netlink_dump_start+0x110/0x16c)
[   22.774694]  r6:00000000 r5:ecc7e840 r4:ecfd5000
[   22.779638] [<c057d45c>] (__netlink_dump_start) from [<c05716dc>] (rtnetlink_rcv_msg+0x118/0x210)
[   22.789110]  r9:00000000 r8:c05710e0 r7:00000000 r6:ecc7e840 r5:ecf53c80 r4:00000484
[   22.797382] [<c05715c4>] (rtnetlink_rcv_msg) from [<c057efd8>] (netlink_rcv_skb+0xa8/0xc4)
[   22.806214]  r8:ecd8dd9c r7:ecc7e840 r6:ecc7e840 r5:c05715c4 r4:ecf53c80
[   22.813387] [<c057ef30>] (netlink_rcv_skb) from [<c05715b4>] (rtnetlink_rcv+0x24/0x34)
[   22.821843]  r7:ecc7e840 r6:ecfd5000 r5:0000001c r4:ecc7e840
[   22.827894] [<c0571590>] (rtnetlink_rcv) from [<c057e910>] (netlink_unicast+0x15c/0x220)
[   22.836532]  r5:0000001c r4:ec8fd000
[   22.840365] [<c057e7b4>] (netlink_unicast) from [<c057ed5c>] (netlink_sendmsg+0x2c8/0x3a0)
[   22.849194]  r9:00000000 r8:ecc7e840 r7:ecfd5000 r6:ecd8de68 r5:00000000 r4:ecd8ded4
[   22.857482] [<c057ea94>] (netlink_sendmsg) from [<c05496ec>] (sock_sendmsg+0x8c/0xb0)
[   22.865846]  r10:00000000 r9:ecd8c000 r8:c000ec44 r7:be8d46bc r6:ec137580 r5:ecaaa4c0
[   22.874219]  r4:c057ea94
[   22.876921] [<c0549660>] (sock_sendmsg) from [<c054ba4c>] (SyS_sendto+0xbc/0xe0)
[   22.884821]  r5:00000000 r4:0000001c
[   22.888649] [<c054b990>] (SyS_sendto) from [<c054ba90>] (SyS_send+0x20/0x28)
[   22.896162]  r7:00000121 r6:0004961c r5:00045344 r4:0000001c
[   22.902234] [<c054ba70>] (SyS_send) from [<c000eac0>] (ret_fast_syscall+0x0/0x30)

Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
tty: serial: omap: add option for external uart select

In some platforms the uart pins can be selected by a GPIO.
The GPIO for the UART selection is passed through DT and is an optional
property.
When passed, the GPIO is set once, at probe time.

Signed-off-by: Eyal Reizer <eyalr@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
ARM: DTS: dra7-evm: Add UART3 select gpio

On dra7xx platform, UART3 going in to WiLink hardware is selected by
driving the GPIO, SEL_UART3_SPI2 low, coming out of PCF8575 chip.

Signed-off-by: Eyal Reizer <eyalr@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
dma: cppi41: wait longer for the HW to return the descriptor

For a "complete" teardown we have to wait until the teardown descriptor
is returned by the hardware. The g_zero testcase "testusb -a -t 9" triggers
the following warning quite reliable:

|------------[ cut here ]------------
|WARNING: CPU: 0 PID: 0 at drivers/dma/cppi41.c:609 cppi41_dma_control+0x198/0x304()
|[<c003f84c>] (warn_slowpath_null) from [<c02be8d8>]
|[<c02be8d8>] (cppi41_dma_control) from [<bf08d25c>]
|[<bf08d25c>] (cppi41_dma_channel_abort [musb_hdrc])
|[<bf08bc38>] (nuke.constprop.10 [musb_hdrc])
|[<bf08bd08>] (musb_gadget_disable [musb_hdrc])
|[<bf252524>] (disable_endpoints [usb_f_ss_lb])
|[<bf2525d8>] (disable_source_sink [usb_f_ss_lb])
|[<bf25260c>] (sourcesink_set_alt [usb_f_ss_lb])
|[<bf23ad24>] (composite_setup [libcomposite])
|[<bf08a2f4>] (musb_g_ep0_irq [musb_hdrc])
|[<bf085ec4>] (musb_interrupt [musb_hdrc])
|[<bf0aeaf4>] (dsps_interrupt [musb_dsps])
|[<c0080ea8>] (handle_irq_event_percpu)
|[<c008112c>] (handle_irq_event)
|[<c008348c>] (handle_level_irq)
|[<c00807a8>] (generic_handle_irq)
|[<c000ee80>] (handle_IRQ)
|[<c00085f0>] (omap3_intc_handle_irq)

and complains about a TD descriptor which is not returned. I've been
looking at several things and haven't noticed anything unusual that
might lead to this.
The manual says "to try again" until the descriptor comes out. I limited
the amount of retries to 100 retries in order to avoid an infinite number
of retries and so a busy-loop. Back then testing revealed that the
number of retries were around 20-30 so 100 seemed a good upper limit.
This g_zero test reaches without a problem 98 retries and it jumps
sometimes to 101 on am335x-evm and so the WARN_ON() triggers. Same test
run on beaglebone black and the retries start at 122 and my max value so
far was at 128.
So lets rise the limit to 500.

Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
dma: cppi41: add a delay while setting the TD bit

The manual says that we need to (repeatedly) set the TearDown-bit for
the endpoint in order to get the active transfer descriptor released.
Doing this "real" quick over and over again seems to work but it also
seems that the hardware might not have enough time to breathe. So I
though, hey lets add a udelay() between between the individual sets
of the bit.
This change with the g_zero testcase resulted in a warning about missing
transfer descriptor (we got the tear-down one). It seems that if the
hardware has some time it manages to release the transfer-descriptor on
the completion queue after the teaddown descriptor.
With this change, I observe that the transfer descriptor is released
after 20-30 retry loops.

Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Merge branch 'connectivity-ti-linux-3.14.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel into ti-linux-3.14.y

TI-Feature: connectivity
TI-Tree: git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel.git
TI-Branch: connectivity-ti-linux-3.14.y

* 'connectivity-ti-linux-3.14.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel:
  dma: cppi41: add a delay while setting the TD bit
  dma: cppi41: wait longer for the HW to return the descriptor
  ARM: DTS: dra7-evm: Add UART3 select gpio
  tty: serial: omap: add option for external uart select
  can: mark device as pm_runtime_irq_safe
  drivers: net : cpsw: Update Kconfig for CPSW

Signed-off-by: Dan Murphy <DMurphy@ti.com>