Hi, On Tue, Mar 3, 2009 at 2:03 AM, Tony Lindgren <tony@xxxxxxxxxxx> wrote: > * 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? Right, but now s3c doesn't used system_rev variable. no problem in this case, Also it has a lot of room (4 bits). it can handle for system revision as original purpose. Current u-boot codes doesn't pass any info to kernel. So if you don't mind I want to commit it as it is. > > 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. Yes I already use this scheme at our omap board. there's a lot of omap board revision. It's already merged at u-boot code. Thank you, Kyungmin Park -- 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
