- 24 Sep, 2018 10 commits
-
-
Laurent Pinchart authored
The official way to stop the display is to clear the display enable (DEN) bit in the DSYSR register, but that operates at a group level and affects the two channels in the group. To disable channels selectively, the driver uses TV sync mode that stops display operation on the channel and turns output signals into inputs. While TV sync mode is available in all DU models currently supported, the D3 and E3 DUs don't support it. We will thus need to find an alternative way to turn channels off. In the meantime, condition the switch to TV sync mode to the availability of the feature, to avoid writing an invalid value to the DSYSR register. When the feature is unavailable the display output will turn blank as all planes are disabled when stopping the CRTC. Signed-off-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Tested-by:
Jacopo Mondi <jacopo+renesas@jmondi.org> Reviewed-by:
Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
-
Laurent Pinchart authored
DSYSR is a DU channel register that also contains group fields. It is thus written to by both the group and CRTC code, using read-update-write sequences. As the register isn't initialized explicitly at startup time, this can lead to invalid or otherwise unexpected values being written to some of the fields if they have been modified by the firmware or just not reset properly. To fix this we can write a fully known value to the DSYSR register when turning a channel's functional clock on. However, the mix of group and channel fields complicate this. A simpler solution is to cache the register and initialize the cached value to the desired hardware defaults. Signed-off-by:
-
Laurent Pinchart authored
All Gen3 SoCs supported so far have a fixed association between DPAD0 and DU channels, which led to hardcoding that association when writing the corresponding hardware register. The D3 and E3 will break that mechanism as DPAD0 can be dynamically connected to either DU0 or DU1. Make DPAD0 routing dynamic on Gen3. To ensure a valid hardware configuration when the DU starts without the RGB output enabled, DPAD0 is associated at initialization time to the first DU channel that it can be connected to. This makes no change on Gen2 as all Gen2 SoCs can connected DPAD0 to DU0, which is the current implicit default value. As the DPAD0 source is always 0 when a single source is possible on Gen2, we can also simplify the Gen2 code in the same function to remove a conditional check. Signed-off-by:
-
Laurent Pinchart authored
On selected SoCs, the DU can use the clock output by the LVDS encoder PLL as its input dot clock. This feature is optional, but on the D3 and E3 SoC it is often the only way to obtain a precise dot clock frequency, as the other available clocks (CPG-generated clock and external clock) usually have fixed rates. Add a DU model information field to describe which DU channels can use the LVDS PLL output clock as their input clock, and configure clock routing accordingly. This feature is available on H2, M2-W, M2-N, D3 and E3 SoCs, with D3 and E3 being the primary targets. It is left disabled in this commit, and will be enabled per-SoC after careful testing. At the hardware level, clock routing is configured at runtime in two steps, first selecting an internal dot clock between the LVDS PLL clock and the external DOTCLKIN clock, and then selecting between the internal dot clock and the CPG-generated clock. The first part requires stopping the whole DU group in order for the change to take effect, thus causing flickering on the screen. For this reason we currently hardcode the clock source to the LVDS PLL clock if available, and allow flicker-free selection of the external DOTCLKIN clock or CPG-generated clock otherwise. A more dynamic clock selection process can be implemented later if the need arises. Signed-off-by:
-
Laurent Pinchart authored
The rcar_du_crtc_get() function is always immediately followed by a call to rcar_du_crtc_setup(). Call the later from the former to simplify the code, and add a comment to explain how the get and put calls are balanced. Signed-off-by:
-
Laurent Pinchart authored
The LVDS encoders in the D3 and E3 SoCs differ significantly from those in the other R-Car Gen3 family members: - The LVDS PLL architecture is more complex and requires computing PLL parameters manually. - The PLL uses external clocks as inputs, which need to be retrieved from DT. - In addition to the different PLL setup, the startup sequence has changed *again* (seems someone had trouble making his/her mind). Supporting all this requires DT bindings extensions for external clocks, brand new PLL setup code, and a few quirks to handle the differences in the startup sequence. The implementation doesn't support all hardware features yet, namely - Using the LV[01] clocks generated by the CPG as PLL input. - Providing the LVDS PLL clock to the DU for use with the RGB output. Those features can be added later when the need will arise. Signed-off-by:
Ulrich Hecht <uli+renesas@fpond.eu> Reviewed-by:
-
Laurent Pinchart authored
The THC63LVD1024 is restricted to a pixel clock frequency in the range of 8 to 135 MHz. Implement the bridge .mode_valid() operation accordingly. Signed-off-by:
Andrzej Hajda <a.hajda@samsung.com> Tested-by:
-
Laurent Pinchart authored
On the D3 and E3 SoCs, the LVDS encoder can derive its internal pixel clock from an externally supplied clock, either through the EXTAL pin or through one of the DU_DOTCLKINx pins. Add corresponding clocks to the DT bindings. To retain backward compatibility with DT that don't specify the clock-names property, the functional clock must always be specified first, and the clock-names property is optional when only the functional clock is specified. Signed-off-by:
-
Laurent Pinchart authored
The E3 (r8a77990) supports two LVDS channels. Extend the binding to support them. Signed-off-by:
Rob Herring <robh@kernel.org> Reviewed-by:
-
Laurent Pinchart authored
Document the E3 (r8a77990) SoC in the R-Car DU bindings. Signed-off-by:
-
- 20 Sep, 2018 5 commits
-
-
git://people.freedesktop.org/~agd5f/linuxDave Airlie authored
This is a new pull for drm-next on top of last weeks with the following changes: - Fixed 64 bit divide - Fixed vram type on vega20 - Misc vega20 fixes - Misc DC fixes - Fix GDS/GWS/OA domain handling Previous changes from last week: amdgpu/kfd: - Picasso (new APU) support - Raven2 (new APU) support - Vega20 enablement - ACP powergating improvements - Add ABGR/XBGR display support - VCN JPEG engine support - Initial xGMI support - Use load balancing for engine scheduling - Lots of new documentation - Rework and clean up i2c and aux handling in DC - Add DP YCbCr 4:2:0 support in DC - Add DMCU firmware loading for Raven (used for ABM and PSR) - New debugfs features in DC - LVDS support in DC - Implement wave kill for gfx/compute (light weight reset for shaders) - Use AGP aperture to avoid gart mappings when possible - GPUVM performance improvements - Bulk moves for more efficient GPUVM LRU handling - Merge amdgpu and amdkfd into one module - Enable gfxoff and stutter mode on Raven - Misc cleanups Scheduler: - Load balancing support - Bug fixes ttm: - Bulk move functionality - Bug fixes radeon: - Misc cleanups Signed-off-by:
Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexdeucher@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180920150438.12693-1-alexander.deucher@amd.com
-
git://linuxtv.org/pinchartl/mediaDave Airlie authored
R-Car DU changes for v4.20 The pull request mostly contains updates to the R-Car DU driver, notably support for interlaced modes on Gen3 hardware, support for the LVDS output on R8A77980, and a set of miscellaneous bug fixes. There are also two SPDX conversion patches for the drm shmobile and panel-lvds drivers, as well as an update to MAINTAINERS to add Kieran Bingham as a co-maintainer for the DU driver. Signed-off-by:
-
Frank Min authored
Temporary disable UVD/VCE block if is virtual device Signed-off-by:
Frank Min <Frank.Min@amd.com> Signed-off-by:
Xiangliang Yu <Xiangliang.Yu@amd.com> Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Frank Min authored
Add sriov capability detection for vega20, then can check if device is virtual device. Signed-off-by:
-
git://anongit.freedesktop.org/drm/drm-miscDave Airlie authored
drm-misc-next for 4.20: UAPI Changes: - None Cross-subsystem Changes: - None Core Changes: - Allow drivers to disable features with per-device granularity (Ville) - Use EOPNOTSUPP when iface/feature is unsupported instead of EINVAL/errno soup (Chris) - Simplify M/N DP quirk by using constant N to limit size of M/N (Shawn) - add quirk for LG LP140WF6-SPM1 eDP panel (Shawn) Driver Changes: - i915/amdgpu: Disable DRIVER_ATOMIC for older/unsupported devices (Ville) - sun4i: add support for R40 HDMI PHY (Icenowy) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Icenowy Zheng <icenowy@aosc.io> Cc: Lee, Shawn C <shawn.c.lee@intel.com> Signed-off-by:
-
- 19 Sep, 2018 25 commits
-
-
Christian König authored
We don't need that in the per ASIC code. Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
-
Christian König authored
Stops crashing on SI. Signed-off-by:
-
Christian König authored
That only worked by pure coincident. Completely remove the shifting and always apply correct PAGE_SHIFT. Signed-off-by:
-
Christian König authored
Don't grab the reservation lock any more and simplify the handling quite a bit. Signed-off-by:
Huang Rui <ray.huang@amd.com> Signed-off-by:
-
Christian König authored
It shouldn't add much overhead and we should make sure that critical VRAM content is always restored. Signed-off-by:
Junwei Zhang <Jerry.Zhang@amd.com> Signed-off-by:
-
Christian König authored
They aren't directly used by the hardware. Signed-off-by:
-
Christian König authored
Even when GPU recovery is disabled we could run into a manually triggered recovery. v2: keep accidental removed comments Signed-off-by:
Emily Deng <Emily.Deng@amd.com> Signed-off-by:
-
Christian König authored
We are going to need this for recoverable page fault handling and it makes shadow handling during GPU reset much more easier. Signed-off-by:
-
Christian König authored
DC doesn't seem to have a fallback path either. So when interrupts doesn't work any more we are pretty much busted no matter what. Signed-off-by:
Chunming Zhou <david1.zhou@amd.com> Signed-off-by:
-
Evan Quan authored
With OD settings applied, the clock table will be updated accordingly. We need to retrieve the new clock tables then. Signed-off-by:
Evan Quan <evan.quan@amd.com> Acked-by:
-
Evan Quan authored
With the latest SMC fw, we are able to get the voltage value for specific frequency point. So, we update the OD relates to take absolute voltage instead of offset. Signed-off-by:
-
Evan Quan authored
Update the conditions to judge whether an OD feature should be supported on vega20. Signed-off-by:
-
Hawking Zhang authored
vega20 should use umc_info v3_3 instead of v3_1. There are serveral versions of umc_info for vega series. Compared to various versions of these structures, vram_info strucure is unified for vega series. The patch switch to query mem_type from vram_info structure for all the vega series dGPU. Signed-off-by:
Hawking Zhang <Hawking.Zhang@amd.com> Reviewed-by:
-
Hawking Zhang authored
atomfirmware has structure changes in varm_info. Updated it to the latest one. Signed-off-by:
-
Mathieu Malaterre authored
In function ‘radeon_process_i2c_ch’ a comparison of a u8 value against 255 is done. Since it is always false, change the signature of this function to use an `int` instead, which match the type used in caller: `radeon_atom_hw_i2c_xfer`. Fix the following warning triggered with W=1: CC [M] drivers/gpu/drm/radeon/atombios_i2c.o drivers/gpu/drm/radeon/atombios_i2c.c: In function ‘radeon_process_i2c_ch’: drivers/gpu/drm/radeon/atombios_i2c.c:71:11: warning: comparison is always false due to limited range of data type [-Wtype-limits] if (num > ATOM_MAX_HW_I2C_READ) { ^ Reviewed-by:Mathieu Malaterre <malat@debian.org> Signed-off-by:
-
A. Wilcox authored
adev->gfx.rlc has the values from rlc_hdr already processed by le32_to_cpu. Using the rlc_hdr values on big-endian machines causes a kernel Oops due to writing well outside of the array (0x24000000 instead of 0x24). Signed-off-by:
A. Wilcox <AWilcox@Wilcox-Tech.com> Signed-off-by:
-
Tom St Denis authored
Signed-off-by:
Tom St Denis <tom.stdenis@amd.com> Reviewed-by:
-
Christian König authored
We no don't allocate zero sized kernel BOs any longer. Signed-off-by:
-
Christian König authored
Just free the BO if the size should be zero. Signed-off-by:
-
Christian König authored
Simply ignore any copying here. Signed-off-by:
-
Christian König authored
Additional to the existing files for VRAM and GTT. Signed-off-by:
-
Christian König authored
The function was modified without updating the documentation. Signed-off-by:
-
Christian König authored
We can't get the mask for the root directory from the number of entries. So add a new function to avoid that problem. v2: fix typo in mask Signed-off-by:
-
Lee, Shawn C authored
The N value was computed by kernel driver that based on synchronous clock mode. But only specific N value (0x8000) would be acceptable for LG LP140WF6-SPM1 eDP panel which is running at asynchronous clock mode. With the other N value, Tcon will enter BITS mode and display black screen. Add this panel into quirk database and give particular N value when calculate M/N divider. v2: no update v3: add lost commit messages back for version 2 v4: send patch to both intel-gfx and dri-devel Cc: Jani Nikula <jani.nikula@intel.com> Cc: Cooper Chiou <cooper.chiou@intel.com> Cc: Matt Atwood <matthew.s.atwood@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Clint Taylor <clinton.a.taylor@intel.com> Signed-off-by:
Lee, Shawn C <shawn.c.lee@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1536733371-25004-4-git-send-email-shawn.c.lee@intel.com
-
Lee, Shawn C authored
Some DP dongles in particular seem to be fussy about too large link M/N values. Set specific value for N divider can resolve this issue per dongle vendor's comment. So configure N as constant value (0x8000) to instead of reduce M/N formula when specific DP dongle connected. v2: add more comments for issue description and fix typo. v3: add lost commit messages back for version 2 v4: send patch to both intel-gfx and dri-devel Cc: Jani Nikula <jani.nikula@intel.com> Cc: Cooper Chiou <cooper.chiou@intel.com> Cc: Matt Atwood <matthew.s.atwood@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Clint Taylor <clinton.a.taylor@intel.com> Tested-by:
Clint Taylor <clinton.a.taylor@intel.com> Signed-off-by:
-
