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

[Jonathan Marek <jonathan@marek.ca>]

modetest should be printing "freq: 60.0Hz", so definitely something 
wrong there. Though I guess you have another problem since I would 
expect the patch to drop it to 30 and not 13.5.

(FYI glmark-x11 isn't vsynced which is why I specifically mentioned 
glmark-drm)

On 3/3/20 9:16 PM, Brian Masney wrote:
> On Tue, Mar 03, 2020 at 08:04:05AM -0500, Jonathan Marek wrote:
>> 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)
> 
> I assume that you mean modetest from
> https://gitlab.freedesktop.org/mesa/drm/tree/master/tests/modetest ?
> Here's the modeset connector information:
> 
> id   encoder status      name    size (mm)  modes   encoders
> 32   31      connected   DSI-1   62x110     1       31
>    modes:
>          index name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot)
>    #0 1080x1920 71.71 1080 1082 1084 1086 1920 1922 1924 1926 150000
>    flags: ; type: preferred, driver
> 
> And the page flip results...
> 
> $ modetest -v -s 32:1080x1920
> trying to open device 'msm'...done
> setting mode 1080x1920-71.71Hz@XR24 on connectors 32, crtc 50
> failed to set gamma: Function not implemented
> freq: 13.50Hz
> freq: 13.51Hz
> freq: 13.51Hz
> 
> It's the same results with and without Ville's patch.
> 
> Here's the beginning of the glmark2 results with the x11-gl flavor:
> 
> =======================================================
>      glmark2 2017.07
> =======================================================
>      OpenGL Information
>      GL_VENDOR:     freedreno
>      GL_RENDERER:   FD330
>      GL_VERSION:    3.1 Mesa 20.0.0-devel
> =======================================================
> [build] use-vbo=false: FPS: 26 FrameTime: 38.462 ms
> [build] use-vbo=true: FPS: 26 FrameTime: 38.462 ms
> [texture] texture-filter=nearest: FPS: 26 FrameTime: 38.462 ms
> [texture] texture-filter=linear: FPS: 26 FrameTime: 38.462 ms
> [texture] texture-filter=mipmap: FPS: 27 FrameTime: 37.037 ms
> [shading] shading=gouraud: FPS: 27 FrameTime: 37.037 ms
> [shading] shading=blinn-phong-inf: FPS: 27 FrameTime: 37.037 ms
> [shading] shading=phong: FPS: 27 FrameTime: 37.037 ms
> [shading] shading=cel: FPS: 26 FrameTime: 38.462 ms
> [bump] bump-render=high-poly: FPS: 27 FrameTime: 37.037 ms
> [bump] bump-render=normals: FPS: 27 FrameTime: 37.037 ms
> [bump] bump-render=height: FPS: 27 FrameTime: 37.037 ms
> [effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 25 FrameTime: 40.000 ms
> [effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 26 FrameTime:
>   38.462 ms
> [pulsar] light=false:quads=5:texture=false: FPS: 26 FrameTime: 38.462 ms
> [desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4:
>   FPS: 26 FrameTime: 38.462 ms
> [desktop] effect=shadow:windows=4: FPS: 27 FrameTime: 37.037 ms
> ...
> 
> Brian
> 
> 
>>
>> 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