- 24 Jun, 2016 16 commits
-
-
Chris Wilson authored
Baby step, update to_i915() conversion from drm_device to drm_i915_private: text data bss dec hex filename 1108812 23207 416 1132435 114793 i915.ko (before) 1104999 23207 416 1128622 1138ae i915.ko (after) Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1466773227-7994-9-git-send-email-chris@chris-wilson.co.uk
-
Chris Wilson authored
drm_connector_register_all() is now automatically called by drm_dev_register(), and so we no longer have to do so ourselves (via intel_modeset_register() after calling drm_dev_register()). Similarly for unregistering. Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1466773227-7994-8-git-send-email-chris@chris-wilson.co.uk
-
Chris Wilson authored
To complete the transition to manual control of load/unload, we need to take over unloading from i915_pci_remove(). This allows us to correctly order our unregister vs shutdown phases, which currently are inverted due to the midlayer. However, the unload sequence is still invalid as we shutdown the driver with the last reference. Ideally, all we want to do is remove the userspace access on device removal, deferring the cleanup to the drm_dev_release() - breaking the reference cycles is then left as an exercise for the reader. Signed-off-by:
-
Chris Wilson authored
Take control over allocating, loading and registering the driver from the DRM midlayer by performing it manually from i915_pci_probe. This allows us to carefully control the order of when we setup the hardware vs when it becomes visible to third parties (including userspace). The current ordering makes the driver visible to userspace first (in order to coordinate with removed DRI1 userspace), but that ordering incurs risk. The risk increases as we strive for more asynchronous loading. One side effect of controlling the allocation is that we can allocate both the drm_device + drm_i915_private in one block, the next step towards subclassing. Unload is still left as before, a mix of midlayer and driver. v2: After drm_dev_init(), we should call drm_dev_unref() so that we call drm_dev_release() and free everything from drm_dev_init(). v3: Fixup missed error code for failing to allocate dev_priv Suggested-by:
-
Chris Wilson authored
Currently debugfs files are created before the driver is even loads. This gives the opportunity for userspace to open that interface and poke around before the backing data structures are initialised - with the possibility of oopsing or worse. Move the creation of the debugfs files to our registration phase, where we announce our presence to the world when we are ready, i.e the sequence changes from drm_dev_register() -> drm_minor_register() -> drm_debugfs_init() -> i915_debugfs_init() -> i915_driver_load() to drm_dev_register() -> drm_minor_register() -> drm_debugfs_init() -> i915_driver_load() -> i915_debugfs_register() Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Chris Wilson authored
Defer connector registration from during construction to the driver registration phase. This is important for ordering the action correctly, e.g. not using debugfs before it is ready. Signed-off-by:
-
Chris Wilson authored
Currently the backlight is being registered in the load phase (before the display and its objects are registered). Move the backlight registration into the analogous phase by performing it from the connector registration, just after its creation. Signed-off-by:
-
Chris Wilson authored
With the introduction of a connector->func for callback from drm_connector_register() we can move all the tasks that we want to do upon registration into that callback. Later, this will allow us to reorder the registration and defer it until after the device is setup and ready for userspace. Signed-off-by:
-
Chris Wilson authored
Currently setting up the backlight for a panel is sometimes done together with initialising the panel, and sometimes after the connector is registered. The backlight setup does not depend upon connector registration (i.e. access to sysfs/debugfs and the kobject hierachy) so perform it consistently just after panel initialisation. Note the discrepancy here as destroying the panel is done during connector unregistration... Signed-off-by:
-
Tvrtko Ursulin authored
Effectively removes one layer of indirection between the mask of possible engines and the engine constructors. Instead of spelling out in code the mapping of HAS_<engine> to constructors, makes more use of the recently added data driven approach by putting engine constructor vfuncs into the table as well. Effect is fewer lines of source and smaller binary. At the same time simplify the error handling since engine destructors can run on unitialized engines anyway. Similar approach could be done for legacy submission is wanted. v2: Removed ugly BUILD_BUG_ONs in favour of newly introduced ENGINE_MASK and HAS_ENGINE macros. Also removed the forward declarations by shuffling functions around. v3: Warn when logical_rings table does not contain enough data and disable the engines which could not be initialized. (Chris Wilson) v4: Chris Wilson suggested a nicer engine init loop. Signed-off-by: -
Daniel Vetter authored
Backmerge drm-next for the reworked device register/unregistering. Chris Wilson needs that to be able to land his i915 load/unload demidlayering. Signed-off-by:Daniel Vetter <daniel.vetter@intel.com>
-
git://git.pengutronix.de/git/pza/linuxDave Airlie authored
MT8173 HDMI support - device tree binding documentation for MT8173 HDMI encoder, CEC, DDC, and PHY - drivers for MT8173 HDMI encoder, CEC (HPD only for now), DDC, and PHY - enable HDMI output via a custom SMCCC call - add ddc-i2c-bus property to HDMI connector device tree binding * tag 'mediatek-drm-2016-06-20' of git://git.pengutronix.de/git/pza/linux: dt-bindings: hdmi-connector: add DDC I2C bus phandle documentation drm/mediatek: enable hdmi output control bit drm/mediatek: Add HDMI support dt-bindings: drm/mediatek: Add Mediatek HDMI dts binding
-
git://linuxtv.org/pinchartl/mediaDave Airlie authored
some rcar-du fixes. * 'drm/next/du' of git://linuxtv.org/pinchartl/media: drm: rcar-du: error message is not needed for EPROBE_DEFER drm: rcar-du: error message is not needed for drm_vblank_init() rcar-du: add/rename DEFR6 TCON bits
-
git://anongit.freedesktop.org/drm-intelDave Airlie authored
- Infrastructure for GVT-g (paravirtualized gpu on gen8+), from Zhi Wang - another attemp at nonblocking atomic plane updates - bugfixes and refactoring for GuC doorbell code (Dave Gordon) - GuC command submission enabled by default, if fw available (Dave Gordon) - more bxt w/a (Arun Siluvery) - bxt phy improvements (Imre Deak) - prep work for stolen objects support (Ankitprasa Sharma & Chris Wilson) - skl/bkl w/a update from Mika Kuoppala - bunch of small improvements and fixes all over, as usual * tag 'drm-intel-next-2016-06-20' of git://anongit.freedesktop.org/drm-intel: (81 commits) drm/i915: Update DRIVER_DATE to 20160620 drm/i915: Introduce GVT context creation API drm/i915: Support LRC context single submission drm/i915: Introduce execlist context status change notification drm/i915: Make addressing mode bits in context descriptor configurable drm/i915: Make ring buffer size of a LRC context configurable drm/i915: gvt: Introduce the basic architecture of GVT-g drm/i915: Fold vGPU active check into inner functions drm/i915: Use offsetof() to calculate the offset of members in PVINFO page drm/i915: Factor out i915_pvinfo.h drm/i915: Serialise presentation with imported dmabufs drm/i915: Use atomic commits for legacy page_flips drm/i915: Move fb_bits updating later in atomic_commit drm/i915: nonblocking commit Reapply "drm/i915: Pass atomic states to fbc update, functions." drm/i915: Roll out the helper nonblock tracking drm/i915: Signal drm events for atomic drm/i915/ilk: Don't disable SSC source if it's in use drm/i915/guc: (re)initialise doorbell h/w when enabling GuC submission drm/i915/guc: replace assign_doorbell() with select_doorbell_register() ...
-
Dave Airlie authored
Merge tag 'topic/drm-misc-2016-06-22-updated' of git://anongit.freedesktop.org/drm-intel into drm-next Again a pile of things all over - Conversion to rst from docbook from Jani. Looks real pretty, and the source is now actually readable (compared to horrible, horrible docbook xml)! https://01.org/linuxgraphics/gfx-docs/drm/ - device register/unregister rework from Chris, with follow-up work from Benjamin. Allows more drivers to demidlayer load/unload and others to remove a bit of boilerplate. - master/auth related cleanup, with docs - some dma-buf polish, merged by Sumit - small stuff all over (like build fixes from Arnd) Group maintainership seems to slowly take off, with both Thierry and Sumit pushing a few things. No hiccups thus far. * tag 'topic/drm-misc-2016-06-22-updated' of git://anongit.freedesktop.org/drm-intel: (68 commits) drm/vc4: Remove unused connector drm/fb-helper: Reduce READ_ONCE(master) to lockless_dereference drm/sun4i: Remove open-coded drm_connector_register_all() drm/vc4: Remove open-coded drm_connector_register_all() drm/atmel-hlcdc: Remove redundant call to drm_connector_unregister_all() drm: document drm_auth.c drm: Clear up master tracking booleans drm: Extract drm_is_current_master drm: Refactor drop/set master code a bit drm: Lobotomize set_busid nonsense for !pci drivers drm: Nuke SET_UNIQUE ioctl drm: Don't call drm_dev_set_unique from platform drivers drm/vgem: Stop calling drm_drv_set_unique drm: Use dev->name as fallback for dev->unique drm: Clean up drm_crtc.h drm: Move master pointer from drm_minor to drm_device drm: sti: rework init sequence drm: sti: use late_register and early_unregister callbacks drm/amdkfd: Clean up inline handling drm: Add callbacks for late registering ...
-
Dave Airlie authored
Add basic support for the sii902x RGB -> HDMI bridge. * tag 'drm-sii902x' of github.com:bbrezillon/linux-at91: drm/bridge: Add sii902x DT bindings doc drm/bridge: Add sii902x driver
-
- 22 Jun, 2016 13 commits
-
-
Ville Syrjälä authored
During hibernation the cached DP port register value will be left with whatever value we have there when we create the hibernation image. Currently that means the port (and eDP PLL) will be off in the cached value. However when we resume there is no guarantee that the value in the actual register will match the cached value. If i915 isn't loaded in the kernel that loads the hibernation image, the port may well be on (eg. left on by the BIOS). The encoder state readout does the right thing in this case and updates our encoder state to reflect the actual hardware state. However the post-resume modeset will then use the stale cached port register value in intel_dp_link_down() and potentially confuse the hardware. This was caught by the following assert WARNING: CPU: 3 PID: 5288 at ../drivers/gpu/drm/i915/intel_dp.c:2184 assert_edp_pll+0x99/0xa0 [i915] eDP PLL state assertion failure (expected on, current off) on account of the eDP PLL getting prematurely turned off when shutting down the port, since the DP_PLL_ENABLE bit wasn't set in the cached register value. Presumably I introduced this problem in commit 6fec7662 ("drm/i915: Use intel_dp->DP in eDP PLL setup") as before that we didn't update the cached value after shuttting the port down. That's assuming the port got enabled at least once prior to hibernating. If that didn't happen then the cached value would still have been totally out of sync with reality (eg. first boot w/o eDP on, then hibernate, and then resume with eDP on). So, let's fix this properly and refresh the cached register value from the hardware register during resume. DDI platforms shouldn't use the cached value during port disable at least, so shouldn't have this particular issue. They might still have issues if we skip the initial modeset and then try to retrain the link or something. But untangling this DP vs. DDI mess is a bigger topic, so let's jut punt on DDI for now. Cc: Jani Nikula <jani.nikula@intel.com> Cc: stable@vger.kernel.org Fixes: 6fec7662 ("drm/i915: Use intel_dp->DP in eDP PLL setup") Signed-off-by:
Imre Deak <imre.deak@intel.com>
-
Imre Deak authored
The wait for panel status helper will only function correctly if the HW panel timings are programmed correctly. Returning prematurely from this helper may lead to obscure bugs later, so sanity check the HW timing registers. v2: - Check the T8, T9 fields too, we do program them (Ville) CC: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Imre Deak authored
This will be needed by the next patch too so factor it out. No functional change. Signed-off-by:
-
Imre Deak authored
No functional change. Signed-off-by:
-
Imre Deak authored
The PPS registers are backed by power well #0 and as such may be reset after system or runtime suspend (both implying a possible DC9 transition). Fix this by reusing the VLV/CHV PPS pipe-reassignment logic. The difference on BXT is that the PPS instances are not pipe but port (or more accurately pin) specific, so we only need to care about the lost HW state. As opposed to VLV/CHV the SW state is fixed and initialized during connector init. This also paves the way towards using the actual port->PPS instance mapping based on VBT. This fixes eDP link training errors on BXT after suspend, where we started the link training too early due to an incorrect T3 (panel power on) register value. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96436Signed-off-by:
-
Imre Deak authored
Move the early PPS initialization calls next to the rest of PPS initialization steps. This allows us to forgo a duplicated call to intel_dp_init_panel_power_sequencer_registers() on VLV/CHV. This will swap the order of DP AUX registration wrt. PPS initialization. There is an existing race here in case of a user space access via the DPAUX device node after DP AUX registration and before calling intel_dp_init_panel_power_sequencer_registers(), but this change won't make this worse. The fix for this is to separate DP AUX initialization and registration, that's a separate work already underway. The order of MST wrt. PPS init as well as the order of intel_dp_init_panel_power_sequencer_registers() wrt. intel_edp_panel_vdd_sanitize() also swap, which is ok, there are no dependencies between these steps. Suggested by Ville. CC: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Imre Deak authored
The initial DPCD read for eDP detection involves using the PPS, but so far we only initialized the PPS registers after the DPCD read. The reason this was done so far is to preserve a possible LVDS PPS HW setup if LVDS is detected but eDP is not. This is not an issue any more after the previous patch, so we can move the init earlier now. This was caught by CI with the PPS sanity checks in place and the initial eDP DPCD readout waiting for the panel power cycle timeout without the PPS registers being initialized. CC: Ville Syrjälä <ville.syrjala@linux.intel.com> CC: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Imre Deak authored
Atm on IBX/CPT we attempt to detect if eDP is present even if LVDS was already detected and an encoder for it was registered. This involves trying to read out the eDP DPCD, which in turn needs the same power sequencer that LVDS uses. Poking at the VDD line at an unexpected time may or may not interfere with the LVDS panel, but it's probably safer to prevent this. Registering both an LVDS and an eDP connector would also present a similar problem accessing the shared PPS at any point later in an unexpected way. We also need this to be able fix PPS initialization before its first use in the next patch. For that we want to be sure that PPS is not in use by LVDS. v2: - Split out the PPS init fix to a separate patch. (Chris) - Add comment about eDP init depending on LVDS init. (Chris) - Make the use of the intel_encoder ptr less error prone. v3: - Use IBX/CPT reference instead of the incorrect ILK, add a WARN about this. (Ville) v4: - Use a helper to get the lvds encoder instead of opencoding the same. (Ville) CC: Ville Syrjälä <ville.syrjala@linux.intel.com> CC: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Daniel Vetter authored
Somehow I didn't spot this when pushing :( Fixes: 398e9799 ("drm/vc4: Remove open-coded drm_connector_register_all()") Acked-by:
-
Chris Wilson authored
We are only documenting that the read is outside of the lock, and do not require strict ordering on the operation. In this case the more relaxed lockless_dereference() will suffice. Signed-off-by:
-
Chris Wilson authored
drm_dev_register() will now register all known connectors, so we no longer have to do so manually. Signed-off-by:
-
Chris Wilson authored
drm_dev_register() will now register all known connectors, so we no longer have to do so manually. Signed-off-by:
-
Chris Wilson authored
drm_connector_unregister_all() is not automatically called by drm_dev_unregister() so we can drop the local call. Signed-off-by:
-
- 21 Jun, 2016 11 commits
-
-
Daniel Vetter authored
Also extract drm_auth.h for nicer grouping. v2: Nuke the other comments since they don't really explain a lot, and within the drm core we generally only document functions exported to drivers: The main audience for these docs are driver writers. v3: Limit the exposure of drm_master internals by only including drm_auth.h where it is neede (Chris). v4: Spelling polish (Emil). Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by:
-
Daniel Vetter authored
- is_master can be removed, we can compute this by checking allowed_master (which really just tracks whether a master struct has been allocated for this fpriv in either open or set_master), and whether the fpriv is the current master on the device. - that frees up is_master as a good replacement name for allowed_master. With that it's clear that it tracks whether the fpriv is a master (with possibly clients attached to it and authenticated against it), and that one of those fprivs with is_master set is the current master. v2: Fix kerneldoc for is_master (Emil). Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by:
-
Daniel Vetter authored
Just rolling out a bit of abstraction to be able to clean up the master logic in the next step. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by:
-
Daniel Vetter authored
File open/set_maseter ioctl and file close/drop_master ioctl share the same master handling code. Extract it. Note that vmwgfx's master_set callback needs to know whether the master is a new one or has been used already, so thread this through. On the close/drop side a similar parameter existed, but wasnt used. Drop it to simplify the flow. v2: Try to make it not leak so much (Emil). v3: Send out the right version ... Cc: Emil Velikov <emil.l.velikov@gmail.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by:
-
Daniel Vetter authored
We already have a fallback in place to fill out the unique from dev->unique, which is set to something reasonable in drm_dev_alloc. Which means we only need to have a special set_busid for pci devices, to be able to care the backwards compat code for drm 1.1 around, which libdrm still needs. While developing and testing this patch things blew up in really interesting ways, and the code is rather confusing in naming things between the kernel code, ioctl #defines and libdrm. For the next brave dragon slayer, document all this madness properly in the userspace interface section of gpu.tmpl. v2: Make drm_dev_set_unique static and update kerneldoc. v3: Entire rewrite, plus document what's going on for posterity in the gpu docbook uapi section. v4: Drop accidental amdgpu hunk (Emil). v5: Drop accidental omapdrm vblank counter change (Emil). v6: Rebase on top of the sphinx conversion. Cc: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Cc: Emil Velikov <emil.l.velikov@gmail.com> Tested-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> (virt_gpu) Reviewed-by:
-
Daniel Vetter authored
Ever since commit 2e1868b560315a8b20d688e646c489a5ad93eeae Author: Eric Anholt <anholt@freebsd.org> Date: Wed Jun 16 09:25:21 2004 +0000 DRI trunk-20040613 import the X server supports drm 1.1, thus doesn't call call libdrm's drmSetBusid - the sole user of this ioctl. When reviewing this note that for hilarity both the kernel-internal functions (set_busid) and the libdrm wrapper (drmSetBusid) have names not matching this ioctl (SET_UNIQUE). v2: Polish commit message (Emil). Cc: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by: -
Daniel Vetter authored
Since commit e112e593 Author: Nicolas Iooss <nicolas.iooss_linux@m4x.org> Date: Fri Dec 11 11:20:28 2015 +0100 drm: use dev_name as default unique name in drm_dev_alloc() we're using a reasonable default which should work for everyone. Only mtk, rcar-du and sun4i are affected, and as kms-only drivers without any rendering support no one should ever care about the unique name v2: Rebase on top of mediatek. Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: Maxime Ripard <maxime.ripard@free-electrons.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by:
Maxime Ripard <maxime.ripard@free-electrons.com> Acked-by:
Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by:
-
Daniel Vetter authored
With the previous patch this is now redudant, the core always sets a reasonable dev->unique string. Cc: Sean Paul <seanpaul@chromium.org> Reviewed-by:
-
Daniel Vetter authored
Lots of arm drivers get this wrong and for most arm boards this is the right thing actually. And anyway with most loaders you want to chase sysfs links anyway to figure out which dri device you want. This will fix dmesg noise for rockchip and sti. Also add a fallback to driver->name for entirely virtual drivers like vgem. v2: Rebase on top of commit e112e593 Author: Nicolas Iooss <nicolas.iooss_linux@m4x.org> Date: Fri Dec 11 11:20:28 2015 +0100 drm: use dev_name as default unique name in drm_dev_alloc() and simplify a bit. Plus add a comment. v3: WARN_ON(!dev->unique) as discussed with Emil. Cc: Ilia Mirkin <imirkin@alum.mit.edu> Reported-by:
Ilia Mirkin <imirkin@alum.mit.edu> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v2) Reviewed-by:
-
Daniel Vetter authored
- Group declarations for separate files (drm_bridge.c, drm_edid.c) - Move declarations only used within drm.ko to drm_crtc_internal.h - drm_property_type_valid to drm_crtc.c, its only callsite Reviewed-by:
-
Daniel Vetter authored
There can only be one current master, and it's for the overall device. Render/control minors don't support master-based auth at all. This simplifies the master logic a lot, at least in my eyes: All these additional pointer chases are just confusing. While doing the conversion I spotted some locking fail: - drm_lock/drm_auth check dev->master without holding the master_mutex. This is fallout from commit c996fd0b Author: Thomas Hellstrom <thellstrom@vmware.com> Date: Tue Feb 25 19:57:44 2014 +0100 drm: Protect the master management with a drm_device::master_mutex v3 but I honestly don't care one bit about those old legacy drivers using this. - debugfs name info should just grab master_mutex. - And the fbdev helper looked at it to figure out whether someone is using KMS. We just need a consistent value, so READ_ONCE. Aside: We should probably check if anyone has opened a control node too, but I guess current userspace doesn't really do that yet. v2: Balance locking, reported by Julia. v3: Rebase on top of Chris' oops fixes. Cc: Julia Lawall <julia.lawall@lip6.fr> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v2) Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> (v2) Signed-off-by:
-
