Small vc4 kms fixes and some questions.

[Mario Kleiner]

On 05/13/2016 08:51 PM, Eric Anholt wrote:
> Mario Kleiner  writes:
>
>> On 05/09/2016 09:38 PM, Eric Anholt wrote:
>>> Mario Kleiner  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 1 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).
>

Yes. You can observe it also as a symptom with async pageflips, where 
the return from flip is async, but the display still doesn't tear.

>> 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_IDLEBIT(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.
>

Thanks for the detailed explanation Eric. The way this is designed is 
almost as if the Broadcom hw engineers had read our DRM vblank handling 
and DRI swap scheduling code and decided to build the hw to exactly 
match the expectations of our code :)

This means that my patch for pageflip completion robustness should be 
perfectly robust and not subject to races with the hardware :) - My 
testing over many runs of 1's of flips confirms that. I've sent the 
patch out for review, cc'ed to you, and it should be fine as is for 
inclusion if you are happy with it.

>> 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 

Small vc4 kms fixes and some questions.

[Eric Anholt]

Mario Kleiner  writes:

> On 05/09/2016 09:38 PM, Eric Anholt wrote:
>> Mario Kleiner  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 1 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_IDLEBIT(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: 

Small vc4 kms fixes and some questions.

[Mario Kleiner]

On 05/09/2016 09:38 PM, Eric Anholt wrote:
> Mario Kleiner  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 1 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_IDLEBIT(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.
>

Small vc4 kms fixes and some questions.

[Eric Anholt]

Mario Kleiner  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.

> 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.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: 

Small vc4 kms fixes and some questions.

[Mario Kleiner]

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?

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.

What worked in the end was using Adafruits kernel-o-matic to build
the 4.4.8 kernel, using their "automated building a kernel for dummies"
method. Their 4.8 kernel however locked up after boot as soon as kms
started.

thanks,
-mario