1. 14 Sep, 2012 11 commits
  2. 11 Sep, 2012 11 commits
  3. 23 Aug, 2012 1 commit
    • Feng Tang's avatar
      mfd: lpc_ich: Fix a 3.5 kernel regression for iTCO_wdt driver · 092369ef
      Feng Tang authored
      There are many reports (including 2 of my machines) that iTCO_wdt watchdog
      driver fails to be initialized in 3.5 kernel with error message like:
      
      [    5.265175] ACPI Warning: 0x00001060-0x0000107f SystemIO conflicts with Region \_SB_.PCI0.LPCB.TCOI 1 (20120320/utaddress-251)
      [    5.265192] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
      [    5.265206] lpc_ich: Resource conflict(s) found affecting iTCO_wdt
      
      The root cause the iTCO_wdt driver in 3.4 probes the HW IO resource from
      LPC's PCI config space, while in 3.5 kernel it relies on lpc_ich driver
      for the probe, which adds a new acpi_check_resource_conflict() check, and
      give up the probe if there is any conflict with ACPI.
      
      Fix it by removing all the checks for iTCO_wdt to keep the same behavior as
      3.4 kernel.
      https://bugzilla.kernel.org/show_bug.cgi?id=44991
      
      Actually the same check could be removed for the gpio-ich in lpc_ich.c,
      but I'm not sure if it will cause problems.
      Signed-off-by: default avatarFeng Tang <feng.tang@intel.com>
      Cc: Aaron Sierra <asierra@xes-inc.com>
      Cc: Wim Van Sebroeck <wim@iguana.be>
      Cc: Len Brown <len.brown@intel.com>
      Cc: Bob Moore <robert.moore@intel.com>
      Signed-off-by: default avatarSamuel Ortiz <sameo@linux.intel.com>
      092369ef
  4. 22 Aug, 2012 1 commit
    • AnilKumar Ch's avatar
      mfd: Move tps65217 regulator plat data handling to regulator · 817bb7fb
      AnilKumar Ch authored
      Regulator platform data handling was mistakenly added to MFD
      driver. So we will see build errors if we compile MFD drivers
      without CONFIG_REGULATOR. This patch moves regulator platform
      data handling from TPS65217 MFD driver to regulator driver.
      
      This makes MFD driver independent of REGULATOR framework so
      build error is fixed if CONFIG_REGULATOR is not set.
      
      drivers/built-in.o: In function `tps65217_probe':
      tps65217.c:(.devinit.text+0x13e37): undefined reference
      to `of_regulator_match'
      
      This patch also fix allocation size of tps65217 platform data.
      Current implementation allocates a struct tps65217_board for each
      regulator specified in the device tree. But the structure itself
      provides array of regulators so one instance of it is sufficient.
      Signed-off-by: default avatarAnilKumar Ch <anilkumar@ti.com>
      817bb7fb
  5. 16 Aug, 2012 11 commits
  6. 15 Aug, 2012 3 commits
    • Dave Airlie's avatar
      Merge branch 'drm-nouveau-fixes' of git://git.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes · 2e26c73a
      Dave Airlie authored
      * 'drm-nouveau-fixes' of git://git.freedesktop.org/git/nouveau/linux-2.6:
        drm/nv86/fifo: suspend fix
        drm/nouveau: disable copy engine on NVAF
        nouveau: fixup scanout enable in nvc0_pm
        drm/nouveau/aux: mask off higher bits of auxch index in i2c table entry
        drm/nvd0/disp: mask off high 16 bit of negative cursor x-coordinate
        drm/nve0/fifo: add support for the flip completion swmthd
      2e26c73a
    • Dave Airlie's avatar
      Merge branch 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel into drm-fixes · a389b6a1
      Dave Airlie authored
      Daniel Vetter writes:
      
      "A few important fixers:
      - fix various lvds backlight issues, regressed in 3.6 (Takashi Iwai)
      - make the retina mbp work (ignore bogus edp bpc value in vbt)
      - fix a gmbus regression introduced in (iirc) 3.4 (Jani Nikula)
      - fix an edp panel power sequence regression, fixes the new macbook air
      - apply the tlb invalidate w/a
      
      Otherwise we still have another gmbus regression (patches are awaiting
      tested-bys) and there's something odd going with some rare systems not
      entering rc6 often enough (and hence blowing through too much power).  It
      seems to be a timing-related issue and can be mitigated by frobbing the
      magic tuning parameters. We're still working on that one. Also, we still
      have some fallout from the hw context support, but you can only hit that
      with mesa master."
      
      * 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel:
        drm/i915: Apply post-sync write for pipe control invalidates
        drm/i915: reorder edp disabling to fix ivb MacBook Air
        drm/i915: ensure i2c adapter is all set before adding it
        drm/i915: ignore eDP bpc settings from vbt
        drm/i915: Fix blank panel at reopening lid
      a389b6a1
    • David S. Miller's avatar
      sparc64: Be less verbose during vmemmap population. · 2856cc2e
      David S. Miller authored
      On a 2-node machine with 256GB of ram we get 512 lines of
      console output, which is just too much.
      
      This mimicks Yinghai Lu's x86 commit c2b91e2e
      (x86_64/mm: check and print vmemmap allocation continuous) except that
      we aren't ever going to get contiguous block pointers in between calls
      so just print when the virtual address or node changes.
      
      This decreases the output by an order of 16.
      
      Also demote this to KERN_DEBUG.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2856cc2e
  7. 14 Aug, 2012 2 commits
    • Chris Wilson's avatar
      drm/i915: Apply post-sync write for pipe control invalidates · 7d54a904
      Chris Wilson authored
      When invalidating the TLBs it is documentated as requiring a post-sync
      write. Failure to do so seems to result in a GPU hang.
      
      Exposure to this hang on IVB seems to be a result of removing the extra
      stalls required for SNB pipecontrol workarounds:
      
      commit 6c6cf5aa
      Author: Chris Wilson <chris@chris-wilson.co.uk>
      Date:   Fri Jul 20 18:02:28 2012 +0100
      
          drm/i915: Only apply the SNB pipe control w/a to gen6
      
      Note: Manually switch the pipe_control cmd to 4 dwords to avoid a
      (silent) functional conflict with -next. This way will get a loud (but
      conflict with next (since the scratch_addr has been deleted there).
      
      Reported-and-tested-by: yex.tian@intel.com
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=53322Acked-by: default avatarBen Widawsky <ben@bwidawsk.net>
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      [danvet: added note about merge conflict with -next.]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      7d54a904
    • Daniel Vetter's avatar
      drm/i915: reorder edp disabling to fix ivb MacBook Air · 35a38556
      Daniel Vetter authored
      eDP is tons of fun. It turns out that at least the new MacBook Air 5,1
      model absolutely doesn't like the new force vdd dance we've introduced
      in
      
      commit 6cb49835
      Author: Daniel Vetter <daniel.vetter@ffwll.ch>
      Date:   Sun May 20 17:14:50 2012 +0200
      
          drm/i915: enable vdd when switching off the eDP panel
      
      But that patch also tried to fix some neat edp sequence issue with the
      force_vdd timings. Closer inspection reveals that we've raised
      force_vdd only to do the aux channel communication dp_sink_dpms. If we
      move the edp_panel_off below that, we don't need any force_vdd for the
      disable sequence, which makes the Air happy.
      
      Unfortunately the reporter of the original bug that the above commit
      fixed is travelling, so we can't test whether this regresses things.
      But my theory is that since we don't check for any power-off ->
      force_vdd-on delays in edp_panel_vdd_on, this was the actual
      root-cause of this failure. With that force_vdd dance completely
      eliminated, I'm hopeful the original bug stays fixed, too.
      
      For reference the old bug, which hopefully doesn't get broken by this:
      
      https://bugzilla.kernel.org/show_bug.cgi?id=43163
      
      In any case, regression fixers win over plain bugfixes, so this needs
      to go in asap.
      
      v2: The crucial pieces seems to be to clear the force_vdd flag
      uncoditionally, too, in edp_panel_off. Looks like this is left behind
      by the firmware somehow.
      
      v3: The Apple firmware seems to switch off the panel on it's own, hence
      we still need to keep force_vdd on, but properly clear it when switching
      the panel off.
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=45671Tested-by: default avatarRoberto Romer <sildurin@gmail.com>
      Tested-by: default avatarDaniel Wagner <wagi@monom.org>
      Tested-by: default avatarKeith Packard <keithp@keithp.com>
      Cc: stable@vger.kernel.org
      Cc: Keith Packard <keithp@keithp.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      35a38556