- 11 Jun, 2019 21 commits
-
-
Nicholas Kazlauskas authored
[Why] The old logic for checking which output depth to use relied on using the current connector state rather than the new proposed state. This was a problem when performing atomic commits since we weren't verifying it against the incoming max_requested_bpc. But switching this to only use the new state and not the current state breaks filtering modes - it'll always assume that the maximum bpc supported by the display is in use, which will cause certain modes like 1440p@144Hz to be filtered even when using 8bpc. [How] Still use the connector->state if we aren't passed an explicit state. This will respect the max_bpc the user currently has when filtering modes. Also remember to reset the default max_requested_bpc to 8 whenever connector reset is called to retain old behavior when using the new property. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110845Signed-off-by:
Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Acked-by:
Alex Deucher <alexander.deucher@amd.com> Reviewed-by:
Harry Wentland <harry.wentland@amd.com> Signed-off-by:
-
Tom St Denis authored
This option is no longer needed. The default code paths are now the only option. v2: Add HPAGE support and a default for non contiguous maps v3: Misread 512 pages as MiB ... Signed-off-by:
Tom St Denis <tom.stdenis@amd.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
Nicholas Kazlauskas authored
[Why] Unlike our regular connectors, MST connectors don't start off with an initial connector state. This causes a NULL pointer dereference to occur when attaching the bpc property since it tries to modify the connector state. We need an initial connector state on the connector to avoid the crash. [How] Use our reset helper to allocate an initial state and reset the values to their defaults. We were already doing this before, just not for MST connectors. Signed-off-by:
Leo Li <sunpeng.li@amd.com> Signed-off-by:
-
Nicholas Kazlauskas authored
[Why] This will be useful for verifying whether we enter the correct output color depth from IGT. [How] Locks the connector and associated CRTC if available and outputs the current and maximum output bpc values. Example: cat /sys/kernel/debug/dri/0/DP-1/output_bpc Current: 8 Maximum: 10 v2: Drop unneeded connector status check Signed-off-by:
David Francis <David.Francis@amd.com> Signed-off-by:
-
Prike Liang authored
Use SMU firmware version to indentify the raven1 refresh device and then load homologous RLC FW. Signed-off-by:
Prike Liang <Prike.Liang@amd.com> Suggested-by: Huang Rui<Ray.Huang@amd.com> Reviewed-by:
Huang Rui <ray.huang@amd.com> Reviewed-by:
Evan Quan <evan.quan@amd.com> Signed-off-by:
-
Chengming Gui authored
add gfxoff_state_changed_by_workload to control gfxoff when set power_profile_mode Signed-off-by:
Chengming Gui <Jack.Gui@amd.com> Reviewed-by:
-
Trigger Huang authored
Under Vega10 SR-IOV VF, L1 register access mode should be enabled by default as the non-security VF will no longer be supported. Signed-off-by:
Trigger Huang <Trigger.Huang@amd.com> Reviewed-by:
Emily Deng <Emily.Deng@amd.com> Signed-off-by:
-
Shirish S authored
[What] readptr read always returns zero, since most likely these blocks are either power or clock gated. [How] fetch rptr after amdgpu_ring_alloc() which informs the power management code that the block is about to be used and hence the gating is turned off. Signed-off-by:
Louis Li <Ching-shih.Li@amd.com> Signed-off-by:
Shirish S <shirish.s@amd.com> Reviewed-by:
-
Louis Li authored
[What] vce ring test fails consistently during resume in s3 cycle, due to mismatch read & write pointers. On debug/analysis its found that rptr to be compared is not being correctly updated/read, which leads to this failure. Below is the failure signature: [drm:amdgpu_vce_ring_test_ring] *ERROR* amdgpu: ring 12 test failed [drm:amdgpu_device_ip_resume_phase2] *ERROR* resume of IP block <vce_v3_0> failed -110 [drm:amdgpu_device_resume] *ERROR* amdgpu_device_ip_resume failed (-110). [How] fetch rptr appropriately, meaning move its read location further down in the code flow. With this patch applied the s3 failure is no more seen for >5k s3 cycles, which otherwise is pretty consistent. V2: remove reduntant fetch of rptr Signed-off-by:
-
Jay Cornwall authored
Ported from gfx8, no changes in register setup. Signed-off-by:
Jay Cornwall <Jay.Cornwall@amd.com> Reviewed-by:
Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by:
-
Oak Zeng authored
Translate queue priority into pipe priority and write to MQDs. The priority values are used to perform queue and pipe arbitration. Signed-off-by:
Oak Zeng <Oak.Zeng@amd.com> Reviewed-by:
-
Felix Kuehling authored
Always mark evicted queues with q->properties.is_evicted = true, even queues that are inactive for other reason. This simplifies maintaining the eviction state as it doesn't require updating is_evicted when other queue activation conditions change. On the other hand, we now need to check those other queue activation conditions whenever an evicted queues is restored. To minimize code duplication, move the queue activation check into a macro so it can be maintained in one central place. Signed-off-by:
Philip Cox <Philip.Cox@amd.com> Acked-by:
-
James Zhu authored
EDC counts are related to instance and se. They are not the same for different type of EDC. EDC clearing are changed to base on individual EDC's instance and SE number. Signed-off-by:
James Zhu <James.Zhu@amd.com> Reviewed-by:
-
Nicholas Kazlauskas authored
[Why] DCN_VERSION_1_01 is no longer handled in the dal_hw_translate_init switch since it was inadvertently dropped in the patch that removed the unnecessary DCN1_01 guards. This caused numerous regressions on DCN1_01 when loading the driver. [How] Add it back. Fixes: 97df424f ("drm/amd/display: Drop DCN1_01 guards") Signed-off-by:
-
Nicholas Kazlauskas authored
[Why] When switching from vt to desktop with EDID emulation we can receive an atomic commit such that we have a crtc where mode_changed = true. During the dm_update_crtc_state disable pass we remove the stream from the context and free it on the dm_new_crtc_state. During the enable pass we compare the new provisional stream to the dm_old_crtc_state->stream and determine that the stream is unchanged and no scaling has been changed. Following this, new_crtc_state->mode_changed is then set to false. The connectors haven't changed and the CRTC active state hasn't changed so drm_atomic_crtc_needs_modeset returns false, so we jump to skip_modeset and we hit: BUG_ON(dm_new_crtc_state->stream == NULL); ...since the old stream is gone from the context and the new stream is also still NULL. [How] Ensure that we still a stream to reuse before checking if we can reuse the old stream without a full modeset. Signed-off-by:
-
Christian König authored
This avoids OOM situations when we have lots of threads submitting at the same time. v3: apply this to the whole driver, not just CS Signed-off-by:
Chunming Zhou <david1.zhou@amd.com> Tested-by:
Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Signed-off-by:
-
Christian König authored
And only move them in on validation. This allows for better control when multiple processes are fighting over those resources. Signed-off-by:
-
Christian König authored
The messages about amdgpu_cs_list_validate are duplicated because the caller will complain into the logs as well and we can also get interrupted by a signal here. Also fix the the caller to not report -EAGAIN from validation. Signed-off-by:
-
Hawking Zhang authored
ras ta interface header need to be updated to match with latest ta fw updates Signed-off-by:
Hawking Zhang <Hawking.Zhang@amd.com> Reviewed-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linuxDaniel Vetter authored
omapdrm changes for 5.3 - Add support for DSI command mode displays Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> From: Tomi Valkeinen <tomi.valkeinen@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/a709f57d-6909-8550-3932-d84e0b5bc3ef@ti.com
-
git://linuxtv.org/pinchartl/mediaDaniel Vetter authored
R-Car DU changes for v5.3: - R8A774A1 SoC support - LVDS dual-link mode support - Support for additional formats - Misc fixes Signed-off-by:
-
- 10 Jun, 2019 7 commits
-
-
Sebastian Reichel authored
This adds the required infrastructure for manually updated displays, such as DSI command mode panels. While those panels often support partial updates we currently always do a full refresh. The display will be refreshed when something calls the dirty callback, such as libdrm's drmModeDirtyFB(). This is currently being done at least by the kernel console and Xorg (with modesetting driver) in their default configuration. Weston does not implement this and the fbdev backend does not work (display will not update). Weston's DRM backend uses double buffering and the page flip will also trigger a display refresh. Signed-off-by:
Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Sebastian Reichel authored
This prepares framedone interrupt handling for manual display update support. Acked-by:
Pavel Machek <pavel@ucw.cz> Tested-by:
Tony Lindgren <tony@atomide.com> Tested-by:
-
Sebastian Reichel authored
While most display types only forward their VM to the DISPC, this is not true for DSI. DSI calculates the VM for DISPC based on its own, but it's not identical. Actually the DSI VM is not even a valid DISPC VM making this check fail. Let's restore the old behaviour and avoid checking the DISPC VM for DSI here. Fixes: 7c27fa57 ("drm/omap: Call dispc timings check operation directly") Acked-by:
-
Sebastian Reichel authored
This macro is only used by omapdrm, which should print debug messages using the DRIVER category instead of the default CORE category. Acked-by:
-
Kefeng Wang authored
Using dev_get_drvdata directly. Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Signed-off-by:
Kefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by:
-
Emil Velikov authored
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by:
Emil Velikov <emil.velikov@collabora.com> Signed-off-by:
-
Thomas Meyer authored
Make sure (of/i2c/platform)_device_id tables are NULL terminated. Signed-off-by:
Thomas Meyer <thomas@m3y3r.de> Signed-off-by:
-
- 08 Jun, 2019 3 commits
-
-
Laurent Pinchart authored
Add support for the DRM_FORMAT_RGBA5551, DRM_FORMAT_RGBX5551, DRM_FORMAT_ABGR1555, DRM_FORMAT_XBGR1555, DRM_FORMAT_BGRA5551 and DRM_FORMAT_BGRX5551 formats to the DU driver. Those formats are only available on Gen3. Signed-off-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Acked-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by:
Jacopo Mondi <jacopo@jmondi.org> Acked-by:
Daniel Vetter <daniel@ffwll.ch>
-
Laurent Pinchart authored
Add support for the DRM_FORMAT_RGBA4444, DRM_FORMAT_RGBX4444, DRM_FORMAT_ABGR4444, DRM_FORMAT_XBGR4444, DRM_FORMAT_BGRA4444 and DRM_FORMAT_BGRX4444 formats to the DU driver. Those formats are only available on Gen3. Signed-off-by:
-
Laurent Pinchart authored
Add support for the DRM_FORMAT_RGBA8888, DRM_FORMAT_RGBX8888, DRM_FORMAT_ABGR8888 and DRM_FORMAT_XBGR8888 formats to the DU driver. Those formats are only available on Gen3. Signed-off-by:
-
- 07 Jun, 2019 9 commits
-
-
Laurent Pinchart authored
In dual-link LVDS mode, the LVDS1 encoder is used as a companion for LVDS0, and both encoders transmit data from DU0. The LVDS1 output of DU1 can't be used in that case, don't create an encoder and connector for it. Signed-off-by:
Jacopo Mondi <jacopo+renesas@jmondi.org> Tested-by:
Sam Ravnborg <sam@ravnborg.org> Reviewed-by:
Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
-
Laurent Pinchart authored
In dual-link mode the LVDS0 encoder transmits even-numbered pixels, and sends odd-numbered pixels to the LVDS1 encoder for transmission on a separate link. To implement support for this mode of operation, determine if the LVDS connection operates in dual-link mode by querying the next device in the pipeline, locate the companion encoder, and control it directly through its bridge operations. Signed-off-by:
-
Laurent Pinchart authored
The DRM core and DU driver guarantee that the LVDS bridge will not be double-enabled or double-disabled. Remove the corresponding unnecessary checks. Signed-off-by:
-
Laurent Pinchart authored
Add a new optional renesas,companion property to point to the companion LVDS encoder. This is used to support dual-link operation where the main LVDS encoder splits even-numbered and odd-numbered pixels between the two LVDS encoders. The new property doesn't control the mode of operation, it only describes the relationship between the master and companion LVDS encoders. Signed-off-by:
-
Laurent Pinchart authored
Set a drm_bridge_timings in the drm_bridge, and use it to report the input bus mode (single-link or dual-link). The other fields of the timings structure are kept to 0 as they do not apply to LVDS buses. Signed-off-by:
-
Laurent Pinchart authored
The THC63LVD1024 LVDS decoder can operate in two modes, single-link or dual-link. In dual-link mode both input ports are used to carry even- and odd-numbered pixels separately. Document this in the DT bindings, along with the related rules governing port and usage. Signed-off-by:
Rob Herring <robh@kernel.org> Tested-by:
-
Laurent Pinchart authored
Extend the drm_bridge_timings structure with a new dual_link field to indicate that the bridge's input bus carries data on two separate physical links. The first use case is LVDS dual-link mode where even- and odd-numbered pixels are transferred on separate LVDS links. Signed-off-by:
-
Kieran Bingham authored
The new writeback feature exports functions so that they can integrate into the rcar_du_kms module. The interface functions are defined in the rcar_du_writeback header, but it is not included in the object file itself leading to compiler warnings for missing prototypes. Include the header as appropriate. Signed-off-by:
-
Biju Das authored
The LVDS encoders on RZ/G2M SoC is similar to R-Car M3-W. Add support for RZ/G2M (R8A774A1) SoC to the LVDS encoder driver. Signed-off-by:
Biju Das <biju.das@bp.renesas.com> Reviewed-by:
-
