[PATCH 1/1] ARM: Exynos: Add generic compatible string

[PATCH 1/1] ARM: Exynos: Add generic compatible string

[Tomasz Figa]

Hi Sachin,

[adding linux-arm-kernel ML to CC list]

On 19.02.2014 12:34, Sachin Kamat wrote:
> To avoid modifying the kernel every time a new SoC variant
> comes out.
>
> Suggested-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
> ---
>   arch/arm/mach-exynos/mach-exynos4-dt.c |    1 +
>   arch/arm/mach-exynos/mach-exynos5-dt.c |    1 +
>   2 files changed, 2 insertions(+)
>
> diff --git a/arch/arm/mach-exynos/mach-exynos4-dt.c b/arch/arm/mach-exynos/mach-exynos4-dt.c
> index d3e54b7644d7..5d037b561253 100644
> --- a/arch/arm/mach-exynos/mach-exynos4-dt.c
> +++ b/arch/arm/mach-exynos/mach-exynos4-dt.c
> @@ -28,6 +28,7 @@ static void __init exynos4_dt_machine_init(void)
>   }
>
>   static char const *exynos4_dt_compat[] __initdata = {
> +	"samsung,exynos4",
>   	"samsung,exynos4210",
>   	"samsung,exynos4212",
>   	"samsung,exynos4412",
> diff --git a/arch/arm/mach-exynos/mach-exynos5-dt.c b/arch/arm/mach-exynos/mach-exynos5-dt.c
> index 37ea261f0f6c..ad0db5a93da8 100644
> --- a/arch/arm/mach-exynos/mach-exynos5-dt.c
> +++ b/arch/arm/mach-exynos/mach-exynos5-dt.c
> @@ -50,6 +50,7 @@ static void __init exynos5_dt_machine_init(void)
>   }
>
>   static char const *exynos5_dt_compat[] __initdata = {
> +	"samsung,exynos5",
>   	"samsung,exynos5250",
>   	"samsung,exynos5420",
>   	"samsung,exynos5440",
>

Since all Exynos chips can be easily recognized using dedicated chip ID 
register, I wonder whether we really need to maintain two distinct board 
files for Exynos 4 and 5 series, especially when both of them are doing 
mostly the same set up, which can be simply generalized to cover all the 
cases.

Instead of adding just another level of artificially fine grained 
compatible strings, I'd rather suggest merging both board files together 
and adding a single compatible string identifying all SoCs that can be 
further differentiated by using hardware chip ID register.

What do you think?

P.S. Please always keep respective subsystem/arch level MLs on CC list, 
in this case linux-arm-kernel. The linux-samsung-soc ML is just a 
convenience tool to group all threads about Samsung SoCs, not a way to 
bypass respective subsystem MLs.

Best regards,
Tomasz

[PATCH 1/1] ARM: Exynos: Add generic compatible string

[Sachin Kamat]

Hi Tomasz,

On 19 February 2014 18:15, Tomasz Figa <t.figa@samsung.com> wrote:
> Hi Sachin,
>
> [adding linux-arm-kernel ML to CC list]
>
>
> On 19.02.2014 12:34, Sachin Kamat wrote:
>>
>> To avoid modifying the kernel every time a new SoC variant
>> comes out.
<snip>
>
> Since all Exynos chips can be easily recognized using dedicated chip ID
> register, I wonder whether we really need to maintain two distinct board
> files for Exynos 4 and 5 series, especially when both of them are doing
> mostly the same set up, which can be simply generalized to cover all the
> cases.
>
> Instead of adding just another level of artificially fine grained compatible
> strings, I'd rather suggest merging both board files together and adding a
> single compatible string identifying all SoCs that can be further
> differentiated by using hardware chip ID register.
>
> What do you think?

I agree with your idea of merging both the files as there is very little that is
different for now. However I am not really sure if having a single compatible
string for all SoCs would be good. What is achieved through compatible string
can very well be done using chip ID too. But wouldn't we need to maintain some
unique identity for the SoCs in human readable form at the DT level?
In the absence
of any other opinion, can probably experiment with this and see how it
takes shape.


> P.S. Please always keep respective subsystem/arch level MLs on CC list, in
> this case linux-arm-kernel. The linux-samsung-soc ML is just a convenience
> tool to group all threads about Samsung SoCs, not a way to bypass respective
> subsystem MLs.

Nothing to disagree. A valid point at large, but for every trivial or
exynos specific
change, including top level MLs would probably amount to spamming :)

-- 
With warm regards,
Sachin

[PATCH 1/1] ARM: Exynos: Add generic compatible string

[Tomasz Figa]

[adding DT ML and DT maintainers on Cc for some discussion]

On 20.02.2014 05:14, Sachin Kamat wrote:
> Hi Tomasz,
>
> On 19 February 2014 18:15, Tomasz Figa <t.figa@samsung.com> wrote:
>> Hi Sachin,
>>
>> [adding linux-arm-kernel ML to CC list]
>>
>>
>> On 19.02.2014 12:34, Sachin Kamat wrote:
>>>
>>> To avoid modifying the kernel every time a new SoC variant
>>> comes out.
> <snip>
>>
>> Since all Exynos chips can be easily recognized using dedicated chip ID
>> register, I wonder whether we really need to maintain two distinct board
>> files for Exynos 4 and 5 series, especially when both of them are doing
>> mostly the same set up, which can be simply generalized to cover all the
>> cases.
>>
>> Instead of adding just another level of artificially fine grained compatible
>> strings, I'd rather suggest merging both board files together and adding a
>> single compatible string identifying all SoCs that can be further
>> differentiated by using hardware chip ID register.
>>
>> What do you think?
>
> I agree with your idea of merging both the files as there is very little that is
> different for now. However I am not really sure if having a single compatible
> string for all SoCs would be good. What is achieved through compatible string
> can very well be done using chip ID too. But wouldn't we need to maintain some
> unique identity for the SoCs in human readable form at the DT level?

Well, my understanding of Device Tree is that it should provide the 
information that can't be automatically retrieved from the hardware, not 
more.

If you have a PCI or USB bus with enumerable devices, you don't list 
them in DT, but instead limit the description to just the host 
controller, if it can't be enumerated.

Same goes for compatible string. My interpretation of it is that if you 
can identify the hardware by some automatic means, e.g. querying some ID 
register, then the compatible should be specific enough to identify the 
class of devices with the same method of querying such register, with no 
need for any additional redundant data in DT.

Of course nothing stops you from retaining more specific compatible 
strings. In fact, this is probably the most appropriate solution, 
because in future you might find out that certain SoCs need some special 
differentiation, e.g. same ID value on two SoCs.

So, to apply this to our case, our Exynos 5250 based Arndale board would 
be changed from

compatible = "insignal,arndale", "samsung,exynos5260";

to

compatible = "insignal,arndale", "samsung,exynos5260", "samsung,exynos";

Now, the board file will be able to match simply by "samsung,exynos" 
compatible string and SoC-specific code in mach-exynos (hopefully none 
after it gets cleaned up fully) will use soc_is_exynos*() macros (what 
AFAIK it is already doing at the moment).

Another benefit of this would be increased safety, because you are 
reading SoC type from actual hardware, not from externally supplied 
data. In conjunction with the more specific compatible string (e.g. 
"samsung,exynos5260") some validation could be performed at boot-up time 
to make sure that DT for correct SoC is used.

> In the absence
> of any other opinion, can probably experiment with this and see how it
> takes shape.
>
>
>> P.S. Please always keep respective subsystem/arch level MLs on CC list, in
>> this case linux-arm-kernel. The linux-samsung-soc ML is just a convenience
>> tool to group all threads about Samsung SoCs, not a way to bypass respective
>> subsystem MLs.
>
> Nothing to disagree. A valid point at large, but for every trivial or
> exynos specific
> change, including top level MLs would probably amount to spamming :)

I agree that for simple discussion threads samsung-soc list alone might 
be sufficient, but any patches should be subject to broader review, not 
limited to Samsung people.

Best regards,
Tomasz

[PATCH 1/1] ARM: Exynos: Add generic compatible string

[Arnd Bergmann]

On Thursday 20 February 2014, Tomasz Figa wrote:
> On 20.02.2014 05:14, Sachin Kamat wrote:
> > Hi Tomasz,
> >
> > On 19 February 2014 18:15, Tomasz Figa <t.figa@samsung.com> wrote:
> >> Hi Sachin,
> >>
> >> [adding linux-arm-kernel ML to CC list]
> >>
> >>
> >> On 19.02.2014 12:34, Sachin Kamat wrote:
> >>>
> >>> To avoid modifying the kernel every time a new SoC variant
> >>> comes out.
> > <snip>
> >>
> >> Since all Exynos chips can be easily recognized using dedicated chip ID
> >> register, I wonder whether we really need to maintain two distinct board
> >> files for Exynos 4 and 5 series, especially when both of them are doing
> >> mostly the same set up, which can be simply generalized to cover all the
> >> cases.
> >>
> >> Instead of adding just another level of artificially fine grained compatible
> >> strings, I'd rather suggest merging both board files together and adding a
> >> single compatible string identifying all SoCs that can be further
> >> differentiated by using hardware chip ID register.
> >>
> >> What do you think?
> >
> > I agree with your idea of merging both the files as there is very little that is
> > different for now. However I am not really sure if having a single compatible
> > string for all SoCs would be good. What is achieved through compatible string
> > can very well be done using chip ID too. But wouldn't we need to maintain some
> > unique identity for the SoCs in human readable form at the DT level?
> 
> Well, my understanding of Device Tree is that it should provide the 
> information that can't be automatically retrieved from the hardware, not 
> more.
> 
> If you have a PCI or USB bus with enumerable devices, you don't list 
> them in DT, but instead limit the description to just the host 
> controller, if it can't be enumerated.
> 
> Same goes for compatible string. My interpretation of it is that if you 
> can identify the hardware by some automatic means, e.g. querying some ID 
> register, then the compatible should be specific enough to identify the 
> class of devices with the same method of querying such register, with no 
> need for any additional redundant data in DT.

There are some limitations to that, and you also have to apply common
sense and taste. In theory you could argue that a compatible string can
identify a board uniquely the same way that a board number did, and
everything else is implied by that. Clearly that's not what we want.
On the other end of the scale, you could eliminate a lot of compatible
strings if you describe each register or each bit in some cases in
DT properties, and that would be just as wrong.

> Of course nothing stops you from retaining more specific compatible 
> strings. In fact, this is probably the most appropriate solution, 
> because in future you might find out that certain SoCs need some special 
> differentiation, e.g. same ID value on two SoCs.
> 
> So, to apply this to our case, our Exynos 5250 based Arndale board would 
> be changed from
> 
> compatible = "insignal,arndale", "samsung,exynos5260";
> 
> to
> 
> compatible = "insignal,arndale", "samsung,exynos5260", "samsung,exynos";

Right, this would make sense.

> Now, the board file will be able to match simply by "samsung,exynos" 
> compatible string and SoC-specific code in mach-exynos (hopefully none 
> after it gets cleaned up fully) will use soc_is_exynos*() macros (what 
> AFAIK it is already doing at the moment).

On principle, I would not take things out of the match list, if that
would break booting with old DT file that don't list "samsung,exynos"
as compatible. But for new SoCs that would work.

Using soc_is_exynos*() too much of course also isn't good. A lot of
the things tested for should probably be checked from individual DT
properties, but again we have to find the right balance. I wouldn't
mind getting rid of the soc_is_exynos*() macros completely, because
a) we can't use them in device drivers
b) all platform code is supposed to be in drivers
c) both rules are enforced for arm64

> Another benefit of this would be increased safety, because you are 
> reading SoC type from actual hardware, not from externally supplied 
> data. In conjunction with the more specific compatible string (e.g. 
> "samsung,exynos5260") some validation could be performed at boot-up time 
> to make sure that DT for correct SoC is used.

I don't think that's necessary. If you get that part wrong, normally
all your hopes are lost with the rest of the information in DT. ;-)

	Arnd

[PATCH 1/1] ARM: Exynos: Add generic compatible string

[Tomasz Figa]

On 20.02.2014 18:00, Arnd Bergmann wrote:
> On Thursday 20 February 2014, Tomasz Figa wrote:
>> On 20.02.2014 05:14, Sachin Kamat wrote:
>>> Hi Tomasz,
>>>
>>> On 19 February 2014 18:15, Tomasz Figa <t.figa@samsung.com> wrote:
>>>> Hi Sachin,
>>>>
>>>> [adding linux-arm-kernel ML to CC list]
>>>>
>>>>
>>>> On 19.02.2014 12:34, Sachin Kamat wrote:
>>>>>
>>>>> To avoid modifying the kernel every time a new SoC variant
>>>>> comes out.
>>> <snip>
>>>>
>>>> Since all Exynos chips can be easily recognized using dedicated chip ID
>>>> register, I wonder whether we really need to maintain two distinct board
>>>> files for Exynos 4 and 5 series, especially when both of them are doing
>>>> mostly the same set up, which can be simply generalized to cover all the
>>>> cases.
>>>>
>>>> Instead of adding just another level of artificially fine grained compatible
>>>> strings, I'd rather suggest merging both board files together and adding a
>>>> single compatible string identifying all SoCs that can be further
>>>> differentiated by using hardware chip ID register.
>>>>
>>>> What do you think?
>>>
>>> I agree with your idea of merging both the files as there is very little that is
>>> different for now. However I am not really sure if having a single compatible
>>> string for all SoCs would be good. What is achieved through compatible string
>>> can very well be done using chip ID too. But wouldn't we need to maintain some
>>> unique identity for the SoCs in human readable form at the DT level?
>>
>> Well, my understanding of Device Tree is that it should provide the
>> information that can't be automatically retrieved from the hardware, not
>> more.
>>
>> If you have a PCI or USB bus with enumerable devices, you don't list
>> them in DT, but instead limit the description to just the host
>> controller, if it can't be enumerated.
>>
>> Same goes for compatible string. My interpretation of it is that if you
>> can identify the hardware by some automatic means, e.g. querying some ID
>> register, then the compatible should be specific enough to identify the
>> class of devices with the same method of querying such register, with no
>> need for any additional redundant data in DT.
>
> There are some limitations to that, and you also have to apply common
> sense and taste. In theory you could argue that a compatible string can
> identify a board uniquely the same way that a board number did, and
> everything else is implied by that. Clearly that's not what we want.

I'd argue about relevance of this example. What I'm talking about is 
kind of data that can be retrieved directly from the hardware. Both 
compatible string and board number are just artificial identifiers that 
can be used by the kernel to decide (in a greatly simplified view) which 
set of static (i.e. hardcoded) data (and code) to use.

If it happens that a new piece of hardware requires just exactly the 
same set, because any possible differences can be obtained by reading 
some registers, then there is no need for the kernel to support any new 
compatible string and such hardware will work on older kernels as well.

> On the other end of the scale, you could eliminate a lot of compatible
> strings if you describe each register or each bit in some cases in
> DT properties, and that would be just as wrong.

I don't mind fine grained compatible strings. In fact, making them fine 
grained is most likely to be the best choice most of the time. Still, 
the simple fact is, though, that data which can be retrieved from the 
hardware automatically should not be repeated in DT. This is called 
redundancy and this is bad, from obvious reasons.

>> Of course nothing stops you from retaining more specific compatible
>> strings. In fact, this is probably the most appropriate solution,
>> because in future you might find out that certain SoCs need some special
>> differentiation, e.g. same ID value on two SoCs.
>>
>> So, to apply this to our case, our Exynos 5250 based Arndale board would
>> be changed from
>>
>> compatible = "insignal,arndale", "samsung,exynos5260";
>>
>> to
>>
>> compatible = "insignal,arndale", "samsung,exynos5260", "samsung,exynos";
>
> Right, this would make sense.
>
>> Now, the board file will be able to match simply by "samsung,exynos"
>> compatible string and SoC-specific code in mach-exynos (hopefully none
>> after it gets cleaned up fully) will use soc_is_exynos*() macros (what
>> AFAIK it is already doing at the moment).
>
> On principle, I would not take things out of the match list, if that
> would break booting with old DT file that don't list "samsung,exynos"
> as compatible. But for new SoCs that would work.

My proposal was about simply adding a fully generic string, without 
removing the specific ones. For already supported SoCs this is pretty 
obvious, as existing DTBs would not have this generic string listed. But 
the specific strings should be also present in DTSes of new SoCs, even 
if not recognized by the kernel, to make sure that in future any 
SoC-specific quirks could be easily handled.

> Using soc_is_exynos*() too much of course also isn't good. A lot of
> the things tested for should probably be checked from individual DT
> properties, but again we have to find the right balance. I wouldn't
> mind getting rid of the soc_is_exynos*() macros completely, because
> a) we can't use them in device drivers
> b) all platform code is supposed to be in drivers
> c) both rules are enforced for arm64

I fully agree. As I said, after cleaning up mach-exynos/ there should be 
no more code left using soc_is_*() macros. Ideally, the whole 
mach-exynos/ should collapse into a single, trivial file, with 
everything done in dedicated drivers.

>> Another benefit of this would be increased safety, because you are
>> reading SoC type from actual hardware, not from externally supplied
>> data. In conjunction with the more specific compatible string (e.g.
>> "samsung,exynos5260") some validation could be performed at boot-up time
>> to make sure that DT for correct SoC is used.
>
> I don't think that's necessary. If you get that part wrong, normally
> all your hopes are lost with the rest of the information in DT. ;-)

This would let you detect the problem earlier, though, without trying to 
probe incorrect devices and activating unsuitable configurations on 
devices that may happen to match on both SoCs. I agree, though, that 
this is not anything essential.

Best regards,
Tomasz

[PATCH 1/1] ARM: Exynos: Add generic compatible string

[Arnd Bergmann]

On Thursday 20 February 2014 18:34:23 Tomasz Figa wrote:
> On 20.02.2014 18:00, Arnd Bergmann wrote:
> >> Of course nothing stops you from retaining more specific compatible
> >> strings. In fact, this is probably the most appropriate solution,
> >> because in future you might find out that certain SoCs need some special
> >> differentiation, e.g. same ID value on two SoCs.
> >>
> >> So, to apply this to our case, our Exynos 5250 based Arndale board would
> >> be changed from
> >>
> >> compatible = "insignal,arndale", "samsung,exynos5260";
> >>
> >> to
> >>
> >> compatible = "insignal,arndale", "samsung,exynos5260", "samsung,exynos";
> >
> > Right, this would make sense.
> >
> >> Now, the board file will be able to match simply by "samsung,exynos"
> >> compatible string and SoC-specific code in mach-exynos (hopefully none
> >> after it gets cleaned up fully) will use soc_is_exynos*() macros (what
> >> AFAIK it is already doing at the moment).
> >
> > On principle, I would not take things out of the match list, if that
> > would break booting with old DT file that don't list "samsung,exynos"
> > as compatible. But for new SoCs that would work.
> 
> My proposal was about simply adding a fully generic string, without 
> removing the specific ones. For already supported SoCs this is pretty 
> obvious, as existing DTBs would not have this generic string listed. But 
> the specific strings should be also present in DTSes of new SoCs, even 
> if not recognized by the kernel, to make sure that in future any 
> SoC-specific quirks could be easily handled.

Yes, that's ideal.

> > Using soc_is_exynos*() too much of course also isn't good. A lot of
> > the things tested for should probably be checked from individual DT
> > properties, but again we have to find the right balance. I wouldn't
> > mind getting rid of the soc_is_exynos*() macros completely, because
> > a) we can't use them in device drivers
> > b) all platform code is supposed to be in drivers
> > c) both rules are enforced for arm64
> 
> I fully agree. As I said, after cleaning up mach-exynos/ there should be 
> no more code left using soc_is_*() macros. Ideally, the whole 
> mach-exynos/ should collapse into a single, trivial file, with 
> everything done in dedicated drivers.

Right.


	Arnd

[PATCH 1/1] ARM: Exynos: Add generic compatible string

[Sachin Kamat]

On 20 February 2014 23:18, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thursday 20 February 2014 18:34:23 Tomasz Figa wrote:
>> On 20.02.2014 18:00, Arnd Bergmann wrote:
>> >> Of course nothing stops you from retaining more specific compatible
>> >> strings. In fact, this is probably the most appropriate solution,
>> >> because in future you might find out that certain SoCs need some special
>> >> differentiation, e.g. same ID value on two SoCs.
>> >>
>> >> So, to apply this to our case, our Exynos 5250 based Arndale board would
>> >> be changed from
>> >>
>> >> compatible = "insignal,arndale", "samsung,exynos5260";
>> >>
>> >> to
>> >>
>> >> compatible = "insignal,arndale", "samsung,exynos5260", "samsung,exynos";
>> >
>> > Right, this would make sense.
>> >
>> >> Now, the board file will be able to match simply by "samsung,exynos"
>> >> compatible string and SoC-specific code in mach-exynos (hopefully none
>> >> after it gets cleaned up fully) will use soc_is_exynos*() macros (what
>> >> AFAIK it is already doing at the moment).
>> >
>> > On principle, I would not take things out of the match list, if that
>> > would break booting with old DT file that don't list "samsung,exynos"
>> > as compatible. But for new SoCs that would work.
>>
>> My proposal was about simply adding a fully generic string, without
>> removing the specific ones. For already supported SoCs this is pretty
>> obvious, as existing DTBs would not have this generic string listed. But
>> the specific strings should be also present in DTSes of new SoCs, even
>> if not recognized by the kernel, to make sure that in future any
>> SoC-specific quirks could be easily handled.
>
> Yes, that's ideal.
>
>> > Using soc_is_exynos*() too much of course also isn't good. A lot of
>> > the things tested for should probably be checked from individual DT
>> > properties, but again we have to find the right balance. I wouldn't
>> > mind getting rid of the soc_is_exynos*() macros completely, because
>> > a) we can't use them in device drivers
>> > b) all platform code is supposed to be in drivers
>> > c) both rules are enforced for arm64
>>
>> I fully agree. As I said, after cleaning up mach-exynos/ there should be
>> no more code left using soc_is_*() macros. Ideally, the whole
>> mach-exynos/ should collapse into a single, trivial file, with
>> everything done in dedicated drivers.
>
> Right.

Now that we have a broader agreement on this, I think we can go ahead with the
following steps as an initial approach:
1. Have a common machine file for both exynos4 and 5 files, mach-exynos-dt.c.
2. Introduce a generic compatible string "samsung,exynos".
3. Append this to the compatible property list for existing boards.

If this plan looks OK, I can send across patches doing this.

-- 
With warm regards,
Sachin

[PATCH 1/1] ARM: Exynos: Add generic compatible string

[Tomasz Figa]

On 21.02.2014 07:08, Sachin Kamat wrote:
> On 20 February 2014 23:18, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Thursday 20 February 2014 18:34:23 Tomasz Figa wrote:
>>> On 20.02.2014 18:00, Arnd Bergmann wrote:
>>>>> Of course nothing stops you from retaining more specific compatible
>>>>> strings. In fact, this is probably the most appropriate solution,
>>>>> because in future you might find out that certain SoCs need some special
>>>>> differentiation, e.g. same ID value on two SoCs.
>>>>>
>>>>> So, to apply this to our case, our Exynos 5250 based Arndale board would
>>>>> be changed from
>>>>>
>>>>> compatible = "insignal,arndale", "samsung,exynos5260";
>>>>>
>>>>> to
>>>>>
>>>>> compatible = "insignal,arndale", "samsung,exynos5260", "samsung,exynos";
>>>>
>>>> Right, this would make sense.
>>>>
>>>>> Now, the board file will be able to match simply by "samsung,exynos"
>>>>> compatible string and SoC-specific code in mach-exynos (hopefully none
>>>>> after it gets cleaned up fully) will use soc_is_exynos*() macros (what
>>>>> AFAIK it is already doing at the moment).
>>>>
>>>> On principle, I would not take things out of the match list, if that
>>>> would break booting with old DT file that don't list "samsung,exynos"
>>>> as compatible. But for new SoCs that would work.
>>>
>>> My proposal was about simply adding a fully generic string, without
>>> removing the specific ones. For already supported SoCs this is pretty
>>> obvious, as existing DTBs would not have this generic string listed. But
>>> the specific strings should be also present in DTSes of new SoCs, even
>>> if not recognized by the kernel, to make sure that in future any
>>> SoC-specific quirks could be easily handled.
>>
>> Yes, that's ideal.
>>
>>>> Using soc_is_exynos*() too much of course also isn't good. A lot of
>>>> the things tested for should probably be checked from individual DT
>>>> properties, but again we have to find the right balance. I wouldn't
>>>> mind getting rid of the soc_is_exynos*() macros completely, because
>>>> a) we can't use them in device drivers
>>>> b) all platform code is supposed to be in drivers
>>>> c) both rules are enforced for arm64
>>>
>>> I fully agree. As I said, after cleaning up mach-exynos/ there should be
>>> no more code left using soc_is_*() macros. Ideally, the whole
>>> mach-exynos/ should collapse into a single, trivial file, with
>>> everything done in dedicated drivers.
>>
>> Right.
>
> Now that we have a broader agreement on this, I think we can go ahead with the
> following steps as an initial approach:
> 1. Have a common machine file for both exynos4 and 5 files, mach-exynos-dt.c.
> 2. Introduce a generic compatible string "samsung,exynos".
> 3. Append this to the compatible property list for existing boards.
>
> If this plan looks OK, I can send across patches doing this.
>

Looks good. I would also merge common.c with this resulting 
mach-exynos-dt.c, as it would be the only user of the code there.

Best regards,
Tomasz

[PATCH 1/1] ARM: Exynos: Add generic compatible string

[Arnd Bergmann]

On Friday 21 February 2014 14:18:49 Tomasz Figa wrote:
> 
> > Now that we have a broader agreement on this, I think we can go ahead with the
> > following steps as an initial approach:
> > 1. Have a common machine file for both exynos4 and 5 files, mach-exynos-dt.c.
> > 2. Introduce a generic compatible string "samsung,exynos".
> > 3. Append this to the compatible property list for existing boards.
> >
> > If this plan looks OK, I can send across patches doing this.
> >
> 
> Looks good. I would also merge common.c with this resulting 
> mach-exynos-dt.c, as it would be the only user of the code there.

Sounds good. While the naming is not important, I would just call the
file 'exynos.c', in line with some of the other platforms we have.
Both the 'mach-' and the '-dt' part of the file name are redundant.

Alternatively, you could merge it all into common.c.

	Arnd

[PATCH 1/1] ARM: Exynos: Add generic compatible string

[Tomasz Figa]

On 21.02.2014 15:48, Arnd Bergmann wrote:
> On Friday 21 February 2014 14:18:49 Tomasz Figa wrote:
>>
>>> Now that we have a broader agreement on this, I think we can go ahead with the
>>> following steps as an initial approach:
>>> 1. Have a common machine file for both exynos4 and 5 files, mach-exynos-dt.c.
>>> 2. Introduce a generic compatible string "samsung,exynos".
>>> 3. Append this to the compatible property list for existing boards.
>>>
>>> If this plan looks OK, I can send across patches doing this.
>>>
>>
>> Looks good. I would also merge common.c with this resulting
>> mach-exynos-dt.c, as it would be the only user of the code there.
>
> Sounds good. While the naming is not important, I would just call the
> file 'exynos.c', in line with some of the other platforms we have.
> Both the 'mach-' and the '-dt' part of the file name are redundant.
>
> Alternatively, you could merge it all into common.c.

exynos.c sounds good to me.

Best regards,
Tomasz

[PATCH 1/1] ARM: Exynos: Add generic compatible string

[Tomasz Figa]

On 21.02.2014 16:21, Tomasz Figa wrote:
> On 21.02.2014 15:48, Arnd Bergmann wrote:
>> On Friday 21 February 2014 14:18:49 Tomasz Figa wrote:
>>>
>>>> Now that we have a broader agreement on this, I think we can go
>>>> ahead with the
>>>> following steps as an initial approach:
>>>> 1. Have a common machine file for both exynos4 and 5 files,
>>>> mach-exynos-dt.c.
>>>> 2. Introduce a generic compatible string "samsung,exynos".
>>>> 3. Append this to the compatible property list for existing boards.
>>>>
>>>> If this plan looks OK, I can send across patches doing this.
>>>>
>>>
>>> Looks good. I would also merge common.c with this resulting
>>> mach-exynos-dt.c, as it would be the only user of the code there.
>>
>> Sounds good. While the naming is not important, I would just call the
>> file 'exynos.c', in line with some of the other platforms we have.
>> Both the 'mach-' and the '-dt' part of the file name are redundant.
>>
>> Alternatively, you could merge it all into common.c.
>
> exynos.c sounds good to me.

One minor thing. It might be a good idea to base on top of my PM 
consolidation part 2 series, to avoid merge conflicts:

http://thread.gmane.org/gmane.linux.ports.arm.kernel/299340

It should hit Kgene's tree this weekend.

Best regards,
Tomasz

[PATCH 1/1] ARM: Exynos: Add generic compatible string

[Sachin Kamat]

On 21 February 2014 21:01, Tomasz Figa <t.figa@samsung.com> wrote:
> On 21.02.2014 16:21, Tomasz Figa wrote:
>>
>> On 21.02.2014 15:48, Arnd Bergmann wrote:
>>>
>>> On Friday 21 February 2014 14:18:49 Tomasz Figa wrote:
>>>>
>>>>
>>>>> Now that we have a broader agreement on this, I think we can go
>>>>> ahead with the
>>>>> following steps as an initial approach:
>>>>> 1. Have a common machine file for both exynos4 and 5 files,
>>>>> mach-exynos-dt.c.
>>>>> 2. Introduce a generic compatible string "samsung,exynos".
>>>>> 3. Append this to the compatible property list for existing boards.
>>>>>
>>>>> If this plan looks OK, I can send across patches doing this.
>>>>>
>>>>
>>>> Looks good. I would also merge common.c with this resulting
>>>> mach-exynos-dt.c, as it would be the only user of the code there.
>>>
>>>
>>> Sounds good. While the naming is not important, I would just call the
>>> file 'exynos.c', in line with some of the other platforms we have.
>>> Both the 'mach-' and the '-dt' part of the file name are redundant.
>>>
>>> Alternatively, you could merge it all into common.c.
>>
>>
>> exynos.c sounds good to me.
>
>
> One minor thing. It might be a good idea to base on top of my PM
> consolidation part 2 series, to avoid merge conflicts:
>
> http://thread.gmane.org/gmane.linux.ports.arm.kernel/299340
>
> It should hit Kgene's tree this weekend.

Sure.

-- 
With warm regards,
Sachin

[PATCH 1/1] ARM: Exynos: Add generic compatible string

[Kukjin Kim]

On 02/24/14 21:03, Sachin Kamat wrote:
> On 21 February 2014 21:01, Tomasz Figa<t.figa@samsung.com>  wrote:
>> On 21.02.2014 16:21, Tomasz Figa wrote:
>>>
>>> On 21.02.2014 15:48, Arnd Bergmann wrote:
>>>>
>>>> On Friday 21 February 2014 14:18:49 Tomasz Figa wrote:
>>>>>
>>>>>
>>>>>> Now that we have a broader agreement on this, I think we can go
>>>>>> ahead with the
>>>>>> following steps as an initial approach:
>>>>>> 1. Have a common machine file for both exynos4 and 5 files,
>>>>>> mach-exynos-dt.c.
>>>>>> 2. Introduce a generic compatible string "samsung,exynos".

Well, I think, we need to consider to use compatible string 
"samsung,exynos" again because "exynos" name can be used on ARMv8 as 
well and I don't want to say that generic/common something is always 
good. So IMHO still using exynos4 and exynos5 would be better.

>>>>>> 3. Append this to the compatible property list for existing boards.
>>>>>>
>>>>>> If this plan looks OK, I can send across patches doing this.
>>>>>>
>>>>>
>>>>> Looks good. I would also merge common.c with this resulting
>>>>> mach-exynos-dt.c, as it would be the only user of the code there.
>>>>
>>>>
>>>> Sounds good. While the naming is not important, I would just call the
>>>> file 'exynos.c', in line with some of the other platforms we have.
>>>> Both the 'mach-' and the '-dt' part of the file name are redundant.
>>>>
>>>> Alternatively, you could merge it all into common.c.
>>>
>>>
>>> exynos.c sounds good to me.
>>

Well, let me see common.c and mach-exynos.c, one is for SoC specific 
stuff and the other is for Board specific so I think, keeping current 
file would be good, we can change the file name mach-exynos.c or 
board-exynos.c though.

Thanks,
Kukjin

>>
>> One minor thing. It might be a good idea to base on top of my PM
>> consolidation part 2 series, to avoid merge conflicts:
>>
>> http://thread.gmane.org/gmane.linux.ports.arm.kernel/299340
>>
>> It should hit Kgene's tree this weekend.
>
> Sure.
>

[PATCH 1/1] ARM: Exynos: Add generic compatible string

[Tomasz Figa]

On 25.02.2014 01:35, Kukjin Kim wrote:
> On 02/24/14 21:03, Sachin Kamat wrote:
>> On 21 February 2014 21:01, Tomasz Figa<t.figa@samsung.com>  wrote:
>>> On 21.02.2014 16:21, Tomasz Figa wrote:
>>>>
>>>> On 21.02.2014 15:48, Arnd Bergmann wrote:
>>>>>
>>>>> On Friday 21 February 2014 14:18:49 Tomasz Figa wrote:
>>>>>>
>>>>>>
>>>>>>> Now that we have a broader agreement on this, I think we can go
>>>>>>> ahead with the
>>>>>>> following steps as an initial approach:
>>>>>>> 1. Have a common machine file for both exynos4 and 5 files,
>>>>>>> mach-exynos-dt.c.
>>>>>>> 2. Introduce a generic compatible string "samsung,exynos".
>
> Well, I think, we need to consider to use compatible string
> "samsung,exynos" again because "exynos" name can be used on ARMv8 as
> well and I don't want to say that generic/common something is always
> good. So IMHO still using exynos4 and exynos5 would be better.

You can create a new compatible string (e.g. "samsung,exynos-armv8") for 
ARMv8 Exynos if support for one in mainline shows up and/or simply use 
another name for ARMv7 Exynos (e.g. "samsung,exynos-armv7").

>>>>>>> 3. Append this to the compatible property list for existing boards.
>>>>>>>
>>>>>>> If this plan looks OK, I can send across patches doing this.
>>>>>>>
>>>>>>
>>>>>> Looks good. I would also merge common.c with this resulting
>>>>>> mach-exynos-dt.c, as it would be the only user of the code there.
>>>>>
>>>>>
>>>>> Sounds good. While the naming is not important, I would just call the
>>>>> file 'exynos.c', in line with some of the other platforms we have.
>>>>> Both the 'mach-' and the '-dt' part of the file name are redundant.
>>>>>
>>>>> Alternatively, you could merge it all into common.c.
>>>>
>>>>
>>>> exynos.c sounds good to me.
>>>
>
> Well, let me see common.c and mach-exynos.c, one is for SoC specific
> stuff and the other is for Board specific so I think, keeping current
> file would be good, we can change the file name mach-exynos.c or
> board-exynos.c though.

There is no board specific stuff in mach-exynos/ with DT, so there is no 
need to keep those file separate, especially when stuff from common.c is 
constantly being (re)moved.

Also I'd rather stick to what other platforms use, which would be 
exynos.c (like tegra.c), as Arnd proposed.

Best regards,
Tomasz

[PATCH 1/1] ARM: Exynos: Add generic compatible string

[Kukjin Kim]

On 02/25/14 09:52, Tomasz Figa wrote:
> On 25.02.2014 01:35, Kukjin Kim wrote:

[...]

>> Well, let me see common.c and mach-exynos.c, one is for SoC specific
>> stuff and the other is for Board specific so I think, keeping current
>> file would be good, we can change the file name mach-exynos.c or
>> board-exynos.c though.
>
> There is no board specific stuff in mach-exynos/ with DT, so there is no
> need to keep those file separate, especially when stuff from common.c is
> constantly being (re)moved.
>
OK.

> Also I'd rather stick to what other platforms use, which would be
> exynos.c (like tegra.c), as Arnd proposed.
>
agreed. OK.

- Kukjin

[PATCH 1/1] ARM: Exynos: Add generic compatible string

[Sachin Kamat]

On 25 February 2014 06:22, Tomasz Figa <tomasz.figa@gmail.com> wrote:
> On 25.02.2014 01:35, Kukjin Kim wrote:
>>
>> On 02/24/14 21:03, Sachin Kamat wrote:
>>>
>>> On 21 February 2014 21:01, Tomasz Figa<t.figa@samsung.com>  wrote:
>>>>
>>>> On 21.02.2014 16:21, Tomasz Figa wrote:
>>>>>
>>>>>
>>>>> On 21.02.2014 15:48, Arnd Bergmann wrote:
>>>>>>
>>>>>>
>>>>>> On Friday 21 February 2014 14:18:49 Tomasz Figa wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Now that we have a broader agreement on this, I think we can go
>>>>>>>> ahead with the
>>>>>>>> following steps as an initial approach:
>>>>>>>> 1. Have a common machine file for both exynos4 and 5 files,
>>>>>>>> mach-exynos-dt.c.
>>>>>>>> 2. Introduce a generic compatible string "samsung,exynos".
>>
>>
>> Well, I think, we need to consider to use compatible string
>> "samsung,exynos" again because "exynos" name can be used on ARMv8 as
>> well and I don't want to say that generic/common something is always
>> good. So IMHO still using exynos4 and exynos5 would be better.
>
>
> You can create a new compatible string (e.g. "samsung,exynos-armv8") for
> ARMv8 Exynos if support for one in mainline shows up and/or simply use
> another name for ARMv7 Exynos (e.g. "samsung,exynos-armv7").

I think "samsung,exynos-armv7" would be better in case we need to
distinguish between
v7 and v8.

-- 
With warm regards,
Sachin

[PATCH 1/1] ARM: Exynos: Add generic compatible string

[Olof Johansson]

On Mon, Feb 24, 2014 at 7:03 PM, Sachin Kamat <sachin.kamat@linaro.org> wrote:
> On 25 February 2014 06:22, Tomasz Figa <tomasz.figa@gmail.com> wrote:
>> On 25.02.2014 01:35, Kukjin Kim wrote:
>>>
>>> On 02/24/14 21:03, Sachin Kamat wrote:
>>>>
>>>> On 21 February 2014 21:01, Tomasz Figa<t.figa@samsung.com>  wrote:
>>>>>
>>>>> On 21.02.2014 16:21, Tomasz Figa wrote:
>>>>>>
>>>>>>
>>>>>> On 21.02.2014 15:48, Arnd Bergmann wrote:
>>>>>>>
>>>>>>>
>>>>>>> On Friday 21 February 2014 14:18:49 Tomasz Figa wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Now that we have a broader agreement on this, I think we can go
>>>>>>>>> ahead with the
>>>>>>>>> following steps as an initial approach:
>>>>>>>>> 1. Have a common machine file for both exynos4 and 5 files,
>>>>>>>>> mach-exynos-dt.c.
>>>>>>>>> 2. Introduce a generic compatible string "samsung,exynos".
>>>
>>>
>>> Well, I think, we need to consider to use compatible string
>>> "samsung,exynos" again because "exynos" name can be used on ARMv8 as
>>> well and I don't want to say that generic/common something is always
>>> good. So IMHO still using exynos4 and exynos5 would be better.
>>
>>
>> You can create a new compatible string (e.g. "samsung,exynos-armv8") for
>> ARMv8 Exynos if support for one in mainline shows up and/or simply use
>> another name for ARMv7 Exynos (e.g. "samsung,exynos-armv7").
>
> I think "samsung,exynos-armv7" would be better in case we need to
> distinguish between
> v7 and v8.

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.

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.


-Olof

[PATCH 1/1] ARM: Exynos: Add generic compatible string

[Arnd Bergmann]

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.

	Arnd

[PATCH 1/1] ARM: Exynos: Add generic compatible string

[Sachin Kamat]

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?

-- 
With warm regards,
Sachin

[PATCH 1/1] ARM: Exynos: Add generic compatible string

[Tomasz Figa]

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.

Best regards,
Tomasz

[PATCH 1/1] ARM: Exynos: Add generic compatible string

[Sachin Kamat]

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

[PATCH 1/1] ARM: Exynos: Add generic compatible string

[Sachin Kamat]

On 21 February 2014 20:51, Tomasz Figa <t.figa@samsung.com> wrote:
> On 21.02.2014 15:48, Arnd Bergmann wrote:
>>
>> On Friday 21 February 2014 14:18:49 Tomasz Figa wrote:
>>>
>>>
>>>> Now that we have a broader agreement on this, I think we can go ahead
>>>> with the
>>>> following steps as an initial approach:
>>>> 1. Have a common machine file for both exynos4 and 5 files,
>>>> mach-exynos-dt.c.
>>>> 2. Introduce a generic compatible string "samsung,exynos".
>>>> 3. Append this to the compatible property list for existing boards.
>>>>
>>>> If this plan looks OK, I can send across patches doing this.
>>>>
>>>
>>> Looks good. I would also merge common.c with this resulting
>>> mach-exynos-dt.c, as it would be the only user of the code there.
>>
>>
>> Sounds good. While the naming is not important, I would just call the
>> file 'exynos.c', in line with some of the other platforms we have.
>> Both the 'mach-' and the '-dt' part of the file name are redundant.
>>
>> Alternatively, you could merge it all into common.c.
>
>
> exynos.c sounds good to me.

Sounds good to me too.

-- 
With warm regards,
Sachin