>-----Original Message-----
>From: Shilimkar, Santosh
>Sent: Saturday, July 10, 2010 2:32 AM
>To: Pandita, Vikram; [email protected]
>Subject: RE: [PATCH 0/3] Fix omap_type() function
>
>> -----Original Message-----
>> From: [email protected] [mailto:linux-omap-
>> [email protected]] On Behalf Of Pandita, Vikram
>> Sent: Saturday, July 10, 2010 12:39 PM
>> To: [email protected]
>> Cc: Pandita, Vikram
>> Subject: [PATCH 0/3] Fix omap_type() function
>>
>> Aim was to get omap_type() function work on omap4.
>> In doing so, fixing an issue with is_sram_locked() function.
>>
>> Patches tested/verified on omap4 sdp.
>> Patches based of latest linus commit: e467e10
>>
>> Vikram Pandita (3):
>> omap: sram: fix is_sram_locked check
>> omap4: fix omap_type() function
>> omap4: SRAM start and size change for EMU/HS devices
>>
>> arch/arm/plat-omap/include/plat/omap44xx.h | 2 +-
>> arch/arm/plat-omap/sram.c | 28 ++++++++++++++--------
>-
>In summary only fixing " is_sram_locked()" and adding the OMAP_2PLUS is
>enough.
All Valid comments. Thanks for the review.
>
>The control module needs to be fixed in right way because with different
>bases in wakeup and core control modules makes
>the current omap_control_read/write break on OMAP4. This is similar problem
>what we have on powerdomain base offsets and needs a proper handling.
>
>Fixing one base will break other register acceses
Yes I can now see how my patch 2 has broken the MMC part in:
omap4_hsmmc1_before_set_reg(...)
Will post a saner V2 with:
Patch 1 -> your ACK
Patch 2 ->
will fix omap_type() in right way
by not using omap_ctrl_readl() instead using right offset
Patch 3 -> just add OMAP_2PLUS change
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
