rockchip isp1 driver #33
Comments
|
What is the configuration file for the kernel? |
|
thank you |
|
Hi: I have a question about the return value of the function rkisp1_irq_handler() in the file drivers/media/platform/rockchip-isp1/dev.c. I think it should return IRQ_HANDLED other than IRQ_NONE, that is:
} When the function returns IRQ_NONE, the kernel will output these logs: |
|
Thanks. |
|
What changes should I make in DTS for rk3399 ? For rk3299 mipi_phy_rx0 is defined within 'cif_isp0: cif_isp@ff910000' node in rk3288.dtsi (https://github.com/rockchip-linux/kernel/blob/isp-early-access/arch/arm/boot/dts/rk3288.dtsi#L1126), but 'cif_isp0: cif_isp@ff910000' node in rk3399-linux.dtsi does not contains 'mipi_phy_rx0' (https://github.com/rockchip-linux/kernel/blob/isp-early-access/arch/arm64/boot/dts/rockchip/rk3399-linux.dtsi#L60). Should I modify 'cif_isp0: cif_isp@ff910000' node in rk3399-linux.dtsi like in rk3288.dtsi ? |
|
https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/527854/149 |
|
Thank you very much. |
yes, it should work. |
|
@axendev , thanks for your recommend and guide, do you mean that I should modify the rockchip-isp1 soures to connect ov cameras? And I should also add the the ov camera's i2c code in the i2c node dir? If you have the worked code, can you provide your sources? Thanks very much! (my email: [email protected] / [email protected]) |
|
I use a single ov5647 sensor on rk3288. I managed to setup the kernel and the dts to the point I'm able to probe the sensor correctly: However, when I try to capture frames the sensor seems to lose power and i2c r/w returns -6: |
|
v4l2-ctl can't be used now since this driver use media controller api. |
|
No luck with dts: https://gist.github.com/teseo-sw/ff8641adf0733078b8053448b9303ccb |
|
check |
|
I add a new wiki page for rockchip-isp1. |
|
Will we be able to use IMX219 on TinkerBoard with all features including 3A by 2018.04? |
|
No promise. Business should go business way. Here is community |
|
The driver is merged to 3A support on Linux is still in develop.I have add a experimental version to rkcamsrc plugin, but it don't work very well. |
do_task_stat() calls get_wchan(), which further does unwind_frame(). unwind_frame() restores frame->pc to original value in case function graph tracer has modified a return address (LR) in a stack frame to hook a function return. However, if function graph tracer has hit a filtered function, then we can't unwind it as ftrace_push_return_trace() has biased the index(frame->graph) with a 'huge negative' offset(-FTRACE_NOTRACE_DEPTH). Moreover, arm64 stack walker defines index(frame->graph) as unsigned int, which can not compare a -ve number. Similar problem we can have with calling of walk_stackframe() from save_stack_trace_tsk() or dump_backtrace(). This patch fixes unwind_frame() to test the index for -ve value and restore index accordingly before we can restore frame->pc. Reproducer: cd /sys/kernel/debug/tracing/ echo schedule > set_graph_notrace echo 1 > options/display-graph echo wakeup > current_tracer ps -ef | grep -i agent Above commands result in: Unable to handle kernel paging request at virtual address ffff801bd3d1e000 pgd = ffff8003cbe97c00 [ffff801bd3d1e000] *pgd=0000000000000000, *pud=0000000000000000 Internal error: Oops: 96000006 [#1] SMP [...] CPU: 5 PID: 11696 Comm: ps Not tainted 4.11.0+ #33 [...] task: ffff8003c21ba000 task.stack: ffff8003cc6c0000 PC is at unwind_frame+0x12c/0x180 LR is at get_wchan+0xd4/0x134 pc : [<ffff00000808892c>] lr : [<ffff0000080860b8>] pstate: 60000145 sp : ffff8003cc6c3ab0 x29: ffff8003cc6c3ab0 x28: 0000000000000001 x27: 0000000000000026 x26: 0000000000000026 x25: 00000000000012d8 x24: 0000000000000000 x23: ffff8003c1c04000 x22: ffff000008c83000 x21: ffff8003c1c00000 x20: 000000000000000f x19: ffff8003c1bc0000 x18: 0000fffffc593690 x17: 0000000000000000 x16: 0000000000000001 x15: 0000b855670e2b60 x14: 0003e97f22cf1d0f x13: 0000000000000001 x12: 0000000000000000 x11: 00000000e8f4883e x10: 0000000154f47ec8 x9 : 0000000070f367c0 x8 : 0000000000000000 x7 : 00008003f7290000 x6 : 0000000000000018 x5 : 0000000000000000 x4 : ffff8003c1c03cb0 x3 : ffff8003c1c03ca0 x2 : 00000017ffe80000 x1 : ffff8003cc6c3af8 x0 : ffff8003d3e9e000 Process ps (pid: 11696, stack limit = 0xffff8003cc6c0000) Stack: (0xffff8003cc6c3ab0 to 0xffff8003cc6c4000) [...] [<ffff00000808892c>] unwind_frame+0x12c/0x180 [<ffff000008305008>] do_task_stat+0x864/0x870 [<ffff000008305c44>] proc_tgid_stat+0x3c/0x48 [<ffff0000082fde0c>] proc_single_show+0x5c/0xb8 [<ffff0000082b27e0>] seq_read+0x160/0x414 [<ffff000008289e6c>] __vfs_read+0x58/0x164 [<ffff00000828b164>] vfs_read+0x88/0x144 [<ffff00000828c2e8>] SyS_read+0x60/0xc0 [<ffff0000080834a0>] __sys_trace_return+0x0/0x4 Fixes: 20380bb (arm64: ftrace: fix a stack tracer's output under function graph tracer) Signed-off-by: Pratyush Anand <[email protected]> Signed-off-by: Jerome Marchand <[email protected]> [[email protected]: replace WARN_ON with WARN_ON_ONCE] Signed-off-by: Catalin Marinas <[email protected]>
[ Upstream commit a314777 ] BUG: unable to handle kernel paging request at ffffffffa016a270 PGD 3270067 P4D 3270067 PUD 3271063 PMD 230bbd067 PTE 0 Oops: 0000 [#1 CPU: 0 PID: 6134 Comm: modprobe Not tainted 5.1.0+ #33 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014 RIP: 0010:atomic_notifier_chain_register+0x24/0x60 Code: 1f 80 00 00 00 00 55 48 89 e5 41 54 49 89 f4 53 48 89 fb e8 ae b4 38 01 48 8b 53 38 48 8d 4b 38 48 85 d2 74 20 45 8b 44 24 10 <44> 3b 42 10 7e 08 eb 13 44 39 42 10 7c 0d 48 8d 4a 08 48 8b 52 08 RSP: 0018:ffffc90000e2bc60 EFLAGS: 00010086 RAX: 0000000000000292 RBX: ffffffff83467240 RCX: ffffffff83467278 RDX: ffffffffa016a260 RSI: ffffffff83752140 RDI: ffffffff83467240 RBP: ffffc90000e2bc70 R08: 0000000000000000 R09: 0000000000000001 R10: 0000000000000000 R11: 00000000014fa61f R12: ffffffffa01c8260 R13: ffff888231091e00 R14: 0000000000000000 R15: ffffc90000e2be78 FS: 00007fbd8d7cd540(0000) GS:ffff888237a00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffa016a270 CR3: 000000022c7e3000 CR4: 00000000000006f0 Call Trace: register_inet6addr_notifier+0x13/0x20 cxgb4_init_module+0x6c/0x1000 [cxgb4 ? 0xffffffffa01d7000 do_one_initcall+0x6c/0x3cc ? do_init_module+0x22/0x1f1 ? rcu_read_lock_sched_held+0x97/0xb0 ? kmem_cache_alloc_trace+0x325/0x3b0 do_init_module+0x5b/0x1f1 load_module+0x1db1/0x2690 ? m_show+0x1d0/0x1d0 __do_sys_finit_module+0xc5/0xd0 __x64_sys_finit_module+0x15/0x20 do_syscall_64+0x6b/0x1d0 entry_SYSCALL_64_after_hwframe+0x49/0xbe If pci_register_driver fails, register inet6addr_notifier is pointless. This patch fix the error path in cxgb4_init_module. Fixes: b5a02f5 ("cxgb4 : Update ipv6 address handling api") Signed-off-by: YueHaibing <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
The commit 304419d ("mmc: core: Allocate per-request data using the block layer core") refactored mechanism of queue handling caused mmc_init_request() can be called just after mmc_cleanup_queue() caused null pointer dereference. Another commit bbdc74d ("mmc: block: Prevent new req entering queue after its cleanup") tried to fix the problem. However it actually miss one corner case. We could still reproduce the issue mentioned with these steps: (1) insert a SD card and mount it (2) hotplug it, so it will leave md->usage still be counted (3) reboot the system which will sync data and umount the card [Unable to handle kernel NULL pointer dereference at virtual address 00000000 [user pgtable: 4k pages, 48-bit VAs, pgd = ffff80007bab3000 [[0000000000000000] *pgd=000000007a828003, *pud=0000000078dce003, *pmd=000000007aab6003, *pte=0000000000000000 [Internal error: Oops: 96000007 [FireflyTeam#1] PREEMPT SMP [Modules linked in: [CPU: 3 PID: 3507 Comm: umount Tainted: G W 4.13.0-rc1-next-20170720-00012-g9d9bf45 rockchip-linux#33 [Hardware name: Firefly-RK3399 Board (DT) [task: ffff80007a1de200 task.stack: ffff80007a01c000 [PC is at mmc_init_request+0x14/0xc4 [LR is at alloc_request_size+0x4c/0x74 [pc : [<ffff0000087d7150>] lr : [<ffff000008378fe0>] pstate: 600001c5 [sp : ffff80007a01f8f0 .... [[<ffff0000087d7150>] mmc_init_request+0x14/0xc4 [[<ffff000008378fe0>] alloc_request_size+0x4c/0x74 [[<ffff00000817ac28>] mempool_create_node+0xb8/0x17c [[<ffff00000837aadc>] blk_init_rl+0x9c/0x120 [[<ffff000008396580>] blkg_alloc+0x110/0x234 [[<ffff000008396ac8>] blkg_create+0x424/0x468 [[<ffff00000839877c>] blkg_lookup_create+0xd8/0x14c [[<ffff0000083796bc>] generic_make_request_checks+0x368/0x3b0 [[<ffff00000837b050>] generic_make_request+0x1c/0x240 So mmc_blk_put wouldn't calling blk_cleanup_queue which actually the QUEUE_FLAG_DYING and QUEUE_FLAG_BYPASS should stay. Block core expect blk_queue_bypass_{start, end} internally to bypass/drain the queue before actually dying the queue, so it didn't expose API to set the queue bypass. I think we should set QUEUE_FLAG_BYPASS whenever queue is removed, although the md->usage is still counted, as no dispatch queue could be found then. Fixes: 304419d ("mmc: core: Allocate per-request data using the block layer core") Signed-off-by: Shawn Lin <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Signed-off-by: Ulf Hansson <[email protected]>
In the (unlikely) event fixup_permanent_addr() returns a failure, addrconf_permanent_addr() calls ipv6_del_addr() without the mandatory call to in6_ifa_hold(), leading to a refcount error, spotted by syzkaller : WARNING: CPU: 1 PID: 3142 at lib/refcount.c:227 refcount_dec+0x4c/0x50 lib/refcount.c:227 Kernel panic - not syncing: panic_on_warn set ... CPU: 1 PID: 3142 Comm: ip Not tainted 4.14.0-rc4-next-20171009+ rockchip-linux#33 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:16 [inline] dump_stack+0x194/0x257 lib/dump_stack.c:52 panic+0x1e4/0x41c kernel/panic.c:181 __warn+0x1c4/0x1e0 kernel/panic.c:544 report_bug+0x211/0x2d0 lib/bug.c:183 fixup_bug+0x40/0x90 arch/x86/kernel/traps.c:178 do_trap_no_signal arch/x86/kernel/traps.c:212 [inline] do_trap+0x260/0x390 arch/x86/kernel/traps.c:261 do_error_trap+0x120/0x390 arch/x86/kernel/traps.c:298 do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:311 invalid_op+0x18/0x20 arch/x86/entry/entry_64.S:905 RIP: 0010:refcount_dec+0x4c/0x50 lib/refcount.c:227 RSP: 0018:ffff8801ca49e680 EFLAGS: 00010286 RAX: 000000000000002c RBX: ffff8801d07cfcdc RCX: 0000000000000000 RDX: 000000000000002c RSI: 1ffff10039493c90 RDI: ffffed0039493cc4 RBP: ffff8801ca49e688 R08: ffff8801ca49dd70 R09: 0000000000000000 R10: ffff8801ca49df58 R11: 0000000000000000 R12: 1ffff10039493cd9 R13: ffff8801ca49e6e8 R14: ffff8801ca49e7e8 R15: ffff8801d07cfcdc __in6_ifa_put include/net/addrconf.h:369 [inline] ipv6_del_addr+0x42b/0xb60 net/ipv6/addrconf.c:1208 addrconf_permanent_addr net/ipv6/addrconf.c:3327 [inline] addrconf_notify+0x1c66/0x2190 net/ipv6/addrconf.c:3393 notifier_call_chain+0x136/0x2c0 kernel/notifier.c:93 __raw_notifier_call_chain kernel/notifier.c:394 [inline] raw_notifier_call_chain+0x2d/0x40 kernel/notifier.c:401 call_netdevice_notifiers_info+0x32/0x60 net/core/dev.c:1697 call_netdevice_notifiers net/core/dev.c:1715 [inline] __dev_notify_flags+0x15d/0x430 net/core/dev.c:6843 dev_change_flags+0xf5/0x140 net/core/dev.c:6879 do_setlink+0xa1b/0x38e0 net/core/rtnetlink.c:2113 rtnl_newlink+0xf0d/0x1a40 net/core/rtnetlink.c:2661 rtnetlink_rcv_msg+0x733/0x1090 net/core/rtnetlink.c:4301 netlink_rcv_skb+0x216/0x440 net/netlink/af_netlink.c:2408 rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:4313 netlink_unicast_kernel net/netlink/af_netlink.c:1273 [inline] netlink_unicast+0x4e8/0x6f0 net/netlink/af_netlink.c:1299 netlink_sendmsg+0xa4a/0xe70 net/netlink/af_netlink.c:1862 sock_sendmsg_nosec net/socket.c:633 [inline] sock_sendmsg+0xca/0x110 net/socket.c:643 ___sys_sendmsg+0x75b/0x8a0 net/socket.c:2049 __sys_sendmsg+0xe5/0x210 net/socket.c:2083 SYSC_sendmsg net/socket.c:2094 [inline] SyS_sendmsg+0x2d/0x50 net/socket.c:2090 entry_SYSCALL_64_fastpath+0x1f/0xbe RIP: 0033:0x7fa9174d3320 RSP: 002b:00007ffe302ae9e8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007ffe302b2ae0 RCX: 00007fa9174d3320 RDX: 0000000000000000 RSI: 00007ffe302aea20 RDI: 0000000000000016 RBP: 0000000000000082 R08: 0000000000000000 R09: 000000000000000f R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffe302b32a0 R13: 0000000000000000 R14: 00007ffe302b2ab8 R15: 00007ffe302b32b8 Fixes: f1705ec ("net: ipv6: Make address flushing on ifdown optional") Signed-off-by: Eric Dumazet <[email protected]> Cc: David Ahern <[email protected]> Acked-by: David Ahern <[email protected]> Signed-off-by: David S. Miller <[email protected]>
[ Upstream commit a314777 ] BUG: unable to handle kernel paging request at ffffffffa016a270 PGD 3270067 P4D 3270067 PUD 3271063 PMD 230bbd067 PTE 0 Oops: 0000 [FireflyTeam#1 CPU: 0 PID: 6134 Comm: modprobe Not tainted 5.1.0+ rockchip-linux#33 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014 RIP: 0010:atomic_notifier_chain_register+0x24/0x60 Code: 1f 80 00 00 00 00 55 48 89 e5 41 54 49 89 f4 53 48 89 fb e8 ae b4 38 01 48 8b 53 38 48 8d 4b 38 48 85 d2 74 20 45 8b 44 24 10 <44> 3b 42 10 7e 08 eb 13 44 39 42 10 7c 0d 48 8d 4a 08 48 8b 52 08 RSP: 0018:ffffc90000e2bc60 EFLAGS: 00010086 RAX: 0000000000000292 RBX: ffffffff83467240 RCX: ffffffff83467278 RDX: ffffffffa016a260 RSI: ffffffff83752140 RDI: ffffffff83467240 RBP: ffffc90000e2bc70 R08: 0000000000000000 R09: 0000000000000001 R10: 0000000000000000 R11: 00000000014fa61f R12: ffffffffa01c8260 R13: ffff888231091e00 R14: 0000000000000000 R15: ffffc90000e2be78 FS: 00007fbd8d7cd540(0000) GS:ffff888237a00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffa016a270 CR3: 000000022c7e3000 CR4: 00000000000006f0 Call Trace: register_inet6addr_notifier+0x13/0x20 cxgb4_init_module+0x6c/0x1000 [cxgb4 ? 0xffffffffa01d7000 do_one_initcall+0x6c/0x3cc ? do_init_module+0x22/0x1f1 ? rcu_read_lock_sched_held+0x97/0xb0 ? kmem_cache_alloc_trace+0x325/0x3b0 do_init_module+0x5b/0x1f1 load_module+0x1db1/0x2690 ? m_show+0x1d0/0x1d0 __do_sys_finit_module+0xc5/0xd0 __x64_sys_finit_module+0x15/0x20 do_syscall_64+0x6b/0x1d0 entry_SYSCALL_64_after_hwframe+0x49/0xbe If pci_register_driver fails, register inet6addr_notifier is pointless. This patch fix the error path in cxgb4_init_module. Fixes: b5a02f5 ("cxgb4 : Update ipv6 address handling api") Signed-off-by: YueHaibing <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
…ol-handlers' Vladimir Zapolskiy says: ==================== ravb/sh_eth: fix sleep in atomic by reusing shared ethtool handlers For ages trivial changes to RAVB and SuperH ethernet links by means of standard 'ethtool' trigger a 'sleeping function called from invalid context' bug, to visualize it on r8a7795 ULCB: % ethtool -r eth0 BUG: sleeping function called from invalid context at kernel/locking/mutex.c:747 in_atomic(): 1, irqs_disabled(): 128, pid: 554, name: ethtool INFO: lockdep is turned off. irq event stamp: 0 hardirqs last enabled at (0): [<0000000000000000>] (null) hardirqs last disabled at (0): [<ffff0000080e1d3c>] copy_process.isra.7.part.8+0x2cc/0x1918 softirqs last enabled at (0): [<ffff0000080e1d3c>] copy_process.isra.7.part.8+0x2cc/0x1918 softirqs last disabled at (0): [<0000000000000000>] (null) CPU: 5 PID: 554 Comm: ethtool Not tainted 4.17.0-rc4-arm64-renesas+ rockchip-linux#33 Hardware name: Renesas H3ULCB board based on r8a7795 ES2.0+ (DT) Call trace: dump_backtrace+0x0/0x198 show_stack+0x24/0x30 dump_stack+0xb8/0xf4 ___might_sleep+0x1c8/0x1f8 __might_sleep+0x58/0x90 __mutex_lock+0x50/0x890 mutex_lock_nested+0x3c/0x50 phy_start_aneg_priv+0x38/0x180 phy_start_aneg+0x24/0x30 ravb_nway_reset+0x3c/0x68 dev_ethtool+0x3dc/0x2338 dev_ioctl+0x19c/0x490 sock_do_ioctl+0xe0/0x238 sock_ioctl+0x254/0x460 do_vfs_ioctl+0xb0/0x918 ksys_ioctl+0x50/0x80 sys_ioctl+0x34/0x48 __sys_trace_return+0x0/0x4 The root cause is that an attempt to modify ECMR and GECMR registers only when RX/TX function is disabled was too overcomplicated in its original implementation, also processing of an optional Link Change interrupt added even more complexity, as a result the implementation was error prone. The new locking scheme is confirmed to be correct by dumping driver specific and generic PHY framework function calls with aid of ftrace while running more or less advanced tests. Please note that sh_eth patches from the series were built-tested only. On purpose I do not add Fixes tags, the reused PHY handlers were added way later than the fixed problems were firstly found in the drivers. Changes from v1 to v2: * the original patches are split to bugfixes and enhancements only, both v1 and v2 series are absolutely equal in total, thus I omit description of changes in individual patches, * the latter implies that there should be no strict need for retesting, but because formally two series are different, I have to drop the tags given by Geert and Andrew, please send your tags again. ==================== Signed-off-by: David S. Miller <[email protected]>
|
I have a issue I am trying to interface mt9v032 using dvp port of rk3399 Firefly board, i am using Android 7.1 can any one help me with drivers, |
|
Hello @axendev , I am also trying to interface dual mipi camera (with same slave addr) with Rk3399 soc,But facing some issue in driver.I mean will I have to write two different drivers for two cameras to probe or a single driver will suffice the requirement. Thanks |
Change-Id: I9f2c1b0d8d56a8d3da1774f51a4701212ac6ffff added IPGRE module to enable: (rockchip-linux#18) ip tunnel add grx mode gre Change-Id: I26bda9ece68f9f6be1277da0779076694d5d845c ayufan: rockchip_linux_defconfig compile ZRAM as module Change-Id: I2ee48973cb370130cc5d75008a07d5777c69208a ayufan: rockchip_defconfig: disable CONFIG_SCHED_WALT as it makes system unstable Change-Id: Id2a150311fcaad9f11127320558dc3caafb250e4 config: add more USB wifi chipsets (rockchip-linux#19) * Add some more USB wifi chipsets to default config. * Fix typo in default config. Added openvswitch kernel module compilation (rockchip-linux#22) ayufan: defconfig: add RK805 pinctrl Change-Id: I9144206544db4e86e73a4d553fb8db3aa194c619 ayufan: enable additional realtek devices Change-Id: Ie3598c47154b648540f161ad4aedd597bc33f83f config: Add support for modules/features requested by issues rockchip-linux#24 (AUTOFS4), rockchip-linux#54 (DRBD), rockchip-linux#64 (Multiple Routing Tables), rockchip-linux#87 (RTL8188EU), rockchip-linux#107 (iSCSI), rockchip-linux#148 (1-W GPIO) (rockchip-linux#24) ayufan: rtl8812au: add Edimax 600 USB adapter Add requested kernel modules/features for issue rockchip-linux#153 and LIRC, PPS GPIO support, remove wifi staging drivers. (rockchip-linux#25) Fix compile error (rockchip-linux#26) Multiple definition error due to midgard and bifrost both selected ayufan: defconfig: add a bunch of kernel modules Change-Id: I77f5c4809c35b6c74a3bb668487eba93a0a15169 ayufan: rockchip_wlan: revert changes Change-Id: I6aa0bbc24e2fdfb6da350ed167d59c4eea836c2a ayufan: defconfig: enable CONFIG_MEMTEST Change-Id: I82c3d1b2d35fb10172f891571ef600a692ac4e61 ayufan: defconfig: remove unusued kernel configs Change-Id: I2a4a2e5785dd5796bb7404718898127718b86425 ayufan: defconfig: enable initrd in bzip2/lzma/lzo/lz4 Change-Id: I88ea1f8127d8fdadf90dd4428a51a1582adc2687 ayufan: defconfig: enable PWM FAN Change-Id: I87a364e95d937c354e06eb41fead43d8d5cb0b4a external: defconfig: Add support for f2fs and crc32 (rockchip-linux#32) Add support for f2fs and it's dependency crc32 to rock64. This patch may or may not need to be included as well due to this bug https://bugs.debian.org/819725 A official patch was added by Debian https://salsa.debian.org/kernel-team/linux/blob/master/debian/patches/bugfix/all/fs-add-module_softdep-declarations-for-hard-coded-cr.patch external: defconfig: enable kernel modules for RBD and IPVS (rockchip-linux#33) external: defconfig: Make crc, crc32, f2fs to be compiled into kernel. (rockchip-linux#35) This changes crc, crc32, and f2fs to be compiled into the kernel instead of as module. This also fixes the issue of crc32-arm64 not being compiled due to a incorrect driver name. CONFIG_CRYPTO_CRC32_ARM64 became CONFIG_CRYPTO_CRC32_ARM64_CE in newer kernel sources. That's why I had to change that here. ayufan: defconfig: use CONFIG_HZ=250 Change-Id: I8009db93ee7c5af5e7804a004ab03d0ba97d20e2 CONFIG_SQUASHFS_XZ=y (rockchip-linux#41) cyberp: defconfig: squashfs xz for snap support defconfig: enable binfmt-misc (rockchip-linux#36) ayufan: defconfig: organize with savedefconfig ayufan: defconfig: support tehuti 10gbps adapter ayufan: defconfig: enable usb gadget via configfs ayufan: dts: compile-in audio codecs Change-Id: I7c70870395a10a0eafff006aabc17faf1d33355e
[ Upstream commit 96298f6 ] According to Core Spec Version 5.2 | Vol 3, Part A 6.1.5, the incoming L2CAP_ConfigReq should be handled during OPEN state. The section below shows the btmon trace when running L2CAP/COS/CFD/BV-12-C before and after this change. === Before === ... > ACL Data RX: Handle 256 flags 0x02 dlen 12 #22 L2CAP: Connection Request (0x02) ident 2 len 4 PSM: 1 (0x0001) Source CID: 65 < ACL Data TX: Handle 256 flags 0x00 dlen 16 #23 L2CAP: Connection Response (0x03) ident 2 len 8 Destination CID: 64 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 256 flags 0x00 dlen 12 #24 L2CAP: Configure Request (0x04) ident 2 len 4 Destination CID: 65 Flags: 0x0000 > HCI Event: Number of Completed Packets (0x13) plen 5 #25 Num handles: 1 Handle: 256 Count: 1 > HCI Event: Number of Completed Packets (0x13) plen 5 #26 Num handles: 1 Handle: 256 Count: 1 > ACL Data RX: Handle 256 flags 0x02 dlen 16 #27 L2CAP: Configure Request (0x04) ident 3 len 8 Destination CID: 64 Flags: 0x0000 Option: Unknown (0x10) [hint] 01 00 .. < ACL Data TX: Handle 256 flags 0x00 dlen 18 #28 L2CAP: Configure Response (0x05) ident 3 len 10 Source CID: 65 Flags: 0x0000 Result: Success (0x0000) Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 672 > HCI Event: Number of Completed Packets (0x13) plen 5 #29 Num handles: 1 Handle: 256 Count: 1 > ACL Data RX: Handle 256 flags 0x02 dlen 14 #30 L2CAP: Configure Response (0x05) ident 2 len 6 Source CID: 64 Flags: 0x0000 Result: Success (0x0000) > ACL Data RX: Handle 256 flags 0x02 dlen 20 #31 L2CAP: Configure Request (0x04) ident 3 len 12 Destination CID: 64 Flags: 0x0000 Option: Unknown (0x10) [hint] 01 00 91 02 11 11 ...... < ACL Data TX: Handle 256 flags 0x00 dlen 14 #32 L2CAP: Command Reject (0x01) ident 3 len 6 Reason: Invalid CID in request (0x0002) Destination CID: 64 Source CID: 65 > HCI Event: Number of Completed Packets (0x13) plen 5 #33 Num handles: 1 Handle: 256 Count: 1 ... === After === ... > ACL Data RX: Handle 256 flags 0x02 dlen 12 #22 L2CAP: Connection Request (0x02) ident 2 len 4 PSM: 1 (0x0001) Source CID: 65 < ACL Data TX: Handle 256 flags 0x00 dlen 16 #23 L2CAP: Connection Response (0x03) ident 2 len 8 Destination CID: 64 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 256 flags 0x00 dlen 12 #24 L2CAP: Configure Request (0x04) ident 2 len 4 Destination CID: 65 Flags: 0x0000 > HCI Event: Number of Completed Packets (0x13) plen 5 #25 Num handles: 1 Handle: 256 Count: 1 > HCI Event: Number of Completed Packets (0x13) plen 5 #26 Num handles: 1 Handle: 256 Count: 1 > ACL Data RX: Handle 256 flags 0x02 dlen 16 #27 L2CAP: Configure Request (0x04) ident 3 len 8 Destination CID: 64 Flags: 0x0000 Option: Unknown (0x10) [hint] 01 00 .. < ACL Data TX: Handle 256 flags 0x00 dlen 18 #28 L2CAP: Configure Response (0x05) ident 3 len 10 Source CID: 65 Flags: 0x0000 Result: Success (0x0000) Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 672 > HCI Event: Number of Completed Packets (0x13) plen 5 #29 Num handles: 1 Handle: 256 Count: 1 > ACL Data RX: Handle 256 flags 0x02 dlen 14 #30 L2CAP: Configure Response (0x05) ident 2 len 6 Source CID: 64 Flags: 0x0000 Result: Success (0x0000) > ACL Data RX: Handle 256 flags 0x02 dlen 20 #31 L2CAP: Configure Request (0x04) ident 3 len 12 Destination CID: 64 Flags: 0x0000 Option: Unknown (0x10) [hint] 01 00 91 02 11 11 ..... < ACL Data TX: Handle 256 flags 0x00 dlen 18 #32 L2CAP: Configure Response (0x05) ident 3 len 10 Source CID: 65 Flags: 0x0000 Result: Success (0x0000) Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 672 < ACL Data TX: Handle 256 flags 0x00 dlen 12 #33 L2CAP: Configure Request (0x04) ident 3 len 4 Destination CID: 65 Flags: 0x0000 > HCI Event: Number of Completed Packets (0x13) plen 5 #34 Num handles: 1 Handle: 256 Count: 1 > HCI Event: Number of Completed Packets (0x13) plen 5 #35 Num handles: 1 Handle: 256 Count: 1 ... Signed-off-by: Howard Chung <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit bcd7026 ] By keep sending L2CAP_CONF_REQ packets, chan->num_conf_rsp increases multiple times and eventually it will wrap around the maximum number (i.e., 255). This patch prevents this by adding a boundary check with L2CAP_MAX_CONF_RSP Btmon log: Bluetooth monitor ver 5.64 = Note: Linux version 6.1.0-rc2 (x86_64) 0.264594 = Note: Bluetooth subsystem version 2.22 0.264636 @ MGMT Open: btmon (privileged) version 1.22 {0x0001} 0.272191 = New Index: 00:00:00:00:00:00 (Primary,Virtual,hci0) [hci0] 13.877604 @ RAW Open: 9496 (privileged) version 2.22 {0x0002} 13.890741 = Open Index: 00:00:00:00:00:00 [hci0] 13.900426 (...) > ACL Data RX: Handle 200 flags 0x00 dlen 1033 rockchip-linux#32 [hci0] 14.273106 invalid packet size (12 != 1033) 08 00 01 00 02 01 04 00 01 10 ff ff ............ > ACL Data RX: Handle 200 flags 0x00 dlen 1547 rockchip-linux#33 [hci0] 14.273561 invalid packet size (14 != 1547) 0a 00 01 00 04 01 06 00 40 00 00 00 00 00 ........@..... > ACL Data RX: Handle 200 flags 0x00 dlen 2061 rockchip-linux#34 [hci0] 14.274390 invalid packet size (16 != 2061) 0c 00 01 00 04 01 08 00 40 00 00 00 00 00 00 04 ........@....... > ACL Data RX: Handle 200 flags 0x00 dlen 2061 rockchip-linux#35 [hci0] 14.274932 invalid packet size (16 != 2061) 0c 00 01 00 04 01 08 00 40 00 00 00 07 00 03 00 ........@....... = bluetoothd: Bluetooth daemon 5.43 14.401828 > ACL Data RX: Handle 200 flags 0x00 dlen 1033 rockchip-linux#36 [hci0] 14.275753 invalid packet size (12 != 1033) 08 00 01 00 04 01 04 00 40 00 00 00 ........@... Change-Id: Id3b87180787bdded28e876ed0500ca6156579fb8 Signed-off-by: Sungwoo Kim <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit f3fe681) Signed-off-by: Greg Kroah-Hartman <[email protected]>
Rockchip ISP1 driver is a new isp driver for rockchip rk3288/rk3399 SoC, we might use it in future for all linux-kernel based OS, including Android, ChromeOS, Linux......
It's writen in standard v4l2, will be compatible with upstream sensor driver.
The development will be last until 2018.04, i hope we could have a working
driver,camera hal3,gstreamer pluginat that time.If you find something is missing in this driver, maybe you could help us add it. ; - p
e.g: MIPI TXRX, you can refer to
https://github.com/rockchip-linux/kernel/tree/release-4.4/drivers/media/platform/rk-isp10At present we have some working drivers for linux, but i recommend to not use them especially you don't have commercial support, since it's also buggy and no one can help you......
Status
I have push the new MIPI CSI driver to
isp-early-accessbranch.https://github.com/rockchip-linux/kernel/tree/isp-early-access
upstream status:
https://patchwork.linuxtv.org/project/linux-media/list/?submitter=7231
I will maintain this branch until the driver be merged into Rockchip 4.4 kernel/Upstream kernel/ChromeOS kernel.
Report bugs are welcome.
Missing feature in this new driver:
TODO in kernel 4.4:
Test in:
The text was updated successfully, but these errors were encountered: