From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-176.mta1.migadu.com (out-176.mta1.migadu.com [95.215.58.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 57ACC263F25 for ; Fri, 14 Feb 2025 12:42:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.176 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1739536931; cv=none; b=ng61cKkXilq/FH0iuOMPoWgODM5qNGjsmqwUQnRsu47EuIyzPekUdRG+1NJ1uX/IOuqv1+9FoUo8l0YJS3dP8tF8J5mZM17EMSGcTprs0QYLglGa3uLBYcecVzr2P7+PArSxBXxTS/mceXJXqLfMsRD6K3h5SswoZkDrfUpIPEI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1739536931; c=relaxed/simple; bh=Lgm54ypC3Xw13cFe84CkEda526EsxKI+I0wTtJzS2kM=; h=Message-ID:Date:MIME-Version:From:Subject:To:Cc:References: In-Reply-To:Content-Type; b=Lf141zQNsd/SA5/mmvBGrKwCo0ubiluMzqsgjk5w1cyOKBQkJxfst7nuCv5BbtX5hOja7FVhAgQ08CTHbotwlOmwxdXBiYg8wRw7ZYarpfGenw/+mHSGuj5zmbGBO/6gNnvlQOPAROO5jZEXukGUqBNXluaMS7B/t4+Rm1RrJH0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=K/LZvksN; arc=none smtp.client-ip=95.215.58.176 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="K/LZvksN" Message-ID: <062b78a3-7e83-4202-a753-4e7bd43e8bc2@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1739536924; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=TmoaaQDA6QHoK5d//GwIdE1FQgIBFCuZsGqbpAtEteg=; b=K/LZvksNFFiUrhXDWrfGZ6wnfWWXw1lTTN6Ee4nsCPd47TEooPFEB3jleQYXkJe3DkUEH+ hIJBUBj1e2ldbdCtsVKKPiX6JM4590naTHtJOwl/SBtSczRghhj7ZnuZNQQFmoM6aQK5Uk XY2kEp7H56jZXDsvyiBJNp6y3CZylY4= Date: Fri, 14 Feb 2025 18:11:11 +0530 Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Aradhya Bhatia Subject: Re: [PATCH v5 2/3] dt-bindings: display: ti: Add schema for AM625 OLDI Transmitter To: Tomi Valkeinen Cc: Maarten Lankhorst , Thomas Zimmermann , Maxime Ripard , David Airlie , Laurent Pinchart , Simona Vetter , Nishanth Menon , Vignesh Raghavendra , Devarsh Thakkar , Praneeth Bajjuri , Udit Kumar , Jayesh Choudhary , Francesco Dolcini , DRI Development List , Devicetree List , Linux Kernel List , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Jyri Sarha References: <20250209160925.380348-1-aradhya.bhatia@linux.dev> <20250209160925.380348-3-aradhya.bhatia@linux.dev> <16db8f3d-04a2-408a-964f-4cf9478229b4@ideasonboard.com> <8c6e790e-f1b6-46ab-9acf-bdea8076405b@linux.dev> Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT Hi Tomi, On 13/02/25 18:50, Tomi Valkeinen wrote: > Hi, > > On 13/02/2025 14:33, Aradhya Bhatia wrote: > >>>> +  ti,companion-oldi: >>>> +    $ref: /schemas/types.yaml#/definitions/phandle >>>> +    description: >>>> +      phandle to companion OLDI transmitter. This property is >>>> mandatory for the >>>> +      primarty OLDI TX if the OLDI TXes are expected to work either >>>> in dual-lvds >>>> +      mode or in clone mode. This property should point to the >>>> secondary OLDI >>>> +      TX. >>>> + >>>> +  ti,secondary-oldi: >>>> +    type: boolean >>>> +    description: >>>> +      Boolean property to mark the OLDI transmitter as the secondary >>>> one, when the >>>> +      OLDI hardware is expected to run as a companion HW, in cases of >>>> dual-lvds >>>> +      mode or clone mode. The primary OLDI hardware is responsible >>>> for all the >>>> +      hardware configuration. >>> >>> I think these work, but I'm wondering if we would ever need to check >>> something from the main oldi from the secondary oldi. In that case >>> "crossed phandles" would be better, i.e. something like: >>> >>> (in the first oldi:) >>> ti,slave-oldi = >>> >>> (in the second oldi:) >>> ti,master-oldi = >> >> When I had first designed the code and the devicetree for OLDI, it was >> done so with the belief that we wouldn't reqiure a bridge instance for >> the secondary OLDI, at all. >> >> While that idea holds true for dual-lvds configuration, it doesn't so >> for the clone mode configuration. For clone mode, as you pointed out, we >> will require a 2nd bridge instance to configure any of the bridges and >> panels that come after the 2nd OLDI. >> >> >>> >>> Then again, if we ever need that, even with these bindings the driver >>> could find the first oldi, but needs to go via the dss's node. >> >> While it is possible to do it this way, it might not be the cleanest >> one. And _if_ there is a ever a DSS in future with more than 2 OLDI >> TXes, say 4, then the decipher logic may get too complicated. >> >> While I cannot think of any case where the secondary OLDI bridge DT >> might need to access the primary OLDI bridge at the moment, I wonder if >> we should play it safer and have this option anyway. >> >> Maybe something like this? >> >> (primary OLDI) >> ti,primary-oldi; >> ti,companion-oldi = ; >> >> (secondary OLDI) >> ti,secondary-oldi; >> ti,companion-oldi = ; > > How is this different than my proposal, except a bit more verbose? That's all the difference there is. Just an alternative to what you suggested. > > If you're thinking about a 4-OLDI hardware, how would this work there? I didn't mean that my alternative would be more helpful. I meant that passing phandles would be a simpler way for 4-OLDI hardware in general. We'd have to sift through a max of 4 OLDI nodes to find the right primary OLDI for a given secondary OLDI - if we try to find it via the dss and oldi-transmitter parent DT nodes. Passing phandles directly would save on all that logic. > (but I want to say that even if it's good to plan for the future, we > shouldn't plan too much based on imaginary hardware =). > That's, of course, true too! =) It's been tricky enough dealing with the hardware combinations as they are today! I will add one more reason though, which made me get along with the idea of passing phandles. And then I will defer to you to make the call, since I don't have the strongest of feelings either way. Passing phandles would allow for _that_ condition to get dropped; making the bindings slightly more flexible to accommodate for any future surprises (especially around the clone mode lvds configuration). (That condition being where the bindings either allow a companion-oldi phandle OR allow the secondary-oldi boolean (but not both)). I could drop that condition without any other changes too, making the companion-oldi property optional for secondary-oldi - but this feels incomplete. Hence, the addition of the primary-oldi boolean. The companion-oldi phandle property will be conditionally required when any one of the boolean properties is present. -- Regards Aradhya