linux-kernel - Re: [PATCH v3 032/105] drm/vc4: crtc: Enable and disable the PV in atomic_enable / disable

Open Source and information security mailing list archives

Date:   Tue, 2 Jun 2020 22:03:13 +0200
From:   Stefan Wahren <stefan.wahren@...e.com>
To:     Eric Anholt <eric@...olt.net>,
        Dave Stevenson <dave.stevenson@...pberrypi.com>,
        Maxime Ripard <maxime@...no.tech>
Cc:     Tim Gover <tim.gover@...pberrypi.com>,
        LKML <linux-kernel@...r.kernel.org>,
        DRI Development <dri-devel@...ts.freedesktop.org>,
        Nicolas Saenz Julienne <nsaenzjulienne@...e.de>,
        bcm-kernel-feedback-list@...adcom.com,
        Phil Elwell <phil@...pberrypi.com>,
        linux-arm-kernel@...ts.infradead.org,
        linux-rpi-kernel@...ts.infradead.org
Subject: Re: [PATCH v3 032/105] drm/vc4: crtc: Enable and disable the PV in
 atomic_enable / disable

Hi,

Am 02.06.20 um 21:31 schrieb Eric Anholt:
> On Tue, Jun 2, 2020 at 8:02 AM Dave Stevenson
> <dave.stevenson@...pberrypi.com> wrote:
>> Hi Maxime and Eric
>>
>> On Tue, 2 Jun 2020 at 15:12, Maxime Ripard <maxime@...no.tech> wrote:
>>> Hi Eric
>>>
>>> On Wed, May 27, 2020 at 09:54:44AM -0700, Eric Anholt wrote:
>>>> On Wed, May 27, 2020 at 8:50 AM Maxime Ripard <maxime@...no.tech> wrote:
>>>>> The VIDEN bit in the pixelvalve currently being used to enable or disable
>>>>> the pixelvalve seems to not be enough in some situations, which whill end
>>>>> up with the pixelvalve stalling.
>>>>>
>>>>> In such a case, even re-enabling VIDEN doesn't bring it back and we need to
>>>>> clear the FIFO. This can only be done if the pixelvalve is disabled though.
>>>>>
>>>>> In order to overcome this, we can configure the pixelvalve during
>>>>> mode_set_no_fb, but only enable it in atomic_enable and flush the FIFO
>>>>> there, and in atomic_disable disable the pixelvalve again.
>>>> What displays has this been tested with?  Getting this sequencing
>>>> right is so painful, and things like DSI are tricky to get to light
>>>> up.
>>> That FIFO is between the HVS and the HDMI PVs, so this was obviously
>>> tested against that. Dave also tested the DSI output IIRC, so we should
>>> be covered here.
>> DSI wasn't working on the first patch set that Maxime sent - I haven't
>> tested this one as yet but will do so.
>> DPI was working early on to both an Adafruit 800x480 DPI panel, and
>> via a VGA666 as VGA.
>> HDMI is obviously working.
>> VEC is being ignored now. The clock structure is more restricted than
>> earlier chips, so to get the required clocks for the VEC without using
>> fractional divides it compromises the clock that other parts of the
>> system can run at (IIRC including the ARM). That's why the VEC has to
>> be explicitly enabled for the firmware to enable it as the only
>> output. It's annoying, but that's just a restriction of the chip.
> I'm more concerned with "make sure we don't regress pre-pi4 with this
> series" than "pi4 displays all work from the beginning"

unfortuntely i can confirm this. With this patch series (using Maxime's
git repo with multi_v7_defconfig) my Raspberry Pi 3 B hangs up while
starting X (screen stays black, heartbeat stops, no more output at the
debug UART). AFAIR v2 didn't had this issue.

Stefan

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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives