On 05/09/2016 09:38 PM, Eric Anholt wrote:
Mario Kleiner <mario.kleiner.de@xxxxxxxxx> 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.
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
