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@xxxxxxxxxxx> 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 devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
