* Lin Tony-B19295 [110901 07:31]:
> I commit a patch to fix this issue. Did you update your code?
Sorry for my stupid question but where did you commit that patch?
/PH
--
Per-Henrik Lundblom epost: p...@whatever.nu
hemsida: www.whatever.nu
--
To unsubscribe from this list: send the
Hello Mr Jeon,
In case if the timeout is specified by the
calling function, the code in this patch will not be executed. But if
some command other than the three are called with 0, then this code
will make sure that atleast the default value is used to timeout.
regards
Girish
Hi Girish,
Girish K S wrote:
>
> V2- The datatype of the cmd6_timeout is changed from u8 to unsigned int,
> as it can hold a value upto 255*10=2550.
> This patch adds the code to handle the default timeout
> for switch command.
> For eMMC 4.5 devices if timeout is not specified for the swit
In the eMMC 4.5 specification the EC_ERASE_MULT and
SEC_TRIM_MULT have become obselete and donot carry
any valid information.
This patch makes sure that the above mentioned
parameters are used only for versions below eMMC 4.5.
All the versions above 4.5 will ignore their usage by
assuming t
V2- The datatype of the cmd6_timeout is changed from u8 to unsigned int,
as it can hold a value upto 255*10=2550 and the data assignment in
mmc_switch function.
This patch adds the code to handle the default timeout
for switch command.
For eMMC 4.5 devices if timeout is not specified for th
On Thu, Sep 01, 2011 at 01:51:15PM +0800, Tony Lin wrote:
> 1ms is enough for hardware to change the clock to stable.
> 100ms is too long.
How do you know that? Can you be sure for PowerPC as well? Have you researched
why the original author of the code has chosen that value? If so, please update
1ms is enough for hardware to change the clock to stable.
100ms is too long.
Signed-off-by: Tony Lin
---
drivers/mmc/host/sdhci-esdhc.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/host/sdhci-esdhc.h b/drivers/mmc/host/sdhci-esdhc.h
index c3b08f1..b97b2f5
I commit a patch to fix this issue. Did you update your code?
> -Original Message-
> From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
> ow...@vger.kernel.org] On Behalf Of Per-Henrik Lundblom
> Sent: Thursday, September 01, 2011 12:34 AM
> To: linux-mmc@vger.kernel.org
> Subject:
V2- The datatype of the cmd6_timeout is changed from u8 to unsigned int,
as it can hold a value upto 255*10=2550.
This patch adds the code to handle the default timeout
for switch command.
For eMMC 4.5 devices if timeout is not specified for the switch
command while accessing a specific fie
Hello Mr Kukjin,
I checked this link
"http://www.spinics.net/lists/linux-mmc/msg09770.html";
given by you,but this link has the patch only to extract the timeout
value from the
extended CSD register of the eMMC 4.5 device. Whereas if you review my patch
you can actually see the implementa
On Aug 26, 2011, at 2:55 AM, Chunhe Lan wrote:
> The mmc_delay() is a wrapper function for mdelay() and msleep().
>
>o mdelay() -- block the system when busy-waiting.
>o msleep() -- suspend the currently running task to enable CPU
> to process other tasks, so it is non-b
Girish K S wrote:
>
> This patch adds the code to handle the default timeout
> for switch command.
> For eMMC 4.5 devices if timeout is not specified for the switch
> command while accessing a specific field,then the default timeout
> shall be used to timeout. Specification says there is no timeou
On Wed, Aug 31, 2011 at 10:06 PM, Eric Miao wrote:
> Zhangfei,
>
> My understanding is that the card in the slot would be either MMC _or_
> SDIO and why do we need another regulator for the power on/off?
>
Hi, Eric
vsdio is used for dynamically power control to sdio, for example
application dynam
Stephen Warren wrote at Tuesday, August 30, 2011 1:17 PM:
> For Seaboard's internal eMMC, this makes the difference between a
> 5.5MB/s and 10.2MB/s transfer rate. On Harmony, there wasn't any
> measurable difference on my cheap/slow ~2MB/s card.
>
> Signed-off-by: Stephen Warren
Grant, when app
* Robert Schwebel [110831 17:50]:
> > I'm working with a driver for an SDIO Wireless LAN card and just tried
> > it out on an i.MX35 based development board (Phytec PCM-043). My
> > impression is that the sdhci-esdhc-imx driver doesn't support SDIO
> > interrupts, is that correct?
>
> I think we
On Wed, Aug 31, 2011 at 02:09:12PM +0200, Per-Henrik Lundblom wrote:
> I'm working with a driver for an SDIO Wireless LAN card and just tried
> it out on an i.MX35 based development board (Phytec PCM-043). My
> impression is that the sdhci-esdhc-imx driver doesn't support SDIO
> interrupts, is that
Zhangfei,
My understanding is that the card in the slot would be either MMC _or_
SDIO and why do we need another regulator for the power on/off?
On Thu, Aug 25, 2011 at 2:26 PM, Zhangfei Gao wrote:
> sdio client may be required power on/off dynamically.
> With regulator vsdio, sdio client power
Hi,
I'm working with a driver for an SDIO Wireless LAN card and just tried
it out on an i.MX35 based development board (Phytec PCM-043). My
impression is that the sdhci-esdhc-imx driver doesn't support SDIO
interrupts, is that correct?
Regards,
PH
--
Per-Henrik Lundblom epost: p...@w
18 matches
Mail list logo
