Some drivers need to be able to have a perfect race-free fbcon setup.
Current drivers only enable hotplug processing after the call to
drm_fb_helper_initial_config which leaves a tiny but important race.

This race is especially noticable on embedded platforms where the
driver itself enables the voltage for the hdmi output, since only then
will monitors (after a bit of delay, as usual) respond by asserting
the hpd pin.

Most of the infrastructure is already there with the split-out
drm_fb_helper_init. And drm_fb_helper_initial_config already has all
the required locking to handle concurrent hpd events since

commit 53f1904b
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Thu Mar 20 14:26:35 2014 +0100

    drm/fb-helper: improve drm_fb_helper_initial_config locking

The only missing bit is making drm_fb_helper_hotplug_event save
against concurrent calls of drm_fb_helper_initial_config. The only
unprotected bit is the check for fb_helper->fb.

With that drivers can first initialize the fb helper, then enabel
hotplug processing and then set up the initial config all in a
completely race-free manner. Update kerneldoc and convert i915 as a
proof of concept.

Feature requested by Thierry since his tegra driver atm reliably boots
slowly enough to misses the hotplug event for an external hdmi screen,
but also reliably boots to quickly for the hpd pin to be asserted when
the fb helper calls into the hdmi ->detect function.

Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Fix a sparse warning: ttm_bo_reserve()'s last argument is a
pointer to a struct, so use NULL as nullpointer.
Signed-off-by: NMartin Kepplinger <martink@posteo.de>
Reviewed-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Use module_init instead of late_initcall, as is the norm for modular
drivers.

module_init was used until 6e8de0bd
("drm/tilcdc: add encoder slave (v2)") changed it to a late_initcall,
but it does not explain why. Tests show it's working properly with
module_init.
Signed-off-by: NGuido Martínez <guido@vanguardiasur.com.ar>
Tested-by: NDarren Etheridge <detheridge@ti.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The TI tilcdc driver is designed with a notion of submodules. Currently,
at unload time, these submodules are iterated and destroyed.

Now that the tilcdc remove order is fixed, this can be handled perfectly
by the kernel using the device infrastructure, since each submodule
is a kernel driver itself, and they are only destroy()'ed at unload
time. Therefore we move the destroy() functionality to each submodule's
remove().

Also, remove some checks in the unloading process since the new code
guarantees the resources are allocated and need a release.
Signed-off-by: NGuido Martínez <guido@vanguardiasur.com.ar>
Tested-by: NDarren Etheridge <detheridge@ti.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

display_timings_release calls kfree on the display_timings object passed
to it. Calling kfree after it is wrong. SLUB debug showed the following
warning:

    =============================================================================
    BUG kmalloc-64 (Tainted: G        W    ): Object already free
    -----------------------------------------------------------------------------

    Disabling lock debugging due to kernel taint
    INFO: Allocated in of_get_display_timings+0x2c/0x214 age=601 cpu=0
    pid=884
     __slab_alloc.constprop.79+0x2e0/0x33c
     kmem_cache_alloc+0xac/0xdc
     of_get_display_timings+0x2c/0x214
     panel_probe+0x7c/0x314 [tilcdc]
     platform_drv_probe+0x18/0x48
     [..snip..]
    INFO: Freed in panel_destroy+0x18/0x3c [tilcdc] age=0 cpu=0 pid=907
     __slab_free+0x34/0x330
     panel_destroy+0x18/0x3c [tilcdc]
     tilcdc_unload+0xd0/0x118 [tilcdc]
     drm_dev_unregister+0x24/0x98
     [..snip..]
Signed-off-by: NGuido Martínez <guido@vanguardiasur.com.ar>
Tested-by: NDarren Etheridge <detheridge@ti.com>
Cc: <stable@vger.kernel.org> #v3.9+
Signed-off-by: NDave Airlie <airlied@redhat.com>

Unregister resources in the correct order on tilcdc_drm_fini, which is
the reverse order they were registered during tilcdc_drm_init.

This also means unregistering the driver before releasing its resources.
Signed-off-by: NGuido Martínez <guido@vanguardiasur.com.ar>
Tested-by: NDarren Etheridge <detheridge@ti.com>
Cc: <stable@vger.kernel.org> #v3.9+
Signed-off-by: NDave Airlie <airlied@redhat.com>

The driver did not unregister the allocated framebuffer, which caused
memory leaks (and memory manager WARNs) when unloading. Also, the
framebuffer device under /dev still existed after unloading.

Add a call to drm_fbdev_cma_fini when unloading the module to prevent
both issues.
Signed-off-by: NGuido Martínez <guido@vanguardiasur.com.ar>
Tested-by: NDarren Etheridge <detheridge@ti.com>
Cc: <stable@vger.kernel.org> #v3.9+
Signed-off-by: NDave Airlie <airlied@redhat.com>

Add a drm_sysfs_connector_remove call when we destroy the panel to make
sure the connector node in sysfs gets deleted.

This is required for proper unload and re-load of this driver, otherwise
we will get a warning about a duplicate filename in sysfs.
Signed-off-by: NGuido Martínez <guido@vanguardiasur.com.ar>
Tested-by: NDarren Etheridge <detheridge@ti.com>
Cc: <stable@vger.kernel.org> #v3.9+
Signed-off-by: NDave Airlie <airlied@redhat.com>

Add a drm_sysfs_connector_remove call when we destroy the panel to make
sure the connector node in sysfs gets deleted.

This is required for proper unload and re-load of this driver as a
module. Without this, we would get a warning at re-load time like so:

   tda998x 0-0070: found TDA19988
   ------------[ cut here ]------------
   WARNING: CPU: 0 PID: 825 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x54/0x74()
   sysfs: cannot create duplicate filename '/class/drm/card0-HDMI-A-1'
   Modules linked in: [..]
   CPU: 0 PID: 825 Comm: modprobe Not tainted 3.15.0-rc4-00027-g9dcdef4 #82
   [<c0013bb8>] (unwind_backtrace) from [<c0011824>] (show_stack+0x10/0x14)
   [<c0011824>] (show_stack) from [<c0034e8c>] (warn_slowpath_common+0x68/0x88)
   [<c0034e8c>] (warn_slowpath_common) from [<c0034edc>] (warn_slowpath_fmt+0x30/0x40)
   [<c0034edc>] (warn_slowpath_fmt) from [<c01243f4>] (sysfs_warn_dup+0x54/0x74)
   [<c01243f4>] (sysfs_warn_dup) from [<c0124708>] (sysfs_do_create_link_sd.isra.2+0xb0/0xb8)
   [<c0124708>] (sysfs_do_create_link_sd.isra.2) from [<c02ae37c>] (device_add+0x338/0x520)
   [<c02ae37c>] (device_add) from [<c02ae6e8>] (device_create_groups_vargs+0xa0/0xc4)
   [<c02ae6e8>] (device_create_groups_vargs) from [<c02ae758>] (device_create+0x24/0x2c)
   [<c02ae758>] (device_create) from [<c029b4ec>] (drm_sysfs_connector_add+0x64/0x204)
   [<c029b4ec>] (drm_sysfs_connector_add) from [<bf0b1b40>] (slave_modeset_init+0x120/0x1bc [tilcdc])
   [<bf0b1b40>] (slave_modeset_init [tilcdc]) from [<bf0b2be8>] (tilcdc_load+0x214/0x4c0 [tilcdc])
   [<bf0b2be8>] (tilcdc_load [tilcdc]) from [<c029955c>] (drm_dev_register+0xa4/0x104)
      [..snip..]
   ---[ end trace 4df8d614936ebdee ]---
   [drm:drm_sysfs_connector_add] *ERROR* failed to register connector device: -17
Signed-off-by: NGuido Martínez <guido@vanguardiasur.com.ar>
Tested-by: NDarren Etheridge <detheridge@ti.com>
Cc: <stable@vger.kernel.org> #v3.9+
Signed-off-by: NDave Airlie <airlied@redhat.com>

Add a drm_sysfs_connector_remove call when we destroy the panel to make
sure the connector node in sysfs gets deleted.

This is required for proper unload and re-load of this driver as a
module. Without this, we would get a warning at re-load time like so:

   ------------[ cut here ]------------
   WARNING: CPU: 0 PID: 824 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x54/0x74()
   sysfs: cannot create duplicate filename '/class/drm/card0-LVDS-1'
   Modules linked in: [...]
   CPU: 0 PID: 824 Comm: modprobe Not tainted 3.15.0-rc4-00027-g6484f96-dirty #81
   [<c0013bb8>] (unwind_backtrace) from [<c0011824>] (show_stack+0x10/0x14)
   [<c0011824>] (show_stack) from [<c0034e8c>] (warn_slowpath_common+0x68/0x88)
   [<c0034e8c>] (warn_slowpath_common) from [<c0034edc>] (warn_slowpath_fmt+0x30/0x40)
   [<c0034edc>] (warn_slowpath_fmt) from [<c01243f4>] (sysfs_warn_dup+0x54/0x74)
   [<c01243f4>] (sysfs_warn_dup) from [<c0124708>] (sysfs_do_create_link_sd.isra.2+0xb0/0xb8)
   [<c0124708>] (sysfs_do_create_link_sd.isra.2) from [<c02ae37c>] (device_add+0x338/0x520)
   [<c02ae37c>] (device_add) from [<c02ae6e8>] (device_create_groups_vargs+0xa0/0xc4)
   [<c02ae6e8>] (device_create_groups_vargs) from [<c02ae758>] (device_create+0x24/0x2c)
   [<c02ae758>] (device_create) from [<c029b4ec>] (drm_sysfs_connector_add+0x64/0x204)
   [<c029b4ec>] (drm_sysfs_connector_add) from [<bf0b1fec>] (panel_modeset_init+0xb8/0x134 [tilcdc])
   [<bf0b1fec>] (panel_modeset_init [tilcdc]) from [<bf0b2bf0>] (tilcdc_load+0x214/0x4c0 [tilcdc])
   [<bf0b2bf0>] (tilcdc_load [tilcdc]) from [<c029955c>] (drm_dev_register+0xa4/0x104)
      [ .. snip .. ]
   ---[ end trace b2d09cd9578b0497 ]---
   [drm:drm_sysfs_connector_add] *ERROR* failed to register connector device: -17
Signed-off-by: NGuido Martínez <guido@vanguardiasur.com.ar>
Tested-by: NDarren Etheridge <detheridge@ti.com>
Cc: <stable@vger.kernel.org> #v3.9+
Signed-off-by: NDave Airlie <airlied@redhat.com>

The "flags" parameter of the DRM_IOCTL_MODE_ADDFB2 ioctl must be
propagated and used by the driver.
The only possible value of flags is DRM_MODE_FB_INTERLACED.
Signed-off-by: NFabien Dessenne <fabien.dessenne@st.com>
Reviewed-by: NBenjamin GAIGNARD <benjamin.gaignard@st.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

bo->mem.placement is not initialized when ttm_bo_man_get_node is called,
so the flag had no effect at all.

v2: change nouveau and vmwgfx as well
Signed-off-by: NChristian König <christian.koenig@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

Fix checkpatch warning:
WARNING: kfree(NULL) is safe this check is probably not required

Cc: David Airlie <airlied@linux.ie>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: NFabian Frederick <fabf@skynet.be>
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>

use mm.h definition
Signed-off-by: NFabian Frederick <fabf@skynet.be>
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>

Nouveau can now be used on ARM, so add an ioprot handler for this
architecture.
Signed-off-by: NLucas Stach <dev@lynxeye.de>
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>

We introduced render-nodes about 1/2 year ago and no problems showed up.
Remove the drm_rnodes argument and enable them by default now.
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>

drm_gem_get_pages() currently allows passing a 'gfp' parameter that is
passed to shmem combined with mapping_gfp_mask(). Given that the default
mapping_gfp_mask() is GFP_HIGHUSER, it is _very_ unlikely that anyone will
ever make use of that parameter. In fact, all drivers currently pass
redundant flags or 0.

This patch removes the 'gfp' parameter. The only reason to keep it is to
remove flags like __GFP_WAIT. But in its current form, it can only be used
to add flags. So to remove __GFP_WAIT, you'd have to drop it from the
mapping_gfp_mask, which again is stupid as this mask is used by shmem-core
for other allocations, too.

If any driver ever requires that parameter, we can introduce a new helper
that takes the raw 'gfp' parameter. The caller'd be responsible to combine
it with mapping_gfp_mask() in a suitable way. The current
drm_gem_get_pages() helper would then simply use mapping_gfp_mask() and
call the new helper. This is what shmem_read_mapping_pages{_gfp,} does
right now.

Moreover, the gfp-zone flag-usage is not obvious: If you pass a modified
zone, shmem core will WARN() or even BUG(). In other words, the following
must be true for 'gfp' passed to shmem_read_mapping_pages_gfp():
    gfp_zone(mapping_gfp_mask(mapping)) == gfp_zone(gfp)
Add a comment to drm_gem_read_pages() explaining that constraint.
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>

OMAP requires bo-pages to be in the DMA32 zone. Explicitly request this by
setting __GFP_DMA32 as mapping-gfp-mask during shmem initialization. This
drops HIGHMEM from the gfp-mask and uses DMA32 instead. shmem-core takes
care to relocate pages during swap-in in case they have been loaded into
the wrong zone.

It is _not_ possible to pass __GFP_DMA32 to shmem_read_mapping_page_gfp()
as the page might have already been swapped-in at that time. The zone-mask
must be set during initialization and be kept constant for now.

Remove the now superfluous TODO in omap_gem.c.
Reviewed-by: NRob Clark <robdclark@gmail.com>
Tested-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>

Contrary to the host-backed shader interface that has a per-context
name-space for shaders, the compat shader namespace was per client
(or rather, per file). Fix this so that the compat shader namespace is per
context, and at the same time, make command buffer managed context resource
management generic.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NJakob Bornecrantz <jakob@vmware.com>

For Haswell and Broadwell, if the display power well has been disabled,
the display audio controller divider values EM4 M VALUE and EM5 N VALUE
will have been lost. The CDCLK frequency is required for reprogramming them
to generate 24MHz HD-A link BCLK. So provide a private interface for the
audio driver to query CDCLK.

This is a stopgap solution until a more generic interface between audio
and display drivers has been implemented.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NMengdong Lin <mengdong.lin@intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Commit "drm/vmwgfx: correct fb_fix_screeninfo.line_length", while fixing a
vmwgfx fbdev bug, also writes the pitch to a supposedly read-only register:
SVGA_REG_BYTES_PER_LINE, while it should be (and also in fact is) written to
SVGA_REG_PITCHLOCK.

This patch is Cc'd stable because of the unknown effects writing to this
register might have, particularly on older device versions.

v2: Updated log message.

Cc: stable@vger.kernel.org
Cc: Christopher Friedt <chrisfriedt@gmail.com>
Tested-by: NChristopher Friedt <chrisfriedt@gmail.com>
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NJakob Bornecrantz <jakob@vmware.com>

1539fb9b managed to somehow +x
drm_drv.c undo it.
Signed-off-by: NDave Airlie <airlied@redhat.com>

Userspace shouldn't be able to access them.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Volatile bit was in the wrong location.  This bit is
not used at the moment.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

This prevents a panic: radeon_crtc_handle_page_flip() could run before
radeon_flip_work_func(), triggering the BUG_ON() in drm_vblank_put().
Tested-by: NDieter Nützel <Dieter@nuetzel-hh.de>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NMichel Dänzer <michel.daenzer@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

We were using the vddc mask rather than the vddci mask.

Bug:
https://bugzilla.kernel.org/show_bug.cgi?id=79071

May also fix:
https://bugs.freedesktop.org/show_bug.cgi?id=69723

Noticed by: Dieter Nützel <Dieter@nuetzel-hh.de>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

We were using the vddc mask rather than the vddci mask.

Bug:
https://bugzilla.kernel.org/show_bug.cgi?id=79071

Possibly also fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=68571Noticed-by: NJonathan Howard <jonathan@unbiased.name>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

v2: agd5f: compile fix
Signed-off-by: NStefan Brüns <stefan.bruens@rwth-aachen.de>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Signed-off-by: NStefan Brüns <stefan.bruens@rwth-aachen.de>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Some monitors seem to have problems with deep color enabled, even
though they claim to support it.  I'm not sure if the monitor
need a quirk or if the driver is doing something the monitor doesn't
like.  At this point lets just disable deep color by default like
we did for hdmi audio and work through the bugs so we can eventually
enable it by default.

bug:
https://bugs.freedesktop.org/show_bug.cgi?id=80531Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

bapm enabled the GPU and CPU to share TDP headroom.  It was
disabled by default since some laptops hung when it was enabled
in conjunction with dpm.  It seems to be stable on desktop
boards and fixes hangs on boot with dpm enabled on certain
boards, so enable it by default on desktop boards.

bug:
https://bugs.freedesktop.org/show_bug.cgi?id=72921Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

bapm allows the GPU and CPU to share TDP.  This allows
for additional performance out of the GPU and CPU when
the headroom is available.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Newer asics shouldn't need any manual adjustment.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Set the default to 600Mhz if it's not set in the bios,
and bump the default to 600Mhz if it's lower than that.

This fixes display issues with certain 4k DP monitors when
using 5.4 Ghz DP clocks.

v2: fix typo.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Drop WA to fix Voltage not getting dropped to Vmin when Gfx is power
gated for latest VLV revision.

Workaround fixed in Latest VLV revision. Forcing Gfx clk up not needed,
and Requesting the min freq should bring bring the voltage Vnn.

v2: Drop WA for Latest VLV revision (Ville)
Signed-off-by: NDeepak S <deepak.s@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
[Jani: modified code comment, reformatted the commit message a bit.]
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Apparently we can't trust this field on other platforms and need to find
some other way.

This fixes a regression introduced in
commit 27da3bdf
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Fri Apr 4 16:12:07 2014 -0700

    drm/i915: use VBT to determine whether to enumerate the VGA port
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

BDW signals the flip done interrupt immediately after the DSPSURF write
when the plane is disabled. This is true even if we've already armed
DSPCNTR to enable the plane at the next vblank. This causes major
problems for our page flip code which relies on the flip done interrupts
happening at vblank time.

So what happens is that we enable the plane, and immediately allow
userspace to submit a page flip. If the plane is still in the process
of being enabled when the page flip is issued, the flip done gets
signalled immediately. Our DSPSURFLIVE check catches this to prevent
premature flip completion, but it also means that we don't get a flip
done interrupt when the plane actually gets enabled, and so the page
flip is never completed.

Work around this by re-introducing blocking vblank waits on BDW
whenever we enable the primary plane.

I removed some of the vblank waits here:
 commit 6304cd91
 Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
 Date:   Fri Apr 25 13:30:12 2014 +0300

    drm/i915: Drop the excessive vblank waits from modeset codepaths

To avoid these blocking vblank waits we should start using the vblank
interrupt instead of the flip done interrupt to complete page flips.
But that's material for another patch.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79354Tested-by: NGuo Jinxian <jinxianx.guo@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

The TDA998x can't handle modes with clocks above 150MHz, or resolutions
larger than 8192x2048.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

One of Jean-Francois patches changed the EDID polling to once every
10ms for 10 interations, whereas the original code did 1ms for 100
interations.  This appears to cause boot-time detection to take
noticably longer.  Revert this change.
Acked-by: NJean-Francois Moine <moinejf@free.fr>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Currently tda998x_encoder_destroy() calls cec_write() and reg_clear(),
as part of the release procedure. Such calls need to access the I2C bus
and therefore, we need to call them before drm_i2c_encoder_destroy()
which unregisters the I2C device.

This commit moves the latter so it's done afterwards.
Signed-off-by: NGuido Martínez <guido@vanguardiasur.com.ar>
Signed-off-by: NEzequiel García <ezequiel@vanguardiasur.com.ar>
Cc: <stable@vger.kernel.org> #v3.9+
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>