This patch adds component framework support to resolve
the probe order issue.

Until now, exynos drm had used codes specific to exynos drm
to resolve that issue so with this patch, the specific codes
are removed.
Signed-off-by: NInki Dae <inki.dae@samsung.com>

Signed-off-by: NInki Dae <inki.dae@samsung.com>

If any fimd channel was already active, initializing iommu will result
in a PAGE FAULT (e.e. u-boot could have turned on the display and
not disabled it before the kernel starts). This patch checks if any
channel is active before initializing iommu and disables it.
Signed-off-by: NAkshu Agrawal <akshu.a@samsung.com>
Signed-off-by: NPrathyush K <prathyush.k@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

In the case of that only one branch of a conditional statement is
a single statement, braces are added to both branches.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

The site-specific OOM messages are unnecessary, because they
duplicate the MM subsystem generic OOM message.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

Make local symbols static, because these are used only in this
file.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

Make local symbole static, because this is used only in this file.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

Exynos drm driver cannot support DRIVER_HAVE_IRQ feature because it uses
driver specific one instead of routine of drm framework to
install/uninstall irq handler.
Signed-off-by: NJoonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

AFAICT, the fb_base of a drm_device's mode_config is never used.  It isn't
accessed by core drm, it isn't used by fbmem, and it isn't exposed to user
space.

Furthermore, it is probably supposed to be a physical address, not the
dma address mapped to the display controller, so this is just wrong.
Signed-off-by: NDaniel Kurtz <djkurtz@chromium.org>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

Kernel access to the eyxnos fbdev framebuffer is via its gem object's
kernel mapping (kvaddr, stored in info->screen_base).

User space access is provided by mmap(), read() and write() of /dev/fb/fb0.
These functions also only use screen_base/screen_size().

Therefore, it is not necessary to set fix->smem_{start,len} or
fix->mmio_{start,len} fields.

This avoids leaking kernel, physical and dma mapped addresses to user
space via the ioctls FBIOGET_VSCREENINFO and FBIOGET_FSCREENINFO.
Signed-off-by: NDaniel Kurtz <djkurtz@chromium.org>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

This adds an encoder type for DP MST encoders.
Reviewed-by: NTodd Previte <tprevite@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This makes drm_get_encoder_name() thread safe.

Reference: http://lkml.kernel.org/r/645ee6e22cad47d38a2b35c21c8d5fe3@DC1-MBX-01\
.ptsecurity.ru
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This makes drm_get_connector_name() thread safe.

[airlied: fix to build.]

Reference: http://lkml.kernel.org/r/645ee6e22cad47d38a2b35c21c8d5fe3@DC1-MBX-01.ptsecurity.ruSigned-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

shmem_read_mapping_page() uses mapping_gfp_mask(mapping) as default gfp
mask. No reason to use shmem_read_mapping_page_gfp() directly if we want
the default behavior.
Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

shmem supports page-relocations during swapin since quite some time. It
was implemented in:

    commit bde05d1c
    Author: Hugh Dickins <hughd@google.com>
    Date:   Tue May 29 15:06:38 2012 -0700

        shmem: replace page if mapping excludes its zone

The gem-comment about wrongly placed DMA32 pages is no longer valid.
Replace it with a proper comment but keep the BUG_ON() to verify correct
shmem behavior.
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This issue was reported by coccicheck using the semantic patch
at scripts/coccinelle/api/memdup.cocci
Signed-off-by: NBenoit Taine <benoit.taine@lip6.fr>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The shmobile DRM driver is only useful on SuperH and shmobile unless
build testing. I am dropping the SuperH dependencies though because
the driver doesn't even build there, so in practice it is an arm-only
driver for now.
Signed-off-by: NJean Delvare <jdelvare@suse.de>
Acked-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The Renesas R-Car Display Unit driver is only useful on shmobile
unless build testing. The LVDS output is useful on an even more
reduced hardware set.
Signed-off-by: NJean Delvare <jdelvare@suse.de>
Acked-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The 800x600 (SVGA) screen resolution was lacking in the set of
built-in selectable EDID screen resolutions that can be used to
repair misbehaving monitor firmware.

This patch adds the related data set and expands the documentation.
Note that the SVGA bit occupies a different byte to all the existing
users of the established timing bits forcing a rework of the
ESTABLISHED_TIMINGS_BITS macro.

Tested new EDID on an aged (and misbehaving) industrial LCD panel;
existing EDIDs still pass edid-decode's checksum checks.
Signed-off-by: NDaniel Thompson <daniel.thompson@linaro.org>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: David Airlie <airlied@linux.ie>
Cc: Carsten Emde <C.Emde@osadl.org>
Cc: linux-doc@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NRob Clark <robdclark@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This is the initial attempt at porting the DP501 code from the userspace
driver,

the firmware file is in
http://people.freedesktop.org/~airlied/ast_dp501_fw.bin

this should really be exposed as another encoder/connector that is cloneable

v0.2:
init 3rd tx properly,
add scratch reduction of VRAM size
backup firmware properly.
Signed-off-by: NDave Airlie <airlied@redhat.com>

we'll need these elsewhere for dp501.
Signed-off-by: NDave Airlie <airlied@redhat.com>

This resyncs the dram post code with the upstream X.org driver
where ast have improved the code for setting up the dram chips.
Signed-off-by: NDave Airlie <airlied@redhat.com>

This is ported from the userspace driver.

Untested on any ast2400 hw so far.
Signed-off-by: NDave Airlie <airlied@redhat.com>

This syncs up the mode code from the X.org driver upstream,
and adds the mode validation step for hw that doesn't have
widescreen.

v2: (from Egbert Eich <eich@suse.de)
squash drm/ast: Use correct structure member for mode validation
to avoid bisect regression.

In struct drm_display_mode crtc_hdisplay and crtc_vdisplay are holding
the crtc parameters after mode fixup. For validation we need hdisplay and
vdisplay.
Signed-off-by: NEgbert Eich <eich@suse.de>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This mode group id_list was never being freed.

v2: take David's suggestion to free in minor_free.
Signed-off-by: NDave Airlie <airlied@redhat.com>

We won't be calling intel_enable_primary_plane() or
intel_disable_primary_plane() with the primary plane in the
wrong state. So remove the useless DISPLAY_PLANE_ENABLE checks.

v2: Convert the checks to WARNs instead (Daniel,Paulo)
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

On ILK when we disable a particular watermark level, we must
maintain the actual watermark values for that level for some time
(until the next vblank possibly). Otherwise we risk underruns.

In order to achieve that result we must merge the LP1+ watermarks a
bit differently since we must also merge levels that are to be
disabled. We must also make sure we don't overflow the fields in the
watermark registers in case the calculated watermarks come out too
big to fit.

As early as possbile we mark all computed watermark levels as
disabled if they would exceed the register maximums. We make sure
to leave the actual watermarks for such levels zeroed out. Then during
merging, we take the maxium values for every level, regardless if
they're disabled or not. That may seem a bit pointless since at the
moment all the watermark levels we merge should have their values
zeroed if the level is already disabled. However soon we will be
dealing with intermediate watermarks that, in addition to the new
watermark values, also contain the previous watermark values, and so
levels that are disabled may no longer be zeroed out.

v2: Split the patch in two (Paulo)
    Use if() instead of & when merging ->enable (Paulo)
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Fix commit message as noted by Paulo.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

When we calculate the watermarks for a pipe make sure we leave any
level fully zeroed out if it would exceed any of the maximum values
that fit in the registers.

This will be important later when we start to use also disabled
watermark levels during LP1+ merging.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Add trace points for observing the atomic pipe update mechanism.

v2: Rebased due to earlier changes
v3: Pass intel_crtc instead of drm_crtc (Daniel)
v4: Pass frame counter from the caller to evaded/end since
    the caller now always has that ready
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NSourab Gupta <sourabgupta@gmail.com>
Reviewed-by: NAkash Goel <akash.goels@gmail.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Move the primary plane enable/disable to occur atomically with the
sprite update that caused the primary plane visibility to change.

FBC and IPS enable/disable is left to happen well before or after
the primary plane change.

v2: Pass intel_crtc instead of drm_crtc (Daniel)
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NSourab Gupta <sourabgupta@gmail.com>
Reviewed-by: NAkash Goel <akash.goels@gmail.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Add a mechanism by which we can evade the leading edge of vblank. This
guarantees that no two sprite register writes will straddle on either
side of the vblank start, and that means all the writes will be latched
together in one atomic operation.

We do the vblank evade by checking the scanline counter, and if it's too
close to the start of vblank (too close has been hardcoded to 100usec
for now), we will wait for the vblank start to pass. In order to
eliminate random delayes from the rest of the system, we operate with
interrupts disabled, except when waiting for the vblank obviously.

Note that we now go digging through pipe_to_crtc_mapping[] in the
vblank interrupt handler, which is a bit dangerous since we set up
interrupts before the crtcs. However in this case since it's the vblank
interrupt, we don't actually unmask it until some piece of code
requests it.

v2: preempt_check_resched() calls after local_irq_enable() (Jesse)
    Hook up the vblank irq stuff on BDW as well
v3: Pass intel_crtc instead of drm_crtc (Daniel)
    Warn if crtc.mutex isn't locked (Daniel)
    Add an explicit compiler barrier and document the barriers (Daniel)
    Note the irq vs. modeset setup madness in the commit message (Daniel)
v4: Use prepare_to_wait() & co. directly and eliminate vbl_received
v5: Refactor intel_pipe_handle_vblank() vs. drm_handle_vblank() (Chris)
    Check for min/max scanline <= 0 (Chris)
    Don't call intel_pipe_update_end() if start failed totally (Chris)
    Check that the vblank counters match on both sides of the critical
    section (Chris)
v6: Fix atomic update for interlaced modes
v7: Reorder code for better readability (Chris)
v8: Drop preempt_check_resched(). It's not available to modules
    anymore and isn't even needed unless we ourselves cause
    a wakeup needing reschedule while interrupts are off
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NSourab Gupta <sourabgupta@gmail.com>
Reviewed-by: NAkash Goel <akash.goels@gmail.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

All the rest of the code to enable this is in my branch. Without my
branch, hitting > 32b offsets is impossible. The code has always
"supported" 64b, but it's never actually been run of tested. This change
doesn't actually fix anything. [1] I am not sure why X won't work yet. I
do not get hangs or obvious errors.

There are 3 fixes grouped together here. First is to remove the
hardcoded 0 for the upper dword of the relocation. The next fix is to
use a 64b value for target_offset. The final fix is to not directly
apply target_offset to reloc->delta. reloc->delta is part of ABI, and so
we cannot change it. As it stands, 32b is enough to represent everything
we're interested in representing anyway. The main problem is, we cannot
add greater than 32b values to it directly.

[1] Almost all of intel-gpu-tools is not yet ready to test 64b
relocations. There are a few places that expect 32b values for offsets
and these all won't work.

Cc: Rafael Barbalho <rafael.barbalho@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Previously, our code only had a 32b offset value for where the
batchbuffer starts. With full PPGTT, and 64b canonical GPU address
space, that is an insufficient value. The code to expand is pretty
straight forward, and only one platform needs to do anything with the
extra bits.
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NRafael Barbalho <rafael.barbalho@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

SDVO is used by both crtcs using the i9xx_ and the ironlake_
functions. For both cases there is nothing between the
encoder->mode_set and the encoder->pre_enable calls that touches the
hardware.

The vlv_ functions are different since they enable the pll before the
->pre_enable hook. But SDVO isn't supported on vlv platforms, so this
doesn't matter.

We've also already clean up all the sdvo state computation logic, all
relevant parts are already in the ->compute_config hook.  So we can
just get rid of the ->mode_set hook by converting it to a ->pre_enable
hook.
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We only set a few bits in the ADPA register, which we then read back
in the enable/disable hooks. So we can just move that bit of state
computation code to the place where we need it since setting these
bits without enabling the CRT encoder has no effects.

The only exceptions are the hotplug bits since they affect the hotplug
detection logic, but we already set those in the ->reset function and
then never touch them.
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Currently for the i9xx crtc hooks there's nothing between the call to
encoder->mode_set and encoder->pre_enable which touches the hardware.

Therefore, since tv is only used on gen3/4, we can just move the hook.
Yay for easy cases!

The only other important thing to check is that the new
->pre_enable hook is idempotent wrt the sw state since now it can
be called multiple times (due to DPMS). After a the bit of refactoring
this is now easy to check: It only reads crtc->config and computes
derived state but otherwise leaves it as-is, so we're good.
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The pipe and plane _are_ disabled when we call this. So replace it
all with the corresponding assert (as self-documenting code) and
rip out all the lore.

Checking for a disabled plane would require us to export those macros
from intel_display.c, but if the pipe is off the plane isn't working
either. So this single check is good enough.
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We only support TV-out on gen3/4 mobile platforms, and i915gm is the
only one that matches.
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

intel_tv_mode_set is still too bug.
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>