* Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> [090302 08:23]: > On Thu, Feb 26, 2009 at 07:59:44PM +0000, Mark Brown wrote: > > +extern unsigned int system_rev; > > + > > +/* > > + * cpu_is_s3c24xx(): True for s3c2400, s3c2410, s3c2440 and so on > > + * cpu_is_s3c241x(): True fro s3c2410, s3c2412 > > + * cpu_is_s3c244x(): True fro s3c2440, s3c2442, s3c2443 > > + * cpu_is_s3c64xx(): True for s3c6400, s3c6410 > > + */ > > +#define GET_S3C_CLASS ((system_rev >> 24) & 0xff) > > I think OMAP people decided in the end that using 'system_rev' for the > SoC was wrong. 'system_rev' was added for NetWinders so that the board > level hardware version could be given to the kernel. > > They've since moved over to a different approach, and storing the SoC > revision in their own private omap_revision variable. > > Is this something s3c should also consider? Yeah now we can use system_rev on omaps to pass the board revision from the bootloader. This allow to remap the board revision specific changes in the board init code. This can be handy for GPIO pin changes for example. So far there has not been a need to pass the SoC revision from the bootloader as it can be detected during the runtime. In some cases the SoC runtime detection does not work easily because of the differences in IO mapping. That can be solved by having functions to set the SoC class from the board init. For omaps we have functions omap2_set_globals_243x() and omap2_set_globals_343x() to do this. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
