diff mbox

[5/6] ARM: DTS: da850-evm: Add node for tlv320aic3106 codec

Message ID 1406801934-23334-6-git-send-email-peter.ujfalusi@ti.com (mailing list archive)
State New, archived
Headers show

Commit Message

Peter Ujfalusi July 31, 2014, 10:18 a.m. UTC
The board uses aic3106 for audio.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
 arch/arm/boot/dts/da850-evm.dts | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

Comments

Sergei Shtylyov July 31, 2014, 2:24 p.m. UTC | #1
Hello.

On 07/31/2014 02:18 PM, Peter Ujfalusi wrote:

> The board uses aic3106 for audio.

> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
> ---
>   arch/arm/boot/dts/da850-evm.dts | 14 ++++++++++++++
>   1 file changed, 14 insertions(+)

> diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
> index 09118c72e83f..b9ef2be0b145 100644
> --- a/arch/arm/boot/dts/da850-evm.dts
> +++ b/arch/arm/boot/dts/da850-evm.dts
> @@ -51,6 +51,20 @@
>   			tps: tps@48 {
>   				reg = <0x48>;
>   			};
> +			tlv320aic3106: tlv320aic3106@1b {

    The "reg" property is <0x18>, why the unit-address part of a name is 
different? Also, the ePAPR standard [1] says:

The name of a node should be somewhat generic, reflecting the function of the 
device and not its precise programming model.

> +				#sound-dai-cells = <0>;
> +				compatible = "ti,tlv320aic3106";
> +				reg = <0x18>;
> +				status = "okay";
> +
> +				/* Regulators */
> +				IOVDD-supply = <&vdcdc2_reg>;
> +				/* Derived from VBAT: Baseboard 3.3V / 1.8V */
> +				AVDD-supply = <&vbat>;
> +				DRVDD-supply = <&vbat>;
> +				DVDD-supply = <&vbat>;
> +			};
> +

[1] http://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf

WBR, Sergei
Peter Ujfalusi Aug. 1, 2014, 5:22 a.m. UTC | #2
On 07/31/2014 05:24 PM, Sergei Shtylyov wrote:
> Hello.
> 
> On 07/31/2014 02:18 PM, Peter Ujfalusi wrote:
> 
>> The board uses aic3106 for audio.
> 
>> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
>> ---
>>   arch/arm/boot/dts/da850-evm.dts | 14 ++++++++++++++
>>   1 file changed, 14 insertions(+)
> 
>> diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
>> index 09118c72e83f..b9ef2be0b145 100644
>> --- a/arch/arm/boot/dts/da850-evm.dts
>> +++ b/arch/arm/boot/dts/da850-evm.dts
>> @@ -51,6 +51,20 @@
>>               tps: tps@48 {
>>                   reg = <0x48>;
>>               };
>> +            tlv320aic3106: tlv320aic3106@1b {
> 
>    The "reg" property is <0x18>, why the unit-address part of a name is
> different?

True, I have lifted the codec part from other dts file and overlooked the
unit-address.
I will resend the series with this fixed.


> Also, the ePAPR standard [1] says:
> 
> The name of a node should be somewhat generic, reflecting the function of the
> device and not its precise programming model.

True. This is why the node for the audio support is named as 'sound'. For the
components, like in this case I do not see issue to call the audio codec with
it's name.

> 
>> +                #sound-dai-cells = <0>;
>> +                compatible = "ti,tlv320aic3106";
>> +                reg = <0x18>;
>> +                status = "okay";
>> +
>> +                /* Regulators */
>> +                IOVDD-supply = <&vdcdc2_reg>;
>> +                /* Derived from VBAT: Baseboard 3.3V / 1.8V */
>> +                AVDD-supply = <&vbat>;
>> +                DRVDD-supply = <&vbat>;
>> +                DVDD-supply = <&vbat>;
>> +            };
>> +
> 
> [1] http://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf

BTW: there's a newer version available:
https://www.power.org/wp-content/uploads/2012/06/Power_ePAPR_APPROVED_v1.1.pdf

> 
> WBR, Sergei
>
Sergei Shtylyov Aug. 1, 2014, 12:49 p.m. UTC | #3
Hello.

On 01-08-2014 9:22, Peter Ujfalusi wrote:

>>> The board uses aic3106 for audio.

>>> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
>>> ---
>>>    arch/arm/boot/dts/da850-evm.dts | 14 ++++++++++++++
>>>    1 file changed, 14 insertions(+)

>>> diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
>>> index 09118c72e83f..b9ef2be0b145 100644
>>> --- a/arch/arm/boot/dts/da850-evm.dts
>>> +++ b/arch/arm/boot/dts/da850-evm.dts
>>> @@ -51,6 +51,20 @@
>>>                tps: tps@48 {
>>>                    reg = <0x48>;
>>>                };
>>> +            tlv320aic3106: tlv320aic3106@1b {

[...]

>> Also, the ePAPR standard [1] says:

>> The name of a node should be somewhat generic, reflecting the function of the
>> device and not its precise programming model.

> True. This is why the node for the audio support is named as 'sound'. For the
> components, like in this case I do not see issue to call the audio codec with
> it's name.

    I do. We should follow the standard consistently. Why not call the node 
"sound-codec"?

WBR, Sergei
Peter Ujfalusi Aug. 1, 2014, 1:02 p.m. UTC | #4
On 08/01/2014 03:49 PM, Sergei Shtylyov wrote:
>    I do. We should follow the standard consistently. Why not call the node
> "sound-codec"?

Well, there is _zero_ cases when the audio codec node is named as
"sound-codec" in linux-next but we have wmXXXX, tlvXXXX, twlXXXX, maxXXXX etc.
Yeah, there are few DTS files which have codec as node name.
So, no, I'm not going to change the node name from tlv320aic3106.
Sergei Shtylyov Aug. 1, 2014, 1:13 p.m. UTC | #5
Hello.

On 08/01/2014 05:02 PM, Peter Ujfalusi wrote:

>>     I do. We should follow the standard consistently. Why not call the node
>> "sound-codec"?

> Well, there is _zero_ cases when the audio codec node is named as
> "sound-codec" in linux-next but we have wmXXXX, tlvXXXX, twlXXXX, maxXXXX etc.

    Which only means people don't read the standard (which is referred to on 
http://www.devicetree.org/Device_Tree_Usage, that says the same).

> Yeah, there are few DTS files which have codec as node name.
> So, no, I'm not going to change the node name from tlv320aic3106.

    So you prefer following the bad examples to following the standard? Well, 
"the Moor has done his duty, the Moor can go"...

WBR, Sergei
Peter Ujfalusi Aug. 1, 2014, 1:34 p.m. UTC | #6
Hi,

On 08/01/2014 04:13 PM, Sergei Shtylyov wrote:
> Hello.
> 
> On 08/01/2014 05:02 PM, Peter Ujfalusi wrote:
> 
>>>     I do. We should follow the standard consistently. Why not call the node
>>> "sound-codec"?
> 
>> Well, there is _zero_ cases when the audio codec node is named as
>> "sound-codec" in linux-next but we have wmXXXX, tlvXXXX, twlXXXX, maxXXXX etc.
> 
>    Which only means people don't read the standard (which is referred to on
> http://www.devicetree.org/Device_Tree_Usage, that says the same).
> 
>> Yeah, there are few DTS files which have codec as node name.
>> So, no, I'm not going to change the node name from tlv320aic3106.
> 
>    So you prefer following the bad examples to following the standard?

those bad examples are in the tree and they did went through the review
process (arch, DT and probably alsa). But it is interesting that we do not
have a single correct node name for audio codecs (probably for other types also).

> Well, "the Moor has done his duty, the Moor can go"...

Let's ask the DT maintainers what should be the correct approach and someone
should go through all the existing DT files and clean them up? People usually
start reading the code for examples before the standard...
Peter Ujfalusi Aug. 4, 2014, 9:09 a.m. UTC | #7
On 08/01/2014 04:34 PM, Peter Ujfalusi wrote:
> Hi,
> 
> On 08/01/2014 04:13 PM, Sergei Shtylyov wrote:
>> Hello.
>>
>> On 08/01/2014 05:02 PM, Peter Ujfalusi wrote:
>>
>>>>     I do. We should follow the standard consistently. Why not call the node
>>>> "sound-codec"?
>>
>>> Well, there is _zero_ cases when the audio codec node is named as
>>> "sound-codec" in linux-next but we have wmXXXX, tlvXXXX, twlXXXX, maxXXXX etc.
>>
>>    Which only means people don't read the standard (which is referred to on
>> http://www.devicetree.org/Device_Tree_Usage, that says the same).
>>
>>> Yeah, there are few DTS files which have codec as node name.
>>> So, no, I'm not going to change the node name from tlv320aic3106.
>>
>>    So you prefer following the bad examples to following the standard?
> 
> those bad examples are in the tree and they did went through the review
> process (arch, DT and probably alsa). But it is interesting that we do not
> have a single correct node name for audio codecs (probably for other types also).

I have thought about this over the weekend and I would keep the node name for
the codec as it is in the patch.
It is the common practice for audio and it also helps when reading the DT file
to quickly see the audio support on the board. We all use the 'sound' node
name for audio cards and when we use the name of the codec as node name we do
not need to look further in the dts file to see what is the codec in used (and
what/which cpu dai we are using). All this can be seen in the main sound
support node.

>> Well, "the Moor has done his duty, the Moor can go"...
> 
> Let's ask the DT maintainers what should be the correct approach and someone
> should go through all the existing DT files and clean them up? People usually
> start reading the code for examples before the standard...
>
diff mbox

Patch

diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
index 09118c72e83f..b9ef2be0b145 100644
--- a/arch/arm/boot/dts/da850-evm.dts
+++ b/arch/arm/boot/dts/da850-evm.dts
@@ -51,6 +51,20 @@ 
 			tps: tps@48 {
 				reg = <0x48>;
 			};
+			tlv320aic3106: tlv320aic3106@1b {
+				#sound-dai-cells = <0>;
+				compatible = "ti,tlv320aic3106";
+				reg = <0x18>;
+				status = "okay";
+
+				/* Regulators */
+				IOVDD-supply = <&vdcdc2_reg>;
+				/* Derived from VBAT: Baseboard 3.3V / 1.8V */
+				AVDD-supply = <&vbat>;
+				DRVDD-supply = <&vbat>;
+				DVDD-supply = <&vbat>;
+			};
+
 		};
 		wdt: wdt@1c21000 {
 			status = "okay";