- 13 Jan, 2016 2 commits
-
-
Daniel Vetter authored
Since commit ac9b8236 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Fri Nov 27 18:55:26 2015 +0200 drm/i915: Introduce a gmbus power domain gmbus also needs the power domain infrastructure right from the start, since as soon as we register the i2c controllers someone can use them. v2: Adjust cleanup paths too (Chris). v3: Rebase onto -nightly (totally bogus tree I had lying around) and also move dpio init head (Ville). v4: Ville instead suggested to move gmbus setup later in the sequence, since it's only needed by the modeset code. v5: Move even close to the actual user, right next to the comment that states where we really need gmbus (and interrupts!). Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Meelis Roos <mroos@linux.ee> Cc: Chris Wilson <chris@chris-wilson.co.uk> Fixes: ac9b8236 ("drm/i915: Introduce a gmbus power domain") Cc: stable@vger.kernel.org References: http://www.spinics.net/lists/intel-gfx/msg83075.htmlSigned-off-by:
Daniel Vetter <daniel.vetter@intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1452682528-19437-1-git-send-email-daniel.vetter@ffwll.chSigned-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Thierry Reding authored
An encoder is associated with a connector by the DRM core as a result of setting up a configuration. Drivers using the atomic or legacy helpers should never set up this link, even if it is a static one. While at it, try to catch this kind of error in the future by adding a WARN_ON() in drm_mode_connector_attach_encoder(). Note that this doesn't cover all the cases, since drivers could set this up after attaching. Drivers that use the atomic helpers will get a warning later on, though, so hopefully the two combined cover enough to help people avoid this in the future. Cc: Russell King <rmk+kernel@arm.linux.org.uk> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Liviu Dudau <Liviu.Dudau@arm.com> Cc: Mark yao <mark.yao@rock-chips.com> Signed-off-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
-
- 11 Jan, 2016 1 commit
-
-
Lukas Wunner authored
Document what I've learned so far about the gmux so that we can collaboratively reverse-engineer its remaining unknown bits without everyone having to start from scratch. The DOC sections are bound together in the gpu.tmpl DocBook under a new vga_switcheroo "Handlers" chapter. Eventually this should be amended with documentation about the four other handlers that exist so far (nouveau v1 DSM, nouveau Optimus DSM, radeon ATPX, amdgpu ATPX). Requires kernel-doc with asciidoc support. The EFI variable was reverse-engineered by Bruno Bierbaumer <bruno@bierbaumer.net> and Andreas Heider <andreas@meetr.de>. Some of the remaining open questions: * How are vblank intervals synchronized on retinas to achieve seamless switching? Is the DP mux capable of this? It's not mentioned in the data sheets. Or is it done at the OS level, i.e. do we have to synchronize vblank intervals between DRM drivers? There's a signal coming from the panel connector and going into gmux, could this be the vblank signal as received by the panel to properly time the switch? * On retinas there's an I2C bus between gmux and the connector of the right I/O board, apparently leading to the Parade PS8401A HDMI repeater. What is this for, is it controlled via gmux registers? Data sheet: http://www.paradetech.com/products/jitter-cleaning-repeaters/ps8401/ * On retinas there's an I2C bus between gmux and the LED driver. Pre-retinas connected the LED driver to SMBUS. Are there additional gmux registers on retinas to control it? * The MacPro6,1 2013 also has a gmux, the same Renesas R4F2113 as the retina MacBook Pro. The Mac Pro doesn't have a built-in display, so what is its purpose? Power control of the dual FirePro GPUs? Switching of the external DP/Thunderbolt ports? The iFixit teardown clearly shows one TI HD3SS212 DisplayPort mux on the logic board next to one of the three Thunderbolt controllers. However six muxes would be necessary to switch all six ports between GPUs. The mux is probably necessary for one of the display configurations allowed by Apple, but which one? https://www.ifixit.com/Teardown/Mac+Pro+Late+2013+Teardown/20778 https://d3nevzfk7ii3be.cloudfront.net/igi/fELBTnt31QhnDsqq.huge https://support.apple.com/en-us/HT202801 * Registers we haven't decoded yet: 0x700 32 Bit configmap? 0x708 32 Bit power sequence? 0x712 8 Bit status of clock from panel on retinas? 0x713 8 Bit dito? 0x724 16 Bit backlight, raw value? 0x760 32 Bit backlight 0x764 32 Bit backlight 0x768 8 Bit backlight 0x76a 16 Bit backlight 0x76c 16 Bit backlight 0x76e 16 Bit backlight 0x77f edp/dp/hdmi probe? retina only. * Addition by Bruno Prémont <bonbons@linux-vserver.org>: "Missing is also precise knowledge as to what the gmux depends on. From behavioral reports, it is somehow sensitive to VGA IO/MEM routing (it apparently needs the routing to go to integrated GPU, not discrete GPU). When the routing is inappropriate backlight control IO just reads back as 0xFF (and eventually gmux IO in general does so)." Signed-off-by:
Lukas Wunner <lukas@wunner.de> Acked-by:
Darren Hart <dvhart@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/da309e436fbeac886477d80376457b7d83ea4b2d.1452431795.git.lukas@wunner.deSigned-off-by:
-
- 08 Jan, 2016 2 commits
-
-
Dan Carpenter authored
We moved the module options from drm_drv.c to drm_irq.c in 18882995 ('drm: Move vblank related module options into drm_irq.c'). Let's move the MODULE_PARM_DESC()s as well so they're together. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Link: http://patchwork.freedesktop.org/patch/msgid/20160108110045.GF32195@mwandaSigned-off-by:
-
Jani Nikula authored
Add a dummy entry to CEA/HDMI mode tables so they can be indexed directly using the VIC, avoiding a +1/-1 dance here and there. This adds clarity to the error checking for various functions that return the VIC on success and zero on failure; we can now explicitly check for 0 instead of just subtracting one from an unsigned type. Also add drm_valid_cea_vic() and drm_valid_hdmi_vic() helpers for checking valid VICs. v2: add drm_valid_cea_vic and drm_valid_hdmi_vic helpers (Ville) use { } instead of { 0 } for initializing the dummy modes Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Alex Deucher <alexander.deucher@amd.com> Signed-off-by:Jani Nikula <jani.nikula@intel.com> Reviewed-by:
-
- 06 Jan, 2016 2 commits
-
-
Maarten Lankhorst authored
Now that connector_mask is reliable there's no need for this function any more. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1451908400-25147-6-git-send-email-maarten.lankhorst@linux.intel.comSigned-off-by:
-
Maarten Lankhorst authored
drm/i915: Update connector_mask during readout, v2. The connector_mask may be used any time during the non-atomic .crtc_disable which is called before the full atomic state is set up and needs to be accurate for that reason. Changes since v1: - Update connector_mask in readout_hw_state and add a comment. Signed-off-by:
-
- 05 Jan, 2016 11 commits
-
-
Chris Wilson authored
drm_gem_handle_delete() contains its own version of drm_gem_object_release_handle(), so lets just call the release method instead. Reported-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1451986951-3703-2-git-send-email-chris@chris-wilson.co.ukReviewed-by:
-
Chris Wilson authored
Good practice dictates that we do not leak stale information to our callers, and should avoid overwriting an outparam on an error path. Reported-by:
-
Daniel Vetter authored
Another pile of vfuncs from the old gpu.tmpl xml documentation that I've forgotten to delete. I spotted a few more things to clarify/extend in the new kerneldoc while going through this once more. v2: Spelling fixes (Thierry). v3: More spelling fixes and use Thierry's proposal to clarify why drivers need to validate modes both in ->mode_fixup and ->mode_valid. Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Thierry Reding <treding@nvidia.com> Acked-by:
-
Daniel Vetter authored
We want this for consistency with existing page_flip semantics. Since this spurred quite a discussion on IRC also document why we reject event generation when the pipe is off: It's not that it's hard to implement, but userspace has a track recording which proves that it's way too easy to accidentally abuse and cause havoc. We want to make sure userspace doesn't get away with that. v2: Somehow thought we do reject events already, but that code only existed in my imagination ... Also suggestions from Thierry. Cc: Daniel Stone <daniels@collabora.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Thierry Reding <thierry.reding@gmail.com> Reviewed-by:
Daniel Stone <daniels@collabora.com> Signed-off-by:
-
Maarten Lankhorst authored
It can be useful to iterate over connectors without grabbing connection_mutex. It can also be used to see how many connectors are on a crtc without iterating over the list. Signed-off-by:
-
Maarten Lankhorst authored
Changes since v1: - Do not reset if state allocation fails. Signed-off-by:
-
Maarten Lankhorst authored
This is useful for drivers that subclass connector_state, like tegra. Changes since v1: - Docbook updates. Signed-off-by:
-
Maarten Lankhorst authored
The atomic helper sets connector_state->connector, which the i915 code didn't. This will become a problem when we start using it. Signed-off-by:
-
Chris Wilson authored
Unlike the handle, the name table uses a sleeping mutex rather than a spinlock. The allocation is in a normal context, and we can use the simpler sleeping gfp_t, rather than have to take from the atomic reserves. Signed-off-by:
-
Chris Wilson authored
We only need a single reference count for all handles (i.e. non-zero obj->handle_count) and so can trim a few atomic operations by only taking the reference on the first handle and dropping it after the last. Signed-off-by:
-
Chris Wilson authored
The current error path for failure when establishing a handle for a GEM object is unbalance, e.g. we call object_close() without calling first object_open(). Use the typical onion structure to only undo what has been set up prior to the error. Signed-off-by:
-
- 04 Jan, 2016 3 commits
-
-
Lukas Wunner authored
Fix indentation of vga_switcheroo sections in gpu.tmpl. Change section type of API documentation from "chapter" to "sect1" so that the individual functions no longer clutter up the ToC. Group together under a new "API" chapter. Fix wording "heretoforth" -> "henceforth". Signed-off-by:
-
Julia Lawall authored
The drm_dp_mst_topology_cbs structures are never modified, so declare them as const. Done with the help of Coccinelle. Signed-off-by:
Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by:
-
Geliang Tang authored
Use to_pci_dev() instead of open-coding it. Signed-off-by:
Geliang Tang <geliangtang@163.com> Signed-off-by:
-
- 21 Dec, 2015 1 commit
-
-
Matt Roper authored
pan_display_atomic() calls drm_atomic_clean_old_fb() to sanitize the legacy FB fields (plane->fb and plane->old_fb). However it was building the plane mask to pass to this function incorrectly (the bitwise OR was using plane indices rather than plane masks). The end result was that sometimes the legacy pointers would become out of sync with the atomic pointers. If another operation tried to re-set the same FB onto the plane, we might end up with the pointers back in sync, but improper reference counts, which would eventually lead to system crashes when we accessed a pointer to a prematurely-destroyed FB. The cause here was a very subtle bug introduced in commit: commit 07d3bad6 Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Date: Wed Nov 11 11:29:11 2015 +0100 drm/core: Fix old_fb handling in pan_display_atomic. I found the crashes were most easily reproduced (on i915 at least) by starting X and then VT switching to a VT that wasn't running a console instance...the sequence of vt/fbcon entries that happen in that case trigger a reference count mismatch and crash the system. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93313Signed-off-by:Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
- 15 Dec, 2015 18 commits
-
-
Nicolas Iooss authored
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:
-
Nicolas Iooss authored
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 3958b792 ("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: -
Ville Syrjälä authored
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:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Ville Syrjälä authored
Moves a bunch of junk to .rodata from .data. drivers/gpu/drm/udl/udl.ko: -.text 11336 +.text 11332 -.rodata 560 +.rodata 684 -.data 696 +.data 572 Signed-off-by:
-
Ville Syrjälä authored
Moves a bunch of junk to .rodata from .data. drivers/gpu/drm/tegra/tegra-drm.ko: -.rodata 13672 +.rodata 13684 -.data 1108 +.data 1096 Signed-off-by:
-
Ville Syrjälä authored
Moves a bunch of junk to .rodata from .data. drivers/gpu/drm/rockchip/dw_hdmi-rockchip.ko: -.rodata 772 +.rodata 828 -.data 148 +.data 92 drivers/gpu/drm/rockchip/rockchipdrm.ko: -.rodata 748 +.rodata 760 -.data 448 +.data 436 Signed-off-by:
-
Ville Syrjälä authored
Moves a bunch of junk to .rodata from .data. drivers/gpu/drm/nouveau/nouveau.ko: -.rodata 105688 +.rodata 105792 -.data 125724 +.data 125620 Signed-off-by:
-
Ville Syrjälä authored
Moves a bunch of junk to .rodata from .data. drivers/gpu/drm/mgag200/mgag200.ko: -.text 29244 +.text 29232 -.rodata 600 +.rodata 668 -.data 688 +.data 620 Signed-off-by:
-
Ville Syrjälä authored
Moves a bunch of junk to .rodata from .data. drivers/gpu/drm/imx/imxdrm.ko: -.rodata 624 +.rodata 652 -.data 372 +.data 344 drivers/gpu/drm/imx/imx-ipuv3-crtc.ko: -.rodata 224 +.rodata 280 -.data 184 +.data 128 drivers/gpu/drm/imx/imx-ldb.ko: -.rodata 660 +.rodata 784 -.data 240 +.data 116 drivers/gpu/drm/imx/imx-tve.ko: -.rodata 400 +.rodata 524 -.data 416 +.data 292 drivers/gpu/drm/imx/parallel-display.ko: -.rodata 400 +.rodata 524 -.data 216 +.data 92 Signed-off-by:
-
Ville Syrjälä authored
Moves a bunch of junk to .rodata from .data. drivers/gpu/drm/i2c/sil164.ko: -.text 1660 +.text 1656 -.rodata 56 +.rodata 104 -.data 212 +.data 164 Signed-off-by:
-
Ville Syrjälä authored
Moves a bunch of junk to .rodata from .data. drivers/gpu/drm/i2c/adv7511.ko: -.rodata 1368 +.rodata 1416 -.data 164 +.data 116 Signed-off-by:
-
Ville Syrjälä authored
Moves a bunch of junk to .rodata from .data. drivers/gpu/drm/exynos/exynosdrm.ko: -.text 125792 +.text 125788 -.rodata 10972 +.rodata 11748 -.data 6720 +.data 5944 Signed-off-by:
Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by:
-
Ville Syrjälä authored
Moves a bunch of junk to .rodata from .data. drivers/gpu/drm/cirrus/cirrus.ko: -.text 10104 +.text 10092 -.rodata 528 +.rodata 596 -.data 608 +.data 540 Signed-off-by:
-
Ville Syrjälä authored
Moves a bunch of junk to .rodata from .data. drivers/gpu/drm/i2c/ch7006.ko: -.text 5752 +.text 5760 -.rodata 6608 +.rodata 6656 -.data 216 +.data 168 Signed-off-by:
-
Ville Syrjälä authored
Moves a bunch of junk to .rodata from .data. drivers/gpu/drm/bridge/nxp-ptn3460.ko: -.rodata 440 +.rodata 536 -.data 208 +.data 112 Signed-off-by:
-
Ville Syrjälä authored
Moves a bunch of junk to .rodata from .data. drivers/gpu/drm/bridge/dw_hdmi.ko: -.rodata 120 +.rodata 216 -.data 96 +.data 0 Signed-off-by:
-
Ville Syrjälä authored
Moves a bunch of junk to .rodata from .data. drivers/gpu/drm/bochs/bochs-drm.ko: -.text 7608 +.text 7600 -.rodata 648 +.rodata 716 -.data 612 +.data 544 Signed-off-by:
-
Ville Syrjälä authored
Moves a bunch of junk to .rodata from .data. drivers/gpu/drm/atmel-hlcdc/atmel-hlcdc-dc.ko: -.text 12488 +.text 12480 -.rodata 1696 +.rodata 1760 -.data 776 +.data 712 Signed-off-by:
-
