summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2015-12-18drm/i915: Limit the busy wait on requests to 5us not 10ms!Chris Wilson
When waiting for high frequency requests, the finite amount of time required to set up the irq and wait upon it limits the response rate. By busywaiting on the request completion for a short while we can service the high frequency waits as quick as possible. However, if it is a slow request, we want to sleep as quickly as possible. The tradeoff between waiting and sleeping is roughly the time it takes to sleep on a request, on the order of a microsecond. Based on measurements of synchronous workloads from across big core and little atom, I have set the limit for busywaiting as 10 microseconds. In most of the synchronous cases, we can reduce the limit down to as little as 2 miscroseconds, but that leaves quite a few test cases regressing by factors of 3 and more. The code currently uses the jiffie clock, but that is far too coarse (on the order of 10 milliseconds) and results in poor interactivity as the CPU ends up being hogged by slow requests. To get microsecond resolution we need to use a high resolution timer. The cheapest of which is polling local_clock(), but that is only valid on the same CPU. If we switch CPUs because the task was preempted, we can also use that as an indicator that the system is too busy to waste cycles on spinning and we should sleep instead. __i915_spin_request was introduced in commit 2def4ad99befa25775dd2f714fdd4d92faec6e34 [v4.2] Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Apr 7 16:20:41 2015 +0100 drm/i915: Optimistically spin for the request completion v2: Drop full u64 for unsigned long - the timer is 32bit wraparound safe, so we can use native register sizes on smaller architectures. Mention the approximate microseconds units for elapsed time and add some extra comments describing the reason for busywaiting. v3: Raise the limit to 10us v4: Now 5us. Reported-by: Jens Axboe <axboe@kernel.dk> Link: https://lkml.org/lkml/2015/11/12/621 Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: "Rogozhkin, Dmitry V" <dmitry.v.rogozhkin@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Eero Tamminen <eero.t.tamminen@intel.com> Cc: "Rantala, Valtteri" <valtteri.rantala@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1449833608-22125-3-git-send-email-chris@chris-wilson.co.uk
2015-12-18drm/i915: Break busywaiting for requests on pending signalsChris Wilson
The busywait in __i915_spin_request() does not respect pending signals and so may consume the entire timeslice for the task instead of returning to userspace to handle the signal. In the worst case this could cause a delay in signal processing of 20ms, which would be a noticeable jitter in cursor tracking. If a higher resolution signal was being used, for example to provide fairness of a server timeslices between clients, we could expect to detect some unfairness between clients (i.e. some windows not updating as fast as others). This issue was noticed when inspecting a report of poor interactivity resulting from excessively high __i915_spin_request usage. Fixes regression from commit 2def4ad99befa25775dd2f714fdd4d92faec6e34 [v4.2] Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Apr 7 16:20:41 2015 +0100 drm/i915: Optimistically spin for the request completion v2: Try to assess the impact of the bug Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Jens Axboe <axboe@kernel.dk> Cc; "Rogozhkin, Dmitry V" <dmitry.v.rogozhkin@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Eero Tamminen <eero.t.tamminen@intel.com> Cc: "Rantala, Valtteri" <valtteri.rantala@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1449833608-22125-2-git-send-email-chris@chris-wilson.co.uk
2015-12-18drm/i915: don't enable autosuspend on platforms without RPM supportImre Deak
pm_runtime_{use,dont_use}_autosuspend() controls whether the device's sysfs power/autosuspend_delay_ms file is writeable or returns -EIO on access to user space. Since commit 25b181b46e4340f69793a886f2cd46608487783b Author: Imre Deak <imre.deak@intel.com> Date: Thu Dec 17 13:44:56 2015 +0200 drm/i915: get a permanent RPM reference on platforms w/o RPM support this sysfs file is writeable also on platforms without RPM support, but userspace (at least IGT) depends on this file being unchangable to determine whether the device supports runtime PM at all. So restore the old behavior. This gets rid of igt/pm_rpm failures on old platforms without RPM support, where the test should be skipped. Testcase: igt/pm_rpm/basic-rte Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: David Weinehall <david.weinehall@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1450371873-878-1-git-send-email-imre.deak@intel.com
2015-12-18drm/i915/backlight: prefer dev_priv over dev pointerJani Nikula
Use dev_priv rather than dev pointer where applicable. Remove plenty of unnecessary temp variables. No functional changes. Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1450428695-28831-1-git-send-email-jani.nikula@intel.com
2015-12-18drm/nouveau/bios/fan: hardcode the fan mode to linearMartin Peres
This is an oversight that made use of the trip-point-based fan managenent on cards that never expose those. This led the fan to stay at fan_min. Fortunately, the emergency code would kick when the temperature would reach 90°C. Reported-by: Tom Englund <tomenglund26@gmail.com> Tested-by: Tom Englund <tomenglund26@gmail.com> Signed-off-by: Martin Peres <martin.peres@free.fr> Tested-by: Daemon32 <lnf.purple@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92126 Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Cc: stable@vger.kernel.org
2015-12-17drm/vc4: fix an error codeDan Carpenter
"exec->exec_bo" is NULL at this point so this code returns success. We want to return -ENOMEM. Fixes: d5b1a78a772f ('drm/vc4: Add support for drawing 3D frames.') Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Eric Anholt <eric@anholt.net>
2015-12-17drm/vc4: allocate enough memory in vc4_save_hang_state()Dan Carpenter
"state" is smaller than "kernel_state" so we end up corrupting memory. Fixes: 214613656b51 ('drm/vc4: Add an interface for capturing the GPU state after a hang.') Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Eric Anholt <eric@anholt.net>
2015-12-17drm/vc4: copy_to_user() returns the number of bytes remainingDan Carpenter
The copy_to/from_user() functions return the number of bytes remaining to be copied. We want to return error codes here. Also it's a bad idea to print an error message if a copy from user fails because users can use that to spam /var/log/messages which is annoying so I removed those. Fixes: 214613656b51 ('drm/vc4: Add an interface for capturing the GPU state after a hang.') Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Eric Anholt <eric@anholt.net>
2015-12-17drm/amdgpu: limit visible vram if it's smaller than the BARAlex Deucher
In some cases the amount of vram may be less than the BAR size, if so, limit visible vram to the amount of actual vram, not the BAR size. Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2015-12-17drm/i915: Disable primary plane if we fail to reconstruct BIOS fb (v2)Matt Roper
If we fail to reconstruct the BIOS fb (e.g., because the FB is too large), we'll be left with plane state that indicates the primary plane is visible yet has a NULL fb. This mismatch causes problems later on (e.g., for the watermark code). Since we've failed to reconstruct the BIOS FB, the best solution is to just disable the primary plane and pretend the BIOS never had it enabled. v2: Add intel_pre_disable_primary() call (Maarten) Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Ville Syrjälä <ville.syrjala@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: drm-intel-fixes@lists.freedesktop.org Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1449171462-30763-2-git-send-email-matthew.d.roper@intel.com
2015-12-17drm/i915: Pin the ifbdev for the info->system_base GGTT mmappingChris Wilson
A long time ago (before 3.14) we relied on a permanent pinning of the ifbdev to lock the fb in place inside the GGTT. However, the introduction of stealing the BIOS framebuffer and reusing its address in the GGTT for the fbdev has muddied waters and we use an inherited fb. However, the inherited fb is only pinned whilst it is active and we no longer have an explicit pin for the info->system_base mmapping used by the fbdev. The result is that after some aperture pressure the fbdev may be evicted, but we continue to write the fbcon into the same GGTT address - overwriting anything else that may be put into that offset. The effect is most pronounced across suspend/resume as intel_fbdev_set_suspend() does a full clear over the whole scanout. v2: Only unpin the intel_fb is we allocate it. If we inherit the fb from the BIOS, we do not own the pinned vma (except for the reference we add in this patch for our access via info->screen_base). v3: Finish balancing the vma pinning for the normal !preallocated case. v4: Try to simplify the pinning even further. v5: Leak the VMA (cleaned up by object-free) to avoid complicated error paths. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: "Goel, Akash" <akash.goel@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Lukas Wunner <lukas@wunner.de> Cc: drm-intel-fixes@lists.freedesktop.org Link: http://patchwork.freedesktop.org/patch/msgid/1449245126-26158-1-git-send-email-chris@chris-wilson.co.uk Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-12-17drm/i915: Set the map-and-fenceable flag for preallocated objectsChris Wilson
As we mark the preallocated objects as bound, we should also flag them correctly as being map-and-fenceable (if appropriate!) so that later users do not get confused and try and rebind the pinned vma in order to get a map-and-fenceable binding. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: "Goel, Akash" <akash.goel@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: drm-intel-fixes@lists.freedesktop.org Link: http://patchwork.freedesktop.org/patch/msgid/1448029000-10616-1-git-send-email-chris@chris-wilson.co.uk Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-12-17drm/i915: mdelay(10) considered harmfulDaniel Vetter
I missed this myself when reviewing commit 237ed86c693d8a8e4db476976aeb30df4deac74b Author: Sonika Jindal <sonika.jindal@intel.com> Date: Tue Sep 15 09:44:20 2015 +0530 drm/i915: Check live status before reading edid Long sleeps like this really shouldn't waste cpu cycles spinning. Cc: Sonika Jindal <sonika.jindal@intel.com> Cc: "Wang, Gary C" <gary.c.wang@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1449859455-32609-1-git-send-email-daniel.vetter@ffwll.ch Reviewed-by: Sonika Jindal <sonika.jindal@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-12-17drm/i915: check that we are in an RPM atomic section in GGTT PTE updatersImre Deak
The device should be on for the whole duration of the update, so check for this. v2: - use the existing dev_priv directly everywhere (Ville) v3: - check also that we are in an RPM atomic section (Chris) - add the assert to i915_ggtt_insert_entries/clear_range too (Chris) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1450203038-5150-11-git-send-email-imre.deak@intel.com
2015-12-17drm/i915: add support for checking RPM atomic sectionsImre Deak
In some cases we want to check whether we hold an RPM wakelock reference for the whole duration of a sequence. To achieve this add a new RPM atomic sequence counter that we increment any time the wakelock refcount drops to zero. Check whether the sequence number stays the same during the atomic section and that we hold the wakelock at the beginning of the section. Motivated by Chris. v2-v3: - unchanged v4: - swap the order of atomic_read() and assert_rpm_wakelock_held() in assert_rpm_atomic_begin() to avoid race Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v3) Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1450203038-5150-10-git-send-email-imre.deak@intel.com
2015-12-17drm/i915: check that we hold an RPM wakelock ref before we put itImre Deak
With this change we have the corresponding wake lock checks in both the rpm get and put functions. v2-v3: - unchanged v4: - keep the corresponding check in the get helper (Chris) v5: - add a note to the commit message that with this change we have the checks both in the rpm get and put functions (Joonas) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1450203038-5150-9-git-send-email-imre.deak@intel.com
2015-12-17drm/i915: add support for checking if we hold an RPM referenceImre Deak
Atm, we assert that the device is not suspended until the point when the device is truly put to a suspended state. This is fine, but we can catch more problems if we check that RPM refcount is non-zero. After that one drops to zero we shouldn't access the device any more, even if the actual device suspend may be delayed. Change assert_rpm_wakelock_held() accordingly to check for a non-zero RPM refcount in addition to the current device-not-suspended check. For the new asserts to work we need to annotate every place explicitly in the code where we expect that the device is powered. The places where we only assume this, but may not hold an RPM reference: - driver load We assume the device to be powered until we enable RPM. Make this explicit by taking an RPM reference around the load function. - system and runtime sudpend/resume handlers These handlers are called when the RPM reference becomes 0 and know the exact point after which the device can get powered off. Disable the RPM-reference-held check for their duration. - the IRQ, hangcheck and RPS work handlers These handlers are flushed in the system/runtime suspend handler before the device is powered off, so it's guaranteed that they won't run while the device is powered off even though they don't hold any RPM reference. Disable the RPM-reference-held check for their duration. In all these cases we still check that the device is not suspended. These explicit annotations also have the positive side effect of documenting our assumptions better. This caught additional WARNs from the atomic modeset path, those should be fixed separately. v2: - remove the redundant HAS_RUNTIME_PM check (moved to patch 1) (Ville) v3: - use a new dedicated RPM wakelock refcount to also catch cases where our own RPM get/put functions were not called (Chris) - assert also that the new RPM wakelock refcount is 0 in the RPM suspend handler (Chris) - change the assert error message to be more meaningful (Chris) - prevent false assert errors and check that the RPM wakelock is 0 in the RPM resume handler too - prevent false assert errors in the hangcheck work too - add a device not suspended assert check to the hangcheck work v4: - rename disable/enable_rpm_asserts to disable/enable_rpm_wakeref_asserts and wakelock_count to wakeref_count - disable the wakeref asserts in the IRQ handlers and RPS work too - update/clarify commit message v5: - mark places we plan to change to use proper RPM refcounting with separate DISABLE/ENABLE_RPM_WAKEREF_ASSERTS aliases (Chris) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1450227139-13471-1-git-send-email-imre.deak@intel.com
2015-12-17drm/i915: use assert_rpm_wakelock_held instead of opencoding itImre Deak
Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1450203038-5150-7-git-send-email-imre.deak@intel.com
2015-12-17drm/i915: add assert_rpm_wakelock_held helperImre Deak
As a preparation for follow-up patches add a new helper that checks whether we hold an RPM reference, since this is what we want most of the cases. Atm this helper will only check for the HW suspended state, a follow-up patch will do the actual change to check the refcount instead. One exception is the forcewake release timer function, where it's guaranteed that the HW is on even though the RPM refcount drops to zero. This guarantee is provided by flushing the timer in the runtime suspend handler. So leave the assert_device_not_suspended check in place there. Also rename assert_device_suspended for consistency and export these helpers as a preparation for the follow-up patches. No functional change. v3: - change the assert warning message to be more meaningful (Chris) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1450203038-5150-6-git-send-email-imre.deak@intel.com
2015-12-17drm/i915: remove HAS_RUNTIME_PM check from RPM get/put/assert helpersImre Deak
We don't really need to check this flag in the get/put/assert helpers, as on platforms without RPM support we won't ever enable RPM. That means pm.suspend will be always false and the assert will be always true. Do this to simplify the code and to let us extend the RPM asserts to all platforms for a better coverage. Motivated by Ville. v2-v3: - unchanged v4: - remove the HAS_RUNTIME_PM check from intel_runtime_pm_enable() too made possible by the previous two patches v5: - rebased on the previous new patch in the series that keeps HAS_RUNTIME_PM() in intel_runtime_pm_enable() with a permanent reference taken there Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v3) Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1450352931-16498-1-git-send-email-imre.deak@intel.com
2015-12-17drm/i915: get a permanent RPM reference on platforms w/o RPM supportImre Deak
Currently we disable RPM functionality on platforms that doesn't support this by not putting/getting the RPM reference we receive from the RPM core during driver loading/unloading respectively. This is somewhat obscure, so make it more explicit by keeping a reference dedicated for this particular purpose whenever the driver is loaded. This makes it possible to remove the HAS_RUNTIME_PM() special casing from every other places in the next patch. v2: - fix intel_runtime_pm_get vs. intel_runtime_pm_put in intel_power_domains_fini() v3: - take only a low level RPM reference so the ref tracking asserts continue to work (Ville) - update the commit message - move the patch earlier for bisectability Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.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/1450352696-16135-1-git-send-email-imre.deak@intel.com
2015-12-17drm/i915: refactor RPM disabling due to RC6 being disabledImre Deak
We can make the RPM dependency on RC6 explcit in the code by taking an actual RPM reference, instead of avoiding to drop the initial one. This will also enable us to remove the HAS_RUNTIME_PM special casing from more places in the next patch. v2: - fixed typo in commit message (Joonas) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1450203038-5150-4-git-send-email-imre.deak@intel.com
2015-12-17drm/i915: clarify comment about mandatory RPM put/get during driver load/unloadImre Deak
Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1450203038-5150-2-git-send-email-imre.deak@intel.com
2015-12-17drm/i915/opregion: handle VBT sizes bigger than 6 KBJani Nikula
The RVDA and RVDS (raw VBT data address and size) fields of the ASLE mailbox may specify an alternate location for VBT instead of mailbox #4. Use the alternate location if available and valid, falling back to mailbox #4 otherwise. v2: Update debug logging (Ville) Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Tested-by: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1450178280-28020-1-git-send-email-jani.nikula@intel.com
2015-12-16drm/amdgpu: fix user fence handlingChristian König
This fixes a random corruption under memory pressure. We need to fence the BO for the user fence as well, otherwise it might be swapped out and the GPU could write the fence value to an undesired location. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2015-12-17Merge tag 'drm/tegra/for-4.5-rc1' of ↵Dave Airlie
git://anongit.freedesktop.org/tegra/linux into drm-next drm/tegra: Changes for v4.5-rc1 This adds support for the version of host1x found on Tegra210 SoCs. It also makes use of the new atomic suspend/resume functionality to bring this feature to Tegra. Other than that it's mostly small fixes and cleanups, with some prep- work for things that will hopefully get merged for the next release. * tag 'drm/tegra/for-4.5-rc1' of git://anongit.freedesktop.org/tegra/linux: drm/tegra: Advertise DRIVER_ATOMIC drm/tegra: Use DRIVER level for IOMMU aperture message drm/tegra: checking for IS_ERR() instead of NULL drm/tegra: dc: Add missing of_node_put() drm/tegra: Implement subsystem-level suspend/resume drm/tegra: sor: Remove unnecessary conditional drm/tegra: sor: Operate on struct drm_dp_aux * drm/tegra: Use drm_gem_object_unreference_unlocked() drm/tegra: Don't take dev->struct_mutex in mmap offset ioctl drm/tegra: Use unlocked gem unreferencing drm/tegra: Use new multi-driver module helpers gpu: host1x: Add Tegra210 support gpu: host1x: Remove core driver on unregister gpu: host1x: Use platform_register/unregister_drivers()
2015-12-17Merge tag 'drm/panel/for-4.5-rc1' of ↵Dave Airlie
git://anongit.freedesktop.org/tegra/linux into drm-next drm/panel: Changes for v4.5-rc1 This set of changes brings in a few more helpers for DSI support as well as a couple of new drivers and support for some more simple panels. * tag 'drm/panel/for-4.5-rc1' of git://anongit.freedesktop.org/tegra/linux: drm/panel: simple: Add QiaoDian qd43003c0-40 of: Add vendor prefix for QiaoDian Xianshi drm/panel: add kernel doc for size attributes in panel_desc drm/panel: simple: Add support for Kyocera TCG121XGLP panel devicetree: add vendor prefix for Kyocera Corporation drm/bridge: Remove gratuitous blank line drm/bridge: dw-hdmi: Use dashes in filenames drm/panel: Add Sharp LS043T1LE01 MIPI DSI panel dt-bindings: Add Sharp LS043T1LE01 panel binding drm/dsi: Add Turn On/Shutdown Peripheral command helpers drm/panel: Add Panasonic VVX10F034N00 MIPI DSI panel dt-bindings: Add Panasonic VVX10F034N00 panel binding drm/panel: simple: Add support for Innolux G121X1-L03 drm/panel: simple: Add support for BOE TV080WUM-NL0 dt-bindings: Add BOE TV080WUM-NL0 panel binding of: Add vendor prefix for BOE Technology Group drm/dsi: Add a helper to get bits per pixel of MIPI DSI pixel format
2015-12-16drm/panel: simple: Add QiaoDian qd43003c0-40Josh Wu
The QiaoDian Xianshi QD43003C0-40 is a 4"3 TFT LCD panel. Timings from the OTA5180A document, ver 0.9, section 10.1.1: http://www.orientdisplay.com/pdf/OTA5180A.pdf Signed-off-by: Josh Wu <josh.wu@atmel.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2015-12-16drm/i915: Fix AVI/HDMI/SPD infoframes on HSW+Ville Syrjälä
I broke AVI/HDMI/SPD infoframes on HSW+ with the register type safety changes. We were supposed to check that the infoframe data register is valid before writing the infoframe data, but the check ended up inverted, and so in practice we never wrote or enabled these infoframes. We were still sending out the GCP infoframe when the sink was deep-color capable. That and the fact that we use a single bool to track our infoframe state meant that the state checker only caught this when a HDMI sink that doesn't do deep-color was used. We really need to fix our infoframe state checking to be much more anal. But in the meantime let's just fix the regression. In fact let's just throw out the register validity check and convert some of the "unknown info frame type" debug messages into MISSING_CASE(). So far we support the same set of infoframe types on all platforms, so the silent debug messages make no sense. Cc: drm-intel-fixes@lists.freedesktop.org Fixes: f0f59a00a1c9 ("drm/i915: Type safe register read/write") Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> (irc) Tested-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> (irc) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1450282200-4203-1-git-send-email-ville.syrjala@linux.intel.com Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93119 Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-12-16drm/i915/bios: reduce indent in parse_general_featuresJani Nikula
Slightly cleaner with early exit. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1450271061-32646-4-git-send-email-jani.nikula@intel.com
2015-12-16drm/i915/bios: prefer using dev_priv over dev pointerJani Nikula
dev_priv is the new black. Or something. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1450271061-32646-3-git-send-email-jani.nikula@intel.com
2015-12-16drm/i915/bios: fix format string of the VBT signature loggingJani Nikula
Specify the maximum number of letters to print from the potentially unterminated buffer, not the minimum. While at it, use sizeof instead of a magic number. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1450271061-32646-2-git-send-email-jani.nikula@intel.com
2015-12-16drm/i915: move drmP.h include to i915_drv.hJani Nikula
The intel_bios.h header doesn't even need it, but other headers included from i915_drv.h do. Let's untangle the mess a bit. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1450271061-32646-1-git-send-email-jani.nikula@intel.com
2015-12-16drm/panel: add kernel doc for size attributes in panel_descUlrich Ölmann
Document that 'width' and 'height' are measured in millimeters. Signed-off-by: Ulrich Ölmann <u.oelmann@pengutronix.de> Signed-off-by: Thierry Reding <treding@nvidia.com>
2015-12-16drm/panel: simple: Add support for Kyocera TCG121XGLP panelLucas Stach
The Kyocera TCG121XGLP panel is an XGA LCD TFT panel connected through LVDS, which can be supported by the simple panel driver. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Thierry Reding <treding@nvidia.com>
2015-12-16drm/i915: prefer for_each_intel_* macros for iterationJani Nikula
Use the for_each_intel_* macros for iterating intel_encoder, intel_connector, and intel_crtc. No functional changes. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1450262896-5325-1-git-send-email-jani.nikula@intel.com
2015-12-16drm/i915/debugfs: add a separate debugfs file for VBTJani Nikula
In the future the VBT might not be in mailbox #4 of the ACPI OpRegion, thus unavailable in i915_opregion, so add a separate file for the VBT. v2: Drop the locking as unneeded (Chris) v3: Rebase Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1450178232-27780-1-git-send-email-jani.nikula@intel.com
2015-12-16drm/i915: don't use a temp buffer for opregion debugfs fileJani Nikula
Hasn't been necessary since commit 115719fceaa733d646e39cdce83cc32ddb891a49 Author: Williams, Dan J <dan.j.williams@intel.com> Date: Mon Oct 12 21:12:57 2015 +0000 i915: switch from acpi_os_ioremap to memremap Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/74664a556a56d0eceb0029bbd77ffc1d771b0628.1450089383.git.jani.nikula@intel.com
2015-12-16drm/i915/opregion: make VBT pointer a constJani Nikula
Because we can. It's not to be touched so tell the compiler too. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/4b1872b121fb34a193cff9a5cb4e7c858d4a55aa.1450089383.git.jani.nikula@intel.com
2015-12-16drm/i915/opregion: make VBT size limit more strictJani Nikula
The VBT in OpRegion should fit in mailbox #4. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/4bdb3f5820e3dbd1cdfa7b65cadfce4f80b880f0.1450089383.git.jani.nikula@intel.com
2015-12-16drm/i915: refactor VBT validationJani Nikula
Make the validation function a boolean operating on a buffer of given size, removing the extra pointer dances. Move the OpRegion based VBT validation to intel_opregion_setup(), only initializing opregion->vbt if it's valid. v2: move logging about valid VBT to opregion setup too (Ville) Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1450178175-27420-1-git-send-email-jani.nikula@intel.com
2015-12-16drm/i915/bios: rename intel_parse_bios to intel_bios_initJani Nikula
While at it, move the declaration to where everything else is declared. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/7d9d879603038889f0128cf7cbbd9f591edc11dd.1450089383.git.jani.nikula@intel.com
2015-12-16drm/i915/bios: move debug logging about VBT source to intel_parse_bios()Jani Nikula
The decision about which source will be used for VBT is done in intel_parse_bios(), not in the VBT validation function. Make the VBT validation function strictly about validation, and move the debug logging to where it logically belongs. Also split the logging about where the valid VBT was found and what the signature is. This will make even more sense in the future when the validation for ACPI OpRegion based VBT takes place at OpRegion setup time. v2: Split logging about VBT signature and BDB version. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1450178092-27148-1-git-send-email-jani.nikula@intel.com
2015-12-16drm/i915/bios: have functions return vbt, not bdb, header pointerJani Nikula
This will simplify further work. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/d2c5210402fdd8c277e1d50892b0620d10c50ae8.1450089383.git.jani.nikula@intel.com
2015-12-16drm/i915: move "no VBT in opregion" quirk to intel_opregion_setup()Jani Nikula
Check the quirk in intel_opregion_setup(), and don't initialize opregion->vbt at all if the quirk says it's not present, hiding the quirk from the rest of the driver. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/7cdc86eb441f8b7075142445a800b07ecf8c76cb.1450089383.git.jani.nikula@intel.com
2015-12-16drm/i915: Add Intel opregion mailbox 5 structureDeepak M
Mailbox 5 is BIOS to Driver Notification mailbox is intended to support BIOS to Driver event notification or data storage for BIOS to Driver data synchronization purpose. Mailbox 5 is the extension of mailbox 3. v4 by Jani: - don't add asle_ext to dev_priv as it's unused - use u8 for bddc and rsvd fields in asle ext struct - add BUILD_BUG_ON the asle ext struct size - debug logging for asle ext present Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Deepak M <m.deepak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/c2d4009659fca32280d9859ec34a62f45b86d895.1450089383.git.jani.nikula@intel.com
2015-12-15drm/etnaviv: add initial etnaviv DRM driverThe etnaviv authors
This adds the etnaviv DRM driver and hooks it up in Makefiles and Kconfig. Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-12-15drm: use dev_name as default unique name in drm_dev_alloc()Nicolas Iooss
The following code pattern exists in some DRM drivers: ddev = drm_dev_alloc(&driver, parent_dev); drm_dev_set_unique(ddev, dev_name(parent_dev)); (Sometimes dev_name(ddev->dev) is used, which is the same.) As suggested in http://lists.freedesktop.org/archives/dri-devel/2015-December/096441.html, the unique name of a new DRM device can be set as dev_name(parent_dev) when parent_dev is not NULL (vgem is a special case). Signed-off-by: Nicolas Iooss <nicolas.iooss_linux@m4x.org> Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-12-15drm: make drm_dev_set_unique() not use a format stringNicolas Iooss
drm_dev_set_unique() uses a format string to define the unique name of a device. This feature is not used as currently all the calls to this function either use "%s" as a format string or directly use dev_name(). Even though this second kind of call does not introduce security problems, because there cannot be "%" characters in dev_name() results, gcc issues a warning when building with -Wformat-security flag ("warning: format string is not a string literal (potentially insecure)"). This warning is useful to find real bugs like the one fixed by commit 3958b79266b1 ("configfs: fix kernel infoleak through user-controlled format string"). False positives which do not bring an extra value make the work of finding real bugs harder. Therefore remove the format-string feature from drm_dev_set_unique(). Signed-off-by: Nicolas Iooss <nicolas.iooss_linux@m4x.org> Link: http://patchwork.freedesktop.org/patch/msgid/1449829228-4425-1-git-send-email-nicolas.iooss_linux@m4x.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-12-15drm/vmwgfx: Constify function pointer structsVille Syrjälä
Moves a bunch of junk to .rodata from .data. drivers/gpu/drm/vmwgfx/vmwgfx.ko: -.text 132244 +.text 132240 -.rodata 18296 +.rodata 18680 -.data 5096 +.data 4712 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Link: http://patchwork.freedesktop.org/patch/msgid/1450178476-26284-28-git-send-email-boris.brezillon@free-electrons.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>