Re: [PATCH] drm/lima: fix reference leak in lima_pm_busy
Thanks, applied to drm-misc-next.
Regards,
Qiang
On Fri, Nov 27, 2020 at 5:42 PM Qinglang Miao wrote:
>
> pm_runtime_get_sync will increment pm usage counter even it
> failed. Forgetting to putting operation will result in a
> reference leak here.
>
> A new function pm_runtime_resume_and_get is introduced in
> [0] to keep usage counter balanced. So We fix the reference
> leak by replacing it with new funtion.
>
> [0] dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with
> usage counter")
>
> Fixes: 50de2e9ebbc0 ("drm/lima: enable runtime pm")
> Reported-by: Hulk Robot
> Signed-off-by: Qinglang Miao
> ---
> drivers/gpu/drm/lima/lima_sched.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/lima/lima_sched.c
> b/drivers/gpu/drm/lima/lima_sched.c
> index dc6df9e9a..f6e7a88a5 100644
> --- a/drivers/gpu/drm/lima/lima_sched.c
> +++ b/drivers/gpu/drm/lima/lima_sched.c
> @@ -200,7 +200,7 @@ static int lima_pm_busy(struct lima_device *ldev)
> int ret;
>
> /* resume GPU if it has been suspended by runtime PM */
> - ret = pm_runtime_get_sync(ldev->dev);
> + ret = pm_runtime_resume_and_get(ldev->dev);
> if (ret < 0)
> return ret;
>
> --
> 2.23.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm/msm: Fix race of GPU init vs timestamp power management.
On Thu, Jan 28, 2021 at 11:17:16AM -0800, Eric Anholt wrote:
> On Thu, Jan 28, 2021 at 10:52 AM Jordan Crouse wrote:
> >
> > On Wed, Jan 27, 2021 at 03:39:44PM -0800, Eric Anholt wrote:
> > > We were using the same force-poweron bit in the two codepaths, so they
> > > could race to have one of them lose GPU power early.
> > >
> > > Signed-off-by: Eric Anholt
> > > Cc: sta...@vger.kernel.org # v5.9
> >
> > You can add:
> > Fixes: 4b565ca5a2cb ("drm/msm: Add A6XX device support")
> >
> > Because that was my ugly.
> >
> > Reviewed-by: Jordan Crouse
>
> I only pointed it at 5.9 because it looked like it would probably
> conflict against older branches. I can add the fixes tag if you'd
> like, though.
Fair enough. It is a good bug to fix but not if there are a lot of conflicts to
deal with.
Jordan
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-intel-next
Hi Dave and Daniel, On my last pull request I incorrectly stated that Async flips were enabled for all ilk+ platforms, while it was only on SKL. I'm sorry about that. I hope there's still time to include a few changes including the actual patches that make this statement true for 5.12. Along with other fixes and clean-up as described below: Here goes drm-intel-next-2021-01-29: - WARN if plane src coords are too big (Ville) - Prevent double YUV range correction on HDR planes (Andres) - DP MST related Fixes (Sean, Imre) - More clean-up around DRAM detection code (Jose) - Actually async flips enable for all ilk+ platforms (Ville) Sorry and Thanks, Rodrigo. The following changes since commit 784953a46589276b38d7e6dcb5ebf7e29db72ff1: drm/i915/display/vrr: Skip the VRR HW state readout on DSI transcoder (2021-01-26 16:34:53 -0800) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2021-01-29 for you to fetch changes up to 3b7bbb3619d2cc92f04ba10ad27d3b616aabf175: drm/i915/dp: Prevent setting the LTTPR LT mode if no LTTPRs are detected (2021-01-29 22:00:07 +0200) - WARN if plane src coords are too big (Ville) - Prevent double YUV range correction on HDR planes (Andres) - DP MST related Fixes (Sean, Imre) - More clean-up around DRAM detection code (Jose) - Actually async flips enable for all ilk+ platforms (Ville) Andres Calderon Jaramillo (1): drm/i915/display: Prevent double YUV range correction on HDR planes Imre Deak (3): drm/dp/mst: Export drm_dp_get_vc_payload_bw() drm/i915: Fix the MST PBN divider calculation drm/i915/dp: Prevent setting the LTTPR LT mode if no LTTPRs are detected José Roberto de Souza (3): drm/i915: Nuke not needed members of dram_info drm/i915/gen11+: Only load DRAM information from pcode drm/i915: Rename is_16gb_dimm to wm_lv_0_adjust_needed Sean Paul (1): drm/i915/hdcp: Disable the QSES check for HDCP 1.4 over MST Ville Syrjälä (6): drm/i915: WARN if plane src coords are too big drm/i915: Limit plane stride to below TILEOFF.x limit drm/i915: Implement async flips for bdw drm/i915: Implement async flip for ivb/hsw drm/i915: Implement async flip for ilk/snb drm/i915: Implement async flips for vlv/chv drivers/gpu/drm/drm_dp_mst_topology.c | 24 ++- drivers/gpu/drm/i915/display/i9xx_plane.c | 213 - drivers/gpu/drm/i915/display/i9xx_plane.h | 2 +- drivers/gpu/drm/i915/display/intel_bw.c| 80 +--- drivers/gpu/drm/i915/display/intel_display.c | 16 +- drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 12 +- .../gpu/drm/i915/display/intel_dp_link_training.c | 36 ++-- drivers/gpu/drm/i915/display/intel_dp_mst.c| 4 +- drivers/gpu/drm/i915/display/intel_sprite.c| 98 -- drivers/gpu/drm/i915/i915_drv.c| 9 +- drivers/gpu/drm/i915/i915_drv.h| 6 +- drivers/gpu/drm/i915/i915_irq.c| 39 ++-- drivers/gpu/drm/i915/i915_reg.h| 3 + drivers/gpu/drm/i915/intel_dram.c | 136 + drivers/gpu/drm/i915/intel_pm.c| 2 +- include/drm/drm_dp_mst_helper.h| 1 + 16 files changed, 434 insertions(+), 247 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [pull] amdgpu, amdkfd drm-next-5.12
[AMD Public Use] > -Original Message- > From: Kuehling, Felix > Sent: Friday, January 29, 2021 5:33 PM > To: Alex Deucher ; amd- > g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; > airl...@gmail.com; daniel.vet...@ffwll.ch > Cc: Deucher, Alexander ; Pan, Xinhui > ; Koenig, Christian > Subject: Re: [pull] amdgpu, amdkfd drm-next-5.12 > > Am 2021-01-29 um 5:28 p.m. schrieb Alex Deucher: > > drm/amdgpu: Make contiguous pinning optional > > This one needs a follow-up fix, as it breaks pinning in GTT. Xinhui should > have > the fix ready very soon. You may want to hold this back until the fix lands. Ok. Ignore this PR for now. I'll send an updated one next week when the fix lands. Thanks, Alex > > Regards, > Felix > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [pull] amdgpu, amdkfd drm-next-5.12
Am 2021-01-29 um 5:28 p.m. schrieb Alex Deucher: > drm/amdgpu: Make contiguous pinning optional This one needs a follow-up fix, as it breaks pinning in GTT. Xinhui should have the fix ready very soon. You may want to hold this back until the fix lands. Regards, Felix ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[pull] amdgpu, amdkfd drm-next-5.12
Hi Dave, Daniel, Fixes for 5.12. The following changes since commit a6b8720c2f85143561c3453e1cf928a2f8586ac0: Merge tag 'amd-drm-next-5.12-2021-01-20' of https://gitlab.freedesktop.org/agd5f/linux into drm-next (2021-01-20 13:08:18 +0100) are available in the Git repository at: https://gitlab.freedesktop.org/agd5f/linux.git tags/amd-drm-next-5.12-2021-01-29 for you to fetch changes up to efa18405baa55a864c61d2f3cc6fe4d363818eb3: drm/amd/display: Fix HDMI deep color output for DCE 6-11. (2021-01-25 17:49:47 -0500) amd-drm-next-5.12-2021-01-29: amdgpu: - Display fixes and cleanups - Vangogh fixes - Fix possible race when there are timeouts on two rings - SR-IOV fixes - Add missing license - DCE 10/12 bpc fixes - Display MALL fixes - Fix SMU user preference settings persistence amdkfd: - Fix config handling Aaron Liu (1): drm/amdgpu: update mmhub mgcg for mmhub_v2_3 Anthony Koo (1): drm/amd/display: [FW Promotion] Release 0.0.48 Aric Cyr (2): drm/amd/display: Allow PSTATE chnage when no displays are enabled drm/amd/display: 3.2.119 Arnd Bergmann (1): amdgpu: fix clang build warning Arunpravin (1): drm/amd/pm: store and reinstate swsmu user power configurations Bhawanpreet Lakha (3): drm/amd/display: Enable programing of MALL watermarks drm/amd/display: Dynamic cursor cache size for MALL eligibility check drm/amd/display: Update dcn30_apply_idle_power_optimizations() code Bing Guo (2): drm/amd/display: Change function decide_dp_link_settings to avoid infinite looping drm/amd/display: Fix dml20v2_ModeSupportAndSystemConfigurationFull() to check DesiredBPP. Colin Ian King (2): drm/amd/display: Fix spelling mistake of function name drm/amdgpu: Fix masking binary not operator on two mask operations Dan Carpenter (1): drm/amd/display: Fix a potential NULL dereference Feifei Xu (1): drm/amdgpu:Add pcie gen5 support in pcie capability. Felix Kuehling (2): drm/amdkfd: Enable userptr support when KFD is enabled drm/amdgpu: Make contiguous pinning optional George Shen (1): drm/amd/display: Log link/connector info provided in BIOS object table Horace Chen (1): drm/amdgpu: race issue when jobs on 2 ring timeout Huang Rui (2): drm/amd/pm: print the timeout of smc message drm/amdgpu: remove gpu info firmware of green sardine Jake Wang (1): drm/amd/display: Update dram_clock_change_latency for DCN2.1 Jiapeng Zhong (1): drm/amdgpu: Assign boolean values to a bool variable Jingwen Chen (2): drm/amd/amdgpu: remove redundant flush_delayed_work drm/amd/amdgpu: add error handling to amdgpu_virt_read_pf2vf_data Jinzhou Su (4): drm/amdgpu: Remove GFXOFF MASK for Vangogh drm/amdgpu: modify GCR_GENERAL_CNTL for Vangogh drm/amdgpu: Add RLC_PG_DELAY_3 for Vangogh drm/amdgpu: Allow GfxOff on Vangogh as default Jonathan Gray (1): drm/amd/display: change license of color_table.c Kevin Wang (1): drm/amd/pm: remove unused message SMU_MSG_SpareX Lang Yu (1): drm/amd/display: fix 64-bit division issue on 32-bit OS Mario Kleiner (2): drm/amd/display: Fix 10/12 bpc setup in DCE output bit depth reduction. drm/amd/display: Fix HDMI deep color output for DCE 6-11. Mike Hsieh (1): drm/amd/display: disable FEC while using eDP Nicholas Kazlauskas (4): drm/amd/display: Use hardware sequencer functions for PG control drm/amd/display: Allow dmub srv hardware reset before HW init drm/amd/display: Guard against NULL pointer deref when get_i2c_info fails drm/amd/display: Fix reset sequence with driver direct DMCUB fw load Pratik Vishwakarma (1): Revert "drm/amd/display: Tune min clk values for MPO for RV" Prike Liang (1): drm/amdgpu/pm: no need GPU status set since mmnbif_gpu_BIF_DOORBELL_FENCE_CNTL added in FSDL Stylon Wang (1): drm/amd/display: Report Freesync to vrr_range debugfs entry in DRM Sung Lee (1): drm/amd/display: DCN2X Find Secondary Pipe properly in MPO + ODM Case Vladimir Stempen (1): drm/amd/display: Fixed corruptions on HPDRX link loss restore Wyatt Wood (1): drm/amd/display: Allow dmu_stg to support cached inbox for dmub drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 86 -- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 7 +- drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 7 +- drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 23 ++- drivers/gpu/drm/amd/amdgpu/mmhub_v2_3.c| 84 +++--- drivers/gpu/drm/amd/amdkfd/Kconfig | 2 + drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 + .../gpu/drm/amd/display/dc/bios/command_table.c| 61 +++ .../drm/amd/display/dc/clk_mgr/dcn10/rv1_clk_mgr.c | 30 +---
Re: [git pull] drm fixes for 5.11-rc6
The pull request you sent on Fri, 29 Jan 2021 13:46:34 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2021-01-29 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/6305d15e013a70a7f1c4ee65d3e035cd705e3517 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: Remove unreachable code
Quoting Vinicius Tinti (2021-01-29 18:15:19) > By enabling -Wunreachable-code-aggressive on Clang the following code > paths are unreachable. That code exists as commentary and, especially for sdvo, library functions that we may need in future. The ivb-gt1 case => as we now set the gt level for ivb, should we not enable the optimisation for ivb unaffected by the w/a? Just no one has taken the time to see if it causes a regression. For error state, the question remains whether we should revert to uncompressed data if the compressed stream is larger than the original. -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[GIT PULL] drm/tegra: Changes for v5.12-rc1
Hi Dave, The following changes since commit 5c8fe583cce542aa0b84adc939ce85293de36e5e: Linux 5.11-rc1 (2020-12-27 15:30:22 -0800) are available in the Git repository at: ssh://git.freedesktop.org/git/tegra/linux.git tags/drm/tegra/for-5.12-rc1 for you to fetch changes up to dcdfe2712b68f1e9dbf4f1a96ad59b80e5cc0ef7: drm/tegra: Fix reference leak when pm_runtime_get_sync() fails (2021-01-15 17:24:51 +0100) Thanks, Thierry drm/tegra: Changes for v5.12-rc1 Adds support for newer firmware image versions of the Video Image Composer (VIC) and adds a comment clarifying the use of the STREAMID registers. Fixes a couple of issues with display and gr2d on older Tegra SoCs such as Tegra114, as well as a runtime PM reference leak. Dmitry Osipenko (3): drm/tegra: dc: Enable display controller driver for Tegra114 drm/tegra: gr2d: Correct swapped device-tree compatibles drm/tegra: gr2d: Add compatible for Tegra114 Mikko Perttunen (2): drm/tegra: falcon: Support newer VIC firmware drm/tegra: vic: Add comments on STREAMID registers Qinglang Miao (1): drm/tegra: Fix reference leak when pm_runtime_get_sync() fails drivers/gpu/drm/tegra/dc.c | 2 +- drivers/gpu/drm/tegra/drm.c| 2 ++ drivers/gpu/drm/tegra/dsi.c| 2 +- drivers/gpu/drm/tegra/falcon.c | 9 + drivers/gpu/drm/tegra/gr2d.c | 9 +++-- drivers/gpu/drm/tegra/hdmi.c | 2 +- drivers/gpu/drm/tegra/hub.c| 2 +- drivers/gpu/drm/tegra/sor.c| 2 +- drivers/gpu/drm/tegra/vic.c| 35 ++- 9 files changed, 45 insertions(+), 20 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH][next] drm/amdgpu: Fix memory leak of object caps on error return paths
On Fri, Jan 29, 2021 at 7:08 AM Colin King wrote:
>
> From: Colin Ian King
>
> Currently there are three error return paths that don't kfree object
> caps. Fix this by performing the allocation of caps after the checks
> and error return paths to avoid the premature allocation and memory
> leaking.
>
> Addresses-Coverity: ("Resource leak")
> Fixes: 555fc7fbb2a2 ("drm/amdgpu: add INFO ioctl support for querying video
> caps")
> Signed-off-by: Colin Ian King
Applied. Thanks!
Alex
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> index 84b666fcfaf6..730f4ac7487b 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> @@ -988,10 +988,6 @@ int amdgpu_info_ioctl(struct drm_device *dev, void
> *data, struct drm_file *filp)
> struct drm_amdgpu_info_video_caps *caps;
> int r;
>
> - caps = kzalloc(sizeof(*caps), GFP_KERNEL);
> - if (!caps)
> - return -ENOMEM;
> -
> switch (info->video_cap.type) {
> case AMDGPU_INFO_VIDEO_CAPS_DECODE:
> r = amdgpu_asic_query_video_codecs(adev, false,
> );
> @@ -1009,6 +1005,11 @@ int amdgpu_info_ioctl(struct drm_device *dev, void
> *data, struct drm_file *filp)
> info->video_cap.type);
> return -EINVAL;
> }
> +
> + caps = kzalloc(sizeof(*caps), GFP_KERNEL);
> + if (!caps)
> + return -ENOMEM;
> +
> for (i = 0; i < codecs->codec_count; i++) {
> int idx = codecs->codec_array[i].codec_type;
>
> --
> 2.29.2
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/display: Simplify bool conversion
On Thu, Jan 28, 2021 at 2:45 PM Abaci Team wrote: > > Fix the following coccicheck warning: > ./drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c:3137:35-40: > WARNING: conversion to bool not needed here > > Reported-by: Abaci Robot > Suggested-by: Yang Li > Signed-off-by: Abaci Team Applied. Thanks! Alex > --- > drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c > b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c > index 017b67b8..fc03d91 100644 > --- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c > +++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c > @@ -3134,7 +3134,7 @@ void dcn10_setup_stereo(struct pipe_ctx *pipe_ctx, > struct dc *dc) > > pipe_ctx->stream_res.opp->funcs->opp_program_stereo( > pipe_ctx->stream_res.opp, > - flags.PROGRAM_STEREO == 1 ? true:false, > + flags.PROGRAM_STEREO == 1, > >timing); > > pipe_ctx->stream_res.tg->funcs->program_stereo( > -- > 1.8.3.1 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 11/14] drm/amdgpu: Guard against write accesses after device removal
Am 29.01.21 um 18:35 schrieb Andrey Grodzovsky: On 1/29/21 10:16 AM, Christian König wrote: Am 28.01.21 um 18:23 schrieb Andrey Grodzovsky: On 1/19/21 1:59 PM, Christian König wrote: Am 19.01.21 um 19:22 schrieb Andrey Grodzovsky: On 1/19/21 1:05 PM, Daniel Vetter wrote: [SNIP] So say writing in a loop to some harmless scratch register for many times both for plugged and unplugged case and measure total time delta ? I think we should at least measure the following: 1. Writing X times to a scratch reg without your patch. 2. Writing X times to a scratch reg with your patch. 3. Writing X times to a scratch reg with the hardware physically disconnected. I suggest to repeat that once for Polaris (or older) and once for Vega or Navi. The SRBM on Polaris is meant to introduce some delay in each access, so it might react differently then the newer hardware. Christian. See attached results and the testing code. Ran on Polaris (gfx8) and Vega10(gfx9) In summary, over 1 million WWREG32 in loop with and without this patch you get around 10ms of accumulated overhead ( so 0.1 millisecond penalty for each WWREG32) for using drm_dev_enter check when writing registers. P.S Bullet 3 I cannot test as I need eGPU and currently I don't have one. Well if I'm not completely mistaken that are 100ms of accumulated overhead. So around 100ns per write. And even bigger problem is that this is a ~67% increase. My bad, and 67% from what ? How u calculate ? My bad, (308501-209689)/209689=47% increase. I'm not sure how many write we do during normal operation, but that sounds like a bit much. Ideas? Well, u suggested to move the drm_dev_enter way up but as i see it the problem with this is that it increase the chance of race where the device is extracted after we check for drm_dev_enter (there is also such chance even when it's placed inside WWREG but it's lower). Earlier I propsed that instead of doing all those guards scattered all over the code simply delay release of system memory pages and unreserve of MMIO ranges to until after the device itself is gone after last drm device reference is dropped. But Daniel opposes delaying MMIO ranges unreserve to after PCI remove code because according to him it will upset the PCI subsytem. Yeah, that's most likely true as well. Maybe Daniel has another idea when he's back from vacation. Christian. Andrey Christian. ___ amd-gfx mailing list amd-...@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 11/14] drm/amdgpu: Guard against write accesses after device removal
On 1/29/21 10:16 AM, Christian König wrote: Am 28.01.21 um 18:23 schrieb Andrey Grodzovsky: On 1/19/21 1:59 PM, Christian König wrote: Am 19.01.21 um 19:22 schrieb Andrey Grodzovsky: On 1/19/21 1:05 PM, Daniel Vetter wrote: [SNIP] So say writing in a loop to some harmless scratch register for many times both for plugged and unplugged case and measure total time delta ? I think we should at least measure the following: 1. Writing X times to a scratch reg without your patch. 2. Writing X times to a scratch reg with your patch. 3. Writing X times to a scratch reg with the hardware physically disconnected. I suggest to repeat that once for Polaris (or older) and once for Vega or Navi. The SRBM on Polaris is meant to introduce some delay in each access, so it might react differently then the newer hardware. Christian. See attached results and the testing code. Ran on Polaris (gfx8) and Vega10(gfx9) In summary, over 1 million WWREG32 in loop with and without this patch you get around 10ms of accumulated overhead ( so 0.1 millisecond penalty for each WWREG32) for using drm_dev_enter check when writing registers. P.S Bullet 3 I cannot test as I need eGPU and currently I don't have one. Well if I'm not completely mistaken that are 100ms of accumulated overhead. So around 100ns per write. And even bigger problem is that this is a ~67% increase. My bad, and 67% from what ? How u calculate ? I'm not sure how many write we do during normal operation, but that sounds like a bit much. Ideas? Well, u suggested to move the drm_dev_enter way up but as i see it the problem with this is that it increase the chance of race where the device is extracted after we check for drm_dev_enter (there is also such chance even when it's placed inside WWREG but it's lower). Earlier I propsed that instead of doing all those guards scattered all over the code simply delay release of system memory pages and unreserve of MMIO ranges to until after the device itself is gone after last drm device reference is dropped. But Daniel opposes delaying MMIO ranges unreserve to after PCI remove code because according to him it will upset the PCI subsytem. Andrey Christian. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/v3d: Fix incorrect return type to timedout_job
The commit a6a1f036c74e ("drm/scheduler: Job timeout handler returns
status (v3)") incorrectly uses "enum drm_task_status" for v3d and causes
a build failure. "enum drm_task_status" got changed into "enum
drm_gpu_sched_status" in v3 of the patch but the change for v3d got
lost.
Fixes: ("drm/scheduler: Job timeout handler returns status (v3)")
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/v3d/v3d_sched.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/v3d/v3d_sched.c b/drivers/gpu/drm/v3d/v3d_sched.c
index ef2338a294ca..ceb33f8e4379 100644
--- a/drivers/gpu/drm/v3d/v3d_sched.c
+++ b/drivers/gpu/drm/v3d/v3d_sched.c
@@ -259,7 +259,7 @@ v3d_cache_clean_job_run(struct drm_sched_job *sched_job)
return NULL;
}
-static enum drm_gpu_sched_status
+static enum drm_gpu_sched_stat
v3d_gpu_reset_for_timeout(struct v3d_dev *v3d, struct drm_sched_job *sched_job)
{
enum v3d_queue q;
@@ -294,7 +294,7 @@ v3d_gpu_reset_for_timeout(struct v3d_dev *v3d, struct
drm_sched_job *sched_job)
* could fail if the GPU got in an infinite loop in the CL, but that
* is pretty unlikely outside of an i-g-t testcase.
*/
-static enum drm_task_status
+static enum drm_gpu_sched_stat
v3d_cl_job_timedout(struct drm_sched_job *sched_job, enum v3d_queue q,
u32 *timedout_ctca, u32 *timedout_ctra)
{
@@ -312,7 +312,7 @@ v3d_cl_job_timedout(struct drm_sched_job *sched_job, enum
v3d_queue q,
return v3d_gpu_reset_for_timeout(v3d, sched_job);
}
-static enum drm_task_status
+static enum drm_gpu_sched_stat
v3d_bin_job_timedout(struct drm_sched_job *sched_job)
{
struct v3d_bin_job *job = to_bin_job(sched_job);
@@ -321,7 +321,7 @@ v3d_bin_job_timedout(struct drm_sched_job *sched_job)
>timedout_ctca, >timedout_ctra);
}
-static enum drm_task_status
+static enum drm_gpu_sched_stat
v3d_render_job_timedout(struct drm_sched_job *sched_job)
{
struct v3d_render_job *job = to_render_job(sched_job);
@@ -330,7 +330,7 @@ v3d_render_job_timedout(struct drm_sched_job *sched_job)
>timedout_ctca, >timedout_ctra);
}
-static enum drm_task_status
+static enum drm_gpu_sched_stat
v3d_generic_job_timedout(struct drm_sched_job *sched_job)
{
struct v3d_job *job = to_v3d_job(sched_job);
@@ -338,7 +338,7 @@ v3d_generic_job_timedout(struct drm_sched_job *sched_job)
return v3d_gpu_reset_for_timeout(job->v3d, sched_job);
}
-static enum drm_task_status
+static enum drm_gpu_sched_stat
v3d_csd_job_timedout(struct drm_sched_job *sched_job)
{
struct v3d_csd_job *job = to_csd_job(sched_job);
--
2.30.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 16/19] drm/amd/display: Change function decide_dp_link_settings to avoid infinite looping
From: Bing Guo [ Upstream commit 4716a7c50c5c66d6ddc42401e1e0ba13b492e105 ] Why: Function decide_dp_link_settings() loops infinitely when required bandwidth can't be supported. How: Check the required bandwidth against verified_link_cap before trying to find a link setting for it. Tested-by: Daniel Wheeler Signed-off-by: Bing Guo Reviewed-by: Jun Lei Acked-by: Anson Jacob Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c index 959eb075d11ed..c18f39271b034 100644 --- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c @@ -1914,6 +1914,9 @@ static bool decide_dp_link_settings(struct dc_link *link, struct dc_link_setting initial_link_setting; uint32_t link_bw; + if (req_bw > dc_link_bandwidth_kbps(link, >verified_link_cap)) + return false; + /* search for the minimum link setting that: * 1. is supported according to the link training result * 2. could support the b/w requested by the timing -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 15/19] drm/amd/display: Update dram_clock_change_latency for DCN2.1
From: Jake Wang
[ Upstream commit 901c1ec05ef277ce9d43cb806a225b28b3efe89a ]
[WHY]
dram clock change latencies get updated using ddr4 latency table, but
does that update does not happen before validation. This value
should not be the default and should be number received from
df for better mode support.
This may cause a PState hang on high refresh panels with short vblanks
such as on 1080p 360hz or 300hz panels.
[HOW]
Update latency from 23.84 to 11.72.
Signed-off-by: Sung Lee
Reviewed-by: Tony Cheng
Acked-by: Aurabindo Pillai
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
index bb7add5ea2273..a6d5beada6634 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
@@ -257,7 +257,7 @@ struct _vcs_dpi_soc_bounding_box_st dcn2_1_soc = {
.num_banks = 8,
.num_chans = 4,
.vmm_page_size_bytes = 4096,
- .dram_clock_change_latency_us = 23.84,
+ .dram_clock_change_latency_us = 11.72,
.return_bus_width_bytes = 64,
.dispclk_dppclk_vco_speed_mhz = 3600,
.xfc_bus_transport_time_us = 4,
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.10 32/41] drm/amd/display: Use hardware sequencer functions for PG control
From: Nicholas Kazlauskas
[ Upstream commit c74f865f14318217350aa33363577cb95b06eb82 ]
[Why & How]
These can differ per ASIC or not be present. Don't call the dcn20 ones
directly but rather the ones defined by the ASIC init table.
Tested-by: Daniel Wheeler
Signed-off-by: Nicholas Kazlauskas
Reviewed-by: Eric Yang
Acked-by: Anson Jacob
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
.../amd/display/dc/dcn10/dcn10_hw_sequencer.c | 18 ++
.../gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c | 9 +++--
2 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
index d0f3bf953d027..0d1e7b56fb395 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
@@ -646,8 +646,13 @@ static void power_on_plane(
if (REG(DC_IP_REQUEST_CNTL)) {
REG_SET(DC_IP_REQUEST_CNTL, 0,
IP_REQUEST_EN, 1);
- hws->funcs.dpp_pg_control(hws, plane_id, true);
- hws->funcs.hubp_pg_control(hws, plane_id, true);
+
+ if (hws->funcs.dpp_pg_control)
+ hws->funcs.dpp_pg_control(hws, plane_id, true);
+
+ if (hws->funcs.hubp_pg_control)
+ hws->funcs.hubp_pg_control(hws, plane_id, true);
+
REG_SET(DC_IP_REQUEST_CNTL, 0,
IP_REQUEST_EN, 0);
DC_LOG_DEBUG(
@@ -1079,8 +1084,13 @@ void dcn10_plane_atomic_power_down(struct dc *dc,
if (REG(DC_IP_REQUEST_CNTL)) {
REG_SET(DC_IP_REQUEST_CNTL, 0,
IP_REQUEST_EN, 1);
- hws->funcs.dpp_pg_control(hws, dpp->inst, false);
- hws->funcs.hubp_pg_control(hws, hubp->inst, false);
+
+ if (hws->funcs.dpp_pg_control)
+ hws->funcs.dpp_pg_control(hws, dpp->inst, false);
+
+ if (hws->funcs.hubp_pg_control)
+ hws->funcs.hubp_pg_control(hws, hubp->inst, false);
+
dpp->funcs->dpp_reset(dpp);
REG_SET(DC_IP_REQUEST_CNTL, 0,
IP_REQUEST_EN, 0);
diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c
b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c
index 01530e686f437..f1e9b3b06b924 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c
@@ -1069,8 +1069,13 @@ static void dcn20_power_on_plane(
if (REG(DC_IP_REQUEST_CNTL)) {
REG_SET(DC_IP_REQUEST_CNTL, 0,
IP_REQUEST_EN, 1);
- dcn20_dpp_pg_control(hws, pipe_ctx->plane_res.dpp->inst, true);
- dcn20_hubp_pg_control(hws, pipe_ctx->plane_res.hubp->inst,
true);
+
+ if (hws->funcs.dpp_pg_control)
+ hws->funcs.dpp_pg_control(hws,
pipe_ctx->plane_res.dpp->inst, true);
+
+ if (hws->funcs.hubp_pg_control)
+ hws->funcs.hubp_pg_control(hws,
pipe_ctx->plane_res.hubp->inst, true);
+
REG_SET(DC_IP_REQUEST_CNTL, 0,
IP_REQUEST_EN, 0);
DC_LOG_DEBUG(
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.10 31/41] drm/amd/display: Change function decide_dp_link_settings to avoid infinite looping
From: Bing Guo [ Upstream commit 4716a7c50c5c66d6ddc42401e1e0ba13b492e105 ] Why: Function decide_dp_link_settings() loops infinitely when required bandwidth can't be supported. How: Check the required bandwidth against verified_link_cap before trying to find a link setting for it. Tested-by: Daniel Wheeler Signed-off-by: Bing Guo Reviewed-by: Jun Lei Acked-by: Anson Jacob Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c index 98464886341f6..004e2b32e02fa 100644 --- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c @@ -2375,6 +2375,9 @@ static bool decide_dp_link_settings(struct dc_link *link, struct dc_link_setting initial_link_setting; uint32_t link_bw; + if (req_bw > dc_link_bandwidth_kbps(link, >verified_link_cap)) + return false; + /* search for the minimum link setting that: * 1. is supported according to the link training result * 2. could support the b/w requested by the timing -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.10 33/41] drm/amd/display: Fixed corruptions on HPDRX link loss restore
From: Vladimir Stempen
[ Upstream commit 4b08d8c78360241d270396a9de6eb774e88acd00 ]
[why]
Heavy corruption or blank screen reported on wake,
with 6k display connected and FEC enabled
[how]
When Disable/Enable stream for display pipes on HPDRX,
DC should take into account ODM split pipes.
Tested-by: Daniel Wheeler
Signed-off-by: Vladimir Stempen
Reviewed-by: Aric Cyr
Acked-by: Anson Jacob
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
index 004e2b32e02fa..17e6fd8201395 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
@@ -3023,14 +3023,14 @@ bool dc_link_handle_hpd_rx_irq(struct dc_link *link,
union hpd_irq_data *out_hpd
for (i = 0; i < MAX_PIPES; i++) {
pipe_ctx =
>dc->current_state->res_ctx.pipe_ctx[i];
if (pipe_ctx && pipe_ctx->stream &&
!pipe_ctx->stream->dpms_off &&
- pipe_ctx->stream->link == link)
+ pipe_ctx->stream->link == link &&
!pipe_ctx->prev_odm_pipe)
core_link_disable_stream(pipe_ctx);
}
for (i = 0; i < MAX_PIPES; i++) {
pipe_ctx =
>dc->current_state->res_ctx.pipe_ctx[i];
if (pipe_ctx && pipe_ctx->stream &&
!pipe_ctx->stream->dpms_off &&
- pipe_ctx->stream->link == link)
+ pipe_ctx->stream->link == link &&
!pipe_ctx->prev_odm_pipe)
core_link_enable_stream(link->dc->current_state, pipe_ctx);
}
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.10 30/41] drm/amd/display: Allow PSTATE chnage when no displays are enabled
From: Aric Cyr
[ Upstream commit 8bc3d461d0a95bbcc2a0a908bbadc87e198a86a8 ]
[Why]
When no displays are currently enabled, display driver should not
disallow PSTATE switching.
[How]
Allow PSTATE switching if either the active configuration supports it,
or there are no active displays.
Tested-by: Daniel Wheeler
Signed-off-by: Aric Cyr
Reviewed-by: Jun Lei
Acked-by: Anson Jacob
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
.../gpu/drm/amd/display/dc/clk_mgr/dcn30/dcn30_clk_mgr.c| 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn30/dcn30_clk_mgr.c
b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn30/dcn30_clk_mgr.c
index b0e9b0509568c..95d883482227e 100644
--- a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn30/dcn30_clk_mgr.c
+++ b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn30/dcn30_clk_mgr.c
@@ -239,6 +239,7 @@ static void dcn3_update_clocks(struct clk_mgr *clk_mgr_base,
struct dmcu *dmcu = clk_mgr_base->ctx->dc->res_pool->dmcu;
bool force_reset = false;
bool update_uclk = false;
+ bool p_state_change_support;
if (dc->work_arounds.skip_clock_update || !clk_mgr->smu_present)
return;
@@ -279,8 +280,9 @@ static void dcn3_update_clocks(struct clk_mgr *clk_mgr_base,
clk_mgr_base->clks.socclk_khz = new_clocks->socclk_khz;
clk_mgr_base->clks.prev_p_state_change_support =
clk_mgr_base->clks.p_state_change_support;
- if (should_update_pstate_support(safe_to_lower,
new_clocks->p_state_change_support, clk_mgr_base->clks.p_state_change_support))
{
- clk_mgr_base->clks.p_state_change_support =
new_clocks->p_state_change_support;
+ p_state_change_support = new_clocks->p_state_change_support ||
(display_count == 0);
+ if (should_update_pstate_support(safe_to_lower, p_state_change_support,
clk_mgr_base->clks.p_state_change_support)) {
+ clk_mgr_base->clks.p_state_change_support =
p_state_change_support;
/* to disable P-State switching, set UCLK min = max */
if (!clk_mgr_base->clks.p_state_change_support)
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.10 29/41] drm/amd/display: Update dram_clock_change_latency for DCN2.1
From: Jake Wang
[ Upstream commit 901c1ec05ef277ce9d43cb806a225b28b3efe89a ]
[WHY]
dram clock change latencies get updated using ddr4 latency table, but
does that update does not happen before validation. This value
should not be the default and should be number received from
df for better mode support.
This may cause a PState hang on high refresh panels with short vblanks
such as on 1080p 360hz or 300hz panels.
[HOW]
Update latency from 23.84 to 11.72.
Signed-off-by: Sung Lee
Reviewed-by: Tony Cheng
Acked-by: Aurabindo Pillai
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
index e73785e74cba8..20441127783ba 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
@@ -295,7 +295,7 @@ struct _vcs_dpi_soc_bounding_box_st dcn2_1_soc = {
.num_banks = 8,
.num_chans = 4,
.vmm_page_size_bytes = 4096,
- .dram_clock_change_latency_us = 23.84,
+ .dram_clock_change_latency_us = 11.72,
.return_bus_width_bytes = 64,
.dispclk_dppclk_vco_speed_mhz = 3600,
.xfc_bus_transport_time_us = 4,
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4, 03/10] soc: mediatek: mmsys: move register operation into mmsys path select function
On 21/01/2021 01:56, Yongqiang Niu wrote:
> On Wed, 2021-01-20 at 20:38 +0100, Matthias Brugger wrote:
>> On Tue, Jan 05, 2021 at 11:06:26AM +0800, Yongqiang Niu wrote:
>>> move register operation into mmsys path select function
>>
>> Why do you want to do that. It seems the register access pattern is the
>> same for all SoCs so far supported, so I don't see the need to duplicate
>> the code in every SoC.
>>
>> Regards,
>> Matthias
>
> mt2701 and mt8173 ovl mout en already different.
> mt2701 ovl mout en register offset is 0x30
> mt8173 olv mout en register offset is 0x40
>
> only the use case is different;
> mt2701 ovl->color0
> mt8173 ovl->rmda0
> there make different define for this different.
>
> #define DISP_REG_CONFIG_DISP_OVL0_MOUT_EN 0x040
>
> #define DISP_REG_CONFIG_DISP_OVL_MOUT_EN 0x030
>
> for the future mt8183, ovl mout en register offset will change to
> 0xf00
>
> this is only one different sample, there will be more and more
> different, so we add this patch for different soc
>
>
That does not explain why you want to put the read and write calls in a per SoC
part, they are the same for all supported SoCs.
Anyway after having a second thought, I don't like this approach at all. I think
splitting up the code in several SoCs to not bloat the driver is a good thing,
but not as it is done in this series.
I'd prefer to use a lookup table as Enric did in his first approach [1]. We
could then add this table in a per SoC header file.
Regards,
Matthias
https://patchwork.kernel.org/project/linux-mediatek/patch/20201006193320.405529-5-enric.balle...@collabora.com/
>>
>>>
>>> Signed-off-by: Yongqiang Niu
>>> ---
>>> drivers/soc/mediatek/mmsys/mtk-mmsys.c | 140
>>> +
>>> 1 file changed, 71 insertions(+), 69 deletions(-)
>>>
>>> diff --git a/drivers/soc/mediatek/mmsys/mtk-mmsys.c
>>> b/drivers/soc/mediatek/mmsys/mtk-mmsys.c
>>> index 6c03282..64c8030 100644
>>> --- a/drivers/soc/mediatek/mmsys/mtk-mmsys.c
>>> +++ b/drivers/soc/mediatek/mmsys/mtk-mmsys.c
>>> @@ -106,141 +106,161 @@ struct mtk_mmsys {
>>> .clk_driver = "clk-mt8183-mm",
>>> };
>>>
>>> -static unsigned int mtk_mmsys_ddp_mout_en(enum mtk_ddp_comp_id cur,
>>> - enum mtk_ddp_comp_id next,
>>> - unsigned int *addr)
>>> +static void mtk_mmsys_ddp_mout_en(void __iomem *config_regs,
>>> + enum mtk_ddp_comp_id cur,
>>> + enum mtk_ddp_comp_id next,
>>> + bool enable)
>>> {
>>> - unsigned int value;
>>> + unsigned int addr, value, reg;
>>>
>>> if (cur == DDP_COMPONENT_OVL0 && next == DDP_COMPONENT_COLOR0) {
>>> - *addr = DISP_REG_CONFIG_DISP_OVL0_MOUT_EN;
>>> + addr = DISP_REG_CONFIG_DISP_OVL0_MOUT_EN;
>>> value = OVL0_MOUT_EN_COLOR0;
>>> } else if (cur == DDP_COMPONENT_OVL0 && next == DDP_COMPONENT_RDMA0) {
>>> - *addr = DISP_REG_CONFIG_DISP_OVL_MOUT_EN;
>>> + addr = DISP_REG_CONFIG_DISP_OVL_MOUT_EN;
>>> value = OVL_MOUT_EN_RDMA;
>>> } else if (cur == DDP_COMPONENT_OD0 && next == DDP_COMPONENT_RDMA0) {
>>> - *addr = DISP_REG_CONFIG_DISP_OD_MOUT_EN;
>>> + addr = DISP_REG_CONFIG_DISP_OD_MOUT_EN;
>>> value = OD_MOUT_EN_RDMA0;
>>> } else if (cur == DDP_COMPONENT_UFOE && next == DDP_COMPONENT_DSI0) {
>>> - *addr = DISP_REG_CONFIG_DISP_UFOE_MOUT_EN;
>>> + addr = DISP_REG_CONFIG_DISP_UFOE_MOUT_EN;
>>> value = UFOE_MOUT_EN_DSI0;
>>> } else if (cur == DDP_COMPONENT_OVL1 && next == DDP_COMPONENT_COLOR1) {
>>> - *addr = DISP_REG_CONFIG_DISP_OVL1_MOUT_EN;
>>> + addr = DISP_REG_CONFIG_DISP_OVL1_MOUT_EN;
>>> value = OVL1_MOUT_EN_COLOR1;
>>> } else if (cur == DDP_COMPONENT_GAMMA && next == DDP_COMPONENT_RDMA1) {
>>> - *addr = DISP_REG_CONFIG_DISP_GAMMA_MOUT_EN;
>>> + addr = DISP_REG_CONFIG_DISP_GAMMA_MOUT_EN;
>>> value = GAMMA_MOUT_EN_RDMA1;
>>> } else if (cur == DDP_COMPONENT_OD1 && next == DDP_COMPONENT_RDMA1) {
>>> - *addr = DISP_REG_CONFIG_DISP_OD_MOUT_EN;
>>> + addr = DISP_REG_CONFIG_DISP_OD_MOUT_EN;
>>> value = OD1_MOUT_EN_RDMA1;
>>> } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DPI0) {
>>> - *addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
>>> + addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
>>> value = RDMA0_SOUT_DPI0;
>>> } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DPI1) {
>>> - *addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
>>> + addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
>>> value = RDMA0_SOUT_DPI1;
>>> } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DSI1) {
>>> - *addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
>>> + addr =
Re: [PATCH 3/5] drm/gma500: Drop DRM_GMA3600 config option
On Fri, Jan 29, 2021 at 4:12 PM Thomas Zimmermann wrote: > > Hi Patrik > > Am 29.01.21 um 15:33 schrieb Patrik Jakobsson: > > On Fri, Jan 29, 2021 at 10:56 AM Thomas Zimmermann > > wrote: > >> > >> With support for the MID-related chips removed, only support for > >> desktop chips is left in the driver. So just build the complete > >> driver if DRM_GMA500 has been selected. Anyone who wants to enable > >> the Poulsbo code would probably also want the Cedarview code. > >> > >> Signed-off-by: Thomas Zimmermann > > > > As GMA600 is staying, can you please also merge that config? > > By 'merge that config', you mean to removed CONFIG_DRM_GMA600 and > configure everything with DRM_GMA500? Yes. No point in keeping it around when config for GMA3600 goes away. > > Best regards > Thomas > > > > > -Patrik > > ___ > > dri-devel mailing list > > dri-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > > -- > Thomas Zimmermann > Graphics Driver Developer > SUSE Software Solutions Germany GmbH > Maxfeldstr. 5, 90409 Nürnberg, Germany > (HRB 36809, AG Nürnberg) > Geschäftsführer: Felix Imendörffer > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 11/14] drm/amdgpu: Guard against write accesses after device removal
Am 28.01.21 um 18:23 schrieb Andrey Grodzovsky: On 1/19/21 1:59 PM, Christian König wrote: Am 19.01.21 um 19:22 schrieb Andrey Grodzovsky: On 1/19/21 1:05 PM, Daniel Vetter wrote: [SNIP] So say writing in a loop to some harmless scratch register for many times both for plugged and unplugged case and measure total time delta ? I think we should at least measure the following: 1. Writing X times to a scratch reg without your patch. 2. Writing X times to a scratch reg with your patch. 3. Writing X times to a scratch reg with the hardware physically disconnected. I suggest to repeat that once for Polaris (or older) and once for Vega or Navi. The SRBM on Polaris is meant to introduce some delay in each access, so it might react differently then the newer hardware. Christian. See attached results and the testing code. Ran on Polaris (gfx8) and Vega10(gfx9) In summary, over 1 million WWREG32 in loop with and without this patch you get around 10ms of accumulated overhead ( so 0.1 millisecond penalty for each WWREG32) for using drm_dev_enter check when writing registers. P.S Bullet 3 I cannot test as I need eGPU and currently I don't have one. Well if I'm not completely mistaken that are 100ms of accumulated overhead. So around 100ns per write. And even bigger problem is that this is a ~67% increase. I'm not sure how many write we do during normal operation, but that sounds like a bit much. Ideas? Christian. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/5] drm/gma500: Drop DRM_GMA3600 config option
Hi Patrik Am 29.01.21 um 15:33 schrieb Patrik Jakobsson: On Fri, Jan 29, 2021 at 10:56 AM Thomas Zimmermann wrote: With support for the MID-related chips removed, only support for desktop chips is left in the driver. So just build the complete driver if DRM_GMA500 has been selected. Anyone who wants to enable the Poulsbo code would probably also want the Cedarview code. Signed-off-by: Thomas Zimmermann As GMA600 is staying, can you please also merge that config? By 'merge that config', you mean to removed CONFIG_DRM_GMA600 and configure everything with DRM_GMA500? Best regards Thomas -Patrik ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer OpenPGP_signature Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/5] drm/gma500: Remove CONFIG_X86 conditionals from source files
On Fri, Jan 29, 2021 at 10:56 AM Thomas Zimmermann wrote: > > Remove the CONFIG_X86 conditionals from the source code. The driver > already depends on X86 in the Kconfig file. Also, no one has been > trying to build it on a non-x86 platform recently, or they would have > noticed that drm_ttm_cache_flush() doesn't exist. > > Signed-off-by: Thomas Zimmermann Thanks! Signed-off-by: Patrik Jakobsson ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/5] drm/gma500: Remove dependency on TTM
On Fri, Jan 29, 2021 at 10:56 AM Thomas Zimmermann wrote: > > The gma500 driver does not use TTM. > > Signed-off-by: Thomas Zimmermann Thanks! Signed-off-by: Patrik Jakobsson > --- > drivers/gpu/drm/gma500/Kconfig | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/gpu/drm/gma500/Kconfig b/drivers/gpu/drm/gma500/Kconfig > index 02de5970d490..405f718b884c 100644 > --- a/drivers/gpu/drm/gma500/Kconfig > +++ b/drivers/gpu/drm/gma500/Kconfig > @@ -3,7 +3,6 @@ config DRM_GMA500 > tristate "Intel GMA500/3600/3650 KMS Framebuffer" > depends on DRM && PCI && X86 && MMU > select DRM_KMS_HELPER > - select DRM_TTM > # GMA500 depends on ACPI_VIDEO when ACPI is enabled, just like i915 > select ACPI_VIDEO if ACPI > select BACKLIGHT_CLASS_DEVICE if ACPI > -- > 2.30.0 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/5] drm/gma500: Drop DRM_GMA3600 config option
On Fri, Jan 29, 2021 at 10:56 AM Thomas Zimmermann wrote: > > With support for the MID-related chips removed, only support for > desktop chips is left in the driver. So just build the complete > driver if DRM_GMA500 has been selected. Anyone who wants to enable > the Poulsbo code would probably also want the Cedarview code. > > Signed-off-by: Thomas Zimmermann As GMA600 is staying, can you please also merge that config? -Patrik ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/5] drm/gma500: Remove Moorestown support
On Fri, Jan 29, 2021 at 10:56 AM Thomas Zimmermann wrote: > > Moorestown is an outdated mobile platform with apparently no users > left. Remove it from gma500. The MID chip-setup code in mid_bios.c > is now unused, so remove it as well. > > Signed-off-by: Thomas Zimmermann As stated earlier. This code must stay since Oaktrail is still supported. Perhaps there are still MRST specifics that can be removed. Let's have a look. -Patrik ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v12] staging: fbtft: add tearing signal detect
On Fri, Jan 29, 2021 at 3:56 PM carlis wrote:
> On Fri, 29 Jan 2021 12:23:08 +0200
> Andy Shevchenko wrote:
We are almost there, I have no idea what Noralf or others are going to
say though.
...
> Hi, I apologize for what I said in the previous two emails. I missed
> one email you sent before, and now I probably understand what you
> meant. Here is a version I modified according to your suggestion:
>
> From 399e7fb91d1dcba4924cd38cc8283393c80b97e4 Mon Sep 17 00:00:00 2001
> From: Carlis
> Date: Sun, 24 Jan 2021 22:43:21 +0800
> Subject: [PATCH v13] staging: fbtft: add tearing signal detect
>
> For st7789v IC,when we need continuous full screen refresh, it is best
Missed space after comma.
> to wait for the tearing effect line signal arrive to avoid screen
to arrive
> tearing.
...
> +#define PANEL_TE_TIMEOUT_MS 34 /* 60Hz for 16.6ms, configured as
> 2*16.6ms */ +
Move comment before the definition
/* comment */
#define DEFINITION
Also consider to use 33 ms as closest to what you mentioned in the comment.
Or leave it with mention that you are using ceil() value.
...
> +/**
> + * init_tearing_effect_line() - init tearing effect line
> + *
As per a few previous reviews.
Okay, I have noticed that the existing kernel-doc is written like
this, but it doesn't prevent you from avoiding this little mistake.
> + * @par: FBTFT parameter object
> + *
> + * Return: 0 on success, or a negative error code otherwise.
> + */
> +static int init_tearing_effect_line(struct fbtft_par *par)
> +{
> + struct device *dev = par->info->device;
> + struct gpio_desc *te;
> + int rc;
> +
> + te = gpiod_get_optional(dev, "te", GPIOD_IN);
> + if (IS_ERR(te))
> + return dev_err_probe(dev, PTR_ERR(te), "Failed to
> request te GPIO\n"); +
Below is okay, but needs a comment explaining why we return a success.
> + if (!te)
> + return 0;
> +
> + par->irq_te = gpiod_to_irq(te);
> +
> + /* GPIO is locked as an IRQ, we may drop the reference */
> + gpiod_put(te);
> +
> + if (par->irq_te < 0)
> + return par->irq_te;
I recommend using a temporary variable. In such a case you won't need
to specifically check for negative error code. So, something like
int irq;
irq = ...
if (irq < 0)
return irq;
->irq_te = irq;
> + init_completion(>panel_te);
> + rc = devm_request_irq(dev, par->irq_te, panel_te_handler,
> + IRQF_TRIGGER_RISING, "TE_GPIO", par);
Right. Now it needs a comment explaining the choice of rising edge type of IRQ.
> + if (rc)
> + return dev_err_probe(dev, rc, "TE IRQ request
> failed.\n"); +
> + disable_irq_nosync(par->irq_te);
> +
> + return 0;
> +}
...
> + rc = init_tearing_effect_line(par);
> + if (rc < 0)
Here is no need to specifically check against less than 0,
if (ret)
will work nicely.
> + return rc;
...
> + if (par->irq_te)
> + write_reg(par, MIPI_DCS_SET_TEAR_ON, 0x00);
Do you need to call MIPI_DCS_SET_TEAR_SCANLINE in this case?
Alos, when there is no IRQ, shouldn't we explicitly call
write_reg(par, MIPI_DCS_SET_TEAR_OFF);
?
...
> /**
> + * st7789v_write_vmem16_bus8() - write data to display
> + *
Redundant.
> + * @par: FBTFT parameter object
> + * @offset: offset from screen_buffer
> + * @len: the length of data to be written
> + *
> + * 16 bit pixel over 8-bit databus
Write 16-bit pixels over 8-bit data bus.
> + * Return: 0 on success, or a negative error code otherwise.
> + */
...
> + if (par->irq_te) {
> + enable_irq(par->irq_te);
> + reinit_completion(>panel_te);
> + ret = wait_for_completion_timeout(>panel_te,
> +
> msecs_to_jiffies(PANEL_TE_TIMEOUT_MS));
> + if (ret == 0)
> + dev_err(dev, "wait panel TE time out\n");
timeout
> +
> + disable_irq(par->irq_te);
> + }
...
> + * @panel_te: completion for panel te line
TE line
> + * @irq_te: LCD Chip tearing effect line
"Linux IRQ for LCD..."
--
With Best Regards,
Andy Shevchenko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/5] drm/gma500: Remove Medfield support
On Fri, Jan 29, 2021 at 10:56 AM Thomas Zimmermann wrote: > > Medfield is an outdated mobile platform with apparently no users left. > Remove it from gma500. > > Signed-off-by: Thomas Zimmermann Great, finally we get rid of that DSI code :) Signed-off-by: Patrik Jakobsson ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] procfs/dmabuf: Add /proc//task//dmabuf_fds
Am 29.01.21 um 15:17 schrieb Simon Ser: On Friday, January 29th, 2021 at 3:13 PM, Pekka Paalanen wrote: Re-importing it adds quite a huge CPU overhead to both userspace as well as the kernel. Perhaps, but so far it seems no-one has noticed the overhead, with Mesa at least. I happily stand corrected. Note, all of this doesn't mean that compositors will stop keeping DMA-BUF FDs around. They may want to keep them open for other purposes like importing them into KMS or other EGL displays as needed. Correct and that's a perfectly valid use case. Just re-importing it on every frame is something we should really try to avoid. At least with debugging enabled it's massive overhead and maybe even performance penalty when we have to re-create device page tables all the time. But thinking more about that it is possible that we short-cut this step as long as the original import was still referenced. Otherwise we probably would have noticed this much earlier. Regards, Christian. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] procfs/dmabuf: Add /proc//task//dmabuf_fds
On Friday, January 29th, 2021 at 3:13 PM, Pekka Paalanen wrote: > > Re-importing it adds quite a huge CPU overhead to both userspace as well > > as the kernel. > > Perhaps, but so far it seems no-one has noticed the overhead, with Mesa > at least. > > I happily stand corrected. Note, all of this doesn't mean that compositors will stop keeping DMA-BUF FDs around. They may want to keep them open for other purposes like importing them into KMS or other EGL displays as needed. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] procfs/dmabuf: Add /proc//task//dmabuf_fds
On Fri, 29 Jan 2021 13:18:01 +0100 Christian König wrote: > Am 28.01.21 um 11:01 schrieb Pekka Paalanen: > > On Wed, 27 Jan 2021 12:01:55 +0100 > > Christian König wrote: > > > >> Somewhat correct. This interface here really doesn't make sense since > >> the file descriptor representation of DMA-buf is only meant to be used > >> for short term usage. > >> > >> E.g. the idea is that you can export a DMA-buf fd from your device > >> driver, transfer that to another process and then import it again into a > >> device driver. > >> > >> Keeping a long term reference to a DMA-buf fd sounds like a design bug > >> in userspace to me. > > Except keeping the fd is exactly what userspace must do if it wishes to > > re-use the buffer without passing a new fd over IPC again. Particularly > > Wayland compositors need to keep the client buffer dmabuf fd open after > > receiving it, so that they can re-import it to EGL to ensure updated > > contents are correctly flushed as EGL has no other API for it. > > Hui what??? I'm not that deep into the EGL specification, but from the > kernel side that is utterly nonsense. > > Could be that re-importing triggers something in userspace, but this > sounds strongly like a workaround to me which shouldn't be necessary. Hi, there was a pretty long discussion about exactly this on #dri-devel today, starting at 12:30: https://people.freedesktop.org/~cbrill/dri-log/index.php?channel=dri-devel_names==2021-01-29 The conclusion is that indeed, it is no longer necessary to re-import to EGL all the time. It should be enough (at least with all Mesa drivers) to call glEGLImageTargetTexture2DOES() every time you want to ensure you get the updated buffer contents. So now people across various projects are thinking how to keep the EGLImage and not re-import on every update. > > That is my vague understanding, and what Weston implements. You can say > > it's a bad userspace API design in EGL, but what else can we do? > > Please open up a bug report with your EGL driver if that is really > necessary. Sure, I would hope there is no such case anymore. > DMA-bufs shared using a file descriptor should be coherent when > written/read from a GPU or other hardware device. What is possible is > that you need to do something special for CPU access. > > In other words once a DMA-buf is imported and available as > handle/texture/image inside EGL it doesn't needs to be flushed/synced > explicitly again. There is still the case where the some GL drivers sometimes need to make a copy when turning the dmabuf into a GL texture[IRC log]. But indeed, that seems to be not EGL's concern. > > Re-importing it adds quite a huge CPU overhead to both userspace as well > as the kernel. Perhaps, but so far it seems no-one has noticed the overhead, with Mesa at least. I happily stand corrected. Thanks, pq pgpHXZI5kTimj.pgp Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v12] staging: fbtft: add tearing signal detect
On Fri, Jan 29, 2021 at 2:54 PM carlis wrote: > On Fri, 29 Jan 2021 12:23:08 +0200 > Andy Shevchenko wrote: > > On Fri, Jan 29, 2021 at 7:01 AM carlis wrote: > > > On Thu, 28 Jan 2021 16:33:02 +0200 > > > Andy Shevchenko wrote: ... > > This one is not like I suggested. > I don't think I have a problem here, if te GPIO is not configured, it > should return NULL, if it is configured, it should be greater than 0 Pointers are always greater than 0 or a special NULL case. The rationale I explained in the previous mail. ... > > > rc = devm_request_irq(dev, > > > par->irq_te, > > > panel_te_handler, > > > IRQF_TRIGGER_RISING, > > > "TE_GPIO", par); > > > > Try to use less LOCs. > > LOCs i can not get you Lines Of Code. Above can occupy less LOCs. -- With Best Regards, Andy Shevchenko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v12] staging: fbtft: add tearing signal detect
On Fri, Jan 29, 2021 at 2:47 PM carlis wrote:
> On Fri, 29 Jan 2021 12:23:08 +0200
> Andy Shevchenko wrote:
> > On Fri, Jan 29, 2021 at 7:01 AM carlis wrote:
> > > On Thu, 28 Jan 2021 16:33:02 +0200
> > > Andy Shevchenko wrote:
> > > > On Thu, Jan 28, 2021 at 2:58 PM Carlis
> > > > wrote:
...
> > Please, go again thru my comments and comments from others and
> > carefully address all of them everywhere in your contribution. If you
> > have questions, ask them in reply in the corresponding context.
...
> > > /**
> > > * init_tearing_effect_line() - init tearing effect line
> >
> > > *
> >
> > For example, above was commented on and hasn't been addressed here.
> >
> hi,here i can not get you.
The above is a blank line which is redundant. It also applied to the
other function in the code.
> > > * @par: FBTFT parameter object
> > > *
> > > * Return: 0 on success, < 0 if error occurred.
> > > */
> > > static int init_tearing_effect_line(struct fbtft_par *par)
> > > {
> > > struct device *dev = par->info->device;
> > > struct gpio_desc *te;
> > > int rc;
> > >
> > > te = gpiod_get_optional(dev, "te", GPIOD_IN);
> > > if (IS_ERR(te))
> > > return dev_err_probe(dev, PTR_ERR(te), "Failed to
> > > request te GPIO\n");
> > >
> >
> > > if (te) {
> >
> > This one is not like I suggested.
> Why? My thinking is that if the TE is not configured and NULL is
> returned, the initialization can still proceed.
I have suggested to bail out immediately. It will reduce an
indentation level on the below code.
> > > par->irq_te = gpiod_to_irq(te);
> > > gpiod_put(te);
> > >
> >
> > > if (par->irq_te) {
> >
> > This is wrong.
>
> Why? i have read gpiod_to_irq code, if an error occurs, a negative
> value is returned, and zero is not possible,so I need this value to
> determine if TE IRQ is configured
It returns two possible cases:
- error code (when negative)
- Linux IRQ number otherwise
You check makes a no-op since in either variant it will proceed to the
request of IRQ, which is wrong in an error case.
> > > rc = devm_request_irq(dev,
> > > par->irq_te,
> > > panel_te_handler,
> > > IRQF_TRIGGER_RISING,
> > > "TE_GPIO", par);
> >
> > Try to use less LOCs.
> >
> > > if (rc)
> > > return dev_err_probe(dev, rc, "TE
> > > IRQ request failed.\n");
> > >
> > > disable_irq_nosync(par->irq_te);
> > > init_completion(>panel_te);
> >
> > > } else {
> > > return dev_err_probe(dev, par->irq_te,
> > > "gpiod to TE IRQ failed.\n");
> > > }
> >
> > Again, it is not what had been suggested.
> >
> > > }
--
With Best Regards,
Andy Shevchenko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/i915/display: Make vlv_find_free_pps() skip pipes which are in use for non DP purposes
As explained by a long comment block, on VLV intel_setup_outputs() sometimes thinks there might be an eDP panel connected while there is none. In this case intel_setup_outputs() will call intel_dp_init() to check. In this scenario vlv_find_free_pps() ends up selecting pipe A for the pps, even though this might be in use for non DP purposes. When this is the case then the assert_pipe() in vlv_force_pll_on() will fail when called from vlv_power_sequencer_kick(). This happens on a Voyo winpad A15, leading to the following WARN/backtrace: [8.661531] [ cut here ] [8.661590] transcoder A assertion failure (expected off, current on) [8.661647] WARNING: CPU: 2 PID: 243 at drivers/gpu/drm/i915/display/intel_display.c:1288 assert_pipe+0x125/0xc20 [i915] [8.661822] Modules linked in: i915(E+) mmc_block crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel i2c_algo_bit drm_kms_helper cec drm drm_privacy_screen_helper video(E) sdhci_acpi sdhci i2c_hid pwm_lpss_platform pwm_lpss mmc_core i2c_dev fuse [8.661944] CPU: 2 PID: 243 Comm: systemd-udevd Tainted: GE 5.11.0-rc5+ #228 [8.661954] Hardware name: To be filled by O.E.M. To be filled by O.E.M./Aptio CRB, BIOS 5.6.5 11/20/2014 [8.661961] RIP: 0010:assert_pipe+0x125/0xc20 [i915] [8.662050] Code: c7 c2 e5 39 4a c0 74 c9 48 c7 c6 53 3b 4a c0 83 fb 06 77 0a 89 db 48 8b 34 dd 80 38 45 c0 48 c7 c7 c8 ff 47 c0 e8 13 6c 8f df <0f> 0b e9 1d ff ff ff 89 db 48 8b 34 dd 80 38 45 c0 eb a0 48 c7 c2 [8.662058] RSP: 0018:a939c0557690 EFLAGS: 00010286 [8.662071] RAX: 0039 RBX: RCX: 89c67bd19058 [8.662078] RDX: ffd8 RSI: 0027 RDI: 89c67bd19050 [8.662085] RBP: 89c64a3c R08: 0001 R09: 0001 [8.662091] R10: a939c05574c0 R11: a0961248 R12: 0009 [8.662098] R13: R14: e000 R15: 89c64a3c [8.662105] FS: 7fe824e42380() GS:89c67bd0() knlGS: [8.662113] CS: 0010 DS: ES: CR0: 80050033 [8.662120] CR2: 7fffdc770558 CR3: 000106ab8000 CR4: 001006e0 [8.662127] Call Trace: [8.662148] assert_pipe+0xa9e/0xc20 [i915] [8.662252] vlv_force_pll_on+0xfb/0x1b0 [i915] [8.662344] intel_dp_sync_state+0xd92/0x2e70 [i915] [8.662448] intel_dp_sync_state+0x1908/0x2e70 [i915] [8.662541] intel_dp_sync_state+0x1a3e/0x2e70 [i915] [8.662620] ? recalibrate_cpu_khz+0x10/0x10 [8.662633] ? ktime_get_with_offset+0xad/0x160 [8.662658] intel_dp_sync_state+0x1f21/0x2e70 [i915] [8.662788] intel_dp_encoder_suspend+0x41f/0x14b0 [i915] [8.662875] ? drm_dp_dpcd_access+0x50/0xf0 [drm_kms_helper] [8.662940] ? __mutex_lock+0x7e/0x7a0 [8.662950] ? drm_dp_dpcd_access+0x50/0xf0 [drm_kms_helper] [8.662982] ? drm_dp_dpcd_access+0x50/0xf0 [drm_kms_helper] [8.663025] intel_dp_encoder_suspend+0xdf3/0x14b0 [i915] [8.663112] ? find_held_lock+0x2b/0x80 [8.663132] drm_dp_dpcd_access+0x62/0xf0 [drm_kms_helper] [8.663181] drm_dp_dpcd_read+0xb6/0xf0 [drm_kms_helper] [8.663223] drm_dp_read_dpcd_caps+0x20/0x110 [drm_kms_helper] [8.663262] intel_dp_init_connector+0x79e/0x1010 [i915] [8.663366] intel_dp_init+0x251/0x480 [i915] [8.663453] intel_modeset_init_nogem+0x1998/0x1b70 [i915] [8.663540] ? intel_pcode_init+0x3b6b/0x5d60 [i915] [8.663625] i915_driver_probe+0x5d5/0xcb0 [i915] [8.663734] ? drm_privacy_screen_get+0x163/0x1a0 [drm_privacy_screen_helper] [8.663759] i915_params_free+0x11a/0x200 [i915] [8.663830] ? __pm_runtime_resume+0x58/0x90 [8.663849] local_pci_probe+0x42/0x80 [8.663869] pci_device_probe+0xd9/0x190 [8.663892] really_probe+0xf2/0x440 [8.663915] driver_probe_device+0xe1/0x150 [8.663930] device_driver_attach+0xa8/0xb0 [8.663948] __driver_attach+0x8c/0x150 [8.663957] ? device_driver_attach+0xb0/0xb0 [8.663966] ? device_driver_attach+0xb0/0xb0 [8.663979] bus_for_each_dev+0x67/0x90 [8.663998] bus_add_driver+0x12e/0x1f0 [8.664015] driver_register+0x8b/0xe0 [8.664025] ? 0xc055a000 [8.664039] init_module+0x62/0x7c [i915] [8.664127] do_one_initcall+0x5b/0x2d0 [8.664143] ? rcu_read_lock_sched_held+0x3f/0x80 [8.664155] ? kmem_cache_alloc_trace+0x292/0x2c0 [8.664178] do_init_module+0x5c/0x260 [8.664194] __do_sys_init_module+0x13d/0x1a0 [8.664247] do_syscall_64+0x33/0x40 [8.664260] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [8.664272] RIP: 0033:0x7fe825d9a6be [8.664284] Code: 48 8b 0d bd 27 0c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 af 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 8a 27 0c 00 f7 d8 64 89 01 48 [8.664293] RSP: 002b:7fffdc778028 EFLAGS: 0246 ORIG_RAX: 00af [
[PATCH 1/2] drm/i915/display: Add a intel_pipe_is_enabled() helper
Factor the code to check if a pipe is currently enabled out of
assert_pipe() and put it in a new intel_pipe_is_enabled() helper,
so that it can be re-used without copy-pasting it.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/display/intel_display.c | 20 ++--
drivers/gpu/drm/i915/display/intel_display.h | 2 ++
2 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 24520f062ff9..f83caceb901b 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -1263,17 +1263,13 @@ void assert_panel_unlocked(struct drm_i915_private
*dev_priv, enum pipe pipe)
pipe_name(pipe));
}
-void assert_pipe(struct drm_i915_private *dev_priv,
-enum transcoder cpu_transcoder, bool state)
+bool intel_pipe_is_enabled(struct drm_i915_private *dev_priv,
+ enum transcoder cpu_transcoder)
{
bool cur_state;
enum intel_display_power_domain power_domain;
intel_wakeref_t wakeref;
- /* we keep both pipes enabled on 830 */
- if (IS_I830(dev_priv))
- state = true;
-
power_domain = POWER_DOMAIN_TRANSCODER(cpu_transcoder);
wakeref = intel_display_power_get_if_enabled(dev_priv, power_domain);
if (wakeref) {
@@ -1285,6 +1281,18 @@ void assert_pipe(struct drm_i915_private *dev_priv,
cur_state = false;
}
+ return cur_state;
+}
+
+void assert_pipe(struct drm_i915_private *dev_priv,
+enum transcoder cpu_transcoder, bool state)
+{
+ bool cur_state = intel_pipe_is_enabled(dev_priv, cpu_transcoder);
+
+ /* we keep both pipes enabled on 830 */
+ if (IS_I830(dev_priv))
+ state = true;
+
I915_STATE_WARN(cur_state != state,
"transcoder %s assertion failure (expected %s, current
%s)\n",
transcoder_name(cpu_transcoder),
diff --git a/drivers/gpu/drm/i915/display/intel_display.h
b/drivers/gpu/drm/i915/display/intel_display.h
index 5e0d42d82c11..be28d9570038 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -523,6 +523,8 @@ void intel_enable_pipe(const struct intel_crtc_state
*new_crtc_state);
void intel_disable_pipe(const struct intel_crtc_state *old_crtc_state);
void i830_enable_pipe(struct drm_i915_private *dev_priv, enum pipe pipe);
void i830_disable_pipe(struct drm_i915_private *dev_priv, enum pipe pipe);
+bool intel_pipe_is_enabled(struct drm_i915_private *dev_priv,
+ enum transcoder cpu_transcoder);
enum pipe intel_crtc_pch_transcoder(struct intel_crtc *crtc);
int vlv_get_hpll_vco(struct drm_i915_private *dev_priv);
int vlv_get_cck_clock(struct drm_i915_private *dev_priv,
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] procfs/dmabuf: Add /proc//task//dmabuf_fds
Am 28.01.21 um 11:01 schrieb Pekka Paalanen: On Wed, 27 Jan 2021 12:01:55 +0100 Christian König wrote: Somewhat correct. This interface here really doesn't make sense since the file descriptor representation of DMA-buf is only meant to be used for short term usage. E.g. the idea is that you can export a DMA-buf fd from your device driver, transfer that to another process and then import it again into a device driver. Keeping a long term reference to a DMA-buf fd sounds like a design bug in userspace to me. Except keeping the fd is exactly what userspace must do if it wishes to re-use the buffer without passing a new fd over IPC again. Particularly Wayland compositors need to keep the client buffer dmabuf fd open after receiving it, so that they can re-import it to EGL to ensure updated contents are correctly flushed as EGL has no other API for it. Hui what??? I'm not that deep into the EGL specification, but from the kernel side that is utterly nonsense. Could be that re-importing triggers something in userspace, but this sounds strongly like a workaround to me which shouldn't be necessary. That is my vague understanding, and what Weston implements. You can say it's a bad userspace API design in EGL, but what else can we do? Please open up a bug report with your EGL driver if that is really necessary. DMA-bufs shared using a file descriptor should be coherent when written/read from a GPU or other hardware device. What is possible is that you need to do something special for CPU access. In other words once a DMA-buf is imported and available as handle/texture/image inside EGL it doesn't needs to be flushed/synced explicitly again. Re-importing it adds quite a huge CPU overhead to both userspace as well as the kernel. However, in the particular case of Wayland, the shared dmabufs should be accounted to the Wayland client process. OOM-killing the client process will eventually free the dmabuf, also the Wayland server references to it. Killing the Wayland server (compositor, display server) OTOH is something that should not be done as long as there are e.g. Wayland clients to be killed. Unfortunately(?), Wayland clients do not have a reason to keep the dmabuf fd open themselves, so they probably close it as soon as it has been sent to a display server. So the process that should be OOM-killed does not have an open fd for the dmabuf (but probably has something else, but not an mmap for CPU). Buffer re-use in Wayland does not require re-sending the dmabuf fd over IPC. Correct. The reference to your memory is kept inside the drivers GEM handle. That's one reason why we said that this approach here is not taking in the whole picture. Regards, Christian. (In general, dmabufs are never mmapped for CPU. They are accessed by devices.) Thanks, pq ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 7/7] dma-buf: system_heap: Add a system-uncached heap re-using the system heap
On Fri, Oct 16, 2020 at 12:04 PM John Stultz wrote: > > On Thu, Oct 8, 2020 at 4:51 AM Brian Starkey wrote: > > On Sat, Oct 03, 2020 at 04:02:57AM +, John Stultz wrote: > > > @@ -393,6 +424,16 @@ static int system_heap_allocate(struct dma_heap > > > *heap, > > > /* just return, as put will call release and that will free > > > */ > > > return ret; > > > } > > > + > > > + /* > > > + * For uncached buffers, we need to initially flush cpu cache, since > > > + * the __GFP_ZERO on the allocation means the zeroing was done by > > > the > > > + * cpu and thus it is likely cached. Map (and implicitly flush) it > > > out > > > + * now so we don't get corruption later on. > > > + */ > > > + if (buffer->uncached) > > > + dma_map_sgtable(dma_heap_get_dev(heap), table, > > > DMA_BIDIRECTIONAL, 0); > > > > Do we have to keep this mapping around for the entire lifetime of the > > buffer? > > Yea, I guess we can just map and unmap it right there. It will look a > little absurd, but that sort of aligns with your next point. > > > Also, this problem (and solution) keeps lingering around. It really > > feels like there should be a better way to solve "clean the linear > > mapping all the way to DRAM", but I don't know what that should be. > > Yea, something better here would be nice... In ION, we had a little helper function named ion_buffer_prep_noncached that called arch_dma_prep_coherent() on all sg entries like so for_each_sg(table->sgl, sg, table->orig_nents, i) arch_dma_prep_coherent(sg_page(sg), sg->length); Would that help? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH][next] drm/amdgpu: Fix memory leak of object caps on error return paths
From: Colin Ian King
Currently there are three error return paths that don't kfree object
caps. Fix this by performing the allocation of caps after the checks
and error return paths to avoid the premature allocation and memory
leaking.
Addresses-Coverity: ("Resource leak")
Fixes: 555fc7fbb2a2 ("drm/amdgpu: add INFO ioctl support for querying video
caps")
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index 84b666fcfaf6..730f4ac7487b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -988,10 +988,6 @@ int amdgpu_info_ioctl(struct drm_device *dev, void *data,
struct drm_file *filp)
struct drm_amdgpu_info_video_caps *caps;
int r;
- caps = kzalloc(sizeof(*caps), GFP_KERNEL);
- if (!caps)
- return -ENOMEM;
-
switch (info->video_cap.type) {
case AMDGPU_INFO_VIDEO_CAPS_DECODE:
r = amdgpu_asic_query_video_codecs(adev, false,
);
@@ -1009,6 +1005,11 @@ int amdgpu_info_ioctl(struct drm_device *dev, void
*data, struct drm_file *filp)
info->video_cap.type);
return -EINVAL;
}
+
+ caps = kzalloc(sizeof(*caps), GFP_KERNEL);
+ if (!caps)
+ return -ENOMEM;
+
for (i = 0; i < codecs->codec_count; i++) {
int idx = codecs->codec_array[i].codec_type;
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/5] drm/gma500: Remove Moorestown/Medfield
Hi Am 29.01.21 um 11:46 schrieb Patrik Jakobsson: On Fri, Jan 29, 2021 at 10:56 AM Thomas Zimmermann wrote: Support for Moorestown and Medfield platforms is being removed from the kernel. So here's a patch to remove the related code from the gma500 driver. On top of that I also cleaned up the configuration a bit. Note that Poulsbo and Cedartrail is still there and will remain. With the MID platforms gone, there's actually a chance of cleaning up the code for the desktop chips. I smoke tested the patchset by running Xorg and Weston on a Cedartrail system. Hi Thomas, It is correct that Moorestown platform support is removed in the kernel but Oaktrail and Moorestown aren't interchangeable. They share the same CPU/GPU but not platform. I still have an Oaktrail device (Minnowboard v1) which needs to be supported. Medfield on the other hand can go as far as I'm concerned. I see. So patch 2 would have to be removed. Best regards Thomas I'll have a closer look at the patches this afternoon. Thanks Patrik -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer OpenPGP_signature Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/2] drm/msm: Call shutdown conditionally
Hi Rob,
Any comments on this series, please?
On Tue, Jan 19, 2021 at 8:15 PM Fabio Estevam wrote:
>
> Issuing a 'reboot' command in i.MX5 leads to the following flow:
>
> [ 24.557742] [] (msm_atomic_commit_tail) from []
> (commit_tail+0xa4/0x1b0)
> [ 24.566349] [] (commit_tail) from []
> (drm_atomic_helper_commit+0x154/0x188)
> [ 24.575193] [] (drm_atomic_helper_commit) from
> [] (drm_atomic_helper_disable_all+0x154/0x1c0)
> [ 24.585599] [] (drm_atomic_helper_disable_all) from
> [] (drm_atomic_helper_shutdown+0x94/0x12c)
> [ 24.596094] [] (drm_atomic_helper_shutdown) from
>
> In the i.MX5 case, priv->kms is not populated (as i.MX5 does not use any
> of the Qualcomm display controllers), causing a NULL pointer
> dereference in msm_atomic_commit_tail():
>
> [ 24.268964] 8<--- cut here ---
> [ 24.274602] Unable to handle kernel NULL pointer dereference at
> virtual address
> [ 24.283434] pgd = (ptrval)
> [ 24.286387] [] *pgd=ca212831
> [ 24.290788] Internal error: Oops: 17 [#1] SMP ARM
> [ 24.295609] Modules linked in:
> [ 24.298777] CPU: 0 PID: 197 Comm: init Not tainted
> 5.11.0-rc2-next-20210111 #333
> [ 24.306276] Hardware name: Freescale i.MX53 (Device Tree Support)
> [ 24.312442] PC is at msm_atomic_commit_tail+0x54/0xb9c
> [ 24.317743] LR is at commit_tail+0xa4/0x1b0
>
> Fix the problem by calling drm_atomic_helper_shutdown() conditionally.
>
> Cc:
> Fixes: 9d5cbf5fe46e ("drm/msm: add shutdown support for display
> platform_driver")
> Suggested-by: Rob Clark
> Signed-off-by: Fabio Estevam
> ---
> Changes since v1:
> - Explain in the commit log that the problem happens after a 'reboot' command.
>
> drivers/gpu/drm/msm/msm_drv.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> index 108c405e03dd..c082b72b9e3b 100644
> --- a/drivers/gpu/drm/msm/msm_drv.c
> +++ b/drivers/gpu/drm/msm/msm_drv.c
> @@ -1311,7 +1311,8 @@ static void msm_pdev_shutdown(struct platform_device
> *pdev)
> {
> struct drm_device *drm = platform_get_drvdata(pdev);
>
> - drm_atomic_helper_shutdown(drm);
> + if (get_mdp_ver(pdev))
> + drm_atomic_helper_shutdown(drm);
> }
>
> static const struct of_device_id dt_match[] = {
> --
> 2.25.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/5] drm/gma500: Remove Moorestown/Medfield
On Fri, Jan 29, 2021 at 10:56 AM Thomas Zimmermann wrote: > > Support for Moorestown and Medfield platforms is being removed from > the kernel. So here's a patch to remove the related code from the > gma500 driver. On top of that I also cleaned up the configuration > a bit. > > Note that Poulsbo and Cedartrail is still there and will remain. With > the MID platforms gone, there's actually a chance of cleaning up the > code for the desktop chips. > > I smoke tested the patchset by running Xorg and Weston on a Cedartrail > system. Hi Thomas, It is correct that Moorestown platform support is removed in the kernel but Oaktrail and Moorestown aren't interchangeable. They share the same CPU/GPU but not platform. I still have an Oaktrail device (Minnowboard v1) which needs to be supported. Medfield on the other hand can go as far as I'm concerned. I'll have a closer look at the patches this afternoon. Thanks Patrik ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v12] staging: fbtft: add tearing signal detect
On Fri, Jan 29, 2021 at 12:23:08PM +0200, Andy Shevchenko wrote: > On Fri, Jan 29, 2021 at 7:01 AM carlis wrote: > > On Thu, 28 Jan 2021 16:33:02 +0200 > > Andy Shevchenko wrote: > > > On Thu, Jan 28, 2021 at 2:58 PM Carlis wrote: > > > > > > Thanks for your contribution, my comments below. > > > > > > > From: zhangxuezhi > > > > > > You probably have to configure your Git to use the same account for > > > author and committer. > > > > hi,you mean like below: > > Carlis > > ? > > I meant that you shouldn't probably have a From: line in the commit message. It's fine, some people like to be sure about this, there is no problem with it being there at all. thanks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v12] staging: fbtft: add tearing signal detect
On Fri, Jan 29, 2021 at 7:01 AM carlis wrote:
> On Thu, 28 Jan 2021 16:33:02 +0200
> Andy Shevchenko wrote:
> > On Thu, Jan 28, 2021 at 2:58 PM Carlis wrote:
> >
> > Thanks for your contribution, my comments below.
> >
> > > From: zhangxuezhi
> >
> > You probably have to configure your Git to use the same account for
> > author and committer.
>
> hi,you mean like below:
> Carlis
> ?
I meant that you shouldn't probably have a From: line in the commit message.
...
> hi, i have modified it according to your suggestion like below:
Please, go again thru my comments and comments from others and
carefully address all of them everywhere in your contribution. If you
have questions, ask them in reply in the corresponding context.
...
> /**
> * init_tearing_effect_line() - init tearing effect line
> *
For example, above was commented on and hasn't been addressed here.
> * @par: FBTFT parameter object
> *
> * Return: 0 on success, < 0 if error occurred.
> */
> static int init_tearing_effect_line(struct fbtft_par *par)
> {
> struct device *dev = par->info->device;
> struct gpio_desc *te;
> int rc;
>
> te = gpiod_get_optional(dev, "te", GPIOD_IN);
> if (IS_ERR(te))
> return dev_err_probe(dev, PTR_ERR(te), "Failed to
> request te GPIO\n");
>
> if (te) {
This one is not like I suggested.
> par->irq_te = gpiod_to_irq(te);
> gpiod_put(te);
>
> if (par->irq_te) {
This is wrong.
> rc = devm_request_irq(dev,
> par->irq_te,
> panel_te_handler,
> IRQF_TRIGGER_RISING,
> "TE_GPIO", par);
Try to use less LOCs.
> if (rc)
> return dev_err_probe(dev, rc, "TE IRQ
> request failed.\n");
>
> disable_irq_nosync(par->irq_te);
> init_completion(>panel_te);
> } else {
> return dev_err_probe(dev, par->irq_te, "gpiod
> to TE IRQ failed.\n");
> }
Again, it is not what had been suggested.
> }
>
> return 0;
> }
The rest is better, but we will see later on when you submit a new
version (And I feel it won't be last).
--
With Best Regards,
Andy Shevchenko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/5] drm/gma500: Drop DRM_GMA3600 config option
With support for the MID-related chips removed, only support for
desktop chips is left in the driver. So just build the complete
driver if DRM_GMA500 has been selected. Anyone who wants to enable
the Poulsbo code would probably also want the Cedarview code.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/gma500/Kconfig | 13 +++--
drivers/gpu/drm/gma500/Makefile | 25 -
drivers/gpu/drm/gma500/psb_drv.c | 4 ++--
3 files changed, 17 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/gma500/Kconfig b/drivers/gpu/drm/gma500/Kconfig
index 6f41b88cf076..02de5970d490 100644
--- a/drivers/gpu/drm/gma500/Kconfig
+++ b/drivers/gpu/drm/gma500/Kconfig
@@ -1,6 +1,6 @@
# SPDX-License-Identifier: GPL-2.0-only
config DRM_GMA500
- tristate "Intel GMA5/600 KMS Framebuffer"
+ tristate "Intel GMA500/3600/3650 KMS Framebuffer"
depends on DRM && PCI && X86 && MMU
select DRM_KMS_HELPER
select DRM_TTM
@@ -10,12 +10,5 @@ config DRM_GMA500
select INPUT if ACPI
help
Say yes for an experimental 2D KMS framebuffer driver for the
- Intel GMA500 ('Poulsbo') and other Intel IMG based graphics
- devices.
-
-config DRM_GMA3600
- bool "Intel GMA3600/3650 support (Experimental)"
- depends on DRM_GMA500
- help
- Say yes to include basic support for Intel GMA3600/3650 (Intel
- Cedar Trail) platforms.
+ Intel GMA500 ('Poulsbo') and Intel GMA3600/3650 (Intel
+ Cedar Trail).
diff --git a/drivers/gpu/drm/gma500/Makefile b/drivers/gpu/drm/gma500/Makefile
index b33dfef17849..04999757d402 100644
--- a/drivers/gpu/drm/gma500/Makefile
+++ b/drivers/gpu/drm/gma500/Makefile
@@ -6,33 +6,32 @@
gma500_gfx-y += \
accel_2d.o \
backlight.o \
+ blitter.o \
+ cdv_device.o \
+ cdv_intel_crt.o \
+ cdv_intel_display.o \
+ cdv_intel_dp.o \
+ cdv_intel_hdmi.o \
+ cdv_intel_lvds.o \
framebuffer.o \
gem.o \
+ gma_device.o \
+ gma_display.o \
gtt.o \
intel_bios.o \
- intel_i2c.o \
intel_gmbus.o \
+ intel_i2c.o \
mmu.o \
- blitter.o \
power.o \
+ psb_device.o \
psb_drv.o \
- gma_display.o \
- gma_device.o \
psb_intel_display.o \
psb_intel_lvds.o \
psb_intel_modes.o \
psb_intel_sdvo.o \
- psb_lid.o \
psb_irq.o \
- psb_device.o
+ psb_lid.o
gma500_gfx-$(CONFIG_ACPI) += opregion.o \
-gma500_gfx-$(CONFIG_DRM_GMA3600) += cdv_device.o \
- cdv_intel_crt.o \
- cdv_intel_display.o \
- cdv_intel_hdmi.o \
- cdv_intel_lvds.o \
- cdv_intel_dp.o
-
obj-$(CONFIG_DRM_GMA500) += gma500_gfx.o
diff --git a/drivers/gpu/drm/gma500/psb_drv.c b/drivers/gpu/drm/gma500/psb_drv.c
index c3653975a6c4..c396324ff763 100644
--- a/drivers/gpu/drm/gma500/psb_drv.c
+++ b/drivers/gpu/drm/gma500/psb_drv.c
@@ -48,9 +48,10 @@ static int psb_pci_probe(struct pci_dev *pdev, const struct
pci_device_id *ent);
* N2800
*/
static const struct pci_device_id pciidlist[] = {
+ /* Poulsbo */
{ 0x8086, 0x8108, PCI_ANY_ID, PCI_ANY_ID, 0, 0, (long) _chip_ops },
{ 0x8086, 0x8109, PCI_ANY_ID, PCI_ANY_ID, 0, 0, (long) _chip_ops },
-#if defined(CONFIG_DRM_GMA3600)
+ /* Cedartrail */
{ 0x8086, 0x0be0, PCI_ANY_ID, PCI_ANY_ID, 0, 0, (long) _chip_ops },
{ 0x8086, 0x0be1, PCI_ANY_ID, PCI_ANY_ID, 0, 0, (long) _chip_ops },
{ 0x8086, 0x0be2, PCI_ANY_ID, PCI_ANY_ID, 0, 0, (long) _chip_ops },
@@ -67,7 +68,6 @@ static const struct pci_device_id pciidlist[] = {
{ 0x8086, 0x0bed, PCI_ANY_ID, PCI_ANY_ID, 0, 0, (long) _chip_ops },
{ 0x8086, 0x0bee, PCI_ANY_ID, PCI_ANY_ID, 0, 0, (long) _chip_ops },
{ 0x8086, 0x0bef, PCI_ANY_ID, PCI_ANY_ID, 0, 0, (long) _chip_ops },
-#endif
{ 0, }
};
MODULE_DEVICE_TABLE(pci, pciidlist);
--
2.30.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/5] drm/gma500: Remove dependency on TTM
The gma500 driver does not use TTM. Signed-off-by: Thomas Zimmermann --- drivers/gpu/drm/gma500/Kconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/gma500/Kconfig b/drivers/gpu/drm/gma500/Kconfig index 02de5970d490..405f718b884c 100644 --- a/drivers/gpu/drm/gma500/Kconfig +++ b/drivers/gpu/drm/gma500/Kconfig @@ -3,7 +3,6 @@ config DRM_GMA500 tristate "Intel GMA500/3600/3650 KMS Framebuffer" depends on DRM && PCI && X86 && MMU select DRM_KMS_HELPER - select DRM_TTM # GMA500 depends on ACPI_VIDEO when ACPI is enabled, just like i915 select ACPI_VIDEO if ACPI select BACKLIGHT_CLASS_DEVICE if ACPI -- 2.30.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/5] drm/gma500: Remove CONFIG_X86 conditionals from source files
Remove the CONFIG_X86 conditionals from the source code. The driver
already depends on X86 in the Kconfig file. Also, no one has been
trying to build it on a non-x86 platform recently, or they would have
noticed that drm_ttm_cache_flush() doesn't exist.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/gma500/mmu.c | 21 -
1 file changed, 21 deletions(-)
diff --git a/drivers/gpu/drm/gma500/mmu.c b/drivers/gpu/drm/gma500/mmu.c
index 13aff19aae9b..d856580b8111 100644
--- a/drivers/gpu/drm/gma500/mmu.c
+++ b/drivers/gpu/drm/gma500/mmu.c
@@ -48,7 +48,6 @@ static inline uint32_t psb_mmu_pd_index(uint32_t offset)
return offset >> PSB_PDE_SHIFT;
}
-#if defined(CONFIG_X86)
static inline void psb_clflush(void *addr)
{
__asm__ __volatile__("clflush (%0)\n" : : "r"(addr) : "memory");
@@ -63,13 +62,6 @@ static inline void psb_mmu_clflush(struct psb_mmu_driver
*driver, void *addr)
psb_clflush(addr);
mb();
}
-#else
-
-static inline void psb_mmu_clflush(struct psb_mmu_driver *driver, void *addr)
-{;
-}
-
-#endif
static void psb_mmu_flush_pd_locked(struct psb_mmu_driver *driver, int force)
{
@@ -293,7 +285,6 @@ static struct psb_mmu_pt *psb_mmu_alloc_pt(struct
psb_mmu_pd *pd)
for (i = 0; i < (PAGE_SIZE / sizeof(uint32_t)); ++i)
*ptes++ = pd->invalid_pte;
-#if defined(CONFIG_X86)
if (pd->driver->has_clflush && pd->hw_context != -1) {
mb();
for (i = 0; i < clflush_count; ++i) {
@@ -302,7 +293,6 @@ static struct psb_mmu_pt *psb_mmu_alloc_pt(struct
psb_mmu_pd *pd)
}
mb();
}
-#endif
kunmap_atomic(v);
spin_unlock(lock);
@@ -459,7 +449,6 @@ struct psb_mmu_driver *psb_mmu_driver_init(struct
drm_device *dev,
driver->has_clflush = 0;
-#if defined(CONFIG_X86)
if (boot_cpu_has(X86_FEATURE_CLFLUSH)) {
uint32_t tfms, misc, cap0, cap4, clflush_size;
@@ -476,7 +465,6 @@ struct psb_mmu_driver *psb_mmu_driver_init(struct
drm_device *dev,
driver->clflush_mask = driver->clflush_add - 1;
driver->clflush_mask = ~driver->clflush_mask;
}
-#endif
up_write(>sem);
return driver;
@@ -486,7 +474,6 @@ struct psb_mmu_driver *psb_mmu_driver_init(struct
drm_device *dev,
return NULL;
}
-#if defined(CONFIG_X86)
static void psb_mmu_flush_ptes(struct psb_mmu_pd *pd, unsigned long address,
uint32_t num_pages, uint32_t desired_tile_stride,
uint32_t hw_tile_stride)
@@ -534,14 +521,6 @@ static void psb_mmu_flush_ptes(struct psb_mmu_pd *pd,
unsigned long address,
}
mb();
}
-#else
-static void psb_mmu_flush_ptes(struct psb_mmu_pd *pd, unsigned long address,
- uint32_t num_pages, uint32_t desired_tile_stride,
- uint32_t hw_tile_stride)
-{
- drm_ttm_cache_flush();
-}
-#endif
void psb_mmu_remove_pfn_sequence(struct psb_mmu_pd *pd,
unsigned long address, uint32_t num_pages)
--
2.30.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/5] drm/gma500: Remove Moorestown/Medfield
Support for Moorestown and Medfield platforms is being removed from the kernel. So here's a patch to remove the related code from the gma500 driver. On top of that I also cleaned up the configuration a bit. Note that Poulsbo and Cedartrail is still there and will remain. With the MID platforms gone, there's actually a chance of cleaning up the code for the desktop chips. I smoke tested the patchset by running Xorg and Weston on a Cedartrail system. Thomas Zimmermann (5): drm/gma500: Remove Medfield support drm/gma500: Remove Moorestown support drm/gma500: Drop DRM_GMA3600 config option drm/gma500: Remove CONFIG_X86 conditionals from source files drm/gma500: Remove dependency on TTM drivers/gpu/drm/gma500/Kconfig| 28 +- drivers/gpu/drm/gma500/Makefile | 43 +- drivers/gpu/drm/gma500/cdv_intel_hdmi.c |4 - drivers/gpu/drm/gma500/framebuffer.c |2 +- drivers/gpu/drm/gma500/intel_gmbus.c |5 +- drivers/gpu/drm/gma500/mdfld_device.c | 564 - drivers/gpu/drm/gma500/mdfld_dsi_dpi.c| 1017 - drivers/gpu/drm/gma500/mdfld_dsi_dpi.h| 79 -- drivers/gpu/drm/gma500/mdfld_dsi_output.c | 603 -- drivers/gpu/drm/gma500/mdfld_dsi_output.h | 377 -- drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c | 679 --- drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.h | 80 -- drivers/gpu/drm/gma500/mdfld_intel_display.c | 966 drivers/gpu/drm/gma500/mdfld_output.c | 74 -- drivers/gpu/drm/gma500/mdfld_output.h | 76 -- drivers/gpu/drm/gma500/mdfld_tmd_vid.c| 197 drivers/gpu/drm/gma500/mdfld_tpo_vid.c| 83 -- drivers/gpu/drm/gma500/mid_bios.c | 333 -- drivers/gpu/drm/gma500/mid_bios.h | 10 - drivers/gpu/drm/gma500/mmu.c | 21 - drivers/gpu/drm/gma500/oaktrail.h | 247 drivers/gpu/drm/gma500/oaktrail_crtc.c| 663 --- drivers/gpu/drm/gma500/oaktrail_device.c | 567 - drivers/gpu/drm/gma500/oaktrail_hdmi.c| 840 -- drivers/gpu/drm/gma500/oaktrail_hdmi_i2c.c| 331 -- drivers/gpu/drm/gma500/oaktrail_lvds.c| 423 --- drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c| 169 --- drivers/gpu/drm/gma500/psb_drv.c | 82 +- drivers/gpu/drm/gma500/psb_drv.h | 108 -- drivers/gpu/drm/gma500/psb_intel_drv.h|6 - drivers/gpu/drm/gma500/psb_intel_lvds.c | 14 +- drivers/gpu/drm/gma500/psb_intel_reg.h| 28 +- drivers/gpu/drm/gma500/psb_intel_sdvo.c | 20 +- drivers/gpu/drm/gma500/psb_irq.c | 72 +- drivers/gpu/drm/gma500/psb_irq.h |2 - drivers/gpu/drm/gma500/psb_reg.h | 14 - drivers/gpu/drm/gma500/tc35876x-dsi-lvds.c| 805 - drivers/gpu/drm/gma500/tc35876x-dsi-lvds.h| 38 - 38 files changed, 31 insertions(+), 9639 deletions(-) delete mode 100644 drivers/gpu/drm/gma500/mdfld_device.c delete mode 100644 drivers/gpu/drm/gma500/mdfld_dsi_dpi.c delete mode 100644 drivers/gpu/drm/gma500/mdfld_dsi_dpi.h delete mode 100644 drivers/gpu/drm/gma500/mdfld_dsi_output.c delete mode 100644 drivers/gpu/drm/gma500/mdfld_dsi_output.h delete mode 100644 drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c delete mode 100644 drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.h delete mode 100644 drivers/gpu/drm/gma500/mdfld_intel_display.c delete mode 100644 drivers/gpu/drm/gma500/mdfld_output.c delete mode 100644 drivers/gpu/drm/gma500/mdfld_output.h delete mode 100644 drivers/gpu/drm/gma500/mdfld_tmd_vid.c delete mode 100644 drivers/gpu/drm/gma500/mdfld_tpo_vid.c delete mode 100644 drivers/gpu/drm/gma500/mid_bios.c delete mode 100644 drivers/gpu/drm/gma500/mid_bios.h delete mode 100644 drivers/gpu/drm/gma500/oaktrail.h delete mode 100644 drivers/gpu/drm/gma500/oaktrail_crtc.c delete mode 100644 drivers/gpu/drm/gma500/oaktrail_device.c delete mode 100644 drivers/gpu/drm/gma500/oaktrail_hdmi.c delete mode 100644 drivers/gpu/drm/gma500/oaktrail_hdmi_i2c.c delete mode 100644 drivers/gpu/drm/gma500/oaktrail_lvds.c delete mode 100644 drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c delete mode 100644 drivers/gpu/drm/gma500/tc35876x-dsi-lvds.c delete mode 100644 drivers/gpu/drm/gma500/tc35876x-dsi-lvds.h -- 2.30.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] iommu/io-pgtable-arm: Add IOMMU_LLC page protection flag
On Mon, Jan 11, 2021 at 07:45:04PM +0530, Sai Prakash Ranjan wrote: > Add a new page protection flag IOMMU_LLC which can be used > by non-coherent masters to set cacheable memory attributes > for an outer level of cache called as last-level cache or > system cache. Initial user of this page protection flag is > the adreno gpu and then can later be used by other clients > such as video where this can be used for per-buffer based > mapping. > > Signed-off-by: Sai Prakash Ranjan > --- > drivers/iommu/io-pgtable-arm.c | 3 +++ > include/linux/iommu.h | 6 ++ > 2 files changed, 9 insertions(+) > > diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c > index 7439ee7fdcdb..ebe653ef601b 100644 > --- a/drivers/iommu/io-pgtable-arm.c > +++ b/drivers/iommu/io-pgtable-arm.c > @@ -415,6 +415,9 @@ static arm_lpae_iopte arm_lpae_prot_to_pte(struct > arm_lpae_io_pgtable *data, > else if (prot & IOMMU_CACHE) > pte |= (ARM_LPAE_MAIR_ATTR_IDX_CACHE > << ARM_LPAE_PTE_ATTRINDX_SHIFT); > + else if (prot & IOMMU_LLC) > + pte |= (ARM_LPAE_MAIR_ATTR_IDX_INC_OCACHE > + << ARM_LPAE_PTE_ATTRINDX_SHIFT); > } > > if (prot & IOMMU_CACHE) > diff --git a/include/linux/iommu.h b/include/linux/iommu.h > index ffaa389ea128..1f82057df531 100644 > --- a/include/linux/iommu.h > +++ b/include/linux/iommu.h > @@ -31,6 +31,12 @@ > * if the IOMMU page table format is equivalent. > */ > #define IOMMU_PRIV (1 << 5) > +/* > + * Non-coherent masters can use this page protection flag to set cacheable > + * memory attributes for only a transparent outer level of cache, also known > as > + * the last-level or system cache. > + */ > +#define IOMMU_LLC(1 << 6) On reflection, I'm a bit worried about exposing this because I think it will introduce a mismatched virtual alias with the CPU (we don't even have a MAIR set up for this memory type). Now, we also have that issue for the PTW, but since we always use cache maintenance (i.e. the streaming API) for publishing the page-tables to a non-coheren walker, it works out. However, if somebody expects IOMMU_LLC to be coherent with a DMA API coherent allocation, then they're potentially in for a nasty surprise due to the mismatched outer-cacheability attributes. So I can take patch (1) as a trivial rename, but unfortunately I think this needs more thought before exposing it beyond the PTW. Will ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 7/8] soc: mediatek: add mtk mutex support for MT8192
Hi, Hsin-Yi:
On Fri, 2021-01-29 at 15:34 +0800, Hsin-Yi Wang wrote:
> From: Yongqiang Niu
>
> Add mtk mutex support for MT8192 SoC.
Reviewed-by: CK Hu
>
> Signed-off-by: Yongqiang Niu
> Signed-off-by: Hsin-Yi Wang
> ---
> drivers/soc/mediatek/mtk-mutex.c | 35
> 1 file changed, 35 insertions(+)
>
> diff --git a/drivers/soc/mediatek/mtk-mutex.c
> b/drivers/soc/mediatek/mtk-mutex.c
> index 718a41beb6afb..dfd9806d5a001 100644
> --- a/drivers/soc/mediatek/mtk-mutex.c
> +++ b/drivers/soc/mediatek/mtk-mutex.c
> @@ -39,6 +39,18 @@
> #define MT8167_MUTEX_MOD_DISP_DITHER 15
> #define MT8167_MUTEX_MOD_DISP_UFOE 16
>
> +#define MT8192_MUTEX_MOD_DISP_OVL0 0
> +#define MT8192_MUTEX_MOD_DISP_OVL0_2L1
> +#define MT8192_MUTEX_MOD_DISP_RDMA0 2
> +#define MT8192_MUTEX_MOD_DISP_COLOR0 4
> +#define MT8192_MUTEX_MOD_DISP_CCORR0 5
> +#define MT8192_MUTEX_MOD_DISP_AAL0 6
> +#define MT8192_MUTEX_MOD_DISP_GAMMA0 7
> +#define MT8192_MUTEX_MOD_DISP_POSTMASK0 8
> +#define MT8192_MUTEX_MOD_DISP_DITHER09
> +#define MT8192_MUTEX_MOD_DISP_OVL2_2L16
> +#define MT8192_MUTEX_MOD_DISP_RDMA4 17
> +
> #define MT8183_MUTEX_MOD_DISP_RDMA0 0
> #define MT8183_MUTEX_MOD_DISP_RDMA1 1
> #define MT8183_MUTEX_MOD_DISP_OVL0 9
> @@ -214,6 +226,20 @@ static const unsigned int
> mt8183_mutex_mod[DDP_COMPONENT_ID_MAX] = {
> [DDP_COMPONENT_WDMA0] = MT8183_MUTEX_MOD_DISP_WDMA0,
> };
>
> +static const unsigned int mt8192_mutex_mod[DDP_COMPONENT_ID_MAX] = {
> + [DDP_COMPONENT_AAL0] = MT8192_MUTEX_MOD_DISP_AAL0,
> + [DDP_COMPONENT_CCORR] = MT8192_MUTEX_MOD_DISP_CCORR0,
> + [DDP_COMPONENT_COLOR0] = MT8192_MUTEX_MOD_DISP_COLOR0,
> + [DDP_COMPONENT_DITHER] = MT8192_MUTEX_MOD_DISP_DITHER0,
> + [DDP_COMPONENT_GAMMA] = MT8192_MUTEX_MOD_DISP_GAMMA0,
> + [DDP_COMPONENT_POSTMASK0] = MT8192_MUTEX_MOD_DISP_POSTMASK0,
> + [DDP_COMPONENT_OVL0] = MT8192_MUTEX_MOD_DISP_OVL0,
> + [DDP_COMPONENT_OVL_2L0] = MT8192_MUTEX_MOD_DISP_OVL0_2L,
> + [DDP_COMPONENT_OVL_2L2] = MT8192_MUTEX_MOD_DISP_OVL2_2L,
> + [DDP_COMPONENT_RDMA0] = MT8192_MUTEX_MOD_DISP_RDMA0,
> + [DDP_COMPONENT_RDMA4] = MT8192_MUTEX_MOD_DISP_RDMA4,
> +};
> +
> static const unsigned int mt2712_mutex_sof[MUTEX_SOF_DSI3 + 1] = {
> [MUTEX_SOF_SINGLE_MODE] = MUTEX_SOF_SINGLE_MODE,
> [MUTEX_SOF_DSI0] = MUTEX_SOF_DSI0,
> @@ -275,6 +301,13 @@ static const struct mtk_mutex_data
> mt8183_mutex_driver_data = {
> .no_clk = true,
> };
>
> +static const struct mtk_mutex_data mt8192_mutex_driver_data = {
> + .mutex_mod = mt8192_mutex_mod,
> + .mutex_sof = mt8183_mutex_sof,
> + .mutex_mod_reg = MT8183_MUTEX0_MOD0,
> + .mutex_sof_reg = MT8183_MUTEX0_SOF0,
> +};
> +
> struct mtk_mutex *mtk_mutex_get(struct device *dev)
> {
> struct mtk_mutex_ctx *mtx = dev_get_drvdata(dev);
> @@ -507,6 +540,8 @@ static const struct of_device_id mutex_driver_dt_match[]
> = {
> .data = _mutex_driver_data},
> { .compatible = "mediatek,mt8183-disp-mutex",
> .data = _mutex_driver_data},
> + { .compatible = "mediatek,mt8192-disp-mutex",
> + .data = _mutex_driver_data},
> {},
> };
> MODULE_DEVICE_TABLE(of, mutex_driver_dt_match);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 6/8] drm/mediatek: add matrix bits private data for ccorr
Hi, Hsin-Yi:
On Fri, 2021-01-29 at 15:34 +0800, Hsin-Yi Wang wrote:
> From: Yongqiang Niu
>
> matrix bits of mt8183 is 12
> matrix bits of mt8192 is 13
>
> Signed-off-by: Yongqiang Niu
> Signed-off-by: Hsin-Yi Wang
> ---
> drivers/gpu/drm/mediatek/mtk_disp_ccorr.c | 22 +++---
> 1 file changed, 19 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
> b/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
> index 0c68090eb1e92..1c7163a12f3b1 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
> @@ -31,8 +31,10 @@
> #define DISP_CCORR_COEF_30x008C
> #define DISP_CCORR_COEF_40x0090
>
> +#define CCORR_MATRIX_BITS12
> +
> struct mtk_disp_ccorr_data {
> - u32 reserved;
> + u32 matrix_bits;
> };
>
> /**
> @@ -116,6 +118,7 @@ void mtk_ccorr_ctm_set(struct device *dev, struct
> drm_crtc_state *state)
> uint16_t coeffs[9] = { 0 };
> int i;
> struct cmdq_pkt *cmdq_pkt = NULL;
> + u32 matrix_bits;
>
> if (!blob)
> return;
> @@ -123,8 +126,16 @@ void mtk_ccorr_ctm_set(struct device *dev, struct
> drm_crtc_state *state)
> ctm = (struct drm_color_ctm *)blob->data;
> input = ctm->matrix;
>
> - for (i = 0; i < ARRAY_SIZE(coeffs); i++)
> + if (ccorr->data)
> + matrix_bits = ccorr->data->matrix_bits;
> + else
> + matrix_bits = CCORR_MATRIX_BITS;
> +
> + for (i = 0; i < ARRAY_SIZE(coeffs); i++) {
> coeffs[i] = mtk_ctm_s31_32_to_s1_10(input[i]);
> + if (matrix_bits > CCORR_MATRIX_BITS)
> + coeffs[i] <<= (matrix_bits - CCORR_MATRIX_BITS);
I think format of MT8192 ccorr coeffs is s1.11, after
mtk_ctm_s31_32_to_s1_10(), you lose one bit precision. So modify
mtk_ctm_s31_32_to_s1_10() to get maximum precision.
Regards,
CK
> + }
>
> mtk_ddp_write(cmdq_pkt, coeffs[0] << 16 | coeffs[1],
> >cmdq_reg, ccorr->regs, DISP_CCORR_COEF_0);
> @@ -205,8 +216,13 @@ static int mtk_disp_ccorr_remove(struct platform_device
> *pdev)
> return 0;
> }
>
> +static const struct mtk_disp_ccorr_data mt8183_ccorr_driver_data = {
> + .matrix_bits = CCORR_MATRIX_BITS,
> +};
> +
> static const struct of_device_id mtk_disp_ccorr_driver_dt_match[] = {
> - { .compatible = "mediatek,mt8183-disp-ccorr"},
> + { .compatible = "mediatek,mt8183-disp-ccorr",
> + .data = _ccorr_driver_data},
> {},
> };
> MODULE_DEVICE_TABLE(of, mtk_disp_ccorr_driver_dt_match);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 2/8] drm/mediatek: add component POSTMASK
On Fri, 2021-01-29 at 16:32 +0800, Yongqiang Niu wrote:
> On Fri, 2021-01-29 at 16:18 +0800, CK Hu wrote:
> > Hi, Hsin-Yi:
> >
> > On Fri, 2021-01-29 at 15:34 +0800, Hsin-Yi Wang wrote:
> > > From: Yongqiang Niu
> > >
> > > This patch add component POSTMASK,
> > >
> > > Signed-off-by: Yongqiang Niu
> > > Signed-off-by: Hsin-Yi Wang
> > > ---
> > > drivers/gpu/drm/mediatek/Makefile| 1 +
> > > drivers/gpu/drm/mediatek/mtk_disp_drv.h | 8 +
> > > drivers/gpu/drm/mediatek/mtk_disp_postmask.c | 161 +++
> > > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 11 ++
> > > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 1 +
> > > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 4 +-
> > > drivers/gpu/drm/mediatek/mtk_drm_drv.h | 1 +
> > > 7 files changed, 186 insertions(+), 1 deletion(-)
> > > create mode 100644 drivers/gpu/drm/mediatek/mtk_disp_postmask.c
> > >
> > > diff --git a/drivers/gpu/drm/mediatek/Makefile
> > > b/drivers/gpu/drm/mediatek/Makefile
> > > index b64674b944860..13a0eafabf9c0 100644
> > > --- a/drivers/gpu/drm/mediatek/Makefile
> > > +++ b/drivers/gpu/drm/mediatek/Makefile
> > > @@ -3,6 +3,7 @@
> > > mediatek-drm-y := mtk_disp_color.o \
> > > mtk_disp_gamma.o \
> > > mtk_disp_ovl.o \
> > > + mtk_disp_postmask.o \
> > > mtk_disp_rdma.o \
> > > mtk_drm_crtc.o \
> > > mtk_drm_ddp_comp.o \
> > > diff --git a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> > > b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> > > index 02191010699f8..d74e85db3fcdf 100644
> > > --- a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> > > +++ b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> > > @@ -37,6 +37,14 @@ void mtk_gamma_set_common(void __iomem *regs, struct
> > > drm_crtc_state *state);
> > > void mtk_gamma_start(struct device *dev);
> > > void mtk_gamma_stop(struct device *dev);
> > >
> > > +int mtk_postmask_clk_enable(struct device *dev);
> > > +void mtk_postmask_clk_disable(struct device *dev);
> > > +void mtk_postmask_config(struct device *dev, unsigned int w,
> > > + unsigned int h, unsigned int vrefresh,
> > > + unsigned int bpc, struct cmdq_pkt *cmdq_pkt);
> > > +void mtk_postmask_start(struct device *dev);
> > > +void mtk_postmask_stop(struct device *dev);
> > > +
> > > void mtk_ovl_bgclr_in_on(struct device *dev);
> > > void mtk_ovl_bgclr_in_off(struct device *dev);
> > > void mtk_ovl_bypass_shadow(struct device *dev);
> > > diff --git a/drivers/gpu/drm/mediatek/mtk_disp_postmask.c
> > > b/drivers/gpu/drm/mediatek/mtk_disp_postmask.c
> > > new file mode 100644
> > > index 0..d640cef9c15a4
> > > --- /dev/null
> > > +++ b/drivers/gpu/drm/mediatek/mtk_disp_postmask.c
> > > @@ -0,0 +1,161 @@
> > > +/*
> > > + * SPDX-License-Identifier:
> > > + *
> > > + * Copyright (c) 2020 MediaTek Inc.
> >
> > 2021
> >
> > > + */
> > > +
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +
> > > +#include "mtk_disp_drv.h"
> > > +#include "mtk_drm_crtc.h"
> > > +#include "mtk_drm_ddp_comp.h"
> > > +
> > > +#define DISP_POSTMASK_EN 0x
> > > +#define POSTMASK_EN BIT(0)
> > > +#define DISP_POSTMASK_CFG0x0020
> > > +#define POSTMASK_RELAY_MODE BIT(0)
> > > +#define DISP_POSTMASK_SIZE 0x0030
> > > +
> > > +struct mtk_disp_postmask_data {
> > > + u32 reserved;
> > > +};
> >
> > Useless, so remove.
> >
> > > +
> > > +/**
> > > + * struct mtk_disp_postmask - DISP_postmask driver structure
> > > + * @ddp_comp - structure containing type enum and hardware resources
> > > + * @crtc - associated crtc to report irq events to
> > > + */
> > > +struct mtk_disp_postmask {
> > > + struct clk *clk;
> > > + void __iomem *regs;
> > > + struct cmdq_client_reg cmdq_reg;
> > > + const struct mtk_disp_postmask_data *data;
> > > +};
> > > +
> > > +int mtk_postmask_clk_enable(struct device *dev)
> > > +{
> > > + struct mtk_disp_postmask *postmask = dev_get_drvdata(dev);
> > > +
> > > + return clk_prepare_enable(postmask->clk);
> > > +}
> > > +
> > > +void mtk_postmask_clk_disable(struct device *dev)
> > > +{
> > > + struct mtk_disp_postmask *postmask = dev_get_drvdata(dev);
> > > +
> > > + clk_disable_unprepare(postmask->clk);
> > > +}
> > > +
> > > +void mtk_postmask_config(struct device *dev, unsigned int w,
> > > + unsigned int h, unsigned int vrefresh,
> > > + unsigned int bpc, struct cmdq_pkt *cmdq_pkt)
> > > +{
> > > + struct mtk_disp_postmask *postmask = dev_get_drvdata(dev);
> > > +
> > > + mtk_ddp_write(cmdq_pkt, w << 16 | h, >cmdq_reg,
> > > postmask->regs,
> > > + DISP_POSTMASK_SIZE);
> > > + mtk_ddp_write(cmdq_pkt, POSTMASK_RELAY_MODE, >cmdq_reg,
> > > + postmask->regs, DISP_POSTMASK_CFG);
> > > +}
>
Re: [PATCH v4 4/8] drm/mediatek: enable OVL_LAYER_SMI_ID_EN for multi-layer usecase
Hi, Hsin-Yi:
On Fri, 2021-01-29 at 15:34 +0800, Hsin-Yi Wang wrote:
> From: Yongqiang Niu
>
> enable OVL_LAYER_SMI_ID_EN for multi-layer usecase, without this patch,
> ovl will hang up when more than 1 layer enabled.
Reviewed-by: CK Hu
>
> Signed-off-by: Yongqiang Niu
> Signed-off-by: Hsin-Yi Wang
> ---
> drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> index da7e38a28759b..961f87f8d4d15 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> @@ -24,6 +24,7 @@
> #define DISP_REG_OVL_RST 0x0014
> #define DISP_REG_OVL_ROI_SIZE0x0020
> #define DISP_REG_OVL_DATAPATH_CON0x0024
> +#define OVL_LAYER_SMI_ID_EN BIT(0)
> #define OVL_BGCLR_SEL_IN BIT(2)
> #define DISP_REG_OVL_ROI_BGCLR 0x0028
> #define DISP_REG_OVL_SRC_CON 0x002c
> @@ -62,6 +63,7 @@ struct mtk_disp_ovl_data {
> unsigned int gmc_bits;
> unsigned int layer_nr;
> bool fmt_rgb565_is_0;
> + bool smi_id_en;
> };
>
> /**
> @@ -134,6 +136,13 @@ void mtk_ovl_start(struct device *dev)
> {
> struct mtk_disp_ovl *ovl = dev_get_drvdata(dev);
>
> + if (ovl->data->smi_id_en) {
> + unsigned int reg;
> +
> + reg = readl(ovl->regs + DISP_REG_OVL_DATAPATH_CON);
> + reg = reg | OVL_LAYER_SMI_ID_EN;
> + writel_relaxed(reg, ovl->regs + DISP_REG_OVL_DATAPATH_CON);
> + }
> writel_relaxed(0x1, ovl->regs + DISP_REG_OVL_EN);
> }
>
> @@ -142,6 +151,14 @@ void mtk_ovl_stop(struct device *dev)
> struct mtk_disp_ovl *ovl = dev_get_drvdata(dev);
>
> writel_relaxed(0x0, ovl->regs + DISP_REG_OVL_EN);
> + if (ovl->data->smi_id_en) {
> + unsigned int reg;
> +
> + reg = readl(ovl->regs + DISP_REG_OVL_DATAPATH_CON);
> + reg = reg & ~OVL_LAYER_SMI_ID_EN;
> + writel_relaxed(reg, ovl->regs + DISP_REG_OVL_DATAPATH_CON);
> + }
> +
> }
>
> void mtk_ovl_config(struct device *dev, unsigned int w,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 2/8] drm/mediatek: add component POSTMASK
Hi, Hsin-Yi:
On Fri, 2021-01-29 at 15:34 +0800, Hsin-Yi Wang wrote:
> From: Yongqiang Niu
>
> This patch add component POSTMASK,
>
> Signed-off-by: Yongqiang Niu
> Signed-off-by: Hsin-Yi Wang
> ---
> drivers/gpu/drm/mediatek/Makefile| 1 +
> drivers/gpu/drm/mediatek/mtk_disp_drv.h | 8 +
> drivers/gpu/drm/mediatek/mtk_disp_postmask.c | 161 +++
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 11 ++
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 1 +
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 4 +-
> drivers/gpu/drm/mediatek/mtk_drm_drv.h | 1 +
> 7 files changed, 186 insertions(+), 1 deletion(-)
> create mode 100644 drivers/gpu/drm/mediatek/mtk_disp_postmask.c
>
> diff --git a/drivers/gpu/drm/mediatek/Makefile
> b/drivers/gpu/drm/mediatek/Makefile
> index b64674b944860..13a0eafabf9c0 100644
> --- a/drivers/gpu/drm/mediatek/Makefile
> +++ b/drivers/gpu/drm/mediatek/Makefile
> @@ -3,6 +3,7 @@
> mediatek-drm-y := mtk_disp_color.o \
> mtk_disp_gamma.o \
> mtk_disp_ovl.o \
> + mtk_disp_postmask.o \
> mtk_disp_rdma.o \
> mtk_drm_crtc.o \
> mtk_drm_ddp_comp.o \
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> index 02191010699f8..d74e85db3fcdf 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> @@ -37,6 +37,14 @@ void mtk_gamma_set_common(void __iomem *regs, struct
> drm_crtc_state *state);
> void mtk_gamma_start(struct device *dev);
> void mtk_gamma_stop(struct device *dev);
>
> +int mtk_postmask_clk_enable(struct device *dev);
> +void mtk_postmask_clk_disable(struct device *dev);
> +void mtk_postmask_config(struct device *dev, unsigned int w,
> + unsigned int h, unsigned int vrefresh,
> + unsigned int bpc, struct cmdq_pkt *cmdq_pkt);
> +void mtk_postmask_start(struct device *dev);
> +void mtk_postmask_stop(struct device *dev);
> +
> void mtk_ovl_bgclr_in_on(struct device *dev);
> void mtk_ovl_bgclr_in_off(struct device *dev);
> void mtk_ovl_bypass_shadow(struct device *dev);
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_postmask.c
> b/drivers/gpu/drm/mediatek/mtk_disp_postmask.c
> new file mode 100644
> index 0..d640cef9c15a4
> --- /dev/null
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_postmask.c
> @@ -0,0 +1,161 @@
> +/*
> + * SPDX-License-Identifier:
> + *
> + * Copyright (c) 2020 MediaTek Inc.
2021
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "mtk_disp_drv.h"
> +#include "mtk_drm_crtc.h"
> +#include "mtk_drm_ddp_comp.h"
> +
> +#define DISP_POSTMASK_EN 0x
> +#define POSTMASK_EN BIT(0)
> +#define DISP_POSTMASK_CFG0x0020
> +#define POSTMASK_RELAY_MODE BIT(0)
> +#define DISP_POSTMASK_SIZE 0x0030
> +
> +struct mtk_disp_postmask_data {
> + u32 reserved;
> +};
Useless, so remove.
> +
> +/**
> + * struct mtk_disp_postmask - DISP_postmask driver structure
> + * @ddp_comp - structure containing type enum and hardware resources
> + * @crtc - associated crtc to report irq events to
> + */
> +struct mtk_disp_postmask {
> + struct clk *clk;
> + void __iomem *regs;
> + struct cmdq_client_reg cmdq_reg;
> + const struct mtk_disp_postmask_data *data;
> +};
> +
> +int mtk_postmask_clk_enable(struct device *dev)
> +{
> + struct mtk_disp_postmask *postmask = dev_get_drvdata(dev);
> +
> + return clk_prepare_enable(postmask->clk);
> +}
> +
> +void mtk_postmask_clk_disable(struct device *dev)
> +{
> + struct mtk_disp_postmask *postmask = dev_get_drvdata(dev);
> +
> + clk_disable_unprepare(postmask->clk);
> +}
> +
> +void mtk_postmask_config(struct device *dev, unsigned int w,
> + unsigned int h, unsigned int vrefresh,
> + unsigned int bpc, struct cmdq_pkt *cmdq_pkt)
> +{
> + struct mtk_disp_postmask *postmask = dev_get_drvdata(dev);
> +
> + mtk_ddp_write(cmdq_pkt, w << 16 | h, >cmdq_reg,
> postmask->regs,
> + DISP_POSTMASK_SIZE);
> + mtk_ddp_write(cmdq_pkt, POSTMASK_RELAY_MODE, >cmdq_reg,
> + postmask->regs, DISP_POSTMASK_CFG);
> +}
> +
> +void mtk_postmask_start(struct device *dev)
> +{
> + struct mtk_disp_postmask *postmask = dev_get_drvdata(dev);
> +
> + writel(POSTMASK_EN, postmask->regs + DISP_POSTMASK_EN);
> +}
> +
> +void mtk_postmask_stop(struct device *dev)
> +{
> + struct mtk_disp_postmask *postmask = dev_get_drvdata(dev);
> +
> + writel_relaxed(0x0, postmask->regs + DISP_POSTMASK_EN);
> +}
> +
> +static int mtk_disp_postmask_bind(struct device *dev, struct device *master,
> void *data)
> +{
> + return 0;
> +}
> +
> +static void
[PATCH v4 7/8] soc: mediatek: add mtk mutex support for MT8192
From: Yongqiang Niu
Add mtk mutex support for MT8192 SoC.
Signed-off-by: Yongqiang Niu
Signed-off-by: Hsin-Yi Wang
---
drivers/soc/mediatek/mtk-mutex.c | 35
1 file changed, 35 insertions(+)
diff --git a/drivers/soc/mediatek/mtk-mutex.c b/drivers/soc/mediatek/mtk-mutex.c
index 718a41beb6afb..dfd9806d5a001 100644
--- a/drivers/soc/mediatek/mtk-mutex.c
+++ b/drivers/soc/mediatek/mtk-mutex.c
@@ -39,6 +39,18 @@
#define MT8167_MUTEX_MOD_DISP_DITHER 15
#define MT8167_MUTEX_MOD_DISP_UFOE 16
+#define MT8192_MUTEX_MOD_DISP_OVL0 0
+#define MT8192_MUTEX_MOD_DISP_OVL0_2L 1
+#define MT8192_MUTEX_MOD_DISP_RDMA02
+#define MT8192_MUTEX_MOD_DISP_COLOR0 4
+#define MT8192_MUTEX_MOD_DISP_CCORR0 5
+#define MT8192_MUTEX_MOD_DISP_AAL0 6
+#define MT8192_MUTEX_MOD_DISP_GAMMA0 7
+#define MT8192_MUTEX_MOD_DISP_POSTMASK08
+#define MT8192_MUTEX_MOD_DISP_DITHER0 9
+#define MT8192_MUTEX_MOD_DISP_OVL2_2L 16
+#define MT8192_MUTEX_MOD_DISP_RDMA417
+
#define MT8183_MUTEX_MOD_DISP_RDMA00
#define MT8183_MUTEX_MOD_DISP_RDMA11
#define MT8183_MUTEX_MOD_DISP_OVL0 9
@@ -214,6 +226,20 @@ static const unsigned int
mt8183_mutex_mod[DDP_COMPONENT_ID_MAX] = {
[DDP_COMPONENT_WDMA0] = MT8183_MUTEX_MOD_DISP_WDMA0,
};
+static const unsigned int mt8192_mutex_mod[DDP_COMPONENT_ID_MAX] = {
+ [DDP_COMPONENT_AAL0] = MT8192_MUTEX_MOD_DISP_AAL0,
+ [DDP_COMPONENT_CCORR] = MT8192_MUTEX_MOD_DISP_CCORR0,
+ [DDP_COMPONENT_COLOR0] = MT8192_MUTEX_MOD_DISP_COLOR0,
+ [DDP_COMPONENT_DITHER] = MT8192_MUTEX_MOD_DISP_DITHER0,
+ [DDP_COMPONENT_GAMMA] = MT8192_MUTEX_MOD_DISP_GAMMA0,
+ [DDP_COMPONENT_POSTMASK0] = MT8192_MUTEX_MOD_DISP_POSTMASK0,
+ [DDP_COMPONENT_OVL0] = MT8192_MUTEX_MOD_DISP_OVL0,
+ [DDP_COMPONENT_OVL_2L0] = MT8192_MUTEX_MOD_DISP_OVL0_2L,
+ [DDP_COMPONENT_OVL_2L2] = MT8192_MUTEX_MOD_DISP_OVL2_2L,
+ [DDP_COMPONENT_RDMA0] = MT8192_MUTEX_MOD_DISP_RDMA0,
+ [DDP_COMPONENT_RDMA4] = MT8192_MUTEX_MOD_DISP_RDMA4,
+};
+
static const unsigned int mt2712_mutex_sof[MUTEX_SOF_DSI3 + 1] = {
[MUTEX_SOF_SINGLE_MODE] = MUTEX_SOF_SINGLE_MODE,
[MUTEX_SOF_DSI0] = MUTEX_SOF_DSI0,
@@ -275,6 +301,13 @@ static const struct mtk_mutex_data
mt8183_mutex_driver_data = {
.no_clk = true,
};
+static const struct mtk_mutex_data mt8192_mutex_driver_data = {
+ .mutex_mod = mt8192_mutex_mod,
+ .mutex_sof = mt8183_mutex_sof,
+ .mutex_mod_reg = MT8183_MUTEX0_MOD0,
+ .mutex_sof_reg = MT8183_MUTEX0_SOF0,
+};
+
struct mtk_mutex *mtk_mutex_get(struct device *dev)
{
struct mtk_mutex_ctx *mtx = dev_get_drvdata(dev);
@@ -507,6 +540,8 @@ static const struct of_device_id mutex_driver_dt_match[] = {
.data = _mutex_driver_data},
{ .compatible = "mediatek,mt8183-disp-mutex",
.data = _mutex_driver_data},
+ { .compatible = "mediatek,mt8192-disp-mutex",
+ .data = _mutex_driver_data},
{},
};
MODULE_DEVICE_TABLE(of, mutex_driver_dt_match);
--
2.30.0.365.g02bc693789-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 2/8] drm/mediatek: add component POSTMASK
From: Yongqiang Niu
This patch add component POSTMASK,
Signed-off-by: Yongqiang Niu
Signed-off-by: Hsin-Yi Wang
---
drivers/gpu/drm/mediatek/Makefile| 1 +
drivers/gpu/drm/mediatek/mtk_disp_drv.h | 8 +
drivers/gpu/drm/mediatek/mtk_disp_postmask.c | 161 +++
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 11 ++
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 1 +
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 4 +-
drivers/gpu/drm/mediatek/mtk_drm_drv.h | 1 +
7 files changed, 186 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/mediatek/mtk_disp_postmask.c
diff --git a/drivers/gpu/drm/mediatek/Makefile
b/drivers/gpu/drm/mediatek/Makefile
index b64674b944860..13a0eafabf9c0 100644
--- a/drivers/gpu/drm/mediatek/Makefile
+++ b/drivers/gpu/drm/mediatek/Makefile
@@ -3,6 +3,7 @@
mediatek-drm-y := mtk_disp_color.o \
mtk_disp_gamma.o \
mtk_disp_ovl.o \
+ mtk_disp_postmask.o \
mtk_disp_rdma.o \
mtk_drm_crtc.o \
mtk_drm_ddp_comp.o \
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
index 02191010699f8..d74e85db3fcdf 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
+++ b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
@@ -37,6 +37,14 @@ void mtk_gamma_set_common(void __iomem *regs, struct
drm_crtc_state *state);
void mtk_gamma_start(struct device *dev);
void mtk_gamma_stop(struct device *dev);
+int mtk_postmask_clk_enable(struct device *dev);
+void mtk_postmask_clk_disable(struct device *dev);
+void mtk_postmask_config(struct device *dev, unsigned int w,
+ unsigned int h, unsigned int vrefresh,
+ unsigned int bpc, struct cmdq_pkt *cmdq_pkt);
+void mtk_postmask_start(struct device *dev);
+void mtk_postmask_stop(struct device *dev);
+
void mtk_ovl_bgclr_in_on(struct device *dev);
void mtk_ovl_bgclr_in_off(struct device *dev);
void mtk_ovl_bypass_shadow(struct device *dev);
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_postmask.c
b/drivers/gpu/drm/mediatek/mtk_disp_postmask.c
new file mode 100644
index 0..d640cef9c15a4
--- /dev/null
+++ b/drivers/gpu/drm/mediatek/mtk_disp_postmask.c
@@ -0,0 +1,161 @@
+/*
+ * SPDX-License-Identifier:
+ *
+ * Copyright (c) 2020 MediaTek Inc.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "mtk_disp_drv.h"
+#include "mtk_drm_crtc.h"
+#include "mtk_drm_ddp_comp.h"
+
+#define DISP_POSTMASK_EN 0x
+#define POSTMASK_ENBIT(0)
+#define DISP_POSTMASK_CFG 0x0020
+#define POSTMASK_RELAY_MODEBIT(0)
+#define DISP_POSTMASK_SIZE 0x0030
+
+struct mtk_disp_postmask_data {
+ u32 reserved;
+};
+
+/**
+ * struct mtk_disp_postmask - DISP_postmask driver structure
+ * @ddp_comp - structure containing type enum and hardware resources
+ * @crtc - associated crtc to report irq events to
+ */
+struct mtk_disp_postmask {
+ struct clk *clk;
+ void __iomem *regs;
+ struct cmdq_client_reg cmdq_reg;
+ const struct mtk_disp_postmask_data *data;
+};
+
+int mtk_postmask_clk_enable(struct device *dev)
+{
+ struct mtk_disp_postmask *postmask = dev_get_drvdata(dev);
+
+ return clk_prepare_enable(postmask->clk);
+}
+
+void mtk_postmask_clk_disable(struct device *dev)
+{
+ struct mtk_disp_postmask *postmask = dev_get_drvdata(dev);
+
+ clk_disable_unprepare(postmask->clk);
+}
+
+void mtk_postmask_config(struct device *dev, unsigned int w,
+unsigned int h, unsigned int vrefresh,
+unsigned int bpc, struct cmdq_pkt *cmdq_pkt)
+{
+ struct mtk_disp_postmask *postmask = dev_get_drvdata(dev);
+
+ mtk_ddp_write(cmdq_pkt, w << 16 | h, >cmdq_reg,
postmask->regs,
+ DISP_POSTMASK_SIZE);
+ mtk_ddp_write(cmdq_pkt, POSTMASK_RELAY_MODE, >cmdq_reg,
+ postmask->regs, DISP_POSTMASK_CFG);
+}
+
+void mtk_postmask_start(struct device *dev)
+{
+ struct mtk_disp_postmask *postmask = dev_get_drvdata(dev);
+
+ writel(POSTMASK_EN, postmask->regs + DISP_POSTMASK_EN);
+}
+
+void mtk_postmask_stop(struct device *dev)
+{
+ struct mtk_disp_postmask *postmask = dev_get_drvdata(dev);
+
+ writel_relaxed(0x0, postmask->regs + DISP_POSTMASK_EN);
+}
+
+static int mtk_disp_postmask_bind(struct device *dev, struct device *master,
void *data)
+{
+ return 0;
+}
+
+static void mtk_disp_postmask_unbind(struct device *dev, struct device *master,
+ void *data)
+{
+}
+
+static const struct component_ops mtk_disp_postmask_component_ops = {
+ .bind = mtk_disp_postmask_bind,
+ .unbind = mtk_disp_postmask_unbind,
+};
+
+static int mtk_disp_postmask_probe(struct platform_device *pdev)
+{
+
Re: [PATCH v12 6/8] drm/mediatek: enable dither function
On Fri, Jan 29, 2021 at 3:42 PM Yongqiang Niu
wrote:
>
> On Fri, 2021-01-29 at 14:46 +0800, Hsin-Yi Wang wrote:
> > On Fri, Jan 29, 2021 at 2:30 PM Yongqiang Niu
> > wrote:
> > >
> > > On Fri, 2021-01-29 at 14:24 +0800, Hsin-Yi Wang wrote:
> > > > On Fri, Jan 29, 2021 at 9:33 AM CK Hu wrote:
> > > > >
> > > > > Hi, Hsin-Yi:
> > > > >
> > > > > On Thu, 2021-01-28 at 19:23 +0800, Hsin-Yi Wang wrote:
> > > > > > From: Yongqiang Niu
> > > > > >
> > > > > > for 5 or 6 bpc panel, we need enable dither function
> > > > > > to improve the display quality
> > > > > >
> > > > > > Signed-off-by: Yongqiang Niu
> > > > > > Signed-off-by: Hsin-Yi Wang
> > > > > > ---
> > > > > > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 15 +--
> > > > > > 1 file changed, 13 insertions(+), 2 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > > > > > b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > > > > > index ac2cb25620357..6c8f246380a74 100644
> > > > > > --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > > > > > +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > > > > > @@ -53,6 +53,7 @@
> > > > > > #define DITHER_ENBIT(0)
> > > > > > #define DISP_DITHER_CFG 0x0020
> > > > > > #define DITHER_RELAY_MODEBIT(0)
> > > > > > +#define DITHER_ENGINE_EN BIT(1)
> > > > > > #define DISP_DITHER_SIZE 0x0030
> > > > > >
> > > > > > #define LUT_10BIT_MASK 0x03ff
> > > > > > @@ -314,9 +315,19 @@ static void mtk_dither_config(struct device
> > > > > > *dev, unsigned int w,
> > > > > > unsigned int bpc, struct cmdq_pkt
> > > > > > *cmdq_pkt)
> > > > > > {
> > > > > > struct mtk_ddp_comp_dev *priv = dev_get_drvdata(dev);
> > > > > > + bool enable = (bpc == 5 || bpc == 6);
> > > > >
> > > > > I strongly believe that dither function in dither is identical to the
> > > > > one in gamma and od, and in mtk_dither_set_common(), 'bpc >=
> > > > > MTK_MIN_BPC' is valid, so I believe we need not to limit bpc to 5 or
> > > > > 6.
> > > > > But we should consider the case that bpc is invalid in
> > > > > mtk_dither_set_common(). Invalid case in gamma and od use different
> > > > > way
> > > > > to process. For gamma, dither is default relay mode, so invalid bpc
> > > > > would do nothing in mtk_dither_set_common() and result in relay mode.
> > > > > For od, it set to relay mode first, them invalid bpc would do nothing
> > > > > in
> > > > > mtk_dither_set_common() and result in relay mode. I would like dither,
> > > > > gamma and od to process invalid bpc in the same way. One solution is
> > > > > to
> > > > > set relay mode in mtk_dither_set_common() for invalid bpc.
> > > > >
> > > > > Regards,
> > > > > CK
> > > > >
> > > >
> > > > I modify the mtk_dither_config() to follow:
> > > >
> > > >
> > > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > > > b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > > > index ac2cb25620357..5b7fcedb9f9a8 100644
> > > > --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > > > +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > > > @@ -53,6 +53,7 @@
> > > > #define DITHER_EN BIT(0)
> > > > #define DISP_DITHER_CFG0x0020
> > > > #define DITHER_RELAY_MODE BIT(0)
> > > > +#define DITHER_ENGINE_EN BIT(1)
> > > > #define DISP_DITHER_SIZE 0x0030
> > > >
> > > > #define LUT_10BIT_MASK 0x03ff
> > > > @@ -166,6 +167,8 @@ void mtk_dither_set_common(void __iomem *regs,
> > > > struct cmdq_client_reg *cmdq_reg,
> > > > DITHER_ADD_LSHIFT_G(MTK_MAX_BPC - bpc),
> > > > cmdq_reg, regs, DISP_DITHER_16);
> > > > mtk_ddp_write(cmdq_pkt, dither_en, cmdq_reg, regs, cfg);
> > > > + } else {
> > > > + mtk_ddp_write(cmdq_pkt, DITHER_RELAY_MODE, cmdq_reg,
> > > > regs, cfg);
> > > > }
> > > > }
> > > >
> > > > @@ -315,8 +318,12 @@ static void mtk_dither_config(struct device *dev,
> > > > unsigned int w,
> > > > {
> > > > struct mtk_ddp_comp_dev *priv = dev_get_drvdata(dev);
> > > >
> > > > - mtk_ddp_write(cmdq_pkt, h << 16 | w, >cmdq_reg,
> > > > priv->regs, DISP_DITHER_SIZE);
> > > > - mtk_ddp_write(cmdq_pkt, DITHER_RELAY_MODE, >cmdq_reg,
> > > > priv->regs, DISP_DITHER_CFG);
> > > > + mtk_ddp_write(cmdq_pkt, h << 16 | w, >cmdq_reg,
> > > > priv->regs,
> > > > + DISP_DITHER_SIZE);
> > > > + mtk_ddp_write(cmdq_pkt, DITHER_RELAY_MODE, >cmdq_reg,
> > > > priv->regs,
> > > > + DISP_DITHER_CFG);
> > > > + mtk_dither_set_common(priv->regs, >cmdq_reg, bpc,
> > > > DISP_DITHER_CFG,
> > > > + DITHER_ENGINE_EN,
Re: [PATCH v12 6/8] drm/mediatek: enable dither function
On Fri, Jan 29, 2021 at 9:33 AM CK Hu wrote:
>
> Hi, Hsin-Yi:
>
> On Thu, 2021-01-28 at 19:23 +0800, Hsin-Yi Wang wrote:
> > From: Yongqiang Niu
> >
> > for 5 or 6 bpc panel, we need enable dither function
> > to improve the display quality
> >
> > Signed-off-by: Yongqiang Niu
> > Signed-off-by: Hsin-Yi Wang
> > ---
> > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 15 +--
> > 1 file changed, 13 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > index ac2cb25620357..6c8f246380a74 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > @@ -53,6 +53,7 @@
> > #define DITHER_ENBIT(0)
> > #define DISP_DITHER_CFG 0x0020
> > #define DITHER_RELAY_MODEBIT(0)
> > +#define DITHER_ENGINE_EN BIT(1)
> > #define DISP_DITHER_SIZE 0x0030
> >
> > #define LUT_10BIT_MASK 0x03ff
> > @@ -314,9 +315,19 @@ static void mtk_dither_config(struct device *dev,
> > unsigned int w,
> > unsigned int bpc, struct cmdq_pkt *cmdq_pkt)
> > {
> > struct mtk_ddp_comp_dev *priv = dev_get_drvdata(dev);
> > + bool enable = (bpc == 5 || bpc == 6);
>
> I strongly believe that dither function in dither is identical to the
> one in gamma and od, and in mtk_dither_set_common(), 'bpc >=
> MTK_MIN_BPC' is valid, so I believe we need not to limit bpc to 5 or 6.
> But we should consider the case that bpc is invalid in
> mtk_dither_set_common(). Invalid case in gamma and od use different way
> to process. For gamma, dither is default relay mode, so invalid bpc
> would do nothing in mtk_dither_set_common() and result in relay mode.
> For od, it set to relay mode first, them invalid bpc would do nothing in
> mtk_dither_set_common() and result in relay mode. I would like dither,
> gamma and od to process invalid bpc in the same way. One solution is to
> set relay mode in mtk_dither_set_common() for invalid bpc.
>
> Regards,
> CK
>
I modify the mtk_dither_config() to follow:
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index ac2cb25620357..5b7fcedb9f9a8 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -53,6 +53,7 @@
#define DITHER_EN BIT(0)
#define DISP_DITHER_CFG0x0020
#define DITHER_RELAY_MODE BIT(0)
+#define DITHER_ENGINE_EN BIT(1)
#define DISP_DITHER_SIZE 0x0030
#define LUT_10BIT_MASK 0x03ff
@@ -166,6 +167,8 @@ void mtk_dither_set_common(void __iomem *regs,
struct cmdq_client_reg *cmdq_reg,
DITHER_ADD_LSHIFT_G(MTK_MAX_BPC - bpc),
cmdq_reg, regs, DISP_DITHER_16);
mtk_ddp_write(cmdq_pkt, dither_en, cmdq_reg, regs, cfg);
+ } else {
+ mtk_ddp_write(cmdq_pkt, DITHER_RELAY_MODE, cmdq_reg, regs, cfg);
}
}
@@ -315,8 +318,12 @@ static void mtk_dither_config(struct device *dev,
unsigned int w,
{
struct mtk_ddp_comp_dev *priv = dev_get_drvdata(dev);
- mtk_ddp_write(cmdq_pkt, h << 16 | w, >cmdq_reg,
priv->regs, DISP_DITHER_SIZE);
- mtk_ddp_write(cmdq_pkt, DITHER_RELAY_MODE, >cmdq_reg,
priv->regs, DISP_DITHER_CFG);
+ mtk_ddp_write(cmdq_pkt, h << 16 | w, >cmdq_reg, priv->regs,
+ DISP_DITHER_SIZE);
+ mtk_ddp_write(cmdq_pkt, DITHER_RELAY_MODE, >cmdq_reg, priv->regs,
+ DISP_DITHER_CFG);
+ mtk_dither_set_common(priv->regs, >cmdq_reg, bpc, DISP_DITHER_CFG,
+ DITHER_ENGINE_EN, cmdq_pkt);
}
So now, not only bpc==5 or 6, but all valid bpc, dither config will
call mtk_dither_set_common() with the flag DITHER_ENGINE_EN(BIT(1)).
od config will call mtk_dither_set_common() with the flag
DISP_DITHERING(BIT(2)).
Additionally for 8173, gamma config will call mtk_dither_set_common()
with the flag DISP_DITHERING (BIT(2))
For invalid mode all of them will be DITHER_RELAY_MODE.
Just to make sure that this follows the spec? thanks
> >
> > - mtk_ddp_write(cmdq_pkt, h << 16 | w, >cmdq_reg, priv->regs,
> > DISP_DITHER_SIZE);
> > - mtk_ddp_write(cmdq_pkt, DITHER_RELAY_MODE, >cmdq_reg,
> > priv->regs, DISP_DITHER_CFG);
> > + if (enable) {
> > + mtk_dither_set_common(priv->regs, >cmdq_reg, bpc,
> > + DISP_DITHER_CFG, DITHER_ENGINE_EN,
> > + cmdq_pkt);
> > + } else {
> > + mtk_ddp_write(cmdq_pkt, DITHER_RELAY_MODE, >cmdq_reg,
> > + priv->regs, DISP_DITHER_CFG);
> > + }
> > +
> > +
[PATCH v4 1/8] drm/mediatek: add component OVL_2L2
From: Yongqiang Niu
This patch add component OVL_2L2
Signed-off-by: Yongqiang Niu
Reviewed-by: Chun-Kuang Hu
Signed-off-by: Hsin-Yi Wang
---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index 5b7fcedb9f9a8..ccfaada998cf5 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -479,6 +479,7 @@ static const struct mtk_ddp_comp_match
mtk_ddp_matches[DDP_COMPONENT_ID_MAX] = {
[DDP_COMPONENT_OVL1]= { MTK_DISP_OVL, 1, _ovl },
[DDP_COMPONENT_OVL_2L0] = { MTK_DISP_OVL_2L,0, _ovl },
[DDP_COMPONENT_OVL_2L1] = { MTK_DISP_OVL_2L,1, _ovl },
+ [DDP_COMPONENT_OVL_2L2] = { MTK_DISP_OVL_2L,2, _ovl },
[DDP_COMPONENT_PWM0]= { MTK_DISP_PWM, 0, NULL },
[DDP_COMPONENT_PWM1]= { MTK_DISP_PWM, 1, NULL },
[DDP_COMPONENT_PWM2]= { MTK_DISP_PWM, 2, NULL },
--
2.30.0.365.g02bc693789-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 6/8] drm/mediatek: add matrix bits private data for ccorr
From: Yongqiang Niu
matrix bits of mt8183 is 12
matrix bits of mt8192 is 13
Signed-off-by: Yongqiang Niu
Signed-off-by: Hsin-Yi Wang
---
drivers/gpu/drm/mediatek/mtk_disp_ccorr.c | 22 +++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
b/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
index 0c68090eb1e92..1c7163a12f3b1 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
@@ -31,8 +31,10 @@
#define DISP_CCORR_COEF_3 0x008C
#define DISP_CCORR_COEF_4 0x0090
+#define CCORR_MATRIX_BITS 12
+
struct mtk_disp_ccorr_data {
- u32 reserved;
+ u32 matrix_bits;
};
/**
@@ -116,6 +118,7 @@ void mtk_ccorr_ctm_set(struct device *dev, struct
drm_crtc_state *state)
uint16_t coeffs[9] = { 0 };
int i;
struct cmdq_pkt *cmdq_pkt = NULL;
+ u32 matrix_bits;
if (!blob)
return;
@@ -123,8 +126,16 @@ void mtk_ccorr_ctm_set(struct device *dev, struct
drm_crtc_state *state)
ctm = (struct drm_color_ctm *)blob->data;
input = ctm->matrix;
- for (i = 0; i < ARRAY_SIZE(coeffs); i++)
+ if (ccorr->data)
+ matrix_bits = ccorr->data->matrix_bits;
+ else
+ matrix_bits = CCORR_MATRIX_BITS;
+
+ for (i = 0; i < ARRAY_SIZE(coeffs); i++) {
coeffs[i] = mtk_ctm_s31_32_to_s1_10(input[i]);
+ if (matrix_bits > CCORR_MATRIX_BITS)
+ coeffs[i] <<= (matrix_bits - CCORR_MATRIX_BITS);
+ }
mtk_ddp_write(cmdq_pkt, coeffs[0] << 16 | coeffs[1],
>cmdq_reg, ccorr->regs, DISP_CCORR_COEF_0);
@@ -205,8 +216,13 @@ static int mtk_disp_ccorr_remove(struct platform_device
*pdev)
return 0;
}
+static const struct mtk_disp_ccorr_data mt8183_ccorr_driver_data = {
+ .matrix_bits = CCORR_MATRIX_BITS,
+};
+
static const struct of_device_id mtk_disp_ccorr_driver_dt_match[] = {
- { .compatible = "mediatek,mt8183-disp-ccorr"},
+ { .compatible = "mediatek,mt8183-disp-ccorr",
+ .data = _ccorr_driver_data},
{},
};
MODULE_DEVICE_TABLE(of, mtk_disp_ccorr_driver_dt_match);
--
2.30.0.365.g02bc693789-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v12 6/8] drm/mediatek: enable dither function
On Fri, Jan 29, 2021 at 2:30 PM Yongqiang Niu
wrote:
>
> On Fri, 2021-01-29 at 14:24 +0800, Hsin-Yi Wang wrote:
> > On Fri, Jan 29, 2021 at 9:33 AM CK Hu wrote:
> > >
> > > Hi, Hsin-Yi:
> > >
> > > On Thu, 2021-01-28 at 19:23 +0800, Hsin-Yi Wang wrote:
> > > > From: Yongqiang Niu
> > > >
> > > > for 5 or 6 bpc panel, we need enable dither function
> > > > to improve the display quality
> > > >
> > > > Signed-off-by: Yongqiang Niu
> > > > Signed-off-by: Hsin-Yi Wang
> > > > ---
> > > > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 15 +--
> > > > 1 file changed, 13 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > > > b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > > > index ac2cb25620357..6c8f246380a74 100644
> > > > --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > > > +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > > > @@ -53,6 +53,7 @@
> > > > #define DITHER_ENBIT(0)
> > > > #define DISP_DITHER_CFG 0x0020
> > > > #define DITHER_RELAY_MODEBIT(0)
> > > > +#define DITHER_ENGINE_EN BIT(1)
> > > > #define DISP_DITHER_SIZE 0x0030
> > > >
> > > > #define LUT_10BIT_MASK 0x03ff
> > > > @@ -314,9 +315,19 @@ static void mtk_dither_config(struct device *dev,
> > > > unsigned int w,
> > > > unsigned int bpc, struct cmdq_pkt *cmdq_pkt)
> > > > {
> > > > struct mtk_ddp_comp_dev *priv = dev_get_drvdata(dev);
> > > > + bool enable = (bpc == 5 || bpc == 6);
> > >
> > > I strongly believe that dither function in dither is identical to the
> > > one in gamma and od, and in mtk_dither_set_common(), 'bpc >=
> > > MTK_MIN_BPC' is valid, so I believe we need not to limit bpc to 5 or 6.
> > > But we should consider the case that bpc is invalid in
> > > mtk_dither_set_common(). Invalid case in gamma and od use different way
> > > to process. For gamma, dither is default relay mode, so invalid bpc
> > > would do nothing in mtk_dither_set_common() and result in relay mode.
> > > For od, it set to relay mode first, them invalid bpc would do nothing in
> > > mtk_dither_set_common() and result in relay mode. I would like dither,
> > > gamma and od to process invalid bpc in the same way. One solution is to
> > > set relay mode in mtk_dither_set_common() for invalid bpc.
> > >
> > > Regards,
> > > CK
> > >
> >
> > I modify the mtk_dither_config() to follow:
> >
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > index ac2cb25620357..5b7fcedb9f9a8 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > @@ -53,6 +53,7 @@
> > #define DITHER_EN BIT(0)
> > #define DISP_DITHER_CFG0x0020
> > #define DITHER_RELAY_MODE BIT(0)
> > +#define DITHER_ENGINE_EN BIT(1)
> > #define DISP_DITHER_SIZE 0x0030
> >
> > #define LUT_10BIT_MASK 0x03ff
> > @@ -166,6 +167,8 @@ void mtk_dither_set_common(void __iomem *regs,
> > struct cmdq_client_reg *cmdq_reg,
> > DITHER_ADD_LSHIFT_G(MTK_MAX_BPC - bpc),
> > cmdq_reg, regs, DISP_DITHER_16);
> > mtk_ddp_write(cmdq_pkt, dither_en, cmdq_reg, regs, cfg);
> > + } else {
> > + mtk_ddp_write(cmdq_pkt, DITHER_RELAY_MODE, cmdq_reg, regs,
> > cfg);
> > }
> > }
> >
> > @@ -315,8 +318,12 @@ static void mtk_dither_config(struct device *dev,
> > unsigned int w,
> > {
> > struct mtk_ddp_comp_dev *priv = dev_get_drvdata(dev);
> >
> > - mtk_ddp_write(cmdq_pkt, h << 16 | w, >cmdq_reg,
> > priv->regs, DISP_DITHER_SIZE);
> > - mtk_ddp_write(cmdq_pkt, DITHER_RELAY_MODE, >cmdq_reg,
> > priv->regs, DISP_DITHER_CFG);
> > + mtk_ddp_write(cmdq_pkt, h << 16 | w, >cmdq_reg, priv->regs,
> > + DISP_DITHER_SIZE);
> > + mtk_ddp_write(cmdq_pkt, DITHER_RELAY_MODE, >cmdq_reg,
> > priv->regs,
> > + DISP_DITHER_CFG);
> > + mtk_dither_set_common(priv->regs, >cmdq_reg, bpc,
> > DISP_DITHER_CFG,
> > + DITHER_ENGINE_EN, cmdq_pkt);
> > }
> >
> > So now, not only bpc==5 or 6, but all valid bpc, dither config will
> > call mtk_dither_set_common() with the flag DITHER_ENGINE_EN(BIT(1)).
> > od config will call mtk_dither_set_common() with the flag
> > DISP_DITHERING(BIT(2)).
> > Additionally for 8173, gamma config will call mtk_dither_set_common()
> > with the flag DISP_DITHERING (BIT(2))
> >
> > For invalid mode all of them will be DITHER_RELAY_MODE.
> >
> > Just to make sure that this follows the spec? thanks
> >
>
> for mt8173 gamma, there is no relay mode, only dither enable or not(bit
[PATCH] drm/tilcdc: send vblank event when disabling crtc
From: Quanyang Wang
When run xrandr to change resolution on Beaglebone Black board, it will
print the error information:
root@beaglebone:~# xrandr -display :0 --output HDMI-1 --mode 720x400
[drm:drm_crtc_commit_wait] *ERROR* flip_done timed out
[drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CRTC:32:tilcdc crtc]
commit wait timed out
[drm:drm_crtc_commit_wait] *ERROR* flip_done timed out
[drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CONNECTOR:34:HDMI-A-1]
commit wait timed out
[drm:drm_crtc_commit_wait] *ERROR* flip_done timed out
[drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [PLANE:31:plane-0] commit
wait timed out
tilcdc 4830e000.lcdc: already pending page flip!
This is because there is operation sequence as below:
drm_atomic_connector_commit_dpms(mode is DRM_MODE_DPMS_OFF):
...
drm_atomic_helper_setup_commit <- init_completion(commit_A->flip_done)
drm_atomic_helper_commit_tail
tilcdc_crtc_atomic_disable
tilcdc_plane_atomic_update <- drm_crtc_send_vblank_event in
tilcdc_crtc_irq
is skipped since tilcdc_crtc->enabled is 0
tilcdc_crtc_atomic_flush <- drm_crtc_send_vblank_event is skipped
since
crtc->state->event is set to be NULL in
tilcdc_plane_atomic_update
drm_mode_setcrtc:
...
drm_atomic_helper_setup_commit <- init_completion(commit_B->flip_done)
drm_atomic_helper_wait_for_dependencies
drm_crtc_commit_wait <- wait for commit_A->flip_done completing
Just as shown above, the steps which could complete commit_A->flip_done
are all skipped and commit_A->flip_done will never be completed. This will
result a time-out ERROR when drm_crtc_commit_wait check the commit_A->flip_done.
So add drm_crtc_send_vblank_event in tilcdc_crtc_atomic_disable to
complete commit_A->flip_done.
Fixes: cb345decb4d2 ("drm/tilcdc: Use standard drm_atomic_helper_commit")
Signed-off-by: Quanyang Wang
---
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index 30213708fc99..d99afd19ca08 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -515,6 +515,15 @@ static void tilcdc_crtc_off(struct drm_crtc *crtc, bool
shutdown)
drm_crtc_vblank_off(crtc);
+ spin_lock_irq(>dev->event_lock);
+
+ if (crtc->state->event) {
+ drm_crtc_send_vblank_event(crtc, crtc->state->event);
+ crtc->state->event = NULL;
+ }
+
+ spin_unlock_irq(>dev->event_lock);
+
tilcdc_crtc_disable_irqs(dev);
pm_runtime_put_sync(dev->dev);
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 0/8] drm/mediatek: add support for mediatek SOC MT8192
This series are based on kernel/git/chunkuang.hu/linux.git mediatek-drm-next This series also depends on component support in mmsys[1]: - [v4,06/10] soc: mediatek: mmsys: add component OVL_2L2 - [v4,07/10] soc: mediatek: mmsys: add component POSTMASK - [v4,08/10] soc: mediatek: mmsys: add component RDMA4 [1] https://patchwork.kernel.org/project/linux-mediatek/patch/1609815993-22744-7-git-send-email-yongqiang@mediatek.com/ Change since v3: - change several function to rebase to mediatek-drm-next - drop pm runtime patches due to it's not related to mt8192 support - fix review comments in v3 Changes since v2: - fix review comment in v2 - add pm runtime for gamma and color - move ddp path select patch to mmsys series - remove some useless patch Yongqiang Niu (8): drm/mediatek: add component OVL_2L2 drm/mediatek: add component POSTMASK drm/mediatek: add component RDMA4 drm/mediatek: enable OVL_LAYER_SMI_ID_EN for multi-layer usecase drm/mediatek: separate ccorr module drm/mediatek: add matrix bits private data for ccorr soc: mediatek: add mtk mutex support for MT8192 drm/mediatek: add support for mediatek SOC MT8192 drivers/gpu/drm/mediatek/Makefile| 4 +- drivers/gpu/drm/mediatek/mtk_disp_ccorr.c| 244 +++ drivers/gpu/drm/mediatek/mtk_disp_drv.h | 17 ++ drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 37 +++ drivers/gpu/drm/mediatek/mtk_disp_postmask.c | 162 drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 6 + drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 108 ++-- drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 1 + drivers/gpu/drm/mediatek/mtk_drm_drv.c | 52 +++- drivers/gpu/drm/mediatek/mtk_drm_drv.h | 2 + drivers/soc/mediatek/mtk-mutex.c | 35 +++ 11 files changed, 572 insertions(+), 96 deletions(-) create mode 100644 drivers/gpu/drm/mediatek/mtk_disp_ccorr.c create mode 100644 drivers/gpu/drm/mediatek/mtk_disp_postmask.c -- 2.30.0.365.g02bc693789-goog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v12 6/8] drm/mediatek: enable dither function
On Fri, 2021-01-29 at 14:46 +0800, Hsin-Yi Wang wrote:
> On Fri, Jan 29, 2021 at 2:30 PM Yongqiang Niu
> wrote:
> >
> > On Fri, 2021-01-29 at 14:24 +0800, Hsin-Yi Wang wrote:
> > > On Fri, Jan 29, 2021 at 9:33 AM CK Hu wrote:
> > > >
> > > > Hi, Hsin-Yi:
> > > >
> > > > On Thu, 2021-01-28 at 19:23 +0800, Hsin-Yi Wang wrote:
> > > > > From: Yongqiang Niu
> > > > >
> > > > > for 5 or 6 bpc panel, we need enable dither function
> > > > > to improve the display quality
> > > > >
> > > > > Signed-off-by: Yongqiang Niu
> > > > > Signed-off-by: Hsin-Yi Wang
> > > > > ---
> > > > > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 15 +--
> > > > > 1 file changed, 13 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > > > > b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > > > > index ac2cb25620357..6c8f246380a74 100644
> > > > > --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > > > > +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > > > > @@ -53,6 +53,7 @@
> > > > > #define DITHER_ENBIT(0)
> > > > > #define DISP_DITHER_CFG 0x0020
> > > > > #define DITHER_RELAY_MODEBIT(0)
> > > > > +#define DITHER_ENGINE_EN BIT(1)
> > > > > #define DISP_DITHER_SIZE 0x0030
> > > > >
> > > > > #define LUT_10BIT_MASK 0x03ff
> > > > > @@ -314,9 +315,19 @@ static void mtk_dither_config(struct device
> > > > > *dev, unsigned int w,
> > > > > unsigned int bpc, struct cmdq_pkt
> > > > > *cmdq_pkt)
> > > > > {
> > > > > struct mtk_ddp_comp_dev *priv = dev_get_drvdata(dev);
> > > > > + bool enable = (bpc == 5 || bpc == 6);
> > > >
> > > > I strongly believe that dither function in dither is identical to the
> > > > one in gamma and od, and in mtk_dither_set_common(), 'bpc >=
> > > > MTK_MIN_BPC' is valid, so I believe we need not to limit bpc to 5 or 6.
> > > > But we should consider the case that bpc is invalid in
> > > > mtk_dither_set_common(). Invalid case in gamma and od use different way
> > > > to process. For gamma, dither is default relay mode, so invalid bpc
> > > > would do nothing in mtk_dither_set_common() and result in relay mode.
> > > > For od, it set to relay mode first, them invalid bpc would do nothing in
> > > > mtk_dither_set_common() and result in relay mode. I would like dither,
> > > > gamma and od to process invalid bpc in the same way. One solution is to
> > > > set relay mode in mtk_dither_set_common() for invalid bpc.
> > > >
> > > > Regards,
> > > > CK
> > > >
> > >
> > > I modify the mtk_dither_config() to follow:
> > >
> > >
> > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > > b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > > index ac2cb25620357..5b7fcedb9f9a8 100644
> > > --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > > +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > > @@ -53,6 +53,7 @@
> > > #define DITHER_EN BIT(0)
> > > #define DISP_DITHER_CFG0x0020
> > > #define DITHER_RELAY_MODE BIT(0)
> > > +#define DITHER_ENGINE_EN BIT(1)
> > > #define DISP_DITHER_SIZE 0x0030
> > >
> > > #define LUT_10BIT_MASK 0x03ff
> > > @@ -166,6 +167,8 @@ void mtk_dither_set_common(void __iomem *regs,
> > > struct cmdq_client_reg *cmdq_reg,
> > > DITHER_ADD_LSHIFT_G(MTK_MAX_BPC - bpc),
> > > cmdq_reg, regs, DISP_DITHER_16);
> > > mtk_ddp_write(cmdq_pkt, dither_en, cmdq_reg, regs, cfg);
> > > + } else {
> > > + mtk_ddp_write(cmdq_pkt, DITHER_RELAY_MODE, cmdq_reg,
> > > regs, cfg);
> > > }
> > > }
> > >
> > > @@ -315,8 +318,12 @@ static void mtk_dither_config(struct device *dev,
> > > unsigned int w,
> > > {
> > > struct mtk_ddp_comp_dev *priv = dev_get_drvdata(dev);
> > >
> > > - mtk_ddp_write(cmdq_pkt, h << 16 | w, >cmdq_reg,
> > > priv->regs, DISP_DITHER_SIZE);
> > > - mtk_ddp_write(cmdq_pkt, DITHER_RELAY_MODE, >cmdq_reg,
> > > priv->regs, DISP_DITHER_CFG);
> > > + mtk_ddp_write(cmdq_pkt, h << 16 | w, >cmdq_reg, priv->regs,
> > > + DISP_DITHER_SIZE);
> > > + mtk_ddp_write(cmdq_pkt, DITHER_RELAY_MODE, >cmdq_reg,
> > > priv->regs,
> > > + DISP_DITHER_CFG);
> > > + mtk_dither_set_common(priv->regs, >cmdq_reg, bpc,
> > > DISP_DITHER_CFG,
> > > + DITHER_ENGINE_EN, cmdq_pkt);
> > > }
> > >
> > > So now, not only bpc==5 or 6, but all valid bpc, dither config will
> > > call mtk_dither_set_common() with the flag DITHER_ENGINE_EN(BIT(1)).
> > > od config will call mtk_dither_set_common() with the flag
> > > DISP_DITHERING(BIT(2)).
> > > Additionally for 8173, gamma config
Re: [PATCH v12] staging: fbtft: add tearing signal detect
On Thu, 28 Jan 2021 16:33:02 +0200
Andy Shevchenko wrote:
> On Thu, Jan 28, 2021 at 2:58 PM Carlis wrote:
>
> Thanks for your contribution, my comments below.
>
> > From: zhangxuezhi
>
> You probably have to configure your Git to use the same account for
> author and committer.
hi,you mean like below:
Carlis
?
>
> > For st7789v ic,when we need continuous full screen refresh, it is
> > best to
>
> 'ic,when' -> 'IC, when'
>
> > wait for the TE signal arrive to avoid screen tearing
>
> Decode TE for people who are not familiar with the abbreviation.
>
> Missed period at the end of sentence.
>
> ...
>
> > #include
> > #include
> > #include
> > +#include
> > +#include
> > #include
> > +#include
> > +
>
> Good, but I would rather squeeze it above to be more or less ordered,
> like just after delay.h inclusion.
>
> > #include
>
> ...
>
> > +#define SPI_PANEL_TE_TIMEOUT 400 /* msecs */
>
> Useless comment. Instead use _MS suffix in the name of constant.
> Besides that please add a comment explaining why this value has been
> chosen.
>
> ...
>
> > +static struct completion spi_panel_te;
>
> As Greg said.
>
> ...
>
> > static int init_display(struct fbtft_par *par)
> > {
> > + int rc;
> > + struct device *dev = par->info->device;
>
> Keep reversed xmas tree order:
>
>struct device *dev = par->info->device;
>int rc;
>
> ...
>
> > + par->gpio.te = devm_gpiod_get_index_optional(dev, "te", 0,
> > GPIOD_IN);
>
> No need to have it requested for all time since you use it as an IRQ
> later on. The IRQ chip will call the GPIO library framework to lock a
> pin as IRQ anyway.
>
> > + if (IS_ERR(par->gpio.te))
> > + return dev_err_probe(par->info->device,
> > PTR_ERR(par->gpio.te),
> > +"Failed to request te
> > gpio\n");
>
> > + if (par->gpio.te) {
>
> Instead you should probably do the following:
>
> int irq;
>
> irq = gpiod_to_irq(...);
> if (irq > 0)
>
> > + init_completion(_panel_te);
> > + rc = devm_request_irq(dev,
>
> > + gpiod_to_irq(par->gpio.te),
>
> ...and here simply use irq.
>
> > +spi_panel_te_handler,
> > IRQF_TRIGGER_RISING,
> > +"TE_GPIO", par);
>
> > + if (IS_ERR(rc))
>
> This is wrong. rc is integer no IS_ERR() is required. Ditto for
> PTR_ERR(). Have you even looked for these macros implementations?
>
> > + return dev_err_probe(par->info->device,
> > PTR_ERR(rc),
>
> Use your temporary variable and move...
>
> > +"TE request_irq
> > failed.\n");
>
> ...this on the previous line.
>
> > + disable_irq_nosync(gpiod_to_irq(par->gpio.te));
>
> Why do you call gpio_to_irq() twice?
>
>
> > + } else {
> > + dev_info(par->info->device, "%s:%d, TE gpio not
> > specified\n",
> > +__func__, __LINE__);
>
> Remove this noise (besides the fact that we don't use __file__ and
> __LINE__ in messages like this.
>
> > + }
>
> Taking all together you probably need to create a helper and use it
> inside init_display(), like
>
> static int init_tearing_effect_line(struct fbtft_par *par)
> {
> struct device *dev = par->info->device;
> struct gpio_desc *te;
> int irq, rc;
>
> te = gpiod_get_optional(dev, "te", GPIOD_IN);
> if (IS_ERR(te))
>return dev_err_probe(dev, PTR_ERR(te), "Failed to request
> te GPIO\n");
>
> irq = gpiod_to_irq(te); // this value you have to save in the
> driver's (per device) data structure.
>
> /* GPIO is locked as an IRQ, we may drop the reference */
> gpiod_put(te);
>
> init_completion(_panel_te); // should be in the (per device)
> data structure
> rc = devm_request_irq(dev, irq, spi_panel_te_handler,
> IRQF_TRIGGER_RISING, "TE_GPIO", par);
> if (rc)
> return dev_err_probe(dev, rc, "TE IRQ request
> failed.\n"); disable_irq_nosync(irq);
> return irq;
> }
>
hi, i have modified it according to your suggestion like below:
static irqreturn_t panel_te_handler(int irq, void *data)
{
struct fbtft_par *par = (struct fbtft_par *)data;
complete(>panel_te);
return IRQ_HANDLED;
}
/**
* init_tearing_effect_line() - init tearing effect line
*
* @par: FBTFT parameter object
*
* Return: 0 on success, < 0 if error occurred.
*/
static int init_tearing_effect_line(struct fbtft_par *par)
{
struct device *dev = par->info->device;
struct gpio_desc *te;
int rc;
te = gpiod_get_optional(dev, "te", GPIOD_IN);
if (IS_ERR(te))
return dev_err_probe(dev, PTR_ERR(te), "Failed to
request te GPIO\n");
if (te) {
par->irq_te = gpiod_to_irq(te);
[PATCH] drm/etnaviv: fix coccicheck by ifnullfree.cocci
Fixes coccicheck warning: ./drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c:616:2-8: WARNING: NULL check before some freeing functions is not needed. ./drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c:618:2-8: WARNING: NULL check before some freeing functions is not needed. ./drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c:620:2-8: WARNING: NULL check before some freeing functions is not needed. ./drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c:622:2-8: WARNING: NULL check before some freeing functions is not needed. Signed-off-by: Tian Tao --- drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 12 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c index d05c359..bd0d66e 100644 --- a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c @@ -612,14 +612,10 @@ int etnaviv_ioctl_gem_submit(struct drm_device *dev, void *data, err_submit_cmds: if (ret && (out_fence_fd >= 0)) put_unused_fd(out_fence_fd); - if (stream) - kvfree(stream); - if (bos) - kvfree(bos); - if (relocs) - kvfree(relocs); - if (pmrs) - kvfree(pmrs); + kvfree(stream); + kvfree(bos); + kvfree(relocs); + kvfree(pmrs); return ret; } -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 8/8] drm/mediatek: add support for mediatek SOC MT8192
From: Yongqiang Niu
add support for mediatek SOC MT8192
Signed-off-by: Yongqiang Niu
Signed-off-by: Hsin-Yi Wang
---
drivers/gpu/drm/mediatek/mtk_disp_ccorr.c| 6 +++
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 20 ++
drivers/gpu/drm/mediatek/mtk_disp_postmask.c | 1 +
drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 6 +++
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 42
5 files changed, 75 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
b/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
index 1c7163a12f3b1..43794192e82b1 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
@@ -220,9 +220,15 @@ static const struct mtk_disp_ccorr_data
mt8183_ccorr_driver_data = {
.matrix_bits = CCORR_MATRIX_BITS,
};
+static const struct mtk_disp_ccorr_data mt8192_ccorr_driver_data = {
+ .matrix_bits = 13,
+};
+
static const struct of_device_id mtk_disp_ccorr_driver_dt_match[] = {
{ .compatible = "mediatek,mt8183-disp-ccorr",
.data = _ccorr_driver_data},
+ { .compatible = "mediatek,mt8192-disp-ccorr",
+ .data = _ccorr_driver_data},
{},
};
MODULE_DEVICE_TABLE(of, mtk_disp_ccorr_driver_dt_match);
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index 961f87f8d4d15..e266baae586c4 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -455,6 +455,22 @@ static const struct mtk_disp_ovl_data
mt8183_ovl_2l_driver_data = {
.fmt_rgb565_is_0 = true,
};
+static const struct mtk_disp_ovl_data mt8192_ovl_driver_data = {
+ .addr = DISP_REG_OVL_ADDR_MT8173,
+ .gmc_bits = 10,
+ .layer_nr = 4,
+ .fmt_rgb565_is_0 = true,
+ .smi_id_en = true,
+};
+
+static const struct mtk_disp_ovl_data mt8192_ovl_2l_driver_data = {
+ .addr = DISP_REG_OVL_ADDR_MT8173,
+ .gmc_bits = 10,
+ .layer_nr = 2,
+ .fmt_rgb565_is_0 = true,
+ .smi_id_en = true,
+};
+
static const struct of_device_id mtk_disp_ovl_driver_dt_match[] = {
{ .compatible = "mediatek,mt2701-disp-ovl",
.data = _ovl_driver_data},
@@ -464,6 +480,10 @@ static const struct of_device_id
mtk_disp_ovl_driver_dt_match[] = {
.data = _ovl_driver_data},
{ .compatible = "mediatek,mt8183-disp-ovl-2l",
.data = _ovl_2l_driver_data},
+ { .compatible = "mediatek,mt8192-disp-ovl",
+ .data = _ovl_driver_data},
+ { .compatible = "mediatek,mt8192-disp-ovl-2l",
+ .data = _ovl_2l_driver_data},
{},
};
MODULE_DEVICE_TABLE(of, mtk_disp_ovl_driver_dt_match);
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_postmask.c
b/drivers/gpu/drm/mediatek/mtk_disp_postmask.c
index d640cef9c15a4..62c8431a09605 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_postmask.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_postmask.c
@@ -146,6 +146,7 @@ static int mtk_disp_postmask_remove(struct platform_device
*pdev)
}
static const struct of_device_id mtk_disp_postmask_driver_dt_match[] = {
+ { .compatible = "mediatek,mt8192-disp-postmask"},
{},
};
MODULE_DEVICE_TABLE(of, mtk_disp_postmask_driver_dt_match);
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
index 728aaadfea8cf..f123fc00a3935 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
@@ -355,6 +355,10 @@ static const struct mtk_disp_rdma_data
mt8183_rdma_driver_data = {
.fifo_size = 5 * SZ_1K,
};
+static const struct mtk_disp_rdma_data mt8192_rdma_driver_data = {
+ .fifo_size = 5 * SZ_1K,
+};
+
static const struct of_device_id mtk_disp_rdma_driver_dt_match[] = {
{ .compatible = "mediatek,mt2701-disp-rdma",
.data = _rdma_driver_data},
@@ -362,6 +366,8 @@ static const struct of_device_id
mtk_disp_rdma_driver_dt_match[] = {
.data = _rdma_driver_data},
{ .compatible = "mediatek,mt8183-disp-rdma",
.data = _rdma_driver_data},
+ { .compatible = "mediatek,mt8192-disp-rdma",
+ .data = _rdma_driver_data},
{},
};
MODULE_DEVICE_TABLE(of, mtk_disp_rdma_driver_dt_match);
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 3da8996438dbc..6261d6bbe863e 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -147,6 +147,25 @@ static const enum mtk_ddp_comp_id mt8183_mtk_ddp_ext[] = {
DDP_COMPONENT_DPI0,
};
+static const enum mtk_ddp_comp_id mt8192_mtk_ddp_main[] = {
+ DDP_COMPONENT_OVL0,
+ DDP_COMPONENT_OVL_2L0,
+ DDP_COMPONENT_RDMA0,
+ DDP_COMPONENT_COLOR0,
+ DDP_COMPONENT_CCORR,
+ DDP_COMPONENT_AAL0,
+ DDP_COMPONENT_GAMMA,
+ DDP_COMPONENT_POSTMASK0,
+ DDP_COMPONENT_DITHER,
+ DDP_COMPONENT_DSI0,
+};
+
+static const enum
[PATCH v4 3/8] drm/mediatek: add component RDMA4
From: Yongqiang Niu
This patch add component RDMA4
Signed-off-by: Yongqiang Niu
Reviewed-by: Chun-Kuang Hu
Signed-off-by: Hsin-Yi Wang
---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index 6c539783118dd..543cbfc9c5d85 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -496,6 +496,7 @@ static const struct mtk_ddp_comp_match
mtk_ddp_matches[DDP_COMPONENT_ID_MAX] = {
[DDP_COMPONENT_RDMA0] = { MTK_DISP_RDMA, 0, _rdma },
[DDP_COMPONENT_RDMA1] = { MTK_DISP_RDMA, 1, _rdma },
[DDP_COMPONENT_RDMA2] = { MTK_DISP_RDMA, 2, _rdma },
+ [DDP_COMPONENT_RDMA4] = { MTK_DISP_RDMA, 4, _rdma },
[DDP_COMPONENT_UFOE]= { MTK_DISP_UFOE, 0, _ufoe },
[DDP_COMPONENT_WDMA0] = { MTK_DISP_WDMA, 0, NULL },
[DDP_COMPONENT_WDMA1] = { MTK_DISP_WDMA, 1, NULL },
--
2.30.0.365.g02bc693789-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 4/8] drm/mediatek: enable OVL_LAYER_SMI_ID_EN for multi-layer usecase
From: Yongqiang Niu
enable OVL_LAYER_SMI_ID_EN for multi-layer usecase, without this patch,
ovl will hang up when more than 1 layer enabled.
Signed-off-by: Yongqiang Niu
Signed-off-by: Hsin-Yi Wang
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index da7e38a28759b..961f87f8d4d15 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -24,6 +24,7 @@
#define DISP_REG_OVL_RST 0x0014
#define DISP_REG_OVL_ROI_SIZE 0x0020
#define DISP_REG_OVL_DATAPATH_CON 0x0024
+#define OVL_LAYER_SMI_ID_ENBIT(0)
#define OVL_BGCLR_SEL_IN BIT(2)
#define DISP_REG_OVL_ROI_BGCLR 0x0028
#define DISP_REG_OVL_SRC_CON 0x002c
@@ -62,6 +63,7 @@ struct mtk_disp_ovl_data {
unsigned int gmc_bits;
unsigned int layer_nr;
bool fmt_rgb565_is_0;
+ bool smi_id_en;
};
/**
@@ -134,6 +136,13 @@ void mtk_ovl_start(struct device *dev)
{
struct mtk_disp_ovl *ovl = dev_get_drvdata(dev);
+ if (ovl->data->smi_id_en) {
+ unsigned int reg;
+
+ reg = readl(ovl->regs + DISP_REG_OVL_DATAPATH_CON);
+ reg = reg | OVL_LAYER_SMI_ID_EN;
+ writel_relaxed(reg, ovl->regs + DISP_REG_OVL_DATAPATH_CON);
+ }
writel_relaxed(0x1, ovl->regs + DISP_REG_OVL_EN);
}
@@ -142,6 +151,14 @@ void mtk_ovl_stop(struct device *dev)
struct mtk_disp_ovl *ovl = dev_get_drvdata(dev);
writel_relaxed(0x0, ovl->regs + DISP_REG_OVL_EN);
+ if (ovl->data->smi_id_en) {
+ unsigned int reg;
+
+ reg = readl(ovl->regs + DISP_REG_OVL_DATAPATH_CON);
+ reg = reg & ~OVL_LAYER_SMI_ID_EN;
+ writel_relaxed(reg, ovl->regs + DISP_REG_OVL_DATAPATH_CON);
+ }
+
}
void mtk_ovl_config(struct device *dev, unsigned int w,
--
2.30.0.365.g02bc693789-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v12 6/8] drm/mediatek: enable dither function
On Fri, 2021-01-29 at 14:24 +0800, Hsin-Yi Wang wrote:
> On Fri, Jan 29, 2021 at 9:33 AM CK Hu wrote:
> >
> > Hi, Hsin-Yi:
> >
> > On Thu, 2021-01-28 at 19:23 +0800, Hsin-Yi Wang wrote:
> > > From: Yongqiang Niu
> > >
> > > for 5 or 6 bpc panel, we need enable dither function
> > > to improve the display quality
> > >
> > > Signed-off-by: Yongqiang Niu
> > > Signed-off-by: Hsin-Yi Wang
> > > ---
> > > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 15 +--
> > > 1 file changed, 13 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > > b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > > index ac2cb25620357..6c8f246380a74 100644
> > > --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > > +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > > @@ -53,6 +53,7 @@
> > > #define DITHER_ENBIT(0)
> > > #define DISP_DITHER_CFG 0x0020
> > > #define DITHER_RELAY_MODEBIT(0)
> > > +#define DITHER_ENGINE_EN BIT(1)
> > > #define DISP_DITHER_SIZE 0x0030
> > >
> > > #define LUT_10BIT_MASK 0x03ff
> > > @@ -314,9 +315,19 @@ static void mtk_dither_config(struct device *dev,
> > > unsigned int w,
> > > unsigned int bpc, struct cmdq_pkt *cmdq_pkt)
> > > {
> > > struct mtk_ddp_comp_dev *priv = dev_get_drvdata(dev);
> > > + bool enable = (bpc == 5 || bpc == 6);
> >
> > I strongly believe that dither function in dither is identical to the
> > one in gamma and od, and in mtk_dither_set_common(), 'bpc >=
> > MTK_MIN_BPC' is valid, so I believe we need not to limit bpc to 5 or 6.
> > But we should consider the case that bpc is invalid in
> > mtk_dither_set_common(). Invalid case in gamma and od use different way
> > to process. For gamma, dither is default relay mode, so invalid bpc
> > would do nothing in mtk_dither_set_common() and result in relay mode.
> > For od, it set to relay mode first, them invalid bpc would do nothing in
> > mtk_dither_set_common() and result in relay mode. I would like dither,
> > gamma and od to process invalid bpc in the same way. One solution is to
> > set relay mode in mtk_dither_set_common() for invalid bpc.
> >
> > Regards,
> > CK
> >
>
> I modify the mtk_dither_config() to follow:
>
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> index ac2cb25620357..5b7fcedb9f9a8 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> @@ -53,6 +53,7 @@
> #define DITHER_EN BIT(0)
> #define DISP_DITHER_CFG0x0020
> #define DITHER_RELAY_MODE BIT(0)
> +#define DITHER_ENGINE_EN BIT(1)
> #define DISP_DITHER_SIZE 0x0030
>
> #define LUT_10BIT_MASK 0x03ff
> @@ -166,6 +167,8 @@ void mtk_dither_set_common(void __iomem *regs,
> struct cmdq_client_reg *cmdq_reg,
> DITHER_ADD_LSHIFT_G(MTK_MAX_BPC - bpc),
> cmdq_reg, regs, DISP_DITHER_16);
> mtk_ddp_write(cmdq_pkt, dither_en, cmdq_reg, regs, cfg);
> + } else {
> + mtk_ddp_write(cmdq_pkt, DITHER_RELAY_MODE, cmdq_reg, regs,
> cfg);
> }
> }
>
> @@ -315,8 +318,12 @@ static void mtk_dither_config(struct device *dev,
> unsigned int w,
> {
> struct mtk_ddp_comp_dev *priv = dev_get_drvdata(dev);
>
> - mtk_ddp_write(cmdq_pkt, h << 16 | w, >cmdq_reg,
> priv->regs, DISP_DITHER_SIZE);
> - mtk_ddp_write(cmdq_pkt, DITHER_RELAY_MODE, >cmdq_reg,
> priv->regs, DISP_DITHER_CFG);
> + mtk_ddp_write(cmdq_pkt, h << 16 | w, >cmdq_reg, priv->regs,
> + DISP_DITHER_SIZE);
> + mtk_ddp_write(cmdq_pkt, DITHER_RELAY_MODE, >cmdq_reg,
> priv->regs,
> + DISP_DITHER_CFG);
> + mtk_dither_set_common(priv->regs, >cmdq_reg, bpc,
> DISP_DITHER_CFG,
> + DITHER_ENGINE_EN, cmdq_pkt);
> }
>
> So now, not only bpc==5 or 6, but all valid bpc, dither config will
> call mtk_dither_set_common() with the flag DITHER_ENGINE_EN(BIT(1)).
> od config will call mtk_dither_set_common() with the flag
> DISP_DITHERING(BIT(2)).
> Additionally for 8173, gamma config will call mtk_dither_set_common()
> with the flag DISP_DITHERING (BIT(2))
>
> For invalid mode all of them will be DITHER_RELAY_MODE.
>
> Just to make sure that this follows the spec? thanks
>
for mt8173 gamma, there is no relay mode, only dither enable or not(bit
2).
for mt8183 dither, there is dither enable bit 1, and relay mode bit 0
> > >
> > > - mtk_ddp_write(cmdq_pkt, h << 16 | w, >cmdq_reg, priv->regs,
> > > DISP_DITHER_SIZE);
> > > - mtk_ddp_write(cmdq_pkt, DITHER_RELAY_MODE, >cmdq_reg,
> > > priv->regs,
Re: [PATCH 04/13] module: use RCU to synchronize find_module
Hi Christoph,
Christoph Hellwig writes:
> diff --git a/kernel/module.c b/kernel/module.c
> index 981302f616b411..6772fb2680eb3e 100644
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -668,7 +668,6 @@ static struct module *find_module_all(const char *name,
> size_t len,
>
> struct module *find_module(const char *name)
> {
> - module_assert_mutex();
Does it make sense to replace the assert above with the warn below (untested)?
RCU_LOCKDEP_WARN(rcu_read_lock_sched_held());
> return find_module_all(name, strlen(name), false);
> }
--
Thiago Jung Bauermann
IBM Linux Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 5/8] drm/mediatek: separate ccorr module
From: Yongqiang Niu
ccorr ctm matrix bits will be different in mt8192
Signed-off-by: Yongqiang Niu
Signed-off-by: Hsin-Yi Wang
---
drivers/gpu/drm/mediatek/Makefile | 3 +-
drivers/gpu/drm/mediatek/mtk_disp_ccorr.c | 222
drivers/gpu/drm/mediatek/mtk_disp_drv.h | 9 +
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 95 +
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 8 +-
drivers/gpu/drm/mediatek/mtk_drm_drv.h | 1 +
6 files changed, 242 insertions(+), 96 deletions(-)
create mode 100644 drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
diff --git a/drivers/gpu/drm/mediatek/Makefile
b/drivers/gpu/drm/mediatek/Makefile
index 13a0eafabf9c0..f119bef6d6e66 100644
--- a/drivers/gpu/drm/mediatek/Makefile
+++ b/drivers/gpu/drm/mediatek/Makefile
@@ -1,6 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
-mediatek-drm-y := mtk_disp_color.o \
+mediatek-drm-y := mtk_disp_ccorr.o \
+ mtk_disp_color.o \
mtk_disp_gamma.o \
mtk_disp_ovl.o \
mtk_disp_postmask.o \
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
b/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
new file mode 100644
index 0..0c68090eb1e92
--- /dev/null
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
@@ -0,0 +1,222 @@
+/*
+ * SPDX-License-Identifier:
+ *
+ * Copyright (c) 2020 MediaTek Inc.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "mtk_disp_drv.h"
+#include "mtk_drm_crtc.h"
+#include "mtk_drm_ddp_comp.h"
+
+#define DISP_CCORR_EN 0x
+#define CCORR_EN BIT(0)
+#define DISP_CCORR_CFG 0x0020
+#define CCORR_RELAY_MODE BIT(0)
+#define CCORR_ENGINE_ENBIT(1)
+#define CCORR_GAMMA_OFFBIT(2)
+#define CCORR_WGAMUT_SRC_CLIP BIT(3)
+#define DISP_CCORR_SIZE0x0030
+#define DISP_CCORR_COEF_0 0x0080
+#define DISP_CCORR_COEF_1 0x0084
+#define DISP_CCORR_COEF_2 0x0088
+#define DISP_CCORR_COEF_3 0x008C
+#define DISP_CCORR_COEF_4 0x0090
+
+struct mtk_disp_ccorr_data {
+ u32 reserved;
+};
+
+/**
+ * struct mtk_disp_ccorr - DISP_CCORR driver structure
+ * @ddp_comp - structure containing type enum and hardware resources
+ * @crtc - associated crtc to report irq events to
+ */
+struct mtk_disp_ccorr {
+ struct clk *clk;
+ void __iomem *regs;
+ struct cmdq_client_reg cmdq_reg;
+ const struct mtk_disp_ccorr_data*data;
+};
+
+int mtk_ccorr_clk_enable(struct device *dev)
+{
+ struct mtk_disp_ccorr *ccorr = dev_get_drvdata(dev);
+
+ return clk_prepare_enable(ccorr->clk);
+}
+
+void mtk_ccorr_clk_disable(struct device *dev)
+{
+ struct mtk_disp_ccorr *ccorr = dev_get_drvdata(dev);
+
+ clk_disable_unprepare(ccorr->clk);
+}
+
+void mtk_ccorr_config(struct device *dev, unsigned int w,
+unsigned int h, unsigned int vrefresh,
+unsigned int bpc, struct cmdq_pkt *cmdq_pkt)
+{
+ struct mtk_disp_ccorr *ccorr = dev_get_drvdata(dev);
+
+ mtk_ddp_write(cmdq_pkt, w << 16 | h, >cmdq_reg, ccorr->regs,
+ DISP_CCORR_SIZE);
+ mtk_ddp_write(cmdq_pkt, CCORR_ENGINE_EN, >cmdq_reg, ccorr->regs,
+ DISP_CCORR_CFG);
+}
+
+void mtk_ccorr_start(struct device *dev)
+{
+ struct mtk_disp_ccorr *ccorr = dev_get_drvdata(dev);
+
+ writel(CCORR_EN, ccorr->regs + DISP_CCORR_EN);
+}
+
+void mtk_ccorr_stop(struct device *dev)
+{
+ struct mtk_disp_ccorr *ccorr = dev_get_drvdata(dev);
+
+ writel_relaxed(0x0, ccorr->regs + DISP_CCORR_EN);
+}
+
+/* Converts a DRM S31.32 value to the HW S1.10 format. */
+static u16 mtk_ctm_s31_32_to_s1_10(u64 in)
+{
+ u16 r;
+
+ /* Sign bit. */
+ r = in & BIT_ULL(63) ? BIT(11) : 0;
+
+ if ((in & GENMASK_ULL(62, 33)) > 0) {
+ /* identity value 0x1 -> 0x400, */
+ /* if bigger this, set it to max 0x7ff. */
+ r |= GENMASK(10, 0);
+ } else {
+ /* take the 11 most important bits. */
+ r |= (in >> 22) & GENMASK(10, 0);
+ }
+
+ return r;
+}
+
+void mtk_ccorr_ctm_set(struct device *dev, struct drm_crtc_state *state)
+{
+ struct mtk_disp_ccorr *ccorr = dev_get_drvdata(dev);
+ struct drm_property_blob *blob = state->ctm;
+ struct drm_color_ctm *ctm;
+ const u64 *input;
+ uint16_t coeffs[9] = { 0 };
+ int i;
+ struct cmdq_pkt *cmdq_pkt = NULL;
+
+ if (!blob)
+ return;
+
+ ctm = (struct drm_color_ctm *)blob->data;
+ input = ctm->matrix;
+
+ for (i = 0; i <
