[alsa-devel] [PATCH] ASoC: fsl-asrc: Convert to use regmap framework's endianness method.
Mark Rutland
mark.rutland at arm.com
Mon Aug 18 14:21:41 CEST 2014
On Mon, Aug 18, 2014 at 01:03:14PM +0100, Li.Xiubo at 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 endian
> >> - mode 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 device
> >> + registers.
> >> + See Documentation/devicetree/bindings/regmap/regmap.txt
> >> + for 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.
More information about the Alsa-devel
mailing list