Hi Stefan, On Tue, Jun 02, 2020 at 10:03:13PM +0200, Stefan Wahren wrote: > Am 02.06.20 um 21:31 schrieb Eric Anholt: > > On Tue, Jun 2, 2020 at 8:02 AM Dave Stevenson > > <dave.stevenson@xxxxxxxxxxxxxxx> wrote: > >> Hi Maxime and Eric > >> > >> On Tue, 2 Jun 2020 at 15:12, Maxime Ripard <maxime@xxxxxxxxxx> 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@xxxxxxxxxx> 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. Did it happen with a DSI display or something else? I've been trying to setup the DSI display on an RPi3 today, but noticed that it looks like there's a regression in next that prevents the HDMI driver to load entirely (without my patches). Maxime
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
