[PATCH] ASoC: dt-bindings: wm8753: Convert to dtschema
Convert the WM8753 audio codec bindings to DT schema.
Signed-off-by: Saalim Quadri danascape@gmail.com --- .../devicetree/bindings/sound/wlf,wm8753.yaml | 62 +++++++++++++++++++ .../devicetree/bindings/sound/wm8753.txt | 40 ------------ 2 files changed, 62 insertions(+), 40 deletions(-) create mode 100644 Documentation/devicetree/bindings/sound/wlf,wm8753.yaml delete mode 100644 Documentation/devicetree/bindings/sound/wm8753.txt
diff --git a/Documentation/devicetree/bindings/sound/wlf,wm8753.yaml b/Documentation/devicetree/bindings/sound/wlf,wm8753.yaml new file mode 100644 index 000000000000..9eebe7d7f0b7 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/wlf,wm8753.yaml @@ -0,0 +1,62 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/wlf,wm8753.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: WM8753 audio CODEC + +description: | + Pins on the device (for linking into audio routes): + * LOUT1 + * LOUT2 + * ROUT1 + * ROUT2 + * MONO1 + * MONO2 + * OUT3 + * OUT4 + * LINE1 + * LINE2 + * RXP + * RXN + * ACIN + * ACOP + * MIC1N + * MIC1 + * MIC2N + * MIC2 + * Mic Bias + +maintainers: + - patches@opensource.cirrus.com + +allOf: + - $ref: dai-common.yaml# + +properties: + compatible: + const: wlf,wm8753 + + reg: + maxItems: 1 + + "#sound-dai-cells": + const: 0 + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + codec@1a { + compatible = "wlf,wm8753"; + reg = <0x1a>; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/wm8753.txt b/Documentation/devicetree/bindings/sound/wm8753.txt deleted file mode 100644 index eca9e5a825a9..000000000000 --- a/Documentation/devicetree/bindings/sound/wm8753.txt +++ /dev/null @@ -1,40 +0,0 @@ -WM8753 audio CODEC - -This device supports both I2C and SPI (configured with pin strapping -on the board). - -Required properties: - - - compatible : "wlf,wm8753" - - - reg : the I2C address of the device for I2C, the chip select - number for SPI. - -Pins on the device (for linking into audio routes): - - * LOUT1 - * LOUT2 - * ROUT1 - * ROUT2 - * MONO1 - * MONO2 - * OUT3 - * OUT4 - * LINE1 - * LINE2 - * RXP - * RXN - * ACIN - * ACOP - * MIC1N - * MIC1 - * MIC2N - * MIC2 - * Mic Bias - -Example: - -wm8753: codec@1a { - compatible = "wlf,wm8753"; - reg = <0x1a>; -};
On 15/04/2023 00:38, Saalim Quadri wrote:
Convert the WM8753 audio codec bindings to DT schema.
Signed-off-by: Saalim Quadri danascape@gmail.com
.../devicetree/bindings/sound/wlf,wm8753.yaml | 62 +++++++++++++++++++ .../devicetree/bindings/sound/wm8753.txt | 40 ------------
Guys,
You choose unusual bindings to convert to DT schema. It is fine but honestly, less useful, with limited impact. This is an old, 12 year old binding without users. Maybe it would be even removed by now...
I suggest converting ones which have a real impact - have users in DTS. Otherwise you will be putting quite a lot of effort for no real gains... because what is the difference between this binding being TXT and DT schema?
2 files changed, 62 insertions(+), 40 deletions(-) create mode 100644 Documentation/devicetree/bindings/sound/wlf,wm8753.yaml delete mode 100644 Documentation/devicetree/bindings/sound/wm8753.txt
Reviewed-by: Krzysztof Kozlowski krzysztof.kozlowski@linaro.org
Best regards, Krzysztof
You choose unusual bindings to convert to DT schema. It is fine but honestly, less useful, with limited impact. This is an old, 12 year old binding without users. Maybe it would be even removed by now... I suggest converting ones which have a real impact - have users in DTS. Otherwise you will be putting quite a lot of effort for no real gains... because what is the difference between this binding being TXT and DT schema?
I am converting these bindings as part of my GSoC project where I need to convert as many files as possible during the given tenure, I am slowly trying to read files in other subsystems too and will push patches for other subsystems too. Is it fine?
About the part where you suggested to convert the txt into a single YAML, shall I continue working on them? As I can see Mark merged the previous 2 patches to linux-next
Kind Regards,
Saalim
On 15/04/2023 22:12, Saalim Quadri wrote:
You choose unusual bindings to convert to DT schema. It is fine but honestly, less useful, with limited impact. This is an old, 12 year old binding without users. Maybe it would be even removed by now... I suggest converting ones which have a real impact - have users in DTS. Otherwise you will be putting quite a lot of effort for no real gains... because what is the difference between this binding being TXT and DT schema?
I am converting these bindings as part of my GSoC project where I need to convert as many files as possible during the given tenure, I am slowly trying to read files in other subsystems too and will push patches for other subsystems too. Is it fine?
In general it is fine. I wonder if we can change the goal of GSoC? I am surprised that such goal was chosen in the first place. Converting old, unused bindings to DT schema is okay, but it would be much better to do this for the bindings which are actually used.
Because I still wonder - what is the difference between this binding being TXT and DT schema?
About the part where you suggested to convert the txt into a single YAML, shall I
The bindings were incomplete, so after adding missing pieces they could stay probably as separate bindings.
continue working on them? As I can see Mark merged the previous 2 patches to linux-next
Best regards, Krzysztof
On 16/04/2023 09:35, Krzysztof Kozlowski wrote:
On 15/04/2023 22:12, Saalim Quadri wrote:
You choose unusual bindings to convert to DT schema. It is fine but honestly, less useful, with limited impact. This is an old, 12 year old binding without users. Maybe it would be even removed by now... I suggest converting ones which have a real impact - have users in DTS. Otherwise you will be putting quite a lot of effort for no real gains... because what is the difference between this binding being TXT and DT schema?
I am converting these bindings as part of my GSoC project where I need to convert as many files as possible during the given tenure, I am slowly trying to read files in other subsystems too and will push patches for other subsystems too. Is it fine?
In general it is fine. I wonder if we can change the goal of GSoC? I am surprised that such goal was chosen in the first place. Converting old, unused bindings to DT schema is okay, but it would be much better to do this for the bindings which are actually used.
Because I still wonder - what is the difference between this binding being TXT and DT schema?
BTW,
If you want to find used bindings and tasks to do, check Rob's bot output:
https://gitlab.com/robherring/linux-dt/-/jobs/4118960859 https://gitlab.com/robherring/linux-dt/-/jobs/4118960858
I pointed to these jobs two months ago when Daniel was looking for some feedback.
Best regards, Krzysztof
Thank you for that, I will take a look and soon push the patches for bindings that are actually being used.
Kind Regards,
Saalim
On Fri, Apr 14, 2023 at 10:38:01PM +0000, Saalim Quadri wrote:
Convert the WM8753 audio codec bindings to DT schema.
Signed-off-by: Saalim Quadri danascape@gmail.com
Acked-by: Charles Keepax ckeepax@opensource.cirrus.com
Thanks, Charles
On Fri, 14 Apr 2023 22:38:01 +0000, Saalim Quadri wrote:
Convert the WM8753 audio codec bindings to DT schema.
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/1] ASoC: dt-bindings: wm8753: Convert to dtschema commit: 59de6c38d713bb16760cc2612a79bc373f79bc6b
All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying to this mail.
Thanks, Mark
participants (4)
-
Charles Keepax -
Krzysztof Kozlowski -
Mark Brown -
Saalim Quadri