Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <7120dfd4-305f-69ac-fee8-123196ed06a9@redhat.com>
Date:   Sat, 31 Dec 2022 16:15:24 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.5.0
Subject: Re: [PATCH v4 2/4] drm: panel: Add Himax HX8394 panel controller
 driver
Content-Language: en-US
To:     =?UTF-8?Q?Ond=c5=99ej_Jirman?= <megi@xff.cz>,
        linux-kernel@vger.kernel.org,
        =?UTF-8?Q?Kamil_Trzci=c5=84ski?= <ayufan@ayufan.eu>,
        Martijn Braam <martijn@brixit.nl>,
        Sam Ravnborg <sam@ravnborg.org>,
        Robert Mader <robert.mader@posteo.de>,
        Tom Fitzhenry <tom@tom-fitzhenry.me.uk>,
        Peter Robinson <pbrobinson@gmail.com>,
        Onuralp Sezer <thunderbirdtr@fedoraproject.org>,
        dri-devel@lists.freedesktop.org,
        Maya Matuszczyk <maccraft123mc@gmail.com>,
        Neal Gompa <ngompa13@gmail.com>,
        linux-arm-kernel@lists.infradead.org,
        Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
        Jagan Teki <jagan@amarulasolutions.com>,
        Daniel Vetter <daniel@ffwll.ch>,
        David Airlie <airlied@gmail.com>,
        Thierry Reding <thierry.reding@gmail.com>
References: <20221230113155.3430142-1-javierm@redhat.com>
 <20221230113155.3430142-3-javierm@redhat.com>
 <20221230154043.7v3zmzqdrnouqzd2@core>
From:   Javier Martinez Canillas <javierm@redhat.com>
In-Reply-To: <20221230154043.7v3zmzqdrnouqzd2@core>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Precedence: bulk

Hello Ondřej,

Thanks a lot for your comments.

On 12/30/22 16:40, Ondřej Jirman wrote:
> Hi Javier,
> 
> On Fri, Dec 30, 2022 at 12:31:52PM +0100, Javier Martinez Canillas wrote:
>> From: Kamil Trzciński <ayufan@ayufan.eu>
>>
>> The driver is for panels based on the Himax HX8394 controller, such as the
>> HannStar HSD060BHW4 720x1440 TFT LCD panel that uses a MIPI-DSI interface.
> 
> I see you've removed debug printks from enable/disable/prepare/unprepare

Yes, because as you said were debug printks. Feel free to propose adding the
debug printks if you consider useful for normal usage and not just for devel
purposes.

> hooks. Have you tested the driver thoroughly with various DRM apps,
> with DPM/suspend/resume, etc.?
>

I did not. I wasn't expecting suspend and resume to work on the PPP given its
support is quite minimal currently.
 
> The dw-mipi-dsi driver does some unorthodox things[1], that can lead to unbalanced
> calls to these functions in some situations, and that's why all these printks
> were there. To ensure the driver hooks are called correctly, while preparing
> the code for upstreaming. This lead to broken display in some situations during
> suspend/resume.
> 
> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c#L868
>

This needs to be fixed in the dw-mipi-dsi driver then. But at least we will get
a panel-himax-hx8394 driver in mainline to avoid having to use downstream trees
for development and testing.

> Also, have you checked the clocks are actually configured correctly by the
> rk3399 cru driver? I have a lot of trouble with that, too. clk driver sometimes
> selects the fractional clock, but does not give it the necessary >20x difference
> between input/output clock rates. You'll only notice if you measure clock rates
> directly, by looking at actual refresh rate, by using some testing DRM app.
> Clock subsystem sometimes shuffles things around if you switch VOPs and use big
> VOP for mipi-dsi display, instead of the default small VOP.
>

I have not. Just verified that the display was working on my PPP and could start
a mutter wayland session. We could fix the clock configuration as follow-up IMO.

> I'll test this patchset in a few days against purely mainline code, but I'm
> pretty sure looking at the modes you use, that this will not work on some
> Pinephone Pro's, and will cause display corruption when you fix your clock
> setup, so that CRU actually outputs 74.25MHz as requested by the mode. (Which
> can be fixed by this patch https://github.com/megous/linux/commit/f7ee16f12ee8a44ee2472f2967ca27768106e00f)
> 

As mentioned, I prefer to make the support incremental. First having the panel
driver and then we can fix any remaining issue as follow-up patch series.

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat