- 23 Sep, 2007 38 commits
-
-
Pierre Ossman authored
SDIO doesn't have a CSD so it uses different timeout values than SD memory. Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
Pierre Ossman authored
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
Pierre Ossman authored
Enable 4-bit data bus mode, according to host and card capabilities. Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
Pierre Ossman authored
Change clock speed to the highest supported by the card. Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
Adrian Bunk authored
On Wed, Jul 25, 2007 at 04:03:04AM -0700, Andrew Morton wrote: >... > Changes since 2.6.22-rc6-mm1: >... > git-mmc.patch >... > git trees >... sdio_dev_attrs[] can become static. Signed-off-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
Nicolas Pitre authored
Signed-off-by: Nicolas Pitre <npitre@mvista.com> Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
Pierre Ossman authored
Support the multi-byte transfer operation, including handlers for common operations like writel()/readl(). Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
Nicolas Pitre authored
This mimics what the serial_core does. Useful for diagnostics. Signed-off-by: Nicolas Pitre <npitre@mvista.com> Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
Nicolas Pitre authored
This currently only accepts the GPS class since that's all I have for testing. Tested with a Matsushita GPS and gpsd version 2.34. Signed-off-by: Nicolas Pitre <npitre@mvista.com> Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
Nicolas Pitre authored
Signed-off-by: Nicolas Pitre <npitre@mvista.com> Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
Nicolas Pitre authored
It is sometimes necessary to give up on trying to claim the host lock, especially if that happens in a thread that has to be stopped. While at it, fix the description for mmc_claim_host() which was wrong. Signed-off-by: Nicolas Pitre <npitre@mvista.com> Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
Nicolas Pitre authored
Signed-off-by: Nicolas Pitre <npitre@mvista.com> Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
Pierre Ossman authored
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
Pierre Ossman authored
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
Pierre Ossman authored
Make the mmc bus uevent callback look like all other subsystems. Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
Pierre Ossman authored
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
Nicolas Pitre authored
The problem is that the sdio_bus must be registered before any SDIO drivers are registered against it otherwise the kernel sulks. Because the sdio_bus registration happens through module_init (equivalent to device_initcall), then any SDIO drivers linked before the SDIO core code in the kernel will be initialized first. Upcoming SDIO function drivers are likely to be located outside the drivers/mmc directory as it is common practice to group drivers according to their function rather than the bus they use. SDIO drivers are therefore likely to appear at random location in the kernel link. To make sure the sdio_bus is always initialized before any SDIO drivers, let's move the MMC init to the subsys_initcall level. Signed-off-by: Nicolas Pitre <npitre@mvista.com> Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
Pierre Ossman authored
Add a more clean separation between global, common CIS information and the function specific one as we need the common information in places where no specific function is specified. Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
Nicolas Pitre authored
This way those tuples that the core cares about are consumed by the core code, and tuples that only function drivers might make sense of are available to drivers. Signed-off-by: Nicolas Pitre <npitre@mvista.com> Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
Nicolas Pitre authored
Signed-off-by: Nicolas Pitre <npitre@mvista.com> Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
Pierre Ossman authored
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
Pierre Ossman authored
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
Pierre Ossman authored
Like many other buses, the devices (functions) on the SDIO bus must be enabled before they can be used. Add functions that allow drivers to do so. Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
Pierre Ossman authored
Add command wrappers that simplify register access from SDIO function drivers. Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
Pierre Ossman authored
Add basic driver handling to the SDIO device model. Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
Pierre Ossman authored
Add the sdio bus type and basic device handling. Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
Pierre Ossman authored
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
Pierre Ossman authored
Really basic init sequence for SDIO cards. Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
Marc Pignat authored
This kind of transfer is not supported, so don't advertise it and make it fail early. Signed-off-by: Marc Pignat <marc.pignat@hevs.ch> Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
Pierre Ossman authored
Some printk:s were missing an explicit level. Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
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: Pierre Ossman <drzeus@drzeus.cx>
-
Pierre Ossman authored
Remove the BYTEBLOCK capability and let the broken hosts fail the requests with -EINVAL instead. Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
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: Pierre Ossman <drzeus@drzeus.cx>
-
Pierre Ossman authored
Make sure we do not try to parse a structure we do not understand. Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
Pierre Ossman authored
Now that we use "normal" error codes, improve the reporting and response to error codes in the core. Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
Pierre Ossman authored
Convert the MMC layer to use standard error codes and not its own, incompatible values. Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
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: Thomas Gleixner <tglx@linutronix.de> Tested-by: Andrew 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: Linus Torvalds <torvalds@linux-foundation.org>
-
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: Thomas Gleixner <tglx@linutronix.de> Tested-by: Andrew 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: Linus Torvalds <torvalds@linux-foundation.org>
-
- 22 Sep, 2007 2 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6Linus Torvalds authored
* 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6: ACPI: suspend: consolidate handling of Sx states addendum ACPI: suspend: consolidate handling of Sx states. ACPI: video: remove dmesg spam ACPI: video: _DOS=0 by default to prevent hotkey hang
-
git://oss.sgi.com:8090/xfs/xfs-2.6Linus Torvalds authored
* 'for-linus' of git://oss.sgi.com:8090/xfs/xfs-2.6: [XFS] fix valid but harmless sparse warning [XFS] fix filestreams on 32-bit boxes
-