summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm
AgeCommit message (Collapse)Author
2019-01-25drm/amd/powerplay: support retrieving and adjusting dcefclock power levels V2Evan Quan
User can use "pp_dpm_dcefclk" to retrieve and adjust dcefclock power levels. V2: expose this interface for Vega10 and later ASICs only Signed-off-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-01-25drm/amd/powerplay: support retrieving and adjusting fclock power levels V2Evan Quan
User can use "pp_dpm_fclk" to retrieve and adjust fclock power levels. V2: expose this interface for Vega20 and later ASICs only Signed-off-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-01-25drm/amd/powerplay: support retrieving and adjusting SOC clock power levels V2Evan Quan
User can use "pp_dpm_socclk" to retrieve and adjust SOC clock power levels. V2: expose this interface for Vega10 and later ASICs only Signed-off-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-01-25drm/amd/powerplay: support enabled ppfeatures retrieving and setting V3Evan Quan
User can use "ppfeatures" sysfs interface to retrieve and set enabled powerplay features. V2: expose this feature for Vega10 and later dGPUs V3: squash in removal of unused variable (Alex) Signed-off-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-01-25drm/amdgpu: set bulk_moveable to false when lru changed v2Chunming Zhou
if lru is changed, we cannot do bulk moving. v2: root bo isn't in bulk moving, skip its change. Signed-off-by: Chunming Zhou <david1.zhou@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-01-25drm/ttm: add lru notify to bo driver v2Chunming Zhou
allow driver do somethings when lru changed. v2: address Michel's comments. Signed-off-by: Chunming Zhou <david1.zhou@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-01-25drm/amdgpu/psp: ignore psp response statusAaron Liu
In some cases, psp response status is not 0 even there is no problem while the command is submitted. Some version of PSP FW doesn't write 0 to that field. So here we would like to only print a warning instead of an error during psp initialization to avoid breaking hw_init and it doesn't return -EINVAL. Signed-off-by: Aaron Liu <aaron.liu@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Reviewed-by: Xiangliang Yu<Xiangliang.Yu@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Reviewed-by: Feifei Xu <Feifei.Xu@amd.com> Reviewed-by: Paul Menzel <pmenzel+amd-gfx@molgen.mpg.de> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-01-25drm/amdgpu: Setting doorbell range registers earlierOak Zeng
HW doorbell writing routing policy: writing to doorbell not in SDMA/IH/MM/ACV doorbell range will be routed to CP. So CP doorbell routing depends on doorbell range setting of above blocks. Setting doorbell range of above blocks earlier (soc15_common_hw_init) to make sure CP doorbell writing be routed to CP block. Signed-off-by: Oak Zeng <Oak.Zeng@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-01-25drm/amdgpu: Fix sdma doorbell range settingOak Zeng
Different ASIC has different SDMA queue number so different SDMA doorbell range. Introduce an extra parameter to sdma_doorbell_range function and set sdma doorbell range correctly. Signed-off-by: Oak Zeng <Oak.Zeng@amd.com> Reviewed-by: Philip Yang <Philip.Yang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-01-25drm/amdgpu: Add per device sdma_doorbell_range fieldOak Zeng
Different ASIC has different sdma doorbell range. Add a per device sdma_doorbell_range field and initialize it. Signed-off-by: Oak Zeng <Oak.Zeng@amd.com> Reviewed-by: Philip Yang <Philip.Yang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-01-25drm/amdgpu/soc15: return proper error codes in baco resetAlex Deucher
Rather than just -1. Reviewed-by: JimQu <Jim.Qu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-01-25drm/amd/display: Include names of all PP clock typesRafał Miłecki
This fixes printing clock names in cases like: [ 5.352311] [drm] DM_PPLIB: values for Invalid clock [ 5.352313] [drm] DM_PPLIB: 400000 in kHz [ 5.352313] [drm] DM_PPLIB: 933000 in kHz [ 5.352314] [drm] DM_PPLIB: 1067000 in kHz [ 5.352315] [drm] DM_PPLIB: 1200000 in kHz [ 5.352317] [drm] DM_PPLIB: values for Invalid clock [ 5.352318] [drm] DM_PPLIB: 300000 in kHz [ 5.352318] [drm] DM_PPLIB: 600000 in kHz [ 5.352319] [drm] DM_PPLIB: 626000 in kHz [ 5.352320] [drm] DM_PPLIB: 654000 in kHz (source: HP EliteBook 745 G5 w. RAVEN 0x1002:0x15DD 0x103C:0x83D5 0xD1) On my system above "Invalid" names got replaced by "F" and "DCF". The same problem was occurring on Huawei Matebook D with just 667000 kHz instead of 400000 kHz. Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-01-25drm/amd: fix typoMatteo Croce
Fix spelling mistake: "lenght" -> "length" Signed-off-by: Matteo Croce <mcroce@redhat.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-01-25drm/amd/display: Skip create new stream if crtc state doesn't changeJerry (Fangzhi) Zuo
Need to check if crtc state is changed so that mode set is required before trying to create new stream. It deals with the MST hotplug use case when plug back to the same connector where the failure to create new stream for the inactive crtc on the old connector. Signed-off-by: Jerry (Fangzhi) Zuo <Jerry.Zuo@amd.com> Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-01-25drm/amdgpu: use BACO reset on vega20 if platform supportJim Qu
Signed-off-by: Jim Qu <Jim.Qu@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-01-25drm/amdgpu: use BACO reset if platform support (v2)Jim Qu
It will fall back to use mode1 reset if platform does not support BACO feature. v2: squash in warning fix (Alex) Signed-off-by: Jim Qu <Jim.Qu@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-01-25drm/amdgpu/powerper: add vega20 BACO functionsJim Qu
Signed-off-by: Jim Qu <Jim.Qu@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-01-25drm/amdgpu: update THM IP register header to support BACOJim Qu
Signed-off-by: Jim Qu <Jim.Qu@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-01-25drm/amdgpu: also include NBIO v7.4 register mask headerJim Qu
Signed-off-by: Jim Qu <Jim.Qu@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-01-25drm/amdgpu: update NBIO v7.4 to support BACOJim Qu
Signed-off-by: Jim Qu <Jim.Qu@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-01-25drm/amdgpu: expose BACO interfaces to upper level from PPJim Qu
Signed-off-by: Jim Qu <Jim.Qu@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-01-25drm/amdgpu: add BACO interfaces for vega10Jim Qu
V2: delay 20ms before BACO out. V3: rename function to vega10_baco_xxx Signed-off-by: Jim Qu <Jim.Qu@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-01-25drm/amdpgu: add common functions for BACO feature in PP (v2)Jim Qu
V2: squash in crash fix for non-register commands (Alex) Signed-off-by: Jim Qu <Jim.Qu@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-01-25drm/i915: Clean up intel_plane_atomic_check_with_state()Ville Syrjälä
Rename some of the state variables in intel_plane_atomic_check_with_state() to make it less confusing. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190111170823.4441-2-ville.syrjala@linux.intel.com Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com>
2019-01-25drm/i915/tv: Filter out >1024 wide modes that would need vertical scaling on ↵Ville Syrjälä
gen3 Since gen3 can't handle >1024 wide sources with vertical scaling let's not advertize such modes in the mode list. Less tempetation to the user to try out things that won't work. v2: s/IS_GEN3(dev_priv/IS_GEN(dev_priv, 3)/ Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181112170000.27531-17-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2019-01-25drm/i915/tv: Fix >1024 modes on gen3Ville Syrjälä
On gen3 we must disable the TV encoder vertical filter for >1024 pixel wide sources. Once that's done all we can is try to center the image on the screen. Naturally the TV mode vertical resolution must be equal or larger than the user mode vertical resolution or else we'd have to cut off part of the user mode. And while we may not be able to respect the user's choice of top and bottom borders exactly (or we'd have to reject he mode most likely), we can try to maintain the relative sizes of the top and bottom border with respect to each orher. Additionally we must configure the pipe as interlaced if the TV mode is interlaced. v2: Make +intel_tv_connector_duplicate_state() static and drop the badly copy pasted kerneldoc s/IS_GEN3(dev_priv/IS_GEN(dev_priv, 3)/ Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181112170000.27531-16-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2019-01-25drm/i915/tv: Generate better pipe timings for TV encoderVille Syrjälä
To make vblank timestamps work better with the TV encoder let's scale the pipe timings such that the relationship between the TV active and TV blanking periods is mirrored in the corresponding pipe timings. Note that in reality the pipe runs at a faster speed during the TV vblank, and correspondigly there are periods when the pipe is enitrely stopped. We pretend that this isn't the case and as such we incur some error in the vblank timestamps during the TV vblank. Further explanation of the issues in a big comment in the code. This makes the vblank timestamps good enough to make i965gm (which doesn't have a working frame counter with the TV encoder) report correct frame numbers. Previously you could get all kinds of nonsense which resulted in eg. glxgears reporting that it's running at twice the actual framerate in most cases. v2: s/IS_GEN4(dev_priv)/IS_GEN(dev_priv, 4)/ in the comment for consistency Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181112170000.27531-15-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2019-01-25drm/i915/tv: Add 1080p30/50/60 TV modesVille Syrjälä
Add the missing 1080p TV modes. On gen4 all of them work just fine, whereas on gen3 only the 30Hz mode actually works correctly. v2: s/IS_GEN3(dev_priv)/IS_GEN(dev_priv, 3)/ Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181112170000.27531-14-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2019-01-25drm/i915/tv: Nuke reported_modes[]Ville Syrjälä
Remove the silly reported_modes[] array. I suppse once upon a time this actually had something to do with modes we reported to userspace. Now it is just the placeholder for the mode we use for load detection. We don't need it even for that, and instead we can just rely on the fallback mode in intel_get_load_detect_pipe(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181112170000.27531-13-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2019-01-25drm/i915/tv: Make TV mode autoselection actually useableVille Syrjälä
The current code insists on picking a new TV mode when switching between component and non-component cables. That's super annoying. Let's just keep the current TV mode unless the new cable type actually disagrees with it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181112170000.27531-12-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2019-01-25drm/i915/tv: Use drm_mode_set_name() to name TV modesVille Syrjälä
No point in storing the mode names in the array. drm_mode_set_name() will give us the same names without wasting space for these string constants. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181112170000.27531-11-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2019-01-25drm/i915/tv: Deobfuscate preferred mode selectionVille Syrjälä
Rewrite the preferred mode selection to just check whether the TV modes is HD or SD. For SD TV modes we favor 480 line modes, for 720p we prefer 720 line modes, and for 1080i/p we prefer 1080 line modes. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181112170000.27531-10-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2019-01-25drm/i915/tv: Nuke silly 0 initialzation of xpos/yposVille Syrjälä
Just assign the margin values directly to xpos/ypos instead of first initializing to zero and then adding the values. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181112170000.27531-8-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2019-01-25drm/i915/tv: Use bools where appropriateVille Syrjälä
'component_only' is a bool. Initialize it like a bool. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181112170000.27531-7-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2019-01-25drm/i915/tv: Store the TV oversampling factor in the TV modeVille Syrjälä
Store the oversampling factor as a number in the TV modes. We shall want to arithmetic with this which is easier if it's a number we can use directly. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181112170000.27531-6-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2019-01-25drm/i915/tv: Fix tv mode clocksVille Syrjälä
The oversample clock is always supposed to be either 108 MHz or 148.5 MHz. Make it so. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181112170000.27531-5-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2019-01-25drm/i915/tv: Fix interlaced ysize calculationVille Syrjälä
Fix the calculation of the vertical active period for interlaced TV modes. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181112170000.27531-4-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2019-01-25drm/i915: Don't try to use the hardware frame counter with i965gm TV outputVille Syrjälä
On i965gm the hardware frame counter does not work when the TV encoder is active. So let's not try to consult the hardware frame counter in that case. Instead we'll fall back to the timestamp based guesstimation method used on gen2. Note that the pipe timings generated by the TV encoder are also rather peculiar. Apparently the pipe wants to run at a much higher speed (related to the oversample clock somehow it seems) but during the vertical active period the TV encoder stalls the pipe every few lines to keep its speed in check. But once the vertical blanking period is reached the pipe gets to run at full speed. This means our vblank timestamp estimates are suspect. Fixing all that would require quite a bit more work. This simple fix at least avoids the nasty vblank timeouts that are happening currently. Curiously the frame counter works just fine on i945gm and gm45. I don't really understand what kind of mishap occurred with the hardware design on i965gm. Sadly I wasn't able to find any chicken bits etc. that would fix the frame counter :( v2: Move the zero vs. non-zero hw counter value handling into i915_get_vblank_counter() (Daniel) Use the per-crtc maximum exclusively, leaving the per-device maximum at zero v3: max_vblank_count not populated yet in intel_enable_pipe() use intel_crtc_max_vblank_count() instead Cc: stable@vger.kernel.org Cc: Daniel Vetter <daniel@ffwll.ch> Fixes: 51e31d49c890 ("drm/i915: Use generic vblank wait") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93782 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190122125149.GE5527@ideak-desk.fi.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2019-01-25drm/i915: Issue engine resets onto idle enginesChris Wilson
Always perform the requested reset, even if we believe the engine is idle. Presumably there was a reason the caller wanted the reset, and in the near future we lose the easy tracking for whether the engine is idle. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190125132230.22221-5-chris@chris-wilson.co.uk
2019-01-25drm/i915/selftests: Trim struct_mutex duration for set-wedged selftestChris Wilson
Trim the struct_mutex hold and exclude the call to i915_gem_set_wedged() as a reminder that it must be callable without struct_mutex held. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190125132230.22221-4-chris@chris-wilson.co.uk
2019-01-25drm/i915: Remove GPU reset dependence on struct_mutexChris Wilson
Now that the submission backends are controlled via their own spinlocks, with a wave of a magic wand we can lift the struct_mutex requirement around GPU reset. That is we allow the submission frontend (userspace) to keep on submitting while we process the GPU reset as we can suspend the backend independently. The major change is around the backoff/handoff strategy for performing the reset. With no mutex deadlock, we no longer have to coordinate with any waiter, and just perform the reset immediately. Testcase: igt/gem_mmap_gtt/hang # regresses Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190125132230.22221-3-chris@chris-wilson.co.uk
2019-01-25drm/i915/guc: Disable global resetChris Wilson
The guc (and huc) currently inexcruitably depend on struct_mutex for device reinitialisation from inside the reset, and indeed taking any mutex here is verboten (as we must be able to reset from underneath any of our mutexes). That makes recovering the guc unviable without, for example, reserving contiguous vma space and pages for it to use. The plan to re-enable global reset for the GuC centres around reusing the WOPM reserved space at the top of the aperture (that we know we can populate a contiguous range large enough to dma xfer the fw image). In the meantime, hopefully no one even notices as the device-reset is only used as a backup to the per-engine resets for handling GPU hangs. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Acked-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190125132230.22221-2-chris@chris-wilson.co.uk
2019-01-25drm/i915: Make all GPU resets atomicChris Wilson
In preparation for the next few commits, make resetting the GPU atomic. Currently, we have prepared gen6+ for atomic resetting of individual engines, but now there is a requirement to perform the whole device level reset (just the register poking) from inside an atomic context. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190125132230.22221-1-chris@chris-wilson.co.uk
2019-01-25drm/rockchip: rgb: update SPDX license identifierSandy Huang
Update SPDX License Identifier from GPL-2.0+ to GPL-2.0 and drop some GPL text. This fixes a mismatch between the existing SPDX headers and GPL boilerplate text. Fixes: 1f0f01515172 ("Add support for Rockchip Soc RGB output interface") Cc: stable@vger.kernel.org Reported-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Sandy Huang <hjc@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/1548238479-171491-1-git-send-email-hjc@rock-chips.com
2019-01-25drm/i915: Compute the HWS offsets explicitlyChris Wilson
Simplify by using sizeof(u32) to convert from the index inside the HWSP to the byte offset. This has the advantage of not only being shorter (and so not upsetting checkpatch!) but that it matches use where we are writing to byte addresses using other commands than MI_STORE_DWORD_IMM. v2: Drop the now superfluous MI_STORE_DWORD_INDEX_SHIFT, it appears to be a local invention so keeping it after the final use does not help to clarify the GPU instruction. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190125120005.25191-2-chris@chris-wilson.co.uk
2019-01-25drm/i915: Remove manual breadcumb countingChris Wilson
Now that we know we measure the size of the engine->emit_breadcrumb() correctly, we can remove the previous manual counting. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190125120005.25191-1-chris@chris-wilson.co.uk
2019-01-25drm/i915: Measure the required reserved size for request emissionChris Wilson
Instead of tediously and fragilely counting up the number of dwords required to emit the breadcrumb to seal a request, fake a request and measure it automatically once during engine setup. The downside is that this requires a fair amount of mocking to create a proper breadcrumb. Still, should be less error prone in future as the breadcrumb size fluctuates! Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190125100520.20163-1-chris@chris-wilson.co.uk
2019-01-25drm/i915/execlists: Move RPCS setup to context pinTvrtko Ursulin
Configuring RPCS in context image just before pin is sufficient and will come extra handy in one of the following patches. v2: * Split image setup a bit differently. (Chris Wilson) v3: * Update context image after reset as well - otherwise the application of pinned default state clears the RPCS. v4: * Use local variable throughout the function. (Chris Wilson) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Suggested-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190125023005.1007-1-chris@chris-wilson.co.uk
2019-01-25drm/sun4i: Add support for A23 display pipelineChen-Yu Tsai
The A23's display pipeline is similar to the A33. Differences include: - Display backend supports larger layers, 8192x8192 instead of 2048x2048 - TCON has DMA input - There is no SAT module packed in the display backend Add support for the display pipeline and its components. As the MIPI DSI output device is not officially documented, and there are no A23 reference devices to test it, it is not covered by this patch. Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190125032314.20915-7-wens@csie.org
2019-01-25drm/sun4i: layer: support just backend formats when frontend is unavailableChen-Yu Tsai
In some cases, such as running a new kernel with an old device tree that has the frontend disabled, the backend's matching frontend might be unavailable. When this happens, the layers should only declare support for formats that the backend support. This partially reverts commit 1c29d263f624 ("drm/sun4i: Rename sun4i_backend_layer_formats to sun4i_layer_formats") by bringing back sun4i_backend_layer_formats, and passing it to drm_universal_plane_init, while also dropping the modifiers list, in the event no frontend is available. Fixes: b636d3f97d04 ("drm/sun4i: frontend: Add support for the BGRX8888 input format") Fixes: 9afe52d54bb0 ("drm/sun4i: frontend: Add support for semi-planar YUV input formats") Fixes: 8c8152bf4db6 ("drm/sun4i: frontend: Add support for planar YUV input formats") Fixes: b2ddf277ab5e ("drm/sun4i: layer: Add tiled modifier support and helper") Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190125032314.20915-6-wens@csie.org
generated by cgit (git 2.34.1) at 2025-09-19 12:43:24 +0000