Rotation support#5
Conversation
Signed-off-by: Hugo Osvaldo Barrera <hugo@whynothugo.nl>
My main goal was to use the Pixel Pipe for rotation, but it soon became obvious that is was the same effort to use it for all rendering, so we can have hardware-based rendering entirely, rather than CPU rendering. Used an internal API between the PxP and the EPDC, so that both rendering and rotation are done in hardware. Using the V4L2 API should be feasible too, but I have no idea how to do so and it would likely be *a lot* more code. I trust this doesn't violate any conventions: I found least one other instance of a similar approach. It's unclear to me if we need the software fallback or not. The main question is: is there any device which has this EPDC but doesn't have the same PxP? Signed-off-by: Hugo Osvaldo Barrera <hugo@whynothugo.nl>
Signed-off-by: Hugo Osvaldo Barrera <hugo@whynothugo.nl>
|
 |
|
using pxp with custom interfaces: when using pxp that way you might try to use also color to bw conversion and these pesky & 0xf0 or the shifts. That would justify such an interface. |
E-reader programs like https://github.com/baskerville/plato expect to be able to perform framebuffer rotation. Without this patch, the content's rotation doesn't match the application's expectation. The image and touch points fall out of sync.
Fair, that makes sense. I'll give it a shot and propose a standalone patch with that. |
|
using pxp with custom interfaces: do we need to keep the software-based fallback, or is it fine to assume that the pxp is available? Obviously dropping the fallback is simpler, but I have no idea if any device has a mxc-epdc and lack a pxp. |
Er, I went through the code and don't see what you mean actually. It seems that everything is done via hardware? |
sctp_stream_update() is only invoked when the association is moved into
COOKIE_WAIT during association setup/reconfiguration. In this path, the
outbound stream scheduler state (stream->out_curr) is expected to be
clean, since no user data should have been transmitted yet unless the
state machine has already partially progressed.
However, a corner case exists in sctp_sf_do_5_2_6_stale(): when a
Stale Cookie ERROR is received, the association is rolled back from
COOKIE_ECHOED to COOKIE_WAIT. In this scenario, user data may already
have been queued and even bundled with the COOKIE-ECHO chunk.
During the rollback, sctp_stream_update() frees the old stream table
and installs a new one, but it does not invalidate stream->out_curr.
As a result, out_curr may still point to a freed sctp_stream_out
entry from the previous stream state.
Later, SCTP scheduler dequeue paths (FCFS, RR, PRIO, etc.) rely on
stream->out_curr->ext, which can lead to use-after-free once the old
stream state has been released via sctp_stream_free().
This results in crashes such as (reported by Yuqi):
BUG: KASAN: slab-use-after-free in sctp_sched_fcfs_dequeue+0x13a/0x140
Read of size 8 at addr ff1100004d4d3208 by task mini_poc/9312
CPU: 1 UID: 1001 PID: 9312 Comm: mini_poc Not tainted
7.1.0-rc1-00305-gbd3a4795d574 #5 PREEMPT(full)
sctp_sched_fcfs_dequeue+0x13a/0x140
sctp_outq_flush+0x1603/0x33e0
sctp_do_sm+0x31c9/0x5d30
sctp_assoc_bh_rcv+0x392/0x6f0
sctp_inq_push+0x1db/0x270
sctp_rcv+0x138d/0x3c10
Fix this by fully purging the association outqueue when handling the
Stale Cookie case. This ensures all pending transmit and retransmit
state is dropped, and any scheduler cached pointers are invalidated,
making it safe to rebuild stream state during COOKIE_WAIT restart.
Updating only stream->out_curr would be insufficient, since queued
and retransmittable data would still reference the old stream state and
trigger later use-after-free in dequeue paths.
Fixes: 5bbbbe3 ("sctp: introduce stream scheduler foundations")
Reported-by: Yuan Tan <yuantan098@gmail.com>
Reported-by: Yifan Wu <yifanwucs@gmail.com>
Reported-by: Juefei Pu <tomapufckgml@gmail.com>
Reported-by: Zhengchuan Liang <zcliangcn@gmail.com>
Reported-by: Xin Liu <bird@lzu.edu.cn>
Reported-by: Yuqi Xu <xuyq21@lenovo.com>
Reported-by: Ren Wei <n05ec@lzu.edu.cn>
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Link: https://patch.msgid.link/94318159b9052907a6cbb7256aee8b5f8dfbfccb.1780510304.git.lucien.xin@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
…kernel/git/kvmarm/kvmarm into HEAD KVM/arm64 fixes for 7.1, take #5 - Correctly drop the ITS translation cache reference when it actually gets invalidated - Take the SRCU lock for SW page table walks - Restore POR_EL0 access to host EL0, avoiding POR_EL0 becoming inaccessible from EL0 after running a guest - Reassign nested_mmus array behind mmu_lock, ensuring that vcpu init and MMU notifiers are mutually exclusive - Correctly handle FEAT_XNX at stage-2
2 participants
The three commits implement rotation. I'd appreciate feedback on these:
39ca70a: implements software based rotation for the DRM driver. I think this is clean and likely suitable for inclusion.
65e11b8: I wanted to get hardware-based rotation, and at some point it became obvious that I could just as easily get away with hardware-based rendering entirely. This works, but I used an internal API to talk to the PxP. There's precedent of this design in the kernel, but I'm not sure that's enough to consider this good, and I'm not sure if there are devices with an mxc-epdc but without an imx-pxp. If there's another "correct" way to do this, I'd be happy to try.
975639c: I still haven't tested this one fully, but it tweaks the FB->DRM delegation to also delegate rotation. Otherwise, when a client rotates via the FB API, this rotation is swallowed and the image remains in its original position. I think this one is too much of a hack. I'm not sure how to do it cleanly or if the idea itself is acceptable for upstream.
This PR is opened as a request for feedback. Feel free to pick any code that seems okay, but it's not open with any expectation of it being ready to merge.