- 27 Sep, 2018 23 commits
-
-
Alex Deucher authored
So we can query what features are enabled for debugging. Reviewed-by:
Rex Zhu <Rex.Zhu@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Alex Deucher authored
For getting the 64 bit enabled smc feature mask from vega parts. Reviewed-by:
-
Alex Deucher authored
For consistency with other asics. Reviewed-by:
-
Alex Deucher authored
For consistency with other asics. Reviewed-by:
-
Alex Deucher authored
to vega10_smumgr.c. For consistency with other vega parts. Reviewed-by:
-
Alex Deucher authored
For consistency with other vega parts. Reviewed-by:
-
Nicholas Kazlauskas authored
[Why] The DISPCLK value was previously requested to be 15% higher for all ASICs that went through the dce110 bandwidth code path. As part of a refactoring of dce_clocks and the dce110 set bandwidth codepath this was removed for power saving considerations. That change caused display corruption under certain hardware configurations with Vega10. [How] The 15% DISPCLK increase is brought back but only on dce110 for now. This is should be a temporary workaround until the root cause is sorted out for why this occurs on Vega (or other ASICs, if reported). Tested-by:
Nick Sarnie <sarnex@gentoo.org> Signed-off-by:
Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by:
Harry Wentland <Harry.Wentland@amd.com> Acked-by:
Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by:
-
SivapiriyanKumarasamy authored
[WHY] Previously night light forced a full update by applying a transfer function update regardless of if it was changed. This logic was removed, Now gamma surface updates are only applied when there is also a plane info update, this does not work in cases such as using the night light slider. [HOW] When moving the night light slider we will perform a full update if the gamma has changed and there is a surface, even when the surface has not changed. Also get stream updates in setgamma prior to update planes and stream. Signed-off-by:
SivapiriyanKumarasamy <sivapiriyan.kumarasamy@amd.com> Reviewed-by:
Anthony Koo <Anthony.Koo@amd.com> Acked-by:
-
Leo Li authored
[Why] The work struct's schedule call was removed a while ago, making this useless. [How] Remove it. Signed-off-by:
Leo Li <sunpeng.li@amd.com> Reviewed-by:
David Francis <David.Francis@amd.com> Acked-by:
-
Nicholas Kazlauskas authored
[Why] During suspend under some hardware configurations can result in a series of atomic commits with a NULL stream status - which causes a NULL pointer dereference. This should be guarded. [How] Exit early from the function - if we can't access the stream then there isn't anything that can be done here. Signed-off-by:
-
Eric Bernstein authored
[Why] Need to add strere 3D information in VSC [How] Update mod_build_vsc_infopacket with stereo info Signed-off-by:
Eric Bernstein <eric.bernstein@amd.com> Reviewed-by:
Charlene Liu <Charlene.Liu@amd.com> Acked-by:
-
Tony Cheng authored
Signed-off-by:
Tony Cheng <tony.cheng@amd.com> Reviewed-by:
Steven Chiu <Steven.Chiu@amd.com> Acked-by:
-
Su Sung Chung authored
[WHY] There are two different variables used to calculate v_update and v_ready, one for validation and the other for performance parameter calculation. Before the variable for validation was used which caused underflow on 1080edp with vsr enabled [HOW] program v_update and v_ready with the variables for performance parameter calculation Signed-off-by:
Su Sung Chung <su.chung@amd.com> Reviewed-by:
Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> Acked-by:
-
SivapiriyanKumarasamy authored
Parse the native color bit and send it to freesync module for future use Signed-off-by:
-
Charlene Liu authored
add pp_smu NULL ptr check Signed-off-by:
-
Samson Tam authored
Use link->link_index as index to pipe_ctx[] to get proper link information instead of using index 0 to avoid potential miss matches. Signed-off-by:
Samson Tam <Samson.Tam@amd.com> Reviewed-by:
-
Nikola Cornij authored
FPGA doesn't program backend, so we don't need certain link settings (audio stream for example). Signed-off-by:
Nikola Cornij <nikola.cornij@amd.com> Reviewed-by:
-
Rex Zhu authored
this can avoid hard hang and be useful for debug. Reviewed-by:
-
Rex Zhu authored
Honour display's request for min engine clock/memory clock. Reviewed-by:
-
Rex Zhu authored
Revert "drm/amd/display: Remove call to amdgpu_pm_compute_clocks" This reverts commit dcd473770e86517543691bdb227103d6c781cd0a. when display configuration changes, dc need to update the changes to powerplay, also need to trigger a power state task. amdgpu_pm_compute_clocks is the interface to set power state task either dpm enabled or powerplay enabled Acked-by:
-
Dave Airlie authored
Sean Paul requested an -rc5 backmerge from some sun4i fixes. Signed-off-by:Dave Airlie <airlied@redhat.com>
-
Dave Airlie authored
- A crash fix founded in recent linux-next from John Garry - One sparse warning fix from Souptick Joarder - Some xxx_unref cleanup from Thomas Zimmermann Signed-off-by:
-
git://linuxtv.org/pinchartl/mediaDave Airlie authored
R-Car DU support for the D3 and E3 SoCs (v4.20) Signed-off-by:
-
- 26 Sep, 2018 6 commits
-
-
Thomas Zimmermann authored
The function ttm_bo_put releases a reference to a TTM buffer object. The function's name is more aligned to the Linux kernel convention of naming ref-counting function _get and _put. A call to ttm_bo_unref takes the address of the TTM BO object's pointer and clears the pointer's value to NULL. This is not necessary in most cases and sometimes even worked around by the calling code. A call to ttm_bo_put only releases the reference without clearing the pointer. The current behaviour of cleaning the pointer is kept in the calling code, but should be removed if not required in a later patch. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
Xinliang Liu <z.liuxinliang@hisilicon.com> Signed-off-by:
-
Thomas Zimmermann authored
This patch unifies the naming of DRM functions for reference counting of struct drm_device. The resulting code is more aligned with the rest of the Linux kernel interfaces. Signed-off-by:
-
Souptick Joarder authored
convert drm_atomic_helper_suspend/resume() to use drm_mode_config_helper_suspend/resume(). Fixed one sparse warning by making hibmc_drm_interrupt static. Signed-off-by:
Ajit Negi <ajitn.linux@gmail.com> Signed-off-by:
Souptick Joarder <jrdr.linux@gmail.com> Reviewed-by:
-
John Garry authored
Switch to use Huawei PCI vendor ID macro from pci_ids.h file. In addition, switch to use PCI_VDEVICE() instead of open coding. Signed-off-by:
John Garry <john.garry@huawei.com> Reviewed-by:
-
John Garry authored
Currently the driver overwrites the surface depth provided by the fb helper to give an invalid bpp/surface depth combination. This has been exposed by commit 70109354 ("drm: Reject unknown legacy bpp and depth for drm_mode_addfb ioctl"), which now causes the driver to fail to probe. Fix by not overwriting the surface depth. Fixes: d1667b86 ("drm/hisilicon/hibmc: Add support for frame buffer") Signed-off-by:
-
John Garry authored
In hibmc_drm_fb_create(), when the call to hibmc_framebuffer_init() fails with error, do not store the error code in the HiBMC device frame-buffer pointer, as this will be later checked for non-zero value in hibmc_fbdev_destroy() when our intention is to check for a valid function pointer. This fixes the following crash: [ 9.699791] Unable to handle kernel NULL pointer dereference at virtual address 000000000000001a [ 9.708672] Mem abort info: [ 9.711489] ESR = 0x96000004 [ 9.714570] Exception class = DABT (current EL), IL = 32 bits [ 9.720551] SET = 0, FnV = 0 [ 9.723631] EA = 0, S1PTW = 0 [ 9.726799] Data abort info: [ 9.729702] ISV = 0, ISS = 0x00000004 [ 9.733573] CM = 0, WnR = 0 [ 9.736566] [000000000000001a] user address but active_mm is swapper [ 9.742987] Internal error: Oops: 96000004 [#1] PREEMPT SMP [ 9.748614] Modules linked in: [ 9.751694] CPU: 16 PID: 293 Comm: kworker/16:1 Tainted: G W 4.19.0-rc4-next-20180920-00001-g9b0012c #322 [ 9.762681] Hardware name: Huawei Taishan 2280 /D05, BIOS Hisilicon D05 IT21 Nemo 2.0 RC0 04/18/2018 [ 9.771915] Workqueue: events work_for_cpu_fn [ 9.776312] pstate: 60000005 (nZCv daif -PAN -UAO) [ 9.781150] pc : drm_mode_object_put+0x0/0x20 [ 9.785547] lr : hibmc_fbdev_fini+0x40/0x58 [ 9.789767] sp : ffff00000af1bcf0 [ 9.793108] x29: ffff00000af1bcf0 x28: 0000000000000000 [ 9.798473] x27: 0000000000000000 x26: ffff000008f66630 [ 9.803838] x25: 0000000000000000 x24: ffff0000095abb98 [ 9.809203] x23: ffff8017db92fe00 x22: ffff8017d2b13000 [ 9.814568] x21: ffffffffffffffea x20: ffff8017d2f80018 [ 9.819933] x19: ffff8017d28a0018 x18: ffffffffffffffff [ 9.825297] x17: 0000000000000000 x16: 0000000000000000 [ 9.830662] x15: ffff0000092296c8 x14: ffff00008939970f [ 9.836026] x13: ffff00000939971d x12: ffff000009229940 [ 9.841391] x11: ffff0000085f8fc0 x10: ffff00000af1b9a0 [ 9.846756] x9 : 000000000000000d x8 : 6620657a696c6169 [ 9.852121] x7 : ffff8017d3340580 x6 : ffff8017d4168000 [ 9.857486] x5 : 0000000000000000 x4 : ffff8017db92fb20 [ 9.862850] x3 : 0000000000002690 x2 : ffff8017d3340480 [ 9.868214] x1 : 0000000000000028 x0 : 0000000000000002 [ 9.873580] Process kworker/16:1 (pid: 293, stack limit = 0x(____ptrval____)) [ 9.880788] Call trace: [ 9.883252] drm_mode_object_put+0x0/0x20 [ 9.887297] hibmc_unload+0x1c/0x80 [ 9.890815] hibmc_pci_probe+0x170/0x3c8 [ 9.894773] local_pci_probe+0x3c/0xb0 [ 9.898555] work_for_cpu_fn+0x18/0x28 [ 9.902337] process_one_work+0x1e0/0x318 [ 9.906382] worker_thread+0x228/0x450 [ 9.910164] kthread+0x128/0x130 [ 9.913418] ret_from_fork+0x10/0x18 [ 9.917024] Code: a94153f3 a8c27bfd d65f03c0 d503201f (f9400c01) [ 9.923180] ---[ end trace 2695ffa0af5be375 ]--- Fixes: d1667b86 ("drm/hisilicon/hibmc: Add support for frame buffer") Signed-off-by:
-
- 24 Sep, 2018 11 commits
-
-
Ulrich Hecht authored
Add support for the R-Car D3 (R8A77995) and E3 (R8A77990) SoCs to the R-Car DU driver. The two SoCs instantiate compatible DUs, so a single information structure is enough. Signed-off-by:
Ulrich Hecht <uli+renesas@fpond.eu> [Add support for R8A77990] 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
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 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:
-
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:
-
