Re: [PATCH] ARM: dts: bcm283x: Use firmware PM driver for V3D

[Stefan Wahren <stefan.wahren@i2se.com>]

Hi Nicolas,

[adjust audience]

Am 13.03.20 um 14:59 schrieb Stefan Wahren:
> Hi Nicolas,
>
> Am 09.03.20 um 20:22 schrieb Nicolas Saenz Julienne:
>> Hi Stefan,
>>
>> On Mon, 2020-03-09 at 16:41 +0100, Stefan Wahren wrote:
>>> Hi Nicolas,
>>>
>>> On 06.03.20 21:33, Stefan Wahren wrote:
>>>> Hi Nicolas,
>>>>
>>>> Am 05.03.20 um 11:44 schrieb Nicolas Saenz Julienne:
>>>>> Hi Stefan,
>>>>>
>>>>> On Tue, 2020-03-03 at 20:24 +0100, Stefan Wahren wrote:
>>>>>>>>> Note: I tested this on RPi3b, RPi3a+ and RPi2b.
>>>>>>>> as i already wrote this prevent X to start on current Raspbian on my
>>>>>>>> Raspberry Pi 3A+ (multi_v7_defconfig, no u-boot). We must be careful
>>>>>>>> here.
>>>>>>>>
>>>>>>>> I will take a look at the debug UART. Maybe there are more helpful
>>>>>>>> information.
>>>>>>> It seems we're seeing different things, I tested this on raspbian
>>>>>>> (multi_v7_defconfig) and on arm64. I'll try again from scratch
>>>>>>> tomorrow.
>>>>>> My modifications to the Raspbian image (from 13.2.2020) are little:
>>>>>>
>>>>>> - specify devicetree to config.txt
>>>>>> - change console to ttyS1 and remove "silent" in cmdline.txt
>>>>>> - rename all original kernel7*.img
>>>>>> - copy dtb and kernel7.img to boot partition
>>>>>> - copy kernel modules to root partition
>>>>> Would you mind retesting with the latest linux-next? I validated an image
>>>>> based
>>>>> on 5.6.0-rc4-next-20200305-00001-g285a7a64cd56 and a fresh raspbian
>>>>> download on
>>>>> RPi3a+ without X issues.
>>>> i retested with todays linux-next and the issue persists on my RPi 3A+ /
>>>> HP ZR2440w with this patch applied.
>>> I tested my display with a RPI 3B, 3B+ and a Zero W. All of them had the
>>> same issue. Btw i used this display the last years for testing the
>>> Raspberry Pi.
>>>
>>> After that i connected the RPI 3B to my TV screen and it works with the
>>> patch applied.
>> Thanks for taking the time on this. I guess all we have left is looking deeper
>> into it. I'll add it to my backlog for now.

i've narrowed down the issue. From kernel 4.19 until 5.1 the DRM
emulated driver was responsible for a working X on my Raspberry Pi 3
with HP ZR2440w. Starting with 5.2 the vc4drmfb took over and with 5.3 X
didn't start anymore (display freeze).

So i start bisecting and this was the commit where the freezing started:

e08ab74bd4 drm/modes: Rewrite the command line parser

After this i enabled drm debug and saw that suggest mode 1920x1200 by
the firmware is rejected by the driver because the pixel clock would be
too high (154 MHz, max = 148.5). This wasn't a problem before since the
firmware provided video cmdline parameter wasn't parseable:

[drm] parse error at position 69 in video mode
'1920x1200M@60,margin_left=0,margin_right=0,margin_top=0,margin_bottom=0'

After mentioned commit the display just freezes (no try to use
1920x1080, no error message).

For comparison i switched to the vendor tree with firmware kms driver
and noticed that the driver switches to 1920x1200 with a pixel at 154 MHz.

So this patch works for me:

---
 drivers/gpu/drm/vc4/vc4_hdmi.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index cea18dc..647803e 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -681,11 +681,12 @@ static enum drm_mode_status
 vc4_hdmi_encoder_mode_valid(struct drm_encoder *crtc,
                 const struct drm_display_mode *mode)
 {
-    /* HSM clock must be 108% of the pixel clock.  Additionally,
-     * the AXI clock needs to be at least 25% of pixel clock, but
-     * HSM ends up being the limiting factor.
+    /* According to spec the HSM clock must be 108% of the pixel clock.
+     * Additionally, the AXI clock needs to be at least 25% of pixel clock,
+     * but HSM ends up being the limiting factor.
+     * It seems that operating the pixel clock at 154 MHz still works.
      */
-    if (mode->clock > HSM_CLOCK_FREQ / (1000 * 108 / 100))
+    if (mode->clock > HSM_CLOCK_FREQ / (1000 * 106 / 100))
         return MODE_CLOCK_HIGH;
 
     return MODE_OK;
-- 
2.7.4



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel