| Message ID | 1392809645-631-1-git-send-email-sachin.kamat@linaro.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 :)
[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 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
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 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
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.
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. > -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
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 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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?
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 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
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",
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(+)