Both the suspend and resume functions incorrectly set psbfb =
to_psb_fb(NULL) outside of the loop over all of the framebuffers. Fix
this by moving the assignment of psbfb inside the loop and removing the
initialisation of fb.
Signed-off-by: NRyan Mallon <rmallon@gmail.com>
Acked-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

this patch separates fimd specific power on/off function from pm function
and the pm interfaces will call that function for power on or off.
and also removes unnecessary codes of resume function.
Signed-off-by: NInki Dae <inki.dae@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>

FB based FIMD and DRM based FIMD drivers use same hardware
so with this patch, only one of them would be selected.
Signed-off-by: NInki Dae <inki.dae@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>

DRM_EXYNOS_HDMI driver and VIDEO_SAMSUNG_S5P_TV driver should be
not enabled at once because they use same HW blocks. So dependency
for DRM_EXYNOS_HDMI is fixed to check VIDEO_SAMSUNG_S5P_TV=n.
Signed-off-by: NSeung-Woo Kim <sw0312.kim@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>

To make a api pair of request_mem_region and release_mem_region,
release_mem_region is used instead of release_resource.
Signed-off-by: NSeung-Woo Kim <sw0312.kim@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>

In error cleanup of agp_backend_initialize() and in agp_backend_cleanup(),
agp_destroy_page() is passed virtual address of the scratch page. This
leads to a kernel warning if the initialization fails (or upon regular
cleanup) as pointer to struct page should be passed instead.
Signed-off-by: NMichal Kubecek <mkubecek@suse.cz>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Both changes in dc97b340 cause serious
regressions in the nouveau driver.

move_notify() was originally able to presume that bo->mem is the old node,
and new_mem is the new node.  The above commit moves the call to
move_notify() to after move() has been done, which means that now, sometimes,
new_mem isn't the new node at all, bo->mem is, and new_mem points at a
stale, possibly-just-been-killed-by-move node.

This is clearly not a good situation.  This patch reverts this change, and
replaces it with a cleanup in the move() failure path instead.

The second issue is that the call to move_notify() from cleanup_memtype_use()
causes the TTM ghost objects to get passed into the driver.  This is clearly
bad as the driver knows nothing about these "fake" TTM BOs, and ends up
accessing uninitialised memory.

I worked around this in nouveau's move_notify() hook by ensuring the BO
destructor was nouveau's.  I don't particularly like this solution, and
would rather TTM never pass the driver these objects.  However, I don't
clearly understand the reason why we're calling move_notify() here anyway
and am happy to work around the problem in nouveau instead of breaking the
behaviour expected by other drivers.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>
Cc: Jerome Glisse <j.glisse@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

My forcewake spinlock patches have a functional conflict with Ben
Widawsky's gen6 drpc support for debugfs. Result was a benign warning
about trying to read an non-atomic variabla with atomic_read.

Note that the entire check is racy anyway and purely informational.
Also update it to reflect the forcewake voodoo changes, the kernel can
now also hold onto a forcewake reference for longer times.
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NKeith Packard <keithp@keithp.com>

If GPU lockup is detected in ib_pool get we are holding the ib_pool
mutex that will be needed by the GPU reset code. As ib_pool code is
safe to be reentrant from GPU reset code we should not block if we
are trying to get the ib pool lock on the behalf of the same userspace
caller, thus use the radeon_mutex_lock helper.
Signed-off-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Silence out the lock dependency warning by moving bo allocation out
of ib mutex protected section. Might lead to useless temporary
allocation but it's not harmful as such things only happen at
initialization.
Signed-off-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

If the master tries to authenticate a client using drm_authmagic and
that client has already closed its drm file descriptor,
either wilfully or because it was terminated, the
call to drm_authmagic will dereference a stale pointer into kmalloc'ed memory
and corrupt it.

Typically this results in a hard system hang.

This patch fixes that problem by removing any authentication tokens
(struct drm_magic_entry) open for a file descriptor when that file
descriptor is closed.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

Corresponding changes to improve our error_state are pending
some other patches to clean up things first.
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Reviewed-by: NKeith Packard <keithp@keithp.com>
Signed-off-by: NKeith Packard <keithp@keithp.com>

We need this to correctly access registers in the gt power well from
userspace.
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Reviewed-by: NKeith Packard <keithp@keithp.com>
Signed-off-by: NKeith Packard <keithp@keithp.com>

Signed-off-by: NEric Anholt <eric@anholt.net>
Cc: stable@vger.kernel.org
Reviewed-by: NKeith Packard <keithp@keithp.com>
Reviewed-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Reviewed-by: NKenneth Graunke <kenneth@whitecape.org>
Signed-off-by: NKeith Packard <keithp@keithp.com>

We had two things in a row claiming to be RC6.
Signed-off-by: NEric Anholt <eric@anholt.net>
Reviewed-by: NKeith Packard <keithp@keithp.com>
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
Reviewed-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Reviewed-by: NKenneth Graunke <kenneth@whitecape.org>
Signed-off-by: NKeith Packard <keithp@keithp.com>

This patch changes event message behaviour to send only updated records
instead of whole list. This fixes bug on which userspace receives non-actual
data in case multiple events occur in row.
Signed-off-by: NJiri Pirko <jpirko@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

do_set_multicast() may not free the memory malloc in
netvsc_set_multicast_list().
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: NHaiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

An implicit instance of module.h leaked back into existence
and was masking the fact that these drivers weren't calling
out the include for itself.  Fix the drivers before we remove
the implicit include path via net/netprio_cgroup.h file.
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

STM has a device ID within its own VENDOR space, and it is being
used in the STA2X11 I/O Hub.
Signed-off-by: NAlessandro Rubini <rubini@gnudd.com>
Acked-by: NGiancarlo Asnaghi <giancarlo.asnaghi@st.com>
Acked-by: NGiuseppe Cavallaro <peppe.cavallaro@st.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

After commit "db8857bf stmmac: use an unique MDIO bus name" my
device stopped being probed because two different names were being
used in different places. This fixes the inconsistency.
Signed-off-by: NAlessandro Rubini <rubini@gnudd.com>
Acked-by: NGiancarlo Asnaghi <giancarlo.asnaghi@st.com>
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Florian Fainelli <florian@openwrt.org>
Acked-by: NFlorian Fainelli <florian@openwrt.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Commit 5bc75a88 ("kernel-doc: fix new warning in regulator core")
added documentation for of_node to address a warning but the
documentation didn't explain what the parameter is for so would be
likely to be unhelpful for users.  Clarify that.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

GMA500 did it the old way and it's been on the TODO list to fix.
Current kernels now blow up if we use the old way so we'd better
do the work!
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

GMA500 did it the old way and it's been on the TODO list to fix. Current kernels
now blow up if we use the old way so we'd better do the work !
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

HDMI 1.3 defines single link clocks up to 340 Mhz.
Refine the current dual link checks to only enable
dual link for DVI > 165 Mhz or HDMI > 340 Mhz if the
hw supports HDMI 1.3 (DCE3+).

Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=44755Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

We were previously just checking for audio.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

dig transmitter control table only has ENABLE/DISABLE actions
on DCE4.1/DCE5.

Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=44955Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

Needs to happen earlier in the mode set.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

We really only need to set it up once on init or resume
rather than on every mode set.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Return a number of bytes read in radeon_atrm_get_bios_chunk() and
properly check this value in radeon_atrm_get_bios().
If radeon_atrm_get_bios_chunk() read less bytes then were requested,
it means that it finished reading bios data.

Prior to this patch, condition in radeon_atrm_get_bios() was always
equivalent to "if (ATRM_BIOS_PAGE <= 0)", so it was always false,
thus radeon_atrm_get_bios() was trying to read past the bios data
wasting boot time.

On my lenovo ideapad u455 laptop this patch drops bios reading time
from ~5.5s to ~1.5s.
Signed-off-by: NIgor Murzov <e-mail@date.by>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

At a boot time I observed following bug:

 BUG: unable to handle kernel paging request at ffff8800a4244000
 IP: [<ffffffff81275b5b>] memcpy+0xb/0x120
 PGD 1816063 PUD 1fe7d067 PMD 1ff9f067 PTE 80000000a4244160
 Oops: 0000 [#1] SMP DEBUG_PAGEALLOC
 CPU 0
 Modules linked in: btusb bluetooth brcmsmac brcmutil crc8 cordic b43 radeon(+)
  mac80211 cfg80211 ttm ohci_hcd drm_kms_helper rfkill drm ssb agpgart mmc_core
  sp5100_tco video battery ac thermal processor rtc_cmos thermal_sys snd_hda_codec_hdmi
  joydev snd_hda_codec_conexant button bcma pcmcia snd_hda_intel snd_hda_codec
  snd_hwdep snd_pcm shpchp pcmcia_core k8temp snd_timer atl1c snd psmouse hwmon
  i2c_piix4 i2c_algo_bit soundcore evdev i2c_core ehci_hcd sg serio_raw snd_page_alloc
  loop btrfs

 Pid: 1008, comm: modprobe Not tainted 3.3.0-rc1 #21 LENOVO 20046                           /AMD CRB
 RIP: 0010:[<ffffffff81275b5b>]  [<ffffffff81275b5b>] memcpy+0xb/0x120
 RSP: 0018:ffff8800aa72db00  EFLAGS: 00010246
 RAX: ffff8800a4150000 RBX: 0000000000001000 RCX: 0000000000000087
 RDX: 0000000000000000 RSI: ffff8800a4244000 RDI: ffff8800a4150bc8
 RBP: ffff8800aa72db78 R08: 0000000000000010 R09: ffffffff8174bbec
 R10: ffffffff812ee010 R11: 0000000000000001 R12: 0000000000001000
 R13: 0000000000010000 R14: ffff8800a4140000 R15: ffff8800aaba1800
 FS:  00007ff9a3bd4720(0000) GS:ffff8800afa00000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
 CR2: ffff8800a4244000 CR3: 00000000a9c18000 CR4: 00000000000006f0
 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
 Process modprobe (pid: 1008, threadinfo ffff8800aa72c000, task ffff8800aa0e4000)
 Stack:
  ffffffffa04e7c7b 0000000000000001 0000000000010000 ffff8800aa72db28
  ffffffff00000001 0000000000001000 ffffffff8113cbef 0000000000000020
  ffff8800a4243420 ffff880000000002 ffff8800aa72db08 ffff8800a9d42000
 Call Trace:
  [<ffffffffa04e7c7b>] ? radeon_atrm_get_bios_chunk+0x8b/0xd0 [radeon]
  [<ffffffff8113cbef>] ? kmalloc_order_trace+0x3f/0xb0
  [<ffffffffa04a9298>] radeon_get_bios+0x68/0x2f0 [radeon]
  [<ffffffffa04c7a30>] rv770_init+0x40/0x280 [radeon]
  [<ffffffffa047d740>] radeon_device_init+0x560/0x600 [radeon]
  [<ffffffffa047ef4f>] radeon_driver_load_kms+0xaf/0x170 [radeon]
  [<ffffffffa043cdde>] drm_get_pci_dev+0x18e/0x2c0 [drm]
  [<ffffffffa04e7e95>] radeon_pci_probe+0xad/0xb5 [radeon]
  [<ffffffff81296c5f>] local_pci_probe+0x5f/0xd0
  [<ffffffff81297418>] pci_device_probe+0x88/0xb0
  [<ffffffff813417aa>] ? driver_sysfs_add+0x7a/0xb0
  [<ffffffff813418d8>] really_probe+0x68/0x180
  [<ffffffff81341be5>] driver_probe_device+0x45/0x70
  [<ffffffff81341cb3>] __driver_attach+0xa3/0xb0
  [<ffffffff81341c10>] ? driver_probe_device+0x70/0x70
  [<ffffffff813400ce>] bus_for_each_dev+0x5e/0x90
  [<ffffffff8134172e>] driver_attach+0x1e/0x20
  [<ffffffff81341298>] bus_add_driver+0xc8/0x280
  [<ffffffff813422c6>] driver_register+0x76/0x140
  [<ffffffff812976d6>] __pci_register_driver+0x66/0xe0
  [<ffffffffa043d021>] drm_pci_init+0x111/0x120 [drm]
  [<ffffffff8133c67a>] ? vga_switcheroo_register_handler+0x3a/0x60
  [<ffffffffa0229000>] ? 0xffffffffa0228fff
  [<ffffffffa02290ec>] radeon_init+0xec/0xee [radeon]
  [<ffffffff810002f2>] do_one_initcall+0x42/0x180
  [<ffffffff8109d8d2>] sys_init_module+0x92/0x1e0
  [<ffffffff815407a9>] system_call_fastpath+0x16/0x1b
 Code: 58 2a 43 50 88 43 4e 48 83 c4 08 5b c9 c3 66 90 e8 cb fd ff ff eb
  e6 90 90 90 90 90 90 90 90 90 48 89 f8 89 d1 c1 e9 03 83 e2 07 <f3> 48
  a5 89 d1 f3 a4 c3 20 48 83 ea 20 4c 8b 06 4c 8b 4e 08 4c
 RIP  [<ffffffff81275b5b>] memcpy+0xb/0x120
  RSP <ffff8800aa72db00>
 CR2: ffff8800a4244000
 ---[ end trace fcffa1599cf56382 ]---

Call to acpi_evaluate_object() not always returns 4096 bytes chunks,
on my system it can return 2048 bytes chunk, so pass the length of
retrieved chunk to memcpy(), not the length of the recieving buffer.
Signed-off-by: NIgor Murzov <e-mail@date.by>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

ioremap() has become more picky and is now spitting out console messages like:

 ioremap error for 0xbddbd000-0xbddbe000, requested 0x10, got 0x0

when loading the einj driver.  What we are trying to so here is map
a couple of data structures that the EINJ table points to. Perhaps
acpi_os_map_memory() is a better tool for this?
Most importantly it works, but as a side benefit it maps the structures
into kernel virtual space so we can access them with normal C memory
dereferences, so instead of using:
	writel(param1, &v5param->apicid);
we can use the more natural:
	v5param->apicid = param1;
Signed-off-by: NTony Luck <tony.luck@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

This function is returning pointers.  Sparse complains here:
drivers/acpi/apei/einj.c:262:32: warning:
	Using plain integer as NULL pointer
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Acked-by: NHuang Ying <ying.huang@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

According to the ACPI spec [1] section 18.6.4 the TRIGGER_ERROR action
table can consists of zero elements.

[1] Advanced Configuration and Power Interface Specification
    Revision 5.0, December 6, 2011
	http://www.acpi.info/DOWNLOADS/ACPIspec50.pdfSigned-off-by: NNiklas Söderlund <niklas.soderlund@ericsson.com>
Acked-by: NHuang Ying <ying.huang@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Commit b298d289
 "PM / Sleep: Fix freezer failures due to racy usermodehelper_is_disabled()"
added read_unlock_usermodehelper() but read_unlock_usermodehelper() is called
without read_lock_usermodehelper() when kmalloc() failed.
Signed-off-by: NTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Acked-by: NSrivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

Changeset 7830bbaf mangled the bandwidth field for CinergyT2.
Properly fill it.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NJosh Wu <josh.wu@atmel.com>
Acked-by: NNicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Fix bug introduced by multi-frontend to single-frontend change.
It is safer to put DVB-T parts sleeping when auto-switching to DVB-T2
and vice versa. That was original behaviour.
Signed-off-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

No more error that error seen when device is plugged:
dvb_ca adapter 0: Invalid PC card inserted :(
Signed-off-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Fix bug introduced by multi-frontend to single-frontend change.
This parameter is no longer used after multi-frontend to single-frontend change.
Signed-off-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Fix bug introduced by multi-frontend to single-frontend change.

* Add missing DVB-C caps
* Change frontend name as single frontend does all the standards
Signed-off-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>