Received-SPF: pass (google.com: domain of linux-kernel+bounces-34698-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Feedback-ID: i1f8241ce:Fastmail
Message-ID: <93d775df-af84-44ff-870e-f720a33ddf34@feathertop.org>
Date: Tue, 23 Jan 2024 15:10:35 +1100
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 2/3] dt-bindings: rockchip: rk809: Document audio codec
 properties
Content-Language: en-US
To: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
 linux-rockchip@lists.infradead.org, conor.dooley@microchip.com,
 robh+dt@kernel.org, devicetree@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org, Chris Zhong <zyw@rock-chips.com>,
 Conor Dooley <conor+dt@kernel.org>, Heiko Stuebner <heiko@sntech.de>,
 Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
 Lee Jones <lee@kernel.org>, Zhang Qing <zhangqing@rock-chips.com>,
 linux-kernel@vger.kernel.org
References: <20240120135529.899403-1-tim@feathertop.org>
 <20240120135529.899403-3-tim@feathertop.org>
 <04ccf5f5-1f02-42f9-b1fc-b781c54d7ae9@linaro.org>
From: Tim Lunn <tim@feathertop.org>
In-Reply-To: <04ccf5f5-1f02-42f9-b1fc-b781c54d7ae9@linaro.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit


On 1/22/24 19:14, Krzysztof Kozlowski wrote:
> On 20/01/2024 14:55, Tim Lunn wrote:
>> Rockchip RK809 shares the same audio codec block as the rk817 mfd, and
>> is compatible with the existing rk817_codec driver.
> Please use subject prefixes matching the subsystem. You can get them for
> example with `git log --oneline -- DIRECTORY_OR_FILE` on the directory
> your patch is touching.
Ok I will check this.
>
>> This patch introduces to the binding the standard property #sound-dai-cells
>> and also an optional codec child node to hold codec specific properties.
>> Currently there is only one property in this node however the downstream
>> driver shows a number of other properties that are supported by the codec
>> hardware, that could be implemented in the future. This maintains the
>> existing driver ABI and keeps consistency with the rk817 bindings.
> So you are adding a new node? Just for one property? No, just put it
> into parent node.
The existing upstream codec driver parses the property from the "codec" 
sub-node, if I
move it to the parent node here, I will need to patch the codec driver 
to search in both locations,
so as to not break the rk817 bindings.  If that is preferred, I can do 
it that way.
>
> Downstream driver does not matter at all in that aspect.
>
The codec hardware supports additional properties but they are not 
implemented currently in
upstream driver.


>
> Best regards,
> Krzysztof
>