>-----Original Message----- >From: Shilimkar, Santosh >Sent: Saturday, July 10, 2010 2:32 AM >To: Pandita, Vikram; linux-omap@xxxxxxxxxxxxxxx >Subject: RE: [PATCH 0/3] Fix omap_type() function > >> -----Original Message----- >> From: linux-omap-owner@xxxxxxxxxxxxxxx [mailto:linux-omap- >> owner@xxxxxxxxxxxxxxx] On Behalf Of Pandita, Vikram >> Sent: Saturday, July 10, 2010 12:39 PM >> To: linux-omap@xxxxxxxxxxxxxxx >> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
