Small vc4 kms fixes and some questions.

[Eric Anholt]

Mario Kleiner <mario.kleiner.de at gmail.com> writes:

> On 05/09/2016 09:38 PM, Eric Anholt wrote:
>> Mario Kleiner <mario.kleiner.de at gmail.com> writes:
>>
>>> Hi Eric and all,
>>>
>>> two small fixes against vc4 kms, built and tested agains the
>>> Raspberry Pi foundations 4.4.8 kernel tree on RPi2B.
>>>
>>> I'm tinkering with a Rpi 2B a bit to see if your vc4 work can
>>> already make the Pi useful as a device for some serious but low
>>> cost neuro-science applications.
>>>
>>> Eric:
>>>
>>> Is there any public documentation about the HVS hardware video scaler
>>> or the pixel valves? I could find other docs about Videocore's 3d
>>> part, but nothing about hvs or the pixel valves? Or are the register
>>> definitions inside the vc4 already all that exists in the hw?
>>
>> Nope, docs for display never got released.  I've got docs internally,
>> and I'm happy to try to answer questions.
>>
>
> Ah good. My questions are around making the pageflip completion events 
> and vblank timestamps as precise and reliable as possible.
>
> Atm. i'm working on a patch to the flip completion handling to make it 
> more robust. The current code in my stress tests with 10000 flips sends 
> out flip completions too early in about 1-2% of the trials.
>
> My current patch reduces these to 0 failures in my test. I'll send the 
> patch out later after some more tweaking and cleanup.
>
> E.g., for crtc/pixelvalve 1 the patch checks if the SCALER_DISPLIST1 and 
> SCALER_DISPLACT1 registers in the HVS match, and only then sends out the 
> pageflip completion event, otherwise waits for the next vblank. I assume 
> SCALER_DISPLACT1 is the true current value for start of active display 
> list whereas SCALER_DISPLIST1 is the value that got latched and then 
> gets committed at the next vblank after writing to the reg. This seems 
> to work well according to my special measurement equipment which can 
> timestamp the true start of display of a new framebuffer.

Oh, interesting.  The docs had said that the display lists were
re-parsed on every line, so I assumed that also meant that the reparsing
started from the head pointer every line.  I've confirmed in the
hardware what you've found: the head pointer is only latched at VSTART
or INIT signal to the display fifo (that start signal comes from the
pixel valve).

> However i don't know if this already perfect, or just strongly reduced 
> error rate, so i need to know when the value gets committed (start of 
> vblank, end of vblank, vsync)? And when does the vblank irq fire for the 
> different possible settings of:
>
> # define PV_INT_VID_IDLE                        BIT(9)
> # define PV_INT_VFP_END                         BIT(8)
> # define PV_INT_VFP_START                       BIT(7)
> # define PV_INT_VACT_START                      BIT(6)
> # define PV_INT_VBP_START                       BIT(5)
> # define PV_INT_VSYNC_START                     BIT(4)
>
> Currently the driver uses PV_INT_VFP_START.

OK, looks like the PV timing state is:

IDLE
START
(vfp lines)
VSYNC
(vsw lines)
VBP
(vbp lines)
VACT
(vact lines)
VFP
(jump to waiting for vfp lines)

The normal timing loop after START does its transitions at HFP, and
those transitions are when you get the VFP/VBP/VSYNC START/END
interrupts.

You'll jump back to IDLE almost right away if VID_EN is dropped.

The VSTART signal to the HVS is when PV does IDLE -> START or on the
last pixel of the active scanout.  Note, this is *not* the PV's START
signal, which looks like it's basically unused.  Also, I think it's an
interesting note that we don't have VFP_START on our first frame, as far
as I've found.

The PV requests that the HVS generate the next line at the last pixel of
each HACTIVE when we're either at end of VBP or VACTIVE-but-not-its-end.

> The second question is if the HVS or pixelvalves have some kind of 
> scanline register that reports the currently scanned out scanline? I'd 
> like to implement scanout position queries, so we can get instant high 
> precision vblank timestamps if possible like we have for intel, amd and 
> nouveau, so we'd have precise timestamps, a vblank counter and also 
> additional power savings. Or lacking that are there other regs that 
> could be used to timestamp vblanks or updates of display lists in the 
> hardware?

HVS has bits 0:11 of DISPSTATx for the Y line being generated.  That
will be in a different clock domain from the PV, but it's probably good
enough, right?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160513/d8d07273/attachment.sig>