Entering nohz code on every micro-idle is costing ~10% throughput for netperf
TCP_RR when scheduling cross-cpu.  Rate limiting entry fixes this, but raises
ticks a bit.  On my Q6600, an idle box goes from ~85 interrupts/sec to 128.

The higher the context switch rate, the more nohz entry costs.  With this patch
and some cycle recovery patches in my tree, max cross cpu context switch rate is
improved by ~16%, a large portion of which of which is this ratelimiting.
Signed-off-by: NMike Galbraith <efault@gmx.de>
Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <1268301003.6785.28.camel@marge.simson.net>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Put all statistic fields of sched_entity in one struct, sched_statistics,
and embed it into sched_entity.

This change allows to memset the sched_statistics to 0 when needed (for
instance when forking), avoiding bugs of non initialized fields.
Signed-off-by: NLucas De Marchi <lucas.de.marchi@gmail.com>
Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <1268275065-18542-1-git-send-email-lucas.de.marchi@gmail.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Since pick_next_highest_task_rt() already iterates all the cgroups and
is really only interested in tasks, skip over the !task entries.
Reported-by: NDhaval Giani <dhaval.giani@gmail.com>
Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
Tested-by: NDhaval Giani <dhaval.giani@gmail.com>
LKML-Reference: <new-submission>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

We haven't used the "orig_rq" variable since
055a0086 "Fix/add missing update_rq_clock() calls"
Signed-off-by: NDan Carpenter <error27@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Andreas Herrmann <andreas.herrmann3@amd.com>
Cc: Gautham R Shenoy <ego@in.ibm.com>
Cc: efault@gmx.de
LKML-Reference: <20100306111752.GL4958@bicker>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

On UV systems, the TSC is not synchronized across blades.  The
sched_clock_cpu() function is returning values that can go
backwards  (I've seen as much as 8 seconds) when switching
between cpus.

As each cpu comes up, early_init_intel() will currently set the
sched_clock_stable flag true.  When mark_tsc_unstable() runs, it
clears the flag, but this only occurs once (the first time a cpu
comes up whose TSC is not synchronized with cpu 0).  After this,
early_init_intel() will set the flag again as the next cpu comes
up.

Only set sched_clock_stable if tsc has not been marked unstable.
Signed-off-by: NDimitri Sivanich <sivanich@sgi.com>
Acked-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Acked-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <20100301174815.GC8224@sgi.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Merge branch 'davinci-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci

* 'davinci-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci: (40 commits)
  DaVinci DM365: Adding support for SPI EEPROM
  DaVinci DM365: Adding DM365 SPI support
  DaVinci DM355: Modifications to DM355 SPI support
  DaVinci: SPI: Adding header file for SPI support.
  davinci: dm646x: CDCE clocks: davinci_clk converted to clk_lookup
  davinci: clkdev cleanup: remove clk_lookup wrapper, use clkdev_add_table()
  DaVinci: DM365: Voice codec support for the DM365 SoC
  davinci: clock: let clk->set_rate function sleep
  Add SDA and SCL pin numbers to i2c platform data
  davinci: da8xx/omap-l1xx: Add EDMA platform data for da850/omap-l138
  davinci: build list of unused EDMA events dynamically
  davinci: Fix edma_alloc_channel api for EDMA_CHANNEL_ANY case
  davinci: Keep count of channel controllers on a platform
  davinci: Correct return value of edma_alloc_channel api
  davinci: add CDCE949 support on DM6467 EVM
  davinci: add support for CDCE949 clock synthesizer
  davinci: da850/omap-l138 EVM: register for suspend support
  davinci: da850/omap-l138: add support for SoC suspend
  davinci: add power management support
  DaVinci: DM365: Changing default queue for DM365.
  ...

* 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev: (38 commits)
  sata_via: Delay on vt6420 when starting ATAPI DMA write
  ata: Detect Delkin Devices compact flash
  pata_efar: Enable parallel scanning
  pata_atiixp: enable parallel scan
  [libata] pata_atiixp: add locking for parallel scanning
  [libata] pata_efar: add locking for parallel scanning
  libata: Pass host flags into the pci helper
  [libata] pata_marvell: CONFIG_AHCI is really CONFIG_SATA_AHCI
  libata: Allow pata_legacy to be built on non-ISA but PCI systems
  pata_pdc202xx_old: fix UDMA mode for PDC2026x chipsets
  pata_pdc202xx_old: fix UDMA mode for Promise UDMA33 cards
  [libata] pata_at91: fix backslash-continued string
  pata_via: store UDMA masks in via_isa_bridges table
  pata_via: fix address setup timings underlocking
  pata_serverworks: fix error message
  pata_serverworks: fix PIO setup for the second channel
  pata_efar: fix secondary port support
  pata_cypress: fix PIO timings underclocking
  pata_cs5535: use correct values for PIO1 and PIO2 data timings
  pata_cmd64x: remove unused definitions
  ...

When writing a disc on certain lite-on dvd-writers (also rebadged
as optiarc/LG/...) connected to a vt6420, the ATAPI CDB ends
up in the datastream and on the disc, causing silent corruption.
Delaying between sending the CDB and starting DMA seems to
prevent this.

I do not know if there are burners that do not suffer from
this, but the patch should be safe for those as well.

There are many reports of this issue, but AFAICT no solution was
found before. For example:
http://lkml.indiana.edu/hypermail/linux/kernel/0802.3/0561.htmlSigned-off-by: NBart Hartgers <bart.hartgers@gmail.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

I have a Delkin Devices compact flash card that isn't being recognized using the
SATA/PATA drivers.
The card is recognized and works with the deprecated ATA drivers.

The error I am seeing is:
ata1.00: failed to IDENTIFY (device reports invalid type, err_mask=0x0)

I tracked it down to ata_id_is_cfa() in include/linux/ata.h.
The Delkin card has id[0] set to 0x844a and id[83] set to 0.
This isn't what the kernel expects and is probably incorrect.

The simplest work-around is to add a check for 0x844a to ata_id_is_cfa().
Signed-off-by: NBen Gardner <gardner.ben@gmail.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

Again originally proposed by Bartlomiej but this does it by using the
generic helper logic instead.
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

This was originally proposed by Bartlomiej but as a device specific
expansion of the init_one function rather than making the helper more
generic.

Enable the parallel scan via the generic flags.
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

This is similar change as commit 60c3be38 for ata_piix host driver
and while pata_atiixp doesn't enable parallel scan yet the race
could probably also be triggered by requesting re-scanning of both
ports at the same time using SCSI sysfs interface.

[Ported to current tree without other patch dependancies by Alan Cox]

Original is
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

This one is
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

Add clearing of UDMA enable bit also for PIO modes and then add
extra locking for parallel scanning.

This is similar change as commit 60c3be38 for ata_piix host driver
and while pata_efar doesn't enable parallel scan yet the race could
probably also be triggered by requesting re-scanning of both ports
at the same time using SCSI sysfs interface.

[Ported to current kernel without other patch dependancies by
 Alan Cox]

Original is
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

This one is
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

This allows parallel scan and the like to be set without having to stop
using the existing full helper functions. This patch merely adds the argument
and fixes up the callers. It doesn't undo the special cases already in the
tree or add any new parallel callers.
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

The marvell driver comtains a fallback to ahci for the sata ports
which is incorrectly checked as CONFIG_AHCI while the only AHCI config
item is actually called SATA_AHCI (which also sounds sensible
considering it's a fallback for the sata ports).
Signed-off-by: NChristoph Egger <siccegge@stud.informatik.uni-erlangen.de>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

This is needed for some unsupported hardware setups on strange 64bit
mainboards where crazy stuff has been done like putting flash ata adapters
on the LPC bus, or where the real hardware is hidden/confused.
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

PDC2026x chipsets need the same treatment as PDC20246 one.

This is completely untested but will hopefully fix UDMA issues
that people have been reporting against pata_pdc202xx_old for
the last couple of years.
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

On Monday 04 January 2010 02:30:24 pm Russell King wrote:

> Found the problem - getting rid of the read of the alt status register
> after the command has been written fixes the UDMA CRC errors on write:
>
> @@ -676,7 +676,8 @@ void ata_sff_exec_command(struct ata_port *ap, const struct
> ata_taskfile *tf)
>         DPRINTK("ata%u: cmd 0x%X\n", ap->print_id, tf->command);
>
>         iowrite8(tf->command, ap->ioaddr.command_addr);
> -       ata_sff_pause(ap);
> +       ndelay(400);
> +//     ata_sff_pause(ap);
>  }
>  EXPORT_SYMBOL_GPL(ata_sff_exec_command);
>
>
> This rather makes sense.  The PDC20247 handles the UDMA part of the
> protocol.  It has no way to tell the PDC20246 to wait while it suspends
> UDMA, so that a normal register access can take place - the 246 ploughs
> on with the register access without any regard to the state of the 247.
>
> If the drive immediately starts the UDMA protocol after a write to the
> command register (as it probably will for the DMA WRITE command), then
> we'll be accessing the taskfile in the middle of the UDMA setup, which
> can't be good.  It's certainly a violation of the ATA specs.

Fix it by adding custom ->sff_exec_command method for UDMA33 chipsets.
Debugged-by: NRussell King <rmk@arm.linux.org.uk>
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

Noticed and rough patch by Joe Perches.
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

* store UDMA masks in via_isa_bridges[] and while at it make "flags"
  field to be u8 instead of u16

* convert the driver to use UDMA masks from via_isa_bridges[]

* remove no longer needed VIA_UDMA* defines

Make some minor documentation and CodingStyle fixes while at it.
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

Correct via_do_set_mode() documentation while at it.
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

Timing registers should be programmed with the desired number of clocks
minus one clock.
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

There shouldn't be any problems with it as IDE cs5535 host driver
has been using those values for years and they match values given
in the (publicly available) datasheet.
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

s/ARTIM2/ARTTIM23/ in cmd648_bmdma_stop() while at it
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

Clear the primary channel pending interrupt bit
instead of the reserved one.
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

Account for the requirements of the DMA mode currently used
by the pair device.
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

Fix incorrect handling of recovery clocks value == 16 resulting
in overclocked recovery timings & potentially underclocked active
timings.
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

Use standard cycle timing for CFA PIO5 and PIO6 modes.

Based on commit 74638c84 for IDE subsystem.
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

Before only the timings for master were set. Datasheet can be found
here: ftp://ftp.vtbridge.org/Docs/Storage/DS_VT6421A_100_CCPL.PDF
Surprisingly, a slave drive works without this patch. According to the
datasheet, the controller by default derives the DMA mode from the
Set Features command issued to a drive. Not sure about the PIO
timings, though. The real problem is that the timings for the master
effectively are the ones tuned for the slave. If these support
different UDMA-settings, there is trouble, especially when the slave
supports a higher UDMA than the master.

Anyhow, using the same mechanism for both master and slave seems like
a good idea.
Signed-off-by: NBart Hartgers <bart.hartgers@gmail.com>
Acked-by: NTejun Heo <tj@kernel.org>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

Make some variables in ahci and a function in pata_pcmcia static, as found
using sparse.
Signed-off-by: NRobert Hancock <hancockrwd@gmail.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

Traditional IDE interface sucks in that it doesn't have a reliable IRQ
pending bit, so if the controller raises IRQ while the driver is
expecting it not to, the IRQ won't be cleared and eventually the IRQ
line will be killed by interrupt subsystem.  Some controllers have
non-standard mechanism to indicate IRQ pending so that this condition
can be detected and worked around.

This patch adds an optional operation ->sff_irq_check() which will be
called for each port from the ata_sff_interrupt() if an unexpected
interrupt is received.  If the operation returns %true,
->sff_check_status() and ->sff_irq_clear() will be cleared for the
port.  Note that this doesn't mark the interrupt as handled so it
won't prevent IRQ subsystem from killing the IRQ if this mechanism
fails to clear the spurious IRQ.

This patch also implements ->sff_irq_check() for ata_piix.  Note that
this adds slight overhead to shared IRQ operation as IRQs which are
destined for other controllers will trigger extra register accesses to
check whether IDE interrupt is pending but this solves rare screaming
IRQ cases and for some curious reason also helps weird BIOS related
glitch on Samsung n130 as reported in bko#14314.

  http://bugzilla.kernel.org/show_bug.cgi?id=14314

* piix_base_ops dropped as suggested by Sergei.

* Spurious IRQ detection doesn't kick in anymore if polling qc is in
  progress.  This provides less protection but some controllers have
  possible data corruption issues if the wrong register is accessed
  while a command is in progress.
Signed-off-by: NTejun Heo <tj@kernel.org>
Reported-by: NJohannes Stezenbach <js@sig21.net>
Reported-by: NHans Werner <hwerner4@gmx.de>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

host->ports[i] is never NULL if i < host->n_ports and non-NULL return
from ata_qc_from_tag() guarantees that the returned qc is active.
Drop unnecessary tests.

Superflous () dropped as suggested by Sergei.
Signed-off-by: NTejun Heo <tj@kernel.org>
Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

Signed-off-by: NSeth Heasley <seth.heasley@intel.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

Signed-off-by: NSeth Heasley <seth.heasley@intel.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

Tested on AMD internal reference board.
Signed-off-by: NShane Huang <shane.huang@amd.com>
Acked-by: NTejun Heo <tj@kernel.org>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

HPT36x chips just don't have DPLL.
Signed-off-by: NSergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>