aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
*-. Merge branches 'd3cold', 'bugzilla-37412' and 'bugzilla-38152' into releaseLen Brown2011-07-144-18/+32
|\ \
| | * ACPI: Fix lockdep false positives in acpi_power_off()Rafael J. Wysocki2011-07-133-17/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | All ACPICA locks are allocated by the same function, acpi_os_create_lock(), with the help of a local variable called "lock". Thus, when lockdep is enabled, it uses "lock" as the name of all those locks and regards them as instances of the same lock, which causes it to report possible locking problems with them when there aren't any. To work around this problem, define acpi_os_create_lock() as a macro and make it pass its argument to spin_lock_init(), so that lockdep uses it as the name of the new lock. Define this macron in a Linux-specific file, to minimize the resulting modifications of the OS-independent ACPICA parts. This change is based on an earlier patch from Andrea Righi and it addresses a regression from 2.6.39 tracked as https://bugzilla.kernel.org/show_bug.cgi?id=38152 Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Reported-and-tested-by: Borislav Petkov <bp@alien8.de> Tested-by: Andrea Righi <andrea@betterlinux.com> Reviewed-by: Florian Mickler <florian@mickler.org> Signed-off-by: Len Brown <len.brown@intel.com>
| * | ACPI, APEI, HEST, Detect duplicated hardware error source IDHuang Ying2011-07-131-1/+11
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | The firmware on some machine will report duplicated hardware error source ID in HEST. This is considered a firmware bug. To provide better warning message, this patch adds duplicated hardware error source ID detecting and corresponding printk. This patch fixes #37412 on kernel bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=37412 Reported-by: marconifabio@ubuntu-it.org Signed-off-by: Huang Ying <ying.huang@intel.com> Tested-by: Mathias <janedo.spam@gmail.com> Signed-off-by: Len Brown <len.brown@intel.com>
* | ACPI: Fixes device power states array overflowLin Ming2011-07-131-1/+1
|/ | | | | | | | | | | | Commit 28c2103 added new state ACPI_STATE_D3_COLD, so the device power states array must be expanded by one also. v2: Use ACPI_D_STATE_COUNT instead of number 5 for the array size. Reported-by: Dan Carpenter <error27@gmail.com> Suggested-by: Oldřich Jedlička <oldium.pro@seznam.cz> Signed-off-by: Lin Ming <ming.m.lin@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
* Merge branch 'merge' of ↵Linus Torvalds2011-07-124-14/+22
|\ | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc * 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc: powerpc/mm: Fix memory_block_size_bytes() for non-pseries mm: Move definition of MIN_MEMORY_BLOCK_SIZE to a header
| * powerpc/mm: Fix memory_block_size_bytes() for non-pseriesBenjamin Herrenschmidt2011-07-121-11/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Just compiling pseries in the kernel causes it to override memory_block_size_bytes() regardless of what is the runtime platform. This cleans up the implementation of that function, fixing a bug or two while at it, so that it's harmless (and potentially useful) for other platforms. Without this, bugs in that code would trigger a WARN_ON() in drivers/base/memory.c when booting some different platforms. If/when we have another platform supporting memory hotplug we might want to either move that out to a generic place or make it a ppc_md. callback. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
| * mm: Move definition of MIN_MEMORY_BLOCK_SIZE to a headerBenjamin Herrenschmidt2011-07-123-3/+3
| | | | | | | | | | | | | | | | | | The macro MIN_MEMORY_BLOCK_SIZE is currently defined twice in two .c files, and I need it in a third one to fix a powerpc bug, so let's first move it into a header Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Acked-by: Ingo Molnar <mingo@elte.hu>
* | Merge branch 'fixes' of ↵Linus Torvalds2011-07-1212-35/+52
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/arm/linux-arm-soc * 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/linux-arm-soc: pcmcia: pxa2xx/vpac270: free gpios on exist rather than requesting ARM: pxa/raumfeld: fix device name for codec ak4104 ARM: pxa/raumfeld: display initialisation fixes ARM: pxa/raumfeld: adapt to upcoming hardware change ARM: pxa: fix gpio_to_chip() clash with gpiolib namespace genirq: replace irq_gc_ack() with {set,clr}_bit variants (fwd) arm: mach-vt8500: add forgotten irq_data conversion ARM: pxa168: correct nand pmu setting ARM: pxa910: correct nand pmu setting ARM: pxa: fix PGSR register address calculation
| * \ Merge branch 'fix' of ↵Arnd Bergmann2011-07-113-24/+26
| |\ \ | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/ycmiao/pxa-linux-2.6 into fixes
| | * | pcmcia: pxa2xx/vpac270: free gpios on exist rather than requestingJonathan Cameron2011-07-111-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk> Acked-by: Marek Vasut <marek.vasut@gmail.com> Signed-off-by: Eric Miao <eric.y.miao@gmail.com>
| | * | ARM: pxa/raumfeld: fix device name for codec ak4104Daniel Mack2011-07-111-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In commit f0fba2ad (ASoC: multi-component - ASoC Multi-Component Support), the name of the ak4104 codec driver was changed without amending the platform code which uses it as well. Signed-off-by: Daniel Mack <zonque@gmail.com> Signed-off-by: Eric Miao <eric.y.miao@gmail.com>
| | * | ARM: pxa/raumfeld: display initialisation fixesSven Neumann2011-07-111-14/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The display requires some milliseconds between GPIO_TFT_VA_EN and GPIO_DISPLAY_ENABLE. Reorder initialisation to comply with the display spec. Also tune timings for better compliance with the spec. Signed-off-by: Sven Neumann <s.neumann@raumfeld.com> Acked-by: Daniel Mack <zonque@gmail.com> Signed-off-by: Eric Miao <eric.y.miao@gmail.com>
| | * | ARM: pxa/raumfeld: adapt to upcoming hardware changeSven Neumann2011-07-111-5/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The backlight control is going to change back to PWM in the upcoming Raumfeld Controller hardware revision. Signed-off-by: Sven Neumann <s.neumann@raumfeld.com> Acked-by: Daniel Mack <zonque@gmail.com> Signed-off-by: Eric Miao <eric.y.miao@gmail.com>
| | * | ARM: pxa: fix gpio_to_chip() clash with gpiolib namespaceLinus Walleij2011-07-111-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The PXA platform code has a static inline helper called gpio_to_chip which clashes with the gpiolib namespace if we try to expose the function with the same name from gpiolib, and it's still confusing even if we don't do that. So rename it to gpio_to_pxachip(). Reported-by: H Hartley Sweeten <hartleys@visionengravers.com> Cc: Eric Miao <eric.miao@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Eric Miao <eric.y.miao@gmail.com>
| * | | genirq: replace irq_gc_ack() with {set,clr}_bit variants (fwd)Simon Guinot2011-07-076-7/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes a regression introduced by e59347a "arm: orion: Use generic irq chip". Depending on the device, interrupts acknowledgement is done by setting or by clearing a dedicated register. Replace irq_gc_ack() with some {set,clr}_bit variants allows to handle both cases. Note that this patch affects the following SoCs: Davinci, Samsung and Orion. Except for this last, the change is minor: irq_gc_ack() is just renamed into irq_gc_ack_set_bit(). For the Orion SoCs, the edge GPIO interrupts support is currently broken. irq_gc_ack() try to acknowledge a such interrupt by setting the corresponding cause register bit. The Orion GPIO device expect the opposite. To fix this issue, the irq_gc_ack_clr_bit() variant is used. Tested on Network Space v2. Reported-by: Joey Oravec <joravec@drewtech.com> Signed-off-by: Simon Guinot <sguinot@lacie.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
| * | | arm: mach-vt8500: add forgotten irq_data conversionWolfram Sang2011-07-071-9/+12
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This platform has not been converted to 'struct irq_data' when the big pile was done. It fails to compile nowadays, because the compatibility code has gone. CC arch/arm/mach-vt8500/irq.o arch/arm/mach-vt8500/irq.c:118:2: error: unknown field 'ack' specified in initializer arch/arm/mach-vt8500/irq.c:118:2: warning: initialization from incompatible pointer type arch/arm/mach-vt8500/irq.c:119:2: error: unknown field 'mask' specified in initializer arch/arm/mach-vt8500/irq.c:119:2: warning: initialization from incompatible pointer type arch/arm/mach-vt8500/irq.c:120:2: error: unknown field 'unmask' specified in initializer arch/arm/mach-vt8500/irq.c:120:2: warning: initialization from incompatible pointer type arch/arm/mach-vt8500/irq.c:121:2: error: unknown field 'set_type' specified in initializer arch/arm/mach-vt8500/irq.c:121:2: warning: initialization from incompatible pointer type make[1]: *** [arch/arm/mach-vt8500/irq.o] Error 1 Add the missing conversion. Tested on a JayPC-Tablet. Signed-off-by: Wolfram Sang <w.sang@pengutronix.de> Acked-by: Alexey Charkov <alchark@gmail.com> Cc: Russell King <rmk+kernel@arm.linux.org.uk> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
| * | ARM: pxa168: correct nand pmu settingLei Wen2011-07-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The original pair of <0x01db, 208000000> is invalid. Correct it to the valid value. The 6th bit of the NFC APMU register indicates NFC works whether at 156Mhz or 78Mhz. So 0x19b indicates NFC works at 156Mhz, and 0x1db indicates it works at 78Mhz. Signed-off-by: Lei Wen <leiwen@marvell.com> Cc: stable@kernel.org Signed-off-by: Eric Miao <eric.y.miao@gmail.com>
| * | ARM: pxa910: correct nand pmu settingLei Wen2011-07-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | The original pair of <0x01db, 208000000> is invalid. Correct to the valid value. Signed-off-by: Lei Wen <leiwen@marvell.com> Cc: stable@kernel.org Signed-off-by: Eric Miao <eric.y.miao@gmail.com>
| * | ARM: pxa: fix PGSR register address calculationPaul Parsons2011-07-061-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The file mfp-pxa2xx.c defines a macro, PGSR(), which translates a gpio bank number to a PGSR register address. The function pxa2xx_mfp_suspend() erroneously passed in a gpio number instead of a gpio bank number. Signed-off-by: Paul Parsons <lost.distance@yahoo.com> Cc: stable@kernel.org Signed-off-by: Eric Miao <eric.y.miao@gmail.com>
* | | Merge branch 'drm-intel-fixes' of ↵Linus Torvalds2011-07-124-32/+105
|\ \ \ | |_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/keithp/linux-2.6 * 'drm-intel-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/keithp/linux-2.6: drm/i915/ringbuffer: Idling requires waiting for the ring to be empty Revert "drm/i915: enable rc6 by default" drm/i915: Clean up i915_driver_load failure path drm/i915: Enable GPU reset on Ivybridge. drm/i915/dp: manage sink power state if possible drm/i915/dp: consolidate AUX retry code drm/i915/dp: remove DPMS mode tracking from DP drm/i915/dp: try to read receiver capabilities 3 times when detecting drm/i915/dp: read more receiver capability bits on hotplug drm/i915/dp: use DP DPCD defines when looking at DPCD values drm/i915/dp: retry link status read 3 times on failure
| * | drm/i915/ringbuffer: Idling requires waiting for the ring to be emptyChris Wilson2011-07-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ...which is measured by the size and not the amount of space remaining. Waiting upon size-8, did one of two things. In the common case with more than 8 bytes available to write into the ring, it would return immediately. Otherwise, it would timeout given the impossible condition of waiting for more space than is available in the ring, leading to warnings such as: [drm:intel_cleanup_ring_buffer] *ERROR* failed to quiesce render ring whilst cleaning up: -16 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Eric Anholt <eric@anholt.net> Signed-off-by: Keith Packard <keithp@keithp.com>
| * | Revert "drm/i915: enable rc6 by default"Keith Packard2011-07-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit a51f7a66fb5e4af5ec4286baef940d06594b59d2. We still have a few Ironlake and Sandybridge machines which fail when RC6 is enabled. Better luck next release? Signed-off-by: Keith Packard <keithp@keithp.com>
| * | drm/i915: Clean up i915_driver_load failure pathKeith Packard2011-07-121-3/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | i915_driver_load adds a write-combining MTRR region for the GTT aperture to improve memory speeds through the aperture. If i915_driver_load fails after this, it would not have cleaned up the MTRR. This shouldn't cause any problems, except for consuming an MTRR register. Still, it's best to clean up completely in the failure path, which is easily done by calling mtrr_del if the mtrr was successfully allocated. i915_driver_load calls i915_gem_load which register i915_gem_inactive_shrink. If i915_driver_load fails after calling i915_gem_load, the shrinker will be left registered. When called, it will access freed memory and crash. The fix is to unregister the shrinker in the failure path using code duplicated from i915_driver_unload. i915_driver_load also has some incorrect gotos in the error cleanup paths: * After failing to initialize the GTT (which cannot happen, btw, intel_gtt_get returns a fixed (non-NULL) value), it tries to free the uninitialized WC IO mapping. Fixed this by changing the target from out_iomapfree to out_rmmap Signed-off-by: Keith Packard <keithp@keithp.com> Tested-by: Lin Ming <ming.m.lin@intel.com>
| * | drm/i915: Enable GPU reset on Ivybridge.Kenneth Graunke2011-07-071-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | According to the hardware documentation, GDRST is exactly the same as on Sandybridge. So simply enable the existing code. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Signed-off-by: Keith Packard <keithp@keithp.com>
| * | drm/i915/dp: manage sink power state if possibleJesse Barnes2011-07-071-0/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On sinks with a DPCD rev of 1.1 or greater, we can send sink power management commands to address 0x600 per section 5.1.5 of the DisplayPort 1.1a spec. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Keith Packard <keithp@keithp.com>
| * | drm/i915/dp: consolidate AUX retry codeJesse Barnes2011-07-071-21/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When checking link status during a hot plug event or detecting sink presence, we need to retry 3 times per the spec (section 9.1 of the 1.1a DisplayPort spec). Consolidate the retry code into a native_aux_read_retry function for use by get_link_status and _detect. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Keith Packard <keithp@keithp.com>
| * | drm/i915/dp: remove DPMS mode tracking from DPJesse Barnes2011-07-071-5/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We currently use this when a hot plug event is received, only checking the link status and re-training if we had previously configured a link. However if we want to preserve the DP configuration across both hot plug and DPMS events (which we do for userspace apps that don't respond to hot plug uevents), we need to unconditionally check the link and try to bring it up on hot plug. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Keith Packard <keithp@keithp.com>
| * | drm/i915/dp: try to read receiver capabilities 3 times when detectingJesse Barnes2011-07-071-5/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If ->detect is called too soon after a hot plug event, the sink may not be ready yet. So try up to 3 times with 1ms sleeps in between tries to get the data (spec dictates that receivers must be ready to respond within 1ms and that sources should try 3 times). See section 9.1 of the 1.1a DisplayPort spec. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Keith Packard <keithp@keithp.com>
| * | drm/i915/dp: read more receiver capability bits on hotplugJesse Barnes2011-07-071-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | When a hotplug event is received, we need to check the receiver cap bits in case they've changed (as they might with a hub or chain config). Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Keith Packard <keithp@keithp.com>
| * | drm/i915/dp: use DP DPCD defines when looking at DPCD valuesJesse Barnes2011-07-071-8/+10
| | | | | | | | | | | | | | | | | | | | | | | | Makes it easier to search for DP related constants. Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Keith Packard <keithp@keithp.com>
| * | drm/i915/dp: retry link status read 3 times on failureJesse Barnes2011-07-071-7/+13
| |/ | | | | | | | | | | | | | | | | | | | | | | Especially after a hotplug or power status change, the sink may not reply immediately to a link status query. So retry 3 times per the spec to really make sure nothing is there. See section 9.1 of the 1.1a DisplayPort spec. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Keith Packard <keithp@keithp.com>
* | Linux 3.0-rc7Linus Torvalds2011-07-111-1/+1
| |
* | Documentation/Changes: remove some really obsolete textLinus Torvalds2011-07-111-25/+18
| | | | | | | | | | | | | | | | | | | | | | | | That file harkens back to the days of the big 2.4 -> 2.6 version jump, and was based even then on older versions. Some of it is just obsolete, and Jesper Juhl points out that it talks about kernel versions 2.6 and should be updated to 3.0. Remove some obsolete text, and re-phrase some other to not be 2.6-specific. Reported-by: Jesper Juhl <jj@chaosbits.net> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* | Merge branch 'v4l_for_linus' of ↵Linus Torvalds2011-07-119-139/+174
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6 * 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6: [media] msp3400: fill in v4l2_tuner based on vt->type field [media] tuner-core.c: don't change type field in g_tuner or g_frequency [media] cx18/ivtv: fix g_tuner support [media] tuner-core: power up tuner when called with s_power(1) [media] v4l2-ioctl.c: check for valid tuner type in S_HW_FREQ_SEEK [media] tuner-core: simplify the standard fixup [media] tuner-core/v4l2-subdev: document that the type field has to be filled in [media] v4l2-subdev.h: remove unused s_mode tuner op [media] feature-removal-schedule: change in how radio device nodes are handled [media] bttv: fix s_tuner for radio [media] pvrusb2: fix g/s_tuner support [media] v4l2-ioctl.c: prefill tuner type for g_frequency and g/s_tuner [media] tuner-core: fix tuner_resume: use t->mode instead of t->type [media] tuner-core: fix s_std and s_tuner
| * | [media] msp3400: fill in v4l2_tuner based on vt->type fieldHans Verkuil2011-07-071-5/+7
| | | | | | | | | | | | | | | | | | | | | | | | The vt->type field determines how the msp3400 should fill in the tuner data, not whether the msp3400 is in radio mode or not. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| * | [media] tuner-core.c: don't change type field in g_tuner or g_frequencyHans Verkuil2011-07-071-19/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The tuner core should not silently change the type field in g_tuner and g_frequency. If the tuner is in a different mode than the one that was requested, then just fill in what you can and don't attempt to read afc, signal or rxsubchans values. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| * | [media] cx18/ivtv: fix g_tuner supportHans Verkuil2011-07-072-12/+4
| | | | | | | | | | | | | | | | | | | | | | | | The driver shouldn't override vt->type, and the tuner name should be based on vt->type as well. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| * | [media] tuner-core: power up tuner when called with s_power(1)Hans Verkuil2011-07-071-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Drivers must be able to rely on s_power to power up subdevices. Note that at this moment no driver attempts to power up tuners. This probably isn't surprising since s_power(1) was never implemented in tuner-core.c until now. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| * | [media] v4l2-ioctl.c: check for valid tuner type in S_HW_FREQ_SEEKHans Verkuil2011-07-071-3/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | Prohibit attempts to change the tuner to a type that is different from the device node the ioctl is called from. I.e. the type must be RADIO for a radio node and ANALOG_TV for a video/vbi node. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| * | [media] tuner-core: simplify the standard fixupHans Verkuil2011-07-071-65/+28
| | | | | | | | | | | | | | | | | | | | | | | | Get rid of a number of unnecessary tuner_dbg messages by simplifying the std fixup function. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| * | [media] tuner-core/v4l2-subdev: document that the type field has to be filled inHans Verkuil2011-07-072-0/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The tuner ops g_frequency, g_tuner and s_tuner require that the tuner type field is filled in. Document this. The tuner-core doc is based on a patch from Mauro Carvalho Chehab <mchehab@redhat.com>. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| * | [media] v4l2-subdev.h: remove unused s_mode tuner opHans Verkuil2011-07-071-4/+1
| | | | | | | | | | | | | | | | | | | | | s_mode is no longer used, so remove it. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| * | [media] feature-removal-schedule: change in how radio device nodes are handledHans Verkuil2011-07-071-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Radio devices have weird side-effects when used with combined TV/radio tuners and the V4L2 spec is ambiguous on how it should work. This results in inconsistent driver behavior which makes life hard for everyone. Be more strict in when and how the switch between radio and tv mode takes place and make sure all drivers behave the same. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| * | [media] bttv: fix s_tuner for radioHans Verkuil2011-07-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix typo: g_tuner should have been s_tuner. Tested with a bttv card. Cc: stable@kernel.org Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| * | [media] pvrusb2: fix g/s_tuner supportHans Verkuil2011-07-071-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The tuner-core subdev requires that the type field of v4l2_tuner is filled in correctly. This is done in v4l2-ioctl.c, but pvrusb2 doesn't use that yet, so we have to do it manually based on whether the current input is radio or not. Tested with my pvrusb2. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Acked-by: Mike Isely <isely@pobox.com> Cc: stable@kernel.org Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| * | [media] v4l2-ioctl.c: prefill tuner type for g_frequency and g/s_tunerHans Verkuil2011-07-071-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The subdevs are supposed to receive a valid tuner type for the g_frequency and g/s_tuner subdev ops. Some drivers do this, others don't. So prefill this in v4l2-ioctl.c based on whether the device node from which this is called is a radio node or not. The spec does not require applications to fill in the type, and if they leave it at 0 then the 'check_mode' call in tuner-core.c will return an error and the ioctl does nothing. Cc: stable@kernel.org Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| * | [media] tuner-core: fix tuner_resume: use t->mode instead of t->typeHans Verkuil2011-07-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | set_mode is called with t->type, which is the tuner type. Instead, use t->mode which is the actual tuner mode (i.e. radio vs tv). Cc: stable@kernel.org Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| * | [media] tuner-core: fix s_std and s_tunerHans Verkuil2011-07-071-28/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Both s_std and s_tuner are broken because set_mode_freq is called before the new std (for s_std) and audmode (for s_tuner) are set. This patch splits set_mode_freq in a set_mode and a set_freq and in s_std/s_tuner first calls set_mode, and if that returns 0 (i.e. the mode is supported) then they set t->std/t->audmode and call set_freq. This fixes a bug where changing std or audmode would actually change it to the previous value. Discovered while testing analog TV standards for cx18 with a tda18271 tuner. Cc: stable@kernel.org Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* | | Merge branch 'pm-fixes' of ↵Linus Torvalds2011-07-111-0/+8
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/rafael/suspend-2.6 * 'pm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/suspend-2.6: PM: Reintroduce dropped call to check_wakeup_irqs
| * | | PM: Reintroduce dropped call to check_wakeup_irqsColin Cross2011-07-111-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Patch 2e711c04dbbf7a7732a3f7073b1fc285d12b369d (PM: Remove sysdev suspend, resume and shutdown operations) deleted sysdev_suspend(), which was being relied on to call check_wakeup_irqs() in suspend. If check_wakeup_irqs() is not called, wake interrupts that are pending when suspend is entered may be lost. It also breaks IRQCHIP_MASK_ON_SUSPEND, which is handled in check_wakeup_irqs(). This patch adds a call to check_wakeup_irqs() in syscore_suspend(), similar to what was deleted in sysdev_suspend(). Signed-off-by: Colin Cross <ccross@android.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>