ARM: OMAP5: hwmod data: add mmu data for ipu & dsp

[ Upstream commit 1528ed0400e4852316a66cacc55b57e46e187a5a ]

A new MMU hwmod class and data structures are created
to represent the MMUs within the IPU and DSP processor
subsystems in OMAP5. The MMUs in OMAP5 are identical to
those in OMAP4.

Cc: Benoit Cousson <bcousson@baylibre.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Acked-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

ARM: OMAP2+: Fix DMA hang after off-idle

[ Upstream commit 9ce2482fc6b22709df087d4a8387b67893176312 ]

Commit 6ddeb6d84459 (dmaengine: omap-dma: move IRQ handling to omap-dma)
added support for handling interrupts in the omap dmaengine driver
instead of the legacy driver. Because of different handling for
interrupts this however caused omap3 to hang eventually after hitting
off-idle.

Any of the virtual 32 DMA channels can be assigned to any of the
four DMA interrupts. So commit 6ddeb6d84459 made the omap dmaengine
driver to use the second DMA interrupt while keeping the legacy code
still using the first DMA interrupt.

This means we need to save and restore both IRQENABLE_L1 in addition
to IRQENABLE_L0. As there is a chance that the DSP might be using
IRQENABLE_L2 or IRQENABLE_L3 lines, let's not touch those until
this has been confirmed. Let's just add a comment to the code for
now.

Fixes: 6ddeb6d84459 (dmaengine: omap-dma: move IRQ handling to omap-dma)
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

ARM: OMAP2+: nand: Fix NAND on OMAP2 and OMAP3 boards

[ Upstream commit 5005e0b76781c37d0a16dd6dd17d015098e8ce92 ]

Commit c66d039197e4 broke NAND for non-DT boot on all OMAP2 and OMAP3
boards using board_nand_init(). Following error is seen at boot

[    0.154998]  (null): Unsupported NAND ECC scheme selected

For OMAP2 and OMAP3 platforms, the ecc_opt parameter in platform data
must be set to OMAP_ECC_HAM1_CODE_HW to work properly.

Tested on omap3-beagle c4.

Fixes: c66d039197e4 (mtd: nand: omap: combine different flavours of 1-bit hamming ecc schemes)
Cc: stable@vger.kernel.org # v3.12+
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

ARM: dts: omap5: Add clocks to USB3 PHY node

[ Upstream commit ada76576404330413eaeb864a265ad250af48d8f ]

The USB3 PHY driver (ti-pipe3) was updated so that the relevant
clock phandles are expected in the DT node.
Provide the necessary clocks.

Reported-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Acked-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

usb: gadget: rndis: Include "u_rndis.h"

[ Upstream commit ae8dd0cc4146740e24ffb2092530c47e838001c5 ]

[ Upstream commit ae8dd0cc4146740e24ffb2092530c47e838001c5 ]

Include "u_rndis.h" in order to fix the following sparse warning:

drivers/usb/gadget/rndis.c:1144:5: warning: symbol 'rndis_init' was not declared. Should it be static?
drivers/usb/gadget/rndis.c:1177:6: warning: symbol 'rndis_exit' was not declared. Should it be static?

Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

ARM: OMAP3: hwmod data: Correct clock domains for USB modules

[ Upstream commit c6c56697ae4bf1226263c19e8353343d7083f40e ]

[ Upstream commit c6c56697ae4bf1226263c19e8353343d7083f40e ]

[ Upstream commit c6c56697ae4bf1226263c19e8353343d7083f40e ]

[ Upstream commit c6c56697ae4bf1226263c19e8353343d7083f40e ]

OMAP3 doesn't contain "l3_init_clkdm" clock domain. Use the
proper clock domains for USB Host and USB TLL modules.

Gets rid of the following warnings during boot
 omap_hwmod: usb_host_hs: could not associate to clkdm l3_init_clkdm
 omap_hwmod: usb_tll_hs: could not associate to clkdm l3_init_clkdm

Reported-by: Nishanth Menon <nm@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Fixes: de231388cb80a8ef3e779bbfa0564ba0157b7377 ("ARM: OMAP: USB: EHCI and OHCI hwmod structures for OMAP3")
Cc: Keshava Munegowda <keshava_mgowda@ti.com>
Cc: Partha Basak <parthab@india.ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

mfd: omap-usb-tll: Update DT clock binding information

[ Upstream commit 2e1b365cea4a0a750b8ffd4bc6ca5e9e8020f53e ]

The omap-usb-tll driver needs one clock for each TLL channel.
Add this information to the DT binding document.

Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

mfd: omap-usb-host: Update DT clock binding information

[ Upstream commit c233544f303259b2e611c5a63c4dcb54daefe693 ]

The omap-usb-host driver expects certained named clocks.
Add this information to the DT binding document.

Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

mfd: omap-usb-host: Use clock names as per function for reference clocks

[ Upstream commit 051fc06dfaa322e1079edc476e6e2500220c562d ]

Use a meaningful name for the reference clocks so that it indicates the
function.

Update the OMAP4+ USB Host node as well to be in sync with the changes.

Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

mfd: omap-usb-host: Use proper clock name instead of alias

[ Upstream commit 775bb078e9af9747f7d4064939e1a50195c9fb4b ]

Use the proper clock name 'usbhost_120m_fck' instead of the
alias 'ehci_logic_fck'

Get rid of the 'ehci_logic_fck' alias from the OMAP3 hwmod data
as well.

Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

mfd: omap-usb-host: Always fail on clk_get() error

[ Upstream commit fedb2e7c2d7b80dfda6d906f665ff01f368e7b51 ]

Be more strict and always fail on clk_get() error.

Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

mfd: omap-usb-host: Get clocks based on hardware revision

[ Upstream commit 3aca446acf32243029f5c83810b50aad3c32b6bf ]

Not all revisions have all the clocks so get the necessary clocks
based on hardware revision.

This should avoid un-necessary clk_get failure messages that were
observed earlier.

Also remove the dummy USB host clocks from the OMAP3 clock data.
These are no longer expected by the driver.

Acked-by: Mike Turquette <mturquette@linaro.org> [OMAP3 CLK data]
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

mfd: omap-usb-host: Use resource managed clk_get()

[ Upstream commit 61b7025f6d6cebc9a8ebbe020c4de5a76a536c90 ]

Use devm_clk_get() instead of clk_get().

Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

mfd: omap-usb-tll: Fix cppcheck sizeof warning

[ Upstream commit 39a85bcbfc54d602934e2657c146c299d71b27ba ]

Static analysis from cppcheck issued the following warning:

[drivers/mfd/omap-usb-tll.c:255]: (warning) Found calculation
  inside sizeof().

The current size calculation is not obvious and is easy to
miscomprehend, so re-work the size of the allocation based
on the size of the struct pointer and quantity to allocate.

Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

phy: omap: Depend on OMAP_OCP2SCP bus driver

[ Upstream commit 02133b9e54ed19e07348ff7abf75aeb92c94d901 ]

The OMAP_USB2 and OMAP_PIPE3 PHY devices will not be
detected if the OMAP_OCP2SCP bus driver is not present.
Make them depend on it.

Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

phy: ti-pipe3: Fix suspend/resume and module reload

[ Upstream commit 56042e4e975ce7b0817ebc024d02fa96ee01e107 ]

Due to Errata i783, SATA breaks if its DPLL is idled. The recommeded
workaround to issue a softreset to the SATA controller doesn't seem to
work. Here we just prevent SATA DPLL from Idling and hence avoid
the issue altogether.

Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

phy: ti-pipe3: streamline PHY operations

[ Upstream commit 629138dbaec33cecbb61fda1f5c1f047a1374993 ]

Limit .power_on() and .power_off() to just control the
PHY power and not the DPLL. The DPLL will be enabled
in .init() and idled in .exit().

Don't reprogram the DPLL if it has been already locked
by the bootloader. This fixes a problem with SATA, where
it fails if SATA was used by the bootloader.

Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

phy: ti-pipe3: Don't get 'wkupclk' and 'refclk' for SATA PHY

[ Upstream commit 9c7f04436088b00727fa389e2b97b182d8488123 ]

SATA PHY doesn't need 'wkupclk; and 'refclk' so don't
try to get them for SATA PHY.

Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

phy: ti-pipe3: Add SATA DPLL support

[ Upstream commit 61f546747715683c334ef231fd648522312dc5ff ]

USB and SATA DPLLs need different settings. Provide
the SATA DPLL settings and use the proper DPLL settings
based on device tree node's compatible_id.

Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

phy: ti-pipe3: cleanup clock handling

[ Upstream commit 1562864f0f034ea393230b470d104e1196b4a5f1 ]

As this driver is no longer USB specific, use generic clock names.
- Fix PLL_SD_SHIFT from 9 to 10
- Don't separate prepare/unprepare clock from enable/disable. This
  ensures optimal power savings.

Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

phy: omap-control: update dra7 and am437 usb2 bindings

[ Upstream commit 51c9f4adaee3fb01bb6f2e2ed72c0753c2609912 ]

The dra7-usb2 and am437-usb2 bindings have not yet been used.
Change them to be more elegant.

Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

phy: ti-pipe3: Add SATA compatible to Documentation binding

[ Upstream commit 4b76e14d95f7b69e71eabc002dcb0dcb9ebb5340 ]

SATA PHY needs a new compatible ID. Add it to the DT binding documentation.

Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

Documentation: dt bindings: move ..usb/usb-phy.txt to ..phy/ti-phy.txt

[ Upstream commit 8d7212bc4107b343e93c13aa30c70b845f7f94ad ]

Since now we have a separate folder for phy, move the PHY dt binding
documentation of TI to that folder.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

phy: ti-pipe3: Add clocks to PIPE3 PHY Documentation binding

[ Upstream commit 57554008699a640c7af114c3f67707a9b88d69a6 ]

Add wakeup, system and reference clocks to DT binding documentation.

Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

phy: omap-control: update dra7 and am437 usb2 Documentation bindings

[ Upstream commit e99952093169b6d6fce8d612d6540c18c8759fff ]

The dra7-usb2 and am437-usb2 bindings have not yet been used.
Change them to be more elegant.

Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

phy: omap-control: Update DT binding information

[ Upstream commit d95faaec4763b94c9eedac9a1f933753015651ed ]

Move omap-control binding information to the right location.

Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

ARM: dts: Get rid of incompatible ids for hci-omap USB host nodes

[ Upstream commit a2525e5404766d25474e164b818098ad348f3444 ]

[ Upstream commit a2525e5404766d25474e164b818098ad348f3444 ]

The OMAP EHCI and OHCI controllers are not compatible with drivers
other than "ti,ehci-omap" and "ti,ohci-omap3" respectively, so get
rid of the incompatible ids.

CC: Alan Stern <stern@rowland.harvard.edu>
CC: Nishant Menon <nm@ti.com>
CC: Kevin Hilman <khilman@linaro.org>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

ata: ahci_platform: runtime resume the device before use

[ Upstream commit e708e46edac8ab2f31e7ee991aa3c5b87638e658 ]

On OMAP platforms the device needs to be runtime resumed before it can
be accessed. The OMAP HWMOD framework takes care of enabling the
module and its resources based on the device's runtime PM state.

In this patch we runtime resume during .probe() and runtime suspend
after .remove().

We also update the runtime PM state during .resume().

CC: Balaji T K <balajitk@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

ata: ahci_platform: Manage SATA PHY

[ Upstream commit 21b5faeec229d4f70a7f60a7b0b065c98198f491 ]

Some platforms have a PHY hooked up to the SATA controller. The PHY
needs to be initialized and powered up for SATA to work. We do that
using the PHY framework.

tj: Minor comment formatting updates.

CC: Balaji T K <balajitk@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Tejun Heo<tj@kernel.org>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

ata: ahci_platform: Update DT compatible list

[ Upstream commit 42a7f53ba0f2baa2ea23cd830511cea7f8612dd2 ]

The ahci_platform driver supports "snps,dwc-ahci".
Add this to the DT binding information.

Signed-off-by: Roger Quadros <rogerq@ti.com>
Reviewed-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

ata: ahci_platform: Add DT compatible for Synopsis DWC AHCI controller

[ Upstream commit c431147184c05849f1d7e14f8fd6254e1026319d ]

Add compatible string "snps,dwc-ahci", which should be used
for Synopsis Designware SATA cores. e.g. on TI OMAP5 and DRA7 platforms.

Signed-off-by: Roger Quadros <rogerq@ti.com>
Reviewed-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

ahci-imx: Port to library-ised ahci_platform

[ Upstream commit 90870d79d4f28711610dd2e72d8fa616c922d110 ]

This avoids the ugliness of creating a nested platform device from probe.

While moving it around anyways, move the mk6q phy init code from probe
to imx_sata_enable, as the phy needs to be re-initialized on resume too,
otherwise the drive won't be recognized after resume.

Tested on a wandboard i.mx6 quad.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

ARM: sunxi: Add support for Allwinner SUNXi SoCs sata to ahci_platform

[ Upstream commit c5754b5220f01e8722799d35c04a76e82c62d7d8 ]

This patch adds support for the ahci sata controler found on Allwinner A10
and A20 SoCs to the ahci_platform driver.

Orignally written by Olliver Schinagl using the approach of having a platform
device which probe method creates a new child platform device which gets
driven by ahci_platform.c, as done by ahci_imx.c .

Refactored by Hans de Goede to add most of the non sunxi specific functionality
to ahci_platform.c and use a platform_data pointer from of_device_id for the
sunxi specific bits.

Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

ahci-platform: "Library-ise" suspend / resume functionality

[ Upstream commit 648cb6fd83b97f0f772db783a280af300fa9f2bc ]

Split suspend / resume code into host suspend / resume functionality and
resource enable / disabling phases, and export the new suspend_ / resume_host
functions.

tj: Minor comment formatting updates.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

ahci-platform: "Library-ise" ahci_probe functionality

[ Upstream commit 23b07d4cb3c0c850055cf968af44019b8da185fb ]

ahci_probe consists of 3 steps:
1) Get resources (get mmio, clks, regulator)
2) Enable resources, handled by ahci_platform_enable_resouces
3) The more or less standard ahci-host controller init sequence

This commit refactors step 1 and 3 into separate functions, so the platform
drivers for AHCI implementations which need a specific order in step 2,
and / or need to do some custom register poking at some time, can re-use
ahci-platform.c code without needing to copy and paste it.

Note that ahci_platform_init_host's prototype takes the 3 non function
members of ahci_platform_data as arguments, the idea is that drivers using
the new exported utility functions will not use ahci_platform_data at all,
and hopefully in the future ahci_platform_data can go away entirely.

tj: Minor comment formatting updates.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

ahci-platform: Add enable_ / disable_resources helper functions

[ Upstream commit 96a01ba52c60fdd74dd6e8cf06645d06515b1396 ]

tj: Minor comment formatting updates.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

ahci-platform: Add support for an optional regulator for sata-target power

[ Upstream commit 4b3e603a298db26c6c37e8b08adcce24d014df13 ]

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

ahci-platform: Add support for devices with more then 1 clock

[ Upstream commit 156c5887948cd191417f18026aab9ce26e5a95da ]

The allwinner-sun4i AHCI controller needs 2 clocks to be enabled and the
imx AHCI controller needs 3 clocks to be enabled.

tj: Minor comment formatting updates.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

libahci: Allow drivers to override start_engine

[ Upstream commit 039ece38da45f5e6a94be3aa7611cf3634bc2461 ]

Allwinner A10 and A20 ARM SoCs have an AHCI sata controller which needs a
special register to be poked before starting the DMA engine.

This register gets reset on an ahci_stop_engine call, so there is no other
place then ahci_start_engine where this poking can be done.

This commit allows drivers to override ahci_start_engine behavior for use by
the Allwinner AHCI driver (and potentially other drivers in the future).

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

ata: delete non-required instances of include <linux/init.h>

[ Upstream commit 1bc18086231c130895b87ec049be8ddcdab552b8 ]

None of these files are actually using any __init type directives
and hence don't need to include <linux/init.h>.  Most are just a
left over from __devinit and __cpuinit removal, or simply due to
code getting copied from one driver to the next.

Cc: linux-ide@vger.kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

ARM: OMAP4: Fix the boot regression with CPU_IDLE enabled

[ Upstream commit 4b353a706a86598ba47307c47301c3c428b79e09 ]

On OMAP4 panda board, there have been several bug reports about boot
hang and lock-ups with CPU_IDLE enabled. The root cause of the issue
is missing interrupts while in idle state. Commit cb7094e8 {cpuidle / omap4 :
use CPUIDLE_FLAG_TIMER_STOP flag} moved the broadcast notifiers to common
code for right reasons but on OMAP4 which suffers from a nasty ROM code
bug with GIC, commit ff999b8a {ARM: OMAP4460: Workaround for ROM bug ..},
we loose interrupts which leads to issues like lock-up, hangs etc.

Patch reverts commit cb7094 {cpuidle / omap4 : use CPUIDLE_FLAG_TIMER_STOP
flag} and 54769d6 {cpuidle: OMAP4: remove timer broadcast initialization} to
avoid the issue. With this change, OMAP4 panda boards, the mentioned
issues are getting fixed. We no longer loose interrupts which was the cause
of the regression.

Fixes: cb7094e8 (cpuidle / omap4 : use CPUIDLE_FLAG_TIMER_STOP flag)
Fixes: ff999b8a (cpuidle: OMAP4: remove timer broadcast initialization)
Cc: stable@vger.kernel.org # v3.9+
Cc: Roger Quadros <rogerq@ti.com>
Cc: Kevin Hilman <khilman@linaro.org>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Reported-tested-by: Roger Quadros <rogerq@ti.com>
Reported-tested-by: Kevin Hilman <khilman@linaro.org>
Tested-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

ARM: omap5: hwmod_data: Correct IDLEMODE for McPDM

[ Upstream commit 0f9e19ad88eee820f517b85531b555a0fa73e7e4 ]

McPDM need to be configured to NO_IDLE mode when it is in used otherwise
vital clocks will be gated which results 'slow motion' audio playback.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: <stable@kernel.org>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

net: cpsw: add missing of_node_put

[ Upstream commit 60e71ab56b5fbd839aaef4f4af7778d86e0206f0 ]

Add missing of_node_put to avoid kref leak.

Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

net: cpsw: fix null dereference at probe

[ Upstream commit 6954cc1f238199e971ec905c5cc87120806ac981 ]

Fix null-pointer dereference at probe when the mdio platform device is
missing (e.g. when it has been disabled in DT).

Cc: stable <stable@vger.kernel.org> # v3.8
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

Revert "net: eth: cpsw: Correctly attach to GPIO bitbang MDIO driver"

[ Upstream commit 59993f48b38fd46863b23bb1bb1dc3291e7278fb ]

This reverts commit f8d56d8f892be43a2404356073e16401eb5a42e6 ("net:
 eth: cpsw: Correctly attach to GPIO bitbang MDIO driver").

Fix potential null-pointer dereference at probe if the mdio-gpio device
has not been successfully probed yet.

The offending commit is plain wrong for a number of reasons. First of
all it accesses internal driver data of an unrelated device. Neither
does it check that the data is non-null (which it is in case the device
has not been probed yet).

Furthermore, the decision on whether to treat any driver data according
to the mdio-gpio driver's internals is made based on the node name. But
the name is not compared against "mdio" which is the normal name for the
node, but rather against "gpio" which the node does not have to be named
(and shouldn't be according to the binding documentation). [ If this
hack is to be kept out-of-tree it should at least be matching against
the compatible property. ]

Cc: Stefan Roese <sr@denx.de>
Cc: stable <stable@vger.kernel.org> # v3.14
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

ARM: dts: AM3517: Disable absent IPs inherited from OMAP3

[ Upstream commit 4c05160342f16361fc37ae34dcae9210306a83e9 ]

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: Suman Anna <s-anna@ti.com>
[tony@atomide.com: updated description for the warnings]
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

ARM: dts: OMAP2: Fix interrupts for OMAP2420 mailbox

[ Upstream commit 4fe5bd5da2ea7b1b8c9455246ddcdb39ab734487 ]

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: Suman Anna <s-anna@ti.com>
[tony@atomide.com: updated description]
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

ARM: dts: OMAP5: Add mailbox dt node to fix boot warning

[ Upstream commit 84d89c3123bf4c3145f7b19fca36dba612a69807 ]

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: Suman Anna <s-anna@ti.com>
[tony@atomide.com: updated description to for the warning]
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

ARM: OMAP5: Switch to THUMB mode if needed on secondary CPU

[ Upstream commit da0159fdb57d6fab54ce3179659a1f9e5b593752 ]

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: Nishanth Menon <nm@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Joel Fernandes <joelf@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

ARM: dts: am437x-gp-evm: Do not reset gpio5

[ Upstream commit 1ff3859e7ea134c09512498aa2251fd3a57d250d ]

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: Nishanth Menon <nm@ti.com>
Tested-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

ARM: dts: Fix GPMC timings for LAN9220

[ Upstream commit dcf2191933c4d3b3d1fcd8b6f5818cc913baa8b2 ]

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: Tony Lindgren <tony@atomide.com>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

ARM: OMAP2+: Fix GPMC remap for devices using an offset

[ Upstream commit fb677ef70b65e22cd4401d31b700a8b4041efae1 ]

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: Javier Martinez Canillas <javier@dowhile0.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

ARM: OMAP2+: Fix oops for GPMC free

[ Upstream commit efe8072316a899294212055c147d3d9adca940a4 ]

If gpmc_cs_remap() fails we will get an error because we are calling
release_resource() on an uninitialized resource. Let's fix that by
checking the resource flags. And while at it, let's also make
gpmc_cs_delete_mem() use the res pointer that we already have to
avoid confusion.

Without this patch we can get the following error:

omap-gpmc 6e000000.gpmc: cannot remap GPMC CS 1 to 0x01000300
Unable to handle kernel NULL pointer dereference at virtual address 00000018
...
(gpmc_cs_free+0x94/0xc8)
(gpmc_probe_generic_child+0x178/0x1ec)
(gpmc_probe_dt+0x1bc/0x2cc)
(gpmc_probe+0x250/0x44c)
(platform_drv_probe+0x3c/0x6c)
(really_probe+0x74/0x208)
(driver_probe_device+0x34/0x50)
(bus_for_each_drv+0x60/0x8c)
(device_attach+0x80/0xa4)
(bus_probe_device+0x88/0xb0)
(device_add+0x320/0x450)
(of_platform_device_create_pdata+0x80/0x9c)
(of_platform_bus_create+0xd0/0x170)
(of_platform_bus_create+0x12c/0x170)
(of_platform_populate+0x60/0x98)
(pdata_quirks_init+0x30/0x48)
(customize_machine+0x20/0x48)
(do_one_initcall+0x2c/0x14c)
(do_basic_setup+0x98/0xd8)
(kernel_init_freeable+0x12c/0x1e0)
(kernel_init+0x8/0xf0)
(ret_from_fork+0x14/0x2c)
Code: e1a04000 e59f0070 eb195136 e5942010 (e5923018)

Cc: Pekon Gupta <pekon@ti.com>
Reviewed-by: Javier Martinez Canillas <javier@dowhile0.org>
Signed-off-by: tony Lindgren <tony@atomide.com>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

usb: phy: am335x-control: wait 1ms after power-up transitions

[ Upstream commit a31a942a148e0083ce560ffeb54fb60e06ab7201 ]

Tests have shown that when a power-up transition is followed by other
PHY operations too quickly, the USB port appears dead. Waiting 1ms fixes
this problem.

Signed-off-by: Daniel Mack <zonque@gmail.com>
Cc: stable@vger.kernel.org [3.14]
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

ARM: OMAP2+: Fix config name for USB3 PHY

[ Upstream commit 4883fb22796ba6661ca133d389bc14157a05f480 ]

commit a70143 (drivers: phy: usb3/pipe3: Adapt pipe3 driver to Generic PHY
Framework) moved phy-omap-usb3 driver in drivers/usb/phy to drivers/phy and
also renamed the file to phy-ti-pipe3. It also renamed the config from
OMAP_USB3 to TI_PIPE3 in Kconfig. However the config name was not changed in
omap2plus_defconfig. Fixed it here.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Acked-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

ARM: dts: dra7xx-clocks: Correct mcasp2_ahclkx_mux bit-shift

[ Upstream commit 8c0b4fd89ead67f5aca63abbadc81dd316b6462c ]

The correct bit is 24 for AHCLKX.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Acked-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

video: Kconfig: move drm and fb into separate menus

[ Upstream commit 776bbb97e0a37fe67bd0870e5aa4845af856b872 ]

At the moment the "Device Drivers / Graphics support" kernel config page
looks rather messy, with DRM and fbdev driver selections on the same
page, some on the top level Graphics support page, some under their
respective subsystems.

If I'm not mistaken, this is caused by the drivers depending on other
things than DRM or FB, which causes Kconfig to arrange the options in
not-so-neat manner.

Both DRM and FB have a main menuconfig option for the whole DRM or FB
subsystem. Optimally, this would be enough to arrange all DRM and FB
options under the respective subsystem, but for whatever reason this
doesn't work reliably.

This patch adds an explicit submenu for DRM and FB, making it much
clearer which options are related to FB, and which to DRM.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Jingoo Han <jg1.han@samsung.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

fbdev: move fbdev core files to separate directory

[ Upstream commit 19757fc8432ac97a07a890d6310cccc1896a1b36 ]

Instead of having fbdev framework core files at the root fbdev
directory, mixed with random fbdev device drivers, move the fbdev core
files to a separate core directory. This makes it much clearer which of
the files are actually part of the fbdev framework, and which are part
of device drivers.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Rob Clark <robdclark@gmail.com>
Acked-by: Jingoo Han <jg1.han@samsung.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

video: move fbdev to drivers/video/fbdev

[ Upstream commit f7018c21350204c4cf628462f229d44d03545254 ]

The drivers/video directory is a mess. It contains generic video related
files, directories for backlight, console, linux logo, lots of fbdev
device drivers, fbdev framework files.

Make some order into the chaos by creating drivers/video/fbdev
directory, and move all fbdev related files there.

No functionality is changed, although I guess it is possible that some
subtle Makefile build order related issue could be created by this
patch.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Rob Clark <robdclark@gmail.com>
Acked-by: Jingoo Han <jg1.han@samsung.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

usb: dwc3: core: Fix gadget for system suspend/resume

[ Upstream commit f45e5f00dacf09362a16339d372fcc96705e40c7 ]

During system resume, if the event buffers are not setup before
the gadget controller starts then we start with invalid context
and this can lead to bus access errors. This is especially true for
platforms that loose the controller context during system suspend.
e.g. AM437x.

The following backtrace was found when the system is suspended
and resumed with g_zero loaded on AM437x-evm (USB cable connected
to host all the while).

[  120.981506] WARNING: CPU: 0 PID: 1656 at drivers/bus/omap_l3_noc.c:137 l3_interrupt_handler+0x198/0x28c()
[  120.981514] L3 custom error: MASTER:USB0 WR TARGET:GPMC
[  120.981638] Modules linked in: g_mass_storage usb_f_mass_storage libcomposite configfs bufferclass_ti(O) omaplfb(O) cryptodev(O) dwc3 snd_soc_evm snd_soc_omap snd_pe
[  120.981659] CPU: 0 PID: 1656 Comm: sh Tainted: G           O 3.12.10-gc559824 #1
[  120.981669] Backtrace:
[  120.981705] [<c0017880>] (dump_backtrace+0x0/0x10c) from [<c0017a1c>] (show_stack+0x18/0x1c)
[  120.981730]  r6:c02819ac r5:00000009 r4:ec137cb8 r3:00000000
[  120.981767] [<c0017a04>] (show_stack+0x0/0x1c) from [<c056c0b0>] (dump_stack+0x20/0x28)
[  120.981802] [<c056c090>] (dump_stack+0x0/0x28) from [<c0046d08>] (warn_slowpath_common+0x70/0x90)
[  120.981830] [<c0046c98>] (warn_slowpath_common+0x0/0x90) from [<c0046dcc>] (warn_slowpath_fmt+0x38/0x40)
[  120.981856]  r8:c0855eb0 r7:00000002 r6:f1000700 r5:00000007 r4:80080003
[  120.981886] [<c0046d94>] (warn_slowpath_fmt+0x0/0x40) from [<c02819ac>] (l3_interrupt_handler+0x198/0x28c)
[  120.981900]  r3:c0801ab8 r2:c06cb354
[  120.981936] [<c0281814>] (l3_interrupt_handler+0x0/0x28c) from [<c007162c>] (handle_irq_event_percpu+0x54/0x1b8)
[  120.981962] [<c00715d8>] (handle_irq_event_percpu+0x0/0x1b8) from [<c00717c0>] (handle_irq_event+0x30/0x40)
[  120.981993] [<c0071790>] (handle_irq_event+0x0/0x40) from [<c0074058>] (handle_fasteoi_irq+0x74/0x128)
[  120.982006]  r4:ed0056c0 r3:00000000
[  120.982033] [<c0073fe4>] (handle_fasteoi_irq+0x0/0x128) from [<c0070f34>] (generic_handle_irq+0x28/0x38)
[  120.982046]  r4:0000002a r3:c0073fe4
[  120.982085] [<c0070f0c>] (generic_handle_irq+0x0/0x38) from [<c0015560>] (handle_IRQ+0x38/0x8c)
[  120.982098]  r4:c080137c r3:00000182
[  120.982124] [<c0015528>] (handle_IRQ+0x0/0x8c) from [<c00087e0>] (gic_handle_irq+0x30/0x5c)
[  120.982145]  r6:ec137dd0 r5:c07ac480 r4:fa24010c r3:00000100
[  120.982169] [<c00087b0>] (gic_handle_irq+0x0/0x5c) from [<c056fcc0>] (__irq_svc+0x40/0x54)
[  120.982179] Exception stack(0xec137dd0 to 0xec137e18)
[  120.982195] 7dc0:                                     00000000 a00001d3 00000000 00000004
[  120.982216] 7de0: a0000153 ec1d9010 c080de90 ec137e30 c080debc 00000000 ed756e44 ec137e2c
[  120.982232] 7e00: ec137de0 ec137e18 bf1150e4 bf115474 60000153 ffffffff
[  120.982253]  r7:ec137e04 r6:ffffffff r5:60000153 r4:bf115474
[  120.982327] [<bf115438>] (dwc3_complete+0x0/0x40 [dwc3]) from [<c0338f50>] (dpm_complete+0xd4/0x19c)
[  120.982341]  r5:ed756e10 r4:ed756e64
[  120.982370] [<c0338e7c>] (dpm_complete+0x0/0x19c) from [<c0339034>] (dpm_resume_end+0x1c/0x20)
[  120.982400] [<c0339018>] (dpm_resume_end+0x0/0x20) from [<c006d4ec>] (suspend_devices_and_enter+0x118/0x33c)
[  120.982412]  r4:c0833da4 r3:00000000
[  120.982436] [<c006d3d4>] (suspend_devices_and_enter+0x0/0x33c) from [<c006d928>] (pm_suspend+0x218/0x254)
[  120.982458] [<c006d710>] (pm_suspend+0x0/0x254) from [<c006c594>] (state_store+0x70/0xc0)
[  120.982478]  r6:c057a6cc r5:c06a8320 r4:00000003 r3:0000006d
[  120.982515] [<c006c524>] (state_store+0x0/0xc0) from [<c0264cc0>] (kobj_attr_store+0x1c/0x28)
[  120.982546] [<c0264ca4>] (kobj_attr_store+0x0/0x28) from [<c012ccb8>] (sysfs_write_file+0x170/0x1a4)
[  120.982583] [<c012cb48>] (sysfs_write_file+0x0/0x1a4) from [<c00d17e4>] (vfs_write+0xb8/0x190)
[  120.982611] [<c00d172c>] (vfs_write+0x0/0x190) from [<c00d1bf8>] (SyS_write+0x44/0x78)
[  120.982641] [<c00d1bb4>] (SyS_write+0x0/0x78) from [<c0014660>] (ret_fast_syscall+0x0/0x30)

Signed-off-by: Roger Quadros <rogerq@ti.com>
Acked-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

usb: gadget: zero: Fix SuperSpeed enumeration for alternate setting 1

[ Upstream commit 9c1b70361e0b38e4acb8e62b54da66538cb77ff2 ]

It was impossible to enumerate on a SuperSpeed (XHCI) host
with alternate setting = 1 due to the wrongly set 'bMaxBurst'
field in the SuperSpeed Endpoint Companion descriptor.

Testcase:
<host> modprobe -r usbtest; modprobe usbtest alt=1
<device> modprobe g_zero
plug device to SuperSpeed port on the host.

Without this patch the host always complains like so
"usb 12-2: Not enough bandwidth for new device state.
 usb 12-2: Not enough bandwidth for altsetting 1"

Bug was introduced by commit cf9a08ae in v3.9

Fixes: cf9a08ae5aec (usb: gadget: convert source sink and loopback to
new function interface)

Cc: 3.9+ <stable@vger.kernel.org> # 3.9+
Reviewed-by: Felipe Balbi <balbi@ti.com>
Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

usb: phy: return an error in usb_get_phy() if try_module_get() fails

[ Upstream commit 9dc9cb0c9ad0f999e29ce4c4f307cd2abbe752d3 ]

[ Upstream commit 9dc9cb0c9ad0f999e29ce4c4f307cd2abbe752d3 ]

In case we found a matching USB PHY in usb_get_phy() but the call to
try_module_get() fails, we shouldn't return a (probably soon dangling)
pointer but an ERR_PTR instead.

Signed-off-by: Mathias Krause <minipli@googlemail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

usb: musb: dsps: move debugfs_remove_recursive()

[ Upstream commit 0fca91b8a446d4a38b8f3d4772c4a8665ebcd7b2 ]

When the platform initialization fails due to missing resources, it will
return -EPROBE_DEFER after dsps_musb_init() has been called.

dsps_musb_init() calls dsps_musb_dbg_init() to allocate the debugfs
nodes. At a later point in time, the probe will be retried, and
dsps_musb_dbg_init() will be called again. debugfs_create_dir() will
fail this time, as the node already exists, and so the entire device
probe will fail with -ENOMEM.

Fix this by moving debugfs_remove_recursive() from dsps_remove() to the
plaform's exit function, so it will be cleanly torn down when the probe
fails. It also feels more natural this way, as .exit is the counterpart
to .init.

Signed-off-by: Daniel Mack <zonque@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

usb: dwc3: gadget: Iterate only over valid endpoints

[ Upstream commit 32702e96a9f76ea0e0a1d218310d2ac1adbd2907 ]

Make dwc3_gadget_resize_tx_fifos() iterate only over IN
endpoints that are actually present, based on the
num_in_eps parameter. This terminates the loop so as to
prevent dereferencing a potential NULL dwc->eps[i] where
i >= (num_in_eps + num_out_eps).

Signed-off-by: Jack Pham <jackp@codeaurora.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

usb: musb: omap2430: make sure clocks are enabled when running mailbox

[ Upstream commit 8b2bc2c9351b4c09bc3d9096e2a7af3988565dbf ]

on early initialization we could fall into
a situation where the mailbox is called before
MUSB's clocks are running, in order to avoid
that, make sure mailbox is always wrapped with
pm_runtime calls.

Reported-by: Stefan Roese <sr@denx.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

usb: musb: fix PHY power on/off

[ Upstream commit 3063a12be2b07c64e9802708a19489342e64c1a3 ]

commi 30a70b0 (usb: musb: fix obex in g_nokia.ko
causing kernel panic) removed phy_power_on()
and phy_power_off() calls from runtime PM callbacks
but it failed to note that the driver depended
on pm_runtime_get_sync() calls to power up the PHY,
thus leaving some platforms without any means to
have a working PHY.

Fix that by enabling the phy during omap2430_musb_init()
and killing it in omap2430_musb_exit().

Fixes: 30a70b0 (usb: musb: fix obex in g_nokia.ko causing kernel panic)
Cc: <stable@vger.kernel.org> # v3.14
Cc: Pali Rohár <pali.rohar@gmail.com>
Cc: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
Reported-by: Michael Scott <hashcode0f@gmail.com>
Tested-by: Michael Scott <hashcode0f@gmail.com>
Tested-by: Stefan Roese <sr@denx.de>
Reported-by: Rabin Vincent <rabin@rab.in>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

drm/omap: fix the handling of fb ref counts

[ Upstream commit f2d022aa421ca903a30f63b04528064b7eceaf5e ]

With the recent primary-plane changes for drm, the primary plane's
framebuffer needs to be ref counted the same way as for
non-primary-planes. This was not done by the omapdrm driver, which
caused the ref count to drop to 0 too early, causing problems.

This patch moves the fb unref and ref from omap_plane_update to
omap_plane_mode_set. This way the fb refs are updated for both primary
and non-primary cases, as omap_plane_update calls omap_plane_mode_set.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

drm/omap: fix plane rotation

[ Upstream commit d4586604acbd2e58921e0363533b9797b0235275 ]

Plane rotation with omapdrm is currently broken.
It seems omap_plane_mode_set() expects width and height in screen
coordinates, so pass it like that.

Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

drm/omap: protect omap_crtc's event with event_lock spinlock

[ Upstream commit 38e5597a03d2d1499a785230031c4f48e1d9c6b7 ]

The vblank_cb callback and the page_flip ioctl can occur together in different
CPU contexts. vblank_cb uses takes tje drm device's event_lock spinlock when
sending the vblank event and updating omap_crtc->event and omap_crtc->od_fb.

Use the same spinlock in page_flip, to make sure the above omap_crtc parameters
are configured sequentially.

Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

drm/omap: Use old_fb to synchronize between successive page flips

[ Upstream commit bc905aced30e48a39af7c452bf46228d7c6188b9 ]

omap_crtc->old_fb is used to check whether the previous page flip has completed
or not. However, it's never initialized to anything, so it's always NULL. This
results in the check to always succeed, and the page_flip to proceed.

Initialize old_fb to the fb that we intend to flip to through page_flip, and
therefore prevent a future page flip to proceed if the last one didn't
complete.

Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

drm: Replace crtc fb with primary plane fb (v3)

[ Upstream commit f4510a2752b75ad5847b7935b68c233cab497f97 ]

Now that CRTC's have a primary plane, there's no need to track the
framebuffer in the CRTC.  Replace all references to the CRTC fb with the
primary plane's fb.

This patch was generated by the Coccinelle semantic patching tool using
the following rules:

        @@ struct drm_crtc C; @@
        -   (C).fb
        +   C.primary->fb

        @@ struct drm_crtc *C; @@
        -   (C)->fb
        +   C->primary->fb

v3: Generate patch via coccinelle.  Actual removal of crtc->fb has been
    moved to a subsequent patch.

v2: Fixup several lingering crtc->fb instances that were missed in the
    first patch iteration.  [Rob Clark]

Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

drm/omap: remove extra plane->destroy from crtc destroy

[ Upstream commit 772cdc9777403f10c4229c49645024a502dfd783 ]

All the planes, including primary planes, are now destroyed by the drm
framework. Thus we no longer need the explicit call to plane->destroy
from the crtc's destroy function.

This patch removes the call, thus fixing the crash caused by double
freeing the plane.

remove omap_crtc->plane->funcs->destroy(omap_crtc->plane)

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

drm/omap: Fix crash when using LCD3 overlay manager

[ Upstream commit 71b6667765c7019f3fd5ea5e0c02f65f7331f3e1 ]

The channel_names list didn't have a string populated for LCD3 manager, this
results in a crash when the display's output is connected to LCD3. Add an entry
for LCD3.

Reported-by: Somnath Mukherjee <somnath@ti.com>
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

drm/omap: gem sync: wait on correct events

[ Upstream commit f2cff0f34ff2c51f703880a2b883ea0c9de4a5ac ]

A waiter of the type OMAP_GEM_READ should wait for a buffer to be completely
written, and only then proceed with reading it. A similar logic applies for
waiters with OMAP_GEM_WRITE flag.

Currently the function is_waiting() waits on the read_complete/read_target
counts in the sync object.

This should be the other way round, as a reader should wait for users who are
'writing' to this buffer, and vice versa.

Make readers of the buffer(OMAP_GEM_READ) wait on the write counters, and
writers to the buffer(OMAP_GEM_WRITE) wait on the read counters in is_waiting()

Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

drm/omap: remove warn from debugfs

[ Upstream commit b841aedfcfd543d836c856bfde5a17c51cab6b26 ]

Patch dfe96ddcfa22b44100814b9435770f6ff1309d37 (omapdrm: simplify locking in
the fb debugfs file) removed taking locks when using omapdrm's debugfs
to dump fb objects.

However, in omap_gem_describe we give a WARN is the lock has not been
taken, so that WARN is now seen every time omapdrm debugfs is used.

So, presuming the removal of locks is ok, we can also remove the WARN.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

drm/omap: print warning when rotating non-TILER fb

[ Upstream commit 5ac96345899be859529e05af42f708ae7bd65782 ]

Print a warning when the user tries to rotate a non-TILER framebuffer.

Also set the rotation to 0, to avoid constant flood of the warnings in
case of page flipping.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

OMAPDSS: Change struct reg_field to dispc_reg_field

[ Upstream commit 5c348ba96cdfd2db6a254de259b54cc20fa7d78a ]

Avoid colision with regmap's struct reg_field definition by renaming
omapdss's struct reg_field to dispc_reg_field, and moving it inside
dispc.c as that's the only place it is used.

Signed-off-by: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

OMAPDSS: Take pixelclock unit change into account in hdmi_compute_acr()

[ Upstream commit a57a22c817fbcb69d41ae517e02933618482f42d ]

Pixelclock unit change from kHz to Hz should be taken into account
in CTS value calculations in hdmi_compute_acr().

Signed-off-by: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

OMAPDSS: fix shared irq handlers

[ Upstream commit 0925afc9a4851c2592f1d45a17aeb7e1ffe188b7 ]

DSS uses shared irq handlers for DISPC and DSI, because on OMAP3, the
DISPC and DSI share the same irq line.

However, the irq handlers presume that the hardware is enabled, which,
in theory, may not be the case with shared irq handlers. So if an
interrupt happens while the DISPC/DSI is off, the kernel will halt as
the irq handler tries to access the DISPC/DSI registers.

In practice that should never happen, as both DSI and DISPC are in the
same power domain. So if there's an IRQ for one of them, the other is
also enabled. However, if CONFIG_DEBUG_SHIRQ is enabled, the kernel will
generate a spurious IRQ, which then causes the problem.

This patch adds an is_enabled field for both DISPC and DSI, which is
used to track if the HW is enabled. For DISPC the code is slightly more
complex, as the users of DISPC can register the interrupt handler, and
we want to hide the is_enabled handling from the users of DISPC.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

OMAPDSS: fix rounding when calculating fclk rate

[ Upstream commit d0e224f9963b79610850b2a10622182176658022 ]

"clk: divider: fix rate calculation for fractional rates" patch (and
similar for TI specific divider) fixes the clk-divider's rounding. This
patch updates the DSS driver to round the rates accordingly.

This fixes the DSS's warnings about clock rate mismatch, and also fixes
the wrong fclk rate being set.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Tested-by: Christoph Fritz <chf.fritz@googlemail.com>
Tested-by: Marek Belisko <marek@goldelico.com>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

drm/omap: fix missing unref to fb's buf object

[ Upstream commit 5e19c06d0e570a347669acc2b850c2f730090b60 ]

omap_fbdev_create() takes a reference to the fb's gem object with
omap_gem_get_paddr(). However, it never releases it with
omap_gem_put_paddr().

This patch adds the missing omap_gem_put_paddr() to omap_fbdev_free().

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

drm/omap: fix enabling/disabling of video pipeline

[ Upstream commit 506096a113832239ce763d20fab8e94f76d56266 ]

At the moment the omap_crtc_pre_apply() handles the enabling, disabling
and configuring of encoders and panels separately from the CRTC (i.e.
the overlay manager).

However, this doesn't work correctly. The encoder driver has to be in
control of its video input (i.e. the crtc) for correct operation.

This problem causes bugs with (at least) HDMI: the HDMI encoder supplies
pixel clock for DISPC, and DISPC supplies video stream for HDMI. The
current code first enables the HDMI encoder, and CRTC after that.
However, the encoder expects the video stream to start during the
encoder's enable, and if it doesn't, there will be sync lost errors.

The encoder enables its video source by calling src->enable(), and this
call goes to omapdrm (omap_crtc_enable), but omapdrm doesn't do anything
in that function. Similarly for disable, which goes to
omap_crtc_disable().

This patch moves the code to setup and enable/disable the crtc to
omap_crtc_enable. and omap_crtc_disable().

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

drm/omap: fix missing disable for unused encoder

[ Upstream commit c7aef12f344459961eb1e0ba10d184816ed42d99 ]

When an encoder is no longer connected to a crtc, the driver will leave
the encoder enabled.

This patch adds code to track the encoder used for a crtc, and when the
encoder changes, the old one is disabled.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

drm/omap: fix race issue when unloading omapdrm

[ Upstream commit e2f8fd74ec1bf15cb2abc1b11f7d9fa09581024e ]

At module unload, omap_fbdev_free() gets called which releases the
framebuffers. However, the framebuffers are still used by crtcs, and
will be released only later at vsync. The driver doesn't wait for this,
and goes on to release the rest of the resources, which often
causes a crash.

This patchs adds a omap_crtc_flush() function which waits until the crtc
has finished with its apply queue and page flips.

The function utilizes a simple polling while-loop, as the performance is
not an issue here.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

drm/omap: fix uninit order in pdev_remove()

[ Upstream commit 707cf58a0a847f60f849b44bfb9b85dcc17c599d ]

When unloading omapdrm driver, the omapdrm platform device is
uninitialized last, after the displays have been disconnected omap_crtc
callbacks have been removed. As the omapdrm pdev uninitialization needs
the features uninitialized in earlier steps, a crash is guaranteed.

This patch fixes the uninitialize order so that the omapdrm pdev is
removed first.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

drm/omap: fix output enable/disable sequence

[ Upstream commit 2ec8e3787ae6957f738bb133e755213b9d7c066e ]

At the moment it's quite easy to get the following errors when the HDMI
output is enabled or disabled:

[drm:omap_crtc_error_irq] *ERROR* tv: errors: 00008000

The reason for the errors is that the omapdrm driver doesn't properly
handle the sync-lost irqs that happen when enabling the DIGIT crtc,
which is used for HDMI and analog TV. The driver does disable the
sync-lost irq properly, but it fails to wait until the output has been
fully enabled (i.e. the first vsync), so the sync-lost errors are still
seen occasionally.

This patch makes the omapdrm act the same way as the omapfb does:

- When enabling a display, we'll wait for the first vsync.
- When disabling a display, we'll wait for framedone if available, or
  odd and even vsyncs.

These changes make sure the output is fully enabled or disabled at the
end of the function.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reported-by: Sanjay Singh Rawat <sanjay.rawat@linaro.org>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

dma: edma: fix incorrect SG list handling

[ Upstream commit 5fc68a6cad658e45dca3e0a6607df3a8e5df4ef9 ]

The code to handle any length SG lists calls edma_resume()
even before edma_start() is called. This is incorrect
because edma_resume() enables edma events on the channel
after which CPU (in edma_start) cannot clear posted
events by writing to ECR (per the EDMA user's guide).

Because of this EDMA transfers fail to start if due
to some reason there is a pending EDMA event registered
even before EDMA transfers are started. This can happen if
an EDMA event is a byproduct of device initialization.

Fix this by calling edma_resume() only if it is not the
first batch of MAX_NR_SG elements.

Without this patch, MMC/SD fails to function on DA850 EVM
with DMA. The behaviour is triggered by specific IP and
this can explain why the issue was not reported before
(example with MMC/SD on AM335x).

Tested on DA850 EVM and AM335x EVM-SK using MMC/SD card.

Cc: stable@vger.kernel.org # v3.12.x+
Cc: Joel Fernandes <joelf@ti.com>
Acked-by: Joel Fernandes <joelf@ti.com>
Tested-by: Jon Ringle <jringle@gridpoint.com>
Tested-by: Alexander Holler <holler@ahsoftware.de>
Reported-by: Jon Ringle <jringle@gridpoint.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

drivers: net: cpsw: enable interrupts after napi enable and clearing previous interrupts

[ Upstream commit f63a975e8f07a75dbf0386402788330d0bebd8d8 ]

When the Ethernet interface is put down and up with heavy Ethernet
traffic, then there is prossibility of an interrupt waiting in irq
controller to be processed, so when the interface is brought up again
just after enable interrupt, it goes to ISR due to the previous
unhandled interrutp and in ISR napi is not scheduled as the napi
is not enabled in ndo_open which results in disabled interrupt for
CPSW and no packets are received in cpsw. So this patch moves enabling
of interupts after napi_enable and clearing CPDMA interrupts.

Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

drivers: net: cpsw: discard all packets received when interface is down

[ Upstream commit 16e5c57da61cda26998bee91a327960ebd1562f6 ]

When the Ethernet interface is brought down during high Ethernet traffic,
then cpsw creates the following warn dump. When cpdma has already processed
the packet then the status will be greater than 0, so the cpsw_rx_handler
considers that the interface is up and try to resubmit one more rx buffer
to cpdma which fails as the DMA is in teardown process. This can be avoided
by checking the interface state and then process the received packet, if the
interface is down just discard and free the skb and return.

[ 2823.104591] WARNING: CPU: 0 PID: 1823 at drivers/net/ethernet/ti/cpsw.c:711 cpsw_rx_handler+0x148/0x164()
[ 2823.114654] Modules linked in:
[ 2823.117872] CPU: 0 PID: 1823 Comm: ifconfig Tainted: G        W     3.14.0-11992-gf34c4a3 #11
[ 2823.126860] [<c0014b5c>] (unwind_backtrace) from [<c00117e4>] (show_stack+0x10/0x14)
[ 2823.135030] [<c00117e4>] (show_stack) from [<c0533a9c>] (dump_stack+0x80/0x9c)
[ 2823.142619] [<c0533a9c>] (dump_stack) from [<c003f0e0>] (warn_slowpath_common+0x6c/0x90)
[ 2823.151141] [<c003f0e0>] (warn_slowpath_common) from [<c003f120>] (warn_slowpath_null+0x1c/0x24)
[ 2823.160336] [<c003f120>] (warn_slowpath_null) from [<c03caeb0>] (cpsw_rx_handler+0x148/0x164)
[ 2823.169314] [<c03caeb0>] (cpsw_rx_handler) from [<c03c730c>] (__cpdma_chan_free+0x90/0xa8)
[ 2823.178028] [<c03c730c>] (__cpdma_chan_free) from [<c03c7418>] (__cpdma_chan_process+0xf4/0x134)
[ 2823.187279] [<c03c7418>] (__cpdma_chan_process) from [<c03c7560>] (cpdma_chan_stop+0xb4/0x17c)
[ 2823.196349] [<c03c7560>] (cpdma_chan_stop) from [<c03c766c>] (cpdma_ctlr_stop+0x44/0x9c)
[ 2823.204872] [<c03c766c>] (cpdma_ctlr_stop) from [<c03cb708>] (cpsw_ndo_stop+0x154/0x188)
[ 2823.213321] [<c03cb708>] (cpsw_ndo_stop) from [<c046f0ec>] (__dev_close_many+0x84/0xc8)
[ 2823.221761] [<c046f0ec>] (__dev_close_many) from [<c046f158>] (__dev_close+0x28/0x3c)
[ 2823.230012] [<c046f158>] (__dev_close) from [<c0474ca8>] (__dev_change_flags+0x88/0x160)
[ 2823.238483] [<c0474ca8>] (__dev_change_flags) from [<c0474da0>] (dev_change_flags+0x18/0x48)
[ 2823.247316] [<c0474da0>] (dev_change_flags) from [<c04d12c4>] (devinet_ioctl+0x61c/0x6e0)
[ 2823.255884] [<c04d12c4>] (devinet_ioctl) from [<c045c660>] (sock_ioctl+0x68/0x2a4)
[ 2823.263789] [<c045c660>] (sock_ioctl) from [<c0125fe4>] (do_vfs_ioctl+0x78/0x61c)
[ 2823.271629] [<c0125fe4>] (do_vfs_ioctl) from [<c01265ec>] (SyS_ioctl+0x64/0x74)
[ 2823.279284] [<c01265ec>] (SyS_ioctl) from [<c000e580>] (ret_fast_syscall+0x0/0x48)

Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

ARM: OMAP2+: hwmod: fix missing braces in _init()

[ Upstream commit 3d36ad7e7a9be0d130c862727a052ed279046437 ]

Bug was introduced by commit 'f92d959: ARM: OMAP2+: hwmod:
Extract no-idle and no-reset info from DT'

There were 2 versions of the patch posted which resulted in the above
commit. While v1 [1] had the bug, v2 [2] had it fixed.
However v1 apparently seemed to have been pulled in by mistake
introducing the bug.

Given of_find_property() does return NULL when the node passed is
NULL, it did not introduce any functional issues as such, just the
fact that the second if check was executed unnecessarily.

[1] https://www.mail-archive.com/linux-omap@vger.kernel.org/msg94220.html
[2] http://www.spinics.net/lists/linux-omap/msg98490.html

Cc: Nishanth Menon <nm@ti.com>
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Fixes: f92d9597f781f6a5a39c73dc71604bd8a21c5299 ("ARM: OMAP2+: hwmod: Extract no-idle and no-reset info from DT")
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

ARM: AM43xx: fix dpll init in bypass mode

[ Upstream commit 8e4cb9aac2ada7f8a986606703c34e2d573bb876 ]

On AM43xx, if a PLL is in bypass at kernel init, the code in
omap2_get_dpll_rate() will not realize this and will try to calculate
the clock rate using the multiplier and the divider, resulting in
errors.

omap2_init_dpll_parent() has similar issue.

Add the missing soc_is_am43xx() check to make the code work on AM43xx.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Sathya Prakash M R <sathyap@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

drivers: net: cpsw: Add default vlan for dual emac case also

[ Upstream commit 629c9a8fd0bbdfc6d702526b327470166ec39c6b ]

Dual EMAC works with VLAN segregation of the ports, so default vlan needs
to be added in dual EMAC case else default vlan will be tagged for all
egress packets and vlan unaware switches/servers will drop packets
from the EVM.

Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Tested-by: Yegor Yefremov <yegorslists@googlemail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

ASoC: davinci-mcasp: Fix bit clock polarity settings

[ Upstream commit 74ddd8c40d8ac747ec780be3da40b37641a9b396 ]

IB_NF, NB_IF and IB_IF configured the bc polarity incorrectly. The receive
polarity was set to the same edge as the TX in these cases.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

v4l: ti-vpe: retain v4l2_buffer flags for captured buffers

[ Upstream commit bbe24c6759b341ab2504318e50ccd5482f5e6002 ]

The dequed CAPTURE_MPLANE type buffers don't contain the flags that the
originally queued OUTPUT_MPLANE type buffers have. This breaks compliance.

Copy the source v4l2_buffer flags to the destination v4l2_buffer flags before
they are dequed.

Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

v4l: ti-vpe: Set correct field parameter for output and capture buffers

[ Upstream commit 5269fef77e14c22b1fde44bc0973a18cf233f778 ]

The vpe driver wasn't setting the correct field parameter for dequed CAPTURE
type buffers for the case where the captured output is progressive.

Set the field to V4L2_FIELD_NONE for the completed destination buffers when
the captured output is progressive.

For OUTPUT type buffers, a queued buffer's field is forced to V4L2_FIELD_NONE
if the pixel format(configured through s_fmt for the buffer type
V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE specifies) the field type isn't interlaced.
If the pixel format specified was V4L2_FIELD_ALTERNATE, and the queued buffer's
field isn't V4L2_FIELD_TOP or V4L2_FIELD_BOTTOM, the vb2 buf_prepare op returns
an error.

This ensures compliance, and that the dequeued output and captured buffers
contain the field type that the driver used internally.

Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

v4l: ti-vpe: zero out reserved fields in try_fmt

[ Upstream commit 92851f1cdbd082eb993847e1c4468f7de08765bb ]

Zero out the reserved formats in v4l2_pix_format_mplane and
v4l2_plane_pix_format members of the returned v4l2_format pointer when passed
through TRY_FMT ioctl.

This ensures that the user doesn't interpret the non-zero fields as some data
passed by the driver, and ensures compliance.

Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

v4l: ti-vpe: Fix initial configuration queue data

[ Upstream commit 67fb87eec08a7705b0b8177095b1ef099a05b8c9 ]

The vpe output and capture queues are initially configured to default values in
vpe_open(). A G_FMT before any S_FMTs will result in these values being
populated.

The colorspace and bytesperline parameter of this initial configuration are
incorrect. This breaks compliance when as we get 'TRY_FMT(G_FMT) != G_FMT'.

Fix the initial queue configuration such that it wouldn't need to be fixed by
try_fmt.

Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

v4l: ti-vpe: Use correct bus_info name for the device in querycap

[ Upstream commit b20902b92e6a49ab21a79d4b2e56a6dd0085c696 ]

The bus_info parameter in v4l2_capabilities expects a 'platform_' prefix. This
wasn't done in the driver and hence was breaking compliance. Update the bus_info
parameter accordingly.

Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

v4l: ti-vpe: report correct capabilities in querycap

[ Upstream commit fca27a9836963a279833f01ed55c458d46ac1c3d ]

querycap currently returns V4L2_CAP_VIDEO_M2M as a capability, this should be
V4L2_CAP_VIDEO_M2M_MPLANE instead, as the driver supports multiplanar formats.

Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Signed-off-by: Dan Murphy <DMurphy@ti.com>

v4l: ti-vpe: Allow usage of smaller images

[ Upstream commit ce392fd7253d53736c162681c519088a058f592b ]

The minimum width and height for VPE input/output was kept as 128 pixels. VPE
doesn't have a constraint on the image height, it requires the image width to
be at least 16 bytes.

Change the minimum supported dimensions to 32x32. This allows us to de-interlace
qcif content. A smaller image size than 32x32 didn't make much sense, so stopped
at this.

Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Signed-off-by: Dan Murphy <DMurphy@ti.com>