Hi Benoit,
On Fri, Sep 3, 2010 at 1:51 PM, kishore kadiyala
<kishorek.kadiyala@xxxxxxxxx> wrote:
> Hi Benoit
>
> <snip>
>
>>> + while (!(omap_readl(base + reg_off)&
>>> MMCHS_SYSSTATUS_RESETDONE))
>>> cpu_relax();
>>
>> Why does that series not seems to be based on your hwmod migration? The
>> reset is fully handle by the hwmod framework now.
>
> Agree. But Kevin has suggested to post this patch independent of hwmod.
> Does this patch has to go in hwmod series ?
>
>>
>> BTW, when do you have to apply a reset in your case? Do you have the need
>> for an API accessible by the driver?
>> I'm asking because for the moment the framework does not expose the reset
>> API and use it only at init time.
>
> Correct , I don't need reset API access in the driver.
One correction here , in case of context restore , driver does
software reset apart from
the initial reset. So reset is required and so both the tables needs
registers SYSCONFIG and
SYSSTATUS. In which case offset deviation of 0x100 can't be maintained.
Regards,
Kishore
>
> <snip>
>
>>>
>>> +enum {
>>> + OMAP_HSMMC_SYSCONFIG = 0,
>>> + OMAP_HSMMC_SYSSTATUS,
>>> + OMAP_HSMMC_CON,
>>> + OMAP_HSMMC_BLK,
>>> + OMAP_HSMMC_ARG,
>>> + OMAP_HSMMC_CMD,
>>> + OMAP_HSMMC_RSP10,
>>> + OMAP_HSMMC_RSP32,
>>> + OMAP_HSMMC_RSP54,
>>> + OMAP_HSMMC_RSP76,
>>> + OMAP_HSMMC_DATA,
>>> + OMAP_HSMMC_PSTATE,
>>> + OMAP_HSMMC_HCTL,
>>> + OMAP_HSMMC_SYSCTL,
>>> + OMAP_HSMMC_STAT,
>>> + OMAP_HSMMC_IE,
>>> + OMAP_HSMMC_ISE,
>>> + OMAP_HSMMC_CAPA,
>>> + OMAP_HSMMC_REV,
>>> + OMAP_HSMMC_CUR_CAPA,
>>> + OMAP_HSMMC_FE,
>>> + OMAP_HSMMC_ADMA_ES,
>>> + OMAP_HSMMC_ADMA_SAL,
>>> +};
>>> +
>>> +static const u16 omap3_mmc_reg_map[] = {
>>> + [OMAP_HSMMC_SYSCONFIG] = 0x0010,
>>> + [OMAP_HSMMC_SYSSTATUS] = 0x0014,
>>> + [OMAP_HSMMC_CON] = 0x002C,
>>> + [OMAP_HSMMC_BLK] = 0x0104,
>>> + [OMAP_HSMMC_ARG] = 0x0108,
>>> + [OMAP_HSMMC_CMD] = 0x010C,
>>> + [OMAP_HSMMC_RSP10] = 0x0110,
>>> + [OMAP_HSMMC_RSP32] = 0x0114,
>>> + [OMAP_HSMMC_RSP54] = 0x0118,
>>> + [OMAP_HSMMC_RSP76] = 0x011C,
>>> + [OMAP_HSMMC_DATA] = 0x0120,
>>> + [OMAP_HSMMC_PSTATE] = 0x0124,
>>> + [OMAP_HSMMC_HCTL] = 0x0128,
>>> + [OMAP_HSMMC_SYSCTL] = 0x012C,
>>> + [OMAP_HSMMC_STAT] = 0x0130,
>>> + [OMAP_HSMMC_IE] = 0x0134,
>>> + [OMAP_HSMMC_ISE] = 0x0138,
>>> + [OMAP_HSMMC_CAPA] = 0x0140,
>>> + [OMAP_HSMMC_REV] = 0x01FC,
>>> +};
>>> +
>>> +static const u16 omap4_mmc_reg_map[] = {
>>> + [OMAP_HSMMC_SYSCONFIG] = 0x0010, /* Use Highlander Version
>>> */
>>> + [OMAP_HSMMC_SYSSTATUS] = 0x0114,
>>
>> In fact that sysstatus is a legacy register that is not needed anymore in
>> the highlander version. The resetdone is in the sysconfig now.
>> So you can ignore it in OMAP4.
>
> Just verified and thanks for pointing this.
> ok will avoid checking resetdone in sysstatus for OMAP4
>
>>
>>> + [OMAP_HSMMC_CON] = 0x012C,
>>> + [OMAP_HSMMC_BLK] = 0x0204,
>>> + [OMAP_HSMMC_ARG] = 0x0208,
>>> + [OMAP_HSMMC_CMD] = 0x020C,
>>> + [OMAP_HSMMC_RSP10] = 0x0210,
>>> + [OMAP_HSMMC_RSP32] = 0x0214,
>>> + [OMAP_HSMMC_RSP54] = 0x0218,
>>> + [OMAP_HSMMC_RSP76] = 0x021C,
>>> + [OMAP_HSMMC_DATA] = 0x0220,
>>> + [OMAP_HSMMC_PSTATE] = 0x0224,
>>> + [OMAP_HSMMC_HCTL] = 0x0228,
>>> + [OMAP_HSMMC_SYSCTL] = 0x022C,
>>> + [OMAP_HSMMC_STAT] = 0x0230,
>>> + [OMAP_HSMMC_IE] = 0x0234,
>>> + [OMAP_HSMMC_ISE] = 0x0238,
>>> + [OMAP_HSMMC_CAPA] = 0x0240,
>>> + [OMAP_HSMMC_REV] = 0x0000, /* Use Highlander Version */
>>> + [OMAP_HSMMC_CUR_CAPA] = 0x0248,
>>> + [OMAP_HSMMC_FE] = 0x0250,
>>> + [OMAP_HSMMC_ADMA_ES] = 0x0254,
>>> + [OMAP_HSMMC_ADMA_SAL] = 0x0258,
>>
>> I didn't check all the registers, but it seems that there is a constant
>> 0x100 offset for most of these registers. Cannot you simplify this table?
>
> Sure will simplify and post.
>
>>
>> Regards,
>> Benoit
>>
>
> <snip>
>
> Regards,
> Kishore
>
--
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
