linux-toradex.git/drivers/gpu/drm, branch v4.8-rc2

drm/cirrus: Fix NULL pointer dereference when registering the fbdev

2016-08-09T03:01:47+00:00

cirrus_modeset_init() is initializing/registering the emulated fbdev
and, since commit c61b93fe51b1 ("drm/atomic: Fix remaining places where
!funcs->best_encoder is valid"), DRM internals can access/test some of
the fields in mode_config->funcs as part of the fbdev registration
process.
Make sure dev->mode_config.funcs is properly set to avoid dereferencing
a NULL pointer.

Reported-by: Mike Marshall 
Reported-by: Eric W. Biederman 
Signed-off-by: Boris Brezillon 
Fixes: c61b93fe51b1 ("drm/atomic: Fix remaining places where !funcs->best_encoder is valid")
Signed-off-by: Dave Airlie

drm/edid: Set 8 bpc color depth for displays with "DFP 1.x compliant TMDS".

2016-08-08T22:56:04+00:00

According to E-EDID spec 1.3, table 3.9, a digital video sink with the
"DFP 1.x compliant TMDS" bit set is "signal compatible with VESA DFP 1.x
TMDS CRGB, 1 pixel / clock, up to 8 bits / color MSB aligned".

For such displays, the DFP spec 1.0, section 3.10 "EDID support" says:

"If the DFP monitor only supports EDID 1.X (1.1, 1.2, etc.)
 without extensions, the host will make the following assumptions:

 1. 24-bit MSB-aligned RGB TFT
 2. DE polarity is active high
 3. H and V syncs are active high
 4. Established CRT timings will be used
 5. Dithering will not be enabled on the host"

So if we don't know the bit depth of the display from additional
colorimetry info we should assume 8 bpc / 24 bpp by default.

This patch adds info->bpc = 8 assignement for that case.

Signed-off-by: Mario Kleiner 
Cc: Jani Nikula 
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Signed-off-by: Dave Airlie

drm/i915/dp: Revert "drm/i915/dp: fall back to 18 bpp when sink capability is unknown"

2016-08-08T22:56:01+00:00

This reverts commit 013dd9e03872
("drm/i915/dp: fall back to 18 bpp when sink capability is unknown")

This commit introduced a regression into stable kernels,
as it reduces output color depth to 6 bpc for any video
sink connected to a Displayport connector if that sink
doesn't report a specific color depth via EDID, or if
our EDID parser doesn't actually recognize the proper
bpc from EDID.

Affected are active DisplayPort->VGA converters and
active DisplayPort->DVI converters. Both should be
able to handle 8 bpc, but are degraded to 6 bpc with
this patch.

The reverted commit was meant to fix
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=105331

A followup patch implements a fix for that specific bug,
which is caused by a faulty EDID of the affected DP panel
by adding a new EDID quirk for that panel.

DP 18 bpp fallback handling and other improvements to
DP sink bpc detection will be handled for future
kernels in a separate series of patches.

Please backport to stable.

Signed-off-by: Mario Kleiner 
Acked-by: Jani Nikula 
Cc: stable@vger.kernel.org
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Signed-off-by: Dave Airlie

drm/edid: Add 6 bpc quirk for display AEO model 0.

2016-08-08T22:56:00+00:00

Bugzilla https://bugzilla.kernel.org/show_bug.cgi?id=105331
reports that the "AEO model 0" display is driven with 8 bpc
without dithering by default, which looks bad because that
panel is apparently a 6 bpc DP panel with faulty EDID.

A fix for this was made by commit 013dd9e03872
("drm/i915/dp: fall back to 18 bpp when sink capability is unknown").

That commit triggers new regressions in precision for DP->DVI and
DP->VGA displays. A patch is out to revert that commit, but it will
revert video output for the AEO model 0 panel to 8 bpc without
dithering.

The EDID 1.3 of that panel, as decoded from the xrandr output
attached to that bugzilla bug report, is somewhat faulty, and beyond
other problems also sets the "DFP 1.x compliant TMDS" bit, which
according to DFP spec means to drive the panel with 8 bpc and
no dithering in absence of other colorimetry information.

Try to make the original bug reporter happy despite the
faulty EDID by adding a quirk to mark that panel as 6 bpc,
so 6 bpc output with dithering creates a nice picture.

Tested by injecting the edid from the fdo bug into a DP connector
via drm_kms_helper.edid_firmware and verifying the 6 bpc + dithering
is selected.

This patch should be backported to stable.

Signed-off-by: Mario Kleiner 
Cc: stable@vger.kernel.org
Cc: Jani Nikula 
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Signed-off-by: Dave Airlie

Merge branch 'drm-next-4.8' of git://people.freedesktop.org/~agd5f/linux into drm-next

2016-08-08T06:45:33+00:00

A few fixes for amdgpu and ttm for 4.8
- fix a ttm regression caused by the new pipelining code
- fixes for mullins on amdgpu
- updated golden settings for amdgpu

* 'drm-next-4.8' of git://people.freedesktop.org/~agd5f/linux:
  drm/ttm: Wait for a BO to become idle before unbinding it from GTT
  drm/amdgpu: update golden setting of polaris10
  drm/amdgpu: update golden setting of stoney
  drm/amdgpu: update golden setting of polaris11
  drm/amdgpu: update golden setting of carrizo
  drm/amdgpu: update golden setting of iceland
  drm/amd/amdgpu: change pptable output format from ASCII to binary
  drm/amdgpu/ci: add mullins to default case for smc ucode
  drm/amdgpu/gmc7: add missing mullins case

Merge tag 'drm-intel-next-fixes-2016-08-05' of git://anongit.freedesktop.org/drm-intel into drm-next

2016-08-08T06:16:26+00:00

3 intel fixes.

* tag 'drm-intel-next-fixes-2016-08-05' of git://anongit.freedesktop.org/drm-intel:
  drm/i915/fbdev: Check for the framebuffer before use
  drm/i915: Never fully mask the the EI up rps interrupt on SNB/IVB
  drm/i915: Wait up to 3ms for the pcu to ack the cdclk change request on SKL

drm: Paper over locking inversion after registration rework

2016-08-08T06:08:25+00:00

drm_connector_register_all requires a few too many locks because our
connector_list locking is busted. Add another FIXME+hack to work
around this. This should address the below lockdep splat:

======================================================
[ INFO: possible circular locking dependency detected ]
4.7.0-rc5+ #524 Tainted: G           O
-------------------------------------------------------
kworker/u8:0/6 is trying to acquire lock:
 (&dev->mode_config.mutex){+.+.+.}, at: [] drm_modeset_lock_all+0x40/0x120

but task is already holding lock:
 ((fb_notifier_list).rwsem){++++.+}, at: [] __blocking_notifier_call_chain+0x35/0x70

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #1 ((fb_notifier_list).rwsem){++++.+}:
       [] lock_acquire+0xb1/0x200
       [] down_write+0x44/0x80
       [] blocking_notifier_chain_register+0x21/0xb0
       [] fb_register_client+0x18/0x20
       [] backlight_device_register+0x136/0x260
       [] intel_backlight_device_register+0xa2/0x160 [i915]
       [] intel_connector_register+0xe/0x10 [i915]
       [] intel_dp_connector_register+0x1b/0x80 [i915]
       [] drm_connector_register+0x4a/0x80
       [] drm_connector_register_all+0x64/0xf0
       [] drm_modeset_register_all+0x174/0x1c0
       [] drm_dev_register+0xc2/0xd0
       [] i915_driver_load+0x1547/0x2200 [i915]
       [] i915_pci_probe+0x4f/0x70 [i915]
       [] local_pci_probe+0x45/0xa0
       [] pci_device_probe+0xdb/0x130
       [] driver_probe_device+0x223/0x440
       [] __driver_attach+0xd5/0x100
       [] bus_for_each_dev+0x66/0xa0
       [] driver_attach+0x1e/0x20
       [] bus_add_driver+0x1ee/0x280
       [] driver_register+0x60/0xe0
       [] __pci_register_driver+0x60/0x70
       [] i915_init+0x5b/0x62 [i915]
       [] do_one_initcall+0x3d/0x150
       [] do_init_module+0x5f/0x1d9
       [] load_module+0x20e6/0x27e0
       [] SYSC_finit_module+0xc3/0xf0
       [] SyS_finit_module+0xe/0x10
       [] entry_SYSCALL_64_fastpath+0x1c/0xac

-> #0 (&dev->mode_config.mutex){+.+.+.}:
       [] __lock_acquire+0x10fc/0x1260
       [] lock_acquire+0xb1/0x200
       [] mutex_lock_nested+0x67/0x3c0
       [] drm_modeset_lock_all+0x40/0x120
       [] drm_fb_helper_restore_fbdev_mode_unlocked+0x2b/0x80
       [] drm_fb_helper_set_par+0x2d/0x50
       [] intel_fbdev_set_par+0x1a/0x60 [i915]
       [] fbcon_init+0x586/0x610
       [] visual_init+0xca/0x130
       [] do_bind_con_driver+0x1c1/0x3a0
       [] do_take_over_console+0x116/0x180
       [] do_fbcon_takeover+0x57/0xb0
       [] fbcon_event_notify+0x658/0x750
       [] notifier_call_chain+0x3e/0xb0
       [] __blocking_notifier_call_chain+0x4d/0x70
       [] blocking_notifier_call_chain+0x16/0x20
       [] fb_notifier_call_chain+0x1b/0x20
       [] register_framebuffer+0x251/0x330
       [] drm_fb_helper_initial_config+0x25f/0x3f0
       [] intel_fbdev_initial_config+0x18/0x30 [i915]
       [] async_run_entry_fn+0x48/0x150
       [] process_one_work+0x1e7/0x750
       [] worker_thread+0x4b/0x4f0
       [] kthread+0xef/0x110
       [] ret_from_fork+0x1f/0x40

other info that might help us debug this:

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock((fb_notifier_list).rwsem);
                               lock(&dev->mode_config.mutex);
                               lock((fb_notifier_list).rwsem);
  lock(&dev->mode_config.mutex);

 *** DEADLOCK ***

6 locks held by kworker/u8:0/6:
 #0:  ("events_unbound"){.+.+.+}, at: [] process_one_work+0x169/0x750
 #1:  ((&entry->work)){+.+.+.}, at: [] process_one_work+0x169/0x750
 #2:  (registration_lock){+.+.+.}, at: [] register_framebuffer+0x27/0x330
 #3:  (console_lock){+.+.+.}, at: [] register_framebuffer+0x26e/0x330
 #4:  (&fb_info->lock){+.+.+.}, at: [] lock_fb_info+0x1d/0x40
 #5:  ((fb_notifier_list).rwsem){++++.+}, at: [] __blocking_notifier_call_chain+0x35/0x70

stack backtrace:
CPU: 2 PID: 6 Comm: kworker/u8:0 Tainted: G           O    4.7.0-rc5+ #524
Hardware name: Intel Corp. Broxton P/NOTEBOOK, BIOS APLKRVPA.X64.0138.B33.1606250842 06/25/2016
Workqueue: events_unbound async_run_entry_fn
 0000000000000000 ffff8800758577f0 ffffffff814507a5 ffffffff828b9900
 ffffffff828b9900 ffff880075857830 ffffffff810dc6fa ffff880075857880
 ffff88007584d688 0000000000000005 0000000000000006 ffff88007584d6b0
Call Trace:
 [] dump_stack+0x67/0x92
 [] print_circular_bug+0x1aa/0x200
 [] __lock_acquire+0x10fc/0x1260
 [] lock_acquire+0xb1/0x200
 [] ? drm_modeset_lock_all+0x40/0x120
 [] ? drm_modeset_lock_all+0x40/0x120
 [] mutex_lock_nested+0x67/0x3c0
 [] ? drm_modeset_lock_all+0x40/0x120
 [] ? rcu_read_lock_sched_held+0x7f/0x90
 [] ? kmem_cache_alloc_trace+0x248/0x2b0
 [] ? drm_modeset_lock_all+0x25/0x120
 [] drm_modeset_lock_all+0x40/0x120
 [] drm_fb_helper_restore_fbdev_mode_unlocked+0x2b/0x80
 [] drm_fb_helper_set_par+0x2d/0x50
 [] intel_fbdev_set_par+0x1a/0x60 [i915]
 [] fbcon_init+0x586/0x610
 [] visual_init+0xca/0x130
 [] do_bind_con_driver+0x1c1/0x3a0
 [] do_take_over_console+0x116/0x180
 [] do_fbcon_takeover+0x57/0xb0
 [] fbcon_event_notify+0x658/0x750
 [] notifier_call_chain+0x3e/0xb0
 [] __blocking_notifier_call_chain+0x4d/0x70
 [] blocking_notifier_call_chain+0x16/0x20
 [] fb_notifier_call_chain+0x1b/0x20
 [] register_framebuffer+0x251/0x330
 [] ? vga_switcheroo_client_fb_set+0x5d/0x70
 [] drm_fb_helper_initial_config+0x25f/0x3f0
 [] intel_fbdev_initial_config+0x18/0x30 [i915]
 [] async_run_entry_fn+0x48/0x150
 [] process_one_work+0x1e7/0x750
 [] ? process_one_work+0x169/0x750
 [] worker_thread+0x4b/0x4f0
 [] ? process_one_work+0x750/0x750
 [] kthread+0xef/0x110
 [] ret_from_fork+0x1f/0x40
 [] ? kthread_stop+0x2e0/0x2e0

v2: Rebase onto the right branch (hand-editing patches ftw) and add more
reporters.

Reported-by: Imre Deak 
Cc: Imre Deak 
Cc: Chris Wilson 
Acked-by: Chris Wilson 
Reported-by: Jiri Kosina 
Cc: Jiri Kosina 
Signed-off-by: Daniel Vetter 
Signed-off-by: Dave Airlie

drm: rcar-du: Link HDMI encoder with bridge

2016-08-08T05:27:11+00:00

The conversion of the rcar-du driver from the I2C slave encoder to the
DRM bridge API left the HDMI encoder's bridge pointer NULL, preventing
the bridge from being handled automatically by the DRM core. Fix it.

Fixes: 1d926114d8f4 ("drm: rcar-du: Remove i2c slave encoder interface for hdmi encoder")
Signed-off-by: Laurent Pinchart 
Signed-off-by: Dave Airlie

Merge tag 'drm-for-v4.8-zpos' of git://people.freedesktop.org/~airlied/linux

2016-08-07T23:35:08+00:00

Pull drm zpos property support from Dave Airlie:
 "This tree was waiting on some media stuff I hadn't had time to get a
  stable branchpoint off, so I just waited until it was all in your tree
  first.

  It's been around a bit on the list and shouldn't affect anything
  outside adding the generic API and moving some ARM drivers to using
  it"

* tag 'drm-for-v4.8-zpos' of git://people.freedesktop.org/~airlied/linux:
  drm: rcar: use generic code for managing zpos plane property
  drm/exynos: use generic code for managing zpos plane property
  drm: sti: use generic zpos for plane
  drm: add generic zpos property

drm/ttm: Wait for a BO to become idle before unbinding it from GTT

2016-08-05T17:37:02+00:00

Fixes hangs under memory pressure, e.g. running the piglit test
tex3d-maxsize concurrently with other tests.

Fixes: 17d33bc9d6ef ("drm/ttm: drop waiting for idle in ttm_bo_evict.")
Reviewed-by: Christian König 
Signed-off-by: Michel Dänzer 
Signed-off-by: Alex Deucher