Arnd Bergmann [Tue, 10 May 2016 14:15:20 +0000 (16:15 +0200)]
Merge tag 'imx-dt-clkdep-4.7' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into next/late
Merge "The i.MX device tree updates with new clocks for 4.7" from Shawn Guo:
- Add LCDIF and FlexCAN device support for i.MX7D
- New support i.MX7D based Nitrogen7 board from Boundary Devices
- Add display support for vf610-colibri board
* tag 'imx-dt-clkdep-4.7' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux:
ARM: dts: vf610-colibri: enable display controller
ARM: dts: vf610: add display nodes
ARM: dts: imx: add Boundary Devices Nitrogen7 board
ARM: dts: imx7d: add flexcan support
ARM: dts: imx7d: add lcdif support
clk: imx: vf610: fix whitespace in vf610-clock.h
clk: imx: vf610: add TCON ipg clock
clk: imx: vf610: fix DCU clock tree
clk: imx: add ckil clock for i.MX7
clk: imx: vf610: add suspend/resume support
clk: imx: vf610: add WKPU unit
clk: imx: vf610: leave DDR clock on
clk: imx: clk-gate2: allow custom gate configuration
clk: imx6sx: Register SAI clocks as shared clocks
Arnd Bergmann [Mon, 9 May 2016 14:26:08 +0000 (16:26 +0200)]
Merge tag 'tegra-for-4.7-xusb-no-defconfig' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into next/late
Merge "ARM: tegra: Enable the XUSB controller" from Thierry Reding:
These changes add support for the XUSB controller on Tegra124. It is an
XHCI compatible controller that replaces the existing EHCI controllers.
Support is enabled on Venice2, Jetson TK1 and Nyan-based Chromebooks.
* tag 'tegra-for-4.7-xusb-no-defconfig' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux:
ARM: tegra: Enable XUSB on Nyan
ARM: tegra: Enable XUSB on Jetson TK1
ARM: tegra: Enable XUSB on Venice2
ARM: tegra: Add Tegra124 XUSB controller
ARM: tegra: Move Tegra124 to the new XUSB pad controller binding
Arnd Bergmann [Mon, 9 May 2016 14:25:12 +0000 (16:25 +0200)]
Merge branches 'tegra/pci' and 'tegra/usb' into next/late
This is a prerequisite for enabling the Tegra XUSB, all the
branches should be merged already at the time we get here.
* tegra/pci:
PCI: tegra: Support per-lane PHYs
dt-bindings: pci: tegra: Update for per-lane PHYs
phy: tegra: Add Tegra210 support
phy: Add Tegra XUSB pad controller support
dt-bindings: phy: tegra-xusb-padctl: Add Tegra210 support
dt-bindings: phy: Add NVIDIA Tegra XUSB pad controller binding
phy: core: Allow children node to be overridden
clk: tegra: Add interface to enable hardware control of SATA/XUSB PLLs
* tegra/usb:
usb: xhci: tegra: Add Tegra210 support
usb: xhci: Add NVIDIA Tegra XUSB controller driver
dt-bindings: usb: xhci-tegra: Add Tegra210 XUSB controller support
dt-bindings: usb: Add NVIDIA Tegra XUSB controller binding
phy: tegra: Add Tegra210 support
phy: Add Tegra XUSB pad controller support
dt-bindings: phy: tegra-xusb-padctl: Add Tegra210 support
dt-bindings: phy: Add NVIDIA Tegra XUSB pad controller binding
phy: core: Allow children node to be overridden
clk: tegra: Add interface to enable hardware control of SATA/XUSB PLLs
Thierry Reding [Thu, 11 Feb 2016 17:12:22 +0000 (18:12 +0100)]
ARM: tegra: Add Tegra124 XUSB controller
Add a device tree node for the Tegra XUSB controller. It contains a
phandle to the XUSB pad controller for control of the PHYs assigned
to the USB ports.
Add support for the on-chip XUSB controller present on Tegra SoCs. This
controller, when loaded with external firmware, exposes an interface
compliant with xHCI. This driver loads the firmware, starts the
controller, and is able to service host-specific messages sent by the
controller's firmware.
The controller also supports USB device mode as well as powergating
of the SuperSpeed and host-controller logic when not in use, but
support for these is not yet implemented.
Based on work by:
Ajay Gupta <ajayg@nvidia.com>
Bharath Yadav <byadav@nvidia.com>
Andrew Bresticker <abrestic@chromium.org>
Add device-tree binding documentation for the XUSB controller present
on Tegra124 and later SoCs. This controller supports USB 3.0 via an xHCI
compliant interface.
Based on work by Andrew Bresticker <abrestic@chromium.org>.
Cc: Rob Herring <robh+dt@kernel.org> Cc: Pawel Moll <pawel.moll@arm.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk> Cc: Kumar Gala <galak@codeaurora.org> Cc: Mathias Nyman <mathias.nyman@intel.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Rob Herring <robh@kernel.org> Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
Thierry Reding [Wed, 11 Nov 2015 17:25:59 +0000 (18:25 +0100)]
PCI: tegra: Support per-lane PHYs
The current XUSB pad controller bindings are insufficient to describe
PHY devices attached to USB controllers. New bindings have been created
to overcome these restrictions. As a side-effect each root port now is
assigned a set of PHY devices, one for each lane associated with the
root port. This has the benefit of allowing fine-grained control of the
power management for each lane.
Thierry Reding [Fri, 4 Mar 2016 15:50:50 +0000 (16:50 +0100)]
dt-bindings: pci: tegra: Update for per-lane PHYs
The XUSB pad controller allows PCIe lanes to be controlled individually,
providing fine-grained control over their power state. Previous attempts
at describing the XUSB pad controller in DT had erroneously assumed that
all PCIe lanes were driven by the same PHY, and hence the PCI host
controller would reference only a single PHY.
Moving to a representation of per-lane PHYs requires that the operating
system driver for the PCI host controller have access to the set of PHY
devices that make up the connection of each root port in order to power
up and down all of the lanes as necessary.
Acked-by: Rob Herring <robh@kernel.org> Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
Thierry Reding [Wed, 11 Nov 2015 17:25:02 +0000 (18:25 +0100)]
phy: tegra: Add Tegra210 support
Add support for the XUSB pad controller found on Tegra210 SoCs. The
hardware is roughly the same, but some of the registers have been moved
around and the number and type of supported pads has changed.
Thierry Reding [Wed, 11 Nov 2015 17:24:21 +0000 (18:24 +0100)]
phy: Add Tegra XUSB pad controller support
Add a new driver for the XUSB pad controller found on NVIDIA Tegra SoCs.
This hardware block used to be exposed as a pin controller, but it turns
out that this isn't a good fit. The new driver and DT binding much more
accurately describe the hardware and are more flexible in supporting new
SoC generations.
Acked-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
Thierry Reding [Wed, 4 Nov 2015 15:53:36 +0000 (16:53 +0100)]
dt-bindings: phy: Add NVIDIA Tegra XUSB pad controller binding
The NVIDIA Tegra XUSB pad controller provides a set of pads, each with a
set of lanes that are used for PCIe, SATA and USB.
A binding exists for the XUSB pad controller already, but it turned out
not to be flexible enough to describe all aspects of the controller. In
particular, the addition of XUSB support (for SuperSpeed USB) has shown
that the existing binding is no longer suitable. Mark the old binding
as deprecated and link to the new binding.
Acked-by: Rob Herring <robh@kernel.org> Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
In order to more flexibly support device tree bindings, allow drivers to
override the container of the child nodes. By default the device node of
the PHY provider is assumed to be the parent for children, but bindings
may decide to add additional levels for better organization.
Acked-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
Merge tag 'renesas-dt-pm-domain-for-v4.7' of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas into next/late
Merge "Renesas ARM Based SoC DT PM Domain Updates for v4.7" into next/late
* Add SYSC PM Domains to DT for R-Car Gen 1 and 2 SoCs
This pull requests is based on a merge of:
* "[GIT PULL] Second Round of Renesas ARM Based SoC R-Car SYSC Updates for
v4.7", tagged as renesas-rcar-sysc2-for-v4.7, which you have already
pulled.
* "[GIT PULL v2] Renesas ARM Based SoC DT Updates for v4.7",
tagged as renesas-dt-for-v4.7, which you have also already pulled.
The reason for the somewhat tedious base on
renesas-rcar-sysc2-for-v4.7, which provides driver changes,
is a hard run-time dependency.
I also have a similar set of changes for arm64 which I will send separately.
* tag 'renesas-dt-pm-domain-for-v4.7' of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas: (88 commits)
ARM: dts: r8a7794: Use SYSC "always-on" PM Domain
ARM: dts: r8a7793: Use SYSC "always-on" PM Domain
ARM: dts: r8a7791: Use SYSC "always-on" PM Domain
ARM: dts: r8a7790: Use SYSC "always-on" PM Domain
ARM: dts: r8a7779: Use SYSC "always-on" PM Domain
ARM: dts: r8a7794: Add SYSC PM Domains
ARM: dts: r8a7793: Add SYSC PM Domains
ARM: dts: r8a7791: Add SYSC PM Domains
ARM: dts: r8a7790: Add SYSC PM Domains
ARM: dts: r8a7779: Add SYSC PM Domains
soc: renesas: rcar-sysc: Add support for R-Car H3 power areas
soc: renesas: rcar-sysc: Add support for R-Car E2 power areas
soc: renesas: rcar-sysc: Add support for R-Car M2-N power areas
soc: renesas: rcar-sysc: Add support for R-Car M2-W power areas
soc: renesas: rcar-sysc: Add support for R-Car H2 power areas
soc: renesas: rcar-sysc: Add support for R-Car H1 power areas
soc: renesas: rcar-sysc: Enable Clock Domain for I/O devices
ARM: dts: gose: Enable SDHI controllers
ARM: dts: r8a7793: Add SDHI controllers
ARM: dts: r8a7790: fix max-frequency for SDHI
...
clk: tegra: Add interface to enable hardware control of SATA/XUSB PLLs
On Tegra210, hardware control of the SATA and XUSB pad PLLs must be
done during the UPHY enable sequence rather than the PLLE enable
sequence. Export functions to do this so that hardware control can
be enabled from the XUSB padctl driver.
Signed-off-by: Andrew Bresticker <abrestic@chromium.org> Signed-off-by: Rhyland Klein <rklein@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
Hook up all devices that are part of the CPG/MSTP Clock Domain to the
SYSC "always-on" PM Domain, for a more consistent device-power-area
description in DT.
Hook up all devices that are part of the CPG/MSTP Clock Domain to the
SYSC "always-on" PM Domain, for a more consistent device-power-area
description in DT.
Hook up all devices that are part of the CPG/MSTP Clock Domain to the
SYSC "always-on" PM Domain, for a more consistent device-power-area
description in DT.
Hook up all devices that are part of the CPG/MSTP Clock Domain to the
SYSC "always-on" PM Domain, for a more consistent device-power-area
description in DT.
Hook up all devices that are part of the CPG/MSTP Clock Domain to the
SYSC "always-on" PM Domain, for a more consistent device-power-area
description in DT.
arm64: dts: r8a7795: Use SYSC "always-on" PM Domain
Hook up all devices that are part of the CPG/MSSR Clock Domain to the
SYSC "always-on" PM Domain, for a more consistent device-power-area
description in DT.
Add a device node for the System Controller.
Hook up the Cortex-A57 CPU cores and the Cortex-A57 and Cortex A53 L2
caches/SCUs to their respective PM Domains.
clk_get() on a disabled clock node will return -EPROBE_DEFER, which can
cause drivers to be deferred forever if such clocks are referenced in
their devices' clocks properties.
Update the various disabled external clock nodes to default to a
frequency of 0, but don't disable them, to prevent this.
soc: renesas: rcar-sysc: Enable Clock Domain for I/O devices
On R-Car H3, some power areas (e.g. A3VP) contain I/O devices, which are
also part of the CPG/MSSR Clock Domain.
On all R-Car SoCs, devices in the "always-on" PM Domain are part of the
Clock Domain served by the CPG/MSSR or CPG/MSTP driver.
Hook up the CPG/MSTP or CPG/MSSR Clock Domain attach/detach callbacks to
enable power management using module clocks. Which callback to hook up
depends on the presence of device nodes compatible with
"renesas,cpg-mstp-clocks". This clears the path for a future migration
from the CPG/MSTP to the CPG/MSSR driver on R-Car H1 and
Gen2.
ARM: dts: kzm9g: Configure NMI key as wake-up source
Add a GPIO key with wake-up capability for the NMI button.
This allows to wake up the system from s2ram without relying on the
buttons on the optional switch board.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Wolfram Sang [Fri, 1 Apr 2016 15:44:39 +0000 (17:44 +0200)]
ARM: dts: r8a7790: lager: Enable UHS-I SDR-50
Add the "1v8" pinctrl state and sd-uhs-sdr50 property to SDHI{0,2}.
Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
soc: renesas: rcar-sysc: Make rcar_sysc_power_is_off() static
As of commit b12ff41658171f53 ("ARM: shmobile: r8a7779: Remove legacy PM
Domain remainings"), rcar_sysc_power_is_off() is no longer used from
SoC-specific code.
soc: renesas: rcar-sysc: Add DT support for SYSC PM domains
Populate the SYSC PM domains from DT, based on the presence of a device
node for the System Controller. The actual power area hiearchy, and
features of specific areas are obtained from tables in the C code.
The SYSCIER and SYSCIMR register values are derived from the power areas
present, which will help to get rid of the hardcoded values in R-Car H1
and R-Car Gen2 platform code later.
Initialization is done from an early_initcall(), to make sure the PM
Domains are initialized before secondary CPU bringup.
soc: renesas: Move pm-rcar to drivers/soc/renesas/rcar-sysc
Move the pm-rcar driver from arch/arm/mach-shmobile/ to
drivers/soc/renesas/, and its header file to include/linux/soc/renesas/,
so it can be shared between arm32 (R-Car H1 and Gen2) and arm64 (R-Car
Gen3). Rename it to rcar-sysc as it's really a driver for the R-Car
System Controller (SYSC).
Kill the intermediate PM_RCAR config symbol, as it's not user
configurable anymore, and to prepare for SoC-specific make rules.
Add the missing #include <linux/types.h> to rcar-sysc.h, which was
exposed by different include order.
Ben Hutchings [Fri, 1 Apr 2016 15:44:38 +0000 (17:44 +0200)]
ARM: dts: r8a7790: Set maximum frequencies for SDHI clocks
Taken from the datasheet.
Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
The R-Car SYSC PM Domain driver has to power manage devices in power
areas using clocks. To reuse code and to share knowledge of clocks
suitable for power management, this is ideally done through the existing
cpg_mssr_attach_dev() and cpg_mssr_detach_dev() callbacks.
Hence these callbacks can no longer rely on their "domain" parameter
pointing to the CPG/MSSR Clock Domain. To handle this, keep a pointer to
the clock domain in a static variable. cpg_mssr_attach_dev() has to
support probe deferral, as the R-Car SYSC PM Domain may be initialized,
and devices may be added to it, before the CPG/MSSR Clock Domain is
initialized.
Dummy callbacks are provided for the case where CPG/MSTP support is not
included, so the rcar-sysc driver won't have to care about this.
clk: renesas: mstp: Provide dummy attach/detach_dev callbacks
Provide dummy cpg_mstp_{at,de}tach_dev() PM Domain callbacks if CPG/MSTP
support is not included, so the rcar-sysc driver won't have to care
about this.
clk: renesas: Provide Kconfig symbols for CPG/MSSR and CPG/MSTP support
Currently the decision whether to build the renesas-cpg-mssr and
clk-mstp drivers is handled by Makefile logic. However, the rcar-sysc
driver will need to know whether CPG/MSSR and/or CPG/MSTP support are
available or not.
To avoid having to duplicate this logic, move it to Kconfig. Provide
non-visible CLK_RENESAS_CPG_MSSR and CLK_RENESAS_CPG_MSTP Kconfig
symbols, which can be used by both Makefiles and C code.
ARM: dts: r8a7779: Correct interrupt type for ARM TWD
The ARM TWD interrupt is a private peripheral interrupt (PPI), and per
the ARM GIC documentation, whether the type for PPIs can be set is
IMPLEMENTATION DEFINED.
For R-Car H1 devices the PPI type cannot be set, and so when we attempt
to set the type for the ARM TWD interrupt it fails. This has gone
unnoticed because it fails silently, and because we cannot re-configure
the type it has had no impact. Nevertheless fix the type for the TWD
interrupt so that it matches the hardware configuration.
Based on patches by Jon Hunter for Tegra20/30 and OMAP4.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
ARM: dts: sh73a0: Correct interrupt type for ARM TWD
The ARM TWD interrupt is a private peripheral interrupt (PPI), and per
the ARM GIC documentation, whether the type for PPIs can be set is
IMPLEMENTATION DEFINED.
For SH-Mobile AG5 devices the PPI type cannot be set, and so when we
attempt to set the type for the ARM TWD interrupt it fails. This has
gone unnoticed because it fails silently, and because we cannot
re-configure the type it has had no impact. Nevertheless fix the type
for the TWD interrupt so that it matches the hardware configuration.
Based on patches by Jon Hunter for Tegra20/30 and OMAP4.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Simon Horman [Wed, 16 Mar 2016 01:52:55 +0000 (10:52 +0900)]
ARM: dts: r8a7793: add CAN clocks to device tree
The R-Car CAN controllers can derive the CAN bus clock not only from their
peripheral clock input (clkp1) but also from the other internal clock
(clkp2) and external clock fed on CAN_CLK pin. Describe those clocks in
the device tree along with the USB_EXTAL clock from which clkp2 is
derived.
Based on work by Sergei Shtylyov for the r8a7791 SoC.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au> Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
PM / Domains: Add DT bindings for the R-Car System Controller
The Renesas R-Car System Controller provides power management for the
CPU cores and various coprocessors, following the generic PM domain
bindings in Documentation/devicetree/bindings/power/power_domain.txt.
This supports R-Car Gen1 (H1), Gen2, and Gen3.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Enable dcu node which is used by the DCU DRM driver. Assign the 5.7"
EDT panel with VGA resolution which Toradex sells often with the
evaluation board.
Signed-off-by: Stefan Agner <stefan@agner.ch> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
The i.MX clock update for 4.7:
- Register SAI clk as shared clocks to support SAI audio on i.MX6SX
- Add the missing ckil clock for i.MX7
- Update clk-gate2 and vf610 clock driver to prepare for suspend
support on VF610
- Fix DCU clock configurations and add TCON ipg clock to support DRM
display on VF610
Stefan Agner [Tue, 12 Apr 2016 00:59:38 +0000 (08:59 +0800)]
clk: imx: vf610: add TCON ipg clock
Add the ipg (bus) clock for the TCON modules (Timing Controller). This
module is required by the new DCU DRM driver, since the display signals
pass through TCON.
Signed-off-by: Stefan Agner <stefan@agner.ch> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Stefan Agner [Tue, 5 Apr 2016 05:28:33 +0000 (22:28 -0700)]
clk: imx: vf610: fix DCU clock tree
Similar to an earlier fix for the SAI clocks, the DCU clock hierarchy
mixes the bus clock with the display controllers pixel clock. Tests
have shown that the gates in CCM_CCGR3/9 registers do not control
the DCU pixel clock, but only the register access clock (bus clock).
Fix this by defining the parent clock of VF610_CLK_DCUx to be the bus
clock (ipg_bus).
Since the clock has not been used far, there are no further changes
needed.
Signed-off-by: Stefan Agner <stefan@agner.ch> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
projects / karo-tx-linux.git / log