On 25 February 2014 17:12, Arnd Bergmann <arnd@xxxxxxxx> wrote: > On Tuesday 25 February 2014, Olof Johansson wrote: >> I disagree. I don't know what Samsung has in mind, but the revision of >> the CPU doesn't have all that much to do with the rest of the SoC. >> It's quite likely that some vendors (maybe not Samsung, but the same >> concept applies) will ship 64-bit SoCs that are very similar to their >> preceding 32-bit ones, same IP, similar busses, etc. I'm pretty sure >> at least some vendors will do very close to that. > > Right. > >> So, if EXYNOS4 and EXYNOS5 can share a compatible value when they use >> different CPUs, then there's no reason that whatever future 64-bit >> ones can also share it. > > How about putting both 'samsung,exynos' and 'samsung,exynos4' in DT then > and having the platform code match exynos4 and exynos5 but not exynos? > > That way, I think we are consistent and future-proof. Any code that needs > to know if it's running on some exynos version can just check for the > 'samsung,exynos' compatible value and that will work on both arm32 and > arm64. Also, if we ever decide we want to run a 32-bit kernel on a 64-bit > exynos, we can just add 'samsung,exynos6' (or whatever number that will > be) to the list. > > My usual disclaimer for this: You should never ever consider actually > running a 32-bit kernel on a 64-bit CPU, but at the same time there > shouldn't be any reason why it won't work either, given that we require > arm64 based systems to have all SoC specific code in drivers and we > can use the same drivers on arm32. Kukjin, Tomasz, What is your opinion about Arnd's suggestion? -- With warm regards, Sachin -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |