On Mon, Aug 18, 2014 at 01:03:14PM +0100, Li.Xiubo@freescale.com wrote:
Documentation/devicetree/bindings/sound/fsl,asrc.txt | 10 +++++++--- sound/soc/fsl/fsl_asrc.c | 6 +----- 2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/fsl,asrc.txt b/Documentation/devicetree/bindings/sound/fsl,asrc.txt index b93362a..791f372 100644 --- a/Documentation/devicetree/bindings/sound/fsl,asrc.txt +++ b/Documentation/devicetree/bindings/sound/fsl,asrc.txt @@ -26,9 +26,12 @@ Required properties: "ipg" Peripheral clock to driver module. "asrck_<0-f>" Clock sources for input and output clock.
- big-endian : If this property is absent, the little endian mode
will be in use as default. Otherwise, the big endianmode will be in use for all the device registers.
- big-endian : If this property is absent, the native endian mode
(same with CPU) will be in use as default. Otherwise,the big endian mode will be in use for all the deviceregisters.See Documentation/devicetree/bindings/regmap/regmap.txtfor more detail.Why does this have to change the semantics of the DT binding?
I'm thinking that maybe in the late fulture, this device will be applied to some PowerPC SoC, from the regmap framework code, we can see that the 'big-endian' property could be ignored.
So,in this case, if it is absent, the default endian mode should be used as defualt or native as the regmap framework said.
As I have mentioned in the past w.r.t. endianness bindings, there is no such thing as a "default endianness" or "native endianness".
PowerPC and ARM can be Bi-endian, configured by the kernel.
The hardware's registers have a fixed endianness regardless of this runtime configuration.
So describe that fixed property, as that does not vary with kernel configuration (and is therefore a property of the HW rather than the combination of HW + kernel).
Thanks, Mark.