Gone with the new gem vma offset manager from David.
We can also ditch the uapi header definition from the enum since
userspace never used this. It ended up in there purely for historical
reasons (for reusing the old drm mmap code essentially), not because
userspace ever needed it.
Cc: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
There's really no need for the drm core to keep a list of all
devices of a given driver - the linux device model keeps perfect
track of this already for us.
The exception is old legacy ums drivers using pci shadow attaching.
So rename the lists to make the use case clearer and rip out everything
else.
v2: Rebase on top of David Herrmann's drm device register changes.
Also drop the bogus dev_set_drvdata for platform drivers that somehow
crept into the original version - drivers really should be in full
control of that field.
v3: Initialize driver->legacy_dev_list outside of the loop, spotted by
David Herrmann.
v4: Rebase on top of the newly created host1x drm_bus for tegra.
Cc: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This patch replicates the correction made by Wei Yongjun on a second
occurrence of the same bug.
The first correction was in commit 8eec455551.
Bug fixed: The error code was not set, so the error condition wasn't reflected
in the return value.
Reported-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: Eli Billauer <eli.billauer@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Scan only to the length permitted by the buffer
One of a set of sscanf problems noted by Jackie Chang
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This very much looks like a remnant of the old legady ums shadow
attach days. Now with the last users gone we can rip it out since
we won't ever support an ums drm driver again.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This patch updates the vme_master and vme_slave structures to use
types with well defined size and to prevent the compiler from
inserting padding (between enable and vme_addr for one).
The original vme_master and vme_slave structs would be different
sizes and have different layouts depending on whether they were built
for a 32-bit or 64-bit system.
On x86 it is possible to have a 32-bit userspace and a 64-bit kernel.
In this type of environment, the userspace and kernel vme_user APIs
would disagree and prevent ioctls from executing (based on ioctl
signatures from _IOR and _IOW).
Signed-off-by: Aaron Sierra <asierra@xes-inc.com>
Acked-by: Martyn Welch <martyn.welch@ge.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Previously, VME bridge support was treated as any other driver (using
module_init() macro), but if VME bridge and vme_user (staging) drivers
were compiled into the kernel, then vme_user would attempt to register
itself before the VME core support had been loaded. This would result
in a kernel panic.
The load order of these built-in drivers is based on the order in which
drivers/staging/vme and driver/vme are compiled.
This patch changes the VME core driver to use the subsys_initcall()
macro which ensures that it is loaded before all other VME drivers
regardless of the order in which they are compiled.
Tested-by: Aaron Sierra <asierra@xes-inc.com>
Signed-off-by: Martyn Welch <martyn.welch@ge.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The drvdata pointer is already assigned to something useful.
Cc: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Again no apparent user of the driver data field.
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We need to chase one pointer here.
Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Again omap already sets the driver data pointer to the drm_device.
Also drop the driver unregister call, that should be (and already is)
done in the module unload hook.
Cc: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
tilcdc already stores the drm_device in the driver data pointer. So
use that.
Cc: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Again no apparent user of the driver data field.
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
I didn't find any user of the driver data yet, so store the
drm_device pointer in there.
Cc: Inki Dae <inki.dae@samsung.com>
Acked-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The magic dance drm_platform_exit does is actually a remnant of the
old legacy shadow attach support for platform devices. Modern modesetting
drm drivers shouldn't do this any more (and usb/pci devices actually don't
do this).
Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The clk_prepare_enable() call can fail. Check it's return value. We
can't propagate it all the way to the user as the KMS operations in
which the clock is enabled return a void.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This patch adds support for isochronous IN transfers to the HWA driver.
The changes include removing the checks that return errors for isoc IN
URBs and adding functionality to read the isoc data returned from the
HWA.
Signed-off-by: Thomas Pugliese <thomas.pugliese@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Pull drm fixes from Dave Airlie:
"Definitely seems quieter this week,
Radeon, intel, intel broadwell, vmwgfx, ttm, armada, and a couple of
core fixes, one revert in radeon
Most of these are either going to stable or fixes for things
introduced in the merge window"
* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux: (30 commits)
drm/edid: add quirk for BPC in Samsung NP700G7A-S01PL notebook
drm/ttm: Fix accesses through vmas with only partial coverage
drm/nouveau: only runtime suspend by default in optimus configuration
drm: don't double-free on driver load error
Revert "drm/radeon: Implement radeon_pci_shutdown"
drm/radeon: add missing display tiling setup for oland
drm/radeon: fix typo in cik_copy_dma
drm/radeon/cik: plug in missing blit callback
drm/radeon/dpm: Fix hwmon crash
drm/radeon: Fix sideport problems on certain RS690 boards
drm/i915: don't update the dri1 breadcrumb with modesetting
DRM: Armada: prime refcounting bug fix
DRM: Armada: fix printing of phys_addr_t/dma_addr_t
DRM: Armada: destroy framebuffer after helper
DRM: Armada: implement lastclose() for fbhelper
drm/i915: Repeat eviction search after idling the GPU
drm/vmwgfx: Add max surface memory param
drm/i915: Fix use-after-free in do_switch
drm/i915: fix pm init ordering
drm/i915: Hold mutex across i915_gem_release
...
In case where debugfs support is disabled, define dummy functions to
avoid the need for #ifdefery in drivers.
Based on an earlier patch by Arnd Bergmann.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
If we fail to remove a conflicting fb driver, we need to abort the
loading of the second driver to avoid likely kernel panics.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: linux-fbdev@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
These are set of two capability registers, it's pretty much given that
they're registers, so reflect their purpose in the name.
Suggested-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Not all drivers will need take all the modeset locks for dirtyfb, so
push the locking down to the drivers.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
There's no reason to keep a reference to objects in the name idr. Each
handle to an object has a reference to the object and just before we
destroy the last handle we take the object out of the name idr. Thus,
if an object is in the name idr, there's at least one reference to the
object.
Or to put it another way, the name idr reference will never keep the
object alive. It just looks like it, which is confusing.
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Sometimes we want to disable all the screens on a system, because that
will allow the graphics card to be put into low-power states. The
problem is that, for example, while all screens are disabled, if we
get a hotplug interrupt, fbcon will decide to set a mode instead of
keeping everything disabled, which will remove us from our low power
states.
Let's assume that if there's a DRM master, it will be able to do
whatever is appropriate when we get the hotplug.
This problem can be reproduced by the runtime PM test program from
intel-gpu-tools: we disable all the screens so the graphics device can
be put into D3, then something triggers a hotplug interrupt, fbcon
sets a mode and breaks our test suite. The problem can be reproduced
more easily by the "i2c" subtest.
Other approaches considered for the problem:
- Return "false" if "bound == 0" and the caller of
drm_fb_helper_is_bound is a hotplug handler. This would break
the case where the machine boots with no outputs connected, then
the user plugs a monitor.
- Add a new IOCTL to force fbcon to not set modes. This would keep
all the current applications behaving the same, but adding a new
IOCTL is not always the greatest idea.
- Return false only if "dev->primary->master && bound == 0". This
was my first implementation, but Chris suggested we should do
the check irrespective of the "bound" variable.
Thanks to Daniel Vetter for the investigation, ideas and the
implementation of the hotplug alternative.
v2: - Do the check first, irrespective of "bound".
- Cc dri-devel
Cc: dri-devel@lists.freedesktop.org
Credits-to: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Otherwise we risk that the 2nd part of the line ends up on a line of
it's own, which means a kernel dmesg line without a log level. This
then upsets the dmesg checker in piglit.
Only really happens in some of the truly nasty igt testcases which
race cache dropping (through debugfs) with other gem operations.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
For error traces in situations that can run away, it is nice to have a
rate-limited version of DRM_ERROR() to avoid massive log flooding.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Add default config for arch-hi3xxx. It's used for Hisilicon Hi3xxx SoC.
Signed-off-by: Haojian Zhuang <haojian.zhuang@linaro.org>
Signed-off-by: Kevin Hilman <khilman@linaro.org>
Enable Hisilicon Hi4511 development platform with device tree support.
Signed-off-by: Haojian Zhuang <haojian.zhuang@linaro.org>
Signed-off-by: Kevin Hilman <khilman@linaro.org>
Add board support with device tree for Hisilicon Hi3620 SoC platform.
Signed-off-by: Haojian Zhuang <haojian.zhuang@linaro.org>
[khilman: fix checkpatch errors]
[khilman: fold in patch which selects GPIO in Kconfig]
Signed-off-by: Kevin Hilman <khilman@linaro.org>
Always use "void *" for arbitrary memory buffers, as this allows to drop
casts in assignments.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
- some more ppgtt prep patches from Ben
- a few fbc fixes from Ville
- power well rework from Imre
- vlv forcewake improvements from Deepak S, Ville and Jesse
- a few smaller things all over
[airlied: fixup forwcewake conflict]
* tag 'drm-intel-next-2013-11-29' of git://people.freedesktop.org/~danvet/drm-intel: (97 commits)
drm/i915: Fix port name in vlv_wait_port_ready() timeout warning
drm/i915: Return a drm_mode_status enum in the mode_valid vfuncs
drm/i915: add intel_display_power_enabled_sw() for use in atomic ctx
drm/i915: drop DRM_ERROR in intel_fbdev init
drm/i915/vlv: use parallel context restore when coming out of RC6
drm/i915/vlv: use a lower RC6 timeout on VLV
drm/i915/sdvo: Fix up debug output to not split lines
drm/i915: make sparse happy for the new vlv mmio read function
drm/i915: drop the right force-wake engine in the vlv mmio funcs
drm/i915: Fix GT wake FIFO free entries for VLV
drm/i915: Report all GTFIFODBG errors
drm/i915: Enabling DebugFS for valleyview forcewake counts
drm/i915/vlv: Valleyview support for forcewake Individual power wells.
drm/i915: Add power well arguments to force wake routines.
drm/i915: Do not attempt to re-enable an unconnected primary plane
drm/i915: add a debugfs entry for power domain info
drm/i915: add a default always-on power well
drm/i915: don't do BDW/HSW specific powerdomains init on other platforms
drm/i915: protect HSW power well check with IS_HASWELL in redisable_vga
drm/i915: use IS_HASWELL/BROADWELL instead of HAS_POWER_WELL
...
Conflicts:
drivers/gpu/drm/i915/intel_display.c
While we don't really have any infrastructure for making use of VC
support, the system BIOS can configure the topology to non-default
VC values prior to boot. This may be due to silicon bugs, desire to
reserve traffic classes, or perhaps just BIOS bugs. When we reset
devices, the VC configuration may return to default values, which can
be incompatible with devices upstream. For instance, Nvidia GRID
cards provide a PCIe switch and some number of GPUs, all supporting
VC. The power-on default for VC is to support TC0-7 across VC0,
however some platforms will only enable TC0/VC0 mapping across the
topology. When we do a secondary bus reset on the downstream switch
port, the GPU is reset to a TC0-7/VC0 mapping while the opposite end
of the link only enables TC0/VC0. If the GPU attempts to use TC1-7,
it fails.
This patch attempts to provide complete support for VC save/restore,
even beyond the minimally required use case above. This includes
save/restore and reload of the arbitration table, save/restore and
reload of the port arbitration tables, and re-enabling of the
channels for VC, VC9, and MFVC capabilities.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Current save/restore is specific to standard capabilities.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
We currently have two instance of this loop which waits for a pending bit
to clear in a status dword. Generalize the function for future users.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Commit e30b06f4d5 (ARM: OMAP2+: Remove
legacy mux code for display.c) removed non-DT DSI and HDMI pinmuxing.
However, DSI pinmuxing is still needed, and removing that caused DSI
displays not to work.
This reverts the DSI parts of the commit.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
When I added support for ACPI5 I made the assumption that
injected processor errors would just need to know the APICID,
memory errors just the address and mask, and PCIe errors just the
segment/bus/device/function. So I had the code check the type of injection
and multiplex the "param1" value appropriately.
This was not a good assumption :-(
There are injection scenarios where we need to specify more than one of
these items. E.g. injecting a cache error we need to specify an APICID
of the cpu that owns the cache, and also an address (so that we can trip
the error by accessing the address).
Add a "flags" file to give the user direct access to specify which items
are valid in the ACPI SET_ERROR_TYPE_WITH_ADDRESS structure. Also add
new files param3 and param4 to hold all these values.
For backwards compatability with old injection scripts we maintain the
old behaviour if flags remains set at zero (or is reset to 0).
Acked-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
Commit 'tty: xuartps: Implement BREAK detection, add SYSRQ support'
(0c0c47bc40) introduced sysrq support
without properly guarding sysrq specific code which results in build
errors when sysrq is disabled:
DNAME=KBUILD_STR(xilinx_uartps)" -c -o
drivers/tty/serial/.tmp_xilinx_uartps.o
drivers/tty/serial/xilinx_uartps.c
drivers/tty/serial/xilinx_uartps.c: In function 'xuartps_isr':
drivers/tty/serial/xilinx_uartps.c:247:5: error: 'struct uart_port'
has no member named 'sysrq'
drivers/tty/serial/xilinx_uartps.c:247:5: error: 'struct uart_port'
has no member named 'sysrq'
drivers/tty/serial/xilinx_uartps.c:247:5: error: 'struct uart_port'
has no member named 'sysrq'
make[3]: *** [drivers/tty/serial/xilinx_uartps.o] Error 1
Reported-by: Masanari Iida <standby24x7@gmail.com>
Cc: Vlad Lungu <vlad.lungu@windriver.com>
Signed-off-by: Soren Brinkmann <soren.brinkmann@xilinx.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Pull networking fixes from David Miller:
"A quick batch of fixes, including the annoying bad lock stack problem
introduced by udp_sk_rx_dst_set() locking change:
1) Use xchg() instead of sk_dst_lock() in udp_sk_rx_dst_set(), from
Eric Dumazet.
2) qlcnic bug fixes from Himanshu Madhani and Manish Chopra.
3) Update IPSEC MAINTAINERS entry, from Steffen Klassert.
4) Administrative neigh entry changes should generate netlink
notifications the same as event generated ones. From Bob
Gilligan.
5) Netfilter SYNPROXY fixes from Patrick McHardy.
6) Netfilter nft_reject endianness fixes from Eric Leblond"
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net:
qlcnic: Dump mailbox registers when mailbox command times out.
qlcnic: Fix mailbox processing during diagnostic test
qlcnic: Allow firmware dump collection when auto firmware recovery is disabled
qlcnic: Fix memory allocation
qlcnic: Fix TSS/RSS validation for 83xx/84xx series adapter.
qlcnic: Fix TSS/RSS ring validation logic.
qlcnic: Fix diagnostic test for all adapters.
qlcnic: Fix usage of netif_tx_{wake, stop} api during link change.
xen-netback: fix fragments error handling in checksum_setup_ip()
neigh: Netlink notification for administrative NUD state change
ipv4: improve documentation of ip_no_pmtu_disc
net: unix: allow bind to fail on mutex lock
MAINTAINERS: Update the IPsec maintainer entry
udp: ipv4: do not use sk_dst_lock from softirq context
netvsc: don't flush peers notifying work during setting mtu
can: peak_usb: fix mem leak in pcan_usb_pro_init()
can: ems_usb: fix urb leaks on failure paths
sctp: loading sctp when load sctp_probe
netfilter: nft_reject: fix endianness in dump function
netfilter: SYNPROXY target: restrict to INPUT/FORWARD
Only print an error when _regulator_get() is expected to return a valid
regulator, that is when _regulator_get() is called from regulator_get() and
we're not using the dummy because we don't have full-constraints, or when
_regulator_get() is called from regulator_get_exclusive() in which case
returning a dummy is not allowed.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Use devm_*() functions to make cleanup paths simpler.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Acked-by: Wan ZongShun <mcuos.com@gmail.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Once a spi_master_get() call succeeds, we need an additional
spi_master_put() call to free the memory, otherwise we will
leak a reference to master. Fix by removing the unnecessary
spi_master_get() call.
Fixes: 247263dba2 ('spi: bcm63xx: use devm_spi_register_master()')
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: Mark Brown <broonie@linaro.org>
