Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 29 1月, 2013 2 次提交
  3. 25 12月, 2012 1 次提交
  5. 16 11月, 2012 1 次提交
  7. 14 11月, 2012 1 次提交
  9. 06 11月, 2012 4 次提交
  11. 17 10月, 2012 1 次提交
  13. 15 9月, 2012 5 次提交
    • S
      ARM: tegra: remove dead code · bab53ce3
      由 Stephen Warren 提交于 
      Now that all boards are converted to device tree, devices.[ch] and
board-pinmux.[ch] are no longer used. So, remove them.

The only exception is the EHCI platform data in devices.h. Move that
data to board-dt-tegra20.c - the only places it's used.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
      bab53ce3
    • L
      ARM: dt: tegra: harmony: add regulators · 3cc404de
      由 Laxman Dewangan 提交于 
      Harmony uses a TPS6586x regulator. Instantiate this, and hook up a
couple of fixed GPIO-controlled regulators too.

Based on Ventana regulator patch by Stephen Warren <swarren@nvidia.com>
and converted to Harmony.

swarren made the following changes:
* Added ldo0 regulator configuration to device tree, and updated
  board-harmony-pcie.c for the new regulator name.
* Fixed vdd_1v05's voltage from 10.5V to 1.05V.
* Modified board-harmony-pcie.c to obtain the en_vdd_1v05 GPIO number at
  run-time from device tree instead of hard-coding it.
* Removed board-harmony{-power.c,.h} now that they're unused.
* Disabled vdd_1v05 regulator; the code in board-harmony-pcie.c hijacks
  this GPIO for now. This will be fixed when the PCIe driver is re-
  written as a driver. The code can't regulator_get("vdd_1v05") right
  now, because the vdd_1v05 regulator's probe gets deferred due to its
  supply being the PMIC, which gets probed after the regulator the first
  time around, and this dependency is only resolved by repeated probing,
  which happens when deferred_probe_initcall() is called, which happens
  in a late initcall, whose runtime order relative to harmony_pcie_init()
  is undefined, since that's also called from a late initcall.
* Removed unused harmony_pcie_initcall().
Signed-off-by: NLaxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: NStephen Warren <swarren@nvidia.com>
      3cc404de
    • S
      ARM: tegra: remove board (but not DT) support for Harmony · bb25af81
      由 Stephen Warren 提交于 
      Harmony can be booted using device tree with equal functionality as when
booted using a board file. Remove as much of the board file as is
possible, since it's no longer needed.

Two special-cases are still left in board-dt-tegra20.c, since the Tegra
PCIe driver doesn't support device tree yet, and the Harmony .dts file
doesn't yet describe regulators which are needed for PCIe. This logic is
now enabled unconditionally rather than via CONFIG_MACH_HARMONY. While
this is more code than other boards, it's still unlikely to be much of a
problem, and both regulators and PCIe should be supported via device tree
in the near future, allowing the remaining code to be removed.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
      bb25af81
    • S
      ARM: tegra: remove board (but not DT) support for Paz00 · cff1dfbf
      由 Stephen Warren 提交于 
      Paz00 (Toshiba AC100) can be booted using device tree with equal
functionality as when booted using a board file. Remove as much of the
board file as is possible, since it's no longer needed.

One special-case is still left in board-dt-tegra20.c, since there is no
way to create a WiFi rfkill device from device tree yet. This logic is
now enabled unconditionally rather than via CONFIG_MACH_PAZ00. The extra
cases where it's enabled (.configs which did not enable Paz00 support)
shouldn't impact much since the amount of code is tiny.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Acked-By: NMarc Dietrich <marvin24@gmx.de>
      cff1dfbf
    • S
      ARM: tegra: remove board (but not DT) support for TrimSlice · be6a9194
      由 Stephen Warren 提交于 
      TrimSlice can be booted using device tree with equal functionality as
when booted using a board file. Remove the board file since it's no
longer needed.

One special-case is still left in board-dt-tegra20.c, since the Tegra
PCIe driver doesn't support device tree yet. This logic is now enabled
by CONFIG_TEGRA_PCI rather than via CONFIG_MACH_TRIMSLICE. The extra
cases where it's enabled (.configs which did not enable TrimSlice
support) shouldn't impact much since the amount of code is tiny.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
      be6a9194
  15. 13 9月, 2012 1 次提交
  17. 07 9月, 2012 1 次提交
    • S
      ARM: tegra: turn on UART A clock at boot · 37c241ed
      由 Stephen Warren 提交于 
      Some boards use UART D for the main serial console, and some use UART A.
UART D's clock is listed in board-dt-tegra20.c's clock table, whereas
UART A's clock is not. This causes the clock code to think UART A's
clock is unsed. The common clock framework turns off unused clocks at
boot time. This makes the kernel appear to hang. Add UART A's clock into
the clock table to prevent this. Eventually, this requirement should be
handled by the UART driver, and/or properties in a board-specific device
tree file.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
      37c241ed
  19. 03 7月, 2012 1 次提交
  21. 30 6月, 2012 1 次提交
  23. 27 6月, 2012 1 次提交
  25. 21 6月, 2012 3 次提交
    • S
      ARM: tegra: paz00: enable WiFi rfkill when booting from device tree · b64a02c6
      由 Stephen Warren 提交于 
      There currently aren't bindings for a WiFi rfkill button, and defining
a good binding is non-trivial. Manually register this "device" when
booting from device tree, in order to bring DT support to the same
feature level as board files, which will in turn allow board files to be
deprecated.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
      b64a02c6
    • S
      ARM: tegra: harmony: init regulators, PCIe when booting from DT · a12c0efc
      由 Stephen Warren 提交于 
      There currently aren't bindings for the Tegra PCIe controller. Work on
this is in progress, but not yet complete. Manually initialize PCIe when
booting from device tree, in order to bring DT support to the same
feature level as board files, which will in turn allow board files to be
deprecated.

PCIe on Harmony requires various regulators to be registered and enabled
before initializing the PCIe controller. Note that since the I2C
controllers are instantiated from DT, we must use i2c_new_device() to
register the PMU rather than i2c_register_board_info().
Signed-off-by: NStephen Warren <swarren@nvidia.com>
      a12c0efc
    • S
      ARM: tegra: trimslice: enable PCIe when booting from device tree · c554dee3
      由 Stephen Warren 提交于 
      There currently aren't bindings for the Tegra PCIe controller. Work on
this is in progress, but not yet complete. Manually initialize PCIe when
booting from device tree, in order to bring DT support to the same
feature level as board files, which will in turn allow board files to be
deprecated.

PCIe hosts the wired Ethernet controller on TrimSlice.

To support this, add infra-structure to board-dt-tegra20.c for board-
specific initialization code. Once device tree support for the relevant
features is in place, this code will be removed.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
      c554dee3
  27. 08 5月, 2012 1 次提交
  29. 19 4月, 2012 2 次提交
  31. 17 4月, 2012 1 次提交
  33. 07 4月, 2012 1 次提交
  35. 22 3月, 2012 1 次提交
  37. 05 3月, 2012 1 次提交
    • S
      ARM: tegra: match SoC name not board name in DT board files · c5444f39
      由 Stephen Warren 提交于 
      board-dt-tegra*.c should support any board using Tegra when booted using
device tree. Instead of explicitly listing all the supported boards,
which requires a kernel change for each new board, list the supported SoC
model instead.

Note that the board files do currently have explicit support for setting
up each board's pinmux. However, it's fairly likely that at least the
basic devices on any new board will work just fine as set up by the boot-
loader, and the pinmux data should be moving into device tree soon anyway.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>
      c5444f39
  39. 18 12月, 2011 2 次提交
  41. 08 12月, 2011 6 次提交
  43. 16 11月, 2011 1 次提交
  45. 10 11月, 2011 1 次提交
    • S
      arm/tegra: Don't create duplicate gpio and pinmux devices · 4b91b6fb
      由 Stephen Warren 提交于 
      *_pinmux_init() register the GPIO and pinmux devices so that they're ready
before any other device needs them.

*_pinmux_init() are also called by board-dt.c in order to set up the GPIO
and pinmux configurations. In this case, if we register the devices, they
end up being probed once due to this registration, and a second time due
to a device-tree node (or vice-versa). The second probe fails since the
memory regions are already requested. Besides, we don't actually want the
duplicated devices.

To avoid this duplicate registration, modify *_pinmux_init() to check
whether it's running on a DT machine. If not, register the pinmux devices.
If so, don't register them.

Finally, modify board-dt.c to call the *_pinmux_init() after all devices have
been instantiated from device-tree. This allows the GPIO and pinmux devices
to be instantiated and initialized before calling functions to configure the
hardware.

This has one disadvantage: The pinmux and GPIO initialization now happens
after /all/ devices are instantiated, rather than after just gpio and
pinmux but before anything else. So the correct HW configuration is not
in place when e.g. the SD/MMC device is probed. Long-term, this should be
solved by doing both:

a) Initializing the HW state from DT nodes during GPIO and pinmux device
   probe.
b) Using the deferred driver probe mechanism, so that drivers can defer
   their probe until after the gpio and pinmux drivers have probed.

v2: s/int is_dt/bool is_dt/
v3: Use of_machine_is_compatible inside *_pinmux_init() rather than passing
an explicit parameter into the function from outside.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>
      4b91b6fb