[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87jzz2rrfr.fsf@minerva.mail-host-address-is-not-set>
Date: Mon, 27 Mar 2023 20:15:52 +0200
From: Javier Martinez Canillas <javierm@...hat.com>
To: Ondřej Jirman <megi@....cz>
Cc: Heiko Stübner <heiko@...ech.de>,
linux-kernel@...r.kernel.org,
Robert Mader <robert.mader@...labora.com>,
Laurent Pinchart <laurent.pinchart@...asonboard.com>,
Peter Robinson <pbrobinson@...il.com>,
Jacopo Mondi <jacopo.mondi@...asonboard.com>,
Martijn Braam <martijn@...xit.nl>,
Kamil Trzciński <ayufan@...fan.eu>,
Caleb Connolly <kc@...tmarketos.org>,
Jarrah Gosbell <kernel@...ef.tools>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Rob Herring <robh+dt@...nel.org>,
Tom Fitzhenry <tom@...-fitzhenry.me.uk>,
devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-rockchip@...ts.infradead.org
Subject: Re: [PATCH v2] arm64: dts: rk3399-pinephone-pro: Add internal
display support
Ondřej Jirman <megi@....cz> writes:
> On Mon, Mar 27, 2023 at 06:15:55PM +0200, Javier Martinez Canillas wrote:
[...]
>>
>> It is broken though? This is what is in Ondrej downstream tree and I see
>> no issues on my Pinephone Pro. He mentioned some flicker when looking at
>> the signals with a scope and hooking a photoresistor.
>
> LED regulator is driven out of spec by a frequency that's 20x lower than
> recommended, if you want short version of what's broken about the DT patch.
>
>> But that's fair. I'll let Ondrej then post a v3 if he wants to address the
>> issues he pointed out, since is his patch after all.
>
> It's not my patch. Original author of the DT is Martijn or Kamil. I just carry
> their DT work in split-up patches in my tree, and I sometimes try to find solutions
> to bugs I find when using PPP. That's the story of these DT changes you're posting.
>
> Since you posted this DT patch for upstreaming, I wanted to help you by reviewed
> it more completely, so I opened the schematic and datasheets for the components
> that are described in this patch, and discovered these new issues I commented
> about. And I also tested it on top of linus/master.
>
> Just because something is in my tree doesn't mean it's mine, or that I reviewed
> it in detail and prepared it for upstreaming, or that I'm interested in
Thanks for the clarification. Because the patch had your authorship I
wrongly assumed that came from you. Sorry about the confusion.
> upstreaming it. I'm just trying to help you with your upstreaming effort by
> testing and review since I got to know the hardware quite well over the last
> years and can check the schematics and datasheets quickly, and I like to think
> upstream code is held to higher standard. That's all.
>
Appreciate your help and I agree that upstream code should be held to a
high standard. But since the DTS in mainline is pretty basic anyways (you
can only boot to serial right now), is not really usable for other thing
than development and keep adding the missing support.
So I thought that we could do it in steps without creating that much work
for the people trying to post the downstream patches and having to re-spin
too many times.
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
Powered by blists - more mailing lists