Skip to content
  1. Sep 20, 2012
  3. Sep 12, 2012
  5. Sep 07, 2012
    • Stephen Warren's avatar
      ARM: dt: tegra: whistler: add regulators · e7765b37
      Stephen Warren authored 
      

Whistler uses a Maxim 8907 regulator. Instantiate this.

The voltage settings were derived from the schematic. The only exception
is the BBAT voltage; the schematic says 1.2v, but the HW can't go that
low, so use the HW default of 2.4v instead.

Almost all regulators list all driven supply signal names in their
regulator-names property. The exception is nvvdd_sv3, which is in turn
named 12 more different names on the schematic, so these were omitted
for brevity.

Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      e7765b37
    • Stephen Warren's avatar
      ARM: dt: tegra: paz00: add regulators · 217b8f0f
      Stephen Warren authored 
      The Toshiba AC100/PAZ00 uses a TPS6586x regulator. Instantiate this.

Three data sources were used for the data encoded here:
* The HW defaults, as extracted from real HW.
* The schematic, which specifies a voltage for each rail in the signal
  names.
* The AC100 kernel used by the Ubuntu port:

  repo git://gitorious.org/~marvin24/ac100/marvin24s-kernel.git


  branch chromeos-ac100-3.0
  file arch/arm/mach-tegra/board-paz00-power.c

  For many rails, the constraints in that tree specified differing min
  and max voltages. In all cases, the min value was ignored, since
  there's no need currently to vary any of the voltages at run-time.
  DVFS might change this in the future.

In most cases these sources all matched. Differences are:

sm0: HW defaults and schematic match at 1.2v. marvin24's kernel had a max
of 1.3v, but this higher voltage was only applied to HW by DVFS code,
which isn't currently supported in mainline.

sm1: HW defaults and schematic match at 1.0v. marvin24's kernel had a max
of 1.125v, but this higher voltage was only applied to HW by DVFS code,
which isn't currently supported in mainline.

ldo3: The HW default is on. marvin24's kernel didn't specify always-on,
but since the board wasn't marked as having fully constrained regulators,
the rail was not turned off, so the difference had no effect. The rail
is needed for USB.

ldo6: The HW default is 2.85v. The schematics indicate 2.85v. However,
since this regulator is used for the same purpose as on other boards that
require 1.8v, this is set to 1.8v. Note that this regulator feeds the CRT
VDAC on Tegra, and so in practice is unlikely to be used, even though it
is actaully hooked up in HW.

Portions based on work by Laxman Dewangan <ldewangan@nvidia.com>

Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
Tested-by: Marc Dietrich <marvin24@gmx.de> # v2
Acked-by: default avatarLaxman Dewangan <ldewangan@nvidia.com>
      217b8f0f
    • Stephen Warren's avatar
      ARM: dt: tegra: ventana: add regulators · 017a0104
      Stephen Warren authored 
      

Ventana uses a TPS6586x regulator. Instantiate this, and hook up a
couple of fixed GPIO-controlled regulators too.

The data was chosen to match the PMIC HW defaults, with the following
exception:

ldo6: The HW default is 2.85v. The schematics are unlabelled. Internal
research indicates that 1.8v is correct. Our downstream kernel also uses
1.8v.

Portions based on work by Laxman Dewangan <ldewangan@nvidia.com>

Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      017a0104
    • Stephen Warren's avatar
      ARM: dt: tegra: seaboard: add regulators · 6529e638
      Stephen Warren authored 
      Seaboard uses a TPS6586x regulator. Instantiate this, and hook up a
couple of fixed GPIO-controlled regulators too.

Two data sources were used for the data encoded here:
* The HW defaults, as extracted from real HW.
* The schematic, which specifies a voltage for each LDO rail.

In most cases these sources matched. The only differences is:

ldo6: The HW default on Springbank is 2.85v. The HW default on Seaboard
is 1.8v. The schematics for both Springbank and Seaboard match at 2.85v.
However, internal research indicates that the schematics are incorrectly
labelled, and 1.8v is correct. The ChromeOS kernel also uses 1.8v.

Note that these settings don't entirely match those in the ChromeOS
kernel found at the URL below. However, the selected values generally
cause no behavior change in the kernel, and so were picked to avoid
regressions.

repo http://git.chromium.org/chromiumos/third_party/kernel.git


branch chromeos-3.2
file arch/arm/mach-tegra/board-seaboard-power.c

Portions based on work by Laxman Dewangan <ldewangan@nvidia.com>

Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      6529e638
    • Laxman Dewangan's avatar
      ARM: tegra: cardhu: add dt entry for fixed regulators · fa4a9252
      Laxman Dewangan authored 
      

Cadhu have multiple power rails which are controlled by
GPIOs. Add support of these power rail control through
fixed regulators. Add entry for all fixed regulators for
cardhu-a02 and a04.
The details are taken from downstream kernel.

Some points on this change are:

* Add the tps65910-LDO5 entry and make it always ON
 to supply power to SDMMC. Once the sd driver support
 regulator handling, this flag will be remove.

* Dropping registration of rail vdd_sdmmc1 as the gpio
  is used by sdhci power-gpio. This need to fix in
  sdhci driver and then need to add the registration
  mechanism. Just removing power-gpio and adding fixed
  regulator with this gpio is causing the sd  access to
  fail because first probe call of this regulator fails
  due to non-available of parent and so it calls
  gpio_free() which disable the pins in gpio mode make
  pin output to LOW causes power to OFF. In probe retry,
  it got success and it powered-on but it again need to
  do again numeration of card here.

Signed-off-by: default avatarLaxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      fa4a9252
    • Laxman Dewangan's avatar
      ARM: dt: tegra: cardhu: split dts file for support multiple board versions · 640a7af5
      Laxman Dewangan authored 
      

There is multiple version of cardhu starting from A01 to A07.
Cardhu A01 and A03 are not supported. Cardhu A02 will have
different sets of GPIOs for fixed regulator compare to
cardhu A04. The Cardhu A05, A06, A07 are compatibe with A04.
Based on cardhu version, the related dts file need to be chosen
like for cardhu A02, use tegra30-cardhu-a02.dts, cardhu A04 and
more, use tegra30-cardhu-a04.dts.
This patch create the DTS file A02 and A04 and convert tegra30-cardhu.dts
as dts include file.

Signed-off-by: default avatarLaxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      640a7af5
    • Laxman Dewangan's avatar
      ARM: dt: tegra: cardhu: add entry for PMIC TPS65911. · 167e6279
      Laxman Dewangan authored 
      

Tegra30 based platform "cardhu" have the power management
IC TPS65911 for the regulator.
Adding DT entry for this device.
Data are chosen from downstream kernel and making the
voltage output as require by default for device to
operate.
The default interrupt line is HIGH from PMIC device and so
inverting the interrupt detection line of PMU interrupt
through configuring PMC.
In this patch, do not registering LDO5 because the input
supply for this rail is different for different version of
cardhu i..e A02 and A04. The registration will be done once
the dts file for cardhu A02 and A04 are added in follow on
patches.

Signed-off-by: default avatarLaxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      167e6279
  7. Sep 02, 2012
    • Linus Torvalds's avatar
      Linux 3.6-rc4 · 4cbe5a55
      Linus Torvalds authored
      4cbe5a55
    • John Stultz's avatar
      time: Move ktime_t overflow checking into timespec_valid_strict · cee58483
      John Stultz authored 
      

Andreas Bombe reported that the added ktime_t overflow checking added to
timespec_valid in commit 4e8b1452 ("time: Improve sanity checking of
timekeeping inputs") was causing problems with X.org because it caused
timeouts larger then KTIME_T to be invalid.

Previously, these large timeouts would be clamped to KTIME_MAX and would
never expire, which is valid.

This patch splits the ktime_t overflow checking into a new
timespec_valid_strict function, and converts the timekeeping codes
internal checking to use this more strict function.

Reported-and-tested-by: default avatarAndreas Bombe <aeb@debian.org>
Cc: Zhouping Liu <zliu@redhat.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Prarit Bhargava <prarit@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Signed-off-by: default avatarJohn Stultz <john.stultz@linaro.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      cee58483
  9. Sep 01, 2012
  11. Aug 31, 2012
    • Linus Torvalds's avatar
      Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux · 155e36d4
      Linus Torvalds authored 
      Pull drm fixes from Dave Airlie:
 "A bunch of scattered fixes ati/intel/nouveau, couple of core ones,
  nothing too shocking or different."

* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
  drm: Add EDID_QUIRK_FORCE_REDUCED_BLANKING for ASUS VW222S
  gma500: Consider CRTC initially active.
  drm/radeon: fix dig encoder selection on DCE61
  drm/radeon: fix double free in radeon_gpu_reset
  drm/radeon: force dma32 to fix regression rs4xx,rs6xx,rs740
  drm/radeon: rework panel mode setup
  drm/radeon/atom: powergating fixes for DCE6
  drm/radeon/atom: rework DIG modesetting on DCE3+
  drm/radeon: don't disable plls that are in use by other crtcs
  drm/radeon: add proper checking of RESOLVE_BOX command for r600-r700
  drm/radeon: initialize tracked CS state
  drm/radeon: fix reading CB_COLORn_MASK from the CS
  drm/nvc0/copy: check PUNITS to determine which copy engines are disabled
  i915: Quirk no_lvds on Gigabyte GA-D525TUD ITX motherboard
  drm/i915: Use the correct size of the GTT for placing the per-process entries
  drm: Check for invalid cursor flags
  drm: Initialize object type when using DRM_MODE() macro
  drm/i915: fix color order for BGR formats on IVB
  drm/i915: fix wrong order of parameters in port checking functions
      155e36d4
  13. Aug 30, 2012
  15. Aug 29, 2012