Some cards have the CRC errors in read on mx51 BBG board.
Configure the eSDHC pad configurations to level up the
compatibility to fix this issue.
Signed-off-by: Richard Zhu
Tested-by: Shawn Guo
---
arch/arm/plat-mxc/include/mach/iomux-mx51.h | 40 +-
1 files changed, 2
Hi,
On Thu, Mar 10 2011, Tony Olech wrote:
> Add a driver for Elan Digital System's VUB300 chip
> which is a USB connected SDIO/SDmem/MMC host controller.
> A VUB300 chip enables a USB 2.0 or USB 1.1 connected host
> computer to use SDIO/SD/MMC cards without the need for
> a directly connected, fo
On Mar 14, 2011, at 3:18 PM, Arnd Bergmann wrote:
> On Monday 14 March 2011 19:50:27 John Watlington wrote:
>> Cards that are in the state you describe are most likely dead due to
>> running out of spare blocks. There is nothing that can be done to
>> rehabilitate them, even using the manufactu
Hi Chris
On Mon, 14 Mar 2011, Chris Ball wrote:
> Hi Guennadi,
>
> On Fri, Mar 11 2011, Guennadi Liakhovetski wrote:
> > Currently kunmap_atomic() doesn't take into account the offset, used
> > with kmap_atomic(). On platforms, where kunmap_atomic() is not a NOP,
> > this will lead to problems,
Hi Guennadi,
On Fri, Mar 11 2011, Guennadi Liakhovetski wrote:
> Currently kunmap_atomic() doesn't take into account the offset, used
> with kmap_atomic(). On platforms, where kunmap_atomic() is not a NOP,
> this will lead to problems, when offset != 0.
>
> Signed-off-by: Guennadi Liakhovetski
>
On Monday 14 March 2011 19:50:27 John Watlington wrote:
> Cards that are in the state you describe are most likely dead due to
> running out of spare blocks. There is nothing that can be done to
> rehabilitate them, even using the manufacturer's secret code.
> In a disturbing trend, most of the c
On Mar 13, 2011, at 6:34 PM, Mikus Grinbergs wrote:
>> The tests have also helped expose other issues with things like sudden
>> power off. In one case a SPO during a write would corrupt the card so
>> badly it became useless. You could only recover them via a super secret
>> tool from the m
On Sunday 13 March 2011, Richard A. Smith wrote:
> On 03/13/2011 01:21 PM, Arnd Bergmann wrote:
> There's a 2nd round of test(s) that runs during the manufacturing and
> burn-in phases. One is a simple firmware test to see if you can talk the
> card at all and then one runs at burn in. It doesn'
> > > intmask)
> > >* boundaries, but as we can't disable the feature
> > > * we need to at least restart the transfer.
> > > */
> > > - if (intmask & SDHCI_INT_DMA_END)
> > > - sdhci_writel(host, sdhci_readl(host, SDHCI_DMA_ADDRESS),
> > > -
Hi,
> Then we'll have a "useless" update. Won't hurt AFAICS, but might
> surprise people examining the debug output.
Ok.
> > I only compile tested this so far, so no proper patch yet, but what I would
> > write based on the comments is something like this:
>
> (Sidenote: Indentation is bro
> > I was just referring to using "" instead of "@". The provider
> > doesn't really matter :)
>
> Ah, ok. Yahoo makes it practically impossible to send well-formed
> patches from the web interface, but as long as it's not completely
> rejected for casual email, I prefer to keep the number of s
The MMC_SDHCI based driver is either based on MMC_SDHCI_PLTFM or
MMC_SDHCI_OF. As both parent CONFIG are 'tristate', it may make
sense to get all children drivers CONFIG as 'tristate'.
Signed-off-by: Shawn Guo
---
drivers/mmc/host/Kconfig | 10 +-
1 files changed, 5 insertions(+), 5 d
On 03/13/2011 06:34 PM, Mikus Grinbergs wrote:
The tests have also helped expose other issues with things like sudden
power off. In one case a SPO during a write would corrupt the card so
badly it became useless. You could only recover them via a super secret
tool from the manufacturer.
Is th
On Sunday 13 March 2011, Mikus Grinbergs wrote:
> > The tests have also helped expose other issues with things like sudden
> > power off. In one case a SPO during a write would corrupt the card so
> > badly it became useless. You could only recover them via a super secret
> > tool from the man
Wolfram Sang wrote:
> > > > Signed-off-by: Mikko Vinni yahoo.com>
> > >
> > > Proper EMail please.
> >
> > Hm, @gmail.com? (cc added for further emails)
>
> I was just referring to using "" instead of "@". The provider
> doesn't really matter :)
Ah, ok. Yahoo makes it practically impossi
> > But we can't guarantee that. Transfer could be up to 65535 * 2K.
>
> In sdhci.c function sdhci_prepare_data there are these checks:
>
> /* Sanity checks */
> BUG_ON(data->blksz * data->blocks > 524288);
> BUG_ON(data->blksz > host->mmc->max_blk_size);
> BUG_ON(data->blocks >
Hi,
Wolfram Sang wrote:
> I finally found some time.
Greatly appreciated.
> > Some SD host controllers (noticed on an integrated JMicron SD reader
> > on an HP Pavilion dv5-1250eo laptop) don't update the dma address
> > register before signaling a dma interrupt due to a dma boundary.
> > D
On Sun, 13 Mar 2011, Magnus Damm wrote:
> On Fri, Mar 11, 2011 at 4:52 PM, Guennadi Liakhovetski
> wrote:
> > On sh-mobile platforms the SDHI driver was using the tmio_mmc SD/SDIO
> > MFD cell driver. Now that the tmio_mmc driver has been split into a
> > core and a separate MFD glue, we can supp
...unrelated to comments by Magnus, I noticed, that titles and commit
messages to two patches from this series contain references to mn57xx,
which shouldn't be there. I'll have to resumbit them without those
references.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Soft
On Sun, Mar 13, 2011 at 9:54 AM, Arnd Bergmann wrote:
> On Sunday 13 March 2011 14:00:04 Andrei Warkentin wrote:
>> > If the latter two are not much different on the toshiba card, that
>> > would be a simpler implementation, and more likely to be useful on
>> > other cards.
>> >
>>
>> Revalidating
On Sun, 13 Mar 2011, Magnus Damm wrote:
> On Sun, Mar 13, 2011 at 7:57 AM, Guennadi Liakhovetski
> wrote:
> > On Sun, 13 Mar 2011, Magnus Damm wrote:
> >
> >> On Fri, Mar 11, 2011 at 5:09 PM, Guennadi Liakhovetski
> >> wrote:
> >> > Not all mn57xx / tmio implementations have registers above oxff
21 matches
Mail list logo
