Re: [PATCH 33/33] drm/panel-simple: Fix dotclock for LG ACX467AKM-7

[Jonathan Marek <jonathan@marek.ca>]

What Xorg prints doesn't mean anything. I don't think there will be 
errors in dmesg, you need to run something that does pageflips as fast 
as possible and see that the refresh rate is still 60. (modetest with 
-v, glmark-drm are examples)

On 3/3/20 7:26 AM, Brian Masney wrote:
> On Mon, Mar 02, 2020 at 10:36:54PM -0500, Jonathan Marek wrote:
>> Another thing: did you verify that the panel still runs at 60hz (and not
>> dropping frames to 30hz)? IIRC that was the behavior with lower clock.
> 
> Yes, the panel is running at 60 HZ according to the Xorg log with
> Ville's patch applied:
> 
>      modeset(0): Modeline "1080x1920"x60.0  125.50  1080 1082 1084 1086
>      1920 1922 1924 1926 (115.6 kHz eP)
> 
> I verified there's no underflow errors in dmesg.
> 
> If I recall correctly, the clock speeds that was in your tree was set
> too low for the gpu_opp_table (that wouldn't cause this issue), but I
> seem to recall there were some other clock speed mismatches. The
> bandwidth requests weren't set on the RPM as well, so maybe that
> contributed to the problem. That's done upstream with the msm8974
> interconnect driver:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/interconnect/qcom/msm8974.c
> 
> There's a separate known issue with 'pp done time out' errors that
> occur on the framebuffer that started upstream several months ago with
> the introduction of async commit support in the MSM driver. I tried
> working around this by enabling the autorefresh feature but it's not
> fully working yet and I hit a dead end since there's no docs available
> publicly for this. The grim details are at:
> 
> https://lore.kernel.org/lkml/20191230020053.26016-2-masneyb@onstation.org/
> 
> So I'm still OK with Ville's patch going in.
> 
> Brian
> 
> 
>>
>> On 3/2/20 10:28 PM, Jonathan Marek wrote:
>>>
>>> On 3/2/20 10:13 PM, Brian Masney wrote:
>>>> On Mon, Mar 02, 2020 at 03:48:22PM -0500, Jonathan Marek wrote:
>>>>> Hi,
>>>>>
>>>>> This is a command mode panel and the the msm/mdp5 driver uses
>>>>> the vrefresh
>>>>> field for the actual refresh rate, while the dotclock field is
>>>>> used for the
>>>>> DSI clocks. The dotclock needed to be a bit higher than
>>>>> necessary otherwise
>>>>> the panel would not work.
>>>>>
>>>>> If you want to get rid of the separate clock/vrefresh fields there would
>>>>> need to be some changes to msm driver.
>>>>>
>>>>> (note I hadn't made the patch with upstreaming in mind, the
>>>>> 150000 value is
>>>>> likely not optimal, just something that worked, this is something that
>>>>> should have been checked with the downstream driver)
>>>>
>>>> Is this the right clock frequency in the downstream MSM 3.4 kernel that
>>>> you're talking about?
>>>>
>>>> https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/arch/arm/mach-msm/clock-8974.c#L3326
>>>>
>>>>
>>>
>>> No, I'm talking about the DSI clock (the driver for it is in
>>> drm/msm/dsi/). For a command mode panel the front/back porches aren't
>>> relevant, but the dsi pixel/byte clock need to be a bit higher than
>>> 1920x1080x60. Since 125498 is a little higher than 124416 that might be
>>> enough (there is also rounding of the clock values to consider).
>>>
>>>> I don't see any obvious clock values in the downstream command mode
>>>> panel configuration:
>>>>
>>>> https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/arch/arm/boot/dts/msm8974-hammerhead/msm8974-hammerhead-panel.dtsi#L591
>>>>
>>>>
>>>> Anyways, I tried Ville's patch with the framebuffer, kmscube, and X11
>>>> and everything appears to be working fine. You can add my Tested-by if
>>>> you end up applying this.
>>>>
>>>> Tested-by: Brian Masney <masneyb@onstation.org>
>>>>
>>>> Brian
>>>>
>>>>
>>>>> On 3/2/20 3:34 PM, Ville Syrjala wrote:
>>>>>> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>>>>>>
>>>>>> The currently listed dotclock disagrees with the currently
>>>>>> listed vrefresh rate. Change the dotclock to match the vrefresh.
>>>>>>
>>>>>> Someone tell me which (if either) of the dotclock or vreresh is
>>>>>> correct?
>>>>>>
>>>>>> Cc: Jonathan Marek <jonathan@marek.ca>
>>>>>> Cc: Brian Masney <masneyb@onstation.org>
>>>>>> Cc: Linus Walleij <linus.walleij@linaro.org>
>>>>>> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
>>>>>> ---
>>>>>>     drivers/gpu/drm/panel/panel-simple.c | 2 +-
>>>>>>     1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/drivers/gpu/drm/panel/panel-simple.c
>>>>>> b/drivers/gpu/drm/panel/panel-simple.c
>>>>>> index b24fdf239440..f958d8dfd760 100644
>>>>>> --- a/drivers/gpu/drm/panel/panel-simple.c
>>>>>> +++ b/drivers/gpu/drm/panel/panel-simple.c
>>>>>> @@ -3996,7 +3996,7 @@ static const struct panel_desc_dsi
>>>>>> panasonic_vvx10f004b00 = {
>>>>>>     };
>>>>>>     static const struct drm_display_mode lg_acx467akm_7_mode = {
>>>>>> -    .clock = 150000,
>>>>>> +    .clock = 125498,
>>>>>>         .hdisplay = 1080,
>>>>>>         .hsync_start = 1080 + 2,
>>>>>>         .hsync_end = 1080 + 2 + 2,
>>>>>>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel