On 07/14/2014 06:12 AM, Tony Lindgren wrote:
* Dave Gerlach <d-gerlach@xxxxxx> [140710 19:59]:
OMAP4 and AM33XX share the same EMIF controller IP. Although there
are significant differences in the IP integration due to which
AM33XX can't reuse the EMIF driver DVFS similar to OMAP4,
it can definitely benefit by reusing the EMIF related macros
defined in drivers/memory/emif.h.
In the current OMAP PM framework the PM code resides under
arch/arm/mach-omap2/. To enable reuse of the register defines move
the register defines in the emif header file to include/linux so that
both the EMIF driver and the AM33XX PM code can benefit.
Signed-off-by: Dave Gerlach <d-gerlach@xxxxxx>
Reviewed-by: Russ Dill <russ.dill@xxxxxx>
Acked-by: Santosh Shililmar <santosh.shilimkar@xxxxxx>
Acked-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
---
v3->v4:
patch unchanged from original:
http://www.spinics.net/lists/linux-omap/msg95314.html
drivers/memory/emif.h | 543 +---------------------------------------------
include/linux/ti_emif.h | 558 ++++++++++++++++++++++++++++++++++++++++++++++++
So far we've seen that exposing hardware registers like this
will lead into various drivers misusing them. I think a better
solution is to implement few targeted functions that allow
sharing code between the platform idle code and memory driver.
Maybe you can have the shared functions in in something like
drivers/memory/ti-emif.c that's always built in? The idle
code won't need any of that early on.
Well the reason it was done this way was to utilize all of the addresses of EMIF
register in the ASM sleep code to do relative addressing from the EMIF base
address. The ASM sleep code (patch 9) needs to save and restore emif context and
set and unset self refresh in emif. The issues will come from the ASM being
copied to and running from SRAM without the ability to access code in DDR
(because we are shutting the EMIF off), so we would need to copy these functions
as well and have to worry about any issues we introduce by relocating c code. Is
it worth the added maintenance burden?
Regards,
Dave
Regards,
Tony
--
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
