Hi John,
Thanks for the suggestion. I tried changing to ".wires=1", but it
again ended in a panic in mmc_omap_irq(), so I must be missing another
piece.
On your other suggestion (off-list) I'm also investigating the CPU
pbias_mmc1 pin which the datasheet errata says should not be
connected. Our board has this connected to VMMC, and I noticed that
this signal is not even listed in the BeagleBoard schematic (implied
NC?).
Thanks,
John
On Wed, Oct 7, 2009 at 10:54 AM, John Rigby <jcrigby@xxxxxxxxx> wrote:
> Your board setup file in arch/arm/mach-omap2/whatever.c should have a
> struct twl4030_hsmmc_info that sets up the platform dependent info
> about your board:
>
> static struct twl4030_hsmmc_info mmc[] = {
> {
> .mmc = 1,
> .wires = 4,
> .gpio_cd = -EINVAL,
> .gpio_wp = -EINVAL,
> },
> {} /* Terminator */
> };
>
> I believe you can set wires to 1 to force it to only use 1 wire.
>
>
> On Tue, Oct 6, 2009 at 3:18 PM, John Faith <jfaith7@xxxxxxxxx> wrote:
>>
>> Hi,
>> I have a prototype board based on the 3530EVM which cannot read its
>> microSD card. I enabled CONFIG_MMC_DEBUG and other printks to the
>> 2.6.29rc3 kernel and can see that info like the transfer rate is
>> coming back but after I reach mmc_set_clock() and setting the bus
>> width, I just get timeouts (output below).
>>
>> Looking at DAT0-3 on a scope, I see activity on DAT0, but the other
>> lines just follow the MMC power, up for ~800ms then off.
>>
>> As an experiment, I tried commenting-out these 2 lines in
>> drivers/mmc/host/omap_hsmmc.c:
>> mmc->caps |= MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED;
>> ...
>> mmc->caps |= MMC_CAP_4_BIT_DATA;
>>
>> in an attempt to use slow, 1-wire transfers, but that got me a panic
>> in mmc_omap_irq().
>>
>> Assuming the hardware is functioning, is there a way to force the SD
>> controller into its simplest/slowest mode to improve my chances of
>> reading the card?
>>
...
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
