From mboxrd@z Thu Jan 1 00:00:00 1970 From: tixy@linaro.org (Jon Medhurst (Tixy)) Date: Wed, 22 Jun 2016 09:43:41 +0100 Subject: [PATCH 1/2] Documentation: bindings: Add DT bindings for ARM's FVP models. In-Reply-To: <20160621213318.GA32655@rob-hp-laptop> References: <1466424796-13769-1-git-send-email-tixy@linaro.org> <20160621132257.GA2263@rob-hp-laptop> <1466516312.2856.27.camel@linaro.org> <20160621213318.GA32655@rob-hp-laptop> Message-ID: <1466585021.3026.24.camel@linaro.org> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Tue, 2016-06-21 at 16:33 -0500, Rob Herring wrote: > On Tue, Jun 21, 2016 at 02:38:32PM +0100, Jon Medhurst (Tixy) wrote: > > On Tue, 2016-06-21 at 08:22 -0500, Rob Herring wrote: > > > > +Required properties (in root node): > > > > +- compatible value: > > > > + compatible = "arm,,", "arm,"; > > > > + where is one of: > > > > + - "fvp-base" for the Base FVP > > > > + - "fvp-ve" for the VE FVP > > > > + and is the part of the model's executable filename with > > > the family > > > > + name omitted, converted to lower case, and with non-alphanumeric > > > characters > > > > + replaced with '-'. E.g. the Base FVP that has two AEMv8 CPU > > > clusters has an > > > > + executable file called FVP_Base_AEMv8A-AEMv8A, so the compatible > > > value for > > > > > > Naming conventions of the exe aren't going to change? > > > > Almost certainly will at some point, as will the very name Fixed Virtual > > Platform, what 'families' ARM produce and their naming, and the > > configuration of the 'hardware' compiled into the models. > > > > These are software models, so can be changed easily at the whim of > > marketing, or current perceived requirements from engineers and > > managers. So generally, it's a moving target, that doesn't fit nicely > > into the needs producing device-trees. > > Then do we even need to specify something so specific? The kernel > probably doesn't even care. Well, it would certainly be easier if we could just use a simple 'arm,fvp' for compatible and model name and not worry about the 100 or so current variants. (Some are 32-bit, some 64-bit with just about every current ARM CPU represented, plus various peripheral sets with regard to display, iommu, dma, etc. > Are you going to upstream new strings > everytime there's a new one (that's public)? I've only been asked to upstream a device-tree for the one that ARM targets in its 'platform release' [1]. Note, all 100+ models are equally 'public' in the sense that they are available to people are pay (like real hardware supported by Linux). [1] https://community.arm.com/docs/DOC-10803) > > We've had models supported upstream for a long time. What's changed now? ARM's software releases are targeting a different model. -- Tixy