summaryrefslogtreecommitdiffstats
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2020-06-11net/mlx5: drain health workqueue in case of driver load errorShay Drory1-0/+5
In case there is a work in the health WQ when we teardown the driver, in driver load error flow, the health work will try to read dev->iseg, which was already unmap in mlx5_pci_close(). Fix it by draining the health workqueue first thing in mlx5_pci_close(). Trace of the error: BUG: unable to handle page fault for address: ffffb5b141c18014 PF: supervisor read access in kernel mode PF: error_code(0x0000) - not-present page PGD 1fe95d067 P4D 1fe95d067 PUD 1fe95e067 PMD 1b7823067 PTE 0 Oops: 0000 [#1] SMP PTI CPU: 3 PID: 6755 Comm: kworker/u128:2 Not tainted 5.2.0-net-next-mlx5-hv_stats-over-last-worked-hyperv #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090006 04/28/2016 Workqueue: mlx5_healtha050:00:02.0 mlx5_fw_fatal_reporter_err_work [mlx5_core] RIP: 0010:ioread32be+0x30/0x40 Code: 00 77 27 48 81 ff 00 00 01 00 76 07 0f b7 d7 ed 0f c8 c3 55 48 c7 c6 3b ee d5 9f 48 89 e5 e8 67 fc ff ff b8 ff ff ff ff 5d c3 <8b> 07 0f c8 c3 66 66 2e 0f 1f 84 00 00 00 00 00 48 81 fe ff ff 03 RSP: 0018:ffffb5b14c56fd78 EFLAGS: 00010292 RAX: ffffb5b141c18000 RBX: ffff8e9f78a801c0 RCX: 0000000000000000 RDX: 0000000000000001 RSI: ffff8e9f7ecd7628 RDI: ffffb5b141c18014 RBP: ffffb5b14c56fd90 R08: 0000000000000001 R09: 0000000000000000 R10: ffff8e9f372a2c30 R11: ffff8e9f87f4bc40 R12: ffff8e9f372a1fc0 R13: ffff8e9f78a80000 R14: ffffffffc07136a0 R15: ffff8e9f78ae6f20 FS: 0000000000000000(0000) GS:ffff8e9f7ecc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffb5b141c18014 CR3: 00000001c8f82006 CR4: 00000000003606e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? mlx5_health_try_recover+0x4d/0x270 [mlx5_core] mlx5_fw_fatal_reporter_recover+0x16/0x20 [mlx5_core] devlink_health_reporter_recover+0x1c/0x50 devlink_health_report+0xfb/0x240 mlx5_fw_fatal_reporter_err_work+0x65/0xd0 [mlx5_core] process_one_work+0x1fb/0x4e0 ? process_one_work+0x16b/0x4e0 worker_thread+0x4f/0x3d0 kthread+0x10d/0x140 ? process_one_work+0x4e0/0x4e0 ? kthread_cancel_delayed_work_sync+0x20/0x20 ret_from_fork+0x1f/0x30 Modules linked in: nfsv3 rpcsec_gss_krb5 nfsv4 nfs fscache 8021q garp mrp stp llc ipmi_devintf ipmi_msghandler rpcrdma rdma_ucm ib_iser rdma_cm ib_umad iw_cm ib_ipoib libiscsi scsi_transport_iscsi ib_cm mlx5_ib ib_uverbs ib_core mlx5_core sb_edac crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel aes_x86_64 mlxfw crypto_simd cryptd glue_helper input_leds hyperv_fb intel_rapl_perf joydev serio_raw pci_hyperv pci_hyperv_mini mac_hid hv_balloon nfsd auth_rpcgss nfs_acl lockd grace sunrpc sch_fq_codel ip_tables x_tables autofs4 hv_utils hid_generic hv_storvsc ptp hid_hyperv hid hv_netvsc hyperv_keyboard pps_core scsi_transport_fc psmouse hv_vmbus i2c_piix4 floppy pata_acpi CR2: ffffb5b141c18014 ---[ end trace b12c5503157cad24 ]--- RIP: 0010:ioread32be+0x30/0x40 Code: 00 77 27 48 81 ff 00 00 01 00 76 07 0f b7 d7 ed 0f c8 c3 55 48 c7 c6 3b ee d5 9f 48 89 e5 e8 67 fc ff ff b8 ff ff ff ff 5d c3 <8b> 07 0f c8 c3 66 66 2e 0f 1f 84 00 00 00 00 00 48 81 fe ff ff 03 RSP: 0018:ffffb5b14c56fd78 EFLAGS: 00010292 RAX: ffffb5b141c18000 RBX: ffff8e9f78a801c0 RCX: 0000000000000000 RDX: 0000000000000001 RSI: ffff8e9f7ecd7628 RDI: ffffb5b141c18014 RBP: ffffb5b14c56fd90 R08: 0000000000000001 R09: 0000000000000000 R10: ffff8e9f372a2c30 R11: ffff8e9f87f4bc40 R12: ffff8e9f372a1fc0 R13: ffff8e9f78a80000 R14: ffffffffc07136a0 R15: ffff8e9f78ae6f20 FS: 0000000000000000(0000) GS:ffff8e9f7ecc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffb5b141c18014 CR3: 00000001c8f82006 CR4: 00000000003606e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 BUG: sleeping function called from invalid context at ./include/linux/percpu-rwsem.h:38 in_atomic(): 0, irqs_disabled(): 1, pid: 6755, name: kworker/u128:2 INFO: lockdep is turned off. CPU: 3 PID: 6755 Comm: kworker/u128:2 Tainted: G D 5.2.0-net-next-mlx5-hv_stats-over-last-worked-hyperv #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090006 04/28/2016 Workqueue: mlx5_healtha050:00:02.0 mlx5_fw_fatal_reporter_err_work [mlx5_core] Call Trace: dump_stack+0x63/0x88 ___might_sleep+0x10a/0x130 __might_sleep+0x4a/0x80 exit_signals+0x33/0x230 ? blocking_notifier_call_chain+0x16/0x20 do_exit+0xb1/0xc30 ? kthread+0x10d/0x140 ? process_one_work+0x4e0/0x4e0 Fixes: 52c368dc3da7 ("net/mlx5: Move health and page alloc init to mdev_init") Signed-off-by: Shay Drory <shayd@mellanox.com> Reviewed-by: Moshe Shemesh <moshe@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
2020-06-11iavf: increase reset complete wait timePaul Greenwalt2-7/+9
With an increased number of VFs, it's possible to encounter the following issue during reset. iavf b8d4:00:02.0: Hardware reset detected iavf b8d4:00:02.0: Reset never finished (0) iavf b8d4:00:02.0: Reset task did not complete, VF disabled Increase the reset complete wait count to allow for 128 VFs to complete reset. Signed-off-by: Paul Greenwalt <paul.greenwalt@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2020-06-11iavf: Fix reporting 2.5 Gb and 5Gb speedsBrett Creeley3-6/+24
Commit 4ae4916b5643 ("i40e: fix 'Unknown bps' in dmesg for 2.5Gb/5Gb speeds") added the ability for the PF to report 2.5 and 5Gb speeds, however, the iavf driver does not recognize those speeds as the values were not added there. Add the proper enums and values so that iavf can properly deal with those speeds. Fixes: 4ae4916b5643 ("i40e: fix 'Unknown bps' in dmesg for 2.5Gb/5Gb speeds") Signed-off-by: Brett Creeley <brett.creeley@intel.com> Signed-off-by: Witold Fijalkowski <witoldx.fijalkowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2020-06-11iavf: use appropriate enum for comparisonAleksandr Loktionov4-29/+24
adapter->link_speed has type enum virtchnl_link_speed but our comparisons are against enum iavf_aq_link_speed. Though they are, currently, the same values, change the comparison to the matching enum virtchnl_link_speed since that may not always be the case. Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Signed-off-by: Piotr Kwapulinski <piotr.kwapulinski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2020-06-11iavf: fix speed reporting over virtchnlBrett Creeley4-21/+120
Link speeds are communicated over virtchnl using an enum virtchnl_link_speed. Currently, the highest link speed is 40Gbps which leaves us unable to reflect some speeds that an ice VF is capable of. This causes link speed to be misreported on the iavf driver. Allow for communicating link speeds using Mbps so that the proper speed can be reported for an ice VF. Moving away from the enum allows us to communicate future speed changes without requiring a new enum to be added. In order to support communicating link speeds over virtchnl in Mbps the following functionality was added: - Added u32 link_speed_mbps in the iavf_adapter structure. - Added the macro ADV_LINK_SUPPORT(_a) to determine if the VF driver supports communicating link speeds in Mbps. - Added the function iavf_get_vpe_link_status() to fill the correct link_status in the event_data union based on the ADV_LINK_SUPPORT(_a) macro. - Added the function iavf_set_adapter_link_speed_from_vpe() to determine whether or not to fill the u32 link_speed_mbps or enum virtchnl_link_speed link_speed field in the iavf_adapter structure based on the ADV_LINK_SUPPORT(_a) macro. - Do not free vf_res in iavf_init_get_resources() as vf_res will be accessed in iavf_get_link_ksettings(); memset to 0 instead. This memory is subsequently freed in iavf_remove(). Fixes: 7c710869d64e ("ice: Add handlers for VF netdevice operations") Signed-off-by: Brett Creeley <brett.creeley@intel.com> Signed-off-by: Sergey Nemov <sergey.nemov@intel.com> Signed-off-by: Paul Greenwalt <paul.greenwalt@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2020-06-11Merge branch 'akpm' (patches from Andrew)Linus Torvalds11-30/+15
Merge some more updates from Andrew Morton: - various hotfixes and minor things - hch's use_mm/unuse_mm clearnups Subsystems affected by this patch series: mm/hugetlb, scripts, kcov, lib, nilfs, checkpatch, lib, mm/debug, ocfs2, lib, misc. * emailed patches from Andrew Morton <akpm@linux-foundation.org>: kernel: set USER_DS in kthread_use_mm kernel: better document the use_mm/unuse_mm API contract kernel: move use_mm/unuse_mm to kthread.c kernel: move use_mm/unuse_mm to kthread.c stacktrace: cleanup inconsistent variable type lib: test get_count_order/long in test_bitops.c mm: add comments on pglist_data zones ocfs2: fix spelling mistake and grammar mm/debug_vm_pgtable: fix kernel crash by checking for THP support lib: fix bitmap_parse() on 64-bit big endian archs checkpatch: correct check for kernel parameters doc nilfs2: fix null pointer dereference at nilfs_segctor_do_construct() lib/lz4/lz4_decompress.c: document deliberate use of `&' kcov: check kcov_softirq in kcov_remote_stop() scripts/spelling: add a few more typos khugepaged: selftests: fix timeout condition in wait_for_scan()
2020-06-11Merge tag 'riscv-for-linus-5.8-mw1' of ↵Linus Torvalds5-26/+215
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux Pull more RISC-V updates from Palmer Dabbelt: - Kconfig select statements are now sorted alphanumerically - first-level interrupts are now handled via a full irqchip driver - CPU hotplug is fixed - vDSO calls now use the common vDSO infrastructure * tag 'riscv-for-linus-5.8-mw1' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: riscv: set the permission of vdso_data to read-only riscv: use vDSO common flow to reduce the latency of the time-related functions riscv: fix build warning of missing prototypes RISC-V: Don't mark init section as non-executable RISC-V: Force select RISCV_INTC for CONFIG_RISCV RISC-V: Remove do_IRQ() function clocksource/drivers/timer-riscv: Use per-CPU timer interrupt irqchip: RISC-V per-HART local interrupt controller driver RISC-V: Rename and move plic_find_hart_id() to arch directory RISC-V: self-contained IPI handling routine RISC-V: Sort select statements alphanumerically
2020-06-11Merge tag 'arm64-upstream' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull arm64 fixes from Will Deacon: "arm64 fixes that came in during the merge window. There will probably be more to come, but it doesn't seem like it's worth me sitting on these in the meantime. - Fix SCS debug check to report max stack usage in bytes as advertised - Fix typo: CONFIG_FTRACE_WITH_REGS => CONFIG_DYNAMIC_FTRACE_WITH_REGS - Fix incorrect mask in HiSilicon L3C perf PMU driver - Fix compat vDSO compilation under some toolchain configurations - Fix false UBSAN warning from ACPI IORT parsing code - Fix booting under bootloaders that ignore TEXT_OFFSET - Annotate debug initcall function with '__init'" * tag 'arm64-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: arm64: warn on incorrect placement of the kernel by the bootloader arm64: acpi: fix UBSAN warning arm64: vdso32: add CONFIG_THUMB2_COMPAT_VDSO drivers/perf: hisi: Fix wrong value for all counters enable arm64: ftrace: Change CONFIG_FTRACE_WITH_REGS to CONFIG_DYNAMIC_FTRACE_WITH_REGS arm64: debug: mark a function as __init to save some memory scs: Report SCS usage in bytes rather than number of entries
2020-06-11ionic: remove support for mgmt deviceShannon Nelson4-25/+0
We no longer support the mgmt device in the ionic driver, so remove the device id and related code. Fixes: b3f064e9746d ("ionic: add support for device id 0x1004") Signed-off-by: Shannon Nelson <snelson@pensando.io> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-11Merge tag 'mailbox-v5.8' of ↵Linus Torvalds8-44/+830
git://git.linaro.org/landing-teams/working/fujitsu/integration Pull mailbox updates from Jassi Brar: "qcom: - new controller driver for IPCC - reorg the of_device data - add support for ipq6018 platform spreadtrum: - new sprd controller driver imx: - implement suspend/resume PM support misc: - make pcc driver struct static - fix return value in imx_mu_scu - disable clock before bailout in imx probe - remove duplicate error mssg in zynqmp probe - fix header size in imx.scu - check for null instead of is-err in zynqmp" * tag 'mailbox-v5.8' of git://git.linaro.org/landing-teams/working/fujitsu/integration: mailbox: qcom: Add ipq6018 apcs compatible mailbox: qcom: Add clock driver name in apcs mailbox driver data dt-bindings: mailbox: Add YAML schemas for QCOM APCS global block mailbox: imx: ONLY IPC MU needs IRQF_NO_SUSPEND flag mailbox: imx: Add runtime PM callback to handle MU clocks mailbox: imx: Add context save/restore for suspend/resume MAINTAINERS: Add entry for Qualcomm IPCC driver mailbox: Add support for Qualcomm IPCC dt-bindings: mailbox: Add devicetree binding for Qcom IPCC mailbox: zynqmp-ipi: Fix NULL vs IS_ERR() check in zynqmp_ipi_mbox_probe() mailbox: imx-mailbox: fix scu msg header size check mailbox: sprd: Add Spreadtrum mailbox driver dt-bindings: mailbox: Add the Spreadtrum mailbox documentation mailbox: ZynqMP IPI: Delete an error message in zynqmp_ipi_probe() mailbox: imx: Disable the clock on devm_mbox_controller_register() failure mailbox: imx: Fix return in imx_mu_scu_xlate() mailbox: imx: Support runtime PM mailbox: pcc: make pcc_mbox_driver static
2020-06-11drivers: dpaa2: Use devm_kcalloc() in setup_dpni()Xu Wang1-2/+3
A multiplication for the size determination of a memory allocation indicated that an array data structure should be processed. Thus use the corresponding function "devm_kcalloc". Signed-off-by: Xu Wang <vulab@iscas.ac.cn> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-11Merge tag 'drm-next-2020-06-11-1' of git://anongit.freedesktop.org/drm/drmLinus Torvalds8-14/+60
Pull drm fixes from Dave Airlie: "One sun4i fix and a connector hotplug race The ast fix is for a regression in 5.6, and one of the i915 ones fixes an oops reported by dhowells. core: - fix race in connectors sending hotplug i915: - Avoid use after free in cmdparser - Avoid NULL dereference when probing all display encoders - Fixup to module parameter type sun4i: - clock divider fix ast: - 24/32 bpp mode setting fix" * tag 'drm-next-2020-06-11-1' of git://anongit.freedesktop.org/drm/drm: drm/ast: fix missing break in switch statement for format->cpp[0] case 4 drm/sun4i: hdmi ddc clk: Fix size of m divider drm/i915/display: Only query DP state of a DDI encoder drm/i915/params: fix i915.reset module param type drm/i915/gem: Mark the buffer pool as active for the cmdparser drm/connector: notify userspace on hotplug after register complete
2020-06-11Rebase locking/kcsan to locking/urgentThomas Gleixner1-0/+2
Merge the state of the locking kcsan branch before the read/write_once() and the atomics modifications got merged. Squash the fallout of the rebase on top of the read/write once and atomic fallback work into the merge. The history of the original branch is preserved in tag locking-kcsan-2020-06-02. Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2020-06-11Merge branch 'linus' of ↵Linus Torvalds5-50/+74
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 Pull crypto fixes from Herbert Xu: "A number of fixes to the omap and nitrox drivers" * 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: crypto: cavium/nitrox - Fix 'nitrox_get_first_device()' when ndevlist is fully iterated crypto: omap-sham - add proper load balancing support for multicore crypto: omap-aes - prevent unregistering algorithms twice crypto: omap-sham - fix very small data size handling crypto: omap-sham - huge buffer access fixes crypto: omap-crypto - fix userspace copied buffer access crypto: omap-sham - force kernel driver usage for sha algos crypto: omap-aes - avoid spamming console with self tests
2020-06-11media: rkvdec: Fix H264 scaling list orderJonas Karlman1-48/+22
The Rockchip Video Decoder driver is expecting that the values in a scaling list are in zig-zag order and applies the inverse scanning process to get the values in matrix order. Commit 0b0393d59eb4 ("media: uapi: h264: clarify expected scaling_list_4x4/8x8 order") clarified that the values in the scaling list should already be in matrix order. Fix this by removing the reordering and change to use two memcpy. Fixes: cd33c830448b ("media: rkvdec: Add the rkvdec driver") Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Tested-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Reviewed-by: Ezequiel Garcia <ezequiel@collabora.com> [hverkuil-cisco@xs4all.nl: rkvdec_scaling_matrix -> rkvdec_h264_scaling_list] Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: v4l2-ctrls: Unset correct HEVC loop filter flagJonas Karlman1-1/+1
Wrong loop filter flag is unset when tiles enabled flag is not set, this cause HEVC decoding issues with Rockchip Video Decoder. Fix this by unsetting the loop filter across tiles enabled flag instead of the pps loop filter across slices enabled flag when tiles are disabled. Fixes: 256fa3920874 ("media: v4l: Add definitions for HEVC stateless decoding") Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: videobuf2-dma-contig: fix bad kfree in vb2_dma_contig_clear_max_seg_sizeTomi Valkeinen1-18/+2
Commit 9495b7e92f716ab2bd6814fab5e97ab4a39adfdd ("driver core: platform: Initialize dma_parms for platform devices") in v5.7-rc5 causes vb2_dma_contig_clear_max_seg_size() to kfree memory that was not allocated by vb2_dma_contig_set_max_seg_size(). The assumption in vb2_dma_contig_set_max_seg_size() seems to be that dev->dma_parms is always NULL when the driver is probed, and the case where dev->dma_parms has bee initialized by someone else than the driver (by calling vb2_dma_contig_set_max_seg_size) will cause a failure. All the current users of these functions are platform devices, which now always have dma_parms set by the driver core. To fix the issue for v5.7, make vb2_dma_contig_set_max_seg_size() return an error if dma_parms is NULL to be on the safe side, and remove the kfree code from vb2_dma_contig_clear_max_seg_size(). For v5.8 we should remove the two functions and move the dma_set_max_seg_size() calls into the drivers. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Fixes: 9495b7e92f71 ("driver core: platform: Initialize dma_parms for platform devices") Cc: stable@vger.kernel.org Acked-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: s5p-mfc: Properly handle dma_parms for the allocated devicesMarek Szyprowski1-1/+5
Commit 9495b7e92f71 ("driver core: platform: Initialize dma_parms for platform devices") in v5.7-rc5 added allocation of dma_parms structure to all platform devices. Then vb2_dma_contig_set_max_seg_size() have been changed not to allocate dma_parms structure and rely on the one allocated by the device core. Lets allocate the needed structure also for the devices created for the 2 MFC device memory ports. Reported-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Suggested-by: Ulf Hansson <ulf.hansson@linaro.org> Fixes: 9495b7e92f71 ("driver core: platform: Initialize dma_parms for platform devices") Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: medium: cec: Make MEDIA_CEC_SUPPORT default to n if !MEDIA_SUPPORTGeert Uytterhoeven1-1/+1
Recently, MEDIA_CEC_SUPPORT became indepedent of MEDIA_SUPPORT. However, if MEDIA_SUPPORT is not enabled, MEDIA_SUPPORT_FILTER is not defined, and MEDIA_CEC_SUPPORT is thus enabled by default, which is not desirable. Fix this by adding a dependency on MEDIA_CEC_SUPPORT to the default configuration. Fixes: 46d2a3b964ddbe63 ("media: place CEC menu before MEDIA_SUPPORT") Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: cedrus: Implement runtime PMJernej Skrabec4-45/+104
This allows the VE clocks and PLL_VE to be disabled most of the time. A runtime PM reference is held while streaming. Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net> Signed-off-by: Samuel Holland <samuel@sholland.org> Reviewed-by: Ezequiel Garcia <ezequiel@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: cedrus: Program output format during each runSamuel Holland2-3/+2
Previously, the output format was programmed as part of the ioctl() handler. However, this has two problems: 1) If there are multiple active streams with different output formats, the hardware will use whichever format was set last for both streams. Similarly, an ioctl() done in an inactive context will wrongly affect other active contexts. 2) The registers are written while the device is not actively streaming. To enable runtime PM tied to the streaming state, all hardware access needs to be moved inside cedrus_device_run(). The call to cedrus_dst_format_set() is now placed just before the codec-specific callback that programs the hardware. Cc: <stable@vger.kernel.org> Fixes: 50e761516f2b ("media: platform: Add Cedrus VPU decoder driver") Suggested-by: Jernej Skrabec <jernej.skrabec@siol.net> Suggested-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Signed-off-by: Samuel Holland <samuel@sholland.org> Tested-by: Jernej Skrabec <jernej.skrabec@siol.net> Reviewed-by: Jernej Skrabec <jernej.skrabec@siol.net> Reviewed-by: Ezequiel Garcia <ezequiel@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: atomisp: improve ACPI/DMI detection logsMauro Carvalho Chehab1-6/+12
As there are several ways where the driver could possible retrieve sensor data, make the prints clearer about what was detected and from where. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: Revert "media: atomisp: add Asus Transform T101HA ACPI vars"Mauro Carvalho Chehab1-16/+0
Now that the EFI _DSM table is parsed by the driver, we don't need a DMI match anymore for Asus Transform T101HA. This reverts commit 0a76fd8e8d202dcaabc714850205d5d75c9b8271. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: Revert "media: atomisp: Add some ACPI detection info"Mauro Carvalho Chehab7-77/+0
This reverts commit 0d64e9420583cbc3c4a3f949ebe38fd8f7769281. As gmin_subdev_add() now takes the ACPI handle directly, we can deprecate the code that were doing this inside each I2C driver. PS.: This also reverts commit c03496b3bd92 ("media: atomisp: add a notice about possible leak resources") Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: atomisp: improve sensor detection code to use _DSM tableMauro Carvalho Chehab2-47/+101
Instead of keep hardcoding device-specific tables, read them directly from the ACPI BIOS, if available. This method is know to work with Asus T101HA device. the same table is also visible on EzPad devices. So, it seems that at least some BIOSes use this method to pass data about ISP2401-connected sensors. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: atomisp: get rid of an iomem abstraction layerMauro Carvalho Chehab18-192/+44
The hive_isp_css_custom_host_hrt.h code, together with atomisp_helper.h, provides an abstraction layer for some functions inside atomisp_compat_css20.c and atomisp_cmd.c. There's no good reason for that. In a matter of fact, after removing the abstraction, the code looked a lot cleaner and easier to understand. So, get rid of them. While here, get rid also of the udelay(1) abstraction code. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: atomisp: get rid of a string_support.h abstraction layerMauro Carvalho Chehab8-215/+38
Some parts of the driver have their own implementation of memcpy() & friends. Replace all of them by strscpy(). Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: atomisp: use strscpy() instead of less secure variantsMauro Carvalho Chehab8-16/+15
Replace usages of strcpy(), strlcpy() and strncpy() in favor of strscpy(). Suggested-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: atomisp: set DFS to MAX if sensor doesn't report fpsMauro Carvalho Chehab1-2/+6
If the sensor doesn't implement support for g_frame_interval, it won't return the expected fps rate. Instead of keeping DFS on its minimal value (which will likely not work), set it to the max. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: atomisp: use different dfs failed messagesMauro Carvalho Chehab2-5/+5
There are several parts of the driver that could produce a "dfs failed!" message. Change the texts, in order to help identifying from where they're coming. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: atomisp: change the detection of ISP2401 at runtimeMauro Carvalho Chehab17-114/+108
Instead of having a static var to detect it, let's use the already-existing arch-specific bytes, as this is how other parts of the code also checks when it needs to do something different, depending on an specific chipset version. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: atomisp: use macros from intel-family.hMauro Carvalho Chehab1-4/+6
Instead of hardcoding the intel family values there, use the already defined ones from asm/intel-family.h. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: atomisp: don't set hpll_freq twice with different valuesMauro Carvalho Chehab1-4/+6
The logic which sets the hpll_freq for BYT sets hpll_freq to 1600MHz, but ignores it, and sets it again after reading from-device-specific EFI vars (this time, using a default of 2000MHz). Remove the first set, as this will be overriden anyway. While here, do minor adjustments on comments and on a printk message. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: atomisp: get rid of a detection hack for a BYT Andorid-based tabletMauro Carvalho Chehab1-65/+18
There's a hack at the driver that selects a different table for a BYT tablet, which sets the maximum frequency to 320 MHz, instead of 400 MHz. After looking at the Intel Aero Yocto's version from: https://download.01.org/aero/deb/pool/main/l/linux-4.4.76-aero-1.3/ It was noticed that this depends on an Android-specific modprobe parameter, which uses a macro (INTEL_MID_BOARD) from this file: arch/x86/include/asm/spid.h >From the comments there, it looks like this macro parses a variable passed at boot time: cmdline : androidboot.spid=vend:cust:manu:plat:prod:hard The devices in question are identified there as: INTEL_BYT_TABLET_BLK_PRO = 0x0000 INTEL_BYT_TABLET_BLK_ENG = 0x8000 Well, this is something that we don't have upstream. So, without further details about that, we can't really parse it. If we ever end supporting those devices with the upstream driver, this patch can be reverted and the device can be detected via DMI (or maybe via PCI ID?). Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: atomisp: use just one mamoiada_params.hMauro Carvalho Chehab3-216/+1
As both isp2400 and isp2401 files are identical, remove one of them and remove the test for ISP variant. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: atomisp: remove some unused defines from *mamoiada_params.hMauro Carvalho Chehab2-38/+2
There are some parameters that are different between isp2400 and isp2401. None of those are actually used. So, get rid of them. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: atomisp: simplify IRQ ifdef logicMauro Carvalho Chehab9-120/+2
There are lots of mess with IRQ ifdef settings. As the *_global.h will already detect the type of IRQ system at compile time, we can get rid of them, replacing by just one ifdef for ISP2401. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: atomisp: get rid of ifdef nonsenseMauro Carvalho Chehab1-8/+8
There are some ifdefs there that end doing the same thing. Get rid of them. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: atomisp: get rid of a duplicated fileMauro Carvalho Chehab3-78/+1
The contents of hive_isp_css_2401_irq_types_hrt.h and hive_isp_css_common/irq_global.h are identical, except for one unused enum: On isp2401, this IRQ line has this name: hrt_isp_css_irq_is2401 = HIVE_GP_DEV_IRQ_ISP_PMEM_ERROR_BIT_ID, While the same bit is named as: hrt_isp_css_irq_isp_pmem_error = HIVE_GP_DEV_IRQ_ISP_PMEM_ERROR_BIT_ID, At the isp2400 version. Remove one of them, in order to reduce the code differences between those two versions. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: atomisp: do some cleanup at irq_local.hMauro Carvalho Chehab5-44/+30
- Get rid of typedefs; - Get rid of a duplicated enum type with different names for ISP2400 and ISP2401; - adjust indentation on the touched code. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: atomisp: improve IRQ handling debug messagesMauro Carvalho Chehab1-5/+6
When an IRQ is not handled, it is nice to know what's the reason. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: atomisp: comment an unused codeMauro Carvalho Chehab1-0/+8
There's a different table for some BYT variants that depend on something inside a FIXME ifdef. Place this also inside it, just to shut up a clang-11 warning. Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: atomisp: get rid of a left-over wrapper functionMauro Carvalho Chehab1-8/+0
The abstraction layer for kvfree() was removed, but there is still a left-over code there. Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: atomisp: get rid of an unused IRQ duplicated eventMauro Carvalho Chehab1-4/+1
There are two names for the same IRQ, but just one is used. Remove the unused one. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: atomisp: get rid of sh_css_pipe.cMauro Carvalho Chehab2-18/+0
There's nothing there, just comments. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: staging: media: atomisp: fix stack overflow in init_pipe_defaults()Arnd Bergmann9-42/+46
When building with clang, multiple copies of the structures to be initialized are passed around on the stack and copied locally, using an insane amount of stack space: drivers/staging/media/atomisp/pci/sh_css.c:2371:1: error: stack frame size of 26864 bytes in function 'create_pipe' [-Werror,-Wframe-larger-than=] Use constantly-allocated variables plus an explicit memcpy() to avoid that. Co-authored-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Fixes: 6dc9a2568f84 ("media: atomisp: convert default struct values to use compound-literals with designated initializers") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: atomisp: re-enable warnings againMauro Carvalho Chehab7-30/+30
For most warnings, the current code is OK. There are still some issues with implicit-fallthough warnings. Solve those and re-enable all warnings for this driver. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: atomisp: remove format duplication at mbus->fourcc tableMauro Carvalho Chehab3-26/+25
This table used to be used also to translate between ia_css abstraction and V4L2 fourcc codes. This was removed on a past patch, but the table now contains two fields with identical values. Get rid of one of them. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: staging: media: atomisp: add PMIC_OPREGION dependencyArnd Bergmann1-0/+1
Without that driver, there is a link failure in ERROR: modpost: "intel_soc_pmic_exec_mipi_pmic_seq_element" [drivers/staging/media/atomisp/pci/atomisp_gmin_platform.ko] undefined! Add an explicit Kconfig dependency. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: staging: media: atomisp: disable all custom formatsArnd Bergmann1-0/+2
clang points out the usage of an incorrect enum type in the list of supported image formats: drivers/staging/media/atomisp/pci/atomisp_subdev.c:49:65: error: implicit conversion from enumeration type 'enum ia_css_frame_format' to different enumeration type 'enum atomisp_input_format' [-Werror,-Wenum-conversion] { V4L2_MBUS_FMT_CUSTOM_NV21, 12, 12, CSS_FRAME_FORMAT_NV21, 0, CSS_FRAME_FORMAT_NV21 }, drivers/staging/media/atomisp/pci/atomisp_subdev.c:49:39: error: implicit conversion from enumeration type 'enum ia_css_frame_format' to different enumeration type 'enum atomisp_input_format' [-Werror,-Wenum-conversion] { V4L2_MBUS_FMT_CUSTOM_NV21, 12, 12, CSS_FRAME_FORMAT_NV21, 0, CSS_FRAME_FORMAT_NV21 }, { V4L2_MBUS_FMT_CUSTOM_NV12, 12, 12, CSS_FRAME_FORMAT_NV12, 0, CSS_FRAME_FORMAT_NV12 }, { MEDIA_BUS_FMT_JPEG_1X8, 8, 8, CSS_FRAME_FORMAT_BINARY_8, 0, ATOMISP_INPUT_FORMAT_BINARY_8 }, Checking the git history, I found a commit that disabled one such case because it did not work. It seems likely that the incorrect enum was part of the original problem and that the others do not work either, or have never been tested. Disable all the ones that cause a warning. Fixes: cb02ae3d71ea ("media: staging: atomisp: Disable custom format for now") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-13 13:26:26 +0000