i915: Fix opregion notifications

opregion-based platforms will send ACPI video event 0x80 for a range of
notification types for legacy compatibility. This is interpreted as a
display switch event, which may not be appropriate in the circumstances.
When we receive such an event we should make sure that the platform is
genuinely requesting a display switch before passing that event through
to userspace.

Signed-off-by: Matthew Garrett <mjg@redhat.com>
Tested-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>

drm/i915: TVDAC_STATE_CHG does not indicate successful load-detect

Do not use this bit to indicate that load detection has completed,
instead just wait for vblank, at which point the load registers will
have been updated.

Signed-off-by: Keith Packard <keithp@keithp.com>
Tested-by: Yi Sun <yi.sun@intel.com>

drm/i915: Select correct pipe during TV detect

Signed-off-by: Keith Packard <keithp@keithp.com>
Tested-by: Yi Sun <yi.sun@intel.com>

Merge branch 'drm-intel-fixes' into drm-intel-next

drm/i915/ringbuffer: Idling requires waiting for the ring to be empty

...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"

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 path

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 i915 frame buffer compression by default

We'll try again with the new fixes. Prepare to see this reverted when
we get regression reports...

Signed-off-by: Keith Packard <keithp@keithp.com>

drm/i915: Share the common work of disabling active FBC before updating

Upon review, all path share the same dependencies for updating the
registers and so we can benefit from sharing the code and checking
early.

This removes the unsightly intel_wait_for_vblank() from the lowlevel
functions and upon further analysis the only path that will require a
wait is if we are performing an instantaneous transition between two
valid FBC configurations. The page-flip path itself will have disabled
FBC registers and will have waited for at least one vblank before
finishing the flip and attempting to re-enable FBC. This wait can be
accomplished simply by delaying the enable until after we are sure that
a vblank will have passed, which we are already doing to make sure that
the display is settled before enabling FBC.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>

drm/i915: Perform intel_enable_fbc() from a delayed task

In order to accommodate the requirements of re-enabling FBC after
page-flipping, but to avoid doing so and incurring the cost of a wait
for vblank in the middle of a page-flip sequence, we defer the actual
enablement by 50ms. If any request to disable FBC arrive within that
interval, the enablement is cancelled and we are saved from blocking on
the wait.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Keith Packard <keithp@keithp.com>

drm/i915: Disable FBC across page-flipping

Page-flipping updates the scanout address, nukes the FBC compressed
image and so forces an FBC update so that the displayed image remains
consistent. However, page-flipping does not update the FBC registers
themselves, which remain pointing to both the old address and the old
CPU fence. Future updates to the new front-buffer (scanout) are then
undetected!

This first approach to demonstrate the issue and highlight the fix,
simply disables FBC upon page-flip (a recompression will be forced on
every flip so FBC becomes immaterial) and then re-enables FBC in the
page-flip finish work function, so that the FBC registers are now
pointing to the new framebuffer and front-buffer rendering works once
more.

Ideally, we want to only re-enable FBC after page-flipping is complete,
as otherwise we are just wasting cycles and power (with needless
recompression) whilst the page-flipping application is still running.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=33487
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Keith Packard <keithp@keithp.com>

drm/i915: Set persistent-mode for ILK/SNB framebuffer compression

Persistent mode is intended for use with front-buffer rendering, such as
X, where it is necessary to detect writes to the scanout either by the
GPU or through the CPU's fence, and recompress the dirty regions on the
fly. (By comparison to the back-buffer rendering, the scanout is always
recompressed after a page-flip.)

References: https://bugs.freedesktop.org/show_bug.cgi?id=33487
References: https://bugs.freedesktop.org/show_bug.cgi?id=31742
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Keith Packard <keithp@keithp.com>

drm/i915: Use of a CPU fence is mandatory to update FBC regions upon CPU writes

...and this requirement is enforced by intel_update_fbc() so we can
remove the later check from g4x_enable_fbc() and ironlake_enable_fbc().

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Keith Packard <keithp@keithp.com>

drm/i915: Remove vestigial pitch from post-gen2 FBC control routines

The cfb_pitch was only used for 8xx_enable_fbc(), every later routine
was just overwriting the value with itself thanks to a copy'n'paste
error.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Keith Packard <keithp@keithp.com>

drm/i915: Replace direct calls to vfunc.disable_fbc with intel_disable_fbc()

...to ensure that any pending FBC enable tasklet is cancelled.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Keith Packard <keithp@keithp.com>

drm/i915: Only export the generic intel_disable_fbc() interface

As the enable/disable routines will be gain additional complexity in
future patches, it is necessary that all callers do not bypass the
generic interface by calling into the chipset routines directly. to do
this we make the chipset routines static, so there is no choice.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Keith Packard <keithp@keithp.com>

Merge branch 'drm-intel-fixes' into drm-intel-next

drm/i915: Enable GPU reset on Ivybridge.

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>

Merge branch 'drm-intel-fixes' into drm-intel-next

drm/i915/dp: manage sink power state if possible

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 code

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 DP

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 detecting

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 hotplug

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 values

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 failure

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>

drm/i915: use pipe bpp in DP link bandwidth calculation

Now that we track bpp on a per-pipe basis, we can use the actual value
rather than assuming 24bpp.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Keith Packard <keithp@keithp.com>

drm/i915: check for supported depth at fb init time

This will catch bad fb configs earlier.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Keith Packard <keithp@keithp.com>

drm: bpp and depth changes require full mode sets

To properly drive a framebuffer with a new depth or bpp, dither settings
and link bandwidth calculations may change, so make sure we go through a
full mode set in that case.

Reported-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Keith Packard <keithp@keithp.com>

drm/i915: use pipe bpp when setting HDMI bpc

The Intel HDMI encoder can support 8bpc or 12bpc.  Set the appropriate
value based on the pipe bpp when configuring the output.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Keith Packard <keithp@keithp.com>

drm/i915: use pipe bpp in DP link bandwidth calculations

The pipe may be driving various bpp values depending on the display
configuration, so take that into account when calculating link bandwidth
requirements.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Keith Packard <keithp@keithp.com>

drm/i915: split out plane update code

Updating the planes is device specific, so create a new display callback
and use it in pipe_set_base.  (In fact we could go even further, valid
display plane bits have changed with each generation, as has tiled
buffer handling.)

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Keith Packard <keithp@keithp.com>

drm/i915: split out Ironlake pipe bpp picking code

Figuring out which pipe bpp to use is a bit painful.  It depends on both
the encoder and display configuration attached to a pipe.  For instance,
to drive a 24bpp framebuffer out to an 18bpp panel, we need to use 6bpc
on the pipe but also enable dithering.  But driving that same
framebuffer to a DisplayPort output on another pipe means using 8bpc and
no dithering.

So split out and enhance the code to handle the various cases, returning
an appropriate pipe bpp as well as whether dithering should be enabled.

Save the resulting pipe bpp in the intel_crtc struct for use by encoders
in calculating bandwidth requirements (defaults to 24bpp on pre-ILK).

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Keith Packard <keithp@keithp.com>

drm/i915: set bpc for DP transcoder

This may not be the default value, so pull the bpc out of the pipe reg
and write it to the DP transcoder so proper dithering and signaling
occurs.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Keith Packard <keithp@keithp.com>

drm/i915: don't set transcoder bpc on CougarPoint

This prevents us from setting reserved or incorrect bits on CougarPoint.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Keith Packard <keithp@keithp.com>

drm/i915: don't set SDVO color range on ILK+

These bits are reserved on ILK+ (ILK+ provides this feature in the
transcoder and pipe configuration instead, which we already set).

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Keith Packard <keithp@keithp.com>

Linux 3.0-rc6

Merge git://git./linux/kernel/git/jejb/scsi-rc-fixes-2.6

* git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6: (277 commits)
  [SCSI] isci: fix checkpatch errors
  isci: Device reset should request sas_phy_reset(phy, true)
  isci: pare back error messsages
  isci: cleanup silicon revision detection
  isci: merge scu_unsolicited_frame.h into unsolicited_frame_control.h
  isci: merge sata.[ch] into request.c
  isci: kill 'get/set' macros
  isci: retire scic_sds_ and scic_ prefixes
  isci: unify isci_host and scic_sds_controller
  isci: unify isci_remote_device and scic_sds_remote_device
  isci: unify isci_port and scic_sds_port
  isci: fix scic_sds_remote_device_terminate_requests
  isci: unify isci_phy and scic_sds_phy
  isci: unify isci_request and scic_sds_request
  isci: rename / clean up scic_sds_stp_request
  isci: preallocate requests
  isci: combine request flags
  isci: unify can_queue tracking on the tci_pool, uplevel tag assignment
  isci: Terminate dev requests on FIS err bit rx in NCQ
  isci: fix frame received locking
  ...

Merge branch 'at91/fixes' of git://git./linux/kernel/git/arm/linux-2.6-arm-soc

* 'at91/fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/linux-2.6-arm-soc:
  AT91: Change nand buswidth logic to match hardware default configuration
  at91: Use "pclk" as con_id on at91cap9 and at91rm9200
  at91: fix udc, ehci and mmc clock device name for cap9/9g45/9rl
  atmel_serial: fix internal port num
  at91: fix at91_set_serial_console: use platform device id

Merge branch 'fbdev-fixes-for-linus' of git://git./linux/kernel/git/lethal/fbdev-3.x

* 'fbdev-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/lethal/fbdev-3.x:
  vesafb: fix memory leak
  fbdev: amba: Link fb device to its parent
  fsl-diu-fb: remove check for pixel clock ranges
  udlfb: Correct sub-optimal resolution selection.
  hecubafb: add module_put on error path in hecubafb_probe()
  sm501fb: fix section mismatch warning
  gx1fb: Fix section mismatch warnings
  fbdev: sh_mobile_meram: Correct pointer check for YCbCr chroma plane

RDMA: Check for NULL mode in .devnode methods

Commits 71c29bd5c235 ("IB/uverbs: Add devnode method to set path/mode")
and c3af0980ce01 ("IB: Add devnode methods to cm_class and umad_class")
added devnode methods that set the mode.

However, these methods don't check for a NULL mode, and so we get a
crash when unloading modules because devtmpfs_delete_node() calls
device_get_devnode() with mode == NULL.

Add the missing checks.

Signed-off-by: Goldwyn Rodrigues <rgoldwyn@suse.de>
[ Also fix cm.c.  - Roland ]
Signed-off-by: Roland Dreier <roland@purestorage.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

AT91: Change nand buswidth logic to match hardware default configuration

The recently modified nand buswitth configuration is not aligned with
board reality: the double footprint on boards is always populated with 8bits
buswidth nand flashes.
So we have to consider that without particular configuration the 8bits
buswidth is selected by default.
Moreover, the previous logic was always using !board_have_nand_8bit(), we
change it to a simpler: board_have_nand_16bit().

Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Tested-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

vesafb: fix memory leak

When releasing framebuffer, free colourmap allocations.

Signed-off-by: Daniel J Blueman <daniel.blueman@gmail.com>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>

Merge branch 'pm-fixes' of git://git./linux/kernel/git/rafael/suspend-2.6

* 'pm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/suspend-2.6:
  PM / Runtime: Update documentation regarding driver removal
  PM: Documentation: fix typo: pm_runtime_idle_sync() doesn't exist.

[SCSI] isci: fix checkpatch errors

Signed-off-by: James Bottomley <JBottomley@Parallels.com>

Merge git://git./linux/kernel/git/djbw/isci

Merge git://git./linux/kernel/git/sfrench/cifs-2.6

* git://git.kernel.org/pub/scm/linux/kernel/git/sfrench/cifs-2.6:
  cifs: set socket send and receive timeouts before attempting connect

Merge branch 'hwmon-for-linus' of git://git./linux/kernel/git/jdelvare/staging

* 'hwmon-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jdelvare/staging:
  hwmon: (k10temp) Update documentation for Fam12h
  hwmon-vid: Fix typo in VIA CPU name
  hwmon: (f71882fg) Add support for the F71869A
  hwmon: Use <> rather than () around my e-mail address
  hwmon: (emc6w201) Properly handle all errors

hwmon: (k10temp) Update documentation for Fam12h

Add some CPU series IDs and links to the Fam12h datasheets.

Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Jean Delvare <khali@linux-fr.org>

hwmon-vid: Fix typo in VIA CPU name

It's Nehemiah, not Nemiah.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Guenter Roeck <guenter.roeck@ericsson.com>

hwmon: (f71882fg) Add support for the F71869A

The F71869A is almost the same as the F71869F/E, except that it has
the normal number of temp and pwm zones for a F71882FG derived chip,
rather then the limited number of the F71869F/E.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Tested-by: Max Baldwin <archerseven@gmail.com>
Acked-by: Guenter Roeck <guenter.roeck@ericsson.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>

hwmon: Use <> rather than () around my e-mail address

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>

hwmon: (emc6w201) Properly handle all errors

Handle errors on 8-bit register reads and writes too. Also use likely
and unlikely to make the functions faster on success.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Guenter Roeck <guenter.roeck@ericsson.com>

isci: Device reset should request sas_phy_reset(phy, true)

The hard_reset parameter passed to the LLDD in the direct-attached
phy control case allows the LLDD to filter link failure events
while the direct-attached device reset is executing.

Signed-off-by: Jeff Skirvin <jeffrey.d.skirvin@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>

isci: pare back error messsages

The messages emitted from task.c and some from request.c likely
duplicate (in a less undertandable way) what is reported by the
midlayer.

Signed-off-by: Dan Williams <dan.j.williams@intel.com>

isci: cleanup silicon revision detection

Perform checking per-pci device (even though all systems will only have
1 pci device in this generation), and delete support for silicon that
does not report a proper revision (i.e. A0).

Reported-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>

isci: merge scu_unsolicited_frame.h into unsolicited_frame_control.h

Does not need its own file.

Signed-off-by: Dan Williams <dan.j.williams@intel.com>

isci: merge sata.[ch] into request.c

Undo some needless separation.

Signed-off-by: Dan Williams <dan.j.williams@intel.com>

isci: kill 'get/set' macros

Most of these simple dereference macros are longer than their open coded
equivalent.  Deleting enum sci_controller_mode is thrown in for good
measure.

Reported-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>

isci: retire scic_sds_ and scic_ prefixes

The distinction between scic_sds_ scic_ and sci_ are no longer relevant
so just unify the prefixes on sci_.  The distinction between isci_ and
sci_ is historically significant, and useful for comparing the old
'core' to the current Linux driver. 'sci_' represents the former core as
well as the routines that are closer to the hardware and protocol than
their 'isci_' brethren. sci == sas controller interface.

Also unwind the 'sds1' out of the parameter structs.

Reported-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>

isci: unify isci_host and scic_sds_controller

Remove the distinction between these two implementations and unify on
isci_host (local instances named ihost).  Hmmm, we had two
'oem_parameters' instances, one was unused... nice.

Reported-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>

isci: unify isci_remote_device and scic_sds_remote_device

Remove the distinction between these two implementations and unify on
isci_remote_device (local instances named idev).

Reported-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>

isci: unify isci_port and scic_sds_port

Remove the distinction between these two implementations and unify on
isci_port (local instances named iport).  The duplicate '->owning_port' and
'->isci_port' in both isci_phy and isci_remote_device will be fixed in a later
patch... this is just the straightforward rename/unification.

Reported-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>

isci: fix scic_sds_remote_device_terminate_requests

Commit 0815632 "isci: unify remote_device stop_handlers" introduced the
possibility that not all requests get terminated if we reach the
request_count.  Now that we properly reference count devices we don't
need this self-defense and can do the straightforward scan of all active
requests.

Reported-by: Jeff Skirvin <jeffrey.d.skirvin@intel.com>
Acked-by: Jeff Skirvin <jeffrey.d.skirvin@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>

isci: unify isci_phy and scic_sds_phy

They are one in the same object so remove the distinction.  The near
duplicate fields (owning_port, and isci_port) will be cleaned up
after the scic_sds_port isci_port unification.

Reported-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>

isci: unify isci_request and scic_sds_request

They are one in the same object so remove the distinction.  The near
duplicate fields (owning_controller, and isci_host) will be cleaned up
after the scic_sds_contoller isci_host unification.

Reported-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>

isci: rename / clean up scic_sds_stp_request

* Rename scic_sds_stp_request to isci_stp_request
* Remove the unused fields and union indirection

Reported-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>

isci: preallocate requests

the dma_pool interface is optimized for object_size << page_size which
is not the case with isci_request objects and the dma_pool routines show
up in the top of the profile.

The old io_request_table which tracked whether tci slots were in-flight
or not is replaced with an IREQ_ACTIVE flag per request.

Signed-off-by: Dan Williams <dan.j.williams@intel.com>

isci: combine request flags

Combine three bools into one unsigned long 'flags'.  Doesn't increase the
request size due to packing. (to do: optimize the structure layout).

Signed-off-by: Dan Williams <dan.j.williams@intel.com>

isci: unify can_queue tracking on the tci_pool, uplevel tag assignment

The tci_pool tracks our outstanding command slots which are also the 'index'
portion of our tags.  Grabbing the tag early in ->lldd_execute_task let's us
drop the isci_host_can_queue() and ->was_tag_assigned_by_user infrastructure.
->was_tag_assigned_by_user required the task context to be duplicated in
request-local buffer.  With the tci established early we can build the
task_context directly into its final location and skip a memcpy.

With the task context buffer at a known address at request construction we
have the opportunity/obligation to also fix sgl handling.  This rework feels
like it belongs in another patch but the sgl handling and task_context are too
intertwined.
1/ fix the 'ab' pair embedded in the task context to point to the 'cd' pair in
   the task context (previously we were prematurely linking to the staging
   buffer).
2/ fix the broken iteration of pio sgls that assumes all sgls are relative to
   the request, and does a dangerous looking reverse lookup of physical
   address to virtual address.

Signed-off-by: Dan Williams <dan.j.williams@intel.com>

isci: Terminate dev requests on FIS err bit rx in NCQ

When the remote device transitions to a not-ready state because of
an NCQ error condition, all outstanding requests to that device
are terminated and completed to libsas on the normal path.  The
device then waits for a READ LOG EXT command to issue on the task
management path.

Signed-off-by: Jeff Skirvin <jeffrey.d.skirvin@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>

isci: fix frame received locking

Updates to the frame_rcvd before need to be atomic with respect to when
they are evaluated by libsas.

Signed-off-by: Dan Williams <dan.j.williams@intel.com>

isci: possible buffer overflow in isci_parse_oem_parameters fixed

scu_index is a parameter of isci_parse_eom_parameters and is an index
in controller table. There is a check: scu_index > SCI_MAX_CONTROLLERS
which is insufficient and should be: scu_index >= SCI_MAX_CONTROLLERS.
scu_index is used as an index in the table which size is
SCI_MAX_CONTROLLERS.

Signed-off-by: Maciej Patelczyk <maciej.patelczyk@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>

isci: fix isci_task_execute_tmf completion

1/ fix the timeout for wait_for_completion_timeout
2/ In the tmf timeout case we need to wait for our termination callback
3/ Once the request is successfully started it will be freed according to the
   normal lifetime for requests.

Signed-off-by: Dan Williams <dan.j.williams@intel.com>

isci: fix support for arbitrarily large smp requests

Instead of duplicating the smp request buffer reuse the one provided by
libsas.  This future proofs the driver to support arbitrarily large smp
requests, and shrinks the request structure size by ~700 bytes.

Signed-off-by: Dan Williams <dan.j.williams@intel.com>

isci: fix dma_unmap_sg usage

One bug and a cleanup:
1/ Fix cases where we were unmapping invalid addresses (smp requests were
   being unmapped)

[  604.662770] ------------[ cut here ]------------
[  604.668026] WARNING: at lib/dma-debug.c:800 check_unmap+0x418/0x740()
[  604.675315] Hardware name: SandyBridge Platform
[  604.680465] isci 0000:03:00.0: DMA-API: device driver tries to free an invalid DMA memory address

2/ The unmap routine is too large to be an inline function, and
   isci_request_io_request_get_next_sge is unused.

Signed-off-by: Dan Williams <dan.j.williams@intel.com>

isci: fix smp response frame overrun

Due to a typo we currently copy way too much when copying over the
response data, but since a request is likely backed by a full page
allocation we don't corrupt live data.

Signed-off-by: Dan Williams <dan.j.williams@intel.com>

isci: kill device_sequence

Now that we have upleveled device reassignment protection to the
isci_remote_device reference count we no longer need this level of
self-defense.

Signed-off-by: Dan Williams <dan.j.williams@intel.com>

isci: kill isci_remote_device_change_state()

Now that "stopping/stopped" are one in the same and signalled by a NULL device
pointer the rest of the device status infrastructure can be removed (->status
and ->state_lock).  The "not ready for i/o state" is replaced with a state
flag, and is evaluated under scic_lock so that we don't see transients from
taking the device reference to submitting the i/o.

This also fixes a potential leakage of can_queue slots in the rare case that
SAS_TASK_ABORTED is set at submission.

Signed-off-by: Dan Williams <dan.j.williams@intel.com>

isci: atomic device lookup and reference counting

We have unsafe references to remote devices that are notified to
disappear at lldd_dev_gone.  In order to clean this up we need a single
canonical source for device lookups and stable references once a lookup
succeeds.  Towards that end guarantee that domain_device.lldd_dev is
NULL as soon as we start the process of stopping a device.  Any code
path that wants to safely lookup a remote device must do so through
task->dev->lldd_dev (isci_lookup_device()).

For in-flight references outside of scic_lock we need reference counting
to ensure that the device is not recycled before we are done with it.
Simplify device back references to just scic_sds_request.target_device
which is now the only permissible internal reference that is maintained
relative to the reference count.

There were two occasions where we wanted new i/o's to be treated as
SAS_TASK_UNDELIVERED but where the domain_dev->lldd_dev link is still
intact.  Introduce a 'gone' flag to prevent i/o while waiting for libsas
to take action on the port down event.

One 'core' leftover is that we currently call
scic_remote_device_destruct() from isci_remote_device_deconstruct()
which is called when the 'core' says the device is stopped.  It would be
more natural for the final put to trigger
isci_remote_device_deconstruct() but this implementation is deferred as
it requires other changes.

Signed-off-by: Dan Williams <dan.j.williams@intel.com>

isci: fix ssp response iu buffer size in isci_tmf

In isci_task_request_complete() we save the response/sense data from the
command.  Make sure isci_tmf has enough space to hold the full response.

[ it does not look like we actually use this data, and
  response_data_len/sense_data_len should be specifying the byte count,
  in any event do the simple fix first so we don't corrupt memory ]

Reported-by: Adam Gruchala <adam.gruchala@intel.com>
Tested-by: Edmund Nadolski <edmund.nadolski@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>

isci: cleanup request allocation

Rather than return an error code and update a pointer that was passed by
reference just return the request object directly (or null if allocation
failed).

Signed-off-by: Dan Williams <dan.j.williams@intel.com>

isci: cleanup/optimize queue increment macros

Every single i/o or event completion incurs a test and branch to see if
the cycle bit changed.  For power-of-2 queue sizes the cycle bit can be
read directly from the rollover of the queue pointer.

Likely premature optimization, but the hidden if() and hidden
assignments / side-effects in the macros were already asking to be
cleaned up.

Signed-off-by: Dan Williams <dan.j.williams@intel.com>

isci: cleanup tag macros

A tag is a 16 bit number where the upper four bits is a sequence number
and the remainder is the task context index (tci).  Sanitize the macro
names and shave 256-bytes out of scic_sds_controller by reducing the size of
io_request_sequence.

scic_sds_io_tag_construct --> ISCI_TAG
scic_sds_io_tag_get_sequence --> ISCI_TAG_SEQ
scic_sds_io_tag_get_index() --> ISCI_TAG_TCI
scic_sds_io_sequence_increment() [delete / open code]

Signed-off-by: Dan Williams <dan.j.williams@intel.com>

isci: cleanup/optimize pool implementation

The circ_buf macros are ~6% faster, as measured by perf, because they take
advantage of power-of-two math assumptions i.e. no test and branch for
rollover. Their semantics are clearer than the hidden side effects in pool.h
(like sci_pool_get() which hides an assignment).

Signed-off-by: Dan Williams <dan.j.williams@intel.com>

isci: Disable link layer hang detection

Some targets exceed the hang detect timer.  Use the OS timeout to
catch hung tasks.

Signed-off-by: Jeff Skirvin <jeffrey.d.skirvin@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>

isci: Hard reset failure will link reset all phys in the port

In the case where the hard reset process fails, each link in
the port is put through a link reset sequence.

Signed-off-by: Jeff Skirvin <jeffrey.d.skirvin@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>

isci: Explicitly decode remote node ready and suspended states

The remote node context should only signal a device reset condition
in a suspended state.

Signed-off-by: Jeff Skirvin <jeffrey.d.skirvin@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>

isci: fix isci_terminate_pending() list management

Walk through the list of pending requests being careful to consider that
multiple requests can be terminated when the lock is dropped (i.e.
invalidating the 'next' reference established by
list_for_each_entry_safe).

Also noticed that all callers to isci_terminate_pending_requests()
specifying terminating, so just drop the parameter.

Signed-off-by: Dan Williams <dan.j.williams@intel.com>

isci: Handle timed-out request terminations correctly

In the situation where a termination of an I/O times-out,
make sure that the linkage from the request to the task
is severed completely.  Also make sure that the selection
of tasks to terminate occurs under scic_lock.

Signed-off-by: Jeff Skirvin <jeffrey.d.skirvin@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>

isci: Requests that do not start must be set to "complete"

Requests that fail at start because of a reset pending condition
must be set to complete in order to allow for later cleanup.

Signed-off-by: Jeff Skirvin <jeffrey.d.skirvin@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>

isci: Add decode for SMP request retry error condition

There are situations with slow expanders in which a first attempt
to execute an SMP request will fail with a timeout.  Immediate
subsequent retries will generally succeed.  This change makes sure
SMP I/O failures are immediately failed to libsas so that retries
happen with no discovery process timeout delay.

Signed-off-by: Jeff Skirvin <jeffrey.d.skirvin@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>

isci: filter broadcast change notifications during SMP phy resets

When resetting a sata device in the domain we have seen occasions where
libsas prematurely marks a device gone in the time it takes for the
device to re-establish the link.  This plays badly with software raid
arrays.  Other libsas drivers have non-uniform delays in their reset
handlers to try to cover this condition, but not sufficient to close the
hole.  Given that a sata device can take many seconds to recover we
filter bcns and poll for the device reattach state before notifying
libsas that the port needs the domain to be rediscovered.  Once this has
been proven out at the lldd level we can think about uplevelling this
feature to a common implementation in libsas.

Signed-off-by: Jeff Skirvin <jeffrey.d.skirvin@intel.com>
[ use kzalloc instead of kmem_cache ]
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
[ use eventq and time macros ]
Signed-off-by: Dan Williams <dan.j.williams@intel.com>

isci: Move the reset delay after the remote node resumption.

Delay after bringing up the RNC to allow for resumption latency.

Signed-off-by: Jeff Skirvin <jeffrey.d.skirvin@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>

isci: remove 'min memory' infrastructure

The old 'core' had aspirations of running in severely memory constrained
environments like bios option-rom, it's not needed for Linux and gets in
the way of other cleanups (like unifying/reducing the number of structure
members in scic_sds_controller/isci_host).

This also fixes a theoretical bug in that the driver would blindly override
the silicon advertised limits for number of ports, task contexts, and remote
node contexts.

Signed-off-by: Dan Williams <dan.j.williams@intel.com>

isci: Added support for C0 to SCU Driver

C0 silicon updates the pci revision id and requires new AFE parameters
for phy signal integrity.  Support for previous silicon revisions is
deprecated (it's also broken for the theoretical case of multiple
controllers at different silicon revisions, all the more reason to get
it removed as soon as possible)

Signed-off-by: Adam Gruchala <adam.gruchala@intel.com>
[fixed up deprecated silicon support]
Signed-off-by: Dan Williams <dan.j.williams@intel.com>

isci: additional state machine cleanup

Additional state machine cleanups:

 o Remove static functions sci_state_machine_exit_state() and
   sci_state_machine_enter_state()
 o Combines sci_base_state_machine_construct() and
   sci_base_state_machine_start() into a single function,
   sci_init_sm()
 o Remove sci_base_state_machine_stop() which is unused.
 o Kill state_machine.[ch]

Signed-off-by: Edmund Nadolski <edmund.nadolski@intel.com>
[fixed too large to inline functions]
Signed-off-by: Dan Williams <dan.j.williams@intel.com>

isci: state machine cleanup

This cleans up several areas of the state machine mechanism:

 o Rename sci_base_state_machine_change_state to sci_change_state
 o Remove sci_base_state_machine_get_state function
 o Rename 'state_machine' struct member to 'sm' in client structs
 o Shorten the name of request states
 o Shorten state machine state names as follows:
        SCI_BASE_CONTROLLER_STATE_xxx to SCIC_xxx
        SCI_BASE_PHY_STATE_xxx to SCI_PHY_xxx
        SCIC_SDS_PHY_STARTING_SUBSTATE_xxx to SCI_PHY_SUB_xxx
        SCI_BASE_PORT_STATE_xxx to SCI_PORT_xxx and
        SCIC_SDS_PORT_READY_SUBSTATE_xxx to SCI_PORT_SUB_xxx
        SCI_BASE_REMOTE_DEVICE_STATE_xxx to SCI_DEV_xxx
        SCIC_SDS_STP_REMOTE_DEVICE_READY_SUBSTATE_xxx to SCI_STP_DEV_xxx
        SCIC_SDS_SMP_REMOTE_DEVICE_READY_SUBSTATE_xxx to SCI_SMP_DEV_xxx
        SCIC_SDS_REMOTE_NODE_CONTEXT_xxx_STATE to SCI_RNC_xxx

Signed-off-by: Edmund Nadolski <edmund.nadolski@intel.com>
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>

isci: Removing unused variables compiler warnings

Newer gcc's are better at identifying "set, but not used" variables.

Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>

isci: Retrieve the EFI variable for OEM parameter

We can call the EFI get_variable service routine directly to retrieve
the EFI variable that holds the OEM parameters table.

Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>