1. 06 Sep, 2012 6 commits
    • 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
  2. 01 Sep, 2012 5 commits
  3. 30 Aug, 2012 5 commits
  4. 29 Aug, 2012 18 commits
  5. 28 Aug, 2012 6 commits
    • Stefan Behrens's avatar
      Btrfs: fix that repair code is spuriously executed for transid failures · 256dd1bb
      Stefan Behrens authored
      If verify_parent_transid() fails for all mirrors, the current code
      calls repair_io_failure() anyway which means:
      - that the disk block is rewritten without repairing anything and
      - that a kernel log message is printed which misleadingly claims
        that a read error was corrected.
      
      This is an example:
      parent transid verify failed on 615015833600 wanted 110423 found 110424
      parent transid verify failed on 615015833600 wanted 110423 found 110424
      btrfs read error corrected: ino 1 off 615015833600 (dev /dev/...)
      
      It is wrong to ignore the results from verify_parent_transid() and to
      call repair_eb_io_failure() when the verification of the transids failed.
      This commit fixes the issue.
      Signed-off-by: default avatarStefan Behrens <sbehrens@giantdisaster.de>
      Signed-off-by: default avatarChris Mason <chris.mason@oracle.com>
      256dd1bb
    • Liu Bo's avatar
      Btrfs: fix ordered extent leak when failing to start a transaction · d280e5be
      Liu Bo authored
      We cannot just return error before freeing ordered extent and releasing reserved
      space when we fail to start a transacion.
      Signed-off-by: default avatarLiu Bo <bo.li.liu@oracle.com>
      Signed-off-by: default avatarChris Mason <chris.mason@oracle.com>
      d280e5be
    • Liu Bo's avatar
      Btrfs: fix a dio write regression · 24c03fa5
      Liu Bo authored
      This bug is introduced by commit 3b8bde746f6f9bd36a9f05f5f3b6e334318176a9
      (Btrfs: lock extents as we map them in DIO).
      
      In dio write, we should unlock the section which we didn't do IO on in case that
      we fall back to buffered write.  But we need to not only unlock the section
      but also cleanup reserved space for the section.
      
      This bug was found while running xfstests 133, with this 133 no longer complains.
      Signed-off-by: default avatarLiu Bo <bo.li.liu@oracle.com>
      Signed-off-by: default avatarChris Mason <chris.mason@oracle.com>
      24c03fa5
    • Josef Bacik's avatar
      Btrfs: fix deadlock with freeze and sync V2 · bd7de2c9
      Josef Bacik authored
      We can deadlock with freeze right now because we unconditionally start a
      transaction in our ->sync_fs() call.  To fix this just check and see if we
      have a running transaction to commit.  This saves us from the deadlock
      because at this point we'll have the umount sem for the sb so we're safe
      from freezes coming in after we've done our check.  With this patch the
      freeze xfstests no longer deadlocks.  Thanks,
      Signed-off-by: default avatarJosef Bacik <jbacik@fusionio.com>
      Signed-off-by: default avatarChris Mason <chris.mason@oracle.com>
      bd7de2c9
    • Stefan Behrens's avatar
      Btrfs: revert checksum error statistic which can cause a BUG() · 5ee0844d
      Stefan Behrens authored
      Commit 442a4f63 added btrfs device
      statistic counters for detected IO and checksum errors to Linux 3.5.
      The statistic part that counts checksum errors in
      end_bio_extent_readpage() can cause a BUG() in a subfunction:
      "kernel BUG at fs/btrfs/volumes.c:3762!"
      That part is reverted with the current patch.
      However, the counting of checksum errors in the scrub context remains
      active, and the counting of detected IO errors (read, write or flush
      errors) in all contexts remains active.
      
      Cc: stable <stable@vger.kernel.org> # 3.5
      Signed-off-by: default avatarStefan Behrens <sbehrens@giantdisaster.de>
      Signed-off-by: default avatarChris Mason <chris.mason@oracle.com>
      5ee0844d
    • Stefan Behrens's avatar
      Btrfs: remove superblock writing after fatal error · 68ce9682
      Stefan Behrens authored
      With commit acce952b, btrfs was changed to flag the filesystem with
      BTRFS_SUPER_FLAG_ERROR and switch to read-only mode after a fatal
      error happened like a write I/O errors of all mirrors.
      In such situations, on unmount, the superblock is written in
      btrfs_error_commit_super(). This is done with the intention to be able
      to evaluate the error flag on the next mount. A warning is printed
      in this case during the next mount and the log tree is ignored.
      
      The issue is that it is possible that the superblock points to a root
      that was not written (due to write I/O errors).
      The result is that the filesystem cannot be mounted. btrfsck also does
      not start and all the other btrfs-progs tools fail to start as well.
      However, mount -o recovery is working well and does the right things
      to recover the filesystem (i.e., don't use the log root, clear the
      free space cache and use the next mountable root that is stored in the
      root backup array).
      
      This patch removes the writing of the superblock when
      BTRFS_SUPER_FLAG_ERROR is set, and removes the handling of the error
      flag in the mount function.
      
      These lines can be used to reproduce the issue (using /dev/sdm):
      SCRATCH_DEV=/dev/sdm
      SCRATCH_MNT=/mnt
      echo 0 25165824 linear $SCRATCH_DEV 0 | dmsetup create foo
      ls -alLF /dev/mapper/foo
      mkfs.btrfs /dev/mapper/foo
      mount /dev/mapper/foo $SCRATCH_MNT
      echo bar > $SCRATCH_MNT/foo
      sync
      echo 0 25165824 error | dmsetup reload foo
      dmsetup resume foo
      ls -alF $SCRATCH_MNT
      touch $SCRATCH_MNT/1
      ls -alF $SCRATCH_MNT
      sleep 35
      echo 0 25165824 linear $SCRATCH_DEV 0 | dmsetup reload foo
      dmsetup resume foo
      sleep 1
      umount $SCRATCH_MNT
      btrfsck /dev/mapper/foo
      dmsetup remove foo
      Signed-off-by: default avatarStefan Behrens <sbehrens@giantdisaster.de>
      Signed-off-by: default avatarJan Schmidt <list.btrfs@jan-o-sch.net>
      68ce9682