Change the X plate resistance so that user-space gets the pressure
value range it expects.
Signed-off-by: Imre Deak <imre.deak@nokia.com>
Signed-off-by: Juha Yrjola <juha.yrjola@nokia.com>

On Nokia 770, the SleepX signal is masked with an MPUIO.  Unmasking
SleepX was previously done in mach-omap1/pm.c, but it belongs to the
board-specific file.
Signed-off-by: Juha Yrjola <juha.yrjola@nokia.com>

Add disable attribute to support device locking mode, where a
unintentional touch event shouldn't wake up the system.

Add missing spin_lock_init.

Do device resume with the lock held.

Do cleanup calls / free memory in the reverse order of initialization.
Signed-off-by: Imre Deak <imre.deak@nokia.com>
Signed-off-by: Juha Yrjola <juha.yrjola@nokia.com>

Move dma related parameters to platform data and also
few more cosmetic changes.
Signed-off-by: Komal Shah <komal_shah802003@yahoo.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

Remove debugging printks and few cosmetic changes.
Signed-off-by: Komal Shah <komal_shah802003@yahoo.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

While doing development for an OMAP2420 board I noticed that the
"workaround for seemingly-lost IRQs for RX ACKs" in omap_udc.c needs a
little tweak in order to prevent NFS root over usbnet from hanging.
According to the documentation the status flag register should only be
accessed when endpoint select bit is set in the EP_NUM register. See
e.g. SPRU761A, end of page 78 (about STAT_FLG register):

"This register cannot be read if EP_NUM.EP_SEL bit is not asserted for the
endpoint."

Similar statement seems to be in the specs for other OMAPs too.

As a change for the workaround seem to have an effect it seems that
there is indeed an underlying "IRQs get lost" problem?

In principle reading the status flag in proc_ep_show() would need
similar change, but I'm not sure how the EP selection would interact
with interrupt processing. Actually I'm not sure how this change
interacts with interrupt processing either but at least it cured the
hangs for the 2420.

It seems that usbnet with Nokia 770 is also a bit unreliable but this
change does not seem to have an effect. Does someone have an OMAP
based system where usbnet is reliable?

Did not get removed earlier as noted by Komal Shah.

This patch will fix the i2c-omap "controller timed out" error on
OMAP1710 (most probably will apply to 1510 as well). Error happens
randomly if dyn_tick is activated (CONFIG_NO_IDLE_HZ=y) and reason was
that ARMXOR_CK clock domain was stopped during MPU idle.

Patch basically creates and uses virtual i2c_fck clock domain which
prevents that its parent ARMXOR_CK is not stopped during MPU idle
whenever i2c_fck is enabled. Patch also makes i2c-omap implementation
between 24xx and OMAP1 more consistent with the clock usage and fixes two
minor bugs.
Signed-off-by: Jarkko Nikula <jarkko.nikula@nokia.com>
Signed-off-by: Juha Yrjl <juha.yrjola@nokia.com>

IOCTL parameters shouldn't be of an enum type, replace them with int.

This also fixes up the places where u8, u16, u32 was used instead of
__u8, __u16, __u32 for things used by user space.

This solves a bug for IOCTL code mismatch between kernel and user space
because the toolchains used generated different value for sizeof(enum
xxx) and this size is encoded in the IOCTL code.
Signed-off-by: Imre Deak <imre.deak@nokia.com>
Signed-off-by: Juha Yrjölä <juha.yrjola@nokia.com>

Signed-off-by: Toshihiro Kobayashi <toshihiro.kobayashi@nokia.com>
Signed-off-by: Juha Yrjl <juha.yrjola@nokia.com>

Attached patch uses clock id for I2C clocks on OMAP2. Tested with H4.
Signed-off-by: Komal Shah <komal_shah802003@yahoo.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

This is Thomas Gleixner's improved version of the patch.

Undo patch bd9dac30 as a
better patch is now available.

Commit 9ec4b1f3 made kprobes not compile
without module support, so just make that clear in the Kconfig file.

Also, since it's marked EXPERIMENTAL, make that dependency explicit too.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

The change to kernel/sched.c's init code to use for_each_cpu()
requires that the cpu_possible_map be setup much earlier.

Set it up via setup_arch(), constrained to NR_CPUS, and later
constrain it to max_cpus in smp_prepare_cpus().

This fixes SMP booting on sparc64.
Signed-off-by: David S. Miller <davem@davemloft.net>

Signed-off-by: David S. Miller <davem@davemloft.net>

Commit 9c869eda broke voyager again
rather subtly because it already had its own topology exporting
functions, so now each CPU gets registered twice.

I think we can actually use the generic ones, so I don't propose
reverting it.  The attached should eliminate the voyager topology
functions in favour of the generic ones.

I also added a define to ensure voyager is never hotplug CPU (we don't
have the support in the SMP harness).
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

The commit e2c03888 added
setup_additional_cpus to setup.c but this is only defined if
CONFIG_HOTPLUG_CPU is set.  This patch changes the #ifdef to reflect that.
Signed-off-by: Brian Magnuson <magnuson@rcn.com>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

RTC_IRQP_SET/RTC_EPOCH_SET don't take a pointer to an argument, but the
argument itself.  This actually simplifies the code and makes it work.
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

The previous experiment for using apicmaintimer on ATI systems didn't
work out very well.  In particular laptops with C2/C3 support often
don't let it tick during idle, which makes it useless.  There were also
some other bugs that made the apicmaintimer often not used at all.

I tried some other experiments - running timer over RTC and some other
things but they didn't really work well neither.

I rechecked the specs now and it turns out this simple change is
actually enough to avoid the double ticks on the ATI systems.  We just
turn off IRQ 0 in the 8254 and only route it directly using the IO-APIC.

I tested it on a few ATI systems and it worked there.  In fact it worked
on all chipsets (NVidia, Intel, AMD, ATI) I tried it on.

According to the ACPI spec routing should always work through the
IO-APIC so I think it's the correct thing to do anyways (and most of the
old gunk in check_timer should be thrown away for x86-64).

But for 2.6.16 it's best to do a fairly minimal change:
 - Use the known to be working everywhere-but-ATI IRQ0 both over 8254
   and IO-APIC setup everywhere
 - Except on ATI disable IRQ0 in the 8254
 - Remove the code to select apicmaintimer on ATI chipsets
 - Add some boot options to allow to override this (just paranoia)

In 2.6.17 I hope to switch the default over to this for everybody.
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

SMP time selection originally ran after all CPUs were brought up because
it needed to know the number of CPUs to decide if it needs an MP safe
timer or not.

This is not needed anymore because we know present CPUs early.

This fixes a couple of problems:
 - apicmaintimer didn't always work because it relied on state that was
   set up time_init_gtod too late.
 - The output for the used timer in early kernel log was misleading
   because time_init_gtod could actually change it later.  Now always
   print the final timer choice
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

It didn't set up the CPU possible map early enough, so the
option didn't actually work.

Noticed by Heiko Carstens
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

ACPI is initialized very early on x86-64, before the DMI code is
initialized.  This means it would often discover a 0 year and then turn
off ACPI because it thought the BIOS was too old.  Some systems don't
boot without ACPI so this was a problem.

I have a full fix by adding new very early DMI detection, but it needs
more testing before it can be merged.  For 2.6.16 let's just turn the
check off.  It never made much sense anyways because there are no x86-64
systems older than 2002 or so and they generally all have working ACPI.

Cc: len.brown@intel.com
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

[description from AK]

Old check for the IO-APIC watchdog during the timer check was wrong -
it obviously should only drop into this if the IO-APIC watchdog is used.
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

This makes x86-64 use the common X86_PM_TIMER Kconfig entry in drivers/acpi

And since PM timer is needed for correct timing on a lot of systems
now (e.g. AMD dual cores) and we often get bug reports from people
who forgot to set it make it depend on CONFIG_EMBEDDED. x86-64 had
this change before and it's a good thing.

I also fixed the description slightly to make this more clear.

Cc: len.brown@intel.com
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

[description from AK]

This fixes booting in APIC mode on some ACER laptops. x86-64
did a similar change some time ago.

See http://bugzilla.kernel.org/show_bug.cgi?id=4700 for details
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Big Unisys systems have multiple clusters too, but they have an
synchronized TSC.

I'm using the SMBIOS to check for vendor == IBM.

Cc: Chris McDermott <lcm@us.ibm.com>
Cc: "Protasevich, Natalie" <Natalie.Protasevich@unisys.com>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Fixes a local DOS on Intel systems that lead to an endless
recursive fault.  AMD machines don't seem to be affected.
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

The value, while currently unused in the native kernel, was off by one.
Signed-Off-By: Jan Beulich <jbeulich@novell.com>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

In previous versions of pci-gart.c, no_iommu was used to determine if IOMMU was
disabled in the GART DMA mapping functions.  This changed in 2.6.16 and now
gart_xxx() functions are only called if gart is enabled.  Therefore, uses of
no_iommu in the GART code are no longer necessary and can be removed.

Also, it removes double deceleration of no_iommu and force_iommu in pci.h and
proto.h, by removing the deceleration in pci.h.

Lastly, end_pfn off by one error.

Tested (along with patch 1/2) on dual opteron with gart enabled, iommu=soft,
and iommu=off.
Signed-off-by: Jon Mason <jdmason@us.ibm.com>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

As the (probably) last user of a Specialix SI board, I noticed that
recent kernels would fail to probe the sucker.  Quick investigation
indicate a few missing braces...

I left the double probing in place, as it looks like it's been here
forever.
Signed-off-by: Marc Zyngier <maz@misterjones.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

There's a problem in sd where we blindly believe the length of the
headers and block descriptors.  Some devices return insane values for
these and cause our length to end up greater than the actual buffer
size, so check to make sure.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

Also removed the buffer size magic number (512) and added DPOFUA of
zero to the defaults
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Commit 9c869eda moved the i386 topology.c
file. That change broke x86-64 compiles, as it uses the same file.
Signed-off-by: Dave Jones <davej@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Sync. with OMAP git tree

Update H4 defconfig with keypad and Irda support enabled
Signed-off-by: Komal Shah <komal_shah802003@yahoo.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>