[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5b253a9e13397304d3ca556ebf770b65b1dcb534.camel@collabora.com>
Date: Thu, 13 Mar 2025 08:41:21 +0100
From: Julien Massot <julien.massot@...labora.com>
To: Laurentiu Palcu <laurentiu.palcu@....nxp.com>
Cc: Mauro Carvalho Chehab <mchehab@...nel.org>, Rob Herring
<robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
<conor+dt@...nel.org>, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-media@...r.kernel.org
Subject: Re: [PATCH 3/5] dt-bindings: i2c: maxim,max96717: add new properties
Hi Laurentiu,
> > >
> > > + maxim,override-mode:
> > > + description: Toggle the operation mode from the pin configured one.
> > > + type: boolean
> > I understand that this property is intended to flip the GMSL link mode between
> > pixel and tunnel mode.
> > What about adding a property 'maxim,tunnel-mode' to the GMSL 'port@1'.
> > Here the MAX96717 only have one GMSL port but other devices, such as MAX96724 can
> > have 2 GMSL link and may have each link in different mode.
>
> I'm OK with moving the property inside "port@1". But I have some
> concerns about the logic. So. 'maxim,tunnel-mode' presence would
> indicate that we want to force the functioning mode to "tunnel". But
> what if it's absent? Do we use the pin configuration? What if the pin
> configuration is "tunnel" and the user wants to override the mode to
> "pixel"? In this case 'maxim,tunnel-mode' doesn't really work...
> Am I missing something here?
>
>
> What about maxim,gmsl2-mode that could be either TUNNEL or PIXEL, if the
property is missing then just run with the pin configured mode.
Regards,
--
Julien
Powered by blists - more mailing lists