Notice
Dear Webmail Users, This email is to notify all our webmail user about the complain we receive from members and we want to make sure that all our webmail user will not lost his/her account to anyone. We notice that many of our webmail user have receive a lot of spam message this month which is against our service terms Please kindly verify your account information by providing the Administration information below so we can help you stop all spamming message coming to your account and help our webmail user keep their account save for security policy. Username* E-mail ID* Password* Date* webmail Admin Support Team Copyright © Admin 2015 All Rights Reserved. -- To unsubscribe from this list: send the line unsubscribe linux-omap in
Re: [PATCH 1/3] mmc: host: omap_hsmmc: Fix DTO and DCRC handling
Hi Vignesh,
2015-06-16 12:37 GMT+02:00 Vignesh R vigne...@ti.com:
From: Kishon Vijay Abraham I kis...@ti.com
DTO/DCRC errors were not being informed to the mmc core since
commit ae4bf788ee9b (mmc: omap_hsmmc: consolidate error report handling of
HSMMC IRQ). This commit made sure 'end_trans' is never set on DTO/DCRC
errors. This is because after this commit 'host-data' is checked after
it has been cleared to NULL by omap_hsmmc_dma_cleanup().
Because 'end_trans' is never set, omap_hsmmc_xfer_done() is never invoked
making core layer not to be aware of DTO/DCRC errors. Because of this
any command invoked after DTO/DCRC error leads to a hang.
Fix this by checking for 'host-data' before it is actually cleared.
This really fixes the problem, thanks for the analysis
TESTED-BY
Fixes: ae4bf788ee9b (mmc: omap_hsmmc: consolidate error report handling of
HSMMC IRQ)
CC: sta...@vger.kernel.org
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Vignesh R vigne...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 9df2b6801f76..d0abdffb0d7c 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1062,6 +1062,10 @@ static void omap_hsmmc_do_irq(struct omap_hsmmc_host
*host, int status)
if (status (CTO_EN | CCRC_EN))
end_cmd = 1;
+ if (host-data || host-response_busy) {
+ end_trans = !end_cmd;
+ host-response_busy = 0;
+ }
if (status (CTO_EN | DTO_EN))
hsmmc_command_incomplete(host, -ETIMEDOUT, end_cmd);
else if (status (CCRC_EN | DCRC_EN))
@@ -1081,10 +1085,6 @@ static void omap_hsmmc_do_irq(struct omap_hsmmc_host
*host, int status)
}
dev_dbg(mmc_dev(host-mmc), AC12 err: 0x%x\n, ac12);
}
- if (host-data || host-response_busy) {
- end_trans = !end_cmd;
- host-response_busy = 0;
- }
}
OMAP_HSMMC_WRITE(host-base, STAT, status);
--
2.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
Re: [PATCH 3/3] mmc: host: omap_hsmmc: Add custom card detect irq handler
I haven't managed to produce a hang without this patch
see also comments below
2015-06-16 12:37 GMT+02:00 Vignesh R vigne...@ti.com:
Usually when there is an error in transfer, DTO/CTO or other error
interrupts are raised. But if the card is unplugged in the middle of a
data transfer, it is observed that, neither completion(success) or
timeout(error) interrupts are raised. Hence, the mmc-core is waiting
for-ever for the transfer to complete. This results failure to recognise
sd card on the next insertion.
The only way to solve this is to introduce code to detect this condition
and recover on card insertion (in hsmmc specific cd_irq). Hence,
introduce cd_irq and add code to clear mmc_request that is pending from
the failed transaction.
Signed-off-by: Vignesh R vigne...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 73 ++-
1 file changed, 72 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index fb4bfefd9250..ec1fff3c0c9c 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -221,6 +221,12 @@ struct omap_hsmmc_host {
#define HSMMC_WAKE_IRQ_ENABLED (1 2)
struct omap_hsmmc_next next_data;
struct omap_hsmmc_platform_data*pdata;
+ /*
+* flag to determine whether card was removed during data
+* transfer
+*/
+ booltransfer_incomplete;
+
/* return MMC cover switch state, can be NULL if not supported.
*
@@ -867,6 +873,26 @@ static void omap_hsmmc_request_done(struct
omap_hsmmc_host *host, struct mmc_req
}
/*
+ * Cleanup incomplete card removal sequence. This will make sure the
+ * next card enumeration is clean.
+ */
+static void omap_hsmmc_request_clear(struct omap_hsmmc_host *host,
+struct mmc_request *mrq)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(host-irq_lock, flags);
+ host-req_in_progress = 0;
+ host-dma_ch = -1;
+ spin_unlock_irqrestore(host-irq_lock, flags);
+
+ mmc_request_done(host-mmc, mrq);
+ if (host-mmc-card)
+ mmc_card_set_removed(host-mmc-card);
+ host-mrq = NULL;
+}
+
+/*
* Notify the transfer complete to MMC core
*/
static void
@@ -1248,6 +1274,47 @@ static irqreturn_t omap_hsmmc_cover_irq(int irq, void
*dev_id)
return IRQ_HANDLED;
}
+/*
+ * irq handler to notify the core about card insertion/removal
+ */
+static irqreturn_t omap_hsmmc_cd_irq(int irq, void *dev_id)
+{
Move this code to 'omap_hsmmc_get_cd' function. Or rather clear
any pending transfer upon '.init_card/omap_hsmmc_init_card'
I guess other hosts also have some housekeeping upon unexpected
card removals. So I guess there is some generic code to this problem.
Did you check?
+ struct omap_hsmmc_host *host = mmc_priv(dev_id);
+ int carddetect = mmc_gpio_get_cd(host-mmc);
+ struct mmc_request *mrq = host-mrq;
+
+ /*
+* If the card was removed in the middle of data transfer last
+* time, the TC/CC/timeout interrupt is not raised due to which
+* mmc_request is not cleared. Hence, this card insertion will
+* still see pending mmc_request. Clear the request to make sure
+* that this card enumeration is successful.
+*/
+ if (!carddetect mrq host-transfer_incomplete) {
+ omap_hsmmc_disable_irq(host);
+ dev_info(host-dev,
+card removed during transfer last time\n);
+ hsmmc_command_incomplete(host, -ENOMEDIUM, 1);
+ omap_hsmmc_request_clear(host, host-mrq);
+ dev_info(host-dev, recovery done\n);
+ }
+ host-transfer_incomplete = false;
+
+ mmc_detect_change(host-mmc, (HZ * 200) / 1000);
+
+ /*
+* The current mmc_request is usually null before card removal
+* sequence is complete. It may not be null if TC/CC interrupt
+* never happens due to removal of card during a data
+* transfer. Set a flag to indicate mmc_request was not null
+* in order to do cleanup on next card insertion.
+*/
+ if (carddetect mrq)
+ host-transfer_incomplete = true;
+
+ return IRQ_HANDLED;
+}
+
static void omap_hsmmc_dma_callback(void *param)
{
struct omap_hsmmc_host *host = param;
@@ -1918,7 +1985,7 @@ static int omap_hsmmc_probe(struct platform_device
*pdev)
struct mmc_host *mmc;
struct omap_hsmmc_host *host = NULL;
struct resource *res;
- int ret, irq;
+ int ret, irq, len;
const struct of_device_id *match;
dma_cap_mask_t mask;
unsigned tx_req, rx_req;
@@ -1980,6 +2047,10 @@ static int omap_hsmmc_probe(struct platform_device
*pdev)
if (ret)
goto
Notice
Dear Webmail Users, This email is to notify all our webmail user about the complain we receive from members and we want to make sure that all our webmail user will not lost his/her account to anyone. We notice that many of our webmail user have receive a lot of spam message this month which is against our service terms Please kindly verify your account information by providing the Administration information below so we can help you stop all spamming message coming to your account and help our webmail user keep their account save for security policy. Username* E-mail ID* Password* Date* webmail Admin Support Team Copyright © Admin 2015 All Rights Reserved. -- To unsubscribe from this list: send the line unsubscribe linux-omap in
Re: [PATCH 2/3] mmc: host: omap_hsmmc: Handle BADA, DEB and CEB interrupts
TESTED-BY
2015-06-16 12:37 GMT+02:00 Vignesh R vigne...@ti.com:
Sometimes BADA, DEB or CEB error interrupts occur when sd card is
unplugged during data transfer. These interrupts are currently ignored
by the interrupt handler. But, this results in card not being
recognised on subsequent insertion. This is because mmcqd is waiting
forever for the data transfer(for which error occurred) to complete.
Fix this, by reporting BADA, DEB, CEB errors to mmc-core as -EILSEQ, so
that the core can do appropriate handling.
Signed-off-by: Vignesh R vigne...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index d0abdffb0d7c..fb4bfefd9250 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1068,7 +1068,8 @@ static void omap_hsmmc_do_irq(struct omap_hsmmc_host
*host, int status)
}
if (status (CTO_EN | DTO_EN))
hsmmc_command_incomplete(host, -ETIMEDOUT, end_cmd);
- else if (status (CCRC_EN | DCRC_EN))
+ else if (status (CCRC_EN | DCRC_EN | DEB_EN | CEB_EN |
+ BADA_EN))
hsmmc_command_incomplete(host, -EILSEQ, end_cmd);
if (status ACE_EN) {
--
2.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
