Re: OSK5912 cpu_is_omap5912() FALSE

[Tony Lindgren <tony@atomide.com>]

* Smith, Stephen <smsmith@ti.com> [060202 15:14]:
> OSK5912/Linux 2.6.13
> 
>  
> 
> There is a discrepancy in cpu.h and what my OSK5912 reflects.
> 
>  
> 
> cpu.h reflects:
> 
> IS_OMAP_TYPE(5912, 0x1611)
> 
>  
> 
> Here is my data from boot, which reflects the correct values:
> 
> OMAP_DIE_ID_0: 0xbfd20610
> 
> OMAP_DIE_ID_1: 0x8e059089 DIE_REV: 2
> 
> OMAP_PRODUCTION_ID_0: 0x00aaaafc
> 
> OMAP_PRODUCTION_ID_1: 0x00016cbe JTAG_ID: 0x6cbe
> 
> OMAP32_ID_0: 0x03320500
> 
> OMAP32_ID_1: 0x2b65f02f
> 
> JTAG_ID: 0xb65f DIE_REV: 2
> 
> OMAP162123 revision 2 handled as 16xx id: 8e059089bfd20610
> 
>  
> 
>  
> 
> Is arch-omap/cpu.h wrong, or is there something more here?  With
> 
> code as it was patched, cpu_is_omap5912() fails.  Sign of problem
> 
> is the inability to reboot the board (# reboot).  I can fix by
> 
> changing cpu.h to:
> 
>  
> 
> IS_OMAP_TYPE(5912, 0x1621)
> 
>  
> 
> I don't want to blindly change because I do not know history of OMAP5912
> 
> and it is possible some previous rev had id'ed as 1611.
> 
> It could also be fixed by adding another type check to arch_reset(), but
> 
> that may include 1621 types that do not require or want workaround.

We should really get rid of cpu_is_omap5912() and just use
cpu_is_omap16xx().

If 1710 is excluded, we should use something like:

(cpu_is_omap16xx() && !cpu_is_omap1710())

In some cases we may need to test for machine_is_omap_osk() instead.

Tony