[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ab36d90a-147a-481f-9ab6-3a027563b8ea@linaro.org>
Date: Mon, 28 Aug 2023 17:07:56 +0200
From: Konrad Dybcio <konrad.dybcio@...aro.org>
To: Doug Anderson <dianders@...omium.org>
Cc: Bjorn Andersson <andersson@...nel.org>,
Sheng-Liang Pan <sheng-liang.pan@...nta.corp-partner.google.com>,
Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
Andy Gross <agross@...nel.org>,
Conor Dooley <conor+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Rob Herring <robh+dt@...nel.org>,
cros-qcom-dts-watchers@...omium.org, devicetree@...r.kernel.org,
linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] arm64: dts: qcom: sc7180: Reorganize trogdor rt5682
audio codec dts
On 28.08.2023 17:04, Doug Anderson wrote:
> Hi,
>
> On Sat, Aug 26, 2023 at 2:36 AM Konrad Dybcio <konrad.dybcio@...aro.org> wrote:
>>
>> On 16.08.2023 20:21, Douglas Anderson wrote:
>>> It was asserted that the "/delete-property/ VBAT-supply;" that we
>>> needed to do in the rt5682s dts fragment was ugly. Let's change up all
>>> the trogdor device trees to make it explicit which version of "rt5682"
>>> we have and avoid the need for the "delete-property".
>>>
>>> As a side effect, this nicely gets rid of the need for a delete-node
>>> in coachz, which doesn't use "rt5682" at all.
>>>
>>> A few notes:
>>> - This doesn't get rid of every "/delete-node/" in trogdor, just the
>>> one that was used for rt5682s.
>>> - Though we no longer have any "/delete-node/", we do still override
>>> the "model" in the "sound" node in one case (in pompom) since that
>>> uses the "2mic" sound setup.
>>>
>>> This is validated to produce the same result (other than a few
>>> properties being reordered) when taking the dtbs generated by the
>>> kernel build and then doing:
>>>
>>> for dtb in *trogdor*.dtb; do
>>> dtc -I dtb -O dts $dtb -o out/$dtb.dts;
>>> done
>>>
>>> Suggested-by: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
>>> Signed-off-by: Douglas Anderson <dianders@...omium.org>
>>> ---
>> [...]
>>
>>> +&mdss_dsi0_phy {
>>> + qcom,phy-rescode-offset-top = /bits/ 8 <31 31 31 31 (-32)>;
>>> + qcom,phy-rescode-offset-bot = /bits/ 8 <31 31 31 31 (-32)>;
>>> + qcom,phy-drive-ldo-level = <450>;
>>> +};
>>> +
>>> +&panel {
>>> + compatible = "boe,tv110c9m-ll3";
>>> +};
>> This is odd
>
> Can you clarify why it's odd? There are two possible panels used in
> wormdignler, one with an INX display and one with a BOE display. This
> one has the BOE display.
>
> For the BOE display, there is one with the old Realtek audio codec
> (rt5682i) and one with the new Realtek audio codec (rt5682s).
>
> Previously, the BOE/rt5682s device tree could just include the
> BOE/rt5682i device tree and override the audio. ...but Krzysztof
> didn't like that. ...so now we have to duplicate the BOE bits in both
> the BOE/rt5682s and BOE/rt5682i files. We could make a fragment for
> just this bit, but that feels overboard for something that's in just
> two files.
I didn't catch that at all, thought it was an unrelated change that
sneaked in..
>
> As per my "after the cut" description, I'm not really convinced that
> the end result here is easier to understand. Some bits are clearer and
> some more complex. I simply wrote it up because it was requested.
Yeah I'm not sure either. But then I'm not sure that there is any
fantastic way to go about things with this many SKUs, all of them
just tip the dt-number-vs-duplication ratio one way or the other :/
Konrad
Powered by blists - more mailing lists