DRM Writeback connector priority changes #6345
Conversation
|
Good oh! Thanks. Do you want me to test (I'm only going to do the obvious) or are you happy that you've already done that? |
drivers/gpu/drm/vc4/vc4_kms.c
Outdated
| dsp3_mux = VC4_SET_FIELD(2, SCALER_DISPCTRL_DSP3_MUX); | ||
| if (vc4_crtc->feeds_txp) { | ||
| dsp3_mux_pri = VC4_SET_FIELD(3, SCALER_DISPCTRL_DSP3_MUX); | ||
| dsp3_mux_pri |= VC4_SET_FIELD(1, SCALER_DISPCTRL_PANIC2); |
There was a problem hiding this comment.
Any reason for this being 1 (Use panic mode for first two of the frame or if empty) rather than 0 (Fixed priority of 2’b00 (never panic).) ?
There was a problem hiding this comment.
Copied from the firmware (middleware/hvs/hvs.c)
static const uint32_t priority_0 = 0x2; // panic when <2 lines in FIFO
static const uint32_t priority_1 = 0x2; // panic when <2 lines in FIFO
static const uint32_t priority_2 = 0x1; // raised but no panic
If you think we can work with never panic, then I'm happy to switch it to that.
There was a problem hiding this comment.
The full options are:
0 = Fixed priority of 2’b00 (never panic).
1 = Use panic mode for first two of the frame or if empty.
2 = Use panic mode whenever less than two complete lines in FIFO.
3 = Fixed priority of 2’b11 (always panic).
I don't see this as real time, so I don't think it needs to panic ever.
But there could be a concern that a non-panicking memory access from a plane being fetched for writeback will hold up a following panicking access from a plane needed by HDMI, effectively killing it's priority (I don't believe there's any way to overtake).
There was a problem hiding this comment.
I know very little on how the AXI priorities are going to interact, hence just copying the firmware settings.
Happy to take guidance on which to use.
There was a problem hiding this comment.
I think logically 0 (never panic) makes sense - we are not real time when writing back, and don't want to interfere with actual real time masters like camera.
If we see the theoretical issue of low priority writeback accesses holding off subsequent high priority accesses needed by hdmi, then we can revisit (it will likely have to be the same as hdmi priority) - but I have no evidence of that actually occurring.
So, I'd recommend 0 for this PR.
Give it the quick tests that you were looking at - I've only done As per my email, there seems to be another issue lurking: I wasn't going to try fixing that under this PR, but may limit our ability to use writeback generically. That's possibly of more interest to DT than you, but thought it worth flagging. |
The transposer/writeback connector should be running with a lower priority, so shouldn't be factored into the load calculations. Signed-off-by: Dave Stevenson <[email protected]>
As the writeback connector doesn't have the same realtime constraints of a live display, drop the panic priority for it. Signed-off-by: Dave Stevenson <[email protected]>
|
I'd forgotten about updating this PR based on popcornmix's request for priority 0. Now done. |
See: raspberrypi/linux#6273 kernel: DRM Writeback connector priority changes See: raspberrypi/linux#6345 kernel: Input: matrix-keypad - don't map irqs when atomic See: raspberrypi/linux#6427
See: raspberrypi/linux#6273 kernel: DRM Writeback connector priority changes See: raspberrypi/linux#6345 kernel: Input: matrix-keypad - don't map irqs when atomic See: raspberrypi/linux#6427
@jc-kynesim
These should get the 10bittest working on Pi3.