SCSI defines discard alignment as the offset to the first
optimal discard.  In the case of SD/MMC, that is always zero
which is the default.

SCSI defines discard granularity as a hint of a optimal
discard size.  That is much better expressed by the MMC
"preferred erase size" (pref_erase) field.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

For example, an eMMC with 2 boot partitions will have 3 threads.
The names change from:

   40 ?        00:00:00 mmcqd/0
   41 ?        00:00:00 mmcqd/0
   42 ?        00:00:00 mmcqd/0

to:

   40 ?        00:00:00 mmcqd/0
   41 ?        00:00:00 mmcqd/0boot0
   42 ?        00:00:00 mmcqd/0boot1
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Cc: Andrei Warkentin <andreiw@motorola.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

The erase timeout calculation may depend on clock rate
which is zero if the clock is gated, so use
mmc_host_clk_rate() which allows for that case.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

The MMC block driver and other drivers (e.g. mmc-test) will expect
the card to be switched to the User Data Area eMMC partition when
they start.  Hence the MMC block driver should ensure it is that
way when it is removed.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Cc: Andrei Warkentin <andreiw@motorola.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

mmc_sdio_power_restore() skips some steps that are performed in other
power-related codepaths which are necessary to fully reset the card.
Without this, runtime PM fails for SD8686 SDIO wifi on OLPC XO-1.5.
Signed-off-by: NDaniel Drake <dsd@laptop.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

HAVE_EFFICIENT_UNALIGNED_ACCESS is a config option, therefore it needs
the CONFIG_ before it when used by the preprocessor.
Signed-off-by: NJames Hogan <james@albanarts.com>
Acked-by: NMichał Mirosław <mirq-linux@rere.qmqm.pl>
Signed-off-by: NChris Ball <cjb@laptop.org>

Don't try to allocate DMA resources if the platform didn't specify
positive DMA slave IDs.
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NChris Ball <cjb@laptop.org>

Commit b6147490 ("mmc: tmio: split core functionality, DMA and
MFD glue") broke handling of the TMIO_MMC_WRPROTECT_DISABLE flag by
the tmio-mmc driver. This patch restores the original behaviour.
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: <stable@kernel.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

Don't use the returned sg_len from dma_map_sg() as inparameter
to dma_unmap_sg(). Use the original sg_len for both dma_map_sg
and dma_unmap_sg according to the documentation in DMA-API.txt.
Signed-off-by: NPer Forlin <per.forlin@linaro.org>
Reviewed-by: NVenkatraman S <svenkatr@ti.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

The OMAP HSMMC driver uses an ocr_mask to determine the list of voltages
supported by the card. It populates this mask based on the list of
voltages supported by the regulator that supplies the voltage.

Commit 64be9782 (omap4 hsmmc: Update ocr mask for MMC2 for regulator
to use) passed a fixed ocr_mask from the OMAP4 SDP board file to limit
the voltage to 2.9-3.0 Volts, and updated the driver to use this mask
if provided, instead of using the regulator's supported voltages.

However the commit is buggy - the ocr_mask is overridden by the
regulator's capabilities anyway. Fix this.

(The bug shows up when a system-wide suspend is attempted on the OMAP4
SDP/Blaze platforms. The eMMC card comes up at 3V, but drops to 1.65V
after the system resumes).
Signed-off-by: NAnand Gadiyar <gadiyar@ti.com>
Acked-by: NBalaji T K <balajitk@ti.com>
Acked-by: NVenkatraman S <svenkatr@ti.com>
Tested-by: NKishore Kadiyala <kishore.kadiyala@ti.com>
Signed-off-by: NSourav Poddar <sourav.poddar@ti.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

After commit e1866b33 "PM / Runtime: Rework runtime PM handling
during driver removal" was introduced, the driver core stopped
incrementing the runtime PM usage counter of the device during
the invocation of the ->remove() callback.

This indirectly broke SDIO's runtime PM path during driver removal,
because no one calls _put_sync() anymore after ->remove() completes.

This means that the power of runtime-PM-managed SDIO cards is kept
high after their driver is removed (even if it was powered down
beforehand).

Fix that by directly calling _put_sync() when the last usage
counter is downref'ed by the SDIO bus.
Reported-and-tested-by: NDaniel Drake <dsd@laptop.org>
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@enac.fr>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

while merging hid-stantum into hid-multitouch, I did not correctly copy/paste
the VIDs for those devices.  This patch fixes it.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@enac.fr>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

In case a device does not provide the feature "Maximum Contact Count",
or set it at 0, the maxcontacts field may be at 0 while calling
input_mt_init_slots.

This patch ensures that hid-multitouch will allways report
ABS_MT_SLOT and ABS_MT_TRACKING_ID to the user space.

This corrects a bug found with some Ilitek devices that has been
integrated in 3.0-rc0.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@enac.fr>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This patch enables support for Marvell IDE PATA controllers found on
Asus P8P67LE motherboard.

The formatting has been corrected and I also received a report from two
users of this motherboard that the patch works.
Signed-off-by: NPaweł Drewniak <czajernia@gmail.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

A voltage value of 0xff01 requires that the driver
look up the max voltage for the board based using the
atom SetVoltage command table.

Setting the proper voltage should fix stability on
some newer asics.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The field is encoded:
0 = 4 banks
1 = 8 banks
2 = 16 banks
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This patch fixes the following conversion specification warning for size_t

drivers/target/tcm_fc/tfc_io.c: In function ‘ft_queue_data_in’:
drivers/target/tcm_fc/tfc_io.c:209: warning: format ‘%x’ expects type ‘unsigned int’, but argument 5 has type ‘size_t’
Reported-by: NRandy Dunlap <randy.dunlap@oracle.com>
Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

There is a typo here, it should be an unlock instead of a lock.  The
original code will deadlock.
Signed-off-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

This patch fixes a bug in ft_send_tm() that was incorrectly calling
ft_get_lun_for_cmd() -> transport_get_lun_for_cmd(), instead of using
transport_get_lun_for_tmr() for the proper struct se_lun lookup
that was triggering an OOPs in the se_cmd->tmr_req failure path.

This patch fixes the issue by re-arranging the codepath where
transport_get_lun_for_tmr() is called after tmr request is allocated and
made it available as part of se_cmd.

It also drops the now unnecessary ft_get_lun_for_cmd() unpacking code, and
uses scsilun_to_int() directly ahead of transport_get_lun_for_cmd() and
transport_get_lun_for_tmr() usage.
Signed-off-by: NPatil, Kiran <kiran.patil@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NNicholas A. Bellinger <nab@linux-iscsi.org>

This patch fixes a number of cases in target core using an incorrectly

	if (strlen(foo) > SOME_MAX_SIZE)

As strlen() returns the number of characters in the string not counting
the NULL character at the end.  So if you do something like:

        char buf[10];

        if (strlen("0123456789") > 10)
                return -ETOOLONG;
        snprintf(buf, 10, "0123456789");
        printf("%s\n", buf);

then the last "9" gets chopped off and only "012345678" is printed.

Plus I threw in one small related cleanup.
Signed-off-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

In the original code, there were several places inside the
target_fabric_configfs_init() function that returned NULL on error
and one place the returned an ERR_PTR.  There are two places that
call this function and they only check for NULL returns; they don't
check for ERR_PTRs.  So I've changed the ERR_PTR so now the function
only returns NULL on error.
Signed-off-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

transport_init_session() and core_tmr_alloc_req() never return NULL,
they only return ERR_PTRs on error.

v2: Fix patch to return PTR_ERR(tl_nexus->se_sess) from Ankit Jain's
feedback.
Signed-off-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NAnkit Jain <jankit@suse.de>
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

This patch converts transport_deregister_session_configfs() to save/restore
spinlock IRQ state for struct se_node_acl->nacl_sess_lock access as tcm_qla2xxx
logic expects to call transport_deregister_session_configfs() code with
irq save already held for struct qla_hw_data.
Reported-by: NRoland Dreier <roland@purestorage.com>
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

This patch fixes two possible NULL pointer dereferences in target v4.0
code where se_tmr release path in core_tmr_release_req() can OOPs upon
transport_get_lun_for_tmr() failure by attempting to access se_device or
se_tmr->tmr_list without a valid member of se_device->tmr_list during
transport_free_se_cmd() release.  This patch moves the se_tmr->tmr_dev
pointer assignment in transport_get_lun_for_tmr() until after possible
-ENODEV failures during unpacked_lun lookup.

This addresses an OOPs originally reported with LIO v4.1 upstream on
.39 code here:

    TARGET_CORE[qla2xxx]: Detected NON_EXISTENT_LUN Access for 0x00000000
    BUG: unable to handle kernel NULL pointer dereference at 0000000000000550
    IP: [<ffffffff81035ec4>] __ticket_spin_trylock+0x4/0x20
    PGD 0
    Oops: 0000 [#1] SMP
    last sysfs file: /sys/devices/system/cpu/cpu23/cache/index2/shared_cpu_map
    CPU 1
    Modules linked in: netconsole target_core_pscsi target_core_file
tcm_qla2xxx target_core_iblock tcm_loop target_core_mod configfs
ipmi_devintf ipmi_si ipmi_msghandler serio_raw i7core_edac ioatdma dca
edac_core ps_bdrv ses enclosure usbhid usb_storage ahci qla2xxx hid
uas e1000e mpt2sas libahci mlx4_core scsi_transport_fc
scsi_transport_sas raid_class scsi_tgt [last unloaded: netconsole]

    Pid: 0, comm: kworker/0:0 Tainted: G        W   2.6.39+ #1 Xyratex Storage Server
    RIP: 0010:[<ffffffff81035ec4>] [<ffffffff81035ec4>]__ticket_spin_trylock+0x4/0x20
    RSP: 0018:ffff88063e803c08  EFLAGS: 00010286
    RAX: ffff880619ab45e0 RBX: 0000000000000550 RCX: 0000000000000000
    RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000550
    RBP: ffff88063e803c08 R08: 0000000000000002 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000568
    R13: 0000000000000001 R14: 0000000000000000 R15: ffff88060cd96a20
    FS:  0000000000000000(0000) GS:ffff88063e800000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
    CR2: 0000000000000550 CR3: 0000000001a03000 CR4: 00000000000006e0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    Process kworker/0:0 (pid: 0, threadinfo ffff880619ab8000, task ffff880619ab45e0)
    Stack:
     ffff88063e803c28 ffffffff812cf039 0000000000000550 0000000000000568
     ffff88063e803c58 ffffffff8157071e ffffffffa028a1dc ffff88060f7e4600
     0000000000000550 ffff880616961480 ffff88063e803c78 ffffffffa028a1dc
    Call Trace:
<IRQ>
     [<ffffffff812cf039>] do_raw_spin_trylock+0x19/0x50
     [<ffffffff8157071e>] _raw_spin_lock+0x3e/0x70
     [<ffffffffa028a1dc>] ? core_tmr_release_req+0x2c/0x60 [target_core_mod]
     [<ffffffffa028a1dc>] core_tmr_release_req+0x2c/0x60 [target_core_mod]
     [<ffffffffa028d0d2>] transport_free_se_cmd+0x22/0x50 [target_core_mod]
     [<ffffffffa028d120>] transport_release_cmd_to_pool+0x20/0x40 [target_core_mod]
     [<ffffffffa028e525>] transport_generic_free_cmd+0xa5/0xb0 [target_core_mod]
     [<ffffffffa0147cc4>] tcm_qla2xxx_handle_tmr+0xc4/0xd0 [tcm_qla2xxx]
     [<ffffffffa0191ba3>] __qla24xx_handle_abts+0xd3/0x150 [qla2xxx]
     [<ffffffffa0197651>] qla_tgt_response_pkt+0x171/0x520 [qla2xxx]
     [<ffffffffa0197a2d>] qla_tgt_response_pkt_all_vps+0x2d/0x220 [qla2xxx]
     [<ffffffffa0171dd3>] qla24xx_process_response_queue+0x1a3/0x670 [qla2xxx]
     [<ffffffffa0196281>] ? qla24xx_atio_pkt+0x81/0x120 [qla2xxx]
     [<ffffffffa0174025>] ? qla24xx_msix_default+0x45/0x2a0 [qla2xxx]
     [<ffffffffa0174198>] qla24xx_msix_default+0x1b8/0x2a0 [qla2xxx]
     [<ffffffff810dadb4>] handle_irq_event_percpu+0x54/0x210
     [<ffffffff810dafb8>] handle_irq_event+0x48/0x70
     [<ffffffff810dd5ee>] ? handle_edge_irq+0x1e/0x110
     [<ffffffff810dd647>] handle_edge_irq+0x77/0x110
     [<ffffffff8100d362>] handle_irq+0x22/0x40
     [<ffffffff8157b28d>] do_IRQ+0x5d/0xe0
     [<ffffffff81571413>] common_interrupt+0x13/0x13
<EOI>
     [<ffffffff813003f7>] ? intel_idle+0xd7/0x130
     [<ffffffff813003f0>] ? intel_idle+0xd0/0x130
     [<ffffffff8144832b>] cpuidle_idle_call+0xab/0x1c0
     [<ffffffff8100a26b>] cpu_idle+0xab/0xf0
     [<ffffffff81566c59>] start_secondary+0x1cb/0x1d2
Reported-by: NRoland Dreier <roland@purestorage.com>
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

Now that the generic code handles UIE mode irqs via periodic
alarm interrupts, no one calls the
rtc_class_ops->update_irq_enable() method anymore.

Further the rtc_class_ops doesn't have a update_irq_enable element
anymore, so this causes a build error.

This patch removes the driver hooks and implementations of
update_irq_enable and the associated setup.

[wsa: updated commit-message and removed update_irq_enable-function, too]
[jstultz: improve commit message, clarifying build issue]
Signed-off-by: NAlexey Charkov <alchark@gmail.com>
Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
Signed-off-by: NJohn Stultz <john.stultz@linaro.org>

On 16.06.2011 [08:28:39 -0500], Brian King wrote:
> On 06/16/2011 02:51 AM, Tejun Heo wrote:
> > On Wed, Jun 15, 2011 at 04:34:17PM -0700, Nishanth Aravamudan wrote:
> >>> That looks like the right thing to do. For ipr's usage of
> >>> libata, we don't have the concept of a port frozen state, so this flag
> >>> should really never get set. The alternate way to fix this would be to
> >>> only set ATA_PFLAG_FROZEN in ata_port_alloc if ap->ops->error_handler
> >>> is not NULL.
> >>
> >> It seemed like ipr is as you say, but I wasn't sure if it was
> >> appropriate to make the change above in the common libata-scis code or
> >> not. I don't want to break some other device on accident.
> >>
> >> Also, I tried your suggestion, but I don't think that can happen in
> >> ata_port_alloc? ata_port_alloc is allocated ap itself, and it seems like
> >> ap->ops typically gets set only after ata_port_alloc returns?
> >
> > Maybe we can test error_handler in ata_sas_port_start()?
>
> Good point. Since libsas is converted to the new eh now, we would need to have
> this test.

Commit 7b3a24c5 ("ahci: don't enable
port irq before handler is registered") caused a regression for CD-ROMs
attached to the IPR SATA bus on Power machines:

  ata_port_alloc: ENTER
  ata_port_probe: ata1: bus probe begin
  ata1.00: ata_dev_read_id: ENTER
  ata1.00: failed to IDENTIFY (I/O error, err_mask=0x40)
  ata1.00: ata_dev_read_id: ENTER
  ata1.00: failed to IDENTIFY (I/O error, err_mask=0x40)
  ata1.00: limiting speed to UDMA7:PIO5
  ata1.00: ata_dev_read_id: ENTER
  ata1.00: failed to IDENTIFY (I/O error, err_mask=0x40)
  ata1.00: disabled
  ata_port_probe: ata1: bus probe end
  scsi_alloc_sdev: Allocation failure during SCSI scanning, some SCSI devices might not be configured

The FROZEN flag added in that commit is only cleared by the new EH code,
which is not used by ipr. Clear this flag in the SAS code if we don't
support new EH.
Reported-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NNishanth Aravamudan <nacc@us.ibm.com>
Signed-off-by: NJeff Garzik <jgarzik@pobox.com>

regardless of firmware revision

It's unlikely NOSETXFER works for a revision of drive but doesn't for
another and pioneer doesn't seem to be fixing firmwares for the
affected drives.  Apply NOSETXFER to the affected pioneer drives
regardless of firmware revision.

  http://article.gmane.org/gmane.linux.ide/49734Signed-off-by: NTejun Heo <tj@kernel.org>
Reported-by: fl-00@gmx.de
Signed-off-by: NJeff Garzik <jgarzik@pobox.com>

The patch below fixes a typo.
Signed-off-by: NJustin P. Mattock <justinmattock@gmail.com>
Signed-off-by: NJeff Garzik <jgarzik@pobox.com>

The driver went to initialize its waitqueue at the start of the main
processing thread.  However, it is possible that this thread is not
scheduled on a CPU before the write function is called which leads to a
following error:

  BUG: spinlock bad magic on CPU#1, swapper/1
   lock: f5f3ebdc, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0
  Pid: 1, comm: swapper Not tainted 3.0.0-rc2+ #67
  Call Trace:
   [<c1289663>] spin_bug+0xa3/0xf0
   [<c12897ad>] do_raw_spin_lock+0x7d/0x150
   [<c14963de>] _raw_spin_lock_irqsave+0x4e/0x60
   [<c102f2bb>] __wake_up+0x1b/0x50
   [<c12d3715>] serial_m3110_con_write+0x55/0x60
   [<c1041575>] __call_console_drivers+0x75/0x90
   [<c10415d9>] _call_console_drivers+0x49/0x80
   [<c1041baa>] console_unlock+0xca/0x1f0
   [<c10420ef>] vprintk+0x18f/0x4f0
   [<c14928a3>] printk+0x18/0x1a
   [<c1042730>] register_console+0x2e0/0x350
   [<c12d098e>] uart_add_one_port+0x33e/0x3d0
   [<c1485ba6>] serial_m3110_probe+0x1c2/0x1df
   [<c1303db7>] spi_drv_probe+0x17/0x20
   ...

Fix this by initializing the waitqueue before the main thread is
created.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Change print message to notice instead of error to clean up non critical
messages showing on startup.  The MAX3111 not being present is a normal
path for end user systems.
Signed-off-by: NWilliam Douglas <william.douglas@intel.com>
[rebased on 3.0, switched to dev_dbg()]
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The lock must be held for the saving and restoring of VGA state.
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
CC: Alexander Zhaunerchyk <alex.vizor@gmail.com>
CC: Andrey Rahmatullin <wrar@wrar.name>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NKeith Packard <keithp@keithp.com>

After commit e8665002
(PM: Allow pm_runtime_suspend() to succeed during system suspend) it
is possible that a device resumed by the pm_runtime_resume(dev) in
pci_pm_prepare() will be suspended immediately from a work item,
timer function or otherwise, defeating the very purpose of calling
pm_runtime_resume(dev) from there.  To prevent that from happening
it is necessary to increment the runtime PM usage counter of the
device by replacing pm_runtime_resume() with pm_runtime_get_sync().
Moreover, the incremented runtime PM usage counter has to be
decremented by the corresponding pci_pm_complete(), via
pm_runtime_put_sync().
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Cc: stable@kernel.org
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Commit 85eb8c8d (PM / Runtime:
Generic clock manipulation rountines for runtime PM (v6)) converted
the shmobile platform to using generic code for runtime PM clock
management, but it changed the behavior for CONFIG_PM_RUNTIME unset
incorrectly.

Specifically, for CONFIG_PM_RUNTIME unset pm_runtime_clk_notify()
should enable clocks for action equal to BUS_NOTIFY_BIND_DRIVER and
it should disable them for action equal to BUS_NOTIFY_UNBOUND_DRIVER
(instead of BUS_NOTIFY_ADD_DEVICE and BUS_NOTIFY_DEL_DEVICE,
respectively).  Make this function behave as appropriate.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Acked-by: NMagnus Damm <damm@opensource.se>

The PM core doesn't handle suspend failures correctly when it comes to
asynchronously suspended devices.  These devices are moved onto the
dpm_suspended_list as soon as the corresponding async thread is
started up, and they remain on the list even if they fail to suspend
or the sleep transition is cancelled before they get suspended.  As a
result, when the PM core unwinds the transition, it tries to resume
the devices even though they were never suspended.

This patch (as1474) fixes the problem by adding a new "is_suspended"
flag to dev_pm_info.  Devices are resumed only if the flag is set.

[rjw:
 * Moved the dev->power.is_suspended check into device_resume(),
   because we need to complete dev->power.completion and clear
   dev->power.is_prepared too for devices whose
   dev->power.is_suspended flags are unset.
 * Fixed __device_suspend() to avoid setting dev->power.is_suspended
   if async_error is different from zero.]
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Cc: stable@kernel.org

This patch (as1473) renames the "in_suspend" field in struct
dev_pm_info to "is_prepared", in preparation for an upcoming change.
The new name is more descriptive of what the field really means.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Cc: stable@kernel.org

This reverts commit 4a684a41.
Userland has always been required to set the object's domain to GTT
before using it through a GTT mapping, it's not something that the
kernel is supposed to enforce.  (The pagefault support is so that we
can handle multiple mappings without userland having to pin across
them, not so that userland can use GTT after GPU domains without
telling the kernel).

Fixes 19.2% +/- 0.8% (n=6) performance regression in cairo-gl
firefox-talos-gfx on my T420 latop.
Signed-off-by: NKeith Packard <keithp@keithp.com>

...we need to apply exactly the same workaround for missing interrupts
from BSD as for the BLT ring, apparently.

See also commit 498e720b
(drm/i915: Fix gen6 (SNB) missed BLT ring interrupts).

Reported-and-tested-by: nkalkhof@web.de
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38529Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NKeith Packard <keithp@keithp.com>

This change got placed in the ironlake path instead of the 9xx path
during a recent code shuffle.
Signed-off-by: NKeith Packard <keithp@keithp.com>

0xff01 is not an actual voltage value, but a flag
for the driver.  If the power state as that value,
skip setting the voltage.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>