Totally unused, so just rip it out. Anyway, we want drivers to be
fully backwards compatible, allowing them to change behaviour is just
a recipe for them to break badly.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This field is never read. No need to set it in radeon. Besides, DRM gem
core clears it during setup, anyway.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
These two helpers are unused. Remove them. They rely on
gem_obj->driver_private, which is set to NULL during setup. As this field
isn't used by the driver, anymore, we can remove this assignment as well.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
gem_bo->driver_private is never read by cirrus nor DRM core. No need to
set it. Besides, drm core clears it during setup, anyway.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
gem_bo->driver_private is never read by mgag200 nor DRM core. No need to
set it. Besides, drm core clears it during setup, anyway.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
gem_bo->driver_private is never read by ast nor DRM core. No need to set
it. Besides, drm core clears it during setup, anyway.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Merge the rcar stable branch that is being shared with the arm-soc tree.
Signed-off-by: Dave Airlie <airlied@redhat.com>
* pfdo/drm-rcar-for-v3.12: (220 commits)
drm/rcar-du: Add FBDEV emulation support
drm/rcar-du: Add internal LVDS encoder support
drm/rcar-du: Configure RGB output routing to DPAD0
drm/rcar-du: Rework output routing support
drm/rcar-du: Add support for DEFR8 register
drm/rcar-du: Add support for multiple groups
drm/rcar-du: Fix buffer pitch alignment for R8A7790 DU
drm/rcar-du: Add support for the R8A7790 DU
drm/rcar-du: Move output routing configuration to group
drm/rcar-du: Remove register definitions for the second channel
drm/rcar-du: Use dynamic number of CRTCs instead of CRTCs array size
drm/rcar-du: Introduce CRTCs groups
drm/rcar-du: Rename rcar_du_plane_(init|register) to rcar_du_planes_*
drm/rcar-du: Create rcar_du_planes structure
drm/rcar-du: Rename platform data fields to match what they describe
drm/rcar-du: Merge LVDS and VGA encoder code
drm/rcar-du: Split VGA encoder and connector
drm/rcar-du: Split LVDS encoder and connector
drm/rcar-du: Clarify comment regarding plane Y source coordinate
drm/rcar-du: Support per-CRTC clock and IRQ
...
Conflicts:
drivers/gpu/drm/i915/i915_dma.c
drivers/gpu/drm/i915/intel_pm.c
drivers/gpu/drm/qxl/qxl_release.c
Add a fixup function that will flip the hsync priority and
add a hskew value that is used to shift the tda998x to the
right by a variable number of pixels depending on the mode.
This works around an issue with the sync timings that tilcdc
is outputing.
Signed-off-by: Darren Etheridge <detheridge@ti.com>
Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Tested-by: Russell King <rmk_kernel@arm.linux.org.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Some LCD controller cannot provide valid VESA style sync, i.e. coincident
HS/VS edges. First, this patch adds hskew passed from the adjusted_mode to
reference pixel calculation to allow those controllers to add an offset
relative to the expected reference pixel.
Signed-off-by: Darren Etheridge <detheridge@ti.com>
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Tested-by: Russell King <rmk_kernel@arm.linux.org.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The video-input-port (VIP) is highly configurable. This prepares
current driver to allow to configure VIP configuration, as some
boards connect lcd controller and TDA998x "pin-swapped" and depend
on VIP to swap the pins by register configuration.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tested-by: Darren Etheridge <detheridge@ti.com>
Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Tested-by: Russell King <rmk_kernel@arm.linux.org.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
When switching between various drivers for this device, it's possible
that some critical registers are left containing values which affect
the device operation. One such case encountered is the VIP output
mux register. This defaults to 0x24 on powerup, but other drivers may
set this to 0x12. This results in incorrect colours.
Fix this by ensuring that the register is always set to the power on
default setting.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tested-by: Darren Etheridge <detheridge@ti.com>
Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Tested-by: Russell King <rmk_kernel@arm.linux.org.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
If NO_DMA=y:
drivers/built-in.o: In function `__drm_pci_free':
drivers/gpu/drm/drm_pci.c:112: undefined reference to `dma_free_coherent'
drivers/built-in.o: In function `drm_pci_alloc':
drivers/gpu/drm/drm_pci.c:72: undefined reference to `dma_alloc_coherent'
drivers/built-in.o: In function `drm_gem_unmap_dma_buf':
drivers/gpu/drm/drm_prime.c:87: undefined reference to `dma_unmap_sg'
drivers/built-in.o: In function `drm_gem_map_dma_buf':
drivers/gpu/drm/drm_prime.c:78: undefined reference to `dma_map_sg'
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Commit 17397a2("ARM: EXYNOS: Remove platform device initialization")
removes calling exynos4_default_sdhci*() functions; thus, these are
not necessary any more.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
usb-serial-simple uses an unknown stringify macro that make
all drivers being named "stringify(vendor)".
This can be a problem when two drivers have the same (wrong) name:
kernel: usbcore: registered new interface driver usb_serial_simple
kernel: usbserial: USB Serial support registered for stringify(vendor)
kernel Error: Driver 'stringify(vendor)' is already registered, aborting...
kernel: usbserial: problem -16 when registering driver stringify(vendor)
kernel: usbserial: USB Serial deregistering driver stringify(vendor)
kernel: usbcore: deregistering interface driver usb_serial_simple
Before the fix:
$ strings drivers/usb/serial/usb-serial-simple.o
usb_serial_simple
stringify(vendor)
After the fix:
$ strings drivers/usb/serial/usb-serial-simple.o
usb_serial_simple
funsoft
flashloader
vivopay
moto_modem
hp4x
suunto
siemens_mpi
This patch makes usb-serial-simple use the correct stringify operator.
Signed-off-by: Yann Droneaud <ydroneaud@opteya.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch corrects the /include to #include on exynos5420
Signed-off-by: Padmavathi Venna <padma.v@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
MFC driver is updated to use only one clock instead of
two. Correcting this in the binding documentation.
Signed-off-by: Arun Kumar K <arun.kk@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
While the Linux driver stack is capable of figuring this out for itself
document the fact that we really do use the internal PHY even with the
directly wired hub on the board to save anyone else having to work this
out for themselves.
Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
The Arndale has a SMSC USB3503 connected in hardware only mode like a PHY,
support it using the usb-nop-xceiv binding.
Note that due to a regrettable decision to use a regulator to represent
the reset signal this uses a fixed voltage regulator to do that, there
is a plan to use the reset controller binding once that is merged so it
does not seem worthwhile to fix the usb-nop-xceiv driver at this point.
Signed-off-by: Mark Brown <broonie@linaro.org>
Tested-by: Tushar Behera <tushar.behera@linaro.org>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
OrigenQuad board boots with secure firmware support. Enable support for
reading smc commands.
The binding has been updated as per the documentation provided in
Documentation/devicetree/bindings/arm/samsung-boards.txt.
Signed-off-by: Tushar Behera <tushar.behera@linaro.org>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
In order to make the device easier to hook up to external components in
system designs and ensure operation when DAPM support becomes mandatory
add DAPM support.
Signed-off-by: Mark Brown <broonie@linaro.org>
In order to make the device easier to hook up to external components in
system designs and ensure operation when DAPM support becomes mandatory
add DAPM support.
Signed-off-by: Mark Brown <broonie@linaro.org>
After any "soft gfx reset" we must manually invalidate the TLBs
associated with each ring. Empirically, it seems that a
suspend/resume or D3-D0 cycle count as a "soft reset". The symptom is
that the hardware would fail to note the new address for its status
page, and so it would continue to write the shadow registers and
breadcrumbs into the old physical address (now used by something
completely different, scary). Whereas the driver would read the new
status page and never see any progress, it would appear that the GPU
hung immediately upon resume.
Based on a patch by naresh kumar kachhi <naresh.kumar.kacchi@intel.com>
Reported-by: Thiago Macieira <thiago@kde.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64725
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Thiago Macieira <thiago@kde.org>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This makes it possible to hook the device into a more complex board and
ensures it will continue to work with non-DAPM support removed from the
core.
Signed-off-by: Mark Brown <broonie@linaro.org>
In order to ensure that the device continues to work with DAPM support
being mandatory provide stub DAPM widgets and routes.
Note that the public information on the device appears to make no
mention of the FM support the driver appears to have.
Signed-off-by: Mark Brown <broonie@linaro.org>
Add pin state information for DP HPD support that requires pin configuration
support using pinctrl interface.
Signed-off-by: Vikas Sajjan <vikas.sajjan@linaro.org>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Adds FIMD DT node to exynos5420 based SMDK. Also adds display-timimg
information node.
Signed-off-by: Vikas Sajjan <vikas.sajjan@linaro.org>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Moves the properties of FIMD DT node which are common across Exynos5 based
SoCs like Exynos5250 and Exynos5420 to exynos5.dtsi
Signed-off-by: Vikas Sajjan <vikas.sajjan@linaro.org>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
As the display-timing information is parsed by FIMD driver, it makes
sense to move the display-timing DT node inside FIMD DT node for exynos5250
Signed-off-by: Vikas Sajjan <vikas.sajjan@linaro.org>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Pull cgroup fix from Tejun Heo:
"This contains one patch to fix the return value of cpuset's cgroups
interface function, which used to always return -ENODEV for the writes
on the 'memory_pressure_enabled' file"
* 'for-3.11-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup:
cpuset: fix the return value of cpuset_write_u64()
