If you want to download Infineon modem via USB, this Infineon USB
flashloader driver is required.
Signed-off-by: Wei Shuai <cpuwolf@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The Option GTM681W uses a qualcomm chip and can be
served by the qcserial device driver.
Signed-off-by: Richard Weinberger <richard@nod.at>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The patch adds a new HIDCOM device and does not affect other devices
driven by the cypress_M8 module. Changes are:
- add VendorID ProductID to device tables
- skip unstable speed check because FRWD uses 115200bps
- skip reset at probe which is an issue workaround for this
particular device.
Signed-off-by: Robert Butora <robert.butora.fi@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
when platform_driver_register broken, we should unregister ucc_uart_driver
Signed-off-by: Libo chen <libo.chen@huawei.com>
Acked-by: Timur Tabi <timur@tabi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add the missing uart_unregister_driver() before return from
s3c24xx_serial_modinit() in the error handling case.
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The usage of strict_strtoul() is not preferred, because
strict_strtoul() is obsolete. Thus, kstrtoul() should be
used.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
MPC5125 PSC controller has different register layout than MPC5121.
To support MPC5125 PSC in this driver we have to provide further
psc_ops functions for SoC specific register accesses.
Add new register access functions to the psc_ops structure and
provide MPC52xx and MPC512x specific implementation for them.
Then replace remaining direct register accesses in the driver by
appropriate psc_ops function calls. The subsequent patch can now
add MPC5125 specific set of psc_ops functions.
Signed-off-by: Vladimir Ermakov <vooon341@gmail.com>
Signed-off-by: Matteo Facchinetti <matteo.facchinetti@sirius-es.it>
Signed-off-by: Anatolij Gustschin <agust@denx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Use the wrapper functions for getting and setting the driver data using
platform_device instead of using dev_{get,set}_drvdata() with &pdev->dev,
so we can directly pass a struct platform_device.
Also, unnecessary dev_set_drvdata() is removed, because the driver core
clears the driver data to NULL after device_release or on probe failure.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Lucas has moved on. Since his email address does not work any more, it's
not expected to get his ack.
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
'wmt_dt_ids' is always compiled in. Hence of_match_ptr is not
necessary.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This reverts commit cfcec52e97.
This regresses a longstanding behaviour on X86 systems, which end up with
PCI serial ports moving between ttyS4 and ttyS0 when you bisect to opposite
sides of this commit, resulting in the need to constantly modify the console
setting in order to bisect across it.
Please revert, we can work on solving this for ARM platforms in a less
disruptive way.
Signed-off-by: Kyle McMartin <kyle@mcmartin.ca>
Cc: Karthik Manamcheri <karthik.manamcheri@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ensure that the uart controller clock is enabled prior to writing to the
interrupt mask and pending registers in the s3c24xx_serial_init_port
function.
Signed-off-by: Chander Kashyap <chander.kashyap@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
We only want to enable hardware flow control if RTS/CTS pins
are connected.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Currently all register maps with a cache need to provide a volatile
callback since the default is to assume all registers are volatile.
This is not sensible if we have a cache so change the default to be
fully cached if a cache is provided.
Signed-off-by: Mark Brown <broonie@linaro.org>
There's no need to take up the space for devices that don't
support WoWLAN, and most drivers can even make the support
data static const (except where it's modified at runtime.)
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The Kirkwood CPU Freq driver needs a CPU definition in order for the probe
routine to activate it. Add a suitable definition to kirkwood.dtsi
This definition is only correct for single core SoCs. There is a dual core
SoC in the kirkwood family (88F632X) but the rest of the Kirkwood drivers in
the kernel don't currently support it. If they ever do the cpus definition
would need to be duplicated in each of the SoC specific include files.
Signed-off-by: Adam Baker <linux@baker-net.org.uk>
Tested-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
'mcasp_dt_ids' is always compiled in. Hence of_match_ptr is not
necessary.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Mark Brown <broonie@linaro.org>
This patch makes GFS2 immediately reclaim/delete all iopen glocks
as soon as they're dequeued. This allows deleters to get an
EXclusive lock on iopen so files are deleted properly instead of
being set as unlinked.
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
This version has one more correction: the vmalloc calls are replaced
by __vmalloc calls to preserve the GFP_NOFS flag.
When GFS2's directory management code allocates buffers for a
directory hash table, if it can't get the memory it needs, it
currently gives a bad return code. Rather than giving an error,
this patch allows it to use virtual memory rather than kernel
memory for the hash table. This should make it possible for
directories to function properly, even when kernel memory becomes
very fragmented.
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
This patch calls get_write_access in a few functions. This
merely increases inode->i_writecount for the duration of the function.
That will ensure that any file closes won't delete the inode's
multi-block reservation while the function is running.
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
This patch sets the log descriptor type according to whether the
journal commit is for (journaled) data or metadata. This was
recently broken when the functions to process data and metadata
log ops were combined.
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
Both clear the IRQ as being a wake source when we are finished with it
and include a missing header file that is required.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Use generic DMA DT helper.
Platforms booting with or without DT populated are both supported.
Based on Ludovic Desroches <ludovic.desroches@atmel.com> patchset
"ARM: at91: move to generic DMA device tree binding"
Signed-off-by: Richard Genoud <richard.genoud@gmail.com>
Acked-by: Ludovic Desroches <ludovic.desroches@gmail.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
The mxs interrupt controller does not support polling for interrupts,
but the driver still does it, which is a relict from
pre-MULTI_IRQ_HANDLER times.
The existing code assumes that 0x7f means no interrupt, but this value
is an actually valid irq number, namely gpio bank 0's irq. This results
in the driver not detecting when irq 0x7f is active which makes the
machine effectively dead lock.
This patch removes the interrupt poll loop and allows usage of gpio0
interrupt without an infinite loop.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
Cc: stable@vger.kernel.org
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Cap max peerings at 63 in accordance with IEEE-2012 8.4.2.100.7.
Triggers a beacon regeneration every time the number of peerings changes.
Previously this would only happen if the "accepting peerings" bit changed.
Signed-off-by: Jacob Minshall <jacob@cozybit.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
nl80211 has already verified the mesh TTL on setting the
mesh config, so no need to check it again in mac80211.
Signed-off-by: Thomas Pedersen <thomas@cozybit.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
It's not supported yet. Fixes display issues when
users force it on.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
24778be20 "spi: convert drivers to use bits_per_word_mask"
removed the "default" statement in the spi_sirfsoc_setup_transfer
switch, causing a new warning:
drivers/spi/spi-sirf.c: In function 'spi_sirfsoc_setup_transfer':
arch/arm/include/asm/io.h:90:2: warning: 'rxfifo_ctrl' may be used uninitialized in this function [-Wmaybe-uninitialized]
asm volatile("str %1, %0"
^
drivers/spi/spi-sirf.c:364:19: note: 'rxfifo_ctrl' was declared here
u32 txfifo_ctrl, rxfifo_ctrl;
^
The compiler has correctly identified that this case may happen,
but since we know that things are horribly broken if bits_per_word
is ever something other than the values we tested, calling BUG()
is an appropriate action and tells the compiler that execution
will not continue afterwards.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Mark Brown <broonie@kernel.org>
Signed-off-by: Mark Brown <broonie@linaro.org>
The current radeon driver initialization routines, when using KMS, are written
so that the IRQ installation routine is called before initializing the WB buffer
and the CP rings. With some ASICs, though, the IRQ routine tries to access the
GFX_INDEX ring causing a call to RREG32 with the value of -1 in
radeon_fence_read. This, in turn causes the system to completely hang with some
cards, requiring a hard reset.
A call stack that can cause such a hang looks like this (using rv515 ASIC for the
example here):
* rv515_init (rv515.c)
* radeon_irq_kms_init (radeon_irq_kms.c)
* drm_irq_install (drm_irq.c)
* radeon_driver_irq_preinstall_kms (radeon_irq_kms.c)
* rs600_irq_process (rs600.c)
* radeon_fence_process - due to SW interrupt (radeon_fence.c)
* radeon_fence_read (radeon_fence.c)
* hang due to RREG32(-1)
The patch moves the IRQ installation to the card startup routine, after the ring
has been initialized, but before the IRQ has been set. This fixes the issue, but
requires a check to see if the IRQ is already installed, as is the case in the
system resume codepath.
I have tested the patch on three machines using the rv515, the rv770 and the
evergreen ASIC. They worked without issues.
This seems to be a known issue and has been reported on several bug tracking
sites by various distributions (see links below). Most of reports recommend
booting the system with KMS disabled and then enabling KMS by reloading the
radeon module. For some reason, this was indeed a usable workaround, however,
UMS is now deprecated and disabled by default.
Bug reports:
https://bugzilla.redhat.com/show_bug.cgi?id=845745https://bugs.launchpad.net/ubuntu/+source/linux/+bug/561789https://bbs.archlinux.org/viewtopic.php?id=156964
Signed-off-by: Adis Hamzić <adis@hamzadis.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
When we build a kernel with support for both ARMv6 and ARMv7,
gas is trying to be helpful by pointing out that the arm-cci
driver would not work on ARMv6:
/tmp/ccu1LDeU.s: Assembler messages:
/tmp/ccu1LDeU.s:450: Error: selected processor does not support ARM mode `wfi '
/tmp/ccu1LDeU.s:451: Error: selected processor does not support ARM mode `wfe '
make[4]: *** [drivers/bus/arm-cci.o] Error 1
We know that the driver will only be used on ARMv7, hence we
can annotate the inline assembly listing to allow those instructions.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Nicolas Pitre <nico@linaro.org>
Cc: Dave Martin <dave.martin@linaro.org>
The bug was introduced with async_dio feature: trying to optimize short reads,
we cut number-of-bytes-to-read to i_size boundary. Hence the following example:
truncate --size=300 /mnt/file
dd if=/mnt/file of=/dev/null iflag=direct
led to FUSE_READ request of 300 bytes size. This turned out to be problem
for userspace fuse implementations who rely on assumption that kernel fuse
does not change alignment of request from client FS.
The patch turns off the optimization if async_dio is disabled. And, if it's
enabled, the patch fixes adjustment of number-of-bytes-to-read to preserve
alignment.
Note, that we cannot throw out short read optimization entirely because
otherwise a direct read of a huge size issued on a tiny file would generate
a huge amount of fuse requests and most of them would be ACKed by userspace
with zero bytes read.
Signed-off-by: Maxim Patlasov <MPatlasov@parallels.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
If request submission fails for an async request (i.e.,
get_user_pages() returns -ERESTARTSYS), we currently skip the
-EIOCBQUEUED return and drop into wait_for_sync_kiocb() forever.
Avoid this by always returning -EIOCBQUEUED for async requests. If
an error occurs, the error is passed into fuse_aio_complete(),
returned via aio_complete() and thus propagated to userspace via
io_getevents().
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Maxim Patlasov <MPatlasov@parallels.com>
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
OMAP5 has 6 timers (GPTimers 5, 6, 8 to 11) that are capable of PWM.
The PWM capability property is missing from the node definitions of
couple of timers.
Add ti,timer-pwm attribute for timer 5, 6, 8 and 11.
Signed-off-by: Suman Anna <s-anna@ti.com>
[benoit.cousson@linaro.org: Update changelog and subject to highlight
the fix]
Signed-off-by: Benoit Cousson <benoit.cousson@linaro.org>
Earlier commits ensured proper muxing of pins related to proper
TWL6030 behavior: see commit 265a2bc8 (ARM: OMAP3: TWL4030: ensure
sys_nirq1 is mux'd and wakeup enabled) and commit 1ef43369 (ARM:
OMAP4: TWL: mux sys_drm_msecure as output for PMIC).
However these only fixed legacy boot and not DT boot. For DT boot,
the default mux values need to be set properly in DT.
Special thanks to Nishanth Menon for the review and catching some
major flaws in earlier versions.
Tested on OMAP4430/Panda and OMAP4460/Panda-ES.
Cc: Nishanth Menon <nm@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Kevin Hilman <khilman@linaro.org>
Acked-by: Grygorii Strashko <grygorii.strashko@ti.com>
[benoit.cousson@linaro.org: Slightly change the subject to align
board name with file name]
Signed-off-by: Benoit Cousson <benoit.cousson@linaro.org>
The gpmc driver is actually looking for "gpmc,num-cs" and
"gpmc,num-waitpins" properties in DT. The binding doc also states
this.
Correct the properties in the dts to provide the right values for the
gpmc driver.
Signed-off-by: Lars Poeschel <poeschel@lemonage.de>
Acked-by: Peter Korsgaard <jacmet@sunsite.dk>
Acked-by: Pekon Gupta <pekon@ti.com>
Signed-off-by: Benoit Cousson <benoit.cousson@linaro.org>
Fix bug introduced by commit 4582a4ab2a "FUSE: Adapt readdirplus to application
usage patterns".
We need to check for a positive dentry; negative dentries are not added by
readdirplus. Secondly we need to advise the use of readdirplus on the *parent*,
otherwise the whole thing is useless. Thirdly all this is only relevant if
"readdirplus_auto" mode is selected by the filesystem.
We advise the use of readdirplus only if the dentry was still valid. If we had
to redo the lookup then there was no use in doing the -plus version.
Reported-by: Bernd Schubert <bernd.schubert@itwm.fraunhofer.de>
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
CC: Feng Shuo <steve.shuo.feng@gmail.com>
CC: stable@vger.kernel.org
Last year, a patch was made for the "HP t5740e Thin Client" (see
http://lists.freedesktop.org/archives/dri-devel/2012-May/023245.html).
This device reports an lvds panel, but does not really have one.
The predecessor of this device is the "hp t5740", which also does not have
an lvds panel. This patch will add the same quirk for this device.
Signed-off-by: Ben Mesman <ben@bnc.nl>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If we always force the pipe A to on we can't use the hw state to
decide whether it should be on. Hence quirk the quirk.
The problem is that crtc->active tracks the state of the entire
display pipe, i.e. including planes, encoders and all. But our hw
state readout simply looks at the pipe. But with the pipe A quirk we
force-enable that (together with it's pll). To fix that mismatch we
have two options:
- Quirk the checked state to match what our sw tracking states if the
pipe A quirk is in effect.
- Improve the hw state readout to not get fooled by the pipe A quirk.
Since we already have similar state clamping in e.g. assert_pipe I've
opted for the first variant. Also note that we don't really loose any
state checking: Individual pieces of the abstract crtc pipe are
checked in the enable/disable functions with the various asssert_*
checks we have, and the hw state check code doesn't check anything if
the pipe is off anyway.
v2: Pimp commit message after discussion with Chris and only apply the
quirk for the quirk if we're checking pipe A. Otherwise we'll miss
state checking for pipe B on i830M ...
v3: Make the code comment consistent with the improved commit message,
too (Chris).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64764
Cc: stable@vger.kernel.org
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reported-and-Tested-by: mlsemon35@gmail.com (v1)
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson noticed that since
commit 1f83fee08d [v3.9]
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Thu Nov 15 17:17:22 2012 +0100
drm/i915: clear up wedged transitions
X can again get -EIO when it does not expect it. And even worse score
a SIGBUS when accessing gtt mmaps. The established ABI is that we
_only_ return an -EIO from execbuf - all other ioctls should just
work. And since the reset code moves all bos out of gpu domains and
clears out all the last_seqno/ring tracking there really shouldn't be
any reason for non-execbuf code to ever touch the hw and see an -EIO.
After some extensive discussions we've noticed that these spurios -EIO
are caused by i915_gem_wait_for_error:
http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg20540.html
That is easy to fix by returning 0 instead of -EIO, since grabbing the
dev->struct_mutex does not yet mean that we actually want to touch the
hw. And so there is no reason at all to fail with -EIO.
But that's not the entire since, since often (at least it's easily
googleable) dmesg indicates that the reset fails and we declare the
gpu wedged. Then, quite a bit later X wakes up with the "Timed out
waiting for the gpu reset to complete" DRM_ERROR message in
wait_for_errror and brings down the desktop with an -EIO/SIGBUS.
So clearly we're missing a wakeup somewhere, since the gpu reset just
doesn't take 10 seconds to complete. And indeed we're do handle the
terminally wedged state wrong.
Fix this all up.
References: https://bugs.freedesktop.org/show_bug.cgi?id=63921
References: https://bugs.freedesktop.org/show_bug.cgi?id=64073
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We only need to do them if the pipe is actually running and if the
framebuffers have changed. Removes two "wait for vblank timed out"
messages when doing a suspend/resume cycle on my i855gm.
v2: s/to_intel_ctrc(crtc)/intel_crtc/ spotted by Chris.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
smatch reports the following warnings:
drivers/net/can/usb/peak_usb/pcan_usb_pro.c:514 pcan_usb_pro_drv_loaded() error: doing dma on the stack (buffer)
drivers/net/can/usb/peak_usb/pcan_usb_pro.c:878 pcan_usb_pro_init() error: doing dma on the stack (&fi)
drivers/net/can/usb/peak_usb/pcan_usb_pro.c:889 pcan_usb_pro_init() error: doing dma on the stack (&bi)
See "Documentation/DMA-API-HOWTO.txt" section "What memory is DMA'able?"
Cc: Stephane Grosjean <s.grosjean@peak-system.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
smatch reports the following warnings:
drivers/net/can/usb/esd_usb2.c:640 esd_usb2_start() error: doing dma on the stack (&msg)
drivers/net/can/usb/esd_usb2.c:846 esd_usb2_close() error: doing dma on the stack (&msg)
drivers/net/can/usb/esd_usb2.c:855 esd_usb2_close() error: doing dma on the stack (&msg)
drivers/net/can/usb/esd_usb2.c:923 esd_usb2_set_bittiming() error: doing dma on the stack (&msg)
drivers/net/can/usb/esd_usb2.c:1047 esd_usb2_probe() error: doing dma on the stack (&msg)
drivers/net/can/usb/esd_usb2.c:1053 esd_usb2_probe() error: doing dma on the stack (&msg)
See "Documentation/DMA-API-HOWTO.txt" section "What memory is DMA'able?"
Signed-off-by: Olivier Sobrie <olivier@sobrie.be>
Cc: Matthias Fuchs <matthias.fuchs@esd.eu>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Unlike Kvaser Leaf light devices, some other Kvaser devices (like USBcan
Pro, USBcan R) receive CAN messages in CMD_LOG_MESSAGE frames. This
patch adds support for it.
Cc: linux-stable <stable@vger.kernel.org> # >= v3.8
Signed-off-by: Jonas Peterson <jonas.peterson@gmail.com>
Signed-off-by: Olivier Sobrie <olivier@sobrie.be>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
My cfg80211/mac80211 locking unification broke the sdata
locking in ieee80211_set_power_mgmt, it needs to acquire
the lock for __ieee80211_request_smps(). Add the locking.
Reported-by: Jakub Kicinski <kubakici@wp.pl>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
People don't like typedefs these days. Eliminate their use from intel_fb.c.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Use container_of() instead of a cast to get struct intel_fbdev
from struct drm_fb_helper.
Also populate the fb_info->par correctly with the drm_fb_helper pointer
instead of the intel_fbdev pointer.
There's no actual functional change since the drm_fb_helper happens to
be the first member inside intel_fbdev.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
