> Hello,
> Could you please post kernel log of such failure?
> What hw are you using?
I'm using sdhci controller. Hynix eMMC4.41. Linux Kernel 3.4.5
There are no kernel log failures as such.
If i add print while sending CMD38 when 'discard' mount option is specified,
then CMD38 with Arg 1 are con
ns. Does TRIM needs some extra
care? BKOPS is not enabled in eMMC (is bkops mandatory if using TRIM?)
Apologies, if this is not proper platform to ask such question. Please guide
and throw some light.
Thanks,
Prasanna NAVARATNA
--
To unsubscribe from this list: send the line "unsubscribe linux
> Did you found time to tide up your patch?
Yes, patch is almost ready. I'm trying to compile and test it once before
submitting. Will post it soon.
Thanks & Regards,
Prasanna NAVARATNA
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body
est kernel.
Need to check on card_busy and utilize it. I will re-work on this patch and
will update a newer version in protocol layer.
Thanks,
Prasanna NAVARATNA
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
egards,
Prasanna NAVARATNA
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello Christian,
> I am looking forward to get my hands on your patch :)
I have submitted the patch to fix "Timeout waiting for hardware interrupt"
faced by me. Please have a look.
The subject of patch is "[PATCH] mmc: sdhci: extend wait for busy signalling"
Regards,
Pras
>From 20efc7e04ebef28c03912824c7edb1bd8f14a20a Mon Sep 17 00:00:00 2001
From: Prasanna NAVARATNA
Date: Tue, 3 Sep 2013 17:31:46 +0530
Subject: [PATCH] mmc: sdhci: extend wait for busy signalling
Certain eMMC features like sanitize, BKOPS, cache, erase etc take
long time (more than max time)
ave it and need to enabled BKOPS for eMMMC4.41?
Is mmc-utils the only way to enable BKOPS?
Regards,
Prasanna NAVARATNA
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello Jaehoon,
> Why do you use MMC_CAP2_BKOPS_EN?
Because BKOPS on eMMC4.41 is optional. So the capability is provided for the
platform to either enable/disable this feature (its not mandatory to always
enable BKOPS on 4.41)
> Maybe we had discussed about this point. i know that we can enable th
>From d596be94f87b86ccb372a4ae55ee478951524895 Mon Sep 17 00:00:00 2001
From: Prasanna NAVARATNA
Date: Fri, 30 Aug 2013 17:18:32 +0530
Subject: [PATCH] mmc: enable BKOPS for supported eMMC(4.41)
BKOPS feature is optional for eMMC 4.41. If an eMMC supports BKOPS
and is of version 4.41 then BK
Hello Christian,
Sorry for the late reply. I had faced the similar problem in the past.
There are certain 4.5 features like BKOPS, Sanitize, cache control operations
which uses CMD6 to trigger the operation and use DAT0 line for busy signalling
which was not monitored for proper completion.
Al
What was the previous command sent before CMD13 when timeout happened?
Can you share some 5 seconds log before the Timeout start happening?
eMMC version being used is 4.41 or 4.5?
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.ker
Ah, yes you are right. Thanks for the feedback.
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
swers?
Regards,
Prasanna NAVARATNA
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
3b3 Mon Sep 17 00:00:00 2001
From: Prasanna NAVARATNA
Date: Mon, 12 Aug 2013 12:26:57 +0530
Subject: [PATCH] mmc: core: add check for card type before
mmc_hw_reset_for_init
During mmc_hw_reset_for_init, the card type is not checked before
calling hw_reset ops.
Add check for the card type as e
cr by querying, as
done during initialization. This results in higher voltage during resume
compared to voltage used during initialization.
To fix this issue, i propose the following patch. Please review :-
>From 305c151cb5b217ff7c622a769df120b14153c25a Mon Sep 17 00:00:00 2001
From: Prasanna NAVARAT
Prasanna NAVARATNA gmail.com> writes:
>
> From f43005e05f1e9d93705ec6b3ab98cfa5215c1896 Mon Sep 17 00:00:00 2001
> From: Prasanna NAVARATNA broadcom.com>
> Date: Thu, 4 Apr 2013 19:55:19 +0530
> Subject: [PATCH] mmc: core: negotiate ocr during resume
>
> Save the ca
” pointer is valid but old card has been replaced with
new card. Your patch will still consider old ocr saved of old card. Right?
I didn't understand, how does your patch works and takes care of this
situation? Please elaborate.
Thanks & Regards,
Prasanna NAVARATNA
--
To unsubscribe fr
accross
sd.c sdio.c and mmc.c
d. ocr field might be helpful in future too. So better to have it rather
than "ocr_bak" in struct mmc_host.
>From ad70dbd00db355d1e8ca08e7ad12e73cb41df960 Mon Sep 17 00:00:00 2001
From: Prasanna NAVARATNA
Date: Thu, 4 Apr 2013 19:55:19 +0530
Subject: [P
ter to have it rather
than "ocr_bak" in struct mmc_host.
>From ad70dbd00db355d1e8ca08e7ad12e73cb41df960 Mon Sep 17 00:00:00 2001
From: Prasanna NAVARATNA
Date: Thu, 4 Apr 2013 19:55:19 +0530
Subject: [PATCH] mmc: core: proper ocr negotiation during resume
Save the card ocr into str
ter to have it rather
than "ocr_bak" in struct mmc_host.
>From ad70dbd00db355d1e8ca08e7ad12e73cb41df960 Mon Sep 17 00:00:00 2001
From: Prasanna NAVARATNA
Date: Thu, 4 Apr 2013 19:55:19 +0530
Subject: [PATCH] mmc: core: proper ocr negotiation during resume
Save the card ocr into str
>From ad70dbd00db355d1e8ca08e7ad12e73cb41df960 Mon Sep 17 00:00:00 2001
From: Prasanna NAVARATNA
Date: Thu, 4 Apr 2013 19:55:19 +0530
Subject: [PATCH] mmc: core: proper ocr negotiation during resume
Save the card ocr into struct mmc_card when read from card
during initialization of sd/mmc/s
egotiate ocr during resume"
This patch will follow the spec and will also negotiate ocr during
mmc_resume_host.
Thanks,
Prasanna NAVARATNA
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Prasanna NAVARATNA gmail.com> writes:
>
> So you agree the ocr mask must not be reset during suspend.
>
> The patch over here exactly addresses the problem which you stated :-
> "mmc core should tell the host driver to use the properly negotiated ocr
> mask to set
>From f43005e05f1e9d93705ec6b3ab98cfa5215c1896 Mon Sep 17 00:00:00 2001
From: Prasanna NAVARATNA
Date: Thu, 4 Apr 2013 19:55:19 +0530
Subject: [PATCH] mmc: core: negotiate ocr during resume
Save the card ocr into struct mmc_card when read from sd card and
negotiate ocr mask dur
es the ocr which is properly negotiated during initialization
time and then restores it back during resume.
Will you please elaborate, what is wrong with this patch? Or are you trying
to tell, this is not the proper way to do the same?
Thanks & Regards,
Prasanna NAVARATNA
--
To unsubscribe
Ulf Hansson linaro.org> writes:
>
> On 4 April 2013 11:44, Prasanna NAVARATNA
gmail.com> wrote:
> > Kevin Liu marvell.com> writes:
> >
> >>
> >> host->ocr has been reset in power off but not restored after power up
> >> in resum
uring suspend, maximum supported voltage from host is saved back and
when resuming back requesting for highest voltage of host (3.3V).
It doesn't care about card's OCR.
This patch fixes it. Looks valid for me.
Thanks & Regards,
Prasanna NAVARATNA
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
28 matches
Mail list logo
