Keeping the modes in the same order as we probe them makes it a bit
easier to track what's happening.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Preserve the destination mode's list head in drm_mode_copy. Just
in case someone decides that it's a good idea to overwrite a mode which
happens to be on some list,
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NThomas Meyer <thomas@m3y3r.de>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NThomas Meyer <thomas@m3y3r.de>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NThomas Meyer <thomas@m3y3r.de>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The structures and strings involved with various pretty-print functions
aren't meant to be modified, so make them all const. The exception is
drm_connector_enum_list which does get modified in drm_connector_init().

While at it move the drm_get_connector_status_name() prototype from
drmP.h to drm_crtc.h where it belongs.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Use drm_get_format_name to print more readable pixel format names
in debug output.

Also unify the debug messages to say "unsupported pixel format",
which better describes what is going on.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Rather than just printing the pixel format as a hex number, decode the
fourcc into human readable form, and also decode the LE vs. BE flag.

Keep printing the raw hex number too in case it contains non-printable
characters.

Some examples what the new drm_get_format_name() produces:
DRM_FORMAT_XRGB8888: "XR24 little-endian (0x34325258)"
DRM_FORMAT_YUYV: "YUYV little-endian (0x56595559)"
DRM_FORMAT_RGB565|DRM_FORMAT_BIG_ENDIAN: "RG16 big-endian (0xb6314752)"
Unprintable characters: "D??? big-endian (0xff7f0244)"

v2: Fix patch author
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This allows importing bo's to own device to work without requiring that the buffer is pinned in GART.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@canonical.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Prevents buffers from being pinned forever.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@canonical.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: NRob Clark <robdclark@gmail.com>

The CMA-specific mapping code will be used to implement dma-buf mmap
support.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: NRob Clark <robdclark@gmail.com>

This allows creating a GEM CMA object without an associated DMA memory
buffer, and will be used to implement DRM PRIME support.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: NRob Clark <robdclark@gmail.com>

The dma-buf mmap code was copied from the GEM mmap implementation.
Replace it with the new drm_gem_mmap_obj() function.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: NRob Clark <robdclark@gmail.com>

The drm_gem_mmap() function first finds the GEM object to be mapped
based on the fake mmap offset and then maps the object. Split the object
mapping code into a standalone drm_gem_mmap_obj() function that can be
used to implement dma-buf mmap() operations.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: NRob Clark <robdclark@gmail.com>

Signed-off-by: NSteffen Trumtrar <s.trumtrar@pengutronix.de>
Signed-off-by: NDave Airlie <airlied@redhat.com>

I didn't fix this in the earlier patch -- it would have broken the
build due to the now-deleted garbage in drm_os_linux.h.
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NAndy Lutomirski <luto@amacapital.net>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NAndy Lutomirski <luto@amacapital.net>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

i915 open-coded logic that was essentially equivalent to the new API.
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NAndy Lutomirski <luto@amacapital.net>
Signed-off-by: NDave Airlie <airlied@redhat.com>

I'm not sure I understand the intent of the previous behavior.  mmap
on /dev/agpgart and DRM_AGP maps had no cache flags set, so they
would be fully cacheable.  But the DRM code (most of the time) would
add a write-combining MTRR that would change the effective memory
type to WC.

The new behavior just requests WC explicitly for all AGP maps.

If there is any code out there that expects cacheable access to the
AGP aperture (because the drm driver doesn't request an MTRR or
because it's using /dev/agpgart directly), then it will now end up
with a UC or WC mapping, depending on the architecture and PAT
availability.  But cacheable access to the aperture seems like it's
asking for trouble, because, AIUI, the aperture is an alias of RAM.
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NAndy Lutomirski <luto@amacapital.net>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Previously, DRM_FRAME_BUFFER mappings, as well as DRM_REGISTERS
mappings with DRM_WRITE_COMBINING set, resulted in an unconditional
MTRR being added but the actual mappings being created as UC-.

Now these mappings have the MTRR added only if needed, but they will
be mapped with pgprot_writecombine.

The non-WC DRM_REGISTERS case now uses pgprot_noncached instead of
hardcoding the bit twiddling.

The DRM_AGP case is unchanged for now.

[airlied: fix ppc build]
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NAndy Lutomirski <luto@amacapital.net>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This replaces drm_mtrr_{add,del} with arch_phys_wc_{add,del}.  The
interface is simplified (because the base and size parameters to
drm_mtrr_del never did anything), and it no longer adds MTRRs on
systems that don't need them.
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NAndy Lutomirski <luto@amacapital.net>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Just the usual printk related warnings.
Signed-off-by: NDave Airlie <airlied@redhat.com>

radeon currently uses a drm function to get the speed capabilities for
the bus, drm_pcie_get_speed_cap_mask. However, this is a non-standard
method of performing this detection and this patch changes it to use
the max_bus_speed attribute.

From: Lucas Kannebley Tavares <lucaskt@linux.vnet.ibm.com>
Signed-off-by: NKleber Sacilotto de Souza <klebers@linux.vnet.ibm.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

This narrows the scope of the apple re-POST hack added in:
drm/radeon: re-POST the asic on Apple hardware when booted via EFI

That patch prevents UVD from working on macs when booted in EFI
mode.  The original patch fixed macbook2,1 systems which were
r5xx and hence have no UVD.  Limit the hack to those systems to
prevent UVD breakage on newer systems.

Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=63935

Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Acked-by: NMatthew Garrett <matthew.garrett@nebula.com>

Skip checking crtcs in hardware without them.  Avoids checking
non-existent hardware.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Newer asics have variable numbers of crtcs.  Use that
rather than the asic family to determine which crtcs
to check.  This avoids checking non-existent crtcs or
missing crtcs on certain asics.
Reviewed-by: NMichel Dänzer <michel.daenzer@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Should be 5 rather than 2.

Noticed by sroland and glisse on IRC.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

The chip id for SUMO2 isn't used.

fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=63935Tested-By: NDave Witbrodt <dawitbro@sbcglobal.net>
Signed-off-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Signed-off-by: NAndrew Jones <drjones@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

devm_request_threaded_irq is used instead of request_threaded_irq
and free_irq is removed.
Signed-off-by: NSeung-Woo Kim <sw0312.kim@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

devm_kfree does not need for fail case of probe function and for
remove function.
Signed-off-by: NSeung-Woo Kim <sw0312.kim@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

Becuase of order of headers, there are build warnings and they are
fixed with this patch.
Signed-off-by: NSeung-Woo Kim <sw0312.kim@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

Struct device pointer got from platform device pointer is already
alsigned as variable, but some functions do not use device pointer.
So this patch replaces thoes usages.
Signed-off-by: NSeung-Woo Kim <sw0312.kim@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

This patch fixes the issue that drm_vblank_get() is failed.

The issus occurs when next page flip request is tried
if previous page flip event wasn't completed yet and then
dpms became off.

So this patch make sure that page flip event is completed
before dpms goes to off.
Signed-off-by: NInki Dae <inki.dae@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>

Rebased.
Signed-off-by: NRob Clark <rob@ti.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

During DP AUX communication we might time out 1 jiffy too early, because
the calculated expiry jiffy value is one less than needed.

This is only one reason for false DP AUX timeouts. For a complete
solution we also need the following fix, which is now queued for
mainline: http://marc.info/?l=linux-kernel&m=136748515710837&w=2

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64133Signed-off-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

At the moment wait_event_timeout/wait_event_interruptible_timeout may
time out 1 jiffy too early, as the calculated expiry time is 1 less than
needed. Besides timing out too early this also means that the
calculation of the remaining time will be incorrect and we will pass a
non-zero remaining time to user space in case of a time out. This is one
reason for the following bugzilla report:

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64270Signed-off-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We need this to avoid premature timeouts whenever scheduling a timeout
based on the current jiffies value. For an explanation see [1].
The following patches will take the helper into use.

Once the more generic solution proposed in the thread at [1] is accepted
this patch can be reverted while keeping the follow-up patches.

[1] http://marc.info/?l=linux-kernel&m=136854294730957&w=2Signed-off-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>