[alsa-devel] [PATCH 4/5] ASoC: samsung: Document compatible strings for Odroid X/X2, Odroid XU3
There are no significant differences across Odroid X, Odroid-X2, Odroid-U3 and Odroid-XU3 with regards to the audio subsystem so add more entries to the compatible strings list.
Signed-off-by: Sylwester Nawrocki s.nawrocki@samsung.com --- Documentation/devicetree/bindings/sound/samsung,odroid.txt | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/samsung,odroid.txt b/Documentation/devicetree/bindings/sound/samsung,odroid.txt index f35a2694eb04..a50a0c6a354b 100644 --- a/Documentation/devicetree/bindings/sound/samsung,odroid.txt +++ b/Documentation/devicetree/bindings/sound/samsung,odroid.txt @@ -1,8 +1,10 @@ -Samsung Exynos Odroid XU3/XU4 audio complex with MAX98090 codec +Hardkernel Odroid X/X2/U3/XU3/XU4 audio complex with MAX98090 codec
Required properties:
- - compatible - "hardkernel,odroid-xu3-audio" - for Odroid XU3 board, + - compatible - "hardkernel,odroid-u3-audio" - for Odroid U3 board, + "hardkernel,odroid-x-audio" - for Odroid X, Odroid X2 boards, + "hardkernel,odroid-xu3-audio" - for Odroid XU3 board, "hardkernel,odroid-xu4-audio" - for Odroid XU4 board - model - the user-visible name of this sound complex - clocks - should contain entries matching clock names in the clock-names
The driver can also support Odroid X/X2 and Odroid U3 without further modifications so related compatible strings are added to the list.
Signed-off-by: Sylwester Nawrocki s.nawrocki@samsung.com --- sound/soc/samsung/odroid.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/sound/soc/samsung/odroid.c b/sound/soc/samsung/odroid.c index e7b371b07230..f4fa0312e8c8 100644 --- a/sound/soc/samsung/odroid.c +++ b/sound/soc/samsung/odroid.c @@ -202,6 +202,8 @@ static int odroid_audio_remove(struct platform_device *pdev) }
static const struct of_device_id odroid_audio_of_match[] = { + { .compatible = "hardkernel,odroid-x-audio" }, + { .compatible = "hardkernel,odroid-u3-audio" }, { .compatible = "hardkernel,odroid-xu3-audio" }, { .compatible = "hardkernel,odroid-xu4-audio" }, { .compatible = "samsung,odroid-xu3-audio" },
On Wed, Mar 14, 2018 at 5:42 PM, Sylwester Nawrocki s.nawrocki@samsung.com wrote:
There are no significant differences across Odroid X, Odroid-X2, Odroid-U3 and Odroid-XU3 with regards to the audio subsystem so add more entries to the compatible strings list.
Signed-off-by: Sylwester Nawrocki s.nawrocki@samsung.com
Documentation/devicetree/bindings/sound/samsung,odroid.txt | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/samsung,odroid.txt b/Documentation/devicetree/bindings/sound/samsung,odroid.txt index f35a2694eb04..a50a0c6a354b 100644 --- a/Documentation/devicetree/bindings/sound/samsung,odroid.txt +++ b/Documentation/devicetree/bindings/sound/samsung,odroid.txt @@ -1,8 +1,10 @@ -Samsung Exynos Odroid XU3/XU4 audio complex with MAX98090 codec +Hardkernel Odroid X/X2/U3/XU3/XU4 audio complex with MAX98090 codec
Required properties:
- compatible - "hardkernel,odroid-xu3-audio" - for Odroid XU3 board,
- compatible - "hardkernel,odroid-u3-audio" - for Odroid U3 board,
"hardkernel,odroid-x-audio" - for Odroid X, Odroid X2 boards,"hardkernel,odroid-xu3-audio" - for Odroid XU3 board, "hardkernel,odroid-xu4-audio" - for Odroid XU4 board
These are the same so I think they should not get separate compatibles. By definition [2] the compatible expresses the compatibility with family of devices. In this case - these belong to the same family.
The same applies to patch 5/5 (implementation of this).
Best regards, Krzysztof
[1] DeviceTree specification v0.2: "They allow a device to express its compatibility with a family of similar devices, potentially allowing a single device driver to match against several devices."
On Fri, Mar 16, 2018 at 08:37:28AM +0100, Krzysztof Kozlowski wrote:
On Wed, Mar 14, 2018 at 5:42 PM, Sylwester Nawrocki
- compatible - "hardkernel,odroid-xu3-audio" - for Odroid XU3 board,
- compatible - "hardkernel,odroid-u3-audio" - for Odroid U3 board,
"hardkernel,odroid-x-audio" - for Odroid X, Odroid X2 boards,"hardkernel,odroid-xu3-audio" - for Odroid XU3 board, "hardkernel,odroid-xu4-audio" - for Odroid XU4 board
These are the same so I think they should not get separate compatibles. By definition [2] the compatible expresses the compatibility with family of devices. In this case - these belong to the same family.
The same applies to patch 5/5 (implementation of this).
I don't see a problem with adding the compatibles - the software handling might be identical but it's not really causing a problem to explicit document which board it is if people want. It may end up coming in useful at some point if there's some mechanical/plastics difference which ends up being useful to handle (though that's much less likely for dev boards like this than for finished products). But equally it's not essential, whatever you two decide.
On 03/16/2018 08:37 AM, Krzysztof Kozlowski wrote:
diff --git a/Documentation/devicetree/bindings/sound/samsung,odroid.txt b/Documentation/devicetree/bindings/sound/samsung,odroid.txt index f35a2694eb04..a50a0c6a354b 100644 --- a/Documentation/devicetree/bindings/sound/samsung,odroid.txt +++ b/Documentation/devicetree/bindings/sound/samsung,odroid.txt @@ -1,8 +1,10 @@ -Samsung Exynos Odroid XU3/XU4 audio complex with MAX98090 codec +Hardkernel Odroid X/X2/U3/XU3/XU4 audio complex with MAX98090 codec
Required properties:
- compatible - "hardkernel,odroid-xu3-audio" - for Odroid XU3 board,
- compatible - "hardkernel,odroid-u3-audio" - for Odroid U3 board,
"hardkernel,odroid-x-audio" - for Odroid X, Odroid X2 boards,"hardkernel,odroid-xu3-audio" - for Odroid XU3 board, "hardkernel,odroid-xu4-audio" - for Odroid XU4 boardThese are the same so I think they should not get separate compatibles. By definition [2] the compatible expresses the compatibility with family of devices. In this case - these belong to the same family.
The same applies to patch 5/5 (implementation of this).
Given that everything except XU4 is already obsoleted, are we going to use "hardkernel,odroid-xu3-audio" for Odroid X and Odroid U3?
We could also make it: "hardkernel,odroid-xu3-audio", "hardkernel,odroid-x-audio" - for Odroid X, Odroid X2 "hardkernel,odroid-xu3-audio", "hardkernel,odroid-u3-audio" - for Odroid U3
And in the driver wee would only have "hardkernel,odroid-xu3-audio", while dts would contain detailed compatible.
On Mon, Mar 19, 2018 at 11:17 AM, Sylwester Nawrocki s.nawrocki@samsung.com wrote:
On 03/16/2018 08:37 AM, Krzysztof Kozlowski wrote:
diff --git a/Documentation/devicetree/bindings/sound/samsung,odroid.txt b/Documentation/devicetree/bindings/sound/samsung,odroid.txt index f35a2694eb04..a50a0c6a354b 100644 --- a/Documentation/devicetree/bindings/sound/samsung,odroid.txt +++ b/Documentation/devicetree/bindings/sound/samsung,odroid.txt @@ -1,8 +1,10 @@ -Samsung Exynos Odroid XU3/XU4 audio complex with MAX98090 codec +Hardkernel Odroid X/X2/U3/XU3/XU4 audio complex with MAX98090 codec
Required properties:
- compatible - "hardkernel,odroid-xu3-audio" - for Odroid XU3 board,
- compatible - "hardkernel,odroid-u3-audio" - for Odroid U3 board,
"hardkernel,odroid-x-audio" - for Odroid X, Odroid X2 boards,"hardkernel,odroid-xu3-audio" - for Odroid XU3 board, "hardkernel,odroid-xu4-audio" - for Odroid XU4 boardThese are the same so I think they should not get separate compatibles. By definition [2] the compatible expresses the compatibility with family of devices. In this case - these belong to the same family.
The same applies to patch 5/5 (implementation of this).
Given that everything except XU4 is already obsoleted, are we going to use "hardkernel,odroid-xu3-audio" for Odroid X and Odroid U3?
We could also make it: "hardkernel,odroid-xu3-audio", "hardkernel,odroid-x-audio" - for Odroid X, Odroid X2 "hardkernel,odroid-xu3-audio", "hardkernel,odroid-u3-audio" - for Odroid U3
And in the driver wee would only have "hardkernel,odroid-xu3-audio", while dts would contain detailed compatible.
Add only these compatibles which are different. If the binding is the same, then there is no point of adding new compatible.
If such difference in binding appears, then it is not a problem to add new compatible. It is however more difficult to remove or change existing binding...
Best regards, Krzysztof
participants (3)
-
Krzysztof Kozlowski -
Mark Brown -
Sylwester Nawrocki