Corrects a bug in MMCI host driver which silently causes
small reads ( 4 bytes as only used in SDIO) from PL-18X to fail.
Signed-off-by: Stefan Nilsson XK stefan.xk.nils...@stericsson.com
Signed-off-by: Ulf Hansson ulf.hans...@stericsson.com
Acked-by: Linus Walleij linus.wall...@linaro.org
---
This patch allows any block size to be set on the SDIO link,
and still have an arbitrary sized packet (adjusted in size by
using sdio_align_size) transferred in an optimal way
(preferably one transfer).
Previously if the block size was larger than the default of
512 bytes and the transfer size
Hello Adrian
On 10/25/2011 10:40 AM, Adrian Hunter wrote:
On 21/10/11 11:16, Giuseppe CAVALLARO wrote:
This patch is to expose the actual SDCLK frequency in
/sys/kernel/debug/mmcX/ios entry.
For example, if the max clk for a normal speed card is 20MHz
this is reported in
On 10/25/2011 1:43 PM, Sebastian Rasmussen wrote:
This patch enhances the debug information reported
for the mmc card by parsing the extended CSD registers
obviously according to all the current specifications.
Does this belong kernel or in userspace? I'm not sure, and
I'm hoping that any
Hi Girish,
On Wed, Oct 26 2011, Girish K S wrote:
This patch adds the support of the HS200 bus speed for eMMC 4.5 devices.
The eMMC 4.5 devices have support for 200MHz bus speed.The mmc core and
host modules have been touched to add support for this module.
It is necessary to know the card
Hi Rajeshwari, Kukjin,
On Fri, Oct 14 2011, Rajeshwari Shinde wrote:
This patch modifies the driver to stop depending on the clock names
being passed from the platform and switch over to bus clock lookup
using generic clock names.
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Stephen,
The mmc-next tree has returned to its original location at:
git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc.git mmc-next
Thanks very much,
Chris.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
sdhci_set_clock or sdhci_reset or sdhci_send_command may be used in
critical region which is protected by spin_lock_irqsave. Thus, these
functions will delay the responsing of the kernel interrupts.
So in this case, using a mdelay will cause unnecessary latency. Our
hardware, in most case will
2011/10/27 Shawn.Dong shawn.dong...@gmail.com:
sdhci_set_clock or sdhci_reset or sdhci_send_command may be used in
critical region which is protected by spin_lock_irqsave. Thus, these
functions will delay the responsing of the kernel interrupts.
So in this case, using a mdelay will cause
Hi,
On Thu, Oct 27, 2011 at 12:18:53PM +0800, Shawn.Dong wrote:
sdhci_set_clock or sdhci_reset or sdhci_send_command may be used in
critical region which is protected by spin_lock_irqsave. Thus, these
functions will delay the responsing of the kernel interrupts.
Yes, so this needs to be
On Thu, Oct 27, 2011 at 07:15:32AM +0200, Wolfram Sang wrote:
Hi,
On Thu, Oct 27, 2011 at 12:18:53PM +0800, Shawn.Dong wrote:
sdhci_set_clock or sdhci_reset or sdhci_send_command may be used in
critical region which is protected by spin_lock_irqsave. Thus, these
functions will delay the
11 matches
Mail list logo
