Re: [PATCH v4 3/6] arm64: dts: qcom: Add AYN QCS8550 Common

[Konrad Dybcio]

On 4/3/26 12:04 AM, Aaron Kling wrote:
> On Mon, Mar 30, 2026 at 6:32 AM Dmitry Baryshkov
> <dmitry.baryshkov@xxxxxxxxxxxxxxxx> wrote:
>>
>> On Mon, Mar 30, 2026 at 01:00:55PM +0200, Konrad Dybcio wrote:
>>> On 3/27/26 10:26 PM, Aaron Kling wrote:
>>>> On Tue, Mar 24, 2026 at 7:36 AM Konrad Dybcio
>>>> <konrad.dybcio@xxxxxxxxxxxxxxxx> wrote:
>>>>>
>>>>> On 3/23/26 5:27 PM, Aaron Kling via B4 Relay wrote:
>>>>>> From: Teguh Sobirin <teguh@xxxxxxxx>
>>>>>>
>>>>>> This contains everything common between the AYN QCS8550 devices. It will
>>>>>> be included by device specific dts'.
>>>>>>
>>>>>> Signed-off-by: Teguh Sobirin <teguh@xxxxxxxx>
>>>>>> Co-developed-by: Aaron Kling <webgeek1234@xxxxxxxxx>
>>>>>> Signed-off-by: Aaron Kling <webgeek1234@xxxxxxxxx>
>>>>>> ---
>>>>>
>>>>> [...]
>>>>>
>>>>>> +     sound {
>>>>>> +             compatible = "qcom,sm8550-sndcard", "qcom,sm8450-sndcard";
>>>>>> +             pinctrl-0 = <&lpi_i2s3_active>;
>>>>>> +             pinctrl-names = "default";
>>>>>> +
>>>>>> +             model = "AYN-Odin2";
>>>>>
>>>>> Is this enough of a distinction? Do you need to make any changes to the
>>>>> one with a HDMI bridge to get HDMI audio?
>>>>
>>>> After this quesstion, I tried to verify hdmi and am unable to even get
>>>> the connector to come up. The lt8912b driver complains that the
>>>> connector doesn't support edid read.
>>
>> Looking at the driver, please drop lt8912_bridge_edid_read(),
>> lt8912_bridge_detect() and lt->bridge.ops assignment. Those bits are
>> lame and useless.
>>
>>> Which per the current connector
>>>> node is correct, none of the devices list a ddc node. I am trying to
>>>> investigate this further, but vendor source release unfortunately
>>>> appears to be missing pieces related to this. And no other current
>>>> qcom device uses this bridge to take a guess at which controller the
>>>> ddc is on.
>>>
>>> Go through the I2C buses that are enabled on the vendor kernel and try
>>> inspecting them with toos like i2cdetect
>>
>> I'd second this suggestion. The chip doesn't support EDID reading, so it
>> is (hopefully) handled via some existing bus. Does downstream handle
>> EDID / HDMI at all?
> 
> I have been unable to get the stock OS to display anything on hdmi at
> all. The downstream kernel reports the head as DSI, and is hardcoded
> to a 1920x1080 mode in the kernel dt. We have been unable to find any
> kernel handling of this bridge at all for downstream, in the source
> release or the prebuilt kernel shipped with the stock OS. Best I can
> tell, they just hardcode the one mode and nothing else will work.
> There are reports of hdmi audio working, though; which I'm not sure
> how if the bridge has no kernel driver at all.
> 
> All i2c nodes used by downstream are already enabled. And when an hdmi
> cable is plugged in, I never see the ddc address, 0x50 if I understand
> correctly, show up on any of them. I tried enabling other i2c nodes to
> check if anything shows up on them, but that causes kernel panics
> during boot and without uart, I can't see why.
> 
> This all seems rather broken, perhaps by odm design. Given this state,
> should I just drop all references to hdmi and leave a comment in the
> dts where the bridge should be to explain why?

That's definitely better than describing (for all we know) broken hw

We can always come back to that if a fix is found

Konrad