When building the da7218 driver on a 64-bit architecture, we get
a harmless warning:
sound/soc/codecs/da7218.c: In function 'da7218_of_get_id':
sound/soc/codecs/da7218.c:2261:10: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
This changes the code to use uintptr_t to ensure we have an integer
type of the same size as a pointer and won't get a warning on any
architecture.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 4d50934abd ("ASoC: da7218: Add da7218 codec driver")
Signed-off-by: Mark Brown <broonie@kernel.org>
We get a warning for the imx-pcm-fiq driver when CONFIG_LPAE
is enabled on ARM, because dma_addr_t is 64-bit then:
sound/soc/fsl/imx-pcm-fiq.c: In function 'snd_imx_pcm_mmap':
sound/soc/fsl/imx-pcm-fiq.c:223:107: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t {aka long long unsigned int}' [-Wformat=]
This changes the printk to use the correct format string for
printing a dma_addr_t.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Probing components can bring new DAI or DAI links based on the topology
info. This patch finds the unbound DAI links and bind them.
Signed-off-by: Mengdong Lin <mengdong.lin@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This function will return success immediately for a bound DAI link.
No need to look for the cpu/codec DAIs again.
Signed-off-by: Mengdong Lin <mengdong.lin@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
A machine driver can register the two ops.
When a DAI link is added or removed by a component's topology, the
ASoC core can call the ops to notify the machine driver for extra
intialization or destruction.
E.g. topology can create FE DAI links from a cpu DAI component, and
the machine driver may define an add_dai_link ops to set machine-specific
.init ops for the DAI link.
Signed-off-by: Mengdong Lin <mengdong.lin@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Implement a dai link list for the soc card.
Add APIs to add/remove a DAI links dynamically, e.g. by topology.
And a dobj is embedded into the struct snd_soc_dai_link. Topology can
use the dobj to find the links created by it and remove them when the
topology component is unloaded.
The predefined DAI links are reserved to keep backward compatibility.
And they will also be added to the list.
Signed-off-by: Mengdong Lin <mengdong.lin@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The driver now exposes sufficient limits so we can
avoid having mlx4 specific work-around.
Signed-off-by: Sagi Grimberg <sagig@mellanox.com>
Reviewed-by: Steve Wise <swise@opengridcomputing.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Fix the spelling of 'output' in the error message.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
We should only add ignore suspend flag for some DAIs and not all.
This patches removes it from the DAIs where we do not support
this
It also marks the endpoints for which ignore_suspend should be
enabled
Signed-off-by: Praveen Diwakar <praveen.diwakar@intel.com>
Signed-off-by: Vunny Sodhi <vunnyx.sodhi@intel.com>
Signed-off-by: Jeeja KP <jeeja.kp@intel.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Some of the usecases can be marked as 'ignore_suspend' by
machine. For these on suspend we should keep audio controller
ON by saving the state and not suspending the device
For this we need to maintain a counter for these streams and be
active on suspend when such a stream is opened.
Signed-off-by: Jeeja KP <jeeja.kp@intel.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
DAPM Machine map for machine was not specifying the paths
correctly.
The correct order should be:
"DMIC01 Rx" (SoC DMIC BE), connected to "DMIC AIF" (DMic Codec
AIF) and then "DMic" (DMic codec Input) connected to "SoC DMIC"
(Machine DMIC MIC Widget)
Signed-off-by: Jeeja KP <jeeja.kp@intel.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Since in Skylake we support another DAI for DMIC quad capture,
add a dailink for this as well. Also specify constrains for DMIC
FE devices and fixup for DMIC BEs
Signed-off-by: Dharageswari.R <dharageswari.r@intel.com>
Signed-off-by: Jeeja KP <jeeja.kp@intel.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
If a module is ON then we should read the module parameters from
DSP rather than driver cached values
Signed-off-by: Omair M Abdullah <omair.m.abdullah@intel.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
For messages which have larger payload than mailbox data, we need
to split the payload using set of messages containing mailbox
size as payload.
For sending such payload we already support LARGE_CONFIG_SET
IPCs and now to query such payload add LARGE_CONFIG_GET IPC
Signed-off-by: Mousami Jana <mousami.janax@intel.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
SKL actual mailbox size is 0x10000 and initial values were 0x800,
so update these accordingly
Signed-off-by: Omair M Abdullah <omair.m.abdullah@intel.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Module initialization parameter data can be set by
- INIT_INSTANCE IPC by using the default value
- SET_PARAMS immediately after INIT_INSTANCE
- SET_PARAMS data from kcontrol values set
this patch add param type to identify the parameters
has to be sent to DSP.
Signed-off-by: Jeeja KP <jeeja.kp@intel.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Mic select is a DSP module which is used to select one or many
inputs to form an output. This is useful to select data
selectively from PDM input and hence the name. This module is of
generic module type.
This patch adds support to add and configure Mic select module in
firmware topology.
Signed-off-by: Dharageswari R <dharageswari.r@intel.com>
Signed-off-by: Jeeja KP <jeeja.kp@intel.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
A module can require extra memory for processing, like audio
algorithms. The memory for these modules needs to be represented
in base module configuration and passed to DSP on init, so add
the memory pages as a field in widget data
Signed-off-by: Dharageswari.R <dharageswari.r@intel.com>
Signed-off-by: Jeeja KP <jeeja.kp@intel.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
A module is loaded when the path consisting the module is opened.
The module binary(ies) is loaded from file system and cached in
kernel memory for future use. This is downloaded to DSP using DMA
and invoking Load module IPCs
This patch adds support for load/unload module IPCs, DMAing
modules and manging the modules
Signed-off-by: Dharageswari R <dharageswari.r@intel.com>
Signed-off-by: Jeeja KP <jeeja.kp@intel.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
* support bcm4359 which can operate in two bands concurrently
* disable runtime pm for USB avoiding issues
* use generic pm callback in PCIe driver
* support wowlan wake indication reporting
* add beamforming support
* unified handling of firmware files
ath10k
* support Manegement Frame Protection (MFP)
* add thermal throttling support for 10.4 firmware
* add support for pktlog in QCA99X0
* add debugfs file to enable Bluetooth coexistence feature
* use firmware's native mesh interface type instead of raw mode
iwlwifi
* BT coex improvements
* D3 operation bugfixes
* rate control improvements
* firmware debugging infra improvements
* ground work for multi Rx
* various security fixes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAABAgAGBQJWZcQtAAoJEG4XJFUm622bgcMH/1VRwtzAKpYVwAyAN0MtVLxe
uANi0Pw1PmEAeEI3TxEBckEH0JYfpg+aAwX7S8scnQSvLP3FYeC5IcHG551vlh0s
FlkGexcXqGrDqjt8mz8hxqqAmMH9YEVlzj2HJf6YFjNS4K84CEgpaSjaSG8S7Wc8
hTSA5K+XxrnEeX41W7FYmeBFLejisg0gVTkS3ZCe4qYz4Gh1oamoA0pOdU+AYOMy
0XBkCT8fqTVXWLHh9/+J7IZOYrjBl4rVaHofeygEAfSRNNfmmjZXX1R+FCQoJEZC
IOEQ31T64G4A37t2N2RGOhiG+2vckdbPg2JsqJosI1L2OZSBbeGZsVW48w+5cgc=
=GQDA
-----END PGP SIGNATURE-----
Merge tag 'wireless-drivers-next-for-davem-2015-12-07' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next
Kalle Vallo says:
====================
brcfmac
* support bcm4359 which can operate in two bands concurrently
* disable runtime pm for USB avoiding issues
* use generic pm callback in PCIe driver
* support wowlan wake indication reporting
* add beamforming support
* unified handling of firmware files
ath10k
* support Manegement Frame Protection (MFP)
* add thermal throttling support for 10.4 firmware
* add support for pktlog in QCA99X0
* add debugfs file to enable Bluetooth coexistence feature
* use firmware's native mesh interface type instead of raw mode
iwlwifi
* BT coex improvements
* D3 operation bugfixes
* rate control improvements
* firmware debugging infra improvements
* ground work for multi Rx
* various security fixes
====================
Conflicts:
drivers/net/wireless/ath/ath10k/pci.c
The conflict resolution at:
http://article.gmane.org/gmane.linux.kernel.next/37391
by Stephen Rothwell was used.
Signed-off-by: David S. Miller <davem@davemloft.net>
Receipt of CM MAD with other than the Send method for an attribute
other than the ClassPortInfo attribute is invalid.
CM attributes other than ClassPortInfo only use the send method.
The SRP initiator does not maintain a timeout policy for CM connect
requests relies on the CM layer to do that. The result was that
the SRP initiator hung as the connect request never completed.
A new SRP target has been observed to respond to Send CM REQ
with GetResp of CM REQ with bad status. This is non conformant
with IBA spec but exposes a vulnerability in the current MAD/CM
code which will respond to the incoming GetResp of CM REQ as if
it was a valid incoming Send of CM REQ rather than tossing
this on the floor. It also causes the MAD layer not to
retransmit the original REQ even though it has not received a REP.
Reviewed-by: Sagi Grimberg <sagig@mellanox.com>
Signed-off-by: Hal Rosenstock <hal@mellanox.com>
Reviewed-by: Ira Weiny <ira.weiny@intel.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Since the mmio has support the 64-bit has been supported for the
64-bit platform, so should the regmap core too.
Signed-off-by: Xiubo Li <lixiubo@cmss.chinamobile.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Previously we recorded "last interrupt position" and used it in
pointer callback. This is not correct implementation, and it causes
underruns when user space monitors buffer level to decide when to
send next data chunk in low latency application.
Remove position recording in IRQ handler and also hw_ptr in
struct mtk_afe_memif used to record that, and let pointer callback
reports current HW pointer instead.
Signed-off-by: Koro Chen <koro.chen@mediatek.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Splite the minimal stride parsing into one signal function.
Signed-off-by: Xiubo Li <lixiubo@cmss.chinamobile.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add support for the SolidRun Armada 388 Clearfog A1 board. This board
has an Armada 388 microsom, dedicated gigabit ethernet, six switched
gigabit ethernet ports, SFP cage, two Mini-PCIe/mSATA slots, a m.2 SATA
slot, and a MikroBUS connector to allow MikroBUS modules to be added.
This DT file adds support for all board facilities with the exception
of full SFP support.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
As the kernel generally uses negated error numbers, *err needs to be
compared with -EAGAIN (d'oh).
Signed-off-by: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Fixes: ea3793ee29 ("core: enable more fine-grained datagram reception control")
Signed-off-by: David S. Miller <davem@davemloft.net>
Workqueue stalls can happen from a variety of usage bugs such as
missing WQ_MEM_RECLAIM flag or concurrency managed work item
indefinitely staying RUNNING. These stalls can be extremely difficult
to hunt down because the usual warning mechanisms can't detect
workqueue stalls and the internal state is pretty opaque.
To alleviate the situation, this patch implements workqueue lockup
detector. It periodically monitors all worker_pools periodically and,
if any pool failed to make forward progress longer than the threshold
duration, triggers warning and dumps workqueue state as follows.
BUG: workqueue lockup - pool cpus=0 node=0 flags=0x0 nice=0 stuck for 31s!
Showing busy workqueues and worker pools:
workqueue events: flags=0x0
pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=17/256
pending: monkey_wrench_fn, e1000_watchdog, cache_reap, vmstat_shepherd, release_one_tty, release_one_tty, release_one_tty, release_one_tty, release_one_tty, release_one_tty, release_one_tty, release_one_tty, release_one_tty, release_one_tty, release_one_tty, release_one_tty, cgroup_release_agent
workqueue events_power_efficient: flags=0x80
pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=2/256
pending: check_lifetime, neigh_periodic_work
workqueue cgroup_pidlist_destroy: flags=0x0
pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/1
pending: cgroup_pidlist_destroy_work_fn
...
The detection mechanism is controller through kernel parameter
workqueue.watchdog_thresh and can be updated at runtime through the
sysfs module parameter file.
v2: Decoupled from softlockup control knobs.
Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: Don Zickus <dzickus@redhat.com>
Cc: Ulrich Obergfell <uobergfe@redhat.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Chris Mason <clm@fb.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
touch_softlockup_watchdog() is used to tell watchdog that scheduler
stall is expected. One group of usage is from paths where the task
may not be able to yield for a long time such as performing slow PIO
to finicky device and coming out of suspend. The other is to account
for scheduler and timer going idle.
For scheduler softlockup detection, there's no reason to distinguish
the two cases; however, workqueue lockup detector is planned and it
can use the same signals from the former group while the latter would
spuriously prevent detection. This patch introduces a new function
touch_softlockup_watchdog_sched() and convert the latter group to call
it instead. For now, it just calls touch_softlockup_watchdog() and
there's no functional difference.
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Ulrich Obergfell <uobergfe@redhat.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Andrew Morton <akpm@linux-foundation.org>
Task or work item involved in memory reclaim trying to flush a
non-WQ_MEM_RECLAIM workqueue or one of its work items can lead to
deadlock. Trigger WARN_ONCE() if such conditions are detected.
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Many codecs, typically found on Realtek codecs, have the analog
loopback path merged to the secondary input of the middle of the
output paths. Currently, we don't offer the dynamic switching in such
configuration but let each loopback path mute by itself.
This should work well in theory, but in reality, we often see that
such a dead loopback path causes some background noises even if all
the elements get muted. Such a problem has been fixed by adding the
quirk accordingly to disable aamix, and it's the right fix, per se.
The only problem is that it's not so trivial to achieve it; user needs
to pass a hint string via patch module option or sysfs.
This patch gives a bit improvement on the situation: it adds "Loopback
Mixing" control element for such codecs like other codecs (e.g. IDT or
VIA codecs) with the individual loopback paths. User can turn on/off
the loopback path simply via a mixer app.
For keeping the compatibility, the loopback is still enabled on these
codecs. But user can try to turn it off if experiencing a suspicious
background or click noise on the fly, then build a static fixup later
once after the problem is addressed.
Other than the addition of the loopback enable/disablement control,
there should be no changes.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
__unflatten_device_tree() calls unflatten_dt_node(), which declares
a static variable. It is therefore not reentrant.
One of the callers of __unflatten_device_tree(), unflatten_device_tree(),
is only called once during early initialization and does not need to be
protected. The other caller, of_fdt_unflatten_tree(), can be called at
any time, possibly multiple times in parallel. This can happen, for
example, if multiple devicetree overlays have to be loaded and installed.
Without this protection, errors such as the following may be seen.
kernel: End of tree marker overwritten: e6a3a458
kernel: find_target_node:
Failed to find target-indirect node at /fragment@0
kernel: __of_overlay_create: of_build_overlay_info() failed for tree@/
Add a mutex to of_fdt_unflatten_tree() to make the call reentrant.
Cc: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Cc: stable@vger.kernel.org # v4.1+
Signed-off-by: Rob Herring <robh@kernel.org>
The meat here is definitely the detailed specs for what atomic_check
and atomic_commit are supposed to do.
And another candidate for a core vfunc that should be in a helper really
(output_poll_changed this time around).
v2: Feedback from Eric on irc:
- spelling fixes.
- spec what async should do
- copy the event related paragraphs from page_flip and adjust
- make it clear that a successful async commit is not allowed to leave
the pipe dead or disabled.
v3: Use FIXME comments to annotate functions that we should move to
some helpers.
v4: Suggestions from Thierry.
Cc: Eric Anholt <eric@anholt.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1449218769-16577-22-git-send-email-daniel.vetter@ffwll.ch
Reviewed-by: Thierry Reding <treding@nvidia.com>
While typing these I noticed that ->dirty is a bit a can of worms
and even supports blt/fill semantics ... shocked me a bit.
Oh well it's defined in a way that nothing bad (just a bit of inefficiency)
will happen for drivers which supports this. So I didn't bother copying
the detailed spec into the new kerneldoc.
v2: Suggestions from Thierry.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1449218769-16577-21-git-send-email-daniel.vetter@ffwll.ch
Reviewed-by: Thierry Reding <treding@nvidia.com>
And merge any docbook we have into the kerneldoc comments.
Since it's a legacy entry point with only two implementation (one each
in atomic and legacy crtc helpers) I've made the documentation for
set_config fairly sparse - no one should ever need to look at this
again, all the ABI we have is baked into code.
For ->page_flip otoh I kept all the extensive docs from the docbook
and even extended it where it was lacking: Currently we have a pile of
legacy page_flip implemantations, and even for atomic drivers there's
not yet a standard implementation in the helpers. Which means every
driver needs to implement this itself, and precise specs are really
valuable.
Otherwise there's just cursor, which really just boils down to "use at
least universal planes". And gamma tables (where we have a bit a mess
with the fbdev helper gamma hooks).
v2: Spelling fixes (Eric).
v3: Suggestions from Thierry.
Cc: Eric Anholt <eric@anholt.net>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1449218769-16577-20-git-send-email-daniel.vetter@ffwll.ch
We always register the DPMS property, it's really a fundamental
part of a display driver. So don't check whether the vfunc is there,
it's non-optional
Yes I've audited all the almost 100 drm_connector_funcs we have, no
one botched this ;-)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1449218769-16577-19-git-send-email-daniel.vetter@ffwll.ch
Reviewed-by: Thierry Reding <treding@nvidia.com>
The special case here is that both ->detect and ->force are actually
functions only called by the probe helpers and hence really shouldn't
be here. But since they've used by pretty much every driver I figured
it's better to just document this for now instead of holding this doc
patch hostage until that's all fixed. For that reason also group force
right next to detect.
v2: Use FIXME comments to annotate where we should move a hook to
helpers.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1449218769-16577-18-git-send-email-daniel.vetter@ffwll.ch
Reviewed-by: Thierry Reding <treding@nvidia.com>
Yes these are internal functions and not exported and we generally
don't document them. But for symmetry with the _set_property functions
(which are exported for the atomic helpers) I'd like to document them.
Upcoming vtable kerneldoc will reference both the set and get_property
functions.
v2: Suggestions from Thierry.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1449218769-16577-17-git-send-email-daniel.vetter@ffwll.ch
Nouveau is the only user, and atomic drivers should do state
save/restoring differently. So move it into noveau.
Saves me typing some kerneldoc, too ;-)
v2: Move misplaced hunk into earlier nouveau patch.
Cc: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1449245647-1315-1-git-send-email-daniel.vetter@ffwll.ch
Reviewed-by: Thierry Reding <treding@nvidia.com>
They're not how system suspend/resume should be done with atomic
(there's new helpers for that developed by Thierry Reding), and for
legacy drivers this really should be a helper hook and not a core one.
But there's not even helper code to use them, and only 2 drivers
(which now have their own private hooks) set them. Ditch them.
Saves me typing some kerneldoc, too ;-)
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1449218769-16577-15-git-send-email-daniel.vetter@ffwll.ch
Reviewed-by: Thierry Reding <treding@nvidia.com>
I want to remove the core ones since with atomic drivers system
suspend/resume is solved much differently. And there's only 2 drivers
(gma500 besides nouveau) really using them.
v2: Fixup bugs Ilia spotted.
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1449245618-1127-1-git-send-email-daniel.vetter@ffwll.ch
Reviewed-by: Thierry Reding <treding@nvidia.com>
I want to remove the core ones since with atomic drivers system
suspend/resume is solved much differently. And there's only 2 drivers
(nouveau besides gma500) really using them.
v2: Fixup build noise 0day reported.
Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1449218769-16577-13-git-send-email-daniel.vetter@ffwll.ch
Reviewed-by: Thierry Reding <treding@nvidia.com> (v1)
save/restore have been removed from drm_encoder_helper_funcs by
'commit 79f13ad5d8e0 ("drm: Move encoder->save/restore into nouveau")'
But this module was still defining it with empty content causing
compilation fails:
drivers/gpu/drm/i2c/tda998x_drv.c:1354:10: warning: initialization from
incompatible pointer type [-Wincompatible-pointer-types]
.save = tda998x_encoder_save,
drivers/gpu/drm/i2c/tda998x_drv.c:1355:2: error: unknown field 'restore'
specified in initializer
.restore = tda998x_encoder_restore,
Cc: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1449513306-17309-1-git-send-email-rodrigo.vivi@intel.com
