Simplify the driver by removing the possibility to build it without the DMA
support and remove the respective Kconfig parameter.
Signed-off-by: Guennadi Liakhovetski
---
drivers/mmc/host/Kconfig|6 --
drivers/mmc/host/sh_mmcif.c | 20
2 files changed, 0 inserti
>> Another question is why to call pm_runtime_get/put when ios-clock changes?
>Is it based on
>> Linus Walleij's aggressive clock gating framework patch? Linus' patch doesn't
>gate SDIO cards.
>runtime_suspend of sdhci should *not* gate the sdio card. It should
>only gate the sdhci.
>An sdio bus in
On Tue, Dec 28, 2010 at 11:46 PM, Alan Stern wrote:
> What's the relation between mmc_power_off() and mmc_power_save_host()?
Essentially they are the same - mmc_power_off() is the one that
actually powers off the card.
mmc_power_save_host() just invokes first a bus-specific ->power_save()
handle
Hi Ian
There are a number of outstanding tmio-mmc patches from Arnd Hannemann and
myself, many of them posted weeks ago. We really would like to have them
in 2.6.38. Would you have time to process them? Otherwise, could someone
else maybe apply them? Listed in the order, in which they should be
This patch enables the interrupt generation for SDIO IRQs
of the sdhi controllers of the SoC. To make sure SDIO IRQs
are used announce the MMC_CAP_SDIO_IRQ capability
on ap325rxa.
Signed-off-by: Arnd Hannemann
Acked-by: Magnus Damm
---
arch/sh/boards/mach-ap325rxa/setup.c | 16 +
This patch enables the interrupt generation for SDIO IRQs
of the sdhi controllers of the SoC. To make sure interrupt
are handled announce the MMC_CAP_SDIO_IRQ capability
on ecovec, kfr2r09 and se7724.
Tested with a b43-based SDIO wireless card on ecovec.
Signed-off-by: Arnd Hannemann
---
Changes
This patch enables the interrupt generation for SDIO IRQs
of the sdhi controllers of the SoC. To make sure interrupts
are handled announce the MMC_CAP_SDIO_IRQ capability
on AP4EVB. Tested with a b43-based SDIO wireless card.
Signed-off-by: Arnd Hannemann
---
arch/arm/mach-shmobile/board-ap4evb.
This patch enables the interrupt generation for SDIO IRQs
of the sdhi controllers of the SoC. To make sure SDIO IRQs
are used, announce the MMC_CAP_SDIO_IRQ capability
on migor.
Signed-off-by: Arnd Hannemann
---
Changes in v3:
- Added missing include to migor.
arch/sh/boards/mach-migor/setup.c
This patch implements SDIO IRQ support for mfds which
announce the TMIO_MMC_SDIO_IRQ flag for tmio_mmc.
If MMC_CAP_SDIO_IRQ is also set SDIO IRQ signalling is activated.
Tested with a b43-based wireless SDIO card and sh_mobile_sdhi.
Signed-off-by: Arnd Hannemann
---
Changes in v3:
- Fix bug whic
The SDHI Controller on SH-Mobile SoCs supports SDIO IRQ signalling.
This patch advertises this fact to the tmio_mmc driver.
Signed-off-by: Arnd Hannemann
Acked-by: Samuel Ortiz
---
drivers/mfd/sh_mobile_sdhi.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/
[PATCH 1/6 v3] mmc: tmio: implement SDIO IRQ
[PATCH 2/6 v3] mfd: sh_mobile_sdhi: activate SDIO IRQ for tmio_mmc
[PATCH 3/6 v3] ARM: mach-shmobile: sh7372 Enable SDIO IRQs
[PATCH 4/6 v3] sh: sh7724 Enable SDIO IRQs
[PATCH 5/6 v3] sh: sh7722 Enable SDIO IRQs
[PATCH 6/6 v3] sh: sh7723 / ap325rxa enabl
On Tue, 28 Dec 2010, Ohad Ben-Cohen wrote:
> On Sun, Dec 26, 2010 at 7:00 PM, Alan Stern wrote:
> > Hmm. It's a little difficult to untangle the web of dev_pm_ops
> > pointers and other stuff.
>
> Yeah, SDIO suspend/resume is very different from other subsystems.
>
> There are several layers o
On Tue, Dec 28, 2010 at 10:04 PM, Rafael J. Wysocki wrote:
> On Tuesday, December 28, 2010, Ohad Ben-Cohen wrote:
>> On Sun, Dec 26, 2010 at 8:37 PM, Rafael J. Wysocki wrote:
>> > So, it only happens during asynchronous suspend? In other words, if
>> > suspend
>> > is synchronous, everything sh
On Tuesday, December 28, 2010, Ohad Ben-Cohen wrote:
> On Tue, Dec 28, 2010 at 9:21 PM, Rafael J. Wysocki wrote:
> > It looks like you could simply do a power down-power up cycle before trying
> > to
> > load new firmware, just in case. I guess that's suboptimal for some reason?
>
> It would wo
On Tuesday, December 28, 2010, Ohad Ben-Cohen wrote:
> On Sun, Dec 26, 2010 at 8:37 PM, Rafael J. Wysocki wrote:
> > So, it only happens during asynchronous suspend? In other words, if suspend
> > is synchronous, everything should be fine, right?
>
> Not necessarily.
So it's not a race after al
On Tue, Dec 28, 2010 at 9:21 PM, Rafael J. Wysocki wrote:
> It looks like you could simply do a power down-power up cycle before trying to
> load new firmware, just in case. I guess that's suboptimal for some reason?
It would work, but we will not be able to unconditionally disable the
radios (e
On Tuesday, December 28, 2010, Ohad Ben-Cohen wrote:
> On Sun, Dec 26, 2010 at 8:35 PM, Rafael J. Wysocki wrote:
> > On Sunday, December 26, 2010, Ohad Ben-Cohen wrote:
> >> On Sun, Dec 26, 2010 at 1:45 PM, Rafael J. Wysocki wrote:
> >> > Why does the driver need the device to be reset even thoug
On Sun, Dec 26, 2010 at 8:37 PM, Rafael J. Wysocki wrote:
> So, it only happens during asynchronous suspend? In other words, if suspend
> is synchronous, everything should be fine, right?
Not necessarily.
Consider this simple scenario, where a device was added after the mmc
host controller, but
On Sun, Dec 26, 2010 at 8:35 PM, Rafael J. Wysocki wrote:
> On Sunday, December 26, 2010, Ohad Ben-Cohen wrote:
>> On Sun, Dec 26, 2010 at 1:45 PM, Rafael J. Wysocki wrote:
>> > Why does the driver need the device to be reset even though it hasn't
>> > been suspeneded yet?
>>
>> Because it is ask
On Sun, Dec 26, 2010 at 7:00 PM, Alan Stern wrote:
> Hmm. It's a little difficult to untangle the web of dev_pm_ops
> pointers and other stuff.
Yeah, SDIO suspend/resume is very different from other subsystems.
There are several layers of abstractions involved, from the host
controller driver,
I'm working with a eMMC device that broke after this commit:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=88ae8b86648
The older hack I'd been given hard-coded the initialisation frequency
at 200kHz (instead of 400kHz in the original upstream) and works fine.
But th
On Mon, Aug 30, 2010 at 11:49:08AM -0600, Grant Likely wrote:
> On Mon, Aug 30, 2010 at 10:38 AM, David Brownell wrote:
> > Since I don't do OpenFirmware, let's hear from
> > Grant on this one.
>
> Looks good to me.
>
> Acked-by: Grant Likely
I wonder what happened with this patch?
Thanks,
-
Hi Arnd,
On Tue, Dec 28, 2010 at 4:03 PM, Arnd Hannemann wrote:
>> Do you mean that your card is always powered on regardless of
>> mmc_power_off() invocations ?
>
> Yes, it seems so.
Ok, thanks for letting us know.
It bothered me that we didn't understand the issue you had, but now it
seems th
Hi Ohad,
Am 28.12.2010 13:45, schrieb Ohad Ben-Cohen:
> On Tue, Dec 28, 2010 at 1:25 PM, Arnd Hannemann wrote:
>> On some boards card power is hard wired to the slot
>> and active regardless of host controller state.
> ...
>> This was observed on AP4EVB with tmio_mmc and a b43 based
>> SDIO card:
On Tue, Dec 28, 2010 at 1:25 PM, Arnd Hannemann wrote:
> On some boards card power is hard wired to the slot
> and active regardless of host controller state.
...
> This was observed on AP4EVB with tmio_mmc and a b43 based
> SDIO card:
> http://marc.info/?l=linux-mmc&m=128854536521274&w=2
Do you
On some boards card power is hard wired to the slot
and active regardless of host controller state.
When runtime PM suspends such a host, certain cards
may keep their current configuration (e.g. bus width),
now when runtime PM resumes the host, communication
with the card will fail.
This was observ
Hi Arnd,
On Thu, Dec 23, 2010 at 7:45 PM, Arnd Hannemann wrote:
> This patch enables the interrupt generation for SDIO IRQs
> of the sdhi controllers of the SoC. To make sure SDIO IRQs
> are used announce the MMC_CAP_SDIO_IRQ capability
> on ap325rxa. Untested, therefore RFC.
>
> Signed-off-by: A
On Wed, Dec 22, 2010 at 3:59 AM, Takashi Iwai wrote:
> At Tue, 21 Dec 2010 22:56:32 -0500,
> zhangfei gao wrote:
>>
>> On Tue, Dec 21, 2010 at 11:36 AM, Philip Rakity wrote:
>> >
>> >
>> > Can you please try this diff and see if it works for you.
>> >
>> > Will do formal patch after your testing.
28 matches
Mail list logo
