by Javier Martinez Canillas

[permalink] [raw]

Subject: Re: [PATCH v4 4/4] arm64: dts: rk3399-pinephone-pro: Add internal display support

Hello Ondřej,

Thanks a lot for your feedback.

On 12/30/22 16:37, Ondřej Jirman wrote:

[...]

>> &i2c0 {
>> clock-frequency = <400000>;
>> i2c-scl-rising-time-ns = <168>;
>> @@ -214,6 +251,9 @@ vcc3v0_touch: LDO_REG2 {
>> regulator-name = "vcc3v0_touch";
>> regulator-min-microvolt = <3000000>;
>> regulator-max-microvolt = <3000000>;
>> + regulator-state-mem {
>> + regulator-off-in-suspend;
>> + };
>
> You're instructing RK818 to shut down the regulator for touch controller during
> suspend, but I think Goodix driver expects touch controller to be kept powered on
> during suspend. Am I missing something?
>
> https://elixir.bootlin.com/linux/latest/source/drivers/input/touchscreen/goodix.c#L1405
>

You tell me, it is your patch :) I just cherry-picked this from your tree:

https://github.com/megous/linux/commit/11f8da60d6a5

But if that is not correct, then I can drop the regulator-off-in-suspend.

[...]

>> +
>> + touchscreen@14 {
>> + compatible = "goodix,gt917s";
>
> This is not the correct compatible. Pinephone Pro uses Goodix GT1158:
>
> Goodix-TS 3-0014: ID 1158, version: 0100
> Goodix-TS 3-0014: Direct firmware load for goodix_1158_cfg.bin failed with error -2
>
>

Same thing. I wasn't aware of this since your patch was using this compatible
string. If "goodix,gt1158" is the correct compatible string, then I agree we
should have that instead even when the firmware is missing. Because the DT is
supposed to describe the hardware. The FW issue can be tackled as a follow-up.

[...]

>> +
>> +&vopb {
>> + status = "okay";
>> + assigned-clocks = <&cru DCLK_VOP0_DIV>, <&cru DCLK_VOP0>,
>> + <&cru ACLK_VOP0>, <&cru HCLK_VOP0>;
>> + assigned-clock-rates = <0>, <0>, <400000000>, <100000000>;
>> + assigned-clock-parents = <&cru PLL_CPLL>, <&cru DCLK_VOP0_FRAC>;
>> +};
>
> So here you're putting a fractional clock into path between CPLL -> VOP0_DIV
> -> DCLK_VOP0_FRAC -> DCLK_VOP0.
>
> Fractional clocks require 20x difference between input and output rates, and
> CPLL is 800Mhz IIRC, while you require 74.25MHz DCLK, so this will not work
> correctly.
>
> Even if this somehow works by fractional clock being bypassed, I did not design
> the panel mode to be used with CPLL's 800 MHz, but with GPLL frequecy of 594 MHz.
>
> GPLL 594/74.25 = 8 (integral divider without the need for fractional clock)
> CPLL 800/74.25 = ~10.77441077441077441077
>
> If you really want to use fractional clock, you'd need to parent it to VPLL
> and set VPLL really high, like close to 2GHz.
>

Thanks for the explanation. Then I just need to squash on top of this, the
following patch. Is that correct?

https://github.com/megous/linux/commit/f19ce7bb7d72

--
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat

2023-01-01 21:55:31

On 1/2/23 16:20, Ondřej Jirman wrote:
> On Mon, Jan 02, 2023 at 02:51:42PM +0100, Javier Martinez Canillas wrote:
>> Hello Ondřej,
>>
>> [...]
>>
>> My goal was to have some initial support in mainline even if there could be some
>> issues. IMO it is better to use upstream as a baseline and attempt to support the
>> PPP incrementally.
>>
>> But since you are aware of the issues and know what are the available fixes, I'll
>> let you continue with the effort and take care of the patches. Hopefully there may
>> be things that will be helpful, such as the binding schema patch and the collected
>> tags. I can also take care of pushing the DRM bits to the drm-misc-next tree once
>> you feel that those are ready to get merged.
>
> Ok. The panel driver itself works fine with some changes in other DRM drivers.
> In fact, it will not need any changes, assuming the to be proposed fixes to
> dw-mipi-dsi will pass, too. So I don't have many objections against this driver
> itself.
>

Exactly, that is what I was trying to say. Awesome that you agree with that.

> I'm not sure I should be giving reviewed-by to driver I co-wrote. :) Anyway,

Indeed :)

> I checked it again, and only issue I found was that shutdown callback tries
> to disable the panel even if it may already be disabled, which will lead to
> unbalanced calls to regulator_disable functions, which may produce some needless
> warnings on shutdown/reboot.
>
> So if you want to commit this driver now, go ahead. DT will need one more round.
>
> As you say, the overall usable support for Pinephone Pro in mainline is still
> way off into the future, so I agree it's not necessary to get hung up on these
> issues. I can do a DT revision + add in the other suggested DRM patches, so that
> there's at least a searchable public record of the remaining issues.
>

Perfect, sounds like a plan. I'll re-spin a v5 that only includes the panel
patches then and drop the DTS. Thanks again for your feedback and comments!

--
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat