Henrik Rydberg [Fri, 5 Sep 2008 02:28:23 +0000 (22:28 -0400)]
Input: bcm5974 - improve finger tracking and counting
The problem of finger tracking, i.e., when to switch focus from one
finger to another on the trackpad, has been improved by utilizing more
information from the bcm5974 chip output. This results in less pointer
hopping when many fingers are on the trackpad. In addition, a finger
counting method based on pressure information from all fingers is
introduced. Together with a pressure hysteresis window, this yields a
more stable counting of the number of fingers on the trackpad.
Signed-off-by: Henrik Rydberg <rydberg@euromail.se> Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Julius Volz [Tue, 2 Sep 2008 13:55:55 +0000 (15:55 +0200)]
IPVS: Allow adding IPv6 services from userspace
Allow adding IPv6 services through the genetlink interface and add checks
to see if the chosen scheduler is supported with IPv6 and whether the
supplied prefix length is sane. Make sure the service count exported via
the sockopt interface only counts IPv4 services.
Signed-off-by: Julius Volz <juliusv@google.com> Signed-off-by: Simon Horman <horms@verge.net.au>
IPVS: Add function to determine if IPv6 address is local
Add __ip_vs_addr_is_local_v6() to find out if an IPv6 address belongs to a
local interface. Use this function to decide whether to set the
IP_VS_CONN_F_LOCALNODE flag for IPv6 destinations.
Signed-off-by: Vince Busam <vbusam@google.com> Signed-off-by: Simon Horman <horms@verge.net.au>
Julius Volz [Tue, 2 Sep 2008 13:55:47 +0000 (15:55 +0200)]
IPVS: Add/adjust Netfilter hook functions and helpers for v6
Add Netfilter hook functions or modify existing ones, if possible, to
process IPv6 packets. Some support functions are also added/modified for
this. ip_vs_nat_icmp_v6() was already added in the patch that added the v6
xmit functions, as it is called from one of them.
Signed-off-by: Julius Volz <juliusv@google.com> Signed-off-by: Simon Horman <horms@verge.net.au>
Julius Volz [Tue, 2 Sep 2008 13:55:40 +0000 (15:55 +0200)]
IPVS: Add 'af' args to protocol handler functions
Add 'af' arguments to conn_schedule(), conn_in_get(), conn_out_get() and
csum_check() function pointers in struct ip_vs_protocol. Extend the
respective functions for TCP, UDP, AH and ESP and adjust the callers.
The changes in the callers need to be somewhat extensive, since they now
need to pass a filled out struct ip_vs_iphdr * to the modified functions
instead of a struct iphdr *.
Signed-off-by: Julius Volz <juliusv@google.com> Signed-off-by: Simon Horman <horms@verge.net.au>
Julius Volz [Tue, 2 Sep 2008 13:55:39 +0000 (15:55 +0200)]
IPVS: Add IPv6 support flag to schedulers
Add 'supports_ipv6' flag to struct ip_vs_scheduler to indicate whether a
scheduler supports IPv6. Set the flag to 1 in schedulers that work with
IPv6, 0 otherwise. This flag is checked in a later patch while trying to
add a service with a specific scheduler. Adjust debug in v6-supporting
schedulers to work with both address families.
Signed-off-by: Julius Volz <juliusv@google.com> Signed-off-by: Simon Horman <horms@verge.net.au>
Julius Volz [Tue, 2 Sep 2008 13:55:37 +0000 (15:55 +0200)]
IPVS: Convert __ip_vs_svc_get() and __ip_vs_fwm_get()
Add support for getting services based on their address family to
__ip_vs_service_get(), __ip_vs_fwm_get() and the helper hash function
ip_vs_svc_hashkey(). Adjust the callers.
Signed-off-by: Julius Volz <juliusv@google.com> Signed-off-by: Simon Horman <horms@verge.net.au>
Julius Volz [Tue, 2 Sep 2008 13:55:36 +0000 (15:55 +0200)]
IPVS: Add internal versions of sockopt interface structs
Add extended internal versions of struct ip_vs_service_user and struct
ip_vs_dest_user (the originals can't be modified as they are part
of the old sockopt interface). Adjust ip_vs_ctl.c to work with the new
data structures and add some minor AF-awareness.
Signed-off-by: Julius Volz <juliusv@google.com> Signed-off-by: Simon Horman <horms@verge.net.au>
Julius Volz [Tue, 2 Sep 2008 13:55:35 +0000 (15:55 +0200)]
IPVS: Add debug macros for v4 and v6 address output
Add some debugging macros that allow conditional output of either v4 or v6
addresses, depending on an 'af' parameter. This is done by creating a
temporary string buffer in an outer debug macro and writing addresses'
string representations into it from another macro which can only be used
when inside the outer one.
Signed-off-by: Julius Volz <juliusv@google.com> Signed-off-by: Simon Horman <horms@verge.net.au>
Julius Volz [Tue, 2 Sep 2008 13:55:34 +0000 (15:55 +0200)]
IPVS: Add general v4/v6 helper functions / data structures
Add a struct ip_vs_iphdr for easier handling of common v4 and v6 header
fields in the same code path. ip_vs_fill_iphdr() helps to fill this struct
from an IPv4 or IPv6 header. Add further helper functions for copying and
comparing addresses.
Signed-off-by: Julius Volz <juliusv@google.com> Signed-off-by: Simon Horman <horms@verge.net.au>
Julius Volz [Tue, 2 Sep 2008 13:55:32 +0000 (15:55 +0200)]
IPVS: Add CONFIG_IP_VS_IPV6 option for IPv6 support
Add boolean config option CONFIG_IP_VS_IPV6 for enabling experimental IPv6
support in IPVS. Only visible if IPv6 support is set to 'y' or both IPv6
and IPVS are modules.
Signed-off-by: Julius Volz <juliusv@google.com> Signed-off-by: Simon Horman <horms@verge.net.au>
Jeremy Kerr [Thu, 4 Sep 2008 05:02:47 +0000 (15:02 +1000)]
powerpc/spufs: Fix race for a free SPU
We currently have a race for a free SPE. With one thread doing a
spu_yield(), and another doing a spu_activate():
thread 1 thread 2
spu_yield(oldctx) spu_activate(ctx)
__spu_deactivate(oldctx)
spu_unschedule(oldctx, spu)
spu->alloc_state = SPU_FREE
spu = spu_get_idle(ctx)
- searches for a SPE in
state SPU_FREE, gets
the context just
freed by thread 1
spu_schedule(ctx, spu)
spu->alloc_state = SPU_USED
spu_schedule(newctx, spu)
- assumes spu is still free
- tries to schedule context on
already-used spu
This change introduces a 'free_spu' flag to spu_unschedule, to indicate
whether or not the function should free the spu after descheduling the
context. We only set this flag if we're not going to re-schedule
another context on this SPU.
Jeremy Kerr [Tue, 2 Sep 2008 01:57:09 +0000 (11:57 +1000)]
powerpc/spufs: Fix multiple get_spu_context()
Commit 8d5636fbca202f61fdb808fc9e20c0142291d802 introduced a reference
count on SPU contexts during find_victim, but this may cause a leak in
the reference count if we later find a better contender for a context to
unschedule.
Change the reference to after we've found our victim context, so we
don't do the extra get_spu_context().
OMAP1_IO_ADDRESS(), OMAP2_IO_ADDRESS() and IO_ADDRESS() returns cookies
for use with __raw_{read|write}* for accessing registers. Therefore,
these macros should return (void __iomem *) cookies, not integer values.
Doing this improves typechecking, and means we can find those places
where, eg, DMA controllers are incorrectly given virtual addresses to
DMA to, or physical addresses are thrown through a virtual to physical
address translation.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Hans de Goede [Mon, 1 Sep 2008 18:28:23 +0000 (15:28 -0300)]
V4L/DVB (8880): PATCH: Fix parents on some webcam drivers
While doing some testing using Luca Risolia's sonix driver I noticed that
the video device did not get ACL's set to allow access by locally logged in
users, nor does it show up as a video device in lshal, causing cheese to not
see it.
This turns out to be caused by all of Luca Risolia's drivers not setting
the parent member of the video_device struct. This patch fixes this.
Cc: Luca Risolia <luca.risolia@studio.unibo.it> Signed-off-by: Hans de Goede <j.w.r.degoede@hhs.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
b2c2-flexcop, dvb/bt8xx and video/bt8xx fails to build on ARM with:
__bad_udelay is specifically designed on ARM to fail when udelay is
called in a bad way. arch/arm/include/asm/delay.h has this to say
about __bad_udelay:
/*
* This function intentionally does not exist; if you see references to
* it, it means that you're calling udelay() with an out of range value.
*
* With currently imposed limits, this means that we support a max delay
* of 2000us. Further limits: HZ<=1000 and bogomips<=3355
*/
extern void __bad_udelay(void);
Solution is to replace udelay by a mdelay and udelay with value less than 2000
__bad_udelay is specifically designed on ARM to fail when udelay is
called in a bad way. arch/arm/include/asm/delay.h has this to say
about __bad_udelay:
/*
* This function intentionally does not exist; if you see references to
* it, it means that you're calling udelay() with an out of range value.
*
* With currently imposed limits, this means that we support a max delay
* of 2000us. Further limits: HZ<=1000 and bogomips<=3355
*/
extern void __bad_udelay(void);
Solution is to replace udelay by a mdelay and udelay with value less than 2000
Introduce a fast TSC-calibration method on sane hardware.
It only uses 17920 PIT timer ticks to calibrate the TSC, plus 256 ticks on
each side to make sure the TSC values were very close to the tick, so the
whole calibration takes 15ms. Yet, despite only takign 15ms,
we can actually give pretty stringent guarantees of accuracy:
- the code requires that we hit each 256-counter block at least 50 times,
so the TSC error is basically at *MOST* just a few PIT cycles off in
any direction. In practice, it's going to be about one microseconds
off (which is how long it takes to read the counter)
- so over 17920 PIT cycles, we can pretty much guarantee that the
calibration error is less than one half of a percent.
My testing bears this out: on my machine, the quick-calibration reports
2934.085kHz, while the slow one reports 2933.415.
Yes, the slower calibration is still more precise. For me, the slow
calibration is stable to within about one hundreth of a percent, so it's
(at a guess) roughly an order-and-a-half of magnitude more precise. The
longer you wait, the more precise you can be.
However, the nice thing about the fast TSC PIT synchronization is that
it's pretty much _guaranteed_ to give that 0.5% precision, and fail
gracefully (and very quickly) if it doesn't get it. And it really is
fairly simple (even if there's a lot of _details_ there, and I didn't get
all of those right ont he first try or even the second ;)
The patch says "110 insertions", but 63 of those new lines are actually
comments.
Andrew Morton noticed that the printk in kernel/resource.c was buggy:
| start and end have type resource_size_t. Such types CANNOT be printed
| unless cast to a known type.
|
| Because there is a %s following an incorrect %lld, the above code will
| crash the machine.
... and it's probably quite unneeded as well, so remove it.
Reported-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
Hans de Goede [Thu, 4 Sep 2008 19:22:57 +0000 (16:22 -0300)]
V4L/DVB (8874): gspca: Adjust hstart for sn9c103/ov7630 and update usb-id's.
- Adjust hstart in ov7630 on sn9c103 initdata to shift bayer pattern, this is
the same change as done for the other initdata tables in a previous patch.
- Assign usb-id's for the ov7630 + sn9c103 to gspca if gspca and sn9c102
drivers are both enabled.
Signed-off-by: Hans de Goede <j.w.r.degoede@hhs.nl> Signed-off-by: Jean-Francois Moine <moinejf@free.fr> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Hans de Goede [Thu, 4 Sep 2008 19:22:57 +0000 (16:22 -0300)]
V4L/DVB (8873): gspca: Bad image offset with rev012a of spca561 and adjust exposure.
-Make raw bayer header size change from 20 to 16 affect rev072a only, my 2
rev012a cams both have a header size of 20
-While testing this I also tested the new exposure setting (good work on
finding the register JF), and after quite a bit of testing have found out the
exact meaning of the register, this patch modifies setexposure to control
the exposure over a much wider range.
Signed-off-by: Hans de Goede <j.w.r.degoede@hhs.nl> Signed-off-by: Jean-Francois Moine <moinejf@free.fr> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Hans de Goede [Thu, 4 Sep 2008 19:22:56 +0000 (16:22 -0300)]
V4L/DVB (8870): gspca: Fix dark room problem with sonixb.
When using the sonixb driver in a dark room and given that the autoexposure
algorithm starts with a setting most suitable for daylight, the picture
produced by the cam may actually be 100% black leading to a avg_lum value of 0,
so an avg_lum value of 0 does not always signal an exposure settings change
(which it normally does). This patch adds a check for the really black image
case and stops dropping all frames as invalid in this case.
Signed-off-by: Hans de Goede <j.w.r.degoede@hhs.nl> Signed-off-by: Jean-Francois Moine <moinejf@free.fr> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Hans de Goede [Thu, 4 Sep 2008 19:22:55 +0000 (16:22 -0300)]
V4L/DVB (8869): gspca: Move the Sonix webcams with TAS5110C1B from sn9c102 to gspca.
This patch makes gspca claim the USB-ID for sn9c101/2 cams with a TAS5110C1B
sensor even if both gspca and sn9c102 are enabled, as these cams are much
better supported under gspca (and extensively tested with gspca).
It also removes an usb-id from sn9c102 for one more unsupported bridge
sensor combo.
Signed-off-by: Hans de Goede <j.w.r.degoede@hhs.nl> Signed-off-by: Jean-Francois Moine <moinejf@free.fr> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Hans de Goede [Thu, 4 Sep 2008 19:20:12 +0000 (16:20 -0300)]
V4L/DVB (8868): gspca: Support for vga modes with sif sensors in sonixb.
- Add documentation for some known registers
- Add support for vga modes (320x240, 160x120) for sif sensors
- Remove F_RAW sensor flag raw mode should work on any sensor as its a bridge
only thing and keeping the flag was becoming awkward.
- Fixup ov6650 and pas106 auto exposure window settings
Signed-off-by: Hans de Goede <j.w.r.degoede@hhs.nl> Signed-off-by: Jean-Francois Moine <moinejf@free.fr> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Yinghai Lu [Thu, 4 Sep 2008 19:09:45 +0000 (21:09 +0200)]
x86: remove cpu_vendor_dev
1. add c_x86_vendor into cpu_dev
2. change cpu_devs to static
3. check c_x86_vendor before put that cpu_dev into array
4. remove alignment for 64bit
5. order the sequence in cpu_devs according to link sequence...
so could put intel at first, then amd...
Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
Yinghai Lu [Thu, 4 Sep 2008 19:09:44 +0000 (21:09 +0200)]
x86: make (early)_identify_cpu more the same between 32bit and 64 bit
1. add extended_cpuid_level for 32bit
2. add generic_identify for 64bit
3. add early_identify_cpu for 32bit
4. early_identify_cpu not be called by identify_cpu
5. remove early in get_cpu_vendor for 32bit
6. add get_cpu_cap
7. add cpu_detect for 64bit
Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
Yinghai Lu [Thu, 4 Sep 2008 19:09:43 +0000 (21:09 +0200)]
x86: move mtrr cpu cap setting early in early_init_xxxx
Krzysztof Helt found MTRR is not detected on k6-2
root cause:
we moved mtrr_bp_init() early for mtrr trimming,
and in early_detect we only read the CPU capability from cpuid,
so some cpu doesn't have that bit in cpuid.
So we need to add early_init_xxxx to preset those bit before mtrr_bp_init
for those earlier cpus.
this patch is for v2.6.27
Reported-by: Krzysztof Helt <krzysztof.h1@wp.pl> Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
Yinghai Lu [Thu, 4 Sep 2008 19:02:44 +0000 (21:02 +0200)]
IO resources: add reserve_region_with_split()
add reserve_region_with_split() to not lose e820 reserved entries if
they overlap with existing IO regions:
with test case by extend 0xe0000000 - 0xeffffff to 0xdd800000 -
we get: e0000000-efffffff : PCI MMCONFIG 0 e0000000-efffffff : reserved
and in /proc/iomem we get:
found conflict for reserved [dd800000, efffffff], try to reserve with split
__reserve_region_with_split: (PCI Bus #80) [dd000000, ddffffff], res: (reserved) [dd800000, efffffff]
__reserve_region_with_split: (PCI Bus #00) [de000000, dfffffff], res: (reserved) [de000000, efffffff]
initcall pci_subsys_init+0x0/0x121 returned 0 after 381 msecs
in dmesg
various fixes and improvements suggested by Linus.
Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
Russell King [Mon, 1 Sep 2008 20:25:33 +0000 (21:25 +0100)]
[ARM] omap: improve is_omap_port()
Make is_omap_port() take the uart_8250_port structure so it can do
whatever test it desires. Convert the test to compare the physical
addresses rather than virtual addresses.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Russell King [Wed, 3 Sep 2008 22:59:23 +0000 (23:59 +0100)]
[ARM] omap: fix build error in ohci-omap.c
drivers/usb/host/ohci-omap.c: In function 'ohci_omap_init':
drivers/usb/host/ohci-omap.c:228: error: 'start_hnp' undeclared (first use in this function)
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Russell King [Wed, 3 Sep 2008 09:15:26 +0000 (10:15 +0100)]
[ARM] omap: fix gpio.c build error
arch/arm/plat-omap/gpio.c: In function '_omap_gpio_init':
arch/arm/plat-omap/gpio.c:1492: error: 'omap_mpuio_device' undeclared (first use in this function)
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
I did some rebenchmarking with modern compilers and dropping
-funroll-loops makes the function consistently go faster by a few
percent. So drop that flag.
Thanks to Richard Guenther for a hint.
Signed-off-by: Andi Kleen <ak@linux.intel.com> Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Ingo Molnar [Fri, 29 Aug 2008 06:09:23 +0000 (08:09 +0200)]
x86: split e820 reserved entries record to late v4
this one replaces:
| commit a2bd7274b47124d2fc4dfdb8c0591f545ba749dd
| Author: Yinghai Lu <yhlu.kernel@gmail.com>
| Date: Mon Aug 25 00:56:08 2008 -0700
|
| x86: fix HPET regression in 2.6.26 versus 2.6.25, check hpet against BAR, v3
v2: insert e820 reserve resources before pnp_system_init
v3: fix merging problem in tip/x86/core
v4: address Linus's review about comments and condition in _late()
Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
Thomas Gleixner [Thu, 4 Sep 2008 15:18:59 +0000 (15:18 +0000)]
x86: TSC make the calibration loop smarter
The last changes made the calibration loop 250ms long which is far
too much. Try to do that more clever.
Experiments have shown that using a 10ms delay for the PIT based calibration
gives us a good enough value. If we have a reference (HPET/PMTIMER) and the
result of the PIT and the reference is close enough, then we can break out of
the calibration loop on a match right away and use the reference value.
Otherwise we just loop 3 times and decide then, which value to take.
One caveat is that for virtualized environments the PIT calibration often does
not work at all and I found out that 10us is a bit too short as well for the
reference to give a sane result. The solution here is to make the last loop
longer when the first two PIT calibrations failed.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@elte.hu>
lockdep: fix compilation when CONFIG_TRACE_IRQFLAGS_SUPPORT is not set
This patch fixes compilation if CONFIG_TRACE_IRQFLAGS_SUPPORT is ever
disabled (which is currently not allowed by Kconfig). Alternatively
we could just remove the option altogether and the associated code
paths. Since the compilation error has been in the tree for at
least two years and no one noticed it, I guess we don't really have
the need for CONFIG_TRACE_IRQFLAGS_SUPPORT=n.
H. Peter Anvin [Thu, 4 Sep 2008 13:19:45 +0000 (06:19 -0700)]
x86: boot/compressed/Makefile: fix "make clean"
The Kbuild variable "targets" is supposed to be
configuration-independent and reflect "all possible targets". This is
required to make "make clean" work properly.
Therefore, move all manipulation of "targets" as well as custom rules
out of the x86-32 ifdef statement. Only leave inside the ifdefs the
things that are genuinely configuration-dependent.
Zhao Yakui [Tue, 26 Aug 2008 05:57:34 +0000 (13:57 +0800)]
ACPI: Avoid bogus timeout about SMbus check
In the function of wait_transaction_complete when the timeout happens,
OS will try to check the status of SMbus again. If the status is what OS
expected, it will be regarded as the bogus timeout. Otherwise it will be
treated as ETIME.
Jonathan Woithe [Fri, 29 Aug 2008 01:36:21 +0000 (11:06 +0930)]
fujitsu-laptop: fix regression for P8010 in 2.6.27-rc
The following patch (based on a patch from Stephen Gildea) fixes a
regression with the LCD brightness keys on Fujitsu P8010 laptops which was
observed with the 2.6.27-rc series (basically they stopped working due to
changes within the fujitsu-laptop and video modules). Please apply to
2.6.27-rc and acpi git.
A more complete solution for this laptop will be included in an upcoming
patch, hopefully for 2.6.28. In the meantime this restores most
functionality for P8010 users.
Signed-off-by: Stephen Gildea <stepheng+fujitsu-laptop@gildea.com> Signed-off-by: Jonathan Woithe <jwoithe@physics.adelaide.edu.au> Signed-off-by: Andi Kleen <ak@linux.intel.com>
projects / linux-2.6-omap-h63xx.git / log