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; } -- 2.13.3
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?
Derald