Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

arm64: dts: rockchip: rock 5b: use more common pd definations #30

Merged
merged 1 commit into from
Oct 18, 2022
Merged

arm64: dts: rockchip: rock 5b: use more common pd definations #30

merged 1 commit into from
Oct 18, 2022

Conversation

amazingfate
Copy link

Instead of using PDO_FIXED which only define one PD defination, PDO_VAR defines all the PD definations bewteen the min volt and max volt.
In this commit I defined all the PD definations with volt from min 5V to max 20V and current up to 5A.
power-role of fusb302 is sink now so source-pdos is useless, I just delete it.

@RadxaYuntian RadxaYuntian self-requested a review October 10, 2022 11:40
RadxaYuntian
RadxaYuntian approved these changes Oct 10, 2022
View reviewed changes
Copy link
Member

@RadxaYuntian RadxaYuntian left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Also double checked with schematic to make sure we can take 20V input. Although I'm very curious what will happen if we run 5A@20V.

@amazingfate
Copy link
Author

LGTM. Also double checked with schematic to make sure we can take 20V input. Although I'm very curious what will happen if we run 5A@20V.

I don't have a 100W pd charger, but this defination can negotiate up to 20V 3.25V with my lenovo thinkplus pd charger.

@RadxaYuntian
Copy link
Member

I'm concerned that the PCB traces may not be able to carry 100W of power. I'll ask hardware engineers.

@RadxaYuntian
Copy link
Member

Sam said it is fine so @RadxaStephen please take a look at this.

@RadxaStephen RadxaStephen merged commit 7afb456 into radxa:stable-5.10-rock5 Oct 18, 2022
RadxaStephen pushed a commit that referenced this pull request Oct 28, 2022
@amazingfate @RadxaStephen
arm64: dts: rockchip: rock 5b: use more common pd definations (#30)
29aae02
stvhay pushed a commit to stvhay/kernel that referenced this pull request Feb 1, 2023
@amazingfate @stvhay
arm64: dts: rockchip: rock 5b: use more common pd definations (radxa#30)
812642a
stvhay pushed a commit to stvhay/kernel that referenced this pull request Feb 12, 2023
@amazingfate @stvhay
arm64: dts: rockchip: rock 5b: use more common pd definations (radxa#30)
2d1af3e
stvhay pushed a commit to stvhay/kernel that referenced this pull request Feb 26, 2023
@amazingfate @stvhay
arm64: dts: rockchip: rock 5b: use more common pd definations (radxa#30)
7ea229d
RadxaStephen pushed a commit to RadxaStephen/kernel that referenced this pull request Mar 3, 2023
@amazingfate @RadxaStephen
arm64: dts: rockchip: rock 5b: use more common pd definations (radxa#30)
432bb0d
RadxaStephen pushed a commit that referenced this pull request Jul 3, 2023
@amazingfate @RadxaStephen
arm64: dts: rockchip: rock 5b: use more common pd definations (#30)
091b5e8
ruiqurm pushed a commit to BUPT-OS/radxa-kernel that referenced this pull request Jan 7, 2025
@pgerum @ruiqurm
evl/net: ipv4: use atomic allocation when learning routes
eec2795 
evl_net_learn_ipv4_route() may be called from a softirq context. Make
sure we don't enter fs reclaim, use atomic allocation instead.

Fixes this lockdep splat:

[  393.641581] ================================
[  393.641584] WARNING: inconsistent lock state
[  393.641588] 6.1.111-00840-g87ef751da8a7-dirty radxa#30 Not tainted
[  393.641594] --------------------------------
[  393.641597] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
[  393.641601] swapper/0/0 [HC0[0]:SC1[3]:HE1:SE0] takes:
[  393.641611] c190530c (fs_reclaim){+.?.}-{0:0}, at: __kmem_cache_alloc_node+0x2c/0x204
[  393.641647] {SOFTIRQ-ON-W} state was registered at:
[  393.641651]   fs_reclaim_acquire+0x70/0xa8
[  393.641664]   __kmem_cache_alloc_node+0x2c/0x204
[  393.641673]   kmalloc_node_trace+0x24/0x4c
[  393.641682]   init_rescuer+0x3c/0xe8
[  393.641696]   workqueue_init+0xa0/0x1e4
[  393.641716]   kernel_init_freeable+0x88/0x240
[  393.641733]   kernel_init+0x14/0x140
[  393.641751]   ret_from_fork+0x14/0x1c
[  393.641760] irq event stamp: 280800
[  393.641764] hardirqs last  enabled at (280800): [<c012ff8c>] handle_softirqs+0xa0/0x480
[  393.641784] hardirqs last disabled at (280798): [<c01ab6f4>] sync_current_irq_stage+0x214/0x268
[  393.641799] softirqs last  enabled at (280780): [<c01301c0>] handle_softirqs+0x2d4/0x480
[  393.641813] softirqs last disabled at (280799): [<c013050c>] __irq_exit_rcu+0x144/0x188
[  393.641827]
[  393.641827] other info that might help us debug this:
[  393.641831]  Possible unsafe locking scenario:
[  393.641831]
[  393.641833]        CPU0
[  393.641835]        ----
[  393.641837]   lock(fs_reclaim);
[  393.641843]   <Interrupt>
[  393.641845]     lock(fs_reclaim);
[  393.641852]
[  393.641852]  *** DEADLOCK ***
[  393.641852]
[  393.641853] 2 locks held by swapper/0/0:
[  393.641859]  #0: c18e21c0 (rcu_read_lock){....}-{1:2}, at: netif_receive_skb_list_internal+0xc8/0x3d4
[  393.641891]  radxa#1: c18e21c0 (rcu_read_lock){....}-{1:2}, at: ip_local_deliver_finish+0x64/0x1c8
[  393.641920]
[  393.641920] stack backtrace:
[  393.641924] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.1.111-00840-g87ef751da8a7-dirty radxa#30
[  393.641933] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[  393.641937] IRQ stage: Linux
[  393.641944]  unwind_backtrace from show_stack+0x10/0x14
[  393.641967]  show_stack from dump_stack_lvl+0x94/0xcc
[  393.641986]  dump_stack_lvl from mark_lock.part.0+0x730/0x940
[  393.642004]  mark_lock.part.0 from __lock_acquire+0x978/0x2924
[  393.642016]  __lock_acquire from lock_acquire+0xf8/0x368
[  393.642029]  lock_acquire from fs_reclaim_acquire+0x70/0xa8
[  393.642042]  fs_reclaim_acquire from __kmem_cache_alloc_node+0x2c/0x204
[  393.642058]  __kmem_cache_alloc_node from kmalloc_trace+0x28/0x58
[  393.642072]  kmalloc_trace from evl_net_learn_ipv4_route+0x6c/0x12c
[  393.642095]  evl_net_learn_ipv4_route from ip_route_output_flow+0x5c/0x64
[  393.642113]  ip_route_output_flow from ip_send_unicast_reply+0x144/0x50c
[  393.642132]  ip_send_unicast_reply from tcp_v4_send_reset+0x25c/0x514
[  393.642151]  tcp_v4_send_reset from tcp_v4_rcv+0x98c/0xcdc
[  393.642164]  tcp_v4_rcv from ip_protocol_deliver_rcu+0x3c/0x248
[  393.642178]  ip_protocol_deliver_rcu from ip_local_deliver_finish+0xd0/0x1c8
[  393.642194]  ip_local_deliver_finish from ip_sublist_rcv_finish+0x38/0xa0
[  393.642210]  ip_sublist_rcv_finish from ip_sublist_rcv+0x1e8/0x340
[  393.642225]  ip_sublist_rcv from ip_list_rcv+0xe4/0x2f8
[  393.642240]  ip_list_rcv from __netif_receive_skb_list_core+0x18c/0x1fc
[  393.642258]  __netif_receive_skb_list_core from netif_receive_skb_list_internal+0x1f8/0x3d4
[  393.642275]  netif_receive_skb_list_internal from net_rx_action+0xe0/0x3cc
[  393.642291]  net_rx_action from handle_softirqs+0xdc/0x480
[  393.642312]  handle_softirqs from __irq_exit_rcu+0x144/0x188
[  393.642332]  __irq_exit_rcu from irq_exit+0x8/0x28
[  393.642352]  irq_exit from arch_do_IRQ_pipelined+0x30/0x64
[  393.642372]  arch_do_IRQ_pipelined from sync_current_irq_stage+0x160/0x268
[  393.642386]  sync_current_irq_stage from __inband_irq_enable+0x48/0x54
[  393.642400]  __inband_irq_enable from cpuidle_enter_state+0x198/0x3e8
[  393.642421]  cpuidle_enter_state from cpuidle_enter+0x30/0x40
[  393.642436]  cpuidle_enter from do_idle+0x1e0/0x2ac
[  393.642460]  do_idle from cpu_startup_entry+0x28/0x2c
[  393.642481]  cpu_startup_entry from rest_init+0xd4/0x188
[  393.642504]  rest_init from arch_post_acpi_subsys_init+0x0/0x8

Signed-off-by: Philippe Gerum <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@RadxaYuntian RadxaYuntian RadxaYuntian approved these changes

Assignees

@RadxaStephen RadxaStephen

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@amazingfate @RadxaYuntian @RadxaStephen