On 21.02.2014 07:08, Sachin Kamat wrote:
On 20 February 2014 23:18, Arnd Bergmann <arnd@xxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
