summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2015-11-11drm/ast: Initialized data needed to map fbdev memoryEgbert Eich4-0/+11
Due to a missing initialization there was no way to map fbdev memory. Thus for example using the Xserver with the fbdev driver failed. This fix adds initialization for fix.smem_start and fix.smem_len in the fb_info structure, which fixes this problem. Requested-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: stable@vger.kernel.org Signed-off-by: Egbert Eich <eich@suse.de> [pulled from SuSE tree by me - airlied] Signed-off-by: Dave Airlie <airlied@redhat.com>
2015-11-10drm/vc4: Add dependency on HAVE_DMA_ATTRS, and select DRM_GEM_CMA_HELPERGuenter Roeck1-1/+2
Avoid the following build errors, seen with m68k:allmodconfig and other architectures which do not support HAVE_DMA_ATTRS. ERROR: "drm_gem_cma_create" [drivers/gpu/drm/vc4/vc4.ko] undefined! ERROR: "drm_gem_cma_prime_mmap" [drivers/gpu/drm/vc4/vc4.ko] undefined! ERROR: "drm_gem_cma_prime_get_sg_table" [drivers/gpu/drm/vc4/vc4.ko] undefined! ERROR: "drm_gem_cma_vm_ops" [drivers/gpu/drm/vc4/vc4.ko] undefined! ERROR: "drm_gem_cma_mmap" [drivers/gpu/drm/vc4/vc4.ko] undefined! ERROR: "drm_gem_cma_prime_vunmap" [drivers/gpu/drm/vc4/vc4.ko] undefined! ERROR: "drm_gem_cma_prime_import_sg_table" [drivers/gpu/drm/vc4/vc4.ko] undefined! ERROR: "drm_gem_cma_free_object" [drivers/gpu/drm/vc4/vc4.ko] undefined! ERROR: "drm_gem_cma_prime_vmap" [drivers/gpu/drm/vc4/vc4.ko] undefined! ERROR: "drm_gem_cma_dumb_map_offset" [drivers/gpu/drm/vc4/vc4.ko] undefined! ERROR: "drm_gem_cma_create" [drivers/gpu/drm/drm_kms_helper.ko] undefined! ERROR: "drm_gem_cma_describe" [drivers/gpu/drm/drm_kms_helper.ko] undefined! ERROR: "drm_gem_cma_free_object" [drivers/gpu/drm/drm_kms_helper.ko] undefined! Acked-by: Eric Anholt <eric@anholt.net> Fixes: c8b75bca92cb ("drm/vc4: Add KMS support for Raspberry Pi.") Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Dave Airlie <airlied@redhat.com>
2015-11-07Merge tag 'drm-intel-next-fixes-2015-11-06' of ↵Dave Airlie7-24/+79
git://anongit.freedesktop.org/drm-intel into drm-next Here's a handful of i915 fixes for drm-next/v4.4. Imre's commit alone should address the remaining warnings galore you experienced on Skylake. Almost all of the rest are also fixes against user or QA reported bugs, with references. * tag 'drm-intel-next-fixes-2015-11-06' of git://anongit.freedesktop.org/drm-intel: drm/i915/skl: disable display side power well support for now drm/i915: Extend DSL readout fix to BDW and SKL. drm/i915: Do graphics device reset under forcewake drm/i915: Skip fence installation for objects with rotated views (v4) drm/i915: add quirk to enable backlight on Dell Chromebook 11 (2015) drm/i915/skl: Prevent unclaimed register writes on skylake. drm/i915: disable CPU PWM also on LPT/SPT backlight disable drm/i915: Fix maxfifo watermark calc on vlv cursor planes drm/i915: add hotplug activation period to hotplug update mask
2015-11-07Merge branch 'vmwgfx-next' of git://people.freedesktop.org/~thomash/linux ↵Dave Airlie6-100/+42
into drm-next One is fix for a regression in 4.3, One irq locking rework. * 'vmwgfx-next' of git://people.freedesktop.org/~thomash/linux: drm/vmwgfx: Relax irq locking somewhat drm/vmwgfx: Properly flush cursor updates and page-flips
2015-11-06drm/vmwgfx: Relax irq locking somewhatThomas Hellstrom4-99/+39
Relax locking with the goal of reducing the number of locking cycles and time spent with irqs disabled. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Sinclair Yeh <syeh@vmware.com>
2015-11-06drm/vmwgfx: Properly flush cursor updates and page-flipsThomas Hellstrom2-1/+3
With the introduction of the new command buffer mechanism, proper care wasn't taken to flush cursor image updates and event-less screen-target page-flips. Fix this by introducing explicit flush points. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Brian Paul <brianp@vmware.com>
2015-11-06drm/i915/skl: disable display side power well support for nowImre Deak2-2/+21
The display power well support on this platform is in a somewhat broken state atm, so disable it by default. This in effect will get rid of incorrect assert WARNs about the CSR/DMC firmware not being loaded during power well toggling. It also removes a problem during driver loading where a register is accessed while its backing power well is down, resulting in another WARN. Until we come up with the root cause of the second problem and the proper fix for both issues, keep all display side power wells on. Also clarify a bit the option description. Reported-by: Dave Airlie <airlied@redhat.com> Reference: http://mid.gmane.org/CAPM=9tyjBQjSBTKa49cRr6SYkpNW7Pq-fUFznZZ8Y1snvvk7mA@mail.gmail.com Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446757451-2777-1-git-send-email-imre.deak@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-11-06drm/i915: Extend DSL readout fix to BDW and SKL.Maarten Lankhorst1-1/+1
Those platforms have the same bug as haswell, and the same fix applies to them. The original HSW fix that this extends is commit 41b578fb0e8b930f2470d3f673b0fa279e77a7b8 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Tue Sep 22 12:15:54 2015 -0700 drm/i915: workaround bad DSL readout v3 Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: stable@vger.kernel.org # v4.3 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91579 Link: http://patchwork.freedesktop.org/patch/msgid/1446535913-31970-3-git-send-email-maarten.lankhorst@linux.intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-11-05drm/i915: Do graphics device reset under forcewakeMika Kuoppala1-1/+10
We have a timed release of a forcewake when using I915_READ/WRITE macros. wait_for() macro will go to quite long sleep if the first read doesn't satisfy the condition for successful exit. With these two interacting, it is possible that we lose the forcewake during the wait_for() and the subsequent read will reaquire forcewake. Further experiments with skl shows that when we lose forcewake, we lose the reset request we submitted. So reset request register is not power context saved. Grab forcewakes for all engines before starting the reset/request dance so that all requests stay valid for the duration of reset requisition across all the engines. v2: Add comment on power well sleeps. Wrap the reset handling under forcewake instead of just reset requests (Chris) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92774 Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Tomi Sarvela <tomix.p.sarvela@intel.com> (v1, v2) Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446721898-1450-1-git-send-email-mika.kuoppala@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-11-05drm/i915: Skip fence installation for objects with rotated views (v4)Vivek Kasireddy1-16/+20
While pinning a fb object to the display plane, only install a fence if the object is using a normal view. This corresponds with the behavior found in i915_gem_object_do_pin() where the fencability criteria is determined only for objects with normal views. v2: Look at the object's map_and_fenceable flag to determine whether to install a fence or not (Chris). v3: Pin and unpin a fence only if the current view type is normal. v4: Extend the "view type is normal" check for pin_fence as well. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Ville Syrjala <ville.syrjala@linux.intel.com> Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446170078-20792-1-git-send-email-vivek.kasireddy@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-11-05vga_switcheroo: Drop client power state VGA_SWITCHEROO_INITLukas Wunner1-2/+0
hda_intel.c:azx_probe() defers initialization of an audio controller on the discrete GPU if the GPU is powered off. The power state of the GPU is determined by calling vga_switcheroo_get_client_state(). vga_switcheroo_get_client_state() returns VGA_SWITCHEROO_INIT if vga_switcheroo is not enabled, i.e. if no second GPU or no handler has registered. This can go wrong in the following scenario: - Driver for the integrated GPU is not loaded. - Driver for the discrete GPU registers with vga_switcheroo, uses driver power control to power down the GPU, handler cuts power to the GPU. - Driver for the audio controller gets loaded after the GPU was powered down, calls vga_switcheroo_get_client_state() which returns VGA_SWITCHEROO_INIT instead of VGA_SWITCHEROO_OFF. - Consequence: azx_probe() tries to initialize the audio controller even though the GPU is powered down. The power state VGA_SWITCHEROO_INIT was introduced by c8e9cf7bb240 ("vga_switcheroo: Add a helper function to get the client state"). It is not apparent what its benefit might be. The idea seems to be to initialize the audio controller even if the power state is VGA_SWITCHEROO_OFF (were vga_switcheroo enabled), but as shown above this can fail. Drop VGA_SWITCHEROO_INIT to solve this. Acked-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Dave Airlie <airlied@redhat.com>
2015-11-05Merge tag 'drm/panel/for-4.4-rc1' of ↵Dave Airlie2-2/+0
git://anongit.freedesktop.org/tegra/linux into drm-next drm/panel: Changes for v4.4-rc1 Just two small cleanup patches to fix coccinelle warnings. * tag 'drm/panel/for-4.4-rc1' of git://anongit.freedesktop.org/tegra/linux: drm/bridge: ptn3460: Fix coccinelle warnings drm/bridge: ps8622: Fix coccinelle warnings
2015-11-05Merge tag 'drm/tegra/for-4.4-rc1' of ↵Dave Airlie6-21/+20
git://anongit.freedesktop.org/tegra/linux into drm-next drm/tegra: Changes for v4.4-rc1 Just a couple of minor fixes and cleanups for this cycle. * tag 'drm/tegra/for-4.4-rc1' of git://anongit.freedesktop.org/tegra/linux: drm/tegra: dc: Request/free syncpoint at init/exit drm/tegra: fb: Remove gratuituous blank line gpu: host1x: Fix MLOCK's debug info
2015-11-05Merge tag 'imx-drm-next-2015-10-30' of ↵Dave Airlie5-10/+119
git://git.pengutronix.de/git/pza/linux into drm-next imx-drm fixes and color format updates - Some correctness fixes found by coccinelle - Add drivers/gpu/ipu-v3 directory to MAINTAINERS - Add support for more color formats - Fix a regression, making displays larger than FullHD work again * tag 'imx-drm-next-2015-10-30' of git://git.pengutronix.de/git/pza/linux: drm/imx: hdmi: fix HDMI setup to allow modes larger than FullHD gpu: ipu-v3: fix div_ratio type gpu: ipu-v3: csi: add support for 8 bpp grayscale sensors. drm/imx: enable ARGB4444 16-bit color format gpu: ipu-v3: add support for ARGB4444 16-bit color format drm/imx: ipuv3-plane: enable support for RGBX8888 and RGBA8888 pixel formats gpu: ipu-v3: add support for RGBX8888 and RGBA8888 pixel formats drm/imx: enable 15-bit RGB with 1-bit alpha formats gpu: ipu-v3: add support for 15-bit RGB with 1-bit alpha formats MAINTAINERS: Add IPUv3 core driver to the i.MX DRM driver section gpu: ipu-v3: ipu-csi: bool test doesn't need a comparison to false
2015-11-05Merge branch 'drm-next-4.4' of git://people.freedesktop.org/~agd5f/linux ↵Dave Airlie25-498/+31339
into drm-next - Updated register headers for GFX 8.1 for Stoney - Add some new CZ revisions - minor pageflip optimizations - Fencing clean up - Warning fix - More fence cleanup - oops fix - Fiji fixes * 'drm-next-4.4' of git://people.freedesktop.org/~agd5f/linux: (29 commits) drm/amdgpu: group together common fence implementation drm/amdgpu: remove AMDGPU_FENCE_OWNER_MOVE drm/amdgpu: remove now unused fence functions drm/amdgpu: fix fence fallback check drm/amdgpu: fix stoping the scheduler timeout drm/amdgpu: cleanup on error in amdgpu_cs_ioctl() drm/amdgpu: update Fiji's Golden setting drm/amdgpu: update Fiji's rev id drm/amdgpu: extract common code in vi_common_early_init drm/amd/scheduler: don't oops on failure to load drm/amdgpu: don't oops on failure to load (v2) drm/amdgpu: don't VT switch on suspend drm/amdgpu: Make amdgpu_mn functions inline drm/amdgpu: remove amdgpu_fence_ref/unref drm/amdgpu: use common fence for sync drm/amdgpu: use the new fence_is_later drm/amdgpu: use common fences for VMID management v2 drm/amdgpu: move ring_from_fence to common code drm/amdgpu: switch to common fence_wait_any_timeout v2 drm/amdgpu: remove unneeded fence functions ...
2015-11-04drm/amdgpu: group together common fence implementationChristian König1-97/+109
And also add some missing function documentation. No functional change. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Chunming Zhou <david1.zhou@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2015-11-04drm/amdgpu: remove AMDGPU_FENCE_OWNER_MOVEChristian König3-4/+3
Moves are exclusive operations anyway, just use the undefined owner for those. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Chunming Zhou <david1.zhou@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2015-11-04drm/amdgpu: remove now unused fence functionsChristian König1-39/+0
Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Chunming Zhou <david1.zhou@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2015-11-04drm/amdgpu: fix fence fallback checkChristian König1-0/+2
Interrupts are notorious unreliable, enable the fallback at a couple of more places. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Chunming Zhou <david1.zhou@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2015-11-04drm/amdgpu: fix stoping the scheduler timeoutChristian König1-1/+1
cancel_delayed_work_sync is forbidden in interrupt context. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Chunming Zhou <david1.zhou@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2015-11-04drm/amdgpu: cleanup on error in amdgpu_cs_ioctl()Dan Carpenter1-2/+4
We recently changed the locking in this function and now there is a missing unlock on error. Also there are some other resources that we should probably release as well... Fixes: f48b2659f521 ('drm/amdgpu: fix the broken vm->mutex V2') Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
2015-11-04drm/i915: Fix locking around GuC firmware loadDaniel Stone2-8/+5
The GuC firmware load requires struct_mutex to create a GEM object, but this collides badly with request_firmware. Move struct_mutex locking down into the loader itself, so we don't hold it across the entire load process, including request_firmware. [ 20.451400] ====================================================== [ 20.451420] [ INFO: possible circular locking dependency detected ] [ 20.451441] 4.3.0-rc5+ #1 Tainted: G W [ 20.451457] ------------------------------------------------------- [ 20.451477] plymouthd/371 is trying to acquire lock: [ 20.451494] (&dev->struct_mutex){+.+.+.}, at: [<ffffffffa0093c62>] drm_gem_mmap+0x112/0x290 [drm] [ 20.451538] but task is already holding lock: [ 20.451557] (&mm->mmap_sem){++++++}, at: [<ffffffff811fd9ac>] vm_mmap_pgoff+0x8c/0xf0 [ 20.451591] which lock already depends on the new lock. [ 20.451617] the existing dependency chain (in reverse order) is: [ 20.451640] -> #3 (&mm->mmap_sem){++++++}: [ 20.451661] [<ffffffff8110644e>] lock_acquire+0xce/0x1c0 [ 20.451683] [<ffffffff8120ec9a>] __might_fault+0x7a/0xa0 [ 20.451705] [<ffffffff8127e34e>] filldir+0x9e/0x130 [ 20.451726] [<ffffffff81295b86>] dcache_readdir+0x186/0x230 [ 20.451748] [<ffffffff8127e117>] iterate_dir+0x97/0x130 [ 20.451769] [<ffffffff8127e66a>] SyS_getdents+0x9a/0x130 [ 20.451790] [<ffffffff8184f2f2>] entry_SYSCALL_64_fastpath+0x12/0x76 [ 20.451829] -> #2 (&sb->s_type->i_mutex_key#2){+.+.+.}: [ 20.451852] [<ffffffff8110644e>] lock_acquire+0xce/0x1c0 [ 20.451872] [<ffffffff8184b516>] mutex_lock_nested+0x86/0x400 [ 20.451893] [<ffffffff81277790>] walk_component+0x1d0/0x2a0 [ 20.451914] [<ffffffff812779f0>] link_path_walk+0x190/0x5a0 [ 20.451935] [<ffffffff8127803b>] path_openat+0xab/0x1260 [ 20.451955] [<ffffffff8127a651>] do_filp_open+0x91/0x100 [ 20.451975] [<ffffffff81267e67>] file_open_name+0xf7/0x150 [ 20.451995] [<ffffffff81267ef3>] filp_open+0x33/0x60 [ 20.452014] [<ffffffff8157e1e7>] _request_firmware+0x277/0x880 [ 20.452038] [<ffffffff8157e9e4>] request_firmware_work_func+0x34/0x80 [ 20.452060] [<ffffffff810c7020>] process_one_work+0x230/0x680 [ 20.452082] [<ffffffff810c74be>] worker_thread+0x4e/0x450 [ 20.452102] [<ffffffff810ce511>] kthread+0x101/0x120 [ 20.452121] [<ffffffff8184f66f>] ret_from_fork+0x3f/0x70 [ 20.452140] -> #1 (umhelper_sem){++++.+}: [ 20.452159] [<ffffffff8110644e>] lock_acquire+0xce/0x1c0 [ 20.452178] [<ffffffff8184c5c1>] down_read+0x51/0xa0 [ 20.452197] [<ffffffff810c203b>] usermodehelper_read_trylock+0x5b/0x130 [ 20.452221] [<ffffffff8157e147>] _request_firmware+0x1d7/0x880 [ 20.452242] [<ffffffff8157e821>] request_firmware+0x31/0x50 [ 20.452262] [<ffffffffa01b54a4>] intel_guc_ucode_init+0xf4/0x400 [i915] [ 20.452305] [<ffffffffa0213913>] i915_driver_load+0xd63/0x16e0 [i915] [ 20.452343] [<ffffffffa00987d9>] drm_dev_register+0xa9/0xc0 [drm] [ 20.452369] [<ffffffffa009ae3d>] drm_get_pci_dev+0x8d/0x1e0 [drm] [ 20.452396] [<ffffffffa01521e4>] i915_pci_probe+0x34/0x50 [i915] [ 20.452421] [<ffffffff81464675>] local_pci_probe+0x45/0xa0 [ 20.452443] [<ffffffff81465a6d>] pci_device_probe+0xfd/0x140 [ 20.452464] [<ffffffff8156a2e4>] driver_probe_device+0x224/0x480 [ 20.452486] [<ffffffff8156a5c8>] __driver_attach+0x88/0x90 [ 20.452505] [<ffffffff81567cf3>] bus_for_each_dev+0x73/0xc0 [ 20.452526] [<ffffffff81569a7e>] driver_attach+0x1e/0x20 [ 20.452546] [<ffffffff815695ae>] bus_add_driver+0x1ee/0x280 [ 20.452566] [<ffffffff8156b100>] driver_register+0x60/0xe0 [ 20.453197] [<ffffffff81464050>] __pci_register_driver+0x60/0x70 [ 20.453845] [<ffffffffa009b070>] drm_pci_init+0xe0/0x110 [drm] [ 20.454497] [<ffffffffa027f092>] 0xffffffffa027f092 [ 20.455156] [<ffffffff81002123>] do_one_initcall+0xb3/0x200 [ 20.455796] [<ffffffff811d8c01>] do_init_module+0x5f/0x1e7 [ 20.456434] [<ffffffff8114c4e6>] load_module+0x2126/0x27d0 [ 20.457071] [<ffffffff8114cdf9>] SyS_finit_module+0xb9/0xf0 [ 20.457738] [<ffffffff8184f2f2>] entry_SYSCALL_64_fastpath+0x12/0x76 [ 20.458370] -> #0 (&dev->struct_mutex){+.+.+.}: [ 20.459773] [<ffffffff8110584f>] __lock_acquire+0x191f/0x1ba0 [ 20.460451] [<ffffffff8110644e>] lock_acquire+0xce/0x1c0 [ 20.461074] [<ffffffffa0093c88>] drm_gem_mmap+0x138/0x290 [drm] [ 20.461693] [<ffffffff8121a5ec>] mmap_region+0x3ec/0x670 [ 20.462298] [<ffffffff8121abb2>] do_mmap+0x342/0x420 [ 20.462901] [<ffffffff811fd9d2>] vm_mmap_pgoff+0xb2/0xf0 [ 20.463532] [<ffffffff81218f62>] SyS_mmap_pgoff+0x1f2/0x290 [ 20.464118] [<ffffffff8102187b>] SyS_mmap+0x1b/0x30 [ 20.464702] [<ffffffff8184f2f2>] entry_SYSCALL_64_fastpath+0x12/0x76 [ 20.465289] other info that might help us debug this: [ 20.467179] Chain exists of: &dev->struct_mutex --> &sb->s_type->i_mutex_key#2 --> &mm->mmap_sem [ 20.468928] Possible unsafe locking scenario: [ 20.470161] CPU0 CPU1 [ 20.470745] ---- ---- [ 20.471325] lock(&mm->mmap_sem); [ 20.471902] lock(&sb->s_type->i_mutex_key#2); [ 20.472538] lock(&mm->mmap_sem); [ 20.473118] lock(&dev->struct_mutex); [ 20.473704] *** DEADLOCK *** Signed-off-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2015-11-03drm/amdgpu: update Fiji's Golden settingFlora Cui1-7/+15
Change-Id: Ic3f3bfce4767cc05d04f6eb24e22a0f3e7ceacaa Signed-off-by: Flora Cui <Flora.Cui@amd.com> Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
2015-11-03drm/amdgpu: update Fiji's rev idFlora Cui1-0/+5
Change-Id: I0018e2b72feb771683c57960ba3ce942bec5d3ab Signed-off-by: Flora Cui <Flora.Cui@amd.com> Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
2015-11-03drm/amdgpu: extract common code in vi_common_early_initFlora Cui1-6/+3
Change-Id: I9ed25353c559e27bc1b1d5b50f977b0ff03de87f Signed-off-by: Flora Cui <Flora.Cui@amd.com> Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
2015-11-03drm/amd/scheduler: don't oops on failure to loadDave Airlie1-1/+2
In two places amdgpu tries to tear down something it hasn't initalised when failing. This is what happens when you enable experimental support on topaz which then fails in ring init. This patch allows it to fail cleanly. agd: Split out from from the original patch since the scheduler is a driver independent. Reviewed-by: Chunming Zhou <david1.zhou@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2015-11-03drm/amdgpu: don't oops on failure to load (v2)Dave Airlie1-0/+3
In two places amdgpu tries to tear down something it hasn't initalised when failing. This is what happens when you enable experimental support on topaz which then fails in ring init. This patch allows it to fail cleanly. v2 (agd): split out scheduler change into a separate patch Reviewed-by: Chunming Zhou <david1.zhou@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2015-11-03drm/amdgpu: don't VT switch on suspendAlex Deucher1-0/+1
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2015-11-03Merge branch 'linux-4.4' of ↵Dave Airlie73-373/+1312
git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-next - Vast improvements to gk20a instmem handling. - Improved PGOB detection + GK107 support. - Compatibility between old/new interfaces added, final missing piece to finally enabling userspace to start using them. - Kepler GDDR5 PLL stability improvements - Support for non-GPIO (PWM) voltage controllers - G8x/GT2xx memory clock improvements - Misc other fixes * 'linux-4.4' of git://anongit.freedesktop.org/git/nouveau/linux-2.6: (45 commits) drm/nouveau: bump patchlevel to indicate availability of abi16/nvif interop drm/nouveau/abi16: implement limited interoperability with usif/nvif drm/nouveau/abi16: introduce locked variant of nouveau_abi16_get() drm/nouveau/abi16: remove unused argument from nouveau_abi16_get() drm/nouveau/pci: enable c800 magic for Medion Erazer X7827 drm/nouveau/pci: enable c800 magic for Lenovo Y510P drm/nouveau/pll/gk104: fix PLL instability due to bad configuration with gddr5 drm/nouveau/clk/g84: Enable reclocking for GDDR3 G94-G200 drm/nouveau/bus/hwsq: Implement VBLANK waiting heuristic drm/nouveau/fb/ramnv50: Script changes for G94 and up drm/nouveau/fb/ramnv50: Deal with cards without timing entries drm/nouveau/fb/ramnv50: Voltage GPIOs drm/nouveau/fb/ramgt215: Restructure r111100 calculation for DDR2 drm/nouveau/fb/ramgt215: Change FBVDD/Q when BIOS asks for it drm/nouveau/fb/ramgt215: Transform GPIO ramfuc method from FBVREF-specific to generic drm/nouveau/bios/rammap: Identify DLLoff for >= GF100 drm/nouveau/pci: Handle 5-bit and 8-bit tag field drm/nouveau/disp,pm: constify nvkm_object_func structures drm/nouveau/gr: add FERMI_COMPUTE_B class to GF110+ drm/nouveau/gr: document mp error 0x10 ...
2015-11-03Merge branch 'exynos-drm-next' of ↵Dave Airlie23-793/+664
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next This pull request includes comprehensive cleanups to HDMI part and several fixups. In addition, this pull request includes also a defconfig patch which enables mixer driver as default. For this, I got already Acked-by from Krzysztof Kozlowski who is a Exynos SoC maintainer. * 'exynos-drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos: (34 commits) drm/exynos/gem: remove DMA-mapping hacks used for constructing page array ARM: exynos_defconfig: enable Exynos DRM Mixer driver drm/exynos: simplify Kconfig component names drm/exynos: re-arrange Kconfig entries drm/exynos: abstract out common dependency drm/exynos: separate Mixer and HDMI drivers drm/exynos/mixer: replace direct cross-driver call with drm mode validation drm/exynos: add atomic_check callback to exynos_crtc drm/exynos/decon5433: add support for DECON-TV drm/exynos/decon5433: remove duplicated initialization drm/exynos/decon5433: merge different flag fields drm/exynos/decon5433: add function to set particular register bits drm/exynos/decon5433: fix timing registers writes drm/exynos/decon5433: add PCLK clock drm/exynos: cleanup name of gem object for exynos_drm drm/exynos: fix to detach device of iommu drm/exynos: add cursor plane support drm/exynos: add global macro for the default primary plane drm/exynos: fix spelling errors drm: exynos: mixer: fix using usleep() in atomic context ...
2015-11-03drm/nouveau: bump patchlevel to indicate availability of abi16/nvif interopBen Skeggs1-1/+3
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-11-03drm/nouveau/abi16: implement limited interoperability with usif/nvifBen Skeggs3-2/+53
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-11-03drm/nouveau/abi16: introduce locked variant of nouveau_abi16_get()Ben Skeggs1-5/+13
USIF already takes the client mutex, but will need access to ABI16 data in order to provide some limited interoperability. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-11-03drm/nouveau/abi16: remove unused argument from nouveau_abi16_get()Ben Skeggs3-9/+8
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-11-03drm/nouveau/pci: enable c800 magic for Medion Erazer X7827Ilia Mirkin1-0/+1
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91557 Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-11-03drm/nouveau/pci: enable c800 magic for Lenovo Y510PIlia Mirkin1-1/+7
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70354#c75 Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-11-03drm/nouveau/pll/gk104: fix PLL instability due to bad configuration with gddr5Karol Herbst1-23/+77
This patch uses an approach closer to the nvidia driver to configure both PLLs for high gddr5 memory clocks (usually above 2400MHz) Previously nouveau used the one PLL as it was used for the lower clocks and just adjusted the second PLL to get as close as possible to the requested clock. This means for my card, that I got a 4050 MHz clock although 4008 MHz was requested. Now the driver iterates over a list of PLL configuration also used by the nvidia driver and then adjust the second PLL to get near the requested clock. Also it hold to some restriction I found while analyzing the PLL configurations This won't fix all gddr5 high clock issues itself, but it should be fine on hybrid gpu systems as found on many laptops these days. Also switching while normal desktop usage should be a lot more stable than before. v2: move the pll code into ramgk104 Signed-off-by: Karol Herbst <nouveau@karolherbst.de> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-11-03drm/nouveau/clk/g84: Enable reclocking for GDDR3 G94-G200Roy Spliet1-1/+1
Your milage may vary, as it's only been tested on a single G94 and one G96. Signed-off-by: Roy Spliet <rspliet@eclipso.eu> Tested-by: Pierre Moreau <pierre.morrow@free.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-11-03drm/nouveau/bus/hwsq: Implement VBLANK waiting heuristicRoy Spliet5-2/+41
Avoids waiting for VBLANKS that never arrive on headless or otherwise unconventional set-ups. Strategy taken from MEMX. Signed-off-by: Roy Spliet <rspliet@eclipso.eu> Tested-by: Pierre Moreau <pierre.morrow@free.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-11-03drm/nouveau/fb/ramnv50: Script changes for G94 and upRoy Spliet1-6/+30
10053c is not even read on some cards, and I have no idea exactly what the criteria are. Likely NVIDIA pre-scans the VBIOS and in their driver disables all features that are never used. The practical effect should be the same as this implementation though. Signed-off-by: Roy Spliet <rspliet@eclipso.eu> Tested-by: Pierre Moreau <pierre.morrow@free.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-11-03drm/nouveau/fb/ramnv50: Deal with cards without timing entriesRoy Spliet3-7/+50
Like Pierre's G94. We might want to structure Kepler similarly in a follow-up. Signed-off-by: Roy Spliet <rspliet@eclipso.eu> Tested-by: Pierre Moreau <pierre.morrow@free.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-11-03drm/nouveau/fb/ramnv50: Voltage GPIOsRoy Spliet2-0/+42
Does not seem to be necessary for NVA0, hence untested by me. Signed-off-by: Roy Spliet <rspliet@eclipso.eu> Tested-by: Pierre Moreau <pierre.morrow@free.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-11-03drm/nouveau/fb/ramgt215: Restructure r111100 calculation for DDR2Roy Spliet1-30/+34
Seems to be mostly equal to DDR3 on < GT218, should improve stability for DDR2 reclocks. Signed-off-by: Roy Spliet <rspliet@eclipso.eu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-11-03drm/nouveau/fb/ramgt215: Change FBVDD/Q when BIOS asks for itRoy Spliet3-0/+20
Signed-off-by: Roy Spliet <rspliet@eclipso.eu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-11-03drm/nouveau/fb/ramgt215: Transform GPIO ramfuc method from FBVREF-specific ↵Roy Spliet2-24/+19
to generic In preparation of changing FBVDDQ, as observed on at least one GDDR3 card. While at it, adhere to func.log[1] properly for consistency. Signed-off-by: Roy Spliet <rspliet@eclipso.eu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-11-03drm/nouveau/bios/rammap: Identify DLLoff for >= GF100Roy Spliet5-12/+39
Signed-off-by: Roy Spliet <rspliet@eclipso.eu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-11-03drm/nouveau/pci: Handle 5-bit and 8-bit tag fieldPierre Moreau6-0/+37
If the hardware supports extended tag field (8-bit ones), then enable it. This is usually done by the VBIOS, but not on some MBPs (see fdo#86537). In case extended tag field is not supported, 5-bit tag field is used which limits the possible number of requests to 32. Apparently bits 7:0 of 0x08841c stores some number of outstanding requests, so cap it to 32 if extended tag is unsupported. Fixes: fdo#86537 v2: Restrict changes to chipsets >= 0x84 v3: * Add nvkm_pci_mask to pci.h * Mask bit 8 before setting it v4: * Rename `add` argument of nvkm_pci_mask to `value` * Move code from nvkm_pci_init to g84_pci_init and remove PCIe and chipset checks v5: * Rebase code on latest PCI structure * Restore PCIe check * Fix namings in nvkm_pci_mask * Rephrase part of the commit message Signed-off-by: Pierre Moreau <pierre.morrow@free.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-11-03drm/nouveau/disp,pm: constify nvkm_object_func structuresJulia Lawall2-2/+2
These nvkm_object_func structures are never modified. All other nvkm_object_func structures are declared as const. Done with the help of Coccinelle. Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-11-03drm/nouveau/gr: add FERMI_COMPUTE_B class to GF110+Ilia Mirkin3-0/+3
GF110+ supports both the A and B compute classes, make sure to accept both. Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-11-03drm/nouveau/gr: document mp error 0x10Ilia Mirkin1-0/+1
NVIDIA provided the documentation for mp error 0x10, INVALID_ADDR_SPACE, which apparently happens when trying to use an atomic operation on local or shared memory (instead of global memory). Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
generated by cgit v1.2.3 (git 2.39.0) at 2025-03-04 05:28:04 +0300