[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200612153558.3ekadlu3e2qctvf6@gilmour.lan>
Date: Fri, 12 Jun 2020 17:35:58 +0200
From: Maxime Ripard <maxime@...no.tech>
To: Eric Anholt <eric@...olt.net>
Cc: Dave Stevenson <dave.stevenson@...pberrypi.com>,
Nicolas Saenz Julienne <nsaenzjulienne@...e.de>,
DRI Development <dri-devel@...ts.freedesktop.org>,
linux-rpi-kernel@...ts.infradead.org,
bcm-kernel-feedback-list@...adcom.com,
linux-arm-kernel@...ts.infradead.org,
LKML <linux-kernel@...r.kernel.org>,
Tim Gover <tim.gover@...pberrypi.com>,
Phil Elwell <phil@...pberrypi.com>
Subject: Re: [PATCH v3 032/105] drm/vc4: crtc: Enable and disable the PV in
atomic_enable / disable
Hi Eric,
On Tue, Jun 02, 2020 at 12:31:37PM -0700, Eric Anholt wrote:
> 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"
I tested the DSI today on an RPI3, and I had to fix an issue with the
HVS-PV muxing, but otherwise it works with this series. Otherwise, the
HDMI and TXP work on the Pi3 too, I'll give a try to the VGA adapter on
it next week to test DPI too.
As a side note, my DSI display without my patches gives DSI transfer
timeouts at boot, since at least (mainline) 5.4, I haven't tested
further back. It just stalls the modeset for a while, but the display
works fine after that.
Does that ring any bell?
Maxime
Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)
Powered by blists - more mailing lists