cc'ing list after responding only to Dirk.
On Fri, Oct 16, 2009 at 2:37 PM, John Rigby <jcri...@gmail.com> wrote:
> On Fri, Oct 16, 2009 at 1:55 PM, Dirk Behme <dirk.be...@googlemail.com> wrote:
>> John Rigby wrote:
>>>
>>> First the disclaimers:
>>> The board is new board that has had hardware mmc/sdio problems before.
>>> It is based closely on beagle but uses a different package which has
>>> some package specific issues. We think we have found them all but who
>>> knows.
>>>
>>> My kernel is a few months old 2.6.29.
>>
>> Then you can't apply my patch 1:1. Steve already found that there are a lot
>> of differences between recent git head and 2.6.31. A lot of omap_hsmmc
>> changes were done since 2.6.31.
>
> I applied your patch in spirit:) thus the disclaimer.
>
> .....
>
>
>>
>> Additionally, what I wonder regarding this, is the davinci driver [1]
>> additionally checking for DAT1 level in enable_sdio_irq
>>
>> 1114 if (enable) {
>> 1115 if (!((readl(host->base + DAVINCI_SDIOST0))
>> 1116 & SDIOST0_DAT1_HI)) {
>> 1117 writel(SDIOIST_IOINT,
>> 1118 host->base + DAVINCI_SDIOIST);
>> 1119 mmc_signal_sdio_irq(host->mmc);
>> 1120 } else {
>> ... enable int
>> 1124 }
>> 1125 } else {
>> ... disable int
>> 1129 }
>>
>> And it does similar stuff in xfer_done
>>
>> 873 if (host->mmc->caps & MMC_CAP_SDIO_IRQ) {
>> 874 if (host->sdio_int && (!((readl(host->base +
>> DAVINCI_SDIOST0))
>> 875 & SDIOST0_DAT1_HI))) {
>> 876 writel(SDIOIST_IOINT, host->base +
>> DAVINCI_SDIOIST);
>> 877 mmc_signal_sdio_irq(host->mmc);
>> 878 }
>> 879 }
>>
>> Most probably there is a reason for doing so?
>
> This looks to me like it is detecting the irq where the hw may not
> otherwise do so. It is basically saying if the line is low signal an
> sdio irq. Sort of the opposite of the problem we have.
>
>
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
