From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnd Bergmann Subject: Re: [PATCH 0/4] Introducing Exynos ChipId driver Date: Mon, 12 May 2014 11:47:04 +0200 Message-ID: <4593340.mEX4CtCUDb@wuerfel> References: <1399097500-4052-1-git-send-email-pankaj.dubey@samsung.com> <4239261.HFHm7SU1iH@wuerfel> <20140512014728.GA6054@quad.lixom.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Return-path: Received: from mout.kundenserver.de ([212.227.17.10]:63989 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751719AbaELJrh (ORCPT ); Mon, 12 May 2014 05:47:37 -0400 In-Reply-To: <20140512014728.GA6054@quad.lixom.net> Sender: linux-samsung-soc-owner@vger.kernel.org List-Id: linux-samsung-soc@vger.kernel.org To: Olof Johansson Cc: linux-arm-kernel@lists.infradead.org, Pankaj Dubey , kgene.kim@samsung.com, linux@arm.linux.org.uk, t.figa@samsung.com, linux-kernel@vger.kernel.org, linux-samsung-soc@vger.kernel.org On Sunday 11 May 2014 18:47:28 Olof Johansson wrote: > > > Also for platsmp.c and pm.c I can think of following approaches > > > 1: Keep these macros till we get generic solution? > > > 2: Allow chipid driver to expose APIs to check SoC id and SoC revisions > > > till we get > > > generic solution. So that at least we can remove #ifdef based macros > > > as soc_is_exynosXYZ. > > > 3: Use of "of_flat_dt_is_compatible" or similar APIs in these machine files > > > till we get > > > generic solution. For some cases where we want to know SoC revision let us > > > map chipid register and get revision there itself. > > > > > > Please let me know what approach you think will be good? > > > > I think 1 or 2 would be better than 3. Between those two, I'm undecided, > > but I think either way the SoC specific values would be better kept in the > > mach-samsung directory than in plat/cpu.h or linux/exynos-chipid.h. > > The generic solution is already there: of_machine_is_compatible() is perfectly > sensible to use for _some_ of these inits. Cpufreq is one of the few that comes > to mind, and maybe some of the platsmp and pm stuff. > > Note that none of them should be used in runtime, i.e. you should only use them > at probe/setup time and maybe have a local state in the driver if needed. > > I'd rather get people used to that format than everybody needing to implement > a chipid driver now too, especially on platforms that might not even have a > suitable chipid block to base a driver around -- not to mention having to > fill the namespace with is_soc_*() stuff. I was coming from the other angle: exynos is already using soc_is_*() in too many places. I'd like to first see the ones cleaned up that really should be doing something else because they have a device-local ID to look at. If we end up with a couple of instances that don't have a good alternative, we can use of_machine_is_compatible() for those, but I'd like to avoid doing a blind conversion because that would likely lead to more instances in the future, not fewer. I agree that we should have to introduce new chip ID drivers on other platforms for the purpose of finding out the SoC version, especially not with private APIs. Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 From: arnd@arndb.de (Arnd Bergmann) Date: Mon, 12 May 2014 11:47:04 +0200 Subject: [PATCH 0/4] Introducing Exynos ChipId driver In-Reply-To: <20140512014728.GA6054@quad.lixom.net> References: <1399097500-4052-1-git-send-email-pankaj.dubey@samsung.com> <4239261.HFHm7SU1iH@wuerfel> <20140512014728.GA6054@quad.lixom.net> Message-ID: <4593340.mEX4CtCUDb@wuerfel> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Sunday 11 May 2014 18:47:28 Olof Johansson wrote: > > > Also for platsmp.c and pm.c I can think of following approaches > > > 1: Keep these macros till we get generic solution? > > > 2: Allow chipid driver to expose APIs to check SoC id and SoC revisions > > > till we get > > > generic solution. So that at least we can remove #ifdef based macros > > > as soc_is_exynosXYZ. > > > 3: Use of "of_flat_dt_is_compatible" or similar APIs in these machine files > > > till we get > > > generic solution. For some cases where we want to know SoC revision let us > > > map chipid register and get revision there itself. > > > > > > Please let me know what approach you think will be good? > > > > I think 1 or 2 would be better than 3. Between those two, I'm undecided, > > but I think either way the SoC specific values would be better kept in the > > mach-samsung directory than in plat/cpu.h or linux/exynos-chipid.h. > > The generic solution is already there: of_machine_is_compatible() is perfectly > sensible to use for _some_ of these inits. Cpufreq is one of the few that comes > to mind, and maybe some of the platsmp and pm stuff. > > Note that none of them should be used in runtime, i.e. you should only use them > at probe/setup time and maybe have a local state in the driver if needed. > > I'd rather get people used to that format than everybody needing to implement > a chipid driver now too, especially on platforms that might not even have a > suitable chipid block to base a driver around -- not to mention having to > fill the namespace with is_soc_*() stuff. I was coming from the other angle: exynos is already using soc_is_*() in too many places. I'd like to first see the ones cleaned up that really should be doing something else because they have a device-local ID to look at. If we end up with a couple of instances that don't have a good alternative, we can use of_machine_is_compatible() for those, but I'd like to avoid doing a blind conversion because that would likely lead to more instances in the future, not fewer. I agree that we should have to introduce new chip ID drivers on other platforms for the purpose of finding out the SoC version, especially not with private APIs. Arnd