1. 11 2月, 2011 5 次提交
    • O
      ARM: tegra: add tegra_defconfig · f2b6133f
      Olof Johansson 提交于
      Adding one single defconfig for the tegra family of boards, to over time
      cover the superset of supported platform and drivers.
      Signed-off-by: NOlof Johansson <olof@lixom.net>
      Signed-off-by: NColin Cross <ccross@android.com>
      f2b6133f
    • C
      ARM: tegra: dma: Fix critical data corruption bugs · 5789fee9
      Colin Cross 提交于
      Sometimes, due to high interrupt latency in the continuous mode
      of DMA transfer, the half buffer complete interrupt is handled
      after DMA has transferred the full buffer.  When this is detected,
      stop DMA immediately and restart with the next buffer if the next
      buffer is ready.
      
      originally fixed by Victor(Weiguo) Pan <wpan@nvidia.com>
      
      In place of using the simple spin_lock()/spi_unlock() in the
      interrupt thread, using the spin_lock_irqsave() and
      spin_unlock_irqrestore(). The lock is shared between the normal
      process context and interrupt context.
      
      originally fixed by Laxman Dewangan (ldewangan@nvidia.com)
      
      The use of shadow registers caused memory corruption at physical
      address 0 because the enable bit was not shadowed, and assuming it
      needed to be set would enable an unconfigured dma block.  Most of the
      register accesses don't need to know the previous state of the
      registers, and the few places that do need to modify only a few bits
      in the registers are the same ones that were sometimes incorrectly
      setting the enable bit.  This patch convert tegra_dma_update_hardware
      to set the entire register, and the other users to read-modify-write,
      and drops the shadow registers completely.
      
      Also fixes missing locking in tegra_dma_allocate_channel
      Signed-off-by: NColin Cross <ccross@android.com>
      5789fee9
    • C
      ARM: tegra: Allow overriding arch_reset · 699fe145
      Colin Cross 提交于
      Signed-off-by: NColin Cross <ccross@android.com>
      699fe145
    • C
      ARM: tegra: cpufreq: Disable cpufreq during suspend · 1eb2ecf1
      Colin Cross 提交于
      On Tegra, calling clk_set_rate on the CPU clock may call into the
      regulator API.  If the regulator driver that controls the CPU
      voltage rail has been suspended, this can lead to attempted
      communication with a hardware block that has already been turned
      off.
      
      Adds a SUSPEND_PREPARE notification hook to drop the frequency to
      the lowest possible during suspend.
      
      Also adds 216MHz (off of PLLP) as the lowest CPU frequency, which
      allows PLLX to be turned off.
      Signed-off-by: NColin Cross <ccross@android.com>
      1eb2ecf1
    • G
      ARM: tegra: iomap: Add missing devices · 537f5af0
      Gary King 提交于
      Adds gart, hdmi, avp, host1x, and pwm controllers to mach/iomap.h
      Signed-off-by: NGary King <gking@nvidia.com>
      Signed-off-by: NColin Cross <ccross@android.com>
      537f5af0
  2. 10 2月, 2011 9 次提交
  3. 07 2月, 2011 15 次提交
  4. 06 2月, 2011 3 次提交
  5. 05 2月, 2011 2 次提交
  6. 04 2月, 2011 1 次提交
    • S
      x86, mm: avoid possible bogus tlb entries by clearing prev mm_cpumask after switching mm · 831d52bc
      Suresh Siddha 提交于
      Clearing the cpu in prev's mm_cpumask early will avoid the flush tlb
      IPI's while the cr3 is still pointing to the prev mm.  And this window
      can lead to the possibility of bogus TLB fills resulting in strange
      failures.  One such problematic scenario is mentioned below.
      
       T1. CPU-1 is context switching from mm1 to mm2 context and got a NMI
           etc between the point of clearing the cpu from the mm_cpumask(mm1)
           and before reloading the cr3 with the new mm2.
      
       T2. CPU-2 is tearing down a specific vma for mm1 and will proceed with
           flushing the TLB for mm1.  It doesn't send the flush TLB to CPU-1
           as it doesn't see that cpu listed in the mm_cpumask(mm1).
      
       T3. After the TLB flush is complete, CPU-2 goes ahead and frees the
           page-table pages associated with the removed vma mapping.
      
       T4. CPU-2 now allocates those freed page-table pages for something
           else.
      
       T5. As the CR3 and TLB caches for mm1 is still active on CPU-1, CPU-1
           can potentially speculate and walk through the page-table caches
           and can insert new TLB entries.  As the page-table pages are
           already freed and being used on CPU-2, this page walk can
           potentially insert a bogus global TLB entry depending on the
           (random) contents of the page that is being used on CPU-2.
      
       T6. This bogus TLB entry being global will be active across future CR3
           changes and can result in weird memory corruption etc.
      
      To avoid this issue, for the prev mm that is handing over the cpu to
      another mm, clear the cpu from the mm_cpumask(prev) after the cr3 is
      changed.
      
      Marking it for -stable, though we haven't seen any reported failure that
      can be attributed to this.
      Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Acked-by: NIngo Molnar <mingo@elte.hu>
      Cc: stable@kernel.org	[v2.6.32+]
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      831d52bc
  7. 03 2月, 2011 4 次提交
    • S
      x86, mtrr: Avoid MTRR reprogramming on BP during boot on UP platforms · f7448548
      Suresh Siddha 提交于
      Markus Kohn ran into a hard hang regression on an acer aspire
      1310, when acpi is enabled. git bisect showed the following
      commit as the bad one that introduced the boot regression.
      
      	commit d0af9eed
      	Author: Suresh Siddha <suresh.b.siddha@intel.com>
      	Date:   Wed Aug 19 18:05:36 2009 -0700
      
      	    x86, pat/mtrr: Rendezvous all the cpus for MTRR/PAT init
      
      Because of the UP configuration of that platform,
      native_smp_prepare_cpus() bailed out (in smp_sanity_check())
      before doing the set_mtrr_aps_delayed_init()
      
      Further down the boot path, native_smp_cpus_done() will call the
      delayed MTRR initialization for the AP's (mtrr_aps_init()) with
      mtrr_aps_delayed_init not set. This resulted in the boot
      processor reprogramming its MTRR's to the values seen during the
      start of the OS boot. While this is not needed ideally, this
      shouldn't have caused any side-effects. This is because the
      reprogramming of MTRR's (set_mtrr_state() that gets called via
      set_mtrr()) will check if the live register contents are
      different from what is being asked to write and will do the actual
      write only if they are different.
      
      BP's mtrr state is read during the start of the OS boot and
      typically nothing would have changed when we ask to reprogram it
      on BP again because of the above scenario on an UP platform. So
      on a normal UP platform no reprogramming of BP MTRR MSR's
      happens and all is well.
      
      However, on this platform, bios seems to be modifying the fixed
      mtrr range registers between the start of OS boot and when we
      double check the live registers for reprogramming BP MTRR
      registers. And as the live registers are modified, we end up
      reprogramming the MTRR's to the state seen during the start of
      the OS boot.
      
      During ACPI initialization, something in the bios (probably smi
      handler?) don't like this fact and results in a hard lockup.
      
      We didn't see this boot hang issue on this platform before the
      commit d0af9eed, because only
      the AP's (if any) will program its MTRR's to the value that BP
      had at the start of the OS boot.
      
      Fix this issue by checking mtrr_aps_delayed_init before
      continuing further in the mtrr_aps_init(). Now, only AP's (if
      any) will program its MTRR's to the BP values during boot.
      
      Addresses https://bugzilla.novell.com/show_bug.cgi?id=623393
      
        [ By the way, this behavior of the bios modifying MTRR's after the start
          of the OS boot is not common and the kernel is not prepared to
          handle this situation well. Irrespective of this issue, during
          suspend/resume, linux kernel will try to reprogram the BP's MTRR values
          to the values seen during the start of the OS boot. So suspend/resume might
          be already broken on this platform for all linux kernel versions. ]
      Reported-and-bisected-by: NMarkus Kohn <jabber@gmx.org>
      Tested-by: NMarkus Kohn <jabber@gmx.org>
      Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Cc: Thomas Renninger <trenn@novell.com>
      Cc: Rafael Wysocki <rjw@novell.com>
      Cc: Venkatesh Pallipadi <venki@google.com>
      Cc: stable@kernel.org # [v2.6.32+]
      LKML-Reference: <1296694975.4418.402.camel@sbsiddha-MOBL3.sc.intel.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      f7448548
    • M
      x86, nx: Don't force pages RW when setting NX bits · f12d3d04
      Matthieu CASTET 提交于
      Xen want page table pages read only.
      
      But the initial page table (from head_*.S) live in .data or .bss.
      
      That was broken by 64edc8ed.  There is
      absolutely no reason to force these pages RW after they have already
      been marked RO.
      Signed-off-by: NMatthieu CASTET <castet.matthieu@free.fr>
      Tested-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      f12d3d04
    • M
      arm: omap4: panda: remove usb_nop_xceiv_register(v1) · ed2af92b
      Ming Lei 提交于
      Panda uses both twl6030 otg phy(vbus, id) and internal
      phy(data lines, DP/DM), so removes usb_nop_xceiv_register to make
      twl6030 otg driver working since current otg code only supports
      one global transceiver. Otherwise, musb doesn't work without
      the remove.
      Reviewd-by: NFelipe Balbi <balbi@ti.com>
      Signed-off-by: NMing Lei <tom.leiming@gmail.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      ed2af92b
    • M
      OMAP1: Fix non-working LCD on OMAP310 · 719078a6
      Marek Vasut 提交于
      This patch fixes bug introduced in revision:
      
      f8e9e984
      omap1: DMA: move LCD related code from plat-omap to mach-omap1
      
      The code introduced by this patch didn't consider any other CPUs but OMAP1510,
      which rendered OMAP310 -- which has the same LCD controller -- non-working. Use
      cpu_is_omap15xx() instead of cpu_is_omap1510() to squash this issue.
      
      Bug found on Palm Zire 71 hardware.
      Signed-off-by: NMarek Vasut <marek.vasut@gmail.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      719078a6
  8. 02 2月, 2011 1 次提交
    • T
      OMAP3: Devkit8000: Change lcd power pin · daf7aabc
      Thomas Weber 提交于
      This patch fixes a wrongly used lcd enable pin.
      
      The Devkit8000 uses twl4030_ledA configured as output gpio only for
      the lcd enable line. twl4030_gpio.1 is used through the generic
      gpio functions while ledA is used via low level twl4030 calls.
      
      This patch removes the low level calls and use the generic gpio functions
      for initialization and use of ledA. This patch also fixes a bug where the
      lcd would not power down when blanking.
      
      Further this patch fixes an indentation issue. The comment line uses
      eight whitespace and is replaced with a hard tab.
      
      gpio_request + gpio_direction_output are replaced with gpio_request_one.
      The return value of gpio_request_one is used to set the value of the
      gpio to -EINVAL when unsuccessful, so that gpio_is_valid can detect the
      unsuccessful request. But already successful requested gpios are not freed.
      Reported-by: NDaniel Morsing <daniel.morsing@gmail.com>
      Signed-off-by: NThomas Weber <weber@corscience.de>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      daf7aabc