Replace the numerical polarity flags with the PWM_POLARITY_INVERTED
symbolic constant.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NThierry Reding <thierry.reding@gmail.com>

Let's follow the ratified DT binding and use uartdm instead of
hsuart. This does break backwards compatibility but this
shouldn't be a problem because the uart driver isn't probing on
these devices without adding clock support (which isn't merged so
far).

Cc: David Brown <davidb@codeaurora.org>
Acked-by: NKumar Gala <galak@codeaurora.org>
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

So I assumed that Beagle bone has only one USB port in host mode because
the micro USB connector had an USB-UART there. I was wrong a little. The
second port runs on host mode, but the micro USB plug is connected to an
internal HUB with two ports: one to the USB-UART and one to musb
instance one.
For that reason, this patch enables both ports: the primary in device
mode only and the second in host mode only.
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

This is what I observe:
On the first connect, the musb starts with DEVCTL.Session set. On
disconnect, musb_core calls try_idle. That functions removes the Session
bit signalizing that the session is over (something that only in OTG is
required). A new device, that is plugged, is no longer recognized.
I've setup a timer and checked the DEVCTL register and I haven't seen a
change in VBus and I saw the B-Device bit set. After setting the IDDIG
into A mode and forcing the device to behave like a A device, I didn't
see a change.
Neither VBUS goes to 0b11 nor does a session start request comes.
In the TI-v3.2 kernel they skip to call musb_platform_try_idle() in the
OTG_STATE_A_WAIT_BCON state while not in OTG mode.
Since the second port hast a standard A plug the patch changes the port
to run in host mode only and skips the timer which would remove
DEVCTL.Session so we can reconnect to another device later.
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

This relfects the code and dts requires changes due to recent .dts
binding updates:
- use mg prefix for the Metor Graphics specific attributes
- use power in mA not in mA/2 as specifed in the USB2.0 specification
- remove the child node for USB. This is driver specific on won't be
  reflected in the device tree
- use the "mentor" prefix instead of "mg".
- use "dr_mode" istead of "mg,port-mode" for the port mode. The former
  is used by a few other drivers.

Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: devicetree@vger.kernel.org
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

I forgot to separete the different names in the reg-names property. This
didn't cause anything to fail because the driver does not use the names
and simply relies on the order of the memory offsets in reg.
This patch fixes this in case it is used later.
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

This fixes a regression exposed during the merge window by commit
9f310ded "ARM: tegra: fix VBUS regulator GPIO polarity in DT"; namely that
USB VBUS doesn't get turned on, so USB devices are not detected. This
affects the internal USB port on TrimSlice (i.e. the USB->SATA bridge, to
which the SSD is connected) and the external port(s) on Seaboard/
Springbank and Whistler.

The Tegra DT as written in v3.11 allows two paths to enable USB VBUS:

1) Via the legacy DT binding for the USB controller; it can directly
   acquire a VBUS GPIO and activate it.

2) Via a regulator for VBUS, which is referenced by the new DT binding
   for the USB controller.

Those two methods both use the same GPIO, and hence whichever of the
USB controller and regulator gets probed first ends up owning the GPIO.
In practice, the USB driver only supports path (1) above, since the
patches to support the new USB binding are not present until v3.12:-(

In practice, the regulator ends up being probed first and owning the
GPIO. Since nothing enables the regulator (the USB driver code is not
yet present), the regulator ends up being turned off. This originally
caused no problem, because the polarity in the regulator definition was
incorrect, so attempting to turn off the regulator actually turned it
on, and everything worked:-(

However, when testing the new USB driver code in v3.12, I noticed the
incorrect polarity and fixed it in commit 9f310ded "ARM: tegra: fix VBUS
regulator GPIO polarity in DT". In the context of v3.11, this patch then
caused the USB VBUS to actually turn off, which broke USB ports with VBUS
control. I got this patch included in v3.11-rc1 since it fixed a bug in
device tree (incorrect polarity specification), and hence was suitable to
be included early in the rc series. I evidently did not test the patch at
all, or correctly, in the context of v3.11, and hence did not notice the
issue that I have explained above:-(

Fix this by making the USB VBUS regulators always enabled. This way, if
the regulator owns the GPIO, it will always be turned on, even if there
is no USB driver code to request the regulator be turned on. Even
ignoring this bug, this is a reasonable way to configure the HW anyway.

If this patch is applied to v3.11, it will cause a couple pretty trivial
conflicts in tegra20-{trimslice,seaboard}.dts when creating v3.12, since
the context right above the added lines changed in patches destined for
v3.12.
Reported-by: NKyle McMartin <kmcmarti@redhat.com>
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>

Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>
Cc: stable <stable@vger.kernel.org> # 3.5+

Exynos PCIe IP consists of Synopsys specific part and Exynos
specific part. Only core block is a Synopsys Designware part;
other parts are Exynos specific.

Also, the Synopsys Designware part can be shared with other
platforms; thus, it can be split two parts such as Synopsys
Designware part and Exynos specific part.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Cc: Pratyush Anand <pratyush.anand@st.com>
Cc: Mohit KUMAR <Mohit.KUMAR@st.com>

This driver is currently used by musb' cppi41 couter part. I may merge
both dma engine user of musb at some point but not just yet.

The driver seems to work in RX/TX mode in host mode, tested on mass
storage. I increaed the size of the TX / RX transfers and waited for the
core code to cancel a transfers and it seems to recover.

v2..3:
- use mall transfers on RX side and check data toggle.
- use rndis mode on tx side so we haveon interrupt for 4096 transfers.
- remove custom "transferred" hack and use dmaengine_tx_status() to
  compute the total amount of data that has been transferred.
- cancel transfers and reclaim descriptors

v1..v2:
- RX path added
- dma mode 0 & 1 is working
- device tree nodes re-created.

Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Dan Williams <djbw@fb.com>
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

This moves the two instances from the big node into two child nodes. The
glue layer ontop does almost nothing.

There is one devices containing the control module for USB (2) phy,
(2) usb and later the dma engine. The usb device is the "glue device"
which contains the musb device as a child. This is what we do ever since.

The new file musb_am335x is just here to prob the new bus and populate
child devices.

There are a lot of changes to the dsps file as a result of the changes:

- musb_core_offset
  This is gone. The device tree provides memory ressources information
  for the device there is no need to "fix" things

- instances
  This is gone as well. If we have two instances then we have have two
  child enabled nodes in the device tree. For instance the SoC in beagle
  bone has two USB instances but only one has been wired up so there is
  no need to load and init the second instance since it won't be used.

- dsps_glue is now per glue device
  In the past there was one of this structs but with an array of two and
  each instance accessed its variable depending on the platform device
  id.

- no unneeded copy of structs
  I do not know why struct dsps_musb_wrapper is copied but it is not
  necessary. The same goes for musb_hdrc_platform_data which allocated
  on demand and then again by platform_device_add_data(). One copy is
  enough.
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Add the RTS/CTS property for auart0 which means we enable the
DMA support for it.
Signed-off-by: NHuang Shijie <b32955@freescale.com>
Acked-by: NShawn Guo <shawn.guo@linaro.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This was missed when splitting out the phy from the controller node in
commit 9dffe3be (ARM: tegra: modify ULPI reset GPIO properties).
Signed-off-by: NLucas Stach <dev@lynxeye.de>
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>

This patch fixes cpu nodes with device_type = "cpu". This change was not
necessary before 3.10-rc7.
Without this patch STi SOCs does not boot as SMP.
Signed-off-by: NSrinivas Kandagatla <srinivas.kandagatla@st.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>

commit e00c27ef
(ARM: dts: OMAP5: Add Palmas MFD node and regulator nodes)
introduced regulator entries for OMAP5uEVM.

However, The regulator information is based on an older temporary
pre-production board variant and does not reflect production board
750-2628-XXX boards.

The following optional/unused regulators can be updated:

- SMPS9 supplies TWL6040 over VDDA_2v1_AUD. This regulator needs to be
enabled only when audio is active. Since it does not come active by
default, it does not require "always-on" or "boot-on".

- LDO2 and LDO8 do not go to any peripheral or connector on the board.
Further, these unused regulators should have been 2.8V for LDO2 and
3.0V for LDO8. Mark these LDOs as disabled in the dts until needed.
Reported-by: NMarc Jüttner <m-juettner@ti.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Acked-by: NJ Keerthy <j-keerthy@ti.com>
Acked-by: NBenoit Cousson <benoit.cousson@gmail.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

commit e00c27ef
(ARM: dts: OMAP5: Add Palmas MFD node and regulator nodes)
introduced regulator entries for OMAP5uEVM.

However, The regulator information is based on an older temporary
pre-production board variant and does not reflect production board
750-2628-XXX boards.

The following fixes are hence mandatory to ensure right voltage is
supplied to key OMAP5 SoC voltage rails:

- LDO1 supplies VDDAPHY_CAM which is OMAP5's vdda_csiporta/b/c. This
can only be supplied at 1.5V or 1.8V and we currently supply 2.8V.

To prevent any potential device damage risk, use the specified
1.5V-1.8V supply.

Remove 'always-on' and 'boot-on' settings here as it is
a 'on need' supply to SoC IP and is not enabled by PMIC by
default at boot.

- LDO3 supplies Low Latency Interface(LLI) hardware module which is a
special hardware to communicate with Modem. However since uEVM is
not setup by default for this communication, this should be disabled
by default.

Further, vdda_lli is supposed to be 1.5V and not 3V.

- LDO4 supplies VDDAPHY_DISP which is vdda_dsiporta/c/vdda_hdmi

This can only be supplied at 1.5V or 1.8V and we currently
supply 2.2V.

To prevent any potential device damage risk, use the specified
1.5V-1.8V supply.

Remove 'always-on' and 'boot-on' settings here as it is a 'on need'
supply to SoC IP and is not enabled by PMIC by default at boot.

- LDO6 supplies the board specified VDDS_1V2_WKUP supply going to
ldo_emu_wkup/vdds_hsic. To stay within the SoC specification supply
1.2V instead of 1.5V.

- LDO7 supplies VDD_VPP which is vpp1. This is currently configured for
1.5V which as per data manual "A pulse width of 1000 ns and an amplitude
of 2V is required to program each eFuse bit. Otherwise, VPP1 must not
be supplied".

So, fix the voltage to 2V. and disable the supply since we have no plans
of programming efuse bits - it can only be done once - in factory.

Further it is not enabled by default by PMIC so, 'boot-on' must be
removed, and the 'always-on' needs to be removed to achieve pulsing
if efuse needs to be programmed.

- LDO9 supplies the board specified vdds_sdcard supply going within SoC
specification of 1.8V or 3.0V. Further the supply is controlled by
switch enabled by REGEN3. So, introduce REGEN3 and map sdcard slot to
be powered by LDO9. Remove 'always-on' allowing the LDO to be disabled
on need basis.
Reported-by: NMarc Jüttner <m-juettner@ti.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Acked-by: NJ Keerthy <j-keerthy@ti.com>
Acked-by: NBenoit Cousson <benoit.cousson@gmail.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

commit e00c27ef
(ARM: dts: OMAP5: Add Palmas MFD node and regulator nodes)
introduced regulator entries for OMAP5uEVM.

However, currently we use the Palmas regulator names which is used for
different purposes on uEVM. Document the same based on 750-2628-XXX
boards - which is meant to be supported by this dts.
Reported-by: NMarc Jüttner <m-juettner@ti.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Acked-by: NJ Keerthy <j-keerthy@ti.com>
Acked-by: NBenoit Cousson <benoit.cousson@gmail.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

USB VBUS regulators are now specified with the vbus-supply property
instead of nvidia,vbus-gpio, so remove the obsolete properties.

The equivalent vbus-supply properties were already added in patch
"ARM: tegra: update device trees for USB binding rework".
Signed-off-by: NMikko Perttunen <mperttunen@nvidia.com>
Acked-by: NStephen Warren <swarren@nvidia.com>
Reviewed-by: NStephen Warren <swarren@nvidia.com>
Tested-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

This patch changes the Tegra20 USB PHY nodes to use the UTMI configuration
parameter names as specified in the device tree binding documentation
after patch "ARM: tegra: finalize USB EHCI and PHY bindings".
Signed-off-by: NMikko Perttunen <mperttunen@nvidia.com>
Acked-by: NStephen Warren <swarren@nvidia.com>
Reviewed-by: NStephen Warren <swarren@nvidia.com>
Tested-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

all other drivers using Synopsys IPs with DT
have a compatible of snps,$driver, in order
to add consistency, we are switching over to
snps,dwc3 but keeping synopsys,dwc3 in the core
driver to maintain backwards compatibility.

New DTS bindings should NOT use synopsys,dwc3.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

This patch fixes a bug in pinctrl setup of serial2 device, Some of the
pins in the pinctrl node of serial2 do not belong to that
pin-controller. This patch divides them in the pins into there
respective pin controller nodes.

Without this patch serial on StiH416-B2000 Board will not work as it
fails with:

"st-pinctrl pin-controller-rear.3: failed to get pin(99) name
st-pinctrl pin-controller-rear.3: maps: function serial2 group serial2-0
num 4
pinconfig core: failed to register map default (3): no group/pin given"
Signed-off-by: NSrinivas Kandagatla <srinivas.kandagatla@st.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>

in drivers/pinctrl/sirf, pingroup name is cko0 and cko1, but in dts, they
are cko0 and cko1_rst. this patch fixes the error in dts.
Signed-off-by: NBarry Song <Baohua.Song@csr.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

this patch adds the lost pin group which supports to let USP0 to simulate
a UART without hardware flow control.
Signed-off-by: NQipan Li <Qipan.Li@csr.com>
Signed-off-by: NBarry Song <Baohua.Song@csr.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Fix the the gpio reg address for the device tree entry.
Signed-off-by: NRohit Vaswani <rvaswani@codeaurora.org>
Signed-off-by: NDavid Brown <davidb@codeaurora.org>

Device Tree "num-ports" property of USB host node has to be
set to maximum number of ports available.
The possibility to activate a particular port is done by specifying the proper
gpio configuration for its vbus.

This patch fixes the USB host node by configuring the 3 ports available on the
product and letting "port A" available for USB gadget usage.
Reported-by: NRodolfo Giometti <giometti@enneenne.com>
Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: NJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Cc: Bo Shen <voice.shen@atmel.com>

On imx51_babbage the codec clock is activated via GPIO4_26.

Provide a real clock to the sgtl5000 codec via device tree.
Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: NShawn Guo <shawn.guo@linaro.org>

For some reason vmmc2 regulator is missing for twl.
Let's add it.
Signed-off-by: NTony Lindgren <tony@atomide.com>

The i.MX53 PWM controller uses two cells to describe the PWM specifier.
Remove the extra unused values from the backlight DT node pwms property.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: NShawn Guo <shawn.guo@linaro.org>

The fec/enet driver calculates MDC rate with the formula below.

  ref_freq / ((MII_SPEED + 1) x 2)

The ref_freq here is the fec internal module clock, which is missing
from clk-vf610 clock driver right now.  And clk-vf610 driver mistakenly
supplies RMII clock (50 MHz) as the source to fec.  This results in the
situation that fec driver gets ref_freq as 50 MHz, while physically it
runs at 66 MHz (fec module clock physically sources from ipg which runs
at 66 MHz).  That's why software expects MDC runs at 2.5 MHz, while the
measurement tells it runs at 3.3 MHz.  And this causes the PHY KSZ8041
keeps swithing between Full and Half mode as below.

  libphy: 400d0000.etherne:00 - Link is Up - 100/Full
  libphy: 400d0000.etherne:00 - Link is Up - 100/Half
  libphy: 400d0000.etherne:00 - Link is Up - 100/Full
  libphy: 400d0000.etherne:00 - Link is Up - 100/Half
  libphy: 400d0000.etherne:00 - Link is Up - 100/Full
  libphy: 400d0000.etherne:00 - Link is Up - 100/Half

Add the missing module clock for ENET0 and ENET1, and correct the clock
supplying in device tree to fix above issue.

Thanks to Alison Wang <b18965@freescale.com> for debugging the issue.
Signed-off-by: NShawn Guo <shawn.guo@linaro.org>

These systems all use saif0 as the mclock provider to codec sgtl5000.
Reflect that in device tree source, so that sgtl5000 can find the clock
by calling clk_get().
Signed-off-by: NShawn Guo <shawn.guo@linaro.org>

The current default pad configuration for UART RX and TX pads sets a 360k
pull-down and writes 1 to a reserved bit (1 << 0). It doesn't seem right to
me that in idle state, the UART has to keep the signal high against a
pull-down resistor.

This patch instead sets a 100k pull-up, which incidentally corresponds to the
register reset value for all but one (MX53_PAD_KEY_ROW0__UART4_RXD_MUX) pad,
and removes the write to the reserved bit.
Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: NShawn Guo <shawn.guo@linaro.org>

On CSR SiRFprimaII/atlasVI, there is a programmable 16-bit divider
(RTC_DIV) that divides the input 32.768KHz clock to the frequency that
users need (E.g.  1 Hz).  The divided real-time clock will be used to
drive a 32-bit counter (RTC_COUNTER) that provides users with the actual
time.

In each cycle of the divided real-time clock, there is a Hertz interrupt
generated to the RISC.  Users can also configure an alarm (RTC_ALARM).
When RTC_COUNTER matches the alarm, there will be an alarm interrupt
generated to the RISC.

The system RTC can generate an alarm wake-up signal to notify the power
controller to wake up from power saving mode.
Signed-off-by: NXianglong Du <Xianglong.Du@csr.com>
Signed-off-by: NBarry Song <Baohua.Song@csr.com>
Cc: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Commit 4c94c8b5 "ARM: tegra: update device trees for USB binding rework"
added regulator definitions for GPIO-controlled USB VBUS. However, none
of these contained the essential DT property enable-active-high. Add
this so that the regulator definitions are correct.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

This patch renames the combatible strings for hdmi, mixer, ddc
and hdmiphy. It follows the convention of using compatible string
which represent the SoC in which the IP was added for the first
time.
Signed-off-by: NRahul Sharma <rahul.sharma@samsung.com>
Acked-by: NKukjin Kim <kgene.kim@samsung.com>
Reviewed-by: NTomasz Figa <t.figa@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

Instead of using a GPIO to turn on/off the CAN transceiver, it is better to
use a regulator as some systems may use a PMIC to power the CAN transceiver.
Acked-by: NShawn Guo <shawn.guo@linaro.org>
Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

This alters the local side address of the iospace to zero,
non prefetchable memory local side address to 0x00000000 and
prefetchable memory local side address to 0x10000000,
so as to match the values actually poked in by the driver.
Reported-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

function-mask DT property is now a mask for a pin at each pin offset
inside a given pincontrol register. Fix DA850 DT data to reflect
this change.
Signed-off-by: NManjunathappa, Prakash <prakash.pm@ti.com>
[nsekhar@ti.com: reword commit message for clarity]
Signed-off-by: NSekhar Nori <nsekhar@ti.com>

This patch adds pcie controller node for exynos5440-ssdk5440,
and also adds a phandle for pin controller node.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Acked-by: NKukjin Kim <kgene.kim@samsung.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Exynos5440 has two PCIe controllers which can be used as root complex
for PCIe interface.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Acked-by: NKukjin Kim <kgene.kim@samsung.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Signed-off-by: NJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>