On Wed, May 03, 2017 at 12:17:38PM +0200, Freddie Chopin wrote: > Hi! > > On Mon, 2017-05-01 at 14:38 +1000, David Gibson wrote: > > There are existing CPU bindings which include additional properties > > giving lists or bitmasks of optional features. For example the PAPR > > standard requires this for guest device trees on POWER. It also > > requires that there be a 'cpu-version' property which gives the > > "logical PVR" which the OS is supposed to look at in most cases > > instead of the physically discoverable PVR register contents. This > > has applications for CPUs put into compatibility modes for > > virtualization, so the use case isn't a perfect match, but the ideas > > may be adaptable. > > > > What *is* a really good rule of thumb is don't invent a new way of > > encoding this information if you can possibly avoid it. I don't know > > if the few cases of DT being used on x86 have something similar, but > > if they do I'd expect it to use the same bitmask as the cpuid > > instruction returns. In your case, if there are existing (read only) > > registers that give the information you need, you could mirror their > > value into the device tree > > I've just browsed the manual for ARMv7-M architecture and there are 3 > read-only registers which have that info, but with a small twist (; > > If the core has single-precision FPU, MVFR0-MVFR2 register values are > 0x10110021, 0x11000011 and 0x00000000. This would be ARM Cortex-M4 with > FPv4-SP-D16 or ARM Cortex-M7 with FPv5-SP-D16. If the core has double- > precision FPU, the values of these registers are 0x10110221, 0x12000011 > and 0x00000040. This is a case for ARM Cortex-M7 with FPv5-D16. The > slight twist is when the core has no FPU at all, as in that case the > manual says these registers are not implemented at all, but I haven't > checked yet whether any attempt to read them causes a fault or just > returns zeroes. That's ok - you can encode "register not present" by simply leaving the property out, or leaving it empty (these are different and distinguishable options). > Could you point me to the binding which describes the properties you > mentioned? I couldn't find 'cpu-version' in the device-tree-rebasing > repository... That should be in the LoPAPR spec, which you can get from https://members.openpowerfoundation.org/document/dl/469 > Maybe - after all - it would be easier and more readable to have FPU as > a subnode of the CPU? Sth like: > > cpus { > cpu@0 { > compatible = "arm,cortex-m4"; > > fpu@0 { > compatible = "arm,fpv4-sp-d16"; > }; > }; > }; > > In this case it's pretty easy to extend that with an optional 'status = > "okay";' / 'status = "disabled";' for the cases where the user doesn't > want FPU to be "globally enabled" (useful when only one thread uses > FPU, so there's no point in saving its context). Urgh.. So, if this was a completely new binding for a completely new CPU, I'd say that sounds like an excellent way of doing it. But it's not. There are lots and lots of existing ARM bindings out there for lots of ARM CPUs, mostly higher end ones, many of which I presume include an FPU, but which won't have this new proposed node. This is pretty much what I mean when I say "don't invent new ways of encoding things". I think this is an argument for using "empty property" rather than "missing property" for encoding a missing FPU. That way your DT client code has these options: no property => unknown FPU state => this DT is not suitable empty property => no FPU properties present => FPU present, tells you which type In the first case you can at least error out sensibly -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
Attachment:
signature.asc
Description: PGP signature
