summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* [CPUFREQ] exynos4210: make needlessly global symbols staticAxel Lin2011-07-131-3/+3
| | | | | | | | | | | | | The following symbols are needlessly defined global: exynos4_verify_speed exynos4_getspeed exynos4_set_clkdiv Make them static. Signed-off-by: Axel Lin <axel.lin@gmail.com> Acked-by: Kukjin Kim <kgene.kim@samsung.com> Signed-off-by: Dave Jones <davej@redhat.com>
* [CPUFREQ] S3C6410: Add some lower frequencies for 800MHz base clock operationMark Brown2011-07-131-0/+2
| | | | | | | | | | | | | | By extension from the 667MHz based clocks currently supported add 100MHz and 200MHz operating points. Due to a lack of documentation these have not been confirmed as supported but by extension from the existing frequencies they should be OK, and I've given them quite a bit of runtime testing. The major risk is synchronization with the non-ARM clocks but as we can't currently scale the ARM PLL the risk should be relatively low. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Kukjin Kim <kgene.kim@samsung.com> Signed-off-by: Dave Jones <davej@redhat.com>
* [CPUFREQ] S5PV210: Add reboot notifier to prevent system hangHuisung Kang2011-07-131-0/+19
| | | | | | | | | | When system reboot, the CPUFREQ level should be 800MHz to prevent system lockup. Signed-off-by: Huisung Kang <hs1218.kang@samsung.com> Signed-off-by: Jonghwan Choi <jhbird.choi@samsung.com> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com> Signed-off-by: Dave Jones <davej@redhat.com>
* [CPUFREQ] S5PV210: Adjust udelay prior to voltage scaling downTodd Poynor2011-07-131-2/+2
| | | | | | | | | | | | Voltage scaling accesses the MAX8998 regulators over bit-banged I2C with lots of udelays. In the case of decreasing CPU speed, the number of loops per us for udelay needs to be adjusted prior to decreasing voltage to avoid delaying for up to 10X too long. Signed-off-by: Todd Poynor <toddpoynor@google.com> Signed-off-by: Jonghwan Choi <jhbird.choi@samsung.com> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com> Signed-off-by: Dave Jones <davej@redhat.com>
* [CPUFREQ] S5PV210: Lock a mutex while changing the cpu frequencyArve Hjønnevåg2011-07-131-9/+19
| | | | | | | | | | | Without this lock the call to change the frequency for suspend could switch to a new frequency while another thread was still changing the cpu voltage. Signed-off-by: Arve Hjønnevåg <arve@android.com> Signed-off-by: Jonghwan Choi <jhbird.choi@samsung.com> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com> Signed-off-by: Dave Jones <davej@redhat.com>
* [CPUFREQ] S5PV210: Add pm_notifier to prevent system unstableHuisung Kang2011-07-131-0/+34
| | | | | | | | | Minimum 800MHz is needed to enter/exit suspend mode due to voltage mismatch. Signed-off-by: Huisung Kang <hs1218.kang@samsung.com> Signed-off-by: Jonghwan Choi <jhbird.choi@samsung.com> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com> Signed-off-by: Dave Jones <davej@redhat.com>
* [CPUFREQ] S5PV210: Add arm/int voltage control supportJonghwan Choi2011-07-131-3/+68
| | | | | | Signed-off-by: Jonghwan Choi <jhbird.choi@samsung.com> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com> Signed-off-by: Dave Jones <davej@redhat.com>
* [CPUFREQ] S5PV210: Add additional symantics for "relation" in cpufreq with pmHuisung Kang2011-07-131-0/+28
| | | | | | | | | | | | Relation has an additional symantics other than standard. s5pv310_target funtion have below additional relation. - DISABLE_FURTHER_CPUFREQ : disable further access to target - ENABLE_FURTHER_CPUFRER : enable access to target Signed-off-by: Huisung Kang <hs1218.kang@samsung.com> Signed-off-by: Jonghwan Choi <jhbird.choi@samsung.com> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com> Signed-off-by: Dave Jones <davej@redhat.com>
* [CPUFREQ] S3C64xx: Notify transition complete as soon as frequency changedMark Brown2011-07-131-2/+2
| | | | | | | | | | | | | | The CPUFREQ_POSTCHANGE notification is used to update things that depend on the system clock rates. Since this may include the interfaces used to talk to the regulators do the notification before we try to update regulators to reflect lowered system clock rate. The voltage scaling is just a power optimisation and may not happen at all so there's no concern about it not having completed. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Kukjin Kim <kgene.kim@samsung.com> Signed-off-by: Dave Jones <davej@redhat.com>
* [CPUFREQ] S3C6410: Support 800MHz operation in cpufreqMark Brown2011-07-131-0/+2
| | | | | | | | | | | At least some newer S3C6410 silicon supports operation up to 800MHz rather than just 667MHz. Unfortunately I don't have access to any of documentation of this other than some running systems, add a new cpufreq table entry for this based on the behaviour of those systems. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Kukjin Kim <kgene.kim@samsung.com> Signed-off-by: Dave Jones <davej@redhat.com>
* [CPUFREQ] s5pv210-cpufreq.c: Add missing clk_putJulia Lawall2011-07-131-8/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The successive calls to clk_get each call clk_put in the case of failure, but this is not done for subsequent error handling code. The calls to clk_get are moved to the end of the function, and appropriate gotos are added. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @r exists@ expression e1,e2; statement S; @@ e1 = clk_get@p1(...); ... when != e1 = e2 when != clk_put(e1) when any if (...) { ... when != clk_put(e1) when != if (...) { ... clk_put(e1) ... } * return@p3 ...; } else S // </smpl> Signed-off-by: Julia Lawall <julia@diku.dk> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com> Signed-off-by: Dave Jones <davej@redhat.com>
* [CPUFREQ] Move compile for S3C64XX cpufreq to /drivers/cpufreqKukjin Kim2011-07-134-5/+10
| | | | | | Cc: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com> Signed-off-by: Dave Jones <davej@redhat.com>
* [CPUFREQ] Remove some vi noise that escaped into the Makefile.Dave Jones2011-07-131-3/+2
|
* [CPUFREQ] Move ARM Samsung cpufreq drivers to drivers/cpufreq/Kukjin Kim2011-07-137-6/+32
| | | | | | | | | | | | According to discussion of the ARM arch subsystem migration, ARM cpufreq drivers move to drivers/cpufreq. So this patch adds Kconfig.arm for ARM like x86 and adds Samsung S5PV210 and EXYNOS4210 cpufreq driver compile in there. As a note, otherw will be moved. Cc: Dave Jones <davej@redhat.com> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com> Signed-off-by: Dave Jones <davej@redhat.com>
* [CPUFREQ/S3C64xx] Move S3C64xx CPUfreq driver into drivers/cpufreqMark Brown2011-07-133-6/+2
| | | | | | | | | | This is a straight code motion patch, there are no changes to the driver itself. The Kconfig is left untouched as the ARM CPUfreq Kconfig is all in one big block in arm/Kconfig and should be moved en masse rather than being done piecemeal. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Dave Jones <davej@redhat.com>
* [CPUFREQ] Handle CPUs with different capabilities in acpi-cpufreqMatthew Garrett2011-07-131-1/+1
| | | | | | | | | | acpi-cpufreq checks each CPU for aperf/mperf support, but only sets a global flag. This will cause errors if some CPUs in the system don't support the feature. Check boot_cpu_has() instead in order to make sure that all CPUs support it. Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Dave Jones <davej@redhat.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-rc7v3.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>
OpenPOWER on IntegriCloud