Small vc4 kms fixes and some questions.

[Mario Kleiner]

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.

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.

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?

thanks,
-mario


>> Is the drm-next tree supposed to boot and work on the Pi already.
>> To me it's a bit confusing against which tree i should actually
>> work and test if i play with patches for vc4? drm-next, one of
>> your many branches, RPi foundation? So far i was unsuccessful in
>> booting kernels i built myself following tutorials. Building worked
>> without error or warning, but booting never made it beyond the Pi's
>> firmware startup splash.
>
> drm-next won't have the devicetree necessary, but linux-next does.  I've
> been doing a lot of my development off of linux-next these days.
>
> I've been using u-boot with all of my upstream kernel development
> (netbooting, since swapping SD cards around is awful).  Apparently for
> non-uboot there was some weirdness with the firmware where you needed to
> do non-standard things to the kernel image to get it to boot, which
> u-boot's kernel included, and then u-boot could load a normal linux
> kernel.  I think that's been changed in the firmware in the last couple
> of weeks, though, so you might not need the weird scripting any more.
>