All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sachin Kamat <sachin.kamat@linaro.org>
To: Tomasz Figa <tomasz.figa@gmail.com>
Cc: Arnd Bergmann <arnd@arndb.de>, Olof Johansson <olof@lixom.net>,
	Kukjin Kim <kgene.kim@samsung.com>,
	Tomasz Figa <t.figa@samsung.com>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	Mark Rutland <Mark.Rutland@arm.com>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	Ian Campbell <ijc+devicetree@hellion.org.uk>,
	Rob Herring <robh+dt@kernel.org>,
	Grant Likely <grant.likely@secretlab.ca>,
	linux-samsung-soc <linux-samsung-soc@vger.kernel.org>
Subject: Re: [PATCH 1/1] ARM: Exynos: Add generic compatible string
Date: Wed, 5 Mar 2014 21:00:22 +0530	[thread overview]
Message-ID: <CAK9yfHyDbx8DcdFvoAQZuo9RWLTZmXZPj8gSo8B4z=R0c=Lf4Q@mail.gmail.com> (raw)
In-Reply-To: <531714C4.2040200@gmail.com>

On 5 March 2014 17:42, Tomasz Figa <tomasz.figa@gmail.com> wrote:
> On 05.03.2014 09:25, Sachin Kamat wrote:
>>
>> On 25 February 2014 17:12, Arnd Bergmann <arnd@arndb.de> 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?
>>
>
> I would still prefer introducing a generic string for 32-bit Exynos SoCs,
> but I don't think it really matters a lot. I guess we can stick to just
> exynos4 and exynos5 compatible strings then, as long as we can merge the
> "board"-files and common.c together, since the code is pretty much
> SoC-independent now.

OK. Just wanted a confirmation before sending out the patches.
Thanks.

-- 
With warm regards,
Sachin

WARNING: multiple messages have this Message-ID (diff)
From: sachin.kamat@linaro.org (Sachin Kamat)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/1] ARM: Exynos: Add generic compatible string
Date: Wed, 5 Mar 2014 21:00:22 +0530	[thread overview]
Message-ID: <CAK9yfHyDbx8DcdFvoAQZuo9RWLTZmXZPj8gSo8B4z=R0c=Lf4Q@mail.gmail.com> (raw)
In-Reply-To: <531714C4.2040200@gmail.com>

On 5 March 2014 17:42, Tomasz Figa <tomasz.figa@gmail.com> wrote:
> On 05.03.2014 09:25, Sachin Kamat wrote:
>>
>> On 25 February 2014 17:12, Arnd Bergmann <arnd@arndb.de> 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?
>>
>
> I would still prefer introducing a generic string for 32-bit Exynos SoCs,
> but I don't think it really matters a lot. I guess we can stick to just
> exynos4 and exynos5 compatible strings then, as long as we can merge the
> "board"-files and common.c together, since the code is pretty much
> SoC-independent now.

OK. Just wanted a confirmation before sending out the patches.
Thanks.

-- 
With warm regards,
Sachin

  reply	other threads:[~2014-03-05 15:30 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-19 11:34 [PATCH 1/1] ARM: Exynos: Add generic compatible string Sachin Kamat
2014-02-19 12:45 ` Tomasz Figa
2014-02-19 12:45   ` Tomasz Figa
2014-02-20  4:14   ` Sachin Kamat
2014-02-20  4:14     ` Sachin Kamat
     [not found]     ` <CAK9yfHy7YHDLCfUGA-ua4iLzK2PMotVZvC=51t-bMkVZVBQFaA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-02-20 14:51       ` Tomasz Figa
2014-02-20 14:51         ` Tomasz Figa
2014-02-20 17:00         ` Arnd Bergmann
2014-02-20 17:00           ` Arnd Bergmann
     [not found]           ` <201402201800.49425.arnd-r2nGTMty4D4@public.gmane.org>
2014-02-20 17:34             ` Tomasz Figa
2014-02-20 17:34               ` Tomasz Figa
2014-02-20 17:48               ` Arnd Bergmann
2014-02-20 17:48                 ` Arnd Bergmann
2014-02-21  6:08                 ` Sachin Kamat
2014-02-21  6:08                   ` Sachin Kamat
2014-02-21 13:18                   ` Tomasz Figa
2014-02-21 13:18                     ` Tomasz Figa
2014-02-21 14:48                     ` Arnd Bergmann
2014-02-21 14:48                       ` Arnd Bergmann
2014-02-21 15:21                       ` Tomasz Figa
2014-02-21 15:21                         ` Tomasz Figa
     [not found]                         ` <53076F00.7000001-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2014-02-21 15:31                           ` Tomasz Figa
2014-02-21 15:31                             ` Tomasz Figa
2014-02-24 12:03                             ` Sachin Kamat
2014-02-24 12:03                               ` Sachin Kamat
2014-02-25  0:35                               ` Kukjin Kim
2014-02-25  0:35                                 ` Kukjin Kim
2014-02-25  0:52                                 ` Tomasz Figa
2014-02-25  0:52                                   ` Tomasz Figa
2014-02-25  1:00                                   ` Kukjin Kim
2014-02-25  1:00                                     ` Kukjin Kim
2014-02-25  3:03                                   ` Sachin Kamat
2014-02-25  3:03                                     ` Sachin Kamat
2014-02-25  4:42                                     ` Olof Johansson
2014-02-25  4:42                                       ` Olof Johansson
2014-02-25 11:42                                       ` Arnd Bergmann
2014-02-25 11:42                                         ` Arnd Bergmann
2014-03-05  8:25                                         ` Sachin Kamat
2014-03-05  8:25                                           ` Sachin Kamat
2014-03-05 12:12                                           ` Tomasz Figa
2014-03-05 12:12                                             ` Tomasz Figa
2014-03-05 15:30                                             ` Sachin Kamat [this message]
2014-03-05 15:30                                               ` Sachin Kamat
2014-02-24 12:02                         ` Sachin Kamat
2014-02-24 12:02                           ` Sachin Kamat

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAK9yfHyDbx8DcdFvoAQZuo9RWLTZmXZPj8gSo8B4z=R0c=Lf4Q@mail.gmail.com' \
    --to=sachin.kamat@linaro.org \
    --cc=Mark.Rutland@arm.com \
    --cc=arnd@arndb.de \
    --cc=devicetree@vger.kernel.org \
    --cc=grant.likely@secretlab.ca \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=kgene.kim@samsung.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=olof@lixom.net \
    --cc=robh+dt@kernel.org \
    --cc=t.figa@samsung.com \
    --cc=tomasz.figa@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.