On Tue, Mar 31, 2020 at 10:28:25AM +0800, Shengjiu Wang wrote:
Hi
On Tue, Mar 24, 2020 at 5:22 AM Nicolin Chen nicoleotsuka@gmail.com wrote:
On Fri, Mar 20, 2020 at 11:32:13AM -0600, Rob Herring wrote:
On Mon, Mar 09, 2020 at 02:19:44PM -0700, Nicolin Chen wrote:
On Mon, Mar 09, 2020 at 11:58:28AM +0800, Shengjiu Wang wrote:
In order to support new EASRC and simplify the code structure, We decide to share the common structure between them. This bring a problem that EASRC accept format directly from devicetree, but ASRC accept width from devicetree.
In order to align with new ESARC, we add new property fsl,asrc-format. The fsl,asrc-format can replace the fsl,asrc-width, then driver can accept format from devicetree, don't need to convert it to format through width.
Signed-off-by: Shengjiu Wang shengjiu.wang@nxp.com
Documentation/devicetree/bindings/sound/fsl,asrc.txt | 5 +++++ 1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/fsl,asrc.txt b/Documentation/devicetree/bindings/sound/fsl,asrc.txt index cb9a25165503..780455cf7f71 100644 --- a/Documentation/devicetree/bindings/sound/fsl,asrc.txt +++ b/Documentation/devicetree/bindings/sound/fsl,asrc.txt @@ -51,6 +51,11 @@ Optional properties: will be in use as default. Otherwise, the big endian mode will be in use for all the device registers.
- fsl,asrc-format : Defines a mutual sample format used by DPCM Back
Ends, which can replace the fsl,asrc-width.The value is SNDRV_PCM_FORMAT_S16_LE, orSNDRV_PCM_FORMAT_S24_LEI am still holding the concern at the DT binding of this format, as it uses values from ASoC header file instead of a dt-binding header file -- not sure if we can do this. Let's wait for Rob's comments.
I assume those are an ABI as well, so it's okay to copy them unless we
They are defined under include/uapi. So I think we can use them?
already have some format definitions for DT. But it does need to be copy in a header under include/dt-bindings/.
Shengjiu is actually quoting those integral values, rather than those macros, so actually no need copy to include/dt-bindings, yet whoever adds this format property to a new DT would need to look up the value in a header file under include/uapi. I's just wondering if that's okay.
Thanks
Shall I keep this change or drop this change?
This version of patch defines the format using those two marcos. So what Rob suggested is to copy those defines from uapi header file to dt-bindings folder. But you don't intend to do that?
My follow-up mail is to find if using integral values is doable. Yet, not seeing any reply further. I think you can make a choice to send it -- We will see how Rob acks eventually, or not.