This structure will be extended using non-framebuffer related callbacks
in subsequent patches, so it should move to a more central location.
Signed-off-by: Thierry Reding <treding@nvidia.com>

When disabling the display controller, stop it and wait for it to become
idle. Doing so ensures that no further accesses to the framebuffer occur
and the buffers can be safely unmapped or freed.
Signed-off-by: Thierry Reding <treding@nvidia.com>

Previously output drivers would all stop the display controller in their
disable path. However with the transition to atomic modesetting the
display controller needs to be kept running until all planes have been
disabled so that software can properly determine (using VBLANK counts)
when it is safe to remove the framebuffers associated with the planes.

Moving this code into the display controller's disable path also gets
rid of the duplication of this into all output drivers.
Signed-off-by: Thierry Reding <treding@nvidia.com>

All output drivers have open-coded variants of this function, so export
it to remove some code duplication.
Signed-off-by: Thierry Reding <treding@nvidia.com>

This callback can be used instead of the legacy ->mode_fixup() and is
passed the CRTC and connector states. It can thus use these states to
validate the modeset and cache values in the state to be used during
the actual modeset.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Thierry Reding <treding@nvidia.com>

In order to prevent drivers from having to perform the same checks over
and over again, add an optional ->atomic_disable callback which the core
calls under the right circumstances.

v2: pass old state and detect edges to avoid calling ->atomic_disable on
already disabled planes, remove redundant comment (Daniel Vetter)

v3: rename helper to drm_atomic_plane_disabling() to clarify that it is
checking for transitions, move helper to drm_atomic_helper.h, clarify
check for !old_state and its relation to transitional helpers

Here's an extract from some discussion rationalizing the behaviour (for
a full version, see the reference below):

    > > Hm, thinking about this some more this will result in a slight difference
    > > in behaviour, at least when drivers just use the helper ->reset functions
    > > but don't disable everything:
    > > - With transitional helpers we assume we know nothing and call
    > >   ->atomic_disable.
    > > - With atomic old_state->crtc == NULL in the same situation right after
    > >   boot-up, but we asssume the plane is really off and _dont_ call
    > >   ->atomic_disable.
    > >
    > > Should we instead check for (old_state && old_state->crtc) and state that
    > > drivers need to make sure they don't have stuff hanging around?
    >
    > I don't think we can check for old_state because otherwise this will
    > always return false, whereas we really want it to force-disable planes
    > that could be on (lacking any more accurate information). For
    > transitional helpers anyway.
    >
    > For the atomic helpers, old_state will never be NULL, but I'd assume
    > that the driver would reconstruct the current state in ->reset().

    By the way, the reason for why old_state can be NULL with transitional
    helpers is the ordering of the steps in the atomic transition. Currently
    the Tegra patches do this (based on your blog post and the Exynos proto-
    type):

        1) atomic conversion, phase 1:
           - implement ->atomic_{check,update,disable}()
           - use drm_plane_helper_{update,disable}()

        2) atomic conversion, phase 2:
           - call drm_mode_config_reset() from ->load()
           - implement ->reset()

    That's only a partial list of what's done in these steps, but that's the
    only relevant pieces for why old_state is NULL.

    What happens is that without ->reset() implemented there won't be any
    initial state, hence plane->state (the old_state here) will be NULL the
    first time atomic state is applied.

    We could of course reorder the sequence such that drivers are required
    to hook up ->reset() before they can (or at the same as they) hook up
    the transitional helpers. We could add an appropriate WARN_ON to this
    helper to make that more obvious.

    However, that will not solve the problem because it only gets rid of the
    special case. We still don't know whether old_state->crtc == NULL is the
    current state or just the initial default.

    So no matter which way we do this, I don't see a way to get away without
    requiring specific semantics from drivers. They would be that:

        - drivers recreate the correct state in ->reset() so that
          old_state->crtc != NULL if the plane is really enabled

    or

        - drivers have to ensure that the real state in fact mirrors the
          initial default as encoded in the state (plane disabled)

References: http://lists.freedesktop.org/archives/dri-devel/2015-January/075578.htmlReviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Thierry Reding <treding@nvidia.com>

There is no use-case where it would be useful for drivers not to
implement this function and the transitional plane helpers already
require drivers to provide an implementation.

v2: add new requirement to kerneldoc
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Thierry Reding <treding@nvidia.com>

kfree(ERR_PTR(-ENOMEM)) will not work very well.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>

We can't save two values to the IRQ flags at the same time so the IRQs
are not enabled at the end.  This kind of bug is easy to miss in testing
if the function is normally called with IRQs disabled so we wouldn't
enable IRQs anyway.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>

Compliance testing shows that HS Trail is off by -12%. Increase the HS
Trail time to make this test pass.
Signed-off-by: David Ung <davidu@nvidia.com>
[treding@nvidia.com: update specification references, add comment]
Signed-off-by: Thierry Reding <treding@nvidia.com>

This allows a DRM driver unload/reload cycle to completely reset the DSI
controller and may help in situations where it's broken.
Signed-off-by: Thierry Reding <treding@nvidia.com>

This reset is necessary to properly clean up the internal state of the
controller.
Signed-off-by: Thierry Reding <treding@nvidia.com>

Use a sized unsigned 32-bit data type (u32) to store register contents.
The DSI registers are 32 bits wide irrespective of the architecture's
data width.
Signed-off-by: Thierry Reding <treding@nvidia.com>

Use a sized unsigned 32-bit data type (u32) to store register contents.
The HDMI registers are 32 bits wide irrespective of the architecture's
data width.
Signed-off-by: Thierry Reding <treding@nvidia.com>

This prevents the compiler from warning about using a variable that is
possibly uninitialized.
Signed-off-by: Thierry Reding <treding@nvidia.com>

Most of the display controller's registers are double-buffered, a few of
them are triple-buffered. The ASSEMBLY shadow copy is latched intto the
ACTIVE copy for double-buffered registers. For triple-buffered registers
the ASSEMBLY copy is first latched into the ARM copy.

Latching into the ACTIVE copy happens immediately if the controller is
inactive. Otherwise the latching happens on the next frame boundary. The
latching of the ASSEMBLY into the ARM copy happens immediately. Latching
is controlled by a set of *_ACT_REQ and *_UPDATE bits in the
DC_CMD_STATE_CONTROL register.
Signed-off-by: Thierry Reding <treding@nvidia.com>

Tegra114 and earlier support specifying the color of the border (i.e.
the active area of the screen that is not covered by any of the overlay
windows). By default this is set to a light blue, so set it to black to
comply with the requirements set by atomic modesetting.
Signed-off-by: Thierry Reding <treding@nvidia.com>

iommu_domain_alloc() returns NULL on error, it never returns error
pointers.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>

The possible_crtcs mask needs to be a mask of CRTC indices. There is no
guarantee that the DRM indices match the hardware pipe number, so the
mask must be computed from the CRTC index.
Signed-off-by: Thierry Reding <treding@nvidia.com>

The DRM core now zeroes out the memory associated with CRTC, encoder and
connector objects upon cleanup, so there's no need to explicitly do that
in drivers anymore.
Signed-off-by: Thierry Reding <treding@nvidia.com>

The iommu_map_sg() function is now available in the IOMMU API, so drop
the open-coded variant.
Signed-off-by: Thierry Reding <treding@nvidia.com>

Previously the struct bus_type exported by the host1x infrastructure was
only a very basic skeleton. Turn that implementation into a more full-
fledged bus to support proper probe ordering and power management.

Note that the bus infrastructure needs to be available before any of the
drivers can be registered. This is automatically ensured if all drivers
are built as loadable modules (via symbol dependencies). If all drivers
are built-in there are no such guarantees and the link order determines
the initcall ordering. Adjust drivers/gpu/Makefile to make sure that the
host1x bus infrastructure is initialized prior to any of its users (only
drm/tegra currently).

v2: Fix building host1x and tegra-drm as modules
Reported-by: Dave Airlie <airlied@gmail.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Mark Zhang <markz@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>

This function is needed in several places, so factor it out.
Signed-off-by: Thierry Reding <treding@nvidia.com>

Instead of locking within host1x_device_add(), call it under the lock to
make the locking more consistent.
Signed-off-by: Thierry Reding <treding@nvidia.com>

When a driver's ->probe() function fails, the host1x bus must not call
its ->remove() function because the driver will already have cleaned up
in the error handling path in ->probe().
Signed-off-by: Thierry Reding <treding@nvidia.com>

Backmerge Linus tree after rc5 + drm-fixes went in.

There were a few amdkfd conflicts I wanted to avoid,
and Ben requested this for nouveau also.

Conflicts:
	drivers/gpu/drm/amd/amdkfd/Makefile
	drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
	drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager.c
	drivers/gpu/drm/amd/amdkfd/kfd_priv.h
	drivers/gpu/drm/amd/include/kgd_kfd_interface.h
	drivers/gpu/drm/i915/intel_runtime_pm.c
	drivers/gpu/drm/radeon/radeon_kfd.c

Merge branch 'drm-sti-next-add-dvo' of git://git.linaro.org/people/benjamin.gaignard/kernel into drm-next

This patch enable the last big hardware feature of my driver: the
connector for panel.
Like for HMDI and HDA, Digital Video Out (DVO) create brige, encoder
and connector
drm objects.

* 'drm-sti-next-add-dvo' of git://git.linaro.org/people/benjamin.gaignard/kernel:
  drm: sti: add DVO output connector

Add atmel HLCDC driver.

* tag 'atmel-hlcdc-drm-3.20' of https://github.com/bbrezillon/linux-at91:
  drm: add DT bindings documentation for atmel-hlcdc-dc driver
  drm: add Atmel HLCDC Display Controller support
  drm: panel: simple-panel: add bus format information for foxlink panel
  drm: panel: simple-panel: add support for bus_format retrieval
  drm: add bus_formats and num_bus_formats fields to drm_display_info

- Infrastructure work in amdkfd to prepare for VI support. This work mainly
  includes separating modules into ASIC-specific functionality, adding
  new properties that are relevant for VI, making sure that shared code is
  reused, etc.

- Improve mechanism of submitting packets to HIQ (the kernel queue that amdkfd
  uses to issue commands to the GPU). The driver used to verify that each CS
  was read by the GPU. However, this proved to be both unnecessary and erroneous.
  Therefore, we cancelled this verification.

- Moved initialization of compute VMIDs into radeon driver

- Various minor fixes

* tag 'drm-amdkfd-next-2015-01-21' of git://people.freedesktop.org/~gabbayo/linux: (22 commits)
  drm/amdkfd: Fix description of sched_policy module parameter
  drm/amdkfd: Remove sync_with_hw() from amdkfd
  drm/amdkfd: Remove unused function busy_wait()
  drm/amdkfd: Replace cpu_relax() with schedule() in DQM
  drm/amdkfd: Fix for-loop when allocating HQD (non-HWS)
  drm/amdkfd: Add initial VI support for KQ
  drm/amdkfd: Encapsulate KQ functions in ops structure
  drm/amdkfd: Add initial VI support for DQM
  drm/amdkfd: Encapsulate DQM functions in ops structure
  drm/amdkfd: Don't BUG on freeing GART sub-allocation
  drm/amdkfd: Fix logic of destroy_queue_nocpsch()
  MAINTAINERS: Update amdkfd files
  drm/amdkfd: Change MQD manager to be H/W specific
  drm/amdkfd: Add asic property to kfd_device_info
  drm/amdkfd: Make KFD_MQD_TYPE enum types H/W agnostic
  drm/amdkfd: Add new VI-specific queue properties
  drm/radeon: Use new cik_structs.h file
  drm/amdkfd: Don't include header files from radeon
  drm/amd: Put cik structures in a common place
  drm/radeon: Don't use relative paths in #include
  ...

Pull superh tracing fix from Steven Rostedt:
 "It's been reported that function tracing does not work on the sh
  architecture because gcc 4.8 for superH does not support -m32, and the
  recordmcount.pl script adds "-m32" when re-compiling the object files
  with the mcount locations.

  I was not able to reproduce this problem, as it seems that -m32 works
  fine for my cross compiler gcc 4.6.3, but I have to assume that -m32
  was deprecated somewhere between 4.6 and 4.8.  As it still seems to
  compile fine without -m32, I have no reason not to add this patch, as
  having -m32 seems to cause trouble for others"

* tag 'trace-sh-3.19' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
  scripts/recordmcount.pl: There is no -m32 gcc option on Super-H anymore

The Atmel HLCDC (HLCD Controller) IP available on some Atmel SoCs (i.e.
at91sam9n12, at91sam9x5 family or sama5d3 family) provides a display
controller device.

The HLCDC block provides a single RGB output port, and only supports LCD
panels connection to LCD panels for now.

The atmel,panel property link the HLCDC RGB output with the LCD panel
connected on this port (note that the HLCDC RGB connector implementation
makes use of the DRM panel framework).

Connection to other external devices (DRM bridges) might be added later by
mean of a new atmel,xxx (atmel,bridge) property.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>

The Atmel HLCDC (HLCD Controller) IP available on some Atmel SoCs (i.e.
at91sam9n12, at91sam9x5 family or sama5d3 family) provides a display
controller device.

This display controller supports at least one primary plane and might
provide several overlays and an hardware cursor depending on the IP
version.

At the moment, this driver only implements an RGB connector to interface
with LCD panels, but support for other kind of external devices might be
added later.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Tested-by: Anthony Harivel <anthony.harivel@emtrion.de>
Tested-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>

Foxlink's fl500wvr00-a0t supports RGB888 format.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Acked-by: Thierry Reding <treding@nvidia.com>

Provide a way to specify panel requirement in terms of supported media bus
format (particularly useful for panels connected to an RGB or LVDS bus).
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Acked-by: Thierry Reding <treding@nvidia.com>

Add bus_formats and num_bus_formats fields and
drm_display_info_set_bus_formats helper function to specify the bus
formats supported by a given display.

This information can be used by display controller drivers to configure
the output interface appropriately (i.e. RGB565, RGB666 or RGB888 on raw
RGB or LVDS busses).
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
Acked-by: Thierry Reding <treding@nvidia.com>

Pull sound fixes from Takashi Iwai:
 "This batch contains two fixes for FireWire lib module and a quirk for
  yet another Logitech WebCam.  The former is the fixes for MIDI
  handling I forgot to pick up during the merge window.  All the fixed
  code is pretty local and shouldn't give any regressions"

* tag 'sound-3.19-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
  ALSA: usb-audio: Add mic volume fix quirk for Logitech Webcam C210
  ALSA: firewire-lib: limit the MIDI data rate
  ALSA: firewire-lib: remove rx_blocks_for_midi quirk

Pull drm fixes from Dave Airlie:
 "Just back from LCA + some days off, had some fixes from the past 2 weeks,

  Some amdkfd code removal for a feature that wasn't ready, otherwise
  just one fix for core helper sleeping, exynos, i915, and radeon fixes.

  I thought I had some sti fixes but they were already in, and it
  confused me for a few mins this morning"

* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
  drm: fb helper should avoid sleeping in panic context
  drm/exynos: fix warning of vblank reference count
  drm/exynos: remove unnecessary runtime pm operations
  drm/exynos: fix reset codes for memory mapped hdmi phy
  drm/radeon: use rv515_ring_start on r5xx
  drm/radeon: add si dpm quirk list
  drm/radeon: don't print error on -ERESTARTSYS
  drm/i915: Fix mutex->owner inspection race under DEBUG_MUTEXES
  drm/i915: Ban Haswell from using RCS flips
  drm/i915: vlv: sanitize RPS interrupt mask during GPU idling
  drm/i915: fix HW lockup due to missing RPS IRQ workaround on GEN6
  drm/i915: gen9: fix RPS interrupt routing to CPU vs. GT
  drm/exynos: remove the redundant machine checking code
  drm/radeon: add a dpm quirk list
  drm/amdkfd: Fix sparse warning (different address space)
  drm/radeon: fix VM flush on CIK (v3)
  drm/radeon: fix VM flush on SI (v3)
  drm/radeon: fix VM flush on cayman/aruba (v3)
  drm/amdkfd: Drop interrupt SW ring buffer

Pull MFD fixes from Lee Jones:
 - Avoid platform ID collision in da9052
 - Skip caching volatile registers in tps65218
 - Use correct address base in tps65218
 - Repair deadlock on suspend in rtsx_usb

* tag 'mfd-fixes-3.19' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd:
  mfd: rtsx_usb: Fix runtime PM deadlock
  mfd: tps65218: Make INT1 our status_base register
  mfd: tps65218: Make INT[12] and STATUS registers volatile
  mfd: da9052-core: Fix platform-device id collision

imx-drm mode fixup support, imx-hdmi bridge conversion and imx-drm cleanup

- Implement mode_fixup for a DI vertical timing limitation
- Use generic DRM OF helpers in DRM core
- Convert imx-hdmi to dw_hdmi drm_bridge and add rockchip
  driver
- Add DC use counter to fix multi-display support
- Simplify handling of DI clock flags
- A few small fixes and cleanup

* tag 'imx-drm-next-2015-01-09' of git://git.pengutronix.de/git/pza/linux: (26 commits)
  imx-drm: core: handling of DI clock flags to ipu_crtc_mode_set()
  gpu: ipu-di: Switch to DIV_ROUND_CLOSEST for DI clock divider calc
  gpu: ipu-v3: Use videomode in struct ipu_di_signal_cfg
  imx-drm: encoder prepare/mode_set must use adjusted mode
  imx-drm: ipuv3-crtc: Implement mode_fixup
  drm_modes: add drm_display_mode_to_videomode
  gpu: ipu-di: remove some non-functional code
  gpu: ipu-di: Add ipu_di_adjust_videomode()
  drm: rockchip: export functions needed by rockchip dw_hdmi bridge driver
  drm: bridge/dw_hdmi: request interrupt only after initializing the mutes
  drm: bridge/dw_hdmi: add rockchip rk3288 support
  dt-bindings: Add documentation for rockchip dw hdmi
  drm: bridge/dw_hdmi: add function dw_hdmi_phy_enable_spare
  drm: bridge/dw_hdmi: clear i2cmphy_stat0 reg in hdmi_phy_wait_i2c_done
  drm: bridge/dw_hdmi: add mode_valid support
  drm: bridge/dw_hdmi: add support for multi-byte register width access
  dt-bindings: add document for dw_hdmi
  drm: imx: imx-hdmi: move imx-hdmi to bridge/dw_hdmi
  drm: imx: imx-hdmi: split phy configuration to platform driver
  drm: imx: imx-hdmi: convert imx-hdmi to drm_bridge mode
  ...

* 'drm/next/du' of git://linuxtv.org/pinchartl/fbdev:
  drm: rcar-du: Implement support for interlaced modes
  drm: rcar-du: Clamp DPMS states to on and off
  drm: rcar-du: Enable hotplug detection on HDMI connector
  drm: rcar-du: Output HSYNC instead of CSYNC
  drm: rcar-du: Add support for external pixel clock
  drm: rcar-du: Refactor DEFR8 feature
  drm: rcar-du: Remove LVDS and HDMI encoders chaining restriction
  drm: rcar-du: Configure pitch for chroma plane of multiplanar formats
  drm: rcar-du: Don't fail probe in case of partial encoder init error
  drm: adv7511: Remove interlaced mode check