V4L2 padding removal, and support for H264_I_PERIOD #598
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
added 5 commits
May 19, 2014 13:03
Adds support for the parameter V4L2_CID_MPEG_VIDEO_H264_I_PERIOD to set the frequency with which I frames are produced. Signed-off-by: Dave Stevenson <[email protected]>
GPU can now support arbitrary strides, although may require additional processing to achieve it. Enable this feature so that the images delivered are the size requested. Signed-off-by: Dave Stevenson <[email protected]>
Signed-off-by: Dave Stevenson <[email protected]>
Removes the amiguity from the conversion routines and stops them dropping back to the SD vs HD choice of coeffs. Signed-off-by: Dave Stevenson <[email protected]>
Move the define for at what resolution the driver switches from a video mode capture to a stills mode capture to module parameters. Signed-off-by: Dave Stevenson <[email protected]>
popcornmix
added a commit
that referenced
this pull request
May 21, 2014
V4L2 padding removal, and support for H264_I_PERIOD
popcornmix
pushed a commit
to raspberrypi/firmware
that referenced
this pull request
May 23, 2014
kernel: V4L2 padding removal, and support for H264_I_PERIOD See: raspberrypi/linux#598 firmware: dispmanx: Limit LBM usage on any channel See: #277 firmware: MMAL: vc_image: Fix some of the combinations for vc_image_pack firmware: MMAL: Don't ask for YUVUV when tearing down an opaque tunnel See: http://www.raspberrypi.org/forums/viewtopic.php?f=43&t=62364&start=300#p552913 firmware: gencmd: Add display_power command for controlling power to hdmi phy firmware: config: Add hdmi_force_mode option to force only one mode See: http://openelec.tv/forum/124-raspberry-pi/71222-display-issues#108236 firmware: hdmi: Make configured mode have high score, so it is respected after power on preferred firmware: hdmi: Call the callback with current hdmi mode, not preferred See: http://forum.stmlabs.com/showthread.php?tid=11003&pid=102973#pid102973 firmware: dispmanx: Move the offline/rotated buffer allocation into attach function. See: raspberrypi/linux#463
popcornmix
pushed a commit
to Hexxeh/rpi-firmware
that referenced
this pull request
May 23, 2014
kernel: V4L2 padding removal, and support for H264_I_PERIOD See: raspberrypi/linux#598 firmware: dispmanx: Limit LBM usage on any channel See: raspberrypi/firmware#277 firmware: MMAL: vc_image: Fix some of the combinations for vc_image_pack firmware: MMAL: Don't ask for YUVUV when tearing down an opaque tunnel See: http://www.raspberrypi.org/forums/viewtopic.php?f=43&t=62364&start=300#p552913 firmware: gencmd: Add display_power command for controlling power to hdmi phy firmware: config: Add hdmi_force_mode option to force only one mode See: http://openelec.tv/forum/124-raspberry-pi/71222-display-issues#108236 firmware: hdmi: Make configured mode have high score, so it is respected after power on preferred firmware: hdmi: Call the callback with current hdmi mode, not preferred See: http://forum.stmlabs.com/showthread.php?tid=11003&pid=102973#pid102973 firmware: dispmanx: Move the offline/rotated buffer allocation into attach function. See: raspberrypi/linux#463
neuschaefer
pushed a commit
to neuschaefer/raspi-binary-firmware
that referenced
this pull request
Feb 27, 2017
kernel: V4L2 padding removal, and support for H264_I_PERIOD See: raspberrypi/linux#598 firmware: dispmanx: Limit LBM usage on any channel See: raspberrypi#277 firmware: MMAL: vc_image: Fix some of the combinations for vc_image_pack firmware: MMAL: Don't ask for YUVUV when tearing down an opaque tunnel See: http://www.raspberrypi.org/forums/viewtopic.php?f=43&t=62364&start=300#p552913 firmware: gencmd: Add display_power command for controlling power to hdmi phy firmware: config: Add hdmi_force_mode option to force only one mode See: http://openelec.tv/forum/124-raspberry-pi/71222-display-issues#108236 firmware: hdmi: Make configured mode have high score, so it is respected after power on preferred firmware: hdmi: Call the callback with current hdmi mode, not preferred See: http://forum.stmlabs.com/showthread.php?tid=11003&pid=102973#pid102973 firmware: dispmanx: Move the offline/rotated buffer allocation into attach function. See: raspberrypi/linux#463
popcornmix
pushed a commit
that referenced
this pull request
Jun 28, 2024
[ Upstream commit af0cb3f ] Xiumei and Christoph reported the following lockdep splat, complaining of the qdisc root lock being taken twice: ============================================ WARNING: possible recursive locking detected 6.7.0-rc3+ #598 Not tainted -------------------------------------------- swapper/2/0 is trying to acquire lock: ffff888177190110 (&sch->q.lock){+.-.}-{2:2}, at: __dev_queue_xmit+0x1560/0x2e70 but task is already holding lock: ffff88811995a110 (&sch->q.lock){+.-.}-{2:2}, at: __dev_queue_xmit+0x1560/0x2e70 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&sch->q.lock); lock(&sch->q.lock); *** DEADLOCK *** May be due to missing lock nesting notation 5 locks held by swapper/2/0: #0: ffff888135a09d98 ((&in_dev->mr_ifc_timer)){+.-.}-{0:0}, at: call_timer_fn+0x11a/0x510 #1: ffffffffaaee5260 (rcu_read_lock){....}-{1:2}, at: ip_finish_output2+0x2c0/0x1ed0 #2: ffffffffaaee5200 (rcu_read_lock_bh){....}-{1:2}, at: __dev_queue_xmit+0x209/0x2e70 #3: ffff88811995a110 (&sch->q.lock){+.-.}-{2:2}, at: __dev_queue_xmit+0x1560/0x2e70 #4: ffffffffaaee5200 (rcu_read_lock_bh){....}-{1:2}, at: __dev_queue_xmit+0x209/0x2e70 stack backtrace: CPU: 2 PID: 0 Comm: swapper/2 Not tainted 6.7.0-rc3+ #598 Hardware name: Red Hat KVM, BIOS 1.13.0-2.module+el8.3.0+7353+9de0a3cc 04/01/2014 Call Trace: <IRQ> dump_stack_lvl+0x4a/0x80 __lock_acquire+0xfdd/0x3150 lock_acquire+0x1ca/0x540 _raw_spin_lock+0x34/0x80 __dev_queue_xmit+0x1560/0x2e70 tcf_mirred_act+0x82e/0x1260 [act_mirred] tcf_action_exec+0x161/0x480 tcf_classify+0x689/0x1170 prio_enqueue+0x316/0x660 [sch_prio] dev_qdisc_enqueue+0x46/0x220 __dev_queue_xmit+0x1615/0x2e70 ip_finish_output2+0x1218/0x1ed0 __ip_finish_output+0x8b3/0x1350 ip_output+0x163/0x4e0 igmp_ifc_timer_expire+0x44b/0x930 call_timer_fn+0x1a2/0x510 run_timer_softirq+0x54d/0x11a0 __do_softirq+0x1b3/0x88f irq_exit_rcu+0x18f/0x1e0 sysvec_apic_timer_interrupt+0x6f/0x90 </IRQ> This happens when TC does a mirred egress redirect from the root qdisc of device A to the root qdisc of device B. As long as these two locks aren't protecting the same qdisc, they can be acquired in chain: add a per-qdisc lockdep key to silence false warnings. This dynamic key should safely replace the static key we have in sch_htb: it was added to allow enqueueing to the device "direct qdisc" while still holding the qdisc root lock. v2: don't use static keys anymore in HTB direct qdiscs (thanks Eric Dumazet) CC: Maxim Mikityanskiy <[email protected]> CC: Xiumei Mu <[email protected]> Reported-by: Christoph Paasch <[email protected]> Closes: multipath-tcp/mptcp_net-next#451 Signed-off-by: Davide Caratti <[email protected]> Link: https://lore.kernel.org/r/7dc06d6158f72053cf877a82e2a7a5bd23692faa.1713448007.git.dcaratti@redhat.com Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
popcornmix
pushed a commit
that referenced
this pull request
Jul 1, 2024
[ Upstream commit af0cb3f ] Xiumei and Christoph reported the following lockdep splat, complaining of the qdisc root lock being taken twice: ============================================ WARNING: possible recursive locking detected 6.7.0-rc3+ #598 Not tainted -------------------------------------------- swapper/2/0 is trying to acquire lock: ffff888177190110 (&sch->q.lock){+.-.}-{2:2}, at: __dev_queue_xmit+0x1560/0x2e70 but task is already holding lock: ffff88811995a110 (&sch->q.lock){+.-.}-{2:2}, at: __dev_queue_xmit+0x1560/0x2e70 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&sch->q.lock); lock(&sch->q.lock); *** DEADLOCK *** May be due to missing lock nesting notation 5 locks held by swapper/2/0: #0: ffff888135a09d98 ((&in_dev->mr_ifc_timer)){+.-.}-{0:0}, at: call_timer_fn+0x11a/0x510 #1: ffffffffaaee5260 (rcu_read_lock){....}-{1:2}, at: ip_finish_output2+0x2c0/0x1ed0 #2: ffffffffaaee5200 (rcu_read_lock_bh){....}-{1:2}, at: __dev_queue_xmit+0x209/0x2e70 #3: ffff88811995a110 (&sch->q.lock){+.-.}-{2:2}, at: __dev_queue_xmit+0x1560/0x2e70 #4: ffffffffaaee5200 (rcu_read_lock_bh){....}-{1:2}, at: __dev_queue_xmit+0x209/0x2e70 stack backtrace: CPU: 2 PID: 0 Comm: swapper/2 Not tainted 6.7.0-rc3+ #598 Hardware name: Red Hat KVM, BIOS 1.13.0-2.module+el8.3.0+7353+9de0a3cc 04/01/2014 Call Trace: <IRQ> dump_stack_lvl+0x4a/0x80 __lock_acquire+0xfdd/0x3150 lock_acquire+0x1ca/0x540 _raw_spin_lock+0x34/0x80 __dev_queue_xmit+0x1560/0x2e70 tcf_mirred_act+0x82e/0x1260 [act_mirred] tcf_action_exec+0x161/0x480 tcf_classify+0x689/0x1170 prio_enqueue+0x316/0x660 [sch_prio] dev_qdisc_enqueue+0x46/0x220 __dev_queue_xmit+0x1615/0x2e70 ip_finish_output2+0x1218/0x1ed0 __ip_finish_output+0x8b3/0x1350 ip_output+0x163/0x4e0 igmp_ifc_timer_expire+0x44b/0x930 call_timer_fn+0x1a2/0x510 run_timer_softirq+0x54d/0x11a0 __do_softirq+0x1b3/0x88f irq_exit_rcu+0x18f/0x1e0 sysvec_apic_timer_interrupt+0x6f/0x90 </IRQ> This happens when TC does a mirred egress redirect from the root qdisc of device A to the root qdisc of device B. As long as these two locks aren't protecting the same qdisc, they can be acquired in chain: add a per-qdisc lockdep key to silence false warnings. This dynamic key should safely replace the static key we have in sch_htb: it was added to allow enqueueing to the device "direct qdisc" while still holding the qdisc root lock. v2: don't use static keys anymore in HTB direct qdiscs (thanks Eric Dumazet) CC: Maxim Mikityanskiy <[email protected]> CC: Xiumei Mu <[email protected]> Reported-by: Christoph Paasch <[email protected]> Closes: multipath-tcp/mptcp_net-next#451 Signed-off-by: Davide Caratti <[email protected]> Link: https://lore.kernel.org/r/7dc06d6158f72053cf877a82e2a7a5bd23692faa.1713448007.git.dcaratti@redhat.com Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Needs my firmware changes to be picked up too (C/Ls 451759, 451760, and 451774) to provide full functionality, otherwise some image formats with width/height not a multiple of 32/16 will fail in colourful ways.
First change is to address #593