From: Jerry Huang
Add callback function to check if the card has been removed.
in order to check if the card has been removed, the function mmc_send_status
will send commad CMD13 to card and ask the card to send its status register to
driver, which will generate interrupt repeatly and make the
From: Jerry Huang
Add callback function sdhci_get_cd to detect the card.
In order to check if the card is present, we will read the PRESENT STATE
register and check the bit13 (Card detect pin level).
Signed-off-by: Jerry Huang
---
drivers/mmc/host/sdhci.c | 19 +++
drivers/
From: Jerry Huang
power on before detecting card.
The driver will not get the right status when using the callback function
'get_cd' to check if the card is present because the power is not on.
Therefore, the controller must be power on before detecting the card status.
Signed-off-by: Jerry Hu
The following patch is to detect if the card has been removed or the card is
present through the callback 'get_cd', which will reduce many interrupt to
check the SD/MMC/ card.
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel
The patch titled
blackfin-sd-host-controller-driver-fix-fix-fix
has been added to the -mm tree. Its filename is
blackfin-sd-host-controller-driver-fix-fix-fix.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing
On Wed, Nov 25, 2009 at 17:04, Andrew Morton wrote:
> --- a/drivers/mmc/host/bfin_sdh.c~blackfin-sd-host-controller-driver-fix
> +++ a/drivers/mmc/host/bfin_sdh.c
> @@ -149,15 +149,17 @@ static int sdh_setup_data(struct sdh_hos
> sdh_enable_stat_irq(host, (DAT_CRC_FAIL | DAT_TIME_OUT | DAT_E
On Thu, Nov 26, 2009 at 03:48:17PM +0900, Jassi Brar wrote:
> We need a way to pass controller specific information to the
> SPI device driver. For that purpose a new header is made.
>
> Signed-off-by: Jassi Brar
> ---
> arch/arm/plat-s3c64xx/include/plat/spi.h | 68
>
Daniel Mack wrote:
On Thu, Dec 03, 2009 at 04:27:39PM +0200, Adrian Hunter wrote:
gDaniel Mack wrote:
[...]
drivers/mmc/core/core.c | 36
drivers/mmc/core/host.c |3 +++
drivers/mmc/host/mmci.c | 28
drivers/mmc/hos
On Thu, Dec 03, 2009 at 04:27:39PM +0200, Adrian Hunter wrote:
> gDaniel Mack wrote:
[...]
> > drivers/mmc/core/core.c | 36
> > drivers/mmc/core/host.c |3 +++
> > drivers/mmc/host/mmci.c | 28
> > drivers/mmc/host/mmci
On Thu, Dec 03, 2009 at 02:58:25PM +, Russell King - ARM Linux wrote:
> On Thu, Dec 03, 2009 at 01:22:41PM +, Mark Brown wrote:
> > without power control). This goes back to the thing about using
> > regulator_get_exclusive(), the message given was that the MMC drivers
> > really needed t
On Thu, Dec 03, 2009 at 01:22:41PM +, Mark Brown wrote:
> On Thu, Dec 03, 2009 at 02:14:23PM +0100, Daniel Mack wrote:
> > I would expect the power to be killed when the last user stops using it.
> > Which should result in the same effect if you only have one host, one
> > regulator, and one us
gDaniel Mack wrote:
At the moment, regulator operations are done from individual mmc host
drivers. This is a problem because the regulators are not claimed
exclusively but the mmc core enables and disables them according to the
return value of regulator_is_enabled(). That can lead to a number of
On Thu, Dec 03, 2009 at 01:40:32PM +, Mark Brown wrote:
> On Thu, Dec 03, 2009 at 02:32:00PM +0100, Daniel Mack wrote:
[...]
> > The mmci people would need to answer that. To me, the code just looked
> > like a power saving feature.
>
> > If this driver needs it, the only tweak to my patch t
On Thu, Dec 03, 2009 at 02:32:00PM +0100, Daniel Mack wrote:
> On Thu, Dec 03, 2009 at 01:22:41PM +, Mark Brown wrote:
> > On Thu, Dec 03, 2009 at 02:14:23PM +0100, Daniel Mack wrote:
> > > I would expect the power to be killed when the last user stops using it.
> > > Which should result in th
On Thu, Dec 03, 2009 at 01:22:41PM +, Mark Brown wrote:
> On Thu, Dec 03, 2009 at 02:14:23PM +0100, Daniel Mack wrote:
[...]
> > I would expect the power to be killed when the last user stops using it.
> > Which should result in the same effect if you only have one host, one
> > regulator, an
On Thu, Dec 03, 2009 at 02:14:23PM +0100, Daniel Mack wrote:
> On Thu, Dec 03, 2009 at 01:06:27PM +, Mark Brown wrote:
> > This is historical, they can all be converted to regulator_get_exclusive()
> > so the move to the core (while good) isn't required for this reason.
> Is it? What if you s
On Thu, Dec 03, 2009 at 01:06:27PM +, Mark Brown wrote:
> On Thu, Dec 03, 2009 at 01:46:30PM +0100, Daniel Mack wrote:
> > At the moment, regulator operations are done from individual mmc host
> > drivers. This is a problem because the regulators are not claimed
> > exclusively but the mmc core
On Thu, Dec 03, 2009 at 01:46:30PM +0100, Daniel Mack wrote:
> At the moment, regulator operations are done from individual mmc host
> drivers. This is a problem because the regulators are not claimed
> exclusively but the mmc core enables and disables them according to the
This is historical, the
At the moment, regulator operations are done from individual mmc host
drivers. This is a problem because the regulators are not claimed
exclusively but the mmc core enables and disables them according to the
return value of regulator_is_enabled(). That can lead to a number of
problems and warnings
19 matches
Mail list logo
