The stmmac driver will try to acquire its private mutex during suspend
via phylink_resolve() -> stmmac_mac_link_down() -> stmmac_eee_init().
However, the phylink configuration is updated with the private mutex
held already, which causes a deadlock during suspend.
Fix this by moving the phylink configuration updates out of the region
of code protected by the private mutex.
Fixes: 19e13cb27b ("net: stmmac: Hold rtnl lock in suspend/resume callbacks")
Suggested-by: Bitan Biswas <bbiswas@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Commit 73f3816609 ("arm64: Advertise mitigation of Spectre-v2, or lack
thereof") renamed the caller of the install_bp_hardening_cb() function
but forgot to update a comment, which can be confusing when trying to
follow the code flow.
Fixes: 73f3816609 ("arm64: Advertise mitigation of Spectre-v2, or lack thereof")
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Will Deacon <will@kernel.org>
The size of individual pages in the page pool in given by an order. The
order is the binary logarithm of the number of pages that make up one of
the pages in the pool. However, the driver currently passes the number
of pages rather than the order, so it ends up wasting quite a bit of
memory.
Fix this by taking the binary logarithm and passing that in the order
field.
Fixes: 2af6106ae9 ("net: stmmac: Introducing support for Page Pool")
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Writing the 0x1704 (BUS_BAR1_BLOCK) register causes the GPU to probe the
memory region at the programmed address. The result is an address decode
error in the external memory controller because address 0, which is what
is written to the register, is not designated as accessible to devices.
Avoid triggering DMA from the GPU by removing teardown of the BAR1.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
When the last reference to a TTM BO is dropped, ttm_bo_release() will
acquire the DMA reservation object's wound/wait mutex while trying to
clean up (ttm_bo_cleanup_refs_or_queue() via ttm_bo_release()). It is
therefore essential that drm_gem_object_release() be called after the
TTM BO has been uninitialized, otherwise drm_gem_object_release() has
already destroyed the wound/wait mutex (via dma_resv_fini()).
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Prior to commit 019cbd4a4f ("drm/nouveau: Initialize GEM object before
TTM object"), the reservation object was locked across all of the buffer
object creation.
After splitting nouveau_bo_new() into separate nouveau_bo_alloc() and
nouveau_bo_init() functions, the reservation object is passed to the
latter, so the lock needs to be held across that function as well.
Fixes: 019cbd4a4f ("drm/nouveau: Initialize GEM object before TTM object")
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Commit 019cbd4a4f ("drm/nouveau: Initialize GEM object before TTM
object") introduced a subtle change in how the buffer allocation size is
handled. Prior to that change, the size would get aligned to at least a
page, whereas after that change a non-page-aligned size would get passed
through unmodified. This ultimately causes a BUG_ON() to trigger in
drm_gem_private_object_init() and crashes the system.
Fix this by restoring the code that align the allocation size.
Fixes: 019cbd4a4f ("drm/nouveau: Initialize GEM object before TTM object")
Reported-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
devm_phy_get() can fail for a number of reasons besides probe deferral.
It can for example return -ENOMEM if it runs out of memory as it tries
to allocate devres structures. Propagating only -EPROBE_DEFER is
problematic because it results in these legitimately fatal errors being
treated as "PHY not specified in DT".
What we really want is to ignore the optional PHYs only if they have not
been specified in DT. devm_phy_optional_get() is a function that exactly
does what's required here, so use that instead.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Andrew Murray <andrew.murray@arm.com>
Cc: Ray Jui <rjui@broadcom.com>
Cc: Scott Branden <sbranden@broadcom.com>
Cc: bcm-kernel-feedback-list@broadcom.com
regulator_get_optional() can fail for a number of reasons besides probe
deferral. It can for example return -ENOMEM if it runs out of memory as
it tries to allocate data structures. Propagating only -EPROBE_DEFER is
problematic because it results in these legitimately fatal errors being
treated as "regulator not specified in DT".
What we really want is to ignore the optional regulators only if they
have not been specified in DT. regulator_get_optional() returns -ENODEV
in this case, so that's the special case that we need to handle. So we
propagate all errors, except -ENODEV, so that real failures will still
cause the driver to fail probe.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Andrew Murray <andrew.murray@arm.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
devm_of_phy_get_by_index() can fail for a number of reasons besides
probe deferral. It can for example return -ENOMEM if it runs out of
memory as it tries to allocate devres structures. Propagating only
-EPROBE_DEFER is problematic because it results in these legitimately
fatal errors being treated as "PHY not specified in DT".
What we really want is to ignore the optional PHYs only if they have not
been specified in DT. devm_of_phy_get_by_index() returns -ENODEV in this
case, so that's the special case that we need to handle. So we propagate
all errors, except -ENODEV, so that real failures will still cause the
driver to fail probe.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Andrew Murray <andrew.murray@arm.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
regulator_get_optional() can fail for a number of reasons besides probe
deferral. It can for example return -ENOMEM if it runs out of memory as
it tries to allocate data structures. Propagating only -EPROBE_DEFER is
problematic because it results in these legitimately fatal errors being
treated as "regulator not specified in DT".
What we really want is to ignore the optional regulators only if they
have not been specified in DT. regulator_get_optional() returns -ENODEV
in this case, so that's the special case that we need to handle. So we
propagate all errors, except -ENODEV, so that real failures will still
cause the driver to fail probe.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Andrew Murray <andrew.murray@arm.com>
Cc: Richard Zhu <hongxing.zhu@nxp.com>
Cc: Lucas Stach <l.stach@pengutronix.de>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: kernel@pengutronix.de
Cc: linux-imx@nxp.com
devm_of_phy_get() can fail for a number of reasons besides probe
deferral. It can for example return -ENOMEM if it runs out of memory as
it tries to allocate devres structures. Propagating only -EPROBE_DEFER
is problematic because it results in these legitimately fatal errors
being treated as "PHY not specified in DT".
What we really want is to ignore the optional PHYs only if they have not
been specified in DT. devm_of_phy_get() returns -ENODEV in this case, so
that's the special case that we need to handle. So we propagate all
errors, except -ENODEV, so that real failures will still cause the
driver to fail probe.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Andrew Murray <andrew.murray@arm.com>
Cc: Jingoo Han <jingoohan1@gmail.com>
Cc: Kukjin Kim <kgene@kernel.org>
Cc: Krzysztof Kozlowski <krzk@kernel.org>
regulator_get_optional() can fail for a number of reasons besides probe
deferral. It can for example return -ENOMEM if it runs out of memory as
it tries to allocate data structures. Propagating only -EPROBE_DEFER is
problematic because it results in these legitimately fatal errors being
treated as "regulator not specified in DT".
What we really want is to ignore the optional regulators only if they
have not been specified in DT. regulator_get_optional() returns -ENODEV
in this case, so that's the special case that we need to handle. So we
propagate all errors, except -ENODEV, so that real failures will still
cause the driver to fail probe.
Tested-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Andrew Murray <andrew.murray@arm.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Shawn Lin <shawn.lin@rock-chips.com>
Cc: Shawn Lin <shawn.lin@rock-chips.com>
Cc: Heiko Stuebner <heiko@sntech.de>
Cc: linux-rockchip@lists.infradead.org
TTM assumes that drivers initialize the embedded GEM object before
calling the ttm_bo_init() function. This is not currently the case
in the Nouveau driver. Fix this by splitting up nouveau_bo_new()
into nouveau_bo_alloc() and nouveau_bo_init() so that the GEM can
be initialized before TTM BO initialization when necessary.
Fixes: b96f3e7c80 ("drm/ttm: use gem vma_node")
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190814093524.GA31345@ulmo
The stmmaceth clock is specified by the slave_bus and apb_pclk clocks in
the device tree bindings for snps,dwc-qos-ethernet-4.10 compatible nodes
of this IP.
The subdrivers for these bindings will be requesting the stmmac clock
correctly at a later point, so there is no need to request it here and
cause an error message to be printed to the kernel log.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The Tegra EQOS driver already resets the MDIO bus at probe time via the
reset GPIO specified in the phy-reset-gpios device tree property. There
is no need to reset the bus again later on.
This avoids the need to query the device tree for the snps,reset GPIO,
which is not part of the Tegra EQOS device tree bindings. This quiesces
an error message from the generic bus reset code if it doesn't find the
snps,reset related delays.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
"Findfrom" is not a word. Replace the function synopsis by something
that makes sense.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Rob Herring <robh@kernel.org>
Some subsystems, such as pinctrl, allow continuing to defer probe
indefinitely. This is useful for devices that depend on resources
provided by devices that are only probed after the init stage.
One example of this can be seen on Tegra, where the DPAUX hardware
contains pinmuxing controls for pins that it shares with an I2C
controller. The I2C controller is typically used for communication
with a monitor over HDMI (DDC). However, other instances of the I2C
controller are used to access system critical components, such as a
PMIC. The I2C controller driver will therefore usually be a builtin
driver, whereas the DPAUX driver is part of the display driver that
is loaded from a module to avoid bloating the kernel image with all
of the DRM/KMS subsystem.
In this particular case the pins used by this I2C/DDC controller
become accessible very late in the boot process. However, since the
controller is only used in conjunction with display, that's not an
issue.
Unfortunately the driver core currently outputs a warning message
when a device fails to get the pinctrl before the end of the init
stage. That can be confusing for the user because it may sound like
an unwanted error occurred, whereas it's really an expected and
harmless situation.
In order to eliminate this warning, this patch allows callers of the
driver_deferred_probe_check_state() helper to specify that they want
to continue deferring probe, regardless of whether we're past the
init stage or not. All of the callers of that function are updated
for the new signature, but only the pinctrl subsystem passes a true
value in the new persist parameter if appropriate.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20190621151725.20414-1-thierry.reding@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
It turns out that this PLL is not used on Tegra210, so there's no need
to enable it via the init table. Remove the init table entry for this
PLL to avoid it getting enabled at boot time. If the bootloader enabled
it and forgot to turn it off, the common clock framework will now know
to disable it because it is unused.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
A PLL in IDDQ doesn't work, whether it's enabled or not. This is not a
configuration that makes sense, so warn about it.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
There is no need to warn if the reference PLL is enabled with the
correct defaults. Only warn if the boot values don't match the defaults.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Some pin groups have park bits for multiple pins in one register.
Support this by turning the parked bit field into a parked bitmask
field. If no parked bits are supported, the bitmask can be 0.
Update the pingroup table on Tegra210, which is the only generation
where this is supported, with the parked bitmask.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Tested-by: Dmitry Osipenko <digetx@gmail.com>
Reviewed-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Rather than reuse the nvidia,tegra30-gpio compatible string
to find the GPIO controller on Tegra30, Tegra114, Tegra124 and
Tegra210, use the most specific compatible string for each
SoC generation for consistency.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Jetson Nano implements CPU sleep via PSCI, much like any of the other
Tegra X1 platforms. Enable the sleep states to allow the CPU to go into
lower power states when idle.
Signed-off-by: Thierry Reding <treding@nvidia.com>
The Jetson Nano has two ID EEPROMs, one for the module and another for
the carrier board. Add both to the device tree so that they can be read
from at runtime.
Signed-off-by: Thierry Reding <treding@nvidia.com>
There is an ID EEPROM on the Jetson TX2 carrier board, part of the
Jetson TX2 Developer Kit, that exposes information that can be used to
identify the carrier board. Add the device tree node so that operating
systems can access this EEPROM.
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
There is an ID EEPROM in the Jetson TX2 module that stores various bits
of information to indentify the module. Add the device tree node so that
operating systems can access this EEPROM.
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
There is an ID EEPROM on the Jetson TX1 carrier board, part of the
Jetson TX1 Developer Kit, that exposes information that can be used to
identify the carrier board. Add the device tree node so that operating
systems can access this EEPROM.
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
There is an ID EEPROM in the Jetson TX1 module that stores various bits
of information to indentify the module. Add the device tree node so that
operating systems can access this EEPROM.
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
If the driver defers probe because of a missing clock, avoid outputting
an error message. The clock will show up eventually.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Due to an integration issue the architected timer on Tegra210 does not
remain on during system suspend (a.k.a. SC7). Mark it accordingly so
that it isn't considered as a means to track suspend time.
Signed-off-by: Thierry Reding <treding@nvidia.com>
The architected timer on Tegra186 and Tegra194 is in an always on power
partition and its reference clock will always run, so mark the timer as
always on.
Signed-off-by: Thierry Reding <treding@nvidia.com>
The Tegra210 SoC has four inputs that consume power in order to supply
the PLLs that drive the various USB, PCI and SATA pads.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
The Tegra124 SoC has four inputs that consume power in order to supply
the PLLs that drive the various USB, PCI and SATA pads.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
These power supplies provide power for various PLLs that are set up and
driven by the XUSB pad controller. These power supplies were previously
improperly added to the PCIe and XUSB controllers, but depending on the
driver probe order, power to the PLLs will not be supplied soon enough
and cause initialization to fail.
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Deferred probe is an expected return value for clk_get() on many
platforms. The driver deals with it properly, so there's no need
to output a warning that may potentially confuse users.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Recent changes have made it much more likely that clocks are not available,
when the SDHCI driver is first probed. However, that is a situation that
the driver can cope with just fine.
To avoid confusion, don't output an error when this happens.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The VDD supply is only needed to supply power to eDP panels connected to
DPAUX. Technically that supply should be dealt with in the panel driver,
but for backwards-compatibility we need to keep this around anyway.
Also as a bit of background: the reason for why this supply is attached
to DPAUX is to make sure the panel is properly powered early on so that
it can generate a hotplug pulse at the appropriate time. This may no
longer be required given the support for deferred fbdev setup that was
"recently" introduced in DRM/KMS.
Signed-off-by: Thierry Reding <treding@nvidia.com>
The legacy GPIO API has long been deprecated. Move the driver over to
the descriptor-based API, which allows us to get rid of some boilerplate
while at it.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Logical devices created by the host1x bus infrastructure don't need to
be associated with a device tree node. Doing so will cause the driver
core to attempt to hook up IOMMU operations and fail because it is not
a real device.
However, for backwards-compatibility, we need to provide various OF_*
uevent variables that were previously provided by of_device_uevent() and
which are parsed by libdrm in userspace when querying the available
devices. Do this by implementing a uevent callback for the host1x bus.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Recent versions of the DMA API debug code have started to warn about
violations of the maximum DMA segment size. This is because the segment
size defaults to 64 KiB, which can easily be exceeded in large buffer
allocations such as used in DRM/KMS for framebuffers.
Technically the Tegra SMMU and ARM SMMU don't have a maximum segment
size (they map individual pages irrespective of whether they are
contiguous or not), so the choice of 4 MiB is a bit arbitrary here. The
maximum segment size is a 32-bit unsigned integer, though, so we can't
set it to the correct maximum size, which would be the size of the
aperture.
Signed-off-by: Thierry Reding <treding@nvidia.com>
When deferring probe, avoid logging a confusing error message. While at
it, make the error message more informational.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Two of the Tegra I2C controllers share pads with the DPAUX controllers.
In order for the I2C controllers to use these pads, they have to be set
into I2C mode. Use the I2C and off pin control states defined in the DT
nodes for DPAUX as "default" and "idle" states, respectively. This
ensures that the I2C controller driver can properly configure the pins
when it needs to perform I2C transactions.
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The GPIO expanders on Jetson TX2 are powered by the VDD_1V8 and
VDD_3V3_SYS supplies, respectively. Model this in device tree so that
the correct supplies are referenced.
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Recent changes have made it much more probable that clocks are not
available yet when the FUSE driver is first probed. However, that is a
situation that the driver can cope with just fine.
To avoid confusion, don't output an error when this happens.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Add some comments to clarify the purpose of the wake event support
implemented in the PMC driver.
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
For interrupts that are not wakeup sources but that may end up getting
mapped through the PMC as interrupt parent (this can happen for GPIOs),
return early in order to avoid a subsequent crash from an out-of-bounds
access to the register region.
Reported-by: Bitan Biswas <bbiswas@nvidia.com>
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The code currently doesn't support allocating more than one wake IRQ at
a time. Detect this situation and error out. Also make sure to output a
warning when that happens to help track down callers.
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Drivers registered with module_platform_driver_probe() are considered
non-hotpluggable, which among other things means that they don't support
deferred probe. However, recent changes in how the ARM SMMU works have
required the BPMP (which is the clock provider on Tegra186 and later) be
bound to the SMMU, which in turn means that the BPMP driver can defer
probe and hence clocks become available much later than they used to.
For most other drivers this is not a problem because they already
properly support deferred probe, but rtc-tegra is the odd one out that
now fails to probe and will therefore never be registered.
Fix this by making the driver a regular driver that supports unloading
and deferred probe.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Many of the variables have redundant prefixes or suffixes. Drop all of
them where not necessary for context. Also make sure to use data types
consistently. For instance, values read from 32-bit register accessors
should be stored in u32.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
This set of changes fixes some checkpatch warnings as well as a number
of punctuation and padding inconsistencies.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
If the subdriver defers probe, do not show an error message. It's
perfectly fine for this error to occur since the driver will get another
chance to probe after some time and will usually succeed after all of
the resources that it requires have been registered.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
Jetson Nano, Jetson TX1 and Jetson TX2 all are named "Developer Kit" and
Jetson AGX Xavier is the odd one out. It's officially also called the
"Developer Kit", not "Development Kit", so make it consistent with the
rest.
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
P2888 is the internal part number for the Jetson AGX Xavier module.
Clarify that using the DT model property.
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
P3310 is the internal part number for the Jetson TX2 module. Clarify
that using the DT model property.
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
P2771 is the internal part number for the Jetson TX2 Developer Kit.
Clarify that using the DT model property.
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Now that all users of the old definitions have been updated to use the
Tegra186 specific prefix, remove the unused definitions.
Signed-off-by: Thierry Reding <treding@nvidia.com>
In order to move away from misleadingly generic definitions of the GPIO
macros, use the Tegra186-specific prefix. These are the last remaining
occurrences. The generic definitions can be removed after this.
Signed-off-by: Thierry Reding <treding@nvidia.com>
The recently introduced XUSB support for Jetson TX2 is causing boot, CPU
hotplug and suspend/resume failures according to several reports.
Temporarily work around this by disabling the XUSB controller and XUSB
pad controller nodes in device tree, while we figure out what's causing
this.
Reported-by: Bitan Biswas <bbiswas@nvidia.com>
Reported-by: Jonathan Hunter <jonathanh@nvidia.com>
Tested-by: Bitan Biswas <bbiswas@nvidia.com>
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Commit 954a03be03 ("iommu/arm-smmu: Break insecure users by disabling
bypass by default") intentionally breaks all devices using the SMMU in
bypass mode. This breaks, among other things, PCI support on Tegra186.
Fix this by populating the iommus property and friends for the PCIe
controller.
Fixes: 954a03be03 ("iommu/arm-smmu: Break insecure users by disabling bypass by default")
Signed-off-by: Thierry Reding <treding@nvidia.com>
Various regulators were marked as always-on for Jetson TX2. At this
point, all of the regulators are properly hooked up, so this workaround
is no longer required.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Enable the relevant pads for XUSB support on P2771-0000 and hook up the
USB supply voltage regulators to the ports.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Move the Trusted Foundations support out of arch/arm/firmware and into
drivers/firmware where most other firmware support implementations are
located.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Some 32-bit Tegra devices supported by the multiplatform ARM v7 default
configuration ship with the Trusted Foundations firmware. Enable support
for it by default.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Support for the Trusted Foundations firmware was recently moved outside
of arch/arm and now needs to be selected explicitly. Since some 32-bit
Tegra devices use this firmware, enable support for it in the default
configuration.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Most of the changes here are just symbols that are now enabled by
default, have been removed, or which have been moved around and now
appear in a different spot.
The only notable change here is that BACKLIGHT_CLASS_DEVICE is now
built-in. This is to allow BACKLIGHT_PWM to be built-in as well.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Update multi_v7_defconfig for dropped and moved options
This series of two patches first updates multi_v7_defconfig for
dropped options, and then updates it for moved options. We want to
do this on regular basis to make it easier to patch multi_v7_defconfig
without introducing errors and merge conflicts. We update the defconfig
in two patches to make sure we're not accidentally losing any needed
options.
After this, updating multi_v7_defconfig will become trivial, and most
likely only a small follow-up patches are needed after the merge window
to update it again for moved options.
The XUSB pad controller is responsible for supplying power to the PLLs
used to drive the various USB, PCI and SATA pads. Move the PLL power
supplies from the PCIe and XUSB controllers to the XUSB pad controller
to make sure they are available when needed.
Signed-off-by: Thierry Reding <treding@nvidia.com>
The XUSB pad controller is responsible for supplying power to the PLLs
used to drive the various USB, PCI and SATA pads. Move the PLL power
supplies from the XUSB controller to the XUSB pad controller to make
sure they are available when needed.
Signed-off-by: Thierry Reding <treding@nvidia.com>
The XUSB pad controller is responsible for supplying power to the PLLs
used to drive the various USB, PCI and SATA pads. Move the PLL power
supplies from the PCIe and XUSB controllers to the XUSB pad controller
to make sure they are available when needed.
Signed-off-by: Thierry Reding <treding@nvidia.com>
The XUSB pad controller is responsible for supplying power to the PLLs
used to drive the various USB, PCI and SATA pads. Move the PLL power
supplies from the PCIe and XUSB controllers to the XUSB pad controller
to make sure they are available when needed.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Parentheses in the SPDX license identifier are only used to group sub-
expressions. If there's no need for such grouping, the parentheses can
be omitted.
Reviewed-by: Igor Opaniuk <igor.opaniuk@toradex.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The Jetson Nano Developer Kit is a Tegra X1 based development board. It
is similar to Jetson TX1 but it is not pin compatible. It features 4 GB
of LPDDR4, an SPI NOR flash for early boot firmware and an SD card slot
used for storage.
HDMI 2.0 or DP 1.2 are available for display, four USB ports (3 USB 2.0
and 1 USB 3.0) can be used to attach a variety of peripherals and a PCI
Ethernet controller provides onboard network connectivity. An M.2 Key-E
slot with PCIe x1 adds additional possibilities.
A 40-pin header on the board can be used to extend the capabilities and
exposed interfaces of the Jetson Nano.
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The XUSB pad controller is responsible for supplying power to the PLLs
used to drive the various USB, PCI and SATA pads. Move the PLL power
supplies from the PCIe and XUSB controllers to the XUSB pad controller
to make sure they are available when needed.
Signed-off-by: Thierry Reding <treding@nvidia.com>
The XUSB pad controller is responsible for supplying power to the PLLs
used to drive the various USB, PCI and SATA pads. Move the PLL power
supplies from the PCIe and XUSB controllers to the XUSB pad controller
to make sure they are available when needed.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Support enabling various supplies needed to provide power to the PLLs
and logic used to drive the USB, PCI and SATA pads.
Reviewed-by: JC Kuo <jckuo@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
The device tree bindings document the "mode" property of "ports"
subnodes, but the driver was not parsing the property. In preparation
for adding role switching, parse the property at probe time.
Based on work by JC Kuo <jckuo@nvidia.com>.
Reviewed-by: JC Kuo <jckuo@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Extend the bindings to cover the set of features found in Tegra186. Note
that, technically, there are four more supplies connected to the XUSB
pad controller (DVDD_PEX, DVDD_PEX_PLL, HVDD_PEX and HVDD_PEX_PLL), but
the power sequencing requirements of Tegra186 require these to be under
the control of the PMIC.
Reviewed-by: JC Kuo <jckuo@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
The audio configuration is only valid if the HDMI codec has been
properly set up. Do not attempt to set up audio before that happens
because it causes a division by zero.
Note that this is only problematic on Tegra20 and Tegra30. Later chips
implement the division instructions which return zero when dividing by
zero and don't throw an exception.
Fixes: db5adf4d6d ("drm/tegra: hdmi: Fix audio to work with any pixel clock rate")
Reported-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Tested-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Rename all occurrences of "terga" to "tegra". It's an easy typo to make
and a difficult one to spot.
Reviewed-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The list of dependencies has become unsorted, which makes it difficult
to find the right place to insert new dependencies. Restore alphabetical
order to make future additions easier.
Signed-off-by: Thierry Reding <treding@nvidia.com>
By implementing the acquire/release protocol, the SOR reset can be
shared with other drivers that also adhere to this protocol, such as the
PMC driver that uses the same reset as part of the powergate and -ungate
implementation using generic power domains.
Runtime PM makes sure that the operations are executed in the right
order, and the reset core has error handling and WARNs in place to make
sure the acquire/release protocol is followed.
Signed-off-by: Thierry Reding <treding@nvidia.com>
By implementing the acquire/release protocol, the resets can be shared
with other drivers that also adhere to this protocol. This will be used
for example by the SOR driver to put hardware into a known good state,
irrespective of whether or not the power domain can be reset.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Add implementations that apply acquire and release operations to all
reset controls part of a reset control array.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
In order to be able to request an array of reset controls in acquired or
released mode, add the acquired flag to of_reset_control_array_get() and
pass the flag to subsequent calls of __of_reset_control_get().
Signed-off-by: Thierry Reding <treding@nvidia.com>
Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Commit 0e7d6f9401 ("gpio: of: Apply regulator-gpio quirk only to
enable-gpios") breaks the device tree ABI specified in the device tree
bindings for fixed regulators (compatible "regulator-fixed"). According
to these bindings the polarity of the GPIO is exclusively controlled by
the presence or absence of the enable-active-high property. As such the
polarity quirk implemented in of_gpio_flags_quirks() must be applied to
the GPIO specified for fixed regulators.
However, commit 0e7d6f9401 ("gpio: of: Apply regulator-gpio quirk only
to enable-gpios") restricted the quirk to the enable-gpios property for
fixed regulators as well, whereas according to the commit message itself
it should only apply to "regulator-gpio" compatible device tree nodes.
Fix this by actually implementing what the offending commit intended,
which is to ensure that the quirk is applied to the GPIO specified by
the "enable-gpio" property for the "regulator-gpio" bindings only.
This fixes a regression on Jetson TX1 where the fixed regulator for the
HDMI +5V pin relies on the flags quirk for the proper polarity.
Fixes: 0e7d6f9401 ("gpio: of: Apply regulator-gpio quirk only to enable-gpios")
Signed-off-by: Thierry Reding <treding@nvidia.com>
Tested-by: Marek Vasut <marek.vasut@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
During initialization, the host and super-speed power domains will
contain an ERR_PTR() encoded error code rather than being NULL. To
avoid a crash, use a !IS_ERR_OR_NULL() condition during cleanup.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Fixes: 6494a9ad86 ("usb: xhci: tegra: Add genpd support")
Cc: stable <stable@vger.kernel.org>
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Commit 482997699e ("ARM: tegra: Fix unit_address_vs_reg DTC warnings
for /memory") inadventently broke device tree ABI by adding a unit-
address to the "/memory" node because the device tree compiler flagged
the missing unit-address as a warning.
Tegra124 Chromebooks (a.k.a. Nyan) use a bootloader that relies on the
full name of the memory node in device tree being exactly "/memory". It
can be argued whether this was a good decision or not, and some other
bootloaders (such as U-Boot) do accept a unit-address in the name of the
node, but the device tree is an ABI and we can't break existing setups
just because the device tree compiler considers it bad practice to omit
the unit-address nowadays.
This partially reverts the offending commit and restores device tree ABI
compatibility.
Fixes: 482997699e ("ARM: tegra: Fix unit_address_vs_reg DTC warnings for /memory")
Reported-by: Tristan Bastian <tristan-c.bastian@gmx.de>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Tested-by: Tristan Bastian <tristan-c.bastian@gmx.de>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Thierry Reding