Skip to content

L
linux
Switch branch/tag
  1. 07 Jul, 2016 4 commits
  3. 06 Jul, 2016 8 commits
  5. 05 Jul, 2016 4 commits
  7. 01 Jul, 2016 2 commits
    • Jon Hunter's avatar
      bus: Add support for Tegra ACONNECT · 46a88534
      Jon Hunter authored 
      Add a bus driver for the Tegra ACONNECT which is used to interface to
various devices within the Audio Processing Engine (APE). The purpose
of the bus driver is to register child devices that are accessed via
the ACONNECT bus and through the device parent child relationship,
ensure that the appropriate power domain and clocks are enabled for
the ACONNECT when any of the child devices are active. Hence, the
ACONNECT driver simply enables runtime-pm for the ACONNECT device
so that when a child device is resumed, it will enable the power-domain
and clocks associated with the ACONNECT.
Signed-off-by: default avatarJon Hunter <jonathanh@nvidia.com>
Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      46a88534
    • Jon Hunter's avatar
      dt-bindings: bus: Add documentation for Tegra210 ACONNECT · 894b68e1
      Jon Hunter authored 
      Add binding documentation for the Tegra ACONNECT bus that is part of the
Audio Processing Engine (APE) on Tegra210. The ACONNECT bus is used to
access devices within the APE subsystem. The APE is located in a
separate power domain and so accesses made to the ACONNECT require the
power domain to be enabled as well as some platform specific clocks.
Signed-off-by: default avatarJon Hunter <jonathanh@nvidia.com>
Acked-by: default avatarRob Herring <robh@kernel.org>
Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      894b68e1
  9. 30 Jun, 2016 12 commits
    • Thierry Reding's avatar
      soc/tegra: Stub out PCIe IRQ workaround on 64-bit ARM · 8582f6d1
      Thierry Reding authored 
      The PCIe host controller found on Tegra20 has a hardware bug that causes
PCIe interrupts to get lost when LP2 is enabled. Stub out the workaround
on 64-bit ARM because none of the more recent Tegra SoC generations seem
to have this bug anymore.
Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      8582f6d1
    • Jon Hunter's avatar
      soc/tegra: pmc: Enable XUSB partitions on boot · 8df12745
      Jon Hunter authored 
      The Tegra XHCI driver does not currently manage the Tegra XUSB power
partitions and so it these partitions have not been enabled by the
bootloader then the system will crash when probing the XHCI device.

While proper support for managing the power partitions is being
developed to the XHCI driver for Tegra, for now power on all the XUSB
partitions for USB host and super-speed on boot if the XHCI driver is
enabled.
Signed-off-by: default avatarJon Hunter <jonathanh@nvidia.com>
Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      8df12745
    • Jon Hunter's avatar
      soc/tegra: pmc: Initialise power partitions early · e2d17960
      Jon Hunter authored 
      If CONFIG_PM_GENERIC_DOMAINS is not enabled, then power partitions
associated with a device will not be enabled automatically by the PM
core when the device is in use. To avoid situations where a device in
a power partition is to be used but the partition is not enabled,
initialise the power partitions for Tegra early in the boot process and
if CONFIG_PM_GENERIC_DOMAINS is not enabled, then power on all
partitions defined in the device-tree blob.

Note that if CONFIG_PM_GENERIC_DOMAINS is not enabled, after the
partitions are turned on, the clocks and resets used as part of the
sequence for turning on the partition are released again as they are no
longer needed by the PMC driver. Another benefit of this is that this
avoids any issues of sharing resets between the PMC driver and other
device drivers that may wish to independently control a particular
reset.
Signed-off-by: default avatarJon Hunter <jonathanh@nvidia.com>
Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      e2d17960
    • Jon Hunter's avatar
      soc/tegra: pmc: Add specific error messages · c2710ac9
      Jon Hunter authored 
      When initialising a powergate, only a single error message is shown if
the initialisation fails. Add more error messages to give specific
details of what failed if the initialisation failed and remove the
generic failure message.
Signed-off-by: default avatarJon Hunter <jonathanh@nvidia.com>
Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      c2710ac9
    • Thierry Reding's avatar
      soc/tegra: pmc: Use whitespace more consistently · da8f4b45
      Thierry Reding authored 
      Use blank lines after blocks and before labels for consistency with the
existing code in the file.
Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      da8f4b45
    • Jon Hunter's avatar
      soc/tegra: pmc: Don't probe PMC if early initialisation fails · a83f1fc3
      Jon Hunter authored 
      Commit 0259f522 ('soc/tegra: pmc: Restore base address on probe
failure') fixes an issue where the PMC base address pointer is not
restored on probe failure. However, this fix creates another problem
where if early initialisation of the PMC driver fails and an initial
mapping for the PMC address space is not created, then when the PMC
device is probed, the PMC base address pointer will not be valid and
this will cause a crash when tegra_pmc_init() is called and attempts
to access a register.

Although the PMC address space is mapped a 2nd time during the probe
and so this could be fixed by populating the base address pointer
earlier during the probe, this adds more complexity to the code.
Moreover, the PMC probe also assumes the the soc data pointer is also
initialised when the device is probed and if not will also lead to a
crash when calling tegra_pmc_init_tsense_reset(). Given that if the
early initialisation does fail then something bad has happen, it seems
acceptable to allow the PMC device probe to fail as well. Therefore, if
the PMC base address pointer or soc data pointer are not valid when
probing the PMC device, WARN and return an error.

Fixes: 0259f522 ('soc/tegra: pmc: Restore base address on probe failure')
Signed-off-by: default avatarJon Hunter <jonathanh@nvidia.com>
Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      a83f1fc3
    • Jon Hunter's avatar
      soc/tegra: pmc: Add missing of_node_put() · b69a6258
      Jon Hunter authored 
      Add missing of_node_put() in PMC early initialisation function to avoid
leaking the device nodes.
Signed-off-by: default avatarJon Hunter <jonathanh@nvidia.com>
[treding@nvidia.com: squash in a couple more of_node_put() calls]
Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      b69a6258
    • Jon Hunter's avatar
      soc/tegra: pmc: Ensure mutex is always initialised · 61fd284b
      Jon Hunter authored 
      The mutex used by the PMC driver may not be initialised if early
initialisation of the driver fails. If this does happen, then it could
be possible for callers of the public PMC functions to still attempt to
acquire the mutex. Fix this by initialising the mutex as soon as
possible to ensure it will always be initialised.
Signed-off-by: default avatarJon Hunter <jonathanh@nvidia.com>
Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      61fd284b
    • Jon Hunter's avatar
      soc/tegra: pmc: Don't populate SoC data until register space is mapped · 718a2426
      Jon Hunter authored 
      The public functions exported by the PMC driver use the presence of the
SoC data pointer to determine if the PMC device is configured and the
registers can be accessed. However, the SoC data is populated before the
PMC register space is mapped and this opens a window where the SoC data
pointer is valid but the register space has not yet been mapped which
could lead to a crash. Furthermore, if the mapping of the PMC register
space fails, then the SoC data pointer is not cleared and so would
expose a larger window where a crash could occur.

Fix this by initialising the SoC data pointer after the PMC register
space has been mapped.
Signed-off-by: default avatarJon Hunter <jonathanh@nvidia.com>
Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      718a2426
    • Jon Hunter's avatar
      soc/tegra: pmc: Fix early initialisation of PMC · 11131895
      Jon Hunter authored 
      During early initialisation, the available power partitions for a given
device is configured as well as the polarity of the PMC interrupt. Both
of which should only be configured if there is a valid device node for
the PMC device. This is because the soc data used for configuring the
power partitions is only available if a device node for the PMC is found
and the code to configure the interrupt polarity uses the device node
pointer directly.

Some early device-tree images may not have this device node and so fix
this by ensuring the device node pointer is valid when configuring these
items.
Signed-off-by: default avatarJon Hunter <jonathanh@nvidia.com>
Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      11131895
    • Jon Hunter's avatar
      soc/tegra: pmc: Ensure powergate is available when powering on · 403db2d2
      Jon Hunter authored 
      The function tegra_power_sequence_power_up() is a public function used
to power on a partition. When this function is called, we do not check
to see if the partition being powered up is valid/available. Fix this
by checking to see that the partition is valid/available.
Signed-off-by: default avatarJon Hunter <jonathanh@nvidia.com>
Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      403db2d2
    • Jon Hunter's avatar
      soc/tegra: pmc: Initialise resets associated with a power partition · 05cfb988
      Jon Hunter authored 
      When registering the Tegra power partitions with the generic PM domain
framework, the current state of the each partition is checked and used
as the default state for the partition. However, the state of each reset
associated with the partition is not initialised and so it is possible
that the state of the resets are not in the expected state. For example,
if a partition is on, then the resets should be de-asserted and if the
partition is off, the resets should be asserted.

There have been cases where the bootloader has powered on a partition
and only de-asserted some of the resets to some of the devices in the
partition. This can cause accesses to these devices to hang the system
when the kernel boots and attempts to probe these devices.

Ideally, the driver for the device should ensure the reset has been
de-asserted when probing, but the resets cannot be shared between the
PMC driver (that needs to de-assert/assert the reset when turning the
partition on or off) and another driver because we cannot ensure the
reset is in the correct state.

To ensure the resets are in the correct state, when using the generic
PM domain framework, put each reset associated with the partition in
the correct state (based upon the partition's current state) when
obtaining the resets for a partition.
Signed-off-by: default avatarJon Hunter <jonathanh@nvidia.com>
Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      05cfb988
  11. 29 Jun, 2016 4 commits
  13. 25 Jun, 2016 3 commits
  15. 24 Jun, 2016 3 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7