- 10 7月, 2018 1 次提交
-
-
由 Ville Syrjälä 提交于
Just like with PIPESTAT, the edge triggered IIR on i965/g4x also causes problems for hotplug interrupts. To make sure we don't get the IIR port interrupt bit stuck low with the ISR bit high we must force an edge in ISR. Unfortunately we can't borrow the PIPESTAT trick and toggle the enable bits in PORT_HOTPLUG_EN as that act itself generates hotplug interrupts. Instead we just have to loop until we've cleared PORT_HOTPLUG_STAT, or we just give up and WARN. v2: Don't frob with PORT_HOTPLUG_EN Cc: stable@vger.kernel.org Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180614175625.1615-1-ville.syrjala@linux.intel.comReviewed-by: NImre Deak <imre.deak@intel.com> (cherry picked from commit 0ba7c51a) Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
-
- 05 7月, 2018 4 次提交
-
-
由 Mikita Lipski 提交于
[why] HDMI 2.0 fails to validate 4K@60 timing with 10 bpc [how] Adding a helper function that would verify if the display depth assigned would pass a bandwidth validation. Drop the display depth by one level till calculated pixel clk is lower than maximum TMDS clk. Bugzilla: https://bugs.freedesktop.org/106959Tested-by: NMike Lothian <mike@fireburn.co.uk> Reviewed-by: NHarry Wentland <harry.wentland@amd.com> Signed-off-by: NMikita Lipski <mikita.lipski@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Mikita Lipski 提交于
[why] HDMI EDID's VSDB contains spectial timings for specifically YCbCr 4:2:0 colour space. In those cases we need to verify if the mode provided is one of the special ones has to use YCbCr 4:2:0 pixel encoding for display info. [how] Verify if the mode is using specific ycbcr420 colour space with the help of DRM helper function and assign the mode to use ycbcr420 pixel encoding. Tested-by: NMike Lothian <mike@fireburn.co.uk> Reviewed-by: NHarry Wentland <harry.wentland@amd.com> Signed-off-by: NMikita Lipski <mikita.lipski@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Hang Yuan 提交于
Commit cd7e 61b9"init mmio by lri command in vgpu inhibit context" initializes registers saved/restored in context with its vreg value through lri command in ring buffer. It relies on vreg got updated on every guest access. There is a case found that Linux guest uses lri command in inhibit-ctx to update the register. This patch adds vreg update on this case. v2: move mmio_attribute functions to gvt.h (Zhenyu) v3: use mask_mmio_write in vreg update v4: refine codes and add more comments (Zhenyu) Fixes: cd7e61b9("drm/i915/gvt: init mmio by lri command in vgpu inhibit context") Signed-off-by: NHang Yuan <hang.yuan@linux.intel.com> Signed-off-by: NWeinan Li <weinan.z.li@intel.com> Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
-
由 Mikulas Patocka 提交于
The displaylink hardware has such a peculiarity that it doesn't render a command until next command is received. This produces occasional corruption, such as when setting 22x11 font on the console, only the first line of the cursor will be blinking if the cursor is located at some specific columns. When we end up with a repeating pixel, the driver has a bug that it leaves one uninitialized byte after the command (and this byte is enough to flush the command and render it - thus it fixes the screen corruption), however whe we end up with a non-repeating pixel, there is no byte appended and this results in temporary screen corruption. This patch fixes the screen corruption by always appending a byte 0xAF at the end of URB. It also removes the uninitialized byte. Signed-off-by: NMikulas Patocka <mpatocka@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 04 7月, 2018 4 次提交
-
-
由 Maciej Purski 提交于
Current link mode values do not allow to enable packed pixel modes. Select packed pixel clock mode, if needed, every time the link mode register gets updated. Signed-off-by: NMaciej Purski <m.purski@samsung.com> Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/1530204243-6370-4-git-send-email-m.purski@samsung.com
-
由 Maciej Purski 提交于
Current implementation does not guarantee packed pixel modes working with every dongle. There are some dongles, which require selecting the output mode explicitly. Write proper values to registers in packed_pixel mode, based on how it is done in vendor's code. Select output color space: RGB (no packed pixel) or YCBCR422 (packed pixel). This reverts commit e8b92efa ("drm/bridge/sii8620: fix display of packed pixel modes in MHL2"). Signed-off-by: NMaciej Purski <m.purski@samsung.com> Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/1530204243-6370-3-git-send-email-m.purski@samsung.com
-
由 Maciej Purski 提交于
Currently AVI infoframe is sent only in MHL3. However, some MHL2 dongles need AVI infoframe to work correctly in either packed pixel mode or non-packed pixel mode. Send AVI infoframe in set_infoframes() in every case. Create an infoframe using drm_hdmi_infoframe_from_display_mode() instead of manually filling each infoframe structure's field. Signed-off-by: NMaciej Purski <m.purski@samsung.com> Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/1530204243-6370-2-git-send-email-m.purski@samsung.com
-
由 Nicolai Hähnle 提交于
The buffer object backing the user fence is reserved using the non-user fence, i.e., as soon as the non-user fence is signaled, the user fence buffer object can be moved or even destroyed. Therefore, emit the user fence first. Both fences have the same cache invalidation behavior, so this should have no user-visible effect. Signed-off-by: NNicolai Hähnle <nicolai.haehnle@amd.com> Reviewed-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
- 03 7月, 2018 4 次提交
-
-
由 Chris Wilson 提交于
If the whole object is already pinned by HW for use as scanout, we will fail to move it to the mappable region and so must resort to using a partial VMA covering the whole object. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104513 Fixes: aa136d9d ("drm/i915: Convert partial ggtt vma to full ggtt if it spans the entire object") Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Matthew Auld <matthew.william.auld@gmail.com> Reviewed-by: NMatthew Auld <matthew.william.auld@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180630090509.469-1-chris@chris-wilson.co.uk (cherry picked from commit 7e7367d3) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Alex Deucher 提交于
new_active_crtcs is a bitmask, new_active_crtc_count is the actual count. Reviewed-by: NRex Zhu <Rex.Zhu@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Alex Deucher 提交于
The phys and vm versions had the values swapped. Reviewed-by: NJunwei Zhang <Jerry.Zhang@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Michel Dänzer 提交于
The property size may be controlled by userspace, can be large (I've seen failure with order 4, i.e. 16 pages / 64 KB) and doesn't need to be physically contiguous. Signed-off-by: NMichel Dänzer <michel.daenzer@amd.com> Reviewed-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180629142710.2069-1-michel@daenzer.net Cc: stable@vger.kernel.org
-
- 02 7月, 2018 5 次提交
-
-
由 Xiaolin Zhang 提交于
changed gvt display transcode DDI mode from DP_SST to DVI to address below calltrace issue during guest booting up which is caused by zero dotclock initial value with DP_SST mode. transcode DVI mode emulation also align with native with DP connection. [drm:drm_calc_timestamping_constants] ERROR crtc 41: Can't calculate constants, dotclock = 0! WARNING: at drivers/gpu/drm/drm_vblank.c:620 drm_calc_vbltimestamp_from_scanoutpos Call Trace: ? drm_calc_timestamping_constants+0x144/0x150 [drm] drm_get_last_vbltimestamp+0x54/0x90 [drm] drm_reset_vblank_timestamp+0x59/0xd0 [drm] drm_crtc_vblank_on+0x7b/0xd0 [drm] intel_modeset_setup_hw_state+0xb67/0xfd0 [i915] ? gen2_read32+0x110/0x110 [i915] ? drm_modeset_lock+0x30/0xa0 [drm] intel_modeset_init+0x794/0x19d0 [i915] ? intel_setup_gmbus+0x232/0x2e0 [i915] i915_driver_load+0xb4a/0xf40 [i915] Signed-off-by: NXiaolin Zhang <xiaolin.zhang@intel.com> Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
-
由 Zhao Yan 提交于
when guest writes ggtt entries, it could write 8 bytes a time if gtt_entry_size is 8. But, qemu could split the 8 bytes into 2 consecutive 4-byte writes. If each 4-byte partial write could trigger a host ggtt write, it is very possible that a wrong combination is written to the host ggtt. E.g. the higher 4 bytes is the old value, but the lower 4 bytes is the new value, and this 8-byte combination is wrong but written to the ggtt, thus causing bugs. To handle this condition, we just record the first 4-byte write, then wait until the second 4-byte write comes and write the combined 64-bit data to host ggtt table. To save memory space and to spot partial write as early as possible, we don't keep this information for every ggtt index. Instread, we just record the last ggtt write position, and assume the two 4-byte writes come in consecutively for each vgpu. This assumption is right based on the characteristic of ggtt entry which stores memory address. When gtt_entry_size is 8, the guest memory physical address should be 64 bits, so any sane guest driver should write 8-byte long data at a time, so 2 consecutive 4-byte writes at the same ggtt index should be trapped in gvt. v2: when incomplete ggtt entry write is located, e.g. 1. guest only writes 4 bytes at a ggtt offset and no long writes the rest 4 bytes. 2. guest writes 4 bytes of a ggtt offset, then write at other ggtt offsets, then return back to write the left 4 bytes of the first ggtt offset. add error handling logic to remap host entry to scratch page, and mark guest virtual ggtt entry as not present. (zhenyu wang) Signed-off-by: NZhao Yan <yan.y.zhao@intel.com> Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
-
由 Thomas Zimmermann 提交于
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: NThomas Zimmermann <tdz@users.sourceforge.net> Signed-off-by: NInki Dae <inki.dae@samsung.com>
-
由 Thomas Zimmermann 提交于
This patch unifies the naming of DRM functions for reference counting of struct drm_gem_object. The resulting code is more aligned with the rest of the Linux kernel interfaces. Signed-off-by: NThomas Zimmermann <tdz@users.sourceforge.net> Signed-off-by: NInki Dae <inki.dae@samsung.com>
-
由 Thomas Zimmermann 提交于
This patch unifies the naming of DRM functions for reference counting of struct drm_framebuffer. The resulting code is more aligned with the rest of the Linux kernel interfaces. Signed-off-by: NThomas Zimmermann <tdz@users.sourceforge.net> Signed-off-by: NInki Dae <inki.dae@samsung.com>
-
- 29 6月, 2018 19 次提交
-
-
由 Jens Axboe 提交于
This was introduced more than a decade ago when sg chaining was added, but we never really caught anything with it. The scatterlist entry size can be critical, since drivers allocate it, so remove the magic member. Recently it's been triggering allocation stalls and failures in NVMe. Tested-by: NJordan Glover <Golden_Miller83@protonmail.ch> Acked-by: NChristoph Hellwig <hch@lst.de> Signed-off-by: NJens Axboe <axboe@kernel.dk>
-
由 Stefan Agner 提交于
The limit_id_fallback array uses enum drm_ipp_size_id to index its content. The content itself is of type enum drm_exynos_ipp_limit_type. Cc: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: NStefan Agner <stefan@agner.ch> Signed-off-by: NInki Dae <inki.dae@samsung.com>
-
由 Marek Szyprowski 提交于
The only bits that should be preserved in decon_win_set_fmt() is WINCONx_ENWIN_F. All other bits depends on the selected pixel formats and are set by the mentioned function. Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: NInki Dae <inki.dae@samsung.com>
-
由 Marek Szyprowski 提交于
Set per-plane global alpha to maximum value to get proper blending of XRGB and ARGB planes. This fixes the strange order of overlapping planes. Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: NInki Dae <inki.dae@samsung.com>
-
由 Marek Szyprowski 提交于
DMA hardware should respect buffer pitch, so use the width calculated from the buffer pitch instead of the virtual one. Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: NInki Dae <inki.dae@samsung.com>
-
由 Marek Szyprowski 提交于
Fix following issues related to planar YUV pixel format configuration: - NV16/61 modes were incorrectly programmed as NV12/21, - YVU420 was programmed as YUV420 on source, - YVU420 and YUV422 were programmed as YUV420 on output. Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: NInki Dae <inki.dae@samsung.com>
-
由 Marek Szyprowski 提交于
Horizontal (DRM_MODE_REFLECT_Y) and vertical (DMR_MODE_REFLECT_Y) flip were swapped in GScaler driver. Fix this by swapping code for interpreting them. Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: NInki Dae <inki.dae@samsung.com>
-
由 Marek Szyprowski 提交于
Investigation revealed that GScaler hardware requires the real buffer width (pitch) to be aligned to 16 pixels. Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: NInki Dae <inki.dae@samsung.com>
-
由 Marek Szyprowski 提交于
DMA hardware should respect buffer pitch, so use the width calculated from the buffer pitch instead of the virtual one. Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: NInki Dae <inki.dae@samsung.com>
-
由 Marek Szyprowski 提交于
Fix Cb/CR components order in two-planar YUV420, YUV422 and YUV444 modes. Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: NInki Dae <inki.dae@samsung.com>
-
由 Andrzej Pietrasiewicz 提交于
Ensure that Scaler hardware is properly reset and interrupts are cleared before processing next image. Signed-off-by: NAndrzej Pietrasiewicz <andrzej.p@samsung.com> Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: NInki Dae <inki.dae@samsung.com>
-
由 Marek Szyprowski 提交于
Horizontal (DRM_MODE_REFLECT_Y) and vertical (DMR_MODE_REFLECT_Y) flip were swapped in Rotator driver. Fix this by swapping code for interpreting them. Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: NInki Dae <inki.dae@samsung.com>
-
由 Marek Szyprowski 提交于
Prepare a common function for size and scale checks and call it for source and destination buffers. Then also move there the state-less checks from exynos_drm_ipp_task_setup_buffer, so the format information is already available in limits processing. Finally perform the IPP_LIMIT_BUFFER check on the real width of the buffer (the width calculated from the provided buffer pitch). Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: NInki Dae <inki.dae@samsung.com>
-
由 Lyude Paul 提交于
The other day I was testing one of the HP laptops at my office with an i915/amdgpu hybrid setup and noticed that hotplugging was non-functional on almost all of the display outputs. I eventually discovered that all of the external outputs were connected to the amdgpu device instead of i915, and that the hotplugs weren't being detected so long as the GPU was in runtime suspend. After some talking with folks at AMD, I learned that amdgpu is actually supposed to support hotplug detection in runtime suspend so long as the OEM has implemented it properly in the firmware. On this HP ZBook 15 G4 (the machine in question), amdgpu wasn't managing to find the ATIF handle at all despite the fact that I could see acpi events being sent in response to any hotplugging. After going through dumps of the firmware, I discovered that this machine did in fact support ATIF, but that it's ATIF method lived in an entirely different namespace than this device's handle (the device handle was \_SB_.PCI0.PEG0.PEGP, but ATIF lives in ATPX's handle at \_SB_.PCI0.GFX0). So, fix this by probing ATPX's ACPI parent's namespace if we can't find ATIF elsewhere, along with storing a pointer to the proper handle to use for ATIF and using that instead of the device's handle. This fixes HPD detection while in runtime suspend for this ZBook! v2: Update the comment to reflect how the namespaces are arranged based on the system configuration. (Alex) Signed-off-by: NLyude Paul <lyude@redhat.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
由 Lyude Paul 提交于
Since it seems that some vendors are storing the ATIF ACPI methods under the same handle that ATPX lives under instead of the device's own handle, we're going to need to be able to retrieve this handle later so we can probe for ATIF there. Signed-off-by: NLyude Paul <lyude@redhat.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
由 Lyude Paul 提交于
Currently, there is nothing in amdgpu that actually uses these structs other than amdgpu_acpi.c. Additionally, since we're about to start saving the correct ACPI handle to use for calling ATIF in this struct this saves us from having to handle making sure that the acpi_handle (and by proxy, the type definition for acpi_handle and all of the other acpi headers) doesn't need to be included within the amdgpu_drv struct itself. This follows the example set by amdgpu_atpx_handler.c. Signed-off-by: NLyude Paul <lyude@redhat.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
由 Evan Quan 提交于
A new member Vr2_I2C_address is added. Signed-off-by: NEvan Quan <evan.quan@amd.com> Acked-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Evan Quan 提交于
The vbios firmware structure changed between v3_1 and v3_2. So, the code to setup bootup values needs different paths based on header version. Signed-off-by: NEvan Quan <evan.quan@amd.com> Acked-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Evan Quan 提交于
Thermal support is enabled on vega12. Signed-off-by: NEvan Quan <evan.quan@amd.com> Acked-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
- 28 6月, 2018 3 次提交
-
-
由 Shirish S 提交于
Currently, amdgpu_do_flip() spinlocks crtc->dev->event_lock and releases it only after committing updates to the stream. dc_commit_updates_for_stream() should be moved out of spinlock for the below reasons: 1. event_lock is supposed to protect access to acrct->pflip_status _only_ 2. dc_commit_updates_for_stream() has potential sleep's and also its not appropriate to be in an atomic state for such long sequences of code. Signed-off-by: NShirish S <shirish.s@amd.com> Suggested-by: NAndrey Grodzovsky <andrey.grodzovsky@amd.com> Reviewed-by: NMichel Dänzer <michel.daenzer@amd.com> Reviewed-by: NHarry Wentland <harry.wentland@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
由 James Zhu 提交于
Support new VCN FW version naming convention: [31, 28] for VEP interface major version if applicable [27, 24] for decode interface major version [23, 20] for encode interface major version [19, 12] for encode interface minor version [11, 0] for firmware revision Bit 20-23, it is encode major and non-zero for new naming convention. This field is part of version minor and DRM_DISABLED_FLAG in old naming convention. Since the latest version minor is 0x5B and DRM_DISABLED_FLAG is zero in old naming convention, this field is always zero so far. These four bits are used to tell which naming convention is present. Signed-off-by: NJames Zhu <James.Zhu@amd.com> Reviewed-by: NFang, Peter <Peter.Fang@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Leo Liu 提交于
Here is the UBSAN dump: [ 3.866656] index 2 is out of range for type 'amdgpu_uvd_inst [2]' [ 3.866693] Workqueue: events work_for_cpu_fn [ 3.866702] Call Trace: [ 3.866710] dump_stack+0x85/0xc5 [ 3.866719] ubsan_epilogue+0x9/0x40 [ 3.866727] __ubsan_handle_out_of_bounds+0x89/0x90 [ 3.866737] ? rcu_read_lock_sched_held+0x58/0x60 [ 3.866746] ? __kmalloc+0x26c/0x2d0 [ 3.866846] amdgpu_fence_driver_start_ring+0x259/0x280 [amdgpu] [ 3.866896] amdgpu_ring_init+0x12c/0x710 [amdgpu] [ 3.866906] ? sprintf+0x42/0x50 [ 3.866956] amdgpu_gfx_kiq_init_ring+0x1bc/0x3a0 [amdgpu] [ 3.867009] gfx_v8_0_sw_init+0x1ad3/0x2360 [amdgpu] [ 3.867062] ? smu7_init+0xec/0x160 [amdgpu] [ 3.867109] amdgpu_device_init+0x112c/0x1dc0 [amdgpu] 'ring->me' might be set as 2 with 'amdgpu_gfx_kiq_init_ring', that would cause out of range for 'amdgpu_uvd_inst[2]'. v2: simplified with ring type Signed-off-by: NLeo Liu <leo.liu@amd.com> Reviewed-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-