summaryrefslogtreecommitdiff
path: root/drivers/media
AgeCommit message (Collapse)AuthorFilesLines
2015-07-21x86/mm/pat, drivers/media/ivtv: Move the PAT warning and replace WARN() with ↵Luis R. Rodriguez1-6/+9
pr_warn() On built-in kernels this warning will always splat, even if no ivtvfb hardware is present, as this is part of the module init: if (WARN(pat_enabled(), "ivtvfb needs PAT disabled, boot with nopat kernel parameter\n")) { Fix that by shifting the PAT requirement check out under the code that does the "quasi-probe" for the device. This device driver relies on an existing driver to find its own devices, it looks for that device driver and its own found devices, then uses driver_for_each_device() to try to see if it can probe each of those devices as a frambuffer device with ivtvfb_init_card(). We tuck the PAT requiremenet check then on the ivtvfb_init_card() call making the check at least require an ivtv device present before complaining. Reported-by: Fengguang Wu <fengguang.wu@intel.com> [0-day test robot] Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: andy@silverblocksystems.net Cc: benh@kernel.crashing.org Cc: bp@suse.de Cc: dan.j.williams@intel.com Cc: dledford@redhat.com Cc: jkosina@suse.cz Cc: julia.lawall@lip6.fr Cc: luto@amacapital.net Cc: mchehab@osg.samsung.com Link: http://lkml.kernel.org/r/1437167245-28273-3-git-send-email-mcgrof@do-not-panic.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-07-01Merge branch 'for-next' of ↵Linus Torvalds4-12/+750
git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds Pull LED subsystem updates from Bryan Wu: "In this cycle, we finished to merge patches for LED Flash class driver. Other than that we have some bug fixes and new drivers for LED controllers" * 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds: (33 commits) leds:lp55xx: fix firmware loading error leds: fix max77693-led build errors leds: fix aat1290 build errors leds: aat1290: pass flags parameter to devm_gpiod_get leds: ktd2692: pass flags parameter to devm_gpiod_get drivers/leds: don't use module_init in non-modular leds-cobalt-raq.c leds: aat1290: add support for V4L2 Flash sub-device DT: aat1290: Document handling external strobe sources leds: max77693: add support for V4L2 Flash sub-device media: Add registration helpers for V4L2 flash sub-devices v4l: async: Add a pointer to of_node to struct v4l2_subdev, match it Documentation: leds: Add description of v4l2-flash sub-device leds: add BCM6358 LED driver leds: add DT binding for BCM6358 LED controller leds: fix brightness changing when software blinking is active Documentation: leds-lp5523: describe master fader attributes leds: lp5523: add master_fader support leds: leds-gpio: Allow compile test if !GPIOLIB leds: leds-gpio: Add missing #include <linux/of.h> gpiolib: Add missing dummies for the unified device properties interface ...
2015-06-30genalloc: rename of_get_named_gen_pool() to of_gen_pool_get()Vladimir Zapolskiy1-1/+1
To be consistent with other kernel interface namings, rename of_get_named_gen_pool() to of_gen_pool_get(). In the original function name "_named" suffix references to a device tree property, which contains a phandle to a device and the corresponding device driver is assumed to register a gen_pool object. Due to a weak relation and to avoid any confusion (e.g. in future possible scenario if gen_pool objects are named) the suffix is removed. [sfr@canb.auug.org.au: crypto/marvell/cesa - fix up for of_get_named_gen_pool() rename] Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Cc: Nicolas Ferre <nicolas.ferre@atmel.com> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: Shawn Guo <shawn.guo@linaro.org> Cc: Sascha Hauer <kernel@pengutronix.de> Cc: Alexandre Belloni <alexandre.belloni@free-electrons.com> Cc: Russell King <linux@arm.linux.org.uk> Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Cc: Vinod Koul <vinod.koul@intel.com> Cc: Takashi Iwai <tiwai@suse.de> Cc: Jaroslav Kysela <perex@perex.cz> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: Boris BREZILLON <boris.brezillon@free-electrons.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2015-06-30genalloc: rename dev_get_gen_pool() to gen_pool_get()Vladimir Zapolskiy1-1/+1
To be consistent with other genalloc interface namings, rename dev_get_gen_pool() to gen_pool_get(). The original omitted "dev_" prefix is removed, since it points to argument type of the function, and so it does not bring any useful information. [akpm@linux-foundation.org: update arch/arm/mach-socfpga/pm.c] Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: Shawn Guo <shawn.guo@linaro.org> Cc: Sascha Hauer <kernel@pengutronix.de> Cc: Alexandre Belloni <alexandre.belloni@free-electrons.com> Cc: Russell King <linux@arm.linux.org.uk> Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Cc: Vinod Koul <vinod.koul@intel.com> Cc: Takashi Iwai <tiwai@suse.de> Cc: Jaroslav Kysela <perex@perex.cz> Cc: Mark Brown <broonie@kernel.org> Cc: Nicolas Ferre <nicolas.ferre@atmel.com> Cc: Alan Tull <atull@opensource.altera.com> Cc: Dinh Nguyen <dinguyen@opensource.altera.com> Cc: Kevin Hilman <khilman@linaro.org> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2015-06-26Merge tag 'staging-4.2-rc1' of ↵Linus Torvalds1-1/+0
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging Pull staging driver updates from Greg KH: "Here's the big, really big, staging tree patches for 4.2-rc1. Loads of stuff in here, almost all just coding style fixes / churn, and a few new drivers as well, one of which I just disabled from the build a few minutes ago due to way too many build warnings. Other than the one "disable this driver" patch, all of these have been in linux-next for quite a while with no reported issues" * tag 'staging-4.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: (1163 commits) staging: wilc1000: disable driver due to build warnings Staging: rts5208: fix CHANGE_LINK_STATE value Staging: sm750fb: ddk750_swi2c.c: Insert spaces before parenthesis Staging: sm750fb: ddk750_swi2c.c: Place braces on correct lines Staging: sm750fb: ddk750_swi2c.c: Insert spaces around operators Staging: sm750fb: ddk750_swi2c.c: Replace spaces with tabs Staging: sm750fb: ddk750_swi2c.h: Shorten lines to under 80 characters Staging: sm750fb: ddk750_swi2c.h: Replace spaces with tabs Staging: sm750fb: modedb.h: Shorten lines to under 80 characters Staging: sm750fb: modedb.h: Replace spaces with tabs staging: comedi: addi_apci_3120: rename 'this_board' variables staging: comedi: addi_apci_1516: rename 'this_board' variables staging: comedi: ni_atmio: cleanup ni_getboardtype() staging: comedi: vmk80xx: sanity check context used to get the boardinfo staging: comedi: vmk80xx: rename 'boardinfo' variables staging: comedi: dt3000: rename 'this_board' variables staging: comedi: adv_pci_dio: rename 'this_board' variables staging: comedi: cb_pcidas64: rename 'thisboard' variables staging: comedi: cb_pcidas: rename 'thisboard' variables staging: comedi: me4000: rename 'thisboard' variables ...
2015-06-26Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linuxLinus Torvalds1-1/+1
Pull drm updates from Dave Airlie: "This is the main drm pull request for v4.2. I've one other new driver from freescale on my radar, it's been posted and reviewed, I'd just like to get someone to give it a last look, so maybe I'll send it or maybe I'll leave it. There is no major nouveau changes in here, Ben was working on something big, and we agreed it was a bit late, there wasn't anything else he considered urgent to merge. There might be another msm pull for some bits that are waiting on arm-soc, I'll see how we time it. This touches some "of" stuff, acks are in place except for the fixes to the build in various configs,t hat I just applied. Summary: New drivers: - virtio-gpu: KMS only pieces of driver for virtio-gpu in qemu. This is just the first part of this driver, enough to run unaccelerated userspace on. As qemu merges more we'll start adding the 3D features for the virgl 3d work. - amdgpu: a new driver from AMD to driver their newer GPUs. (VI+) It contains a new cleaner userspace API, and is a clean break from radeon moving forward, that AMD are going to concentrate on. It also contains a set of register headers auto generated from AMD internal database. core: - atomic modesetting API completed, enabled by default now. - Add support for mode_id blob to atomic ioctl to complete interface. - bunch of Displayport MST fixes - lots of misc fixes. panel: - new simple panels - fix some long-standing build issues with bridge drivers radeon: - VCE1 support - add a GPU reset counter for userspace - lots of fixes. amdkfd: - H/W debugger support module - static user-mode queues - support killing all the waves when a process terminates - use standard DECLARE_BITMAP i915: - Add Broxton support - S3, rotation support for Skylake - RPS booting tuning - CPT modeset sequence fixes - ns2501 dither support - enable cmd parser on haswell - cdclk handling fixes - gen8 dynamic pte allocation - lots of atomic conversion work exynos: - Add atomic modesetting support - Add iommu support - Consolidate drm driver initialization - and MIC, DECON and MIPI-DSI support for exynos5433 omapdrm: - atomic modesetting support (fixes lots of things in rewrite) tegra: - DP aux transaction fixes - iommu support fix msm: - adreno a306 support - various dsi bits - various 64-bit fixes - NV12MT support rcar-du: - atomic and misc fixes sti: - fix HDMI timing complaince tilcdc: - use drm component API to access tda998x driver - fix module unloading qxl: - stability fixes" * 'drm-next' of git://people.freedesktop.org/~airlied/linux: (872 commits) drm/nouveau: Pause between setting gpu to D3hot and cutting the power drm/dp/mst: close deadlock in connector destruction. drm: Always enable atomic API drm/vgem: Set unique to "vgem" of: fix a build error to of_graph_get_endpoint_by_regs function drm/dp/mst: take lock around looking up the branch device on hpd irq drm/dp/mst: make sure mst_primary mstb is valid in work function of: add EXPORT_SYMBOL for of_graph_get_endpoint_by_regs ARM: dts: rename the clock of MIPI DSI 'pll_clk' to 'sclk_mipi' drm/atomic: Don't set crtc_state->enable manually drm/exynos: dsi: do not set TE GPIO direction by input drm/exynos: dsi: add support for MIC driver as a bridge drm/exynos: dsi: add support for Exynos5433 drm/exynos: dsi: make use of array for clock access drm/exynos: dsi: make use of driver data for static values drm/exynos: dsi: add macros for register access drm/exynos: dsi: rename pll_clk to sclk_clk drm/exynos: mic: add MIC driver of: add helper for getting endpoint node of specific identifiers drm/exynos: add Exynos5433 decon driver ...
2015-06-25Merge tag 'media/v4.2-1' of ↵Linus Torvalds473-6623/+23455
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media Pull media updates from Mauro Carvalho Chehab: - Lots of improvements at the DVB API DocBook documentation. Now, the frontend and the network APIs are fully in sync with the Kernel and looks more like the rest of the media documentation; - New frontend driver: cx24120 - New driver for a PCI device: cobalt. This driver is actually not sold in the market, but it is a good example of a multi-HDMI input device; - The dt3155 driver were promoted from staging; - The mantis driver got remote controller support; - New V4L2 driver for ST bdisp SoC chipsets; - Make sparse and smatch happier: several bugs were solved by fixing the issues reported by those static code analyzers. - Lots of new device additions, new features, improvements and cleanups at the existing drivers. * tag 'media/v4.2-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: (553 commits) [media] lmedm04: fix the range for relative measurements [media] lmedm04: use u32 instead of u64 for relative stats [media] omap3isp: remove unused var [media] saa7134: fix page size on some archs [media] use CONFIG_PM_SLEEP for suspend/resume [media] tuner-i2c: be consistent with I2C declaration [media] si470x: cleanup define namespace [media] bdisp: prevent compiling on random arch [media] vb2: Don't WARN when v4l2_buffer.bytesused is 0 for multiplanar buffers [media] MAINTAINERS: Add entry for the Renesas VSP1 driver [media] videodev2.h: fix copy-and-paste error in V4L2_MAP_XFER_FUNC_DEFAULT [media] Revert "[media] vb2: Push mmap_sem down to memops" [media] mantis: cleanup a warning [media] bdisp-debug: don't try to divide by s64 [media] cx88: don't declare restart_video_queue if not used [media] au0828: move dev->boards atribuition to happen earlier [media] lmedm04: implement dvb v5 statistics [media] bdisp: remove unused var [media] bdisp: remove needless check ts2020: fix compilation on i386 ...
2015-06-24[media] lmedm04: fix the range for relative measurementsMauro Carvalho Chehab1-11/+8
Relative measurements are typically between 0 and 0xffff. However, for some tuners (TUNER_S7395 and TUNER_S0194), the range were from 0 to 0xff00, with means that 100% is never archived. Also, TUNER_RS2000 uses a more complex math. So, create a macro that does the conversion using bit operations and use it for all conversions. The code is also easier to read with is a bonus. While here, remove a bogus comment. Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2015-06-24[media] lmedm04: use u32 instead of u64 for relative statsMauro Carvalho Chehab1-3/+3
Cleanup this sparse warning: drivers/media/usb/dvb-usb-v2/lmedm04.c:302 lme2510_update_stats() warn: should '((255 - st->signal_sn - 161) * 3) << 8' be a 64 bit type? Both c_tmp and s_tmp actually stores a u16 stat. Using a u64 data there is a waste, specially on u32 archs, as 64 ints there are more expensive. So, change the types to u32 and do the typecast only when storing the result. Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2015-06-24[media] omap3isp: remove unused varMauro Carvalho Chehab1-4/+0
drivers/media/platform/omap3isp/isppreview.c:932:6: warning: variable ‘features’ set but not used [-Wunused-but-set-variable] Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2015-06-24[media] saa7134: fix page size on some archsMauro Carvalho Chehab1-3/+3
On some archs, like tile, the PAGE_SIZE is not 4K. In the case of tile arch, it can be either 16KB or 64KB. Due to that, a warning is produced: drivers/media/pci/saa7134/saa7134.h:678:43: warning: large integer implicitly truncated to unsigned type [-Woverflow] This is actually an error, as it will write trach to the DMA size registers. The logic at saa7134-ts already does the right thing: saa_writeb(SAA7134_TS_DMA0, ((dev->ts.nr_packets-1)&0xff)); saa_writeb(SAA7134_TS_DMA1, (((dev->ts.nr_packets-1)>>8)&0xff)); /* TSNOPIT=0, TSCOLAP=0 */ saa_writeb(SAA7134_TS_DMA2, ((((dev->ts.nr_packets-1)>>16)&0x3f) | 0x00)); So, fix the driver to take larger page sizes into account. Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2015-06-24[media] use CONFIG_PM_SLEEP for suspend/resumeMauro Carvalho Chehab1-1/+1
Using CONFIG_PM_SLEEP suppress the warnings when the driver is compiled without PM sleep functions: drivers/media/rc/st_rc.c:338:12: warning: ‘st_rc_suspend’ defined but not used [-Wunused-function] drivers/media/rc/st_rc.c:359:12: warning: ‘st_rc_resume’ defined but not used [-Wunused-function] Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Acked-by: Maxime Coquelin <maxime.coquelin@st.com>
2015-06-23Merge branch 'for-linus' of ↵Linus Torvalds1-3/+3
git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial Pull trivial tree updates from Jiri Kosina: "As usual, mostly comment, kerneldoc and printk() fixes" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial: lpfc: Grammar s/an negative/a negative/ ARM: lib/lib1funcs.S: fix typo s/substractions/subtractions/ cx25821: cx25821-medusa-reg.h: fix 0x0x prefix lib: crc-itu-t.[ch] fix 0x0x prefix in integer constants rapidio: Fix kerneldoc and comment qla4xxx: Fix printk() in qla4_83xx_read_reset_template() and qla4_83xx_pre_loopback_config() treewide: Kconfig: fix wording / spelling usb/serial: fix grammar in Kconfig help text for FTDI_SIO megaraid_sas: fix kerneldoc netfilter: ebtables: fix comment grammar drm/radeon: fix comment isdn: fix grammar in comment ARM: KVM: fix comment
2015-06-23[media] tuner-i2c: be consistent with I2C declarationMauro Carvalho Chehab1-4/+6
On alpha, gcc warns a log about signed/unsigned ballance, with produces 3185 warnings. Ok, this is bogus, but it indicates that the declaration at V4L2 side is not consistent with the one at I2C. With this trivial patch, the number of errors reduce to 2959 warnings. Still too much, but it is 7.1% less. So let's do it. Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2015-06-22Merge branch 'x86-core-for-linus' of ↵Linus Torvalds2-35/+26
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 core updates from Ingo Molnar: "There were so many changes in the x86/asm, x86/apic and x86/mm topics in this cycle that the topical separation of -tip broke down somewhat - so the result is a more traditional architecture pull request, collected into the 'x86/core' topic. The topics were still maintained separately as far as possible, so bisectability and conceptual separation should still be pretty good - but there were a handful of merge points to avoid excessive dependencies (and conflicts) that would have been poorly tested in the end. The next cycle will hopefully be much more quiet (or at least will have fewer dependencies). The main changes in this cycle were: * x86/apic changes, with related IRQ core changes: (Jiang Liu, Thomas Gleixner) - This is the second and most intrusive part of changes to the x86 interrupt handling - full conversion to hierarchical interrupt domains: [IOAPIC domain] ----- | [MSI domain] --------[Remapping domain] ----- [ Vector domain ] | (optional) | [HPET MSI domain] ----- | | [DMAR domain] ----------------------------- | [Legacy domain] ----------------------------- This now reflects the actual hardware and allowed us to distangle the domain specific code from the underlying parent domain, which can be optional in the case of interrupt remapping. It's a clear separation of functionality and removes quite some duct tape constructs which plugged the remap code between ioapic/msi/hpet and the vector management. - Intel IOMMU IRQ remapping enhancements, to allow direct interrupt injection into guests (Feng Wu) * x86/asm changes: - Tons of cleanups and small speedups, micro-optimizations. This is in preparation to move a good chunk of the low level entry code from assembly to C code (Denys Vlasenko, Andy Lutomirski, Brian Gerst) - Moved all system entry related code to a new home under arch/x86/entry/ (Ingo Molnar) - Removal of the fragile and ugly CFI dwarf debuginfo annotations. Conversion to C will reintroduce many of them - but meanwhile they are only getting in the way, and the upstream kernel does not rely on them (Ingo Molnar) - NOP handling refinements. (Borislav Petkov) * x86/mm changes: - Big PAT and MTRR rework: making the code more robust and preparing to phase out exposing direct MTRR interfaces to drivers - in favor of using PAT driven interfaces (Toshi Kani, Luis R Rodriguez, Borislav Petkov) - New ioremap_wt()/set_memory_wt() interfaces to support Write-Through cached memory mappings. This is especially important for good performance on NVDIMM hardware (Toshi Kani) * x86/ras changes: - Add support for deferred errors on AMD (Aravind Gopalakrishnan) This is an important RAS feature which adds hardware support for poisoned data. That means roughly that the hardware marks data which it has detected as corrupted but wasn't able to correct, as poisoned data and raises an APIC interrupt to signal that in the form of a deferred error. It is the OS's responsibility then to take proper recovery action and thus prolonge system lifetime as far as possible. - Add support for Intel "Local MCE"s: upcoming CPUs will support CPU-local MCE interrupts, as opposed to the traditional system- wide broadcasted MCE interrupts (Ashok Raj) - Misc cleanups (Borislav Petkov) * x86/platform changes: - Intel Atom SoC updates ... and lots of other cleanups, fixlets and other changes - see the shortlog and the Git log for details" * 'x86-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (222 commits) x86/hpet: Use proper hpet device number for MSI allocation x86/hpet: Check for irq==0 when allocating hpet MSI interrupts x86/mm/pat, drivers/infiniband/ipath: Use arch_phys_wc_add() and require PAT disabled x86/mm/pat, drivers/media/ivtv: Use arch_phys_wc_add() and require PAT disabled x86/platform/intel/baytrail: Add comments about why we disabled HPET on Baytrail genirq: Prevent crash in irq_move_irq() genirq: Enhance irq_data_to_desc() to support hierarchy irqdomain iommu, x86: Properly handle posted interrupts for IOMMU hotplug iommu, x86: Provide irq_remapping_cap() interface iommu, x86: Setup Posted-Interrupts capability for Intel iommu iommu, x86: Add cap_pi_support() to detect VT-d PI capability iommu, x86: Avoid migrating VT-d posted interrupts iommu, x86: Save the mode (posted or remapped) of an IRTE iommu, x86: Implement irq_set_vcpu_affinity for intel_ir_chip iommu: dmar: Provide helper to copy shared irte fields iommu: dmar: Extend struct irte for VT-d Posted-Interrupts iommu: Add new member capability to struct irq_remap_ops x86/asm/entry/64: Disentangle error_entry/exit gsbase/ebx/usermode code x86/asm/entry/32: Shorten __audit_syscall_entry() args preparation x86/asm/entry/32: Explain reloading of registers after __audit_syscall_entry() ...
2015-06-22media: Add registration helpers for V4L2 flash sub-devicesJacek Anaszewski3-0/+723
This patch adds helper functions for registering/unregistering LED Flash class devices as V4L2 sub-devices. The functions should be called from the LED subsystem device driver. In case the support for V4L2 Flash sub-devices is disabled in the kernel config the functions' empty versions will be used. Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com> Acked-by: Kyungmin Park <kyungmin.park@samsung.com> Cc: Sakari Ailus <sakari.ailus@iki.fi> Cc: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2015-06-22[media] si470x: cleanup define namespaceMauro Carvalho Chehab3-10/+10
Some architectures already use CHIPID defines: drivers/media/radio/si470x/radio-si470x.h:57:0: warning: "CHIPID" redefined [enabled by default] drivers/media/radio/si470x/radio-si470x.h:57:0: warning: "CHIPID" redefined [enabled by default] drivers/media/radio/si470x/radio-si470x.h:57:0: warning: "CHIPID" redefined [enabled by default] So, use SI_foo namespace to avoid conflicts. Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2015-06-22[media] bdisp: prevent compiling on random archMauro Carvalho Chehab2-10/+1
This driver requires support for DMA attrs function, and not just DMA. Change the options accordingly to remove those errors: /devel/v4l/to_next/drivers/media/platform/sti/bdisp/bdisp-hw.c: In function ‘bdisp_hw_free_nodes’: /devel/v4l/to_next/drivers/media/platform/sti/bdisp/bdisp-hw.c:132:3: error: implicit declaration of function ‘dma_free_attrs’ [-Werror=implicit-function-declaration] dma_free_attrs(ctx->bdisp_dev->dev, ^ /devel/v4l/to_next/drivers/media/platform/sti/bdisp/bdisp-hw.c: In function ‘bdisp_hw_alloc_nodes’: /devel/v4l/to_next/drivers/media/platform/sti/bdisp/bdisp-hw.c:157:9: error: implicit declaration of function ‘dma_alloc_attrs’ [-Werror=implicit-function-declaration] base = dma_alloc_attrs(dev, node_size * MAX_NB_NODE, &paddr, ^ /devel/v4l/to_next/drivers/media/platform/sti/bdisp/bdisp-hw.c:157:7: warning: assignment makes pointer from integer without a cast [-Wint-conversion] base = dma_alloc_attrs(dev, node_size * MAX_NB_NODE, &paddr, ^ /devel/v4l/to_next/drivers/media/platform/sti/bdisp/bdisp-hw.c: In function ‘bdisp_hw_alloc_filters’: /devel/v4l/to_next/drivers/media/platform/sti/bdisp/bdisp-hw.c:219:7: warning: assignment makes pointer from integer without a cast [-Wint-conversion] base = dma_alloc_attrs(dev, size, &paddr, GFP_KERNEL | GFP_DMA, &attrs); Also, get rid of bogus, unused and duplicated symbol declaration for the config option done at bdisp/Kconfig. Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2015-06-22[media] vb2: Don't WARN when v4l2_buffer.bytesused is 0 for multiplanar buffersLaurent Pinchart1-10/+23
Commit f61bf13b6a07 ("[media] vb2: add allow_zero_bytesused flag to the vb2_queue struct") added a WARN_ONCE to catch usage of a deprecated API using a zero value for v4l2_buffer.bytesused. However, the condition is checked incorrectly, as the v4L2_buffer bytesused field is supposed to be ignored for multiplanar buffers. This results in spurious warnings when using the multiplanar API. Fix it by checking v4l2_buffer.bytesused for uniplanar buffers and v4l2_plane.bytesused for multiplanar buffers. Fixes: f61bf13b6a07 ("[media] vb2: add allow_zero_bytesused flag to the vb2_queue struct") Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Cc: stable@vger.kernel.org # for v4.0 Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2015-06-18[media] Revert "[media] vb2: Push mmap_sem down to memops"Hans Verkuil4-18/+3
This reverts commit 48b25a3a713b90988b6882d318f7c0a6bed9aabc. That commit caused two regressions. The first is a BUG: Jun 14 18:42:15 test-media kernel: [ 115.972299] BUG: unable to handle kernel NULL pointer dereference at 0000000000000100 Jun 14 18:42:15 test-media kernel: [ 115.972307] IP: [<ffffffff810d5cd0>] __lock_acquire+0x2f0/0x2070 Jun 14 18:42:15 test-media kernel: [ 115.972316] PGD 0 Jun 14 18:42:15 test-media kernel: [ 115.972318] Oops: 0000 [#1] PREEMPT SMP Jun 14 18:42:15 test-media kernel: [ 115.972321] Modules linked in: vivid v4l2_dv_timings videobuf2_vmalloc videobuf2_memops videobuf2_core v4l2_common videodev media vmw_balloon vmw_vmci acpi_cpufreq processor button Jun 14 18:42:15 test-media kernel: [ 115.972333] CPU: 0 PID: 1542 Comm: v4l2-ctl Not tainted 4.1.0-rc3-test-media #1190 Jun 14 18:42:15 test-media kernel: [ 115.972336] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/20/2014 Jun 14 18:42:15 test-media kernel: [ 115.972337] task: ffff880220ce4200 ti: ffff88021d16c000 task.ti: ffff88021d16c000 Jun 14 18:42:15 test-media kernel: [ 115.972339] RIP: 0010:[<ffffffff810d5cd0>] [<ffffffff810d5cd0>] __lock_acquire+0x2f0/0x2070 Jun 14 18:42:15 test-media kernel: [ 115.972342] RSP: 0018:ffff88021d16f9b8 EFLAGS: 00010002 Jun 14 18:42:15 test-media kernel: [ 115.972343] RAX: 0000000000000046 RBX: 0000000000000292 RCX: 0000000000000001 Jun 14 18:42:15 test-media kernel: [ 115.972345] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000100 Jun 14 18:42:15 test-media kernel: [ 115.972346] RBP: ffff88021d16fa88 R08: 0000000000000001 R09: 0000000000000000 Jun 14 18:42:15 test-media kernel: [ 115.972347] R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000001 Jun 14 18:42:15 test-media kernel: [ 115.972348] R13: ffff880220ce4200 R14: 0000000000000100 R15: 0000000000000000 Jun 14 18:42:15 test-media kernel: [ 115.972350] FS: 00007f2441e7f740(0000) GS:ffff880236e00000(0000) knlGS:0000000000000000 Jun 14 18:42:15 test-media kernel: [ 115.972351] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b Jun 14 18:42:15 test-media kernel: [ 115.972353] CR2: 0000000000000100 CR3: 0000000001e0b000 CR4: 00000000001406f0 Jun 14 18:42:15 test-media kernel: [ 115.972424] Stack: Jun 14 18:42:15 test-media kernel: [ 115.972427] ffff88021d16fa98 ffffffff810d6543 0000000000000006 0000000000000246 Jun 14 18:42:15 test-media kernel: [ 115.972431] ffff88021d16fa08 ffffffff810d532d ffff880220ce4a78 ffff880200000000 Jun 14 18:42:15 test-media kernel: [ 115.972433] ffff880200000001 0000000000000000 0000000000000001 000000000093a4a0 Jun 14 18:42:15 test-media kernel: [ 115.972436] Call Trace: Jun 14 18:42:15 test-media kernel: [ 115.972440] [<ffffffff810d6543>] ? __lock_acquire+0xb63/0x2070 Jun 14 18:42:15 test-media kernel: [ 115.972443] [<ffffffff810d532d>] ? mark_held_locks+0x6d/0xa0 Jun 14 18:42:15 test-media kernel: [ 115.972445] [<ffffffff810d37a8>] ? __lock_is_held+0x58/0x80 Jun 14 18:42:15 test-media kernel: [ 115.972447] [<ffffffff810d852c>] lock_acquire+0x6c/0xa0 Jun 14 18:42:15 test-media kernel: [ 115.972452] [<ffffffffa039f1f6>] ? vb2_vmalloc_put_userptr+0x36/0x110 [videobuf2_vmalloc] Jun 14 18:42:15 test-media kernel: [ 115.972458] [<ffffffff819b1a92>] down_read+0x42/0x60 Jun 14 18:42:15 test-media kernel: [ 115.972460] [<ffffffffa039f1f6>] ? vb2_vmalloc_put_userptr+0x36/0x110 [videobuf2_vmalloc] Jun 14 18:42:15 test-media kernel: [ 115.972463] [<ffffffff819af1b1>] ? mutex_lock_nested+0x2b1/0x560 Jun 14 18:42:15 test-media kernel: [ 115.972467] [<ffffffffa038fdc5>] ? vb2_queue_release+0x25/0x40 [videobuf2_core] Jun 14 18:42:15 test-media kernel: [ 115.972469] [<ffffffffa039f1f6>] vb2_vmalloc_put_userptr+0x36/0x110 [videobuf2_vmalloc] Jun 14 18:42:15 test-media kernel: [ 115.972472] [<ffffffffa038b626>] __vb2_queue_free+0x146/0x5e0 [videobuf2_core] Jun 14 18:42:15 test-media kernel: [ 115.972475] [<ffffffffa038fdd3>] vb2_queue_release+0x33/0x40 [videobuf2_core] Jun 14 18:42:15 test-media kernel: [ 115.972478] [<ffffffffa038fe75>] _vb2_fop_release+0x95/0xb0 [videobuf2_core] Jun 14 18:42:15 test-media kernel: [ 115.972481] [<ffffffffa038feb9>] vb2_fop_release+0x29/0x50 [videobuf2_core] Jun 14 18:42:15 test-media kernel: [ 115.972485] [<ffffffffa03ad372>] vivid_fop_release+0x92/0x230 [vivid] Jun 14 18:42:15 test-media kernel: [ 115.972491] [<ffffffffa0358460>] v4l2_release+0x30/0x80 [videodev] Jun 14 18:42:15 test-media kernel: [ 115.972496] [<ffffffff811a51d5>] __fput+0xe5/0x200 Jun 14 18:42:15 test-media kernel: [ 115.972498] [<ffffffff811a5339>] ____fput+0x9/0x10 Jun 14 18:42:15 test-media kernel: [ 115.972501] [<ffffffff810a9fa4>] task_work_run+0xc4/0xf0 Jun 14 18:42:15 test-media kernel: [ 115.972504] [<ffffffff8108c670>] do_exit+0x3a0/0xaf0 Jun 14 18:42:15 test-media kernel: [ 115.972507] [<ffffffff819b3a9b>] ? _raw_spin_unlock_irq+0x2b/0x60 Jun 14 18:42:15 test-media kernel: [ 115.972509] [<ffffffff8108e0ff>] do_group_exit+0x4f/0xe0 Jun 14 18:42:15 test-media kernel: [ 115.972511] [<ffffffff8109a170>] get_signal+0x200/0x8c0 Jun 14 18:42:15 test-media kernel: [ 115.972514] [<ffffffff819b14b5>] ? __mutex_unlock_slowpath+0xf5/0x240 Jun 14 18:42:15 test-media kernel: [ 115.972518] [<ffffffff81002593>] do_signal+0x23/0x820 Jun 14 18:42:15 test-media kernel: [ 115.972521] [<ffffffff819b1609>] ? mutex_unlock+0x9/0x10 Jun 14 18:42:15 test-media kernel: [ 115.972524] [<ffffffffa0358648>] ? v4l2_ioctl+0x78/0xf0 [videodev] Jun 14 18:42:15 test-media kernel: [ 115.972526] [<ffffffff819b4653>] ? int_very_careful+0x5/0x46 Jun 14 18:42:15 test-media kernel: [ 115.972529] [<ffffffff810d54bd>] ? trace_hardirqs_on_caller+0x15d/0x200 Jun 14 18:42:15 test-media kernel: [ 115.972531] [<ffffffff81002de0>] do_notify_resume+0x50/0x60 Jun 14 18:42:15 test-media kernel: [ 115.972533] [<ffffffff819b46a6>] int_signal+0x12/0x17 Jun 14 18:42:15 test-media kernel: [ 115.972534] Code: ca 81 31 c0 e8 7a e2 8c 00 e8 aa 1d 8d 00 0f 1f 44 00 00 31 db 48 81 c4 a8 00 00 00 89 d8 5b 41 5c 41 5d 41 5e 41 5f 5d c3 66 90 <49> 81 3e 40 4e 02 82 b8 00 00 00 00 44 0f 44 e0 41 83 ff 01 0f Jun 14 18:42:15 test-media kernel: [ 115.972567] RIP [<ffffffff810d5cd0>] __lock_acquire+0x2f0/0x2070 Jun 14 18:42:15 test-media kernel: [ 115.972569] RSP <ffff88021d16f9b8> Jun 14 18:42:15 test-media kernel: [ 115.972570] CR2: 0000000000000100 Jun 14 18:42:15 test-media kernel: [ 115.972573] ---[ end trace 25595c2b8560cb57 ]--- Jun 14 18:42:15 test-media kernel: [ 115.972575] Fixing recursive fault but reboot is needed! This can be reproduced by loading the vivid driver and running: v4l2-ctl --stream-user and pressing Ctrl-C. You may have to try a few times, but in my experience this BUG is triggered quite quickly. The second is a possible deadlock: Jun 14 18:44:07 test-media kernel: [ 49.376650] ====================================================== Jun 14 18:44:07 test-media kernel: [ 49.376651] [ INFO: possible circular locking dependency detected ] Jun 14 18:44:07 test-media kernel: [ 49.376653] 4.1.0-rc3-test-media #1190 Not tainted Jun 14 18:44:07 test-media kernel: [ 49.376654] ------------------------------------------------------- Jun 14 18:44:07 test-media kernel: [ 49.376655] v4l2-compliance/1468 is trying to acquire lock: Jun 14 18:44:07 test-media kernel: [ 49.376657] (&mm->mmap_sem){++++++}, at: [<ffffffffa03a81f6>] vb2_vmalloc_put_userptr+0x36/0x110 [videobuf2_vmalloc] Jun 14 18:44:07 test-media kernel: [ 49.376665] Jun 14 18:44:07 test-media kernel: [ 49.376665] but task is already holding lock: Jun 14 18:44:07 test-media kernel: [ 49.376666] (&q->mmap_lock){+.+...}, at: [<ffffffffa0398dc5>] vb2_queue_release+0x25/0x40 [videobuf2_core] Jun 14 18:44:07 test-media kernel: [ 49.376670] Jun 14 18:44:07 test-media kernel: [ 49.376670] which lock already depends on the new lock. Jun 14 18:44:07 test-media kernel: [ 49.376670] Jun 14 18:44:07 test-media kernel: [ 49.376671] Jun 14 18:44:07 test-media kernel: [ 49.376671] the existing dependency chain (in reverse order) is: Jun 14 18:44:07 test-media kernel: [ 49.376672] Jun 14 18:44:07 test-media kernel: [ 49.376672] -> #1 (&q->mmap_lock){+.+...}: Jun 14 18:44:07 test-media kernel: [ 49.376675] [<ffffffff810d852c>] lock_acquire+0x6c/0xa0 Jun 14 18:44:07 test-media kernel: [ 49.376682] [<ffffffff819aef5e>] mutex_lock_nested+0x5e/0x560 Jun 14 18:44:07 test-media kernel: [ 49.376689] [<ffffffffa03934a2>] vb2_mmap+0x232/0x350 [videobuf2_core] Jun 14 18:44:07 test-media kernel: [ 49.376691] [<ffffffffa0395a60>] vb2_fop_mmap+0x20/0x30 [videobuf2_core] Jun 14 18:44:07 test-media kernel: [ 49.376694] [<ffffffffa0361102>] v4l2_mmap+0x52/0x90 [videodev] Jun 14 18:44:07 test-media kernel: [ 49.376698] [<ffffffff81177e33>] mmap_region+0x3b3/0x5e0 Jun 14 18:44:07 test-media kernel: [ 49.376701] [<ffffffff81178377>] do_mmap_pgoff+0x317/0x400 Jun 14 18:44:07 test-media kernel: [ 49.376703] [<ffffffff81165320>] vm_mmap_pgoff+0x90/0xc0 Jun 14 18:44:07 test-media kernel: [ 49.376708] [<ffffffff81176867>] SyS_mmap_pgoff+0x1d7/0x280 Jun 14 18:44:07 test-media kernel: [ 49.376709] [<ffffffff81007f8d>] SyS_mmap+0x1d/0x20 Jun 14 18:44:07 test-media kernel: [ 49.376714] [<ffffffff819b44ae>] system_call_fastpath+0x12/0x76 Jun 14 18:44:07 test-media kernel: [ 49.376716] Jun 14 18:44:07 test-media kernel: [ 49.376716] -> #0 (&mm->mmap_sem){++++++}: Jun 14 18:44:07 test-media kernel: [ 49.376718] [<ffffffff810d79b3>] __lock_acquire+0x1fd3/0x2070 Jun 14 18:44:07 test-media kernel: [ 49.376720] [<ffffffff810d852c>] lock_acquire+0x6c/0xa0 Jun 14 18:44:07 test-media kernel: [ 49.376721] [<ffffffff819b1a92>] down_read+0x42/0x60 Jun 14 18:44:07 test-media kernel: [ 49.376723] [<ffffffffa03a81f6>] vb2_vmalloc_put_userptr+0x36/0x110 [videobuf2_vmalloc] Jun 14 18:44:07 test-media kernel: [ 49.376725] [<ffffffffa0394626>] __vb2_queue_free+0x146/0x5e0 [videobuf2_core] Jun 14 18:44:07 test-media kernel: [ 49.376727] [<ffffffffa0398dd3>] vb2_queue_release+0x33/0x40 [videobuf2_core] Jun 14 18:44:07 test-media kernel: [ 49.376729] [<ffffffffa0398e75>] _vb2_fop_release+0x95/0xb0 [videobuf2_core] Jun 14 18:44:07 test-media kernel: [ 49.376731] [<ffffffffa0398eb9>] vb2_fop_release+0x29/0x50 [videobuf2_core] Jun 14 18:44:07 test-media kernel: [ 49.376733] [<ffffffffa03b6372>] vivid_fop_release+0x92/0x230 [vivid] Jun 14 18:44:07 test-media kernel: [ 49.376737] [<ffffffffa0361460>] v4l2_release+0x30/0x80 [videodev] Jun 14 18:44:07 test-media kernel: [ 49.376739] [<ffffffff811a51d5>] __fput+0xe5/0x200 Jun 14 18:44:07 test-media kernel: [ 49.376744] [<ffffffff811a5339>] ____fput+0x9/0x10 Jun 14 18:44:07 test-media kernel: [ 49.376746] [<ffffffff810a9fa4>] task_work_run+0xc4/0xf0 Jun 14 18:44:07 test-media kernel: [ 49.376749] [<ffffffff81002dd1>] do_notify_resume+0x41/0x60 Jun 14 18:44:07 test-media kernel: [ 49.376752] [<ffffffff819b46a6>] int_signal+0x12/0x17 Jun 14 18:44:07 test-media kernel: [ 49.376754] Jun 14 18:44:07 test-media kernel: [ 49.376754] other info that might help us debug this: Jun 14 18:44:07 test-media kernel: [ 49.376754] Jun 14 18:44:07 test-media kernel: [ 49.376755] Possible unsafe locking scenario: Jun 14 18:44:07 test-media kernel: [ 49.376755] Jun 14 18:44:07 test-media kernel: [ 49.376756] CPU0 CPU1 Jun 14 18:44:07 test-media kernel: [ 49.376757] ---- ---- Jun 14 18:44:07 test-media kernel: [ 49.376758] lock(&q->mmap_lock); Jun 14 18:44:07 test-media kernel: [ 49.376759] lock(&mm->mmap_sem); Jun 14 18:44:07 test-media kernel: [ 49.376760] lock(&q->mmap_lock); Jun 14 18:44:07 test-media kernel: [ 49.376761] lock(&mm->mmap_sem); Jun 14 18:44:07 test-media kernel: [ 49.376763] Jun 14 18:44:07 test-media kernel: [ 49.376763] *** DEADLOCK *** Jun 14 18:44:07 test-media kernel: [ 49.376763] Jun 14 18:44:07 test-media kernel: [ 49.376764] 2 locks held by v4l2-compliance/1468: Jun 14 18:44:07 test-media kernel: [ 49.376765] #0: (&dev->mutex#3){+.+.+.}, at: [<ffffffffa0398e0a>] _vb2_fop_release+0x2a/0xb0 [videobuf2_core] Jun 14 18:44:07 test-media kernel: [ 49.376770] #1: (&q->mmap_lock){+.+...}, at: [<ffffffffa0398dc5>] vb2_queue_release+0x25/0x40 [videobuf2_core] Jun 14 18:44:07 test-media kernel: [ 49.376773] Jun 14 18:44:07 test-media kernel: [ 49.376773] stack backtrace: Jun 14 18:44:07 test-media kernel: [ 49.376776] CPU: 2 PID: 1468 Comm: v4l2-compliance Not tainted 4.1.0-rc3-test-media #1190 Jun 14 18:44:07 test-media kernel: [ 49.376777] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/20/2014 Jun 14 18:44:07 test-media kernel: [ 49.376779] ffffffff8279e0b0 ffff88021d6f7ba8 ffffffff819a7aac 0000000000000011 Jun 14 18:44:07 test-media kernel: [ 49.376781] ffffffff8279e0b0 ffff88021d6f7bf8 ffffffff819a3964 ffff88021d6f7bd8 Jun 14 18:44:07 test-media kernel: [ 49.376783] ffff8800ac8aa100 0000000000000002 ffff8800ac8aa9a0 0000000000000002 Jun 14 18:44:07 test-media kernel: [ 49.376785] Call Trace: Jun 14 18:44:07 test-media kernel: [ 49.376788] [<ffffffff819a7aac>] dump_stack+0x4f/0x7b Jun 14 18:44:07 test-media kernel: [ 49.376792] [<ffffffff819a3964>] print_circular_bug+0x20f/0x251 Jun 14 18:44:07 test-media kernel: [ 49.376793] [<ffffffff810d79b3>] __lock_acquire+0x1fd3/0x2070 Jun 14 18:44:07 test-media kernel: [ 49.376795] [<ffffffff810d6543>] ? __lock_acquire+0xb63/0x2070 Jun 14 18:44:07 test-media kernel: [ 49.376797] [<ffffffff810d37a8>] ? __lock_is_held+0x58/0x80 Jun 14 18:44:07 test-media kernel: [ 49.376798] [<ffffffff810d852c>] lock_acquire+0x6c/0xa0 Jun 14 18:44:07 test-media kernel: [ 49.376800] [<ffffffffa03a81f6>] ? vb2_vmalloc_put_userptr+0x36/0x110 [videobuf2_vmalloc] Jun 14 18:44:07 test-media kernel: [ 49.376802] [<ffffffff819b1a92>] down_read+0x42/0x60 Jun 14 18:44:07 test-media kernel: [ 49.376803] [<ffffffffa03a81f6>] ? vb2_vmalloc_put_userptr+0x36/0x110 [videobuf2_vmalloc] Jun 14 18:44:07 test-media kernel: [ 49.376805] [<ffffffff819af1b1>] ? mutex_lock_nested+0x2b1/0x560 Jun 14 18:44:07 test-media kernel: [ 49.376807] [<ffffffffa0398dc5>] ? vb2_queue_release+0x25/0x40 [videobuf2_core] Jun 14 18:44:07 test-media kernel: [ 49.376808] [<ffffffffa03a81f6>] vb2_vmalloc_put_userptr+0x36/0x110 [videobuf2_vmalloc] Jun 14 18:44:07 test-media kernel: [ 49.376810] [<ffffffffa0398e0a>] ? _vb2_fop_release+0x2a/0xb0 [videobuf2_core] Jun 14 18:44:07 test-media kernel: [ 49.376812] [<ffffffffa0394626>] __vb2_queue_free+0x146/0x5e0 [videobuf2_core] Jun 14 18:44:07 test-media kernel: [ 49.376814] [<ffffffffa0398dd3>] vb2_queue_release+0x33/0x40 [videobuf2_core] Jun 14 18:44:07 test-media kernel: [ 49.376816] [<ffffffffa0398e75>] _vb2_fop_release+0x95/0xb0 [videobuf2_core] Jun 14 18:44:07 test-media kernel: [ 49.376818] [<ffffffffa0398eb9>] vb2_fop_release+0x29/0x50 [videobuf2_core] Jun 14 18:44:07 test-media kernel: [ 49.376820] [<ffffffffa03b6372>] vivid_fop_release+0x92/0x230 [vivid] Jun 14 18:44:07 test-media kernel: [ 49.376822] [<ffffffffa0361460>] v4l2_release+0x30/0x80 [videodev] Jun 14 18:44:07 test-media kernel: [ 49.376824] [<ffffffff811a51d5>] __fput+0xe5/0x200 Jun 14 18:44:07 test-media kernel: [ 49.376825] [<ffffffff819b4653>] ? int_very_careful+0x5/0x46 Jun 14 18:44:07 test-media kernel: [ 49.376827] [<ffffffff811a5339>] ____fput+0x9/0x10 Jun 14 18:44:07 test-media kernel: [ 49.376828] [<ffffffff810a9fa4>] task_work_run+0xc4/0xf0 Jun 14 18:44:07 test-media kernel: [ 49.376830] [<ffffffff81002dd1>] do_notify_resume+0x41/0x60 Jun 14 18:44:07 test-media kernel: [ 49.376832] [<ffffffff819b46a6>] int_signal+0x12/0x17 This can be triggered by loading the vivid module with the module option 'no_error_inj=1' and running 'v4l2-compliance -s5'. Again, it may take a few attempts to trigger this but for me it happens quite quickly. Without this patch I cannot reproduce these two issues. So reverting is the best solution for now. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Cc: Jan Kara <jack@suse.cz> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2015-06-18[media] mantis: cleanup a warningMauro Carvalho Chehab1-2/+2
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> drivers/media/pci/mantis/mantis_i2c.c: In function 'mantis_i2c_init': drivers/media/pci/mantis/mantis_i2c.c:222:15: warning: variable 'intmask' set but not used [-Wunused-but-set-variable] u32 intstat, intmask;
2015-06-18x86/mm/pat, drivers/media/ivtv: Use arch_phys_wc_add() and require PAT disabledLuis R. Rodriguez2-35/+26
We are burrying direct access to MTRR code support on x86 in order to take advantage of PAT. In the future, we also want to make the default behavior of ioremap_nocache() to use strong UC, at which point the use of mtrr_add() on those systems would make write-combining void. In order to help both enable us to later make strong UC default and in order to phase out direct MTRR access code, port the driver over to the arch_phys_wc_add() API and annotate that the device driver requires systems to boot with PAT disabled, with the 'nopat' kernel parameter. This is a workable compromise given that the hardware is really rare these days, and perhaps only some lost souls stuck with obsolete hardware are expected to be using this feature of the device driver. Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com> Signed-off-by: Borislav Petkov <bp@suse.de> Acked-by: Andy Walls <awalls@md.metrocast.net> Acked-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Antonino Daplas <adaplas@gmail.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Dave Airlie <airlied@redhat.com> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: Doug Ledford <dledford@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com> Cc: Juergen Gross <jgross@suse.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Roger Pau Monné <roger.pau@citrix.com> Cc: Stefan Bader <stefan.bader@canonical.com> Cc: Suresh Siddha <sbsiddha@gmail.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ville Syrjälä <syrjala@sci.fi> Cc: bhelgaas@google.com Cc: konrad.wilk@oracle.com Cc: linux-media@vger.kernel.org Cc: tomi.valkeinen@ti.com Cc: toshi.kani@hp.com Link: http://lkml.kernel.org/r/1434053994-2196-2-git-send-email-mcgrof@do-not-panic.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-06-17Kconfig: disable Media Controller for DVBMauro Carvalho Chehab1-0/+1
Since when we start discussions about the usage Media Controller for complex hardware, one thing become clear: the way it is, MC fails to map anything different than capture/output/m2m video-only streaming. The point is that MC has entities named as devnodes, but the only devnode used (before the DVB patches) is MEDIA_ENT_T_DEVNODE_V4L. Due to the way MC got implemented, however, this entity actually doesn't represent the devnode, but the hardware I/O engine that receives data via DMA. By coincidence, such DMA is associated with the V4L device node on webcam hardware, but this is not true even for other V4L2 devices. For example, on USB hardware, the DMA is done via the USB controller. The data passes though a in-kernel filter that strips off the URB headers. Other V4L2 devices like radio may not even have DMA. When it have, the DMA is done via ALSA, and not via the V4L devnode. In other words, MC is broken as a whole, but tagging it as BROKEN right now would do more harm than good. So, instead, let's mark, for now, the DVB part as broken and block all new changes to MC while we fix this mess, whith we hopefully will do for the next Kernel version. Requested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2015-06-15v4l: async: Add a pointer to of_node to struct v4l2_subdev, match itSakari Ailus1-12/+27
V4L2 async sub-devices are currently matched (OF case) based on the struct device_node pointer in struct device. LED devices may have more than one LED, and in that case the OF node to match is not directly the device's node, but a LED's node. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2015-06-11[media] bdisp-debug: don't try to divide by s64Mauro Carvalho Chehab1-11/+22
There are several warnings there, on some architectures, related to dividing a s32 by a s64 value: drivers/media/platform/sti/bdisp/bdisp-debug.c:594: warning: comparison of distinct pointer types lacks a cast drivers/media/platform/sti/bdisp/bdisp-debug.c:594: warning: right shift count >= width of type drivers/media/platform/sti/bdisp/bdisp-debug.c:594: warning: passing argument 1 of '__div64_32' from incompatible pointer type drivers/media/platform/sti/bdisp/bdisp-debug.c:595: warning: comparison of distinct pointer types lacks a cast drivers/media/platform/sti/bdisp/bdisp-debug.c:595: warning: right shift count >= width of type drivers/media/platform/sti/bdisp/bdisp-debug.c:595: warning: passing argument 1 of '__div64_32' from incompatible pointer type CC [M] drivers/media/tuners/mt2060.o drivers/media/platform/sti/bdisp/bdisp-debug.c:596: warning: comparison of distinct pointer types lacks a cast drivers/media/platform/sti/bdisp/bdisp-debug.c:596: warning: right shift count >= width of type drivers/media/platform/sti/bdisp/bdisp-debug.c:596: warning: passing argument 1 of '__div64_32' from incompatible pointer type drivers/media/platform/sti/bdisp/bdisp-debug.c:597: warning: comparison of distinct pointer types lacks a cast drivers/media/platform/sti/bdisp/bdisp-debug.c:597: warning: right shift count >= width of type drivers/media/platform/sti/bdisp/bdisp-debug.c:597: warning: passing argument 1 of '__div64_32' from incompatible pointer type That doesn't make much sense. What the driver is actually trying to do is to divide one second by a value. So, check the range before dividing. That warrants the right result and will remove the warnings on non-64 bits archs. Also fixes this warning: drivers/media/platform/sti/bdisp/bdisp-debug.c:588: warning: comparison of distinct pointer types lacks a cast by using div64_s64() instead of calling do_div() directly. Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2015-06-10[media] cx88: don't declare restart_video_queue if not usedMauro Carvalho Chehab1-1/+1
While compiled on alpha, got this error: drivers/media/pci/cx88/cx88-video.c:415:12: warning: 'restart_video_queue' defined but not used [-Wunused-function] Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2015-06-10[media] au0828: move dev->boards atribuition to happen earlierRafael Lourenço de Lima Chehab2-2/+2
The attribution of dev->boards occured too late, which would couse an OOPS in media controller registration. Signed-off-by: Rafael Lourenço de Lima Chehab <chehabrafael@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2015-06-10[media] lmedm04: implement dvb v5 statisticsMalcolm Priestley1-27/+77
Indroduce function lme2510_update_stats to update statistics directly from usb interrupt. Provide signal and snr wrap rounds for dvb v3 functions. Block and post bit are not available. When i2c_talk_onoff is on no statistics are available, with possible future hand over to the relevant frontend/tuner. Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2015-06-10[media] bdisp: remove unused varMauro Carvalho Chehab1-3/+0
Fix the following warning: drivers/media/platform/sti/bdisp/bdisp-v4l2.c: In function 'bdisp_register_device': drivers/media/platform/sti/bdisp/bdisp-v4l2.c:1024:26: warning: variable 'pdev' set but not used [-Wunused-but-set-variable] struct platform_device *pdev; Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2015-06-10[media] bdisp: remove needless checkFabien Dessenne1-2/+1
As reported by smatch: drivers/media/platform/sti/bdisp/bdisp-v4l2.c:947 bdisp_s_selection() warn: unsigned 'out.width' is never less than zero. drivers/media/platform/sti/bdisp/bdisp-v4l2.c:947 bdisp_s_selection() warn: unsigned 'out.height' is never less than zero. Indeed, width and height are unsigned. Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2015-06-10ts2020: fix compilation on i386Mauro Carvalho Chehab1-3/+4
drivers/built-in.o: In function `ts2020_read_signal_strength': ts2020.c:(.text+0x298ff94): undefined reference to `__divdi3' ts2020.c:(.text+0x298ffd4): undefined reference to `__divdi3' ts2020.c:(.text+0x298fffd): undefined reference to `__divdi3' Makefile:921: recipe for target 'vmlinux' failed Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2015-06-10[media] mantis: cleanup CodingStyle issues due to last commitMauro Carvalho Chehab5-32/+28
Commit a96762da0cfc('[media] mantis: add remote control support') introduced some new CodingStyle issues. Fix them. No functional changes. Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2015-06-10[media] mantis: add remote control supportJan Klötzke9-150/+166
The embedded UART is apparently used to receive decoded IR (RC5?) codes. Forward these scan codes to the RC framework and (where known) add corresponding mapping tables to translate them into regular keys. This patch has been tested on a TechniSat CableStar HD2. The mappings of other rc-maps were taken from Christoph Pinkl's patch (http://patchwork.linuxtv.org/patch/7217/) and the s2-liplianin repository. The major difference to Christoph's patch is a reworked interrupt handling of the UART because the RX interrupt is apparently level triggered and requires masking until the FIFO is read by the UART worker. Signed-off-by: Jan Klötzke <jan@kloetzke.net> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2015-06-10[media] rc/keymaps: add keytable for Twinhan DTV CAB CIJan Klötzke2-0/+99
This RC map was taken from Christoph Pinkl's patch (http://patchwork.linuxtv.org/patch/7217/). It is used solely by the respective mantis based card because the encoding is not known. Signed-off-by: Jan Klötzke <jan@kloetzke.net> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2015-06-10[media] rc/keymaps: add keytable for Terratec Cinergy S2 HDJan Klötzke2-0/+87
This RC map was taken from Christoph Pinkl's patch (http://patchwork.linuxtv.org/patch/7217/). It is used solely by the respective mantis based card because the encoding is not known. Signed-off-by: Jan Klötzke <jan@kloetzke.net> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2015-06-10[media] rc/keymaps: add keytable for Terratec Cinergy C PCIJan Klötzke2-0/+89
This RC map was taken from Christoph Pinkl's patch (http://patchwork.linuxtv.org/patch/7217/). It is used solely by the respective mantis based card because the encoding is not known. Signed-off-by: Jan Klötzke <jan@kloetzke.net> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2015-06-10[media] rc/keymaps: add RC keytable for TechniSat TS35Jan Klötzke2-0/+77
The TS35 remote is distributed with TechniSat CableStar HD2 cards (mantis chipset). The exact protocol type is unknown, making this rc map probably only usable by mantis cards. Signed-off-by: Jan Klötzke <jan@kloetzke.net> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2015-06-10[media] dvb-core: prevent some corruption the legacy ioctlDan Carpenter1-1/+7
Quite a few of the ->diseqc_send_master_cmd() implementations don't check cmd->msg_len so it can lead to memory corruption. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2015-06-10[media] saa7164: Improvements for I2C handling"Olli Salonen1-10/+1
This reverts commit ad90b6b0f10566d4a5546e27fe455ce3b5e6b6c7. This patch breaks I2C communication towards Si2168. After reverting and applying the other patch in this series the I2C communication is correct. Signed-off-by: Olli Salonen <olli.salonen@iki.fi> Reviewed-by: Antti Palosaari <crope@iki.fi> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2015-06-10[media] saa7164: change Si2168 reglen to 0 bitOlli Salonen1-2/+2
The i2c_reg_len for Si2168 should be 0 for correct I2C communication. Signed-off-by: Olli Salonen <olli.salonen@iki.fi> Reviewed-by: Antti Palosaari <crope@iki.fi> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2015-06-10[media] s5k5baf: Convert use of __constant_cpu_to_be16 to cpu_to_be16Vaishali Thakkar1-1/+1
In little endian cases, macro cpu_to_be16 unfolds to __swab16 which provides special case for constants. In big endian cases, __constant_cpu_to_be16 and cpu_to_be16 expand directly to the same expression. So, replace __constant_cpu_to_be16 with cpu_to_be16 with the goal of getting rid of the definition of __constant_cpu_to_be16 completely. The semantic patch that performs this transformation is as follows: @@expression x;@@ - __constant_cpu_to_be16(x) + cpu_to_be16(x) Signed-off-by: Vaishali Thakkar <vthakkar1994@gmail.com> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2015-06-10[media] lmedm04: Enable dont_poll for TS2020 tunerMalcolm Priestley1-0/+1
Following a change made to TS2020 tuner in patches ts2020: Provide DVBv5 API signal strength ts2020: Allow stats polling to be suppressed Polling on the driver must be suppressed because the demuxer is stopped by I2C messages. Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com> Signed-off-by: Antti Palosaari <crope@iki.fi> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2015-06-10[media] ts2020: Allow stats polling to be suppressedDavid Howells2-4/+17
Statistics polling can not be done by lmedm04 driver's implementation of M88RS2000/TS2020 because I2C messages stop the device's demuxer, so allow polling for statistics to be suppressed in the ts2020 driver by setting dont_poll in the ts2020_config struct. Reported-by: Malcolm Priestley <tvboxspy@gmail.com> Signed-off-by: David Howells <dhowells@redhat.com> cc: Malcolm Priestley <tvboxspy@gmail.com> Signed-off-by: Antti Palosaari <crope@iki.fi> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2015-06-10[media] ts2020: Copy loop_through from the config to the internal dataDavid Howells2-2/+3
Copy the loop_through setting from the ts2020_config struct to the internal ts2020_priv struct so that it can actually be used. Whilst we're at it, group the bitfields together in the same order in both structs so that the compiler has a good chance to copy them in one go. Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Antti Palosaari <crope@iki.fi> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2015-06-10[media] ts2020: Provide DVBv5 API signal strengthDavid Howells1-9/+53
Provide a DVBv5 API signal strength. This is in units of 0.001 dBm rather than a percentage. >From Antti Palosaari's testing with a signal generator, it appears that the gain calculated according to Montage's specification if negated is a reasonable representation of the signal strength of the generator. To this end: (1) Polled statistic gathering needed to be implemented in the TS2020 driver. This is done in the ts2020_stat_work() function. (2) The calculated gain is placed as the signal strength in the dtv_property_cache associated with the front end with the scale set to FE_SCALE_DECIBEL. (3) The DVBv3 format signal strength then needed to be calculated from the signal strength stored in the dtv_property_cache rather than accessing the value when ts2020_read_signal_strength() is called. Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Antti Palosaari <crope@iki.fi> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2015-06-10[media] TS2020: Calculate tuner gain correctlyDavid Howells6-18/+148
The TS2020 and TS2022 tuners take an input from the demodulator indicating the AGC setting on that component that is then used to influence the tuner's own gain. This should be taken into account when calculating the gain and signal strength. Further, the existing TS2020 driver miscalculates the signal strength as the result of its calculations can exceed the storage capacity of the 16-bit word used to return it to userspace. To this end: (1) Add a callback function (->get_agc_pwm()) in the ts2020_config struct that the tuner can call to get the AGC PWM value from the demodulator. (2) Modify the TS2020 driver to calculate the gain according to Montage's specification with the adjustment that we produce a negative value and scale it to 0.001dB units (which is what the DVBv5 API will require): (a) Callback to the demodulator to retrieve the AGC PWM value and then turn that into Vagc for incorporation in the calculations. If the callback is unset, assume a Vagc of 0. (b) Calculate the tuner gain from a combination of Vagc and the tuner's RF gain and baseband gain settings. (3) Turn this into a percentage signal strength as per Montage's specification for return to userspace with the DVBv3 API. (4) Provide a function in the M88DS3103 demodulator driver that can be used to get the AGC PWM value on behalf of the tuner. (5) The ts2020_config.get_agc_pwm function should be set by the code that stitches together the drivers for each card. For the DVBSky cards that use the M88DS3103 with the TS2020 or the TS2022, set the get_agc_pwm function to point to m88ds3103_get_agc_pwm. I have tested this with a DVBSky S952 card which has an M88DS3103 and a TS2022. Thanks to Montage for providing access to information about the workings of these parts. Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Antti Palosaari <crope@iki.fi> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2015-06-10[media] em28xx: PCTV 461e use I2C client for demod and SECAntti Palosaari1-53/+83
Use I2C client binding for demod and SEC. Signed-off-by: Antti Palosaari <crope@iki.fi> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2015-06-10[media] m88ds3103: use regmap for I2C register accessAntti Palosaari3-290/+145
Use regmap for I2C register access. Remove own I2C repeated mutex as it should not be needed. I2C adapter lock is already taken when I2C mux adapter is called, no need for double locking. Signed-off-by: Antti Palosaari <crope@iki.fi> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2015-06-10[media] m88ds3103: rename variables and correct loggingAntti Palosaari4-280/+267
Rename driver state from priv to dev. Use I2C client for correct logging. Use adapter and address from I2C client structure where needed. Signed-off-by: Antti Palosaari <crope@iki.fi> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2015-06-10[media] ts2020: Add a comment about lifetime of on-stack pdata in ↵David Howells1-0/+2
ts2020_attach() ts2020_attach() allocates a variable pdata on the stack and then passes a pointer to it to i2c_new_device() which stashes the pointer in persistent structures. Add a comment to the effect that this isn't actually an error because the contents of the variable are only used in ts2020_probe() and this is only called ts2020_attach()'s stack frame exists. Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Antti Palosaari <crope@iki.fi> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>