On Mon, Aug 07, 2017 at 07:35:30AM -0500, Derald Woods wrote:
On Mon, Jul 31, 2017 at 7:41 AM, Derald D. Woods woods.technical@gmail.com wrote:
Fixes: 00bbe96ebabb ("arm: omap: Unify get_device_type() function")
The control status register value is embedded in a structure somewhere in SRAM, with the last refactoring effort. This patch allows OMAP3 EVM (TMDSEVM3530) to boot again using the known control register base and offset for 'readl', for the OMAP34XX case.
Signed-off-by: Derald D. Woods woods.technical@gmail.com
Changes in v2:
- Added 'signed-off-by'
- Updated description
arch/arm/mach-omap2/sysinfo-common.c | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/arch/arm/mach-omap2/sysinfo-common.c b/arch/arm/mach-omap2/sysinfo-common.c index 1dc7051ab3..3955e803ad 100644 --- a/arch/arm/mach-omap2/sysinfo-common.c +++ b/arch/arm/mach-omap2/sysinfo-common.c @@ -16,6 +16,10 @@ */ u32 get_device_type(void) { +#if defined(CONFIG_OMAP34XX)
return (readl(OMAP34XX_CTRL_BASE + 0x2f0) & DEVICE_TYPE_MASK) >>DEVICE_TYPE_SHIFT;+#endif return (readl((*ctrl)->control_status) & DEVICE_TYPE_MASK) >> DEVICE_TYPE_SHIFT; }
Is there any comment or concern with this patch? It was the simplest means to get OMAP35XX booting again and still keep the original patch. Basically it avoids the pointer to the OMAP_SRAM_SCRATCH_SYS_CTRL located structure as now defined in "arch/arm/mach-omap2/omap3/hw_data.c". OMAP3 has a larger active SOC base than just OMAP36XX and greater. Was there anything really broken with 'get_device_type()' previously?
Is the pointer value wrong for 35xx? The problem, such as it was, was having the same function duplicated in a number of places, and needing to make it more easily / readily available (rather than duplicated again) for some additional patches. I'd really rather not introduce an #if here unless we really have no other choice. Thanks!