1. 23 Sep, 2007 9 commits
    • Pierre Ossman's avatar
      mmc: add missing printk levels · 8fdd8521
      Pierre Ossman authored
      Some printk:s were missing an explicit level.
      Signed-off-by: default avatarPierre Ossman <drzeus@drzeus.cx>
      8fdd8521
    • Pierre Ossman's avatar
      mmc: remove confusing flag · be0192aa
      Pierre Ossman authored
      The MMC_DATA_MULTI flag never had a proper definition of what it
      means, so remove it and let the drivers check the block count in
      the request.
      Signed-off-by: default avatarPierre Ossman <drzeus@drzeus.cx>
      be0192aa
    • Pierre Ossman's avatar
      mmc: remove BYTEBLOCK capability · 255d01af
      Pierre Ossman authored
      Remove the BYTEBLOCK capability and let the broken hosts fail the
      requests with -EINVAL instead.
      Signed-off-by: default avatarPierre Ossman <drzeus@drzeus.cx>
      255d01af
    • Pierre Ossman's avatar
      mmc: mmc_set_data_timeout() parameter write is redundant · b146d26a
      Pierre Ossman authored
      The write parameter in mmc_set_data_timeout() is redundant as the
      data structure contains information about the direction of the
      transfer.
      Signed-off-by: default avatarPierre Ossman <drzeus@drzeus.cx>
      b146d26a
    • Pierre Ossman's avatar
      mmc: read ext_csd version number · d7604d76
      Pierre Ossman authored
      Make sure we do not try to parse a structure we do not
      understand.
      Signed-off-by: default avatarPierre Ossman <drzeus@drzeus.cx>
      d7604d76
    • Pierre Ossman's avatar
      mmc: improve error code feedback · adf66a0d
      Pierre Ossman authored
      Now that we use "normal" error codes, improve the reporting and response
      to error codes in the core.
      Signed-off-by: default avatarPierre Ossman <drzeus@drzeus.cx>
      adf66a0d
    • Pierre Ossman's avatar
      mmc: remove custom error codes · 17b0429d
      Pierre Ossman authored
      Convert the MMC layer to use standard error codes and not its own,
      incompatible values.
      Signed-off-by: default avatarPierre Ossman <drzeus@drzeus.cx>
      17b0429d
    • Thomas Gleixner's avatar
      clockevents: remove the suspend/resume workaround^Wthinko · b7e113dc
      Thomas Gleixner authored
      In a desparate attempt to fix the suspend/resume problem on Andrews
      VAIO I added a workaround which enforced the broadcast of the oneshot
      timer on resume. This was actually resolving the problem on the VAIO
      but was just a stupid workaround, which was not tackling the root
      cause: the assignement of lower idle C-States in the ACPI processor_idle
      code. The cpuidle patches, which utilize the dynamic tick feature and
      go faster into deeper C-states exposed the problem again. The correct
      solution is the previous patch, which prevents lower C-states across
      the suspend/resume.
      
      Remove the enforcement code, including the conditional broadcast timer
      arming, which helped to pamper over the real problem for quite a time.
      The oneshot broadcast flag for the cpu, which runs the resume code can
      never be set at the time when this code is executed. It only gets set,
      when the CPU is entering a lower idle C-State.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Tested-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Cc: Len Brown <lenb@kernel.org>
      Cc: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      b7e113dc
    • Thomas Gleixner's avatar
      ACPI: disable lower idle C-states across suspend/resume · b04e7bdb
      Thomas Gleixner authored
      device_suspend() calls ACPI suspend functions, which seems to have undesired
      side effects on lower idle C-states. It took me some time to realize that
      especially the VAIO BIOSes (both Andrews jinxed UP and my elfstruck SMP one)
      show this effect. I'm quite sure that other bug reports against suspend/resume
      about turning the system into a brick have the same root cause.
      
      After fishing in the dark for quite some time, I realized that removing the ACPI
      processor module before suspend (this removes the lower C-state functionality)
      made the problem disappear. Interestingly enough the propability of having a
      bricked box is influenced by various factors (interrupts, size of the ram image,
      ...). Even adding a bunch of printks in the wrong places made the problem go
      away. The previous periodic tick implementation simply pampered over the
      problem, which explains why the dyntick / clockevents changes made this more
      prominent.
      
      We avoid complex functionality during the boot process and we have to do the
      same during suspend/resume. It is a similar scenario and equaly fragile.
      
      Add suspend / resume functions to the ACPI processor code and disable the lower
      idle C-states across suspend/resume. Fall back to the default idle
      implementation (halt) instead.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Tested-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Cc: Len Brown <lenb@kernel.org>
      Cc: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      b04e7bdb
  2. 22 Sep, 2007 6 commits
  3. 21 Sep, 2007 8 commits
  4. 20 Sep, 2007 17 commits