- 29 Mar, 2019 2 commits
-
-
git://linuxtv.org/pinchartl/mediaDave Airlie authored
R-Car DU miscellaneous changes for v5.2 Signed-off-by:
Dave Airlie <airlied@redhat.com> From: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190328042035.GA4846@pendragon.ideasonboard.com
-
git://anongit.freedesktop.org/drm/drm-intelDave Airlie authored
UAPI Changes: - Make mmap code more asynchronous. Avoid full SET_DOMAIN on GTT mmap pagefault, and flushes pages on acquisition instead. Moves some of the work from mmap fault time to execbuf time to avoid lock contention during mmap access. Has neutral to positive impact on perf as the flushing moves to execbuf time in real world workloads on the current known userspaces due to recycling of BOs. If there exist an unknown non-recycling userspace, they should explicitly do the SET_DOMAIN and not rely on kernel doing implicit SET_DOMAIN because swapout/in might have happenedt. - Restore the accidentally removed behaviour of returning object size on GEM_CREATE From 2011: ff72145b ("drm: dumb scanout create/mmap for intel/radeon (v3)") - Includes a some neutered patches to prepare to complete the earlier Mesa recovery feature uAPI. Looking to enable this in the next PR. Driver Changes: - Add Elkhartlake (Gen11) support code and PCI IDs - Add missing Amberlake PCI ID 0x87CA (Ville) - Fix to Bugzilla #109780: Pick the first mode from EDID as the fixed mode when there is no preferred mode (Ville) - Fix GCC 4.8 build by using __is_constexpr() (Chris, Randy, Uma) - Add "Broadcast RGB", "force_audio" and "max_bpc" properties to DP MST (Ville) - Remove 8bpc limitation from DP MST (Ville) - Fix changing between limited and full range RGB output in DP fastsets (Ville) - Reject unsupported HDR formats (Maarten) - Handle YUV subpixel support better (Maarten) - Various plane watermarks fixes and cleaning of the code (Ville) - Icelake port sync master select fix (Manasi) - Icelake VEBOX disable bitmask fix (Jose) - Close a race where userspace could see incompletely initialized GEM context (Chris) - Avoid C3 on i945gm to keep vblank interrupts steady (Ville) - Avoid recalculating PLL HW readout each time (Lucas) - A ton of patches to modularize uncore code (Daniel) - Instead of storing media fuse value, immediately derive engine masks (Daniele) - Reduce struct_mutex usage (Chris) - Iterate over child devices to initialize ddi_port_info (Jani) - Fixes to return correct error values when bailing out of functions (Dan) - Use bitmap_zalloc() (Andy) - Reorder and clarify Gen3/4 code (Ville) - Refactor out common code in display mode handling (Ville) - GuC code fixes (Sujaritha, Michal) - Selftest improvements (Chris) Signed-off-by:
-
- 28 Mar, 2019 12 commits
-
-
Joonas Lahtinen authored
Signed-off-by:Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
-
Joonas Lahtinen authored
Signed-off-by: -
Joonas Lahtinen authored
Signed-off-by: -
Laurent Pinchart authored
On the D3 SoC the LVDS PHY must be enabled in the same register write that enables the LVDS output. Skip writing the LVEN bit independently on that platform, it will be set by the write that sets LVRES. Signed-off-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by:
Jacopo Mondi <jacopo+renesas@jmondi.org>
-
Laurent Pinchart authored
The D3 and E3 SoCs have different pixel clock frequency limits for the LVDS encoder than the other SoCs in the Gen3 family. Adjust the mode fixup implementation accordingly. Signed-off-by:
-
Kieran Bingham authored
The rcar_du_crtc functions have a heavy reliance on the rcar_du_group structure, in many cases just to access the DU device context. To better separate the groups out of the CRTC handling code, give the rcar_du_crtc its own pointer to the device and remove the indirection through the group pointers. Signed-off-by:
Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Reviewed-by:
-
Laurent Pinchart authored
The PLL parameters are computed by looping over the range of acceptable M, N and E values, and selecting the combination that produces the output frequency closest to the target. The internal frequency constraints are taken into account by restricting the tested values for the PLL parameters, reducing the search space. The target frequency, however, is only taken into account when computing the post-PLL divider, which can result in a 0 value for the divider when the PLL output frequency being tested is lower than half of the target frequency. Subsequent loops will produce a better set of PLL parameters, but for some of the iterations this can result in a division by 0. Fix it by clamping the divider value. We could instead restrict the E values being tested in the inner loop, but that would require additional calculation that would likely be less efficient as the E parameter can only take three different values. Fixes: c25c0136 ("drm: rcar-du: lvds: D3/E3 support") Signed-off-by:
-
Laurent Pinchart authored
drm_framebuffer.h makes use of a pointer to struct drm_format_info but doesn't include drm_fourcc.h (neither directly nor indirectly). Forward-declare the structure. Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Sam Ravnborg <sam@ravnborg.org>
-
Kieran Bingham authored
The CRTC suspend and resume functions have been replaced, but the prototypes were not removed. Remove the redundant definitions. Signed-off-by:
Simon Horman <horms+renesas@verge.net.au> Reviewed-by:
-
Kieran Bingham authored
The rcar_du_crtc_mode_valid() and rcar_du_crtc_get_crc_sources() functions are accessed only through a function pointer table. Convert the function definitions to be static to the module. Signed-off-by:
-
Kieran Bingham authored
The drm_crtc_state documentation contains a subtle misspelling of the word subtle. Correct it. Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
-
Laurent Pinchart authored
The R-Car DU driver assumes that a bridge is always connected to the DU output. This is valid for the LVDS and HDMI outputs, but the DPAD outputs can be connected directly to a panel, in which case no bridge is available. To support this use case, detect whether the entities connected to the DU DPAD outputs are encoders or panels based on the number of ports of their DT node, and retrieve the corresponding type of DRM objects. For panels, additionally create panel bridge instances. Signed-off-by:
Kevin Key <kevin.key@gentex.com> Reviewed-by:
-
- 27 Mar, 2019 13 commits
-
-
Maarten Lankhorst authored
90/270 rotation is not supported for Y21x and the 12/16 bits XVYU formats, reject support for them. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190322135954.20434-3-maarten.lankhorst@linux.intel.comReviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com>
-
Maarten Lankhorst authored
This was missing in the original addition of those formats, but in PLANE_SIZE description it's mentioned that 8 cpp formats are not valid with Yf tiling. Reject this case properly. Also reject Y21x Yf tiling support this is also not supported. Changes since v1: - Reject Y21x as well. Signed-off-by:
-
Maarten Lankhorst authored
Y41x formats is a 4:4:4 format, so it can be addressed with pixel level accuracy. Meanwhile it seems that while rotating YUYV 4:2:2 formats need a multiple of 2 for width and height, otherwise corruption occurs. For YUV 4:2:2, the spec says that w/h should always be even, but we get away with odd height while unrotated. When rotating it seems corruption occurs with an odd x/y, and w/h should always be even. Just to be completely paranoid, reject odd x/y w/h when rotating 90/270. Signed-off-by:
-
Joonas Lahtinen authored
This is needed to get the fourcc code merged without conflicts. Signed-off-by: -
Chris Wilson authored
The intent was to expose these as part of the means to perform full context recovery (though not the SINGLE_TIMELINE, that is for later and just sucked as collateral damage). As that requires a couple more patches to complete the series, roll back the earlier chunks of ABI for an intervening PR. We keep all the internals intact and under selftests. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190327105814.14694-1-chris@chris-wilson.co.ukReviewed-by:
-
Zhenyu Wang authored
This is to disable semaphore usage when on vGPU for now. Unfortunately GVT-g hasn't fully enabled semaphore usage yet, so current guest with semaphore use would cause vGPU failure. Although current semaphore failure with vGPU can be simply resolved by allowing cmd parser to accept MI_SEMAPHORE_WAIT command with address audit, we're checking general usage of semaphore and how we should handle it properly for virtualization in consider of function and security concern. So we decide to request to disable it for now in guest driver. Once GVT could support it, we would add new compat bit to turn it on. Fixes: e8861964 ("drm/i915: Use HW semaphores for inter-engine synchronisation on gen8+") #vgpu Cc: Kevin Tian <kevin.tian@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Zhenyu Wang <zhenyuw@linux.intel.com> Acked-by:
-
Ville Syrjälä authored
Update the DP MSA MISC bits for fastsets. This is needed when we change between limited and full range RGB output. On HSW+ changing limited_range does not currently result in a full modeset since we have don't have the readout code for it (for DP we could, and probably should, readout from TRANS_MSA_MISC itself, for HDMI we would have to rely on the infoframe). So the PIPE_CONF_CHECK() is only performed for pre-HSW platforms. That means any change in the value will result in a fastset instead. Fortunately there is no prohibition to changing TRANS_MSA_MISC dynamically, so it looks like we can legally do fastsets for this. Signed-off-by:
-
Ville Syrjälä authored
Allow the user to limit the output bpc with DP MST. Signed-off-by:
-
Ville Syrjälä authored
Allow DP MST to output any color depth. This means deep color as well as falling back to 6bpc if we would otherwise require too much bandwidth. TODO: We should probably extend bw_contstrained scheme to force all streams on the link to 6bpc if we can't fit the new stream(s) otherwise. v2: Use a proper for-loop (Jani) Signed-off-by:
-
Ville Syrjälä authored
We already expose the force_audio property with SST. Do the same with MST. Signed-off-by:
-
Ville Syrjälä authored
Add the "Broadcast RGB" property to MST connectors, and implement the same logic for it as we have in the SST code. v2: Extract and reuse intel_dp_limited_color_range() Cc: Ivan Vlk <ari@adyline.sk> Tested-by:
Ivan Vlk <ari@adyline.sk> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108821Signed-off-by:
-
José Roberto de Souza authored
GT VEBOX DISABLE is only 4 bits wide but it was using a 8 bits wide mask, the remaning reserved bits is set to 0 causing 4 more nonexistent VEBOX engines being detected as enabled, triggering the BUG_ON() because of mismatch between vebox_mask and newly added VEBOX_MASK(). [ 64.081621] [drm:intel_device_info_init_mmio [i915]] vdbox enable: 0005, instances: 0005 [ 64.081763] [drm:intel_device_info_init_mmio [i915]] vebox enable: 00f1, instances: 0001 [ 64.081825] intel_device_info_init_mmio:925 GEM_BUG_ON(vebox_mask != ({ unsigned int first__ = (VECS0); unsigned int count__ = (2); ((&(dev_priv)->__info)->engine_mask & (((~0UL) - (1UL << (first__)) + 1) & (~0UL >> (64 - 1 - (first__ + count__ - 1))))) >> first__; })) [ 64.082047] ------------[ cut here ]------------ [ 64.082054] kernel BUG at drivers/gpu/drm/i915/intel_device_info.c:925! BSpec: 20680 Fixes: 9511cb64 ("drm/i915: Adding missing '; ' to ENGINE_INSTANCES") Fixes: 26376a7e ("drm/i915/icl: Check for fused-off VDBOX and VEBOX instances") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Oscar Mateo <oscar.mateo@intel.com> Signed-off-by:José Roberto de Souza <jose.souza@intel.com> Reviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by:
-
Daniele Ceraolo Spurio authored
When building with ARCH=i386, readq and writeq are not defined, resulting in: intel_uncore.h: In function ‘__raw_uncore_read64’: intel_uncore.h:257:9: error: implicit declaration of function ‘readq’; did you mean ‘readl’? [-Werror=implicit-function-declaration] return read##s__(uncore->regs + i915_mmio_reg_offset(reg)); \ ^ and: intel_uncore.h: In function ‘__raw_uncore_write64’: intel_uncore.h:264:2: error: implicit declaration of function ‘writeq’; did you mean ‘writel’? [-Werror=implicit-function-declaration] write##s__(val, uncore->regs + i915_mmio_reg_offset(reg)); \ ^ Add the io-64-nonatomic-lo-hi include to have readq and writeq available for all builds. This header internally includes linux/io.h, so the native readq and writeq definitions will be used when available. Fixes: 6cc5ca76 ("drm/i915: rename raw reg access functions") Signed-off-by:Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by:
-
- 26 Mar, 2019 13 commits
-
-
Chris Wilson authored
Tvrtko spotted that I left off the trailing ';'. It went unnoticed by CI because despite adding the macro, we didn't add a user, so include one as well (a simple debug print). Reported-by:
-
Michał Winiarski authored
Since GEM_CREATE is trying to outsmart the user by rounding up unaligned objects, we used to update the size returned to userspace. This update seems to have been lost throughout the history. v2: Use round_up(), reorder locals (Chris) References: ff72145b ("drm: dumb scanout create/mmap for intel/radeon (v3)") Signed-off-by:
Michał Winiarski <michal.winiarski@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Janusz Krzysztofik <janusz.krzysztofik@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by:
-
Daniele Ceraolo Spurio authored
A few advantages: - Prepares us for the planned split of display uncore from GT uncore - Improves our engine-centric view of the world in the engine code and allows us to avoid jumping back to dev_priv. - Allows us to wrap accesses to engine register in nice macros that automatically pick the right mmio base. Signed-off-by:
-
Daniele Ceraolo Spurio authored
The intel_uncore structure is the owner of register access, so subclass the function to it. While at it, use a local uncore var and switch to the new read/write functions where it makes sense. Signed-off-by:
-
Daniele Ceraolo Spurio authored
The intel_uncore structure is the owner of register access, so subclass the function to it. While at it, use a local uncore var and switch to the new read/write functions where it makes sense. Signed-off-by:
-
Daniele Ceraolo Spurio authored
The intel_uncore structure is the owner of FW, so subclass the function to it. While at it, use a local uncore var and switch to the new read/write functions where it makes sense. Signed-off-by:
-
Daniele Ceraolo Spurio authored
The full read/write ops can now work on the intel_uncore struct. Introduce intel_uncore_read/write functions working on intel_uncore and switch the I915_READ/WRITE macro to internally call those. v2: no change v3: add intel_uncore_read/write functions (Chris), update commit msg Signed-off-by:
-
Daniele Ceraolo Spurio authored
Remove a bit of pointer dancing in the reg access path. Signed-off-by:
-
Daniele Ceraolo Spurio authored
Save the HW capabilities to avoid having to jump back to dev_priv every time. Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
Daniele Ceraolo Spurio authored
We have several cases where we don't have forcewake (older gens, GVT and planned display-only uncore), so, instead of checking every time against the various condition, save the info in a flag and use that. Note that this patch also change the behavior for gen5 with vpgu enabled, but this is not an issue since we don't support vgpu on gen5. v2: split out from previous path, fix check for missing case (Paulo) v3: Inline helper for clarity in testing flags Signed-off-by:
-
Daniele Ceraolo Spurio authored
They now work on uncore, so use raw_uncore_ prefix. Also move them to uncore.h Signed-off-by:
-
Lucas De Marchi authored
Now that pll_id is not used anymore for combophy, reduce its scope. Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190322223751.22089-6-lucas.demarchi@intel.comReviewed-by:
-
Lucas De Marchi authored
By the time icl_ddi_clock_get() is called we've just got the hw state from the pll registers. We don't need to read them again: we can rather reuse what was cached in the dpll_hw_state. While at it, s/refclk/ref_clock/ just to be consistent with the name used in code nearby. Signed-off-by:
-
