[git pull] drm fixes for 6.4-rc5
Hi Linus, Quiet enough week, though the misc fixes tree didn't get to me when I was sending this, so maybe it'll be a bit bigger next week, just one i915 fix and some scattered amdgpu fixes. Dave. drm-fixes-2023-06-02: drm fixes for v6.4-rc5 amdgpu: - Fix mclk and fclk output ordering on some APUs - Fix display regression with 5K VRR - VCN, JPEG spurious interrupt warning fixes - Fix SI DPM on some ARM64 platforms - Fix missing TMZ enablement on GC 11.0.1 i915: - Fix for OA reporting to allow detecting non-power-of-two reports The following changes since commit 7877cb91f1081754a1487c144d85dc0d2e2e7fc4: Linux 6.4-rc4 (2023-05-28 07:49:00 -0400) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2023-06-02 for you to fetch changes up to b6ccf213d95e9373ac1f7fbcb5de3b52eec0ddb3: Merge tag 'drm-intel-fixes-2023-06-01' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes (2023-06-02 10:33:29 +1000) drm fixes for v6.4-rc5 amdgpu: - Fix mclk and fclk output ordering on some APUs - Fix display regression with 5K VRR - VCN, JPEG spurious interrupt warning fixes - Fix SI DPM on some ARM64 platforms - Fix missing TMZ enablement on GC 11.0.1 i915: - Fix for OA reporting to allow detecting non-power-of-two reports Ashutosh Dixit (1): drm/i915/perf: Clear out entire reports after reading if not power of 2 size Dave Airlie (2): Merge tag 'amd-drm-fixes-6.4-2023-05-31' of https://gitlab.freedesktop.org/agd5f/linux into drm-fixes Merge tag 'drm-intel-fixes-2023-06-01' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes Guchun Chen (1): drm/amd/pm: resolve reboot exception for si oland Horatio Zhang (6): drm/amdgpu: separate ras irq from vcn instance irq for UVD_POISON drm/amdgpu: add RAS POISON interrupt funcs for vcn_v2_6 drm/amdgpu: add RAS POISON interrupt funcs for vcn_v4_0 drm/amdgpu: separate ras irq from jpeg instance irq for UVD_POISON drm/amdgpu: add RAS POISON interrupt funcs for jpeg_v2_6 drm/amdgpu: add RAS POISON interrupt funcs for jpeg_v4_0 Ikshwaku Chauhan (1): drm/amdgpu: enable tmz by default for GC 11.0.1 Michel Dänzer (2): Revert "drm/amd/display: Block optimize on consecutive FAMS enables" Revert "drm/amd/display: Do not set drr on pipe commit" Tim Huang (5): drm/amd/pm: reverse mclk and fclk clocks levels for SMU v13.0.4 drm/amd/pm: reverse mclk clocks levels for SMU v13.0.5 drm/amd/pm: reverse mclk and fclk clocks levels for yellow carp drm/amd/pm: reverse mclk and fclk clocks levels for vangogh drm/amd/pm: reverse mclk and fclk clocks levels for renoir drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c| 3 +- drivers/gpu/drm/amd/amdgpu/amdgpu_jpeg.c | 27 +++- drivers/gpu/drm/amd/amdgpu/amdgpu_jpeg.h | 3 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c| 27 +++- drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h| 3 ++ drivers/gpu/drm/amd/amdgpu/jpeg_v2_5.c | 28 + drivers/gpu/drm/amd/amdgpu/jpeg_v4_0.c | 28 - drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c | 25 --- drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c | 36 ++ drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c | 9 -- drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.c | 25 +-- drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c | 29 - drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c | 10 +++--- drivers/gpu/drm/amd/pm/swsmu/smu12/renoir_ppt.c| 5 +-- .../gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_4_ppt.c | 5 +-- .../gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_5_ppt.c | 5 +-- .../gpu/drm/amd/pm/swsmu/smu13/yellow_carp_ppt.c | 5 +-- drivers/gpu/drm/i915/i915_perf.c | 17 ++ 18 files changed, 184 insertions(+), 106 deletions(-)
Re: [PATCH v2 1/2] dt-bindings: display: bridge: Add NXP i.MX93 parallel display format configuration
On Fri, Jun 2, 2023 at 1:45 AM Krzysztof Kozlowski wrote: > > On 31/05/2023 11:32, Liu Ying wrote: > > NXP i.MX93 mediamix blk-ctrl contains one DISPLAY_MUX register which > > configures parallel display format by using the "PARALLEL_DISP_FORMAT" > > field. Add device tree bindings for the display format configuration. > > > > Signed-off-by: Liu Ying > > --- > > v1->v2: > > * No change. > > How did you implement Rob's comment? Should have discussed more in v1 about Rob's comment, but let me explain why this dt-binding makes sense here: Both i.MX8mp SoC and i.MX93 SoC media block control devices contain a LVDS Display Bridge(LDB) child device. The i.MX93 block control device additionally contains this PDFC child device. LDB dt-binding [1] is written in a separate file and referenced in i.MX8mp block control dt-binding [2]. So, for the sake of consistency, it makes sense to keep this PDFC dt-binding and reference it together with the LDB one [1] in i.MX93 block control dt-binding [3] in future, doesn't it? It seems good to have a separate PDFC dt-binding in case it can/will be referenced by multiple parent device dt-bindings. [1] Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml [2] Documentation/devicetree/bindings/soc/imx/fsl,imx8mp-media-blk-ctrl.yaml [3] Documentation/devicetree/bindings/soc/imx/fsl,imx93-media-blk-ctrl.yaml Regards, Liu Ying > > > > > .../display/bridge/nxp,imx93-pdfc.yaml| 78 +++ > > 1 file changed, 78 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/display/bridge/nxp,imx93-pdfc.yaml
[PATCH] dim: Disallow remote branch deletions with 'dim push'
An inadvertent 'dim push -d' can delete remote branches. Disallow such remote branch deletions. Signed-off-by: Ashutosh Dixit --- dim | 6 ++ 1 file changed, 6 insertions(+) diff --git a/dim b/dim index 126568e..e5899e6 100755 --- a/dim +++ b/dim @@ -1029,6 +1029,12 @@ function dim_push_branch fi fi + # Disallow remote branch deletions, say with 'dim push -d' + if [[ "$@" == *"-d"* ]]; then + echoerr "Attempt to delete remote branch, aborting." + return 1 + fi + git_push $remote $branch "$@" update_linux_next $branch drm-intel-next drm-intel-next-fixes drm-intel-fixes -- 2.38.0
Re: [Freedreno] [PATCH] Revert "drm/msm/dp: Remove INIT_SETUP delay"
Hi Abhinav, June 1, 2023 at 3:20 PM, "Abhinav Kumar" wrote: > > > > [drm:drm_mode_config_helper_resume] *ERROR* Failed to resume (-107) > > > > We are not able to recreate this on sc7280 chromebooks , will need to check > on sc7180. This does not seem directly related to any of the hotplug changes > though so needs to be checked separately. So please feel free to raise a > gitlab bug for this and assign to me. Thank you for checking with sc7280. I created https://gitlab.freedesktop.org/drm/msm/-/issues/25 and CCed you. I've also verified that the error persists with v6.4.0-rc4 + Kuogee's patch (just in case you may have tested on sc7280 with 6.4). > > https://patchwork.freedesktop.org/patch/538601/?series=118148=3 > > Apologies if you were not CCed on this, if a next version is CCed, > > will ask kuogee to cc you. > > Meanwhile, will be great if you can verify if it works for you and > > provide Tested-by tags. I see Bjorn also tested the patch. As it fixes a serious USB-C DP regression which broke USB-C DP completely on lazor for v6.3, can it be included in upcoming 6.3.y release? Thank you Leonard
[Bug 90091] Computer freeze
https://bugzilla.kernel.org/show_bug.cgi?id=90091 --- Comment #5 from Marc Collin (marc.col...@protonmail.com) --- i don't have this computer anymore -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
RE: [PATCH] drm/exynos: fix race condition UAF in exynos_g2d_exec_ioctl
Andi~ :)
> -Original Message-
> From: Andi Shyti
> Sent: Thursday, June 1, 2023 5:29 PM
> To: 대인기/Tizen Platform Lab(SR)/삼성전자
> Cc: 'lm0963' ; sw0312@samsung.com;
> kyungmin.p...@samsung.com; airl...@gmail.com; dan...@ffwll.ch;
> krzysztof.kozlow...@linaro.org; alim.akh...@samsung.com; dri-
> de...@lists.freedesktop.org; linux-arm-ker...@lists.infradead.org; linux-
> samsung-...@vger.kernel.org; linux-ker...@vger.kernel.org
> Subject: Re: [PATCH] drm/exynos: fix race condition UAF in
> exynos_g2d_exec_ioctl
>
> Hi Inki,
>
> > > > > > > > If it is async, runqueue_node is freed in
> g2d_runqueue_worker on
> > > another
> > > > > > > > worker thread. So in extreme cases, if g2d_runqueue_worker
> runs
> > > first, and
> > > > > > > > then executes the following if statement, there will be use-
> > > after-free.
> > > > > > > >
> > > > > > > > Signed-off-by: Min Li
> > > > > > > > ---
> > > > > > > > drivers/gpu/drm/exynos/exynos_drm_g2d.c | 2 +-
> > > > > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > > > >
> > > > > > > > diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> > > b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> > > > > > > > index ec784e58da5c..414e585ec7dd 100644
> > > > > > > > --- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> > > > > > > > +++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> > > > > > > > @@ -1335,7 +1335,7 @@ int exynos_g2d_exec_ioctl(struct
> > > drm_device *drm_dev, void *data,
> > > > > > > > /* Let the runqueue know that there is work to do. */
> > > > > > > > queue_work(g2d->g2d_workq, >runqueue_work);
> > > > > > > >
> > > > > > > > - if (runqueue_node->async)
> > > > > > > > + if (req->async)
> > > > > > >
> > > > > > > did you actually hit this? If you did, then the fix is not OK.
> > > > > >
> > > > > > No, I didn't actually hit this. I found it through code review.
> This
> > > > > > is only a theoretical issue that can only be triggered in
> extreme
> > > > > > cases.
> > > > >
> > > > > first of all runqueue is used again two lines below this, which
> > > > > means that if you don't hit the uaf here you will hit it
> > > > > immediately after.
> > > >
> > > > No, if async is true, then it will goto out, which will directly
> return.
> > > >
> > > > if (runqueue_node->async)
> > > > goto out; // here, go to out, will directly return
> > > >
> > > > wait_for_completion(_node->complete); // not hit
> > > > g2d_free_runqueue_node(g2d, runqueue_node);
> > > >
> > > > out:
> > > > return 0;
> > >
> > > that's right, sorry, I misread it.
> > >
> > > > > Second, if runqueue is freed, than we need to remove the part
> > > > > where it's freed because it doesn't make sense to free runqueue
> > > > > at this stage.
> > > >
> > > > It is freed by g2d_free_runqueue_node in g2d_runqueue_worker
> > > >
> > > > static void g2d_runqueue_worker(struct work_struct *work)
> > > > {
> > > > ..
> > > > if (runqueue_node) {
> > > > pm_runtime_mark_last_busy(g2d->dev);
> > > > pm_runtime_put_autosuspend(g2d->dev);
> > > >
> > > > complete(_node->complete);
> > > > if (runqueue_node->async)
> > > > g2d_free_runqueue_node(g2d, runqueue_node);//
freed
> here
> > >
> > > this is what I'm wondering: is it correct to free a resource
> > > here? The design looks to me a bit fragile and prone to mistakes.
> >
> > This question seems to deviate from the purpose of this patch. If you
> are providing additional opinions for code quality improvement unrelated
> to this patch, it would be more appropriate for me to answer instead of
> him.
>
> It's not deviating as the question was already made in my first
> review. It just looks strange to me that a piece of data shared
> amongst processes can be freed up without sinchronizing. A bunch
I believe that if we overlook any doubts or concerns about worrisome
aspects without completely resolving them, it wouldn't be helpful to the
community.
Therefore, I would like to clarify more explicitly in order to ensure a
better understanding.
AFAIK, the data you mentioned isn't shared between processes. This data is
generated driver-internally when the user makes a rendering request and
will be removed once the 2D GPU finishes rendering.
However, there may be another issue that I'm not aware of, so if there is
any, give me it more specifically as it would help improve driver stability.
Thanks again,
Inki Dae
> of if's do not make it robust enough.
>
> The patch itself, in my point of view, is not really fixing much
> and won't make any difference, it's just exposing the weakness I
> mentioned.
>
> However, honestly speaking, I don't know the driver well enough
> to suggest architectural changes and that's why I r-b'ed this
> one. But the first thing that comes to my mind, without looking
> much at the code, is using kref's as a way to make sure that a
> resource doesn't magically disappear under your nose.
>
> But, of course, this is
Re: [PATCH 0/2] drm/i915/gt: Fix recent kCFI violations
Hi Nathan,
On Tue, May 30, 2023 at 11:24:37AM -0700, Nathan Chancellor wrote:
> Hi all,
>
> This series fixes a few clang kernel Control Flow Integrity (kCFI)
> violations that appear after commit 9275277d5324 ("drm/i915: use
> pat_index instead of cache_level"). They were found between run time
> testing on real hardware and compile time testing with
> -Wincompatible-function-pointer-types-strict (which is not yet enabled
> for the kernel but I build with it locally to catch new instances).
>
> If there are any problems or questions, please let me know.
>
> ---
> Nathan Chancellor (2):
> drm/i915/gt: Fix second parameter type of pre-gen8 pte_encode callbacks
> drm/i915/gt: Fix parameter in gmch_ggtt_insert_{entries,page}()
pushed in drm-intel-gt-next.
Thank you,
Andi
Re: [Intel-gfx] [PATCH] drm/i915/pxp: use correct format string for size_t
Hi Arnd,
On Thu, Jun 01, 2023 at 10:00:27PM +, Teres Alexis, Alan Previn wrote:
> On Thu, 2023-06-01 at 23:36 +0200, Arnd Bergmann wrote:
> > From: Arnd Bergmann
> >
> > While 'unsigned long' needs the %ld format string, size_t needs the %z
> > modifier:
>
> alan:snip
>
>
> > +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
> > @@ -143,7 +143,7 @@ gsccs_send_message(struct intel_pxp *pxp,
> >
> > reply_size = header->message_size - sizeof(*header);
> > if (reply_size > msg_out_size_max) {
> > - drm_warn(>drm, "caller with insufficient PXP reply size
> > %u (%ld)\n",
> > + drm_warn(>drm, "caller with insufficient PXP reply size
> > %u (%zd)\n",
> > reply_size, msg_out_size_max);
> > reply_size = msg_out_size_max;
> > }
> Thanks Arnd for catching this, although i believe Nathan sumbmitted a patch
> for the same fix yesterday and received an RB from Andi.
yes, the patch is here:
https://patchwork.freedesktop.org/patch/540272/?series=118593=1
I'm waiting for full CI results to merge this.
Thanks,
Andi
Re: [PATCH v5 5/7] drm/i915/mtl/huc: auth HuC via GSC
On Wed, 2023-05-31 at 16:54 -0700, Ceraolo Spurio, Daniele wrote: > The full authentication via the GSC requires an heci packet submission > to the GSC FW via the GSC CS. The GSC has new PXP command for this > (literally called NEW_HUC_AUTH). > The intel_huc_auth function is also updated to handle both authentication > types. > > alan:snip > @@ -399,6 +416,9 @@ void intel_huc_fini(struct intel_huc *huc) >*/ > delayed_huc_load_fini(huc); > > + if (huc->heci_pkt) > + i915_vma_unpin_and_release(>heci_pkt, 0); alan: nit: i just realized that for consistency (init mirror-ing fini), we should be doing this heci releasing after the intel_uc_fw_fini below. But since the below object isnt referencing the heci packet, this doens't matter, so consider a nit. alan:snip > @@ -470,31 +491,41 @@ int intel_huc_auth(struct intel_huc *huc) > if (!intel_uc_fw_is_loaded(>fw)) > return -ENOEXEC; > > - /* GSC will do the auth */ > + /* GSC will do the auth with the load */ > if (intel_huc_is_loaded_by_gsc(huc)) > return -ENODEV; alan: nit: sorry for another late comment but merely a nit - wondering if we should add a warn in here (to catch if we could end up here) but its okay - this in theory shouldnt happen anyway. alan:snip > +++ b/drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c alan:snip Only a couple of late-comer-nits that you can ignore, else LGTM: Reviewed-by: Alan Previn
[PATCH v3] amdgpu: validate offset_in_bo of drm_amdgpu_gem_va
This is motivated by OOB access in amdgpu_vm_update_range when
offset_in_bo+map_size overflows.
v2: keep the validations in amdgpu_vm_bo_map
v3: add the validations to amdgpu_vm_bo_map/amdgpu_vm_bo_replace_map
rather than to amdgpu_gem_va_ioctl
Fixes: 9f7eb5367d00 ("drm/amdgpu: actually use the VM map parameters")
Signed-off-by: Chia-I Wu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 22f9a65ca0fc7..76d57bc7ac620 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -1434,14 +1434,14 @@ int amdgpu_vm_bo_map(struct amdgpu_device *adev,
uint64_t eaddr;
/* validate the parameters */
- if (saddr & ~PAGE_MASK || offset & ~PAGE_MASK ||
- size == 0 || size & ~PAGE_MASK)
+ if (saddr & ~PAGE_MASK || offset & ~PAGE_MASK || size & ~PAGE_MASK)
+ return -EINVAL;
+ if (saddr + size <= saddr || offset + size <= offset)
return -EINVAL;
/* make sure object fit at this offset */
eaddr = saddr + size - 1;
- if (saddr >= eaddr ||
- (bo && offset + size > amdgpu_bo_size(bo)) ||
+ if ((bo && offset + size > amdgpu_bo_size(bo)) ||
(eaddr >= adev->vm_manager.max_pfn << AMDGPU_GPU_PAGE_SHIFT))
return -EINVAL;
@@ -1500,14 +1500,14 @@ int amdgpu_vm_bo_replace_map(struct amdgpu_device *adev,
int r;
/* validate the parameters */
- if (saddr & ~PAGE_MASK || offset & ~PAGE_MASK ||
- size == 0 || size & ~PAGE_MASK)
+ if (saddr & ~PAGE_MASK || offset & ~PAGE_MASK || size & ~PAGE_MASK)
+ return -EINVAL;
+ if (saddr + size <= saddr || offset + size <= offset)
return -EINVAL;
/* make sure object fit at this offset */
eaddr = saddr + size - 1;
- if (saddr >= eaddr ||
- (bo && offset + size > amdgpu_bo_size(bo)) ||
+ if ((bo && offset + size > amdgpu_bo_size(bo)) ||
(eaddr >= adev->vm_manager.max_pfn << AMDGPU_GPU_PAGE_SHIFT))
return -EINVAL;
--
2.41.0.rc0.172.g3f132b7071-goog
Re: [PATCH v2 1/2] drm/msm/dpu: retrieve DSI DSC struct at atomic_check()
On 02/06/2023 01:08, Kuogee Hsieh wrote:
At current implementation, DSI DSC struct is populated at display setup
during system bootup. This mechanism works fine with embedded display.
But will run into problem with plugin/unplug oriented external display,
such as DP, due to DSC struct will become stale once external display
unplugged. New DSC struct has to be re populated to reflect newer external
display which just plugged in. Move retrieving of DSI DSC struct to
atomic_check() so that same mechanism will work for both embedded display
and external plugin/unplug oriented display.
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 3b416e1..5c440a0 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -604,7 +604,7 @@ static int dpu_encoder_virt_atomic_check(
struct drm_display_mode *adj_mode;
struct msm_display_topology topology;
struct dpu_global_state *global_state;
- int i = 0;
+ int index, i = 0;
int ret = 0;
if (!drm_enc || !crtc_state || !conn_state) {
@@ -639,6 +639,10 @@ static int dpu_encoder_virt_atomic_check(
}
}
+ index = dpu_enc->disp_info.h_tile_instance[0];
+if (dpu_enc->disp_info.intf_type == DRM_MODE_ENCODER_DSI)
+ dpu_enc->dsc = msm_dsi_get_dsc_config(priv->dsi[index]);
As discussed previously, one should not write to non-state objects from
atomic_check. This chunk does.
Not to mention that this will start exploding once you try adding DP
next to it.
Please abstain from posting next revisions until the discussions on the
previous one are more or less finished. For now this is NAK.
Not to mention that this patch doesn't pass checkpatch.pl.
+
topology = dpu_encoder_get_topology(dpu_enc, dpu_kms, adj_mode,
crtc_state);
/*
@@ -1034,7 +1038,7 @@ static void dpu_encoder_virt_atomic_mode_set(struct
drm_encoder *drm_enc,
struct dpu_hw_blk *hw_dsc[MAX_CHANNELS_PER_ENC];
int num_lm, num_ctl, num_pp, num_dsc;
unsigned int dsc_mask = 0;
- int i;
+ int index, i;
if (!drm_enc) {
DPU_ERROR("invalid encoder\n");
@@ -1055,6 +1059,10 @@ static void dpu_encoder_virt_atomic_mode_set(struct
drm_encoder *drm_enc,
trace_dpu_enc_mode_set(DRMID(drm_enc));
+ index = dpu_enc->disp_info.h_tile_instance[0];
+if (dpu_enc->disp_info.intf_type == DRM_MODE_ENCODER_DSI)
+ dpu_enc->dsc = msm_dsi_get_dsc_config(priv->dsi[index]);
Doesn't this seem 100% same as the previous chunk? Doesn't it plead to
be extracted to a helper function?
+
/* Query resource that have been reserved in atomic check step. */
num_pp = dpu_rm_get_assigned_resources(_kms->rm, global_state,
drm_enc->base.id, DPU_HW_BLK_PINGPONG, hw_pp,
@@ -2121,8 +2129,10 @@ void dpu_encoder_helper_phys_cleanup(struct
dpu_encoder_phys *phys_enc)
phys_enc->hw_pp->merge_3d->idx);
}
- if (dpu_enc->dsc)
+ if (dpu_enc->dsc) {
dpu_encoder_unprep_dsc(dpu_enc);
+ dpu_enc->dsc = NULL;
+ }
intf_cfg.stream_sel = 0; /* Don't care value for video mode */
intf_cfg.mode_3d = dpu_encoder_helper_get_3d_blend_mode(phys_enc);
--
With best wishes
Dmitry
[PATCH net-next v6 6/6] MAINTAINERS: ASP 2.0 Ethernet driver maintainers
Add maintainers entry for ASP 2.0 Ethernet driver. Reviewed-by: Simon Horman Signed-off-by: Florian Fainelli Signed-off-by: Justin Chen --- v3 - Change from gmail to broadcom emails MAINTAINERS | 9 + 1 file changed, 9 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index c25172d6471a..986b975b1d67 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4198,6 +4198,15 @@ F: drivers/net/mdio/mdio-bcm-unimac.c F: include/linux/platform_data/bcmgenet.h F: include/linux/platform_data/mdio-bcm-unimac.h +BROADCOM ASP 2.0 ETHERNET DRIVER +M: Justin Chen +M: Florian Fainelli +L: bcm-kernel-feedback-l...@broadcom.com +L: net...@vger.kernel.org +S: Supported +F: Documentation/devicetree/bindings/net/brcm,asp-v2.0.yaml +F: drivers/net/ethernet/broadcom/asp2/ + BROADCOM IPROC ARM ARCHITECTURE M: Ray Jui M: Scott Branden -- 2.7.4 smime.p7s Description: S/MIME Cryptographic Signature
[PATCH net-next v6 5/6] net: phy: bcm7xxx: Add EPHY entry for 74165
From: Florian Fainelli
74165 is a 16nm process SoC with a 10/100 integrated Ethernet PHY,
utilize the recently defined 16nm EPHY macro to configure that PHY.
Reviewed-by: Simon Horman
Reviewed-by: Andrew Lunn
Signed-off-by: Florian Fainelli
Signed-off-by: Justin Chen
---
drivers/net/phy/bcm7xxx.c | 1 +
include/linux/brcmphy.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/net/phy/bcm7xxx.c b/drivers/net/phy/bcm7xxx.c
index f8c17a253f8b..8478b081c058 100644
--- a/drivers/net/phy/bcm7xxx.c
+++ b/drivers/net/phy/bcm7xxx.c
@@ -913,6 +913,7 @@ static struct phy_driver bcm7xxx_driver[] = {
BCM7XXX_28NM_GPHY(PHY_ID_BCM7278, "Broadcom BCM7278"),
BCM7XXX_28NM_GPHY(PHY_ID_BCM7364, "Broadcom BCM7364"),
BCM7XXX_28NM_GPHY(PHY_ID_BCM7366, "Broadcom BCM7366"),
+ BCM7XXX_16NM_EPHY(PHY_ID_BCM74165, "Broadcom BCM74165"),
BCM7XXX_28NM_GPHY(PHY_ID_BCM74371, "Broadcom BCM74371"),
BCM7XXX_28NM_GPHY(PHY_ID_BCM7439, "Broadcom BCM7439"),
BCM7XXX_28NM_GPHY(PHY_ID_BCM7439_2, "Broadcom BCM7439 (2)"),
diff --git a/include/linux/brcmphy.h b/include/linux/brcmphy.h
index e9afbfb6d7a5..409ec9d35051 100644
--- a/include/linux/brcmphy.h
+++ b/include/linux/brcmphy.h
@@ -44,6 +44,7 @@
#define PHY_ID_BCM7366 0x600d8490
#define PHY_ID_BCM7346 0x600d8650
#define PHY_ID_BCM7362 0x600d84b0
+#define PHY_ID_BCM741650x359052c0
#define PHY_ID_BCM7425 0x600d86b0
#define PHY_ID_BCM7429 0x600d8730
#define PHY_ID_BCM7435 0x600d8750
--
2.7.4
smime.p7s
Description: S/MIME Cryptographic Signature
[PATCH net-next v6 4/6] net: phy: mdio-bcm-unimac: Add asp v2.0 support
Add mdio compat string for ASP 2.0 ethernet driver.
Reviewed-by: Simon Horman
Reviewed-by: Andrew Lunn
Signed-off-by: Florian Fainelli
Signed-off-by: Justin Chen
---
drivers/net/mdio/mdio-bcm-unimac.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/mdio/mdio-bcm-unimac.c
b/drivers/net/mdio/mdio-bcm-unimac.c
index bfc9be23c973..6b26a0803696 100644
--- a/drivers/net/mdio/mdio-bcm-unimac.c
+++ b/drivers/net/mdio/mdio-bcm-unimac.c
@@ -334,6 +334,8 @@ static SIMPLE_DEV_PM_OPS(unimac_mdio_pm_ops,
unimac_mdio_suspend, unimac_mdio_resume);
static const struct of_device_id unimac_mdio_ids[] = {
+ { .compatible = "brcm,asp-v2.1-mdio", },
+ { .compatible = "brcm,asp-v2.0-mdio", },
{ .compatible = "brcm,genet-mdio-v5", },
{ .compatible = "brcm,genet-mdio-v4", },
{ .compatible = "brcm,genet-mdio-v3", },
--
2.7.4
smime.p7s
Description: S/MIME Cryptographic Signature
[PATCH net-next v6 3/6] net: bcmasp: Add support for ASP2.0 Ethernet controller
Add support for the Broadcom ASP 2.0 Ethernet controller which is first
introduced with 72165. This controller features two distinct Ethernet
ports that can be independently operated.
This patch supports:
- Wake-on-LAN using magic packets
- basic ethtool operations (link, counters, message level)
- MAC destination address filtering (promiscuous, ALL_MULTI, etc.)
Reviewed-by: Simon Horman
Signed-off-by: Florian Fainelli
Signed-off-by: Justin Chen
---
v6
- Fixed a reserved mac filter indexing error
- Removed tx_lock
- Simplified tx_timeout hook
- Removed get_stats
- Fixed phy ioctl
- Fixed dev -> ndev typo
- Fixed set_wol double disable
v5
- Remove unnecessary parenthesis
- Use bool for bcmasp_netfilt_check_dup()
v4
- Address sparse warnings
- Fix one more reverse xmas tree violation
- Improve error logic for bcmasp_netfilt_get_reg_offset()
- Remove inlines
v3
- Fix logic error with net stats where some stats were missing
- General clean up addressing formatting/spelling/consistency
- Use dev_err_probe to save a few LoCs
- Use put_unaligned when updating net stats
v2
- Replace a couple functions with helper functions
- Fix a few WoL issues
drivers/net/ethernet/broadcom/Kconfig | 11 +
drivers/net/ethernet/broadcom/Makefile |1 +
drivers/net/ethernet/broadcom/asp2/Makefile|2 +
drivers/net/ethernet/broadcom/asp2/bcmasp.c| 1467
drivers/net/ethernet/broadcom/asp2/bcmasp.h| 638 +
.../net/ethernet/broadcom/asp2/bcmasp_ethtool.c| 568
drivers/net/ethernet/broadcom/asp2/bcmasp_intf.c | 1393 +++
.../net/ethernet/broadcom/asp2/bcmasp_intf_defs.h | 238
8 files changed, 4318 insertions(+)
create mode 100644 drivers/net/ethernet/broadcom/asp2/Makefile
create mode 100644 drivers/net/ethernet/broadcom/asp2/bcmasp.c
create mode 100644 drivers/net/ethernet/broadcom/asp2/bcmasp.h
create mode 100644 drivers/net/ethernet/broadcom/asp2/bcmasp_ethtool.c
create mode 100644 drivers/net/ethernet/broadcom/asp2/bcmasp_intf.c
create mode 100644 drivers/net/ethernet/broadcom/asp2/bcmasp_intf_defs.h
diff --git a/drivers/net/ethernet/broadcom/Kconfig
b/drivers/net/ethernet/broadcom/Kconfig
index 948586bf1b5b..d4166141145d 100644
--- a/drivers/net/ethernet/broadcom/Kconfig
+++ b/drivers/net/ethernet/broadcom/Kconfig
@@ -255,4 +255,15 @@ config BNXT_HWMON
Say Y if you want to expose the thermal sensor data on NetXtreme-C/E
devices, via the hwmon sysfs interface.
+config BCMASP
+ tristate "Broadcom ASP 2.0 Ethernet support"
+ default ARCH_BRCMSTB
+ depends on OF
+ select MII
+ select PHYLIB
+ select MDIO_BCM_UNIMAC
+ help
+ This configuration enables the Broadcom ASP 2.0 Ethernet controller
+ driver which is present in Broadcom STB SoCs such as 72165.
+
endif # NET_VENDOR_BROADCOM
diff --git a/drivers/net/ethernet/broadcom/Makefile
b/drivers/net/ethernet/broadcom/Makefile
index 0ddfb5b5d53c..bac5cb6ad0cd 100644
--- a/drivers/net/ethernet/broadcom/Makefile
+++ b/drivers/net/ethernet/broadcom/Makefile
@@ -17,3 +17,4 @@ obj-$(CONFIG_BGMAC_BCMA) += bgmac-bcma.o bgmac-bcma-mdio.o
obj-$(CONFIG_BGMAC_PLATFORM) += bgmac-platform.o
obj-$(CONFIG_SYSTEMPORT) += bcmsysport.o
obj-$(CONFIG_BNXT) += bnxt/
+obj-$(CONFIG_BCMASP) += asp2/
diff --git a/drivers/net/ethernet/broadcom/asp2/Makefile
b/drivers/net/ethernet/broadcom/asp2/Makefile
new file mode 100644
index ..e07550315f83
--- /dev/null
+++ b/drivers/net/ethernet/broadcom/asp2/Makefile
@@ -0,0 +1,2 @@
+obj-$(CONFIG_BCMASP) += bcm-asp.o
+bcm-asp-objs := bcmasp.o bcmasp_intf.o bcmasp_ethtool.o
diff --git a/drivers/net/ethernet/broadcom/asp2/bcmasp.c
b/drivers/net/ethernet/broadcom/asp2/bcmasp.c
new file mode 100644
index ..f4d0d20824a3
--- /dev/null
+++ b/drivers/net/ethernet/broadcom/asp2/bcmasp.c
@@ -0,0 +1,1467 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Broadcom STB ASP 2.0 Driver
+ *
+ * Copyright (c) 2023 Broadcom
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "bcmasp.h"
+#include "bcmasp_intf_defs.h"
+
+static void _intr2_mask_clear(struct bcmasp_priv *priv, u32 mask)
+{
+ intr2_core_wl(priv, mask, ASP_INTR2_MASK_CLEAR);
+ priv->irq_mask &= ~mask;
+}
+
+static void _intr2_mask_set(struct bcmasp_priv *priv, u32 mask)
+{
+ intr2_core_wl(priv, mask, ASP_INTR2_MASK_SET);
+ priv->irq_mask |= mask;
+}
+
+void bcmasp_enable_tx_irq(struct bcmasp_intf *intf, int en)
+{
+ struct bcmasp_priv *priv = intf->parent;
+
+ if (en)
+ _intr2_mask_clear(priv, ASP_INTR2_TX_DESC(intf->channel));
+ else
+ _intr2_mask_set(priv,
[PATCH net-next v6 2/6] dt-bindings: net: Brcm ASP 2.0 Ethernet controller
From: Florian Fainelli
Add a binding document for the Broadcom ASP 2.0 Ethernet
controller.
Reviewed-by: Conor Dooley
Signed-off-by: Florian Fainelli
Signed-off-by: Justin Chen
---
v6
- Moved compatible to the top
- Changed quotes to be consistent
- Elaborated on brcm,channel description
v5
- Fix compatible string yaml format to properly capture what we want
v4
- Adjust compatible string example to reference SoC and HW ver
v3
- Minor formatting issues
- Change channel prop to brcm,channel for vendor specific format
- Removed redundant v2.0 from compat string
- Fix ranges field
v2
- Minor formatting issues
.../devicetree/bindings/net/brcm,asp-v2.0.yaml | 153 +
1 file changed, 153 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/brcm,asp-v2.0.yaml
diff --git a/Documentation/devicetree/bindings/net/brcm,asp-v2.0.yaml
b/Documentation/devicetree/bindings/net/brcm,asp-v2.0.yaml
new file mode 100644
index ..3f2bf64b65c0
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/brcm,asp-v2.0.yaml
@@ -0,0 +1,153 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/brcm,asp-v2.0.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom ASP 2.0 Ethernet controller
+
+maintainers:
+ - Justin Chen
+ - Florian Fainelli
+
+description: Broadcom Ethernet controller first introduced with 72165
+
+properties:
+ compatible:
+oneOf:
+ - items:
+ - enum:
+ - brcm,bcm74165-asp
+ - const: brcm,asp-v2.1
+ - items:
+ - enum:
+ - brcm,bcm72165-asp
+ - const: brcm,asp-v2.0
+
+ "#address-cells":
+const: 1
+ "#size-cells":
+const: 1
+
+ reg:
+maxItems: 1
+
+ ranges: true
+
+ interrupts:
+minItems: 1
+items:
+ - description: RX/TX interrupt
+ - description: Port 0 Wake-on-LAN
+ - description: Port 1 Wake-on-LAN
+
+ clocks:
+maxItems: 1
+
+ ethernet-ports:
+type: object
+properties:
+ "#address-cells":
+const: 1
+ "#size-cells":
+const: 0
+
+patternProperties:
+ "^port@[0-9]+$":
+type: object
+
+$ref: ethernet-controller.yaml#
+
+properties:
+ reg:
+maxItems: 1
+description: Port number
+
+ brcm,channel:
+$ref: /schemas/types.yaml#/definitions/uint32
+description: |
+ ASP Channel Number
+
+ The depacketizer channel that consumes packets from
+ the unimac/port.
+
+required:
+ - reg
+ - brcm,channel
+
+additionalProperties: false
+
+patternProperties:
+ "^mdio@[0-9a-f]+$":
+type: object
+$ref: brcm,unimac-mdio.yaml
+
+description:
+ ASP internal UniMAC MDIO bus
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - ranges
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+
+ethernet@9c0 {
+compatible = "brcm,bcm72165-asp", "brcm,asp-v2.0";
+reg = <0x9c0 0x1fff14>;
+interrupts = ;
+ranges = <0x0 0x9c0 0x1fff14>;
+clocks = < 14>;
+#address-cells = <1>;
+#size-cells = <1>;
+
+mdio@c614 {
+compatible = "brcm,asp-v2.0-mdio";
+reg = <0xc614 0x8>;
+reg-names = "mdio";
+#address-cells = <1>;
+#size-cells = <0>;
+
+phy0: ethernet-phy@1 {
+reg = <1>;
+};
+ };
+
+mdio@ce14 {
+compatible = "brcm,asp-v2.0-mdio";
+reg = <0xce14 0x8>;
+reg-names = "mdio";
+#address-cells = <1>;
+#size-cells = <0>;
+
+phy1: ethernet-phy@1 {
+reg = <1>;
+};
+};
+
+ethernet-ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+reg = <0>;
+brcm,channel = <8>;
+phy-mode = "rgmii";
+phy-handle = <>;
+};
+
+port@1 {
+reg = <1>;
+brcm,channel = <9>;
+phy-mode = "rgmii";
+phy-handle = <>;
+};
+};
+};
--
2.7.4
smime.p7s
Description: S/MIME Cryptographic Signature
[PATCH net-next v6 1/6] dt-bindings: net: brcm, unimac-mdio: Add asp-v2.0
The ASP 2.0 Ethernet controller uses a brcm unimac. Reviewed-by: Simon Horman Acked-by: Conor Dooley Signed-off-by: Florian Fainelli Signed-off-by: Justin Chen --- Documentation/devicetree/bindings/net/brcm,unimac-mdio.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/net/brcm,unimac-mdio.yaml b/Documentation/devicetree/bindings/net/brcm,unimac-mdio.yaml index 0be426ee1e44..6684810fcbf0 100644 --- a/Documentation/devicetree/bindings/net/brcm,unimac-mdio.yaml +++ b/Documentation/devicetree/bindings/net/brcm,unimac-mdio.yaml @@ -22,6 +22,8 @@ properties: - brcm,genet-mdio-v3 - brcm,genet-mdio-v4 - brcm,genet-mdio-v5 + - brcm,asp-v2.0-mdio + - brcm,asp-v2.1-mdio - brcm,unimac-mdio reg: -- 2.7.4 smime.p7s Description: S/MIME Cryptographic Signature
[PATCH net-next v6 0/6] Brcm ASP 2.0 Ethernet Controller
Add support for the Broadcom ASP 2.0 Ethernet controller which is first introduced with 72165. Florian Fainelli (2): dt-bindings: net: Brcm ASP 2.0 Ethernet controller net: phy: bcm7xxx: Add EPHY entry for 74165 Justin Chen (4): dt-bindings: net: brcm,unimac-mdio: Add asp-v2.0 net: bcmasp: Add support for ASP2.0 Ethernet controller net: phy: mdio-bcm-unimac: Add asp v2.0 support MAINTAINERS: ASP 2.0 Ethernet driver maintainers .../devicetree/bindings/net/brcm,asp-v2.0.yaml | 153 ++ .../devicetree/bindings/net/brcm,unimac-mdio.yaml |2 + MAINTAINERS|9 + drivers/net/ethernet/broadcom/Kconfig | 11 + drivers/net/ethernet/broadcom/Makefile |1 + drivers/net/ethernet/broadcom/asp2/Makefile|2 + drivers/net/ethernet/broadcom/asp2/bcmasp.c| 1467 drivers/net/ethernet/broadcom/asp2/bcmasp.h| 638 + .../net/ethernet/broadcom/asp2/bcmasp_ethtool.c| 568 drivers/net/ethernet/broadcom/asp2/bcmasp_intf.c | 1393 +++ .../net/ethernet/broadcom/asp2/bcmasp_intf_defs.h | 238 drivers/net/mdio/mdio-bcm-unimac.c |2 + drivers/net/phy/bcm7xxx.c |1 + include/linux/brcmphy.h|1 + 14 files changed, 4486 insertions(+) create mode 100644 Documentation/devicetree/bindings/net/brcm,asp-v2.0.yaml create mode 100644 drivers/net/ethernet/broadcom/asp2/Makefile create mode 100644 drivers/net/ethernet/broadcom/asp2/bcmasp.c create mode 100644 drivers/net/ethernet/broadcom/asp2/bcmasp.h create mode 100644 drivers/net/ethernet/broadcom/asp2/bcmasp_ethtool.c create mode 100644 drivers/net/ethernet/broadcom/asp2/bcmasp_intf.c create mode 100644 drivers/net/ethernet/broadcom/asp2/bcmasp_intf_defs.h -- 2.7.4 smime.p7s Description: S/MIME Cryptographic Signature
Re: [PATCH v2 0/2] retrieve DSI DSC through DRM bridge
On 02/06/2023 01:08, Kuogee Hsieh wrote: move retrieving DSC from setup_display to atomic_check() and delete struct drm_dsc_config from struct msm_display_info. This is obvious from the patches themselves. You should be describing _why_ the changes are necessary, not what is changed. What was changed between v1 and v2? Kuogee Hsieh (2): drm/msm/dpu: retrieve DSI DSC struct at atomic_check() drm/msm/dpu: remove struct drm_dsc_config from struct msm_display_info drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 18 +- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h | 1 - drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 2 -- 3 files changed, 13 insertions(+), 8 deletions(-) -- With best wishes Dmitry
[PATCH v2 2/2] drm/msm/dpu: remove struct drm_dsc_config from struct msm_display_info
Since struct drm_dsc_config is retrieved at atomic_check() instead of at
display setup time during bootup. Saving struct drm_dsc_config at
struct msm_display_info is not necessary and become redundant.
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 2 --
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h | 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 2 --
3 files changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 5c440a0..53274a5 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -2332,8 +2332,6 @@ static int dpu_encoder_setup_display(struct
dpu_encoder_virt *dpu_enc,
dpu_enc->idle_pc_supported =
dpu_kms->catalog->caps->has_idle_pc;
- dpu_enc->dsc = disp_info->dsc;
-
mutex_lock(_enc->enc_lock);
for (i = 0; i < disp_info->num_of_h_tiles && !ret; i++) {
/*
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
index 2c9ef8d..50e64cf 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
@@ -36,7 +36,6 @@ struct msm_display_info {
uint32_t h_tile_instance[MAX_H_TILES_PER_DISPLAY];
bool is_cmd_mode;
bool is_te_using_watchdog_timer;
- struct drm_dsc_config *dsc;
};
/**
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index c24f487..2390e5c 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -554,8 +554,6 @@ static int _dpu_kms_initialize_dsi(struct drm_device *dev,
info.h_tile_instance[info.num_of_h_tiles++] = i;
info.is_cmd_mode = msm_dsi_is_cmd_mode(priv->dsi[i]);
- info.dsc = msm_dsi_get_dsc_config(priv->dsi[i]);
-
if (msm_dsi_is_bonded_dsi(priv->dsi[i]) && priv->dsi[other]) {
rc = msm_dsi_modeset_init(priv->dsi[other], dev,
encoder);
if (rc) {
--
2.7.4
[PATCH v2 0/2] retrieve DSI DSC through DRM bridge
move retrieving DSC from setup_display to atomic_check() and delete struct drm_dsc_config from struct msm_display_info. Kuogee Hsieh (2): drm/msm/dpu: retrieve DSI DSC struct at atomic_check() drm/msm/dpu: remove struct drm_dsc_config from struct msm_display_info drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 18 +- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h | 1 - drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 2 -- 3 files changed, 13 insertions(+), 8 deletions(-) -- 2.7.4
[PATCH v2 1/2] drm/msm/dpu: retrieve DSI DSC struct at atomic_check()
At current implementation, DSI DSC struct is populated at display setup
during system bootup. This mechanism works fine with embedded display.
But will run into problem with plugin/unplug oriented external display,
such as DP, due to DSC struct will become stale once external display
unplugged. New DSC struct has to be re populated to reflect newer external
display which just plugged in. Move retrieving of DSI DSC struct to
atomic_check() so that same mechanism will work for both embedded display
and external plugin/unplug oriented display.
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 3b416e1..5c440a0 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -604,7 +604,7 @@ static int dpu_encoder_virt_atomic_check(
struct drm_display_mode *adj_mode;
struct msm_display_topology topology;
struct dpu_global_state *global_state;
- int i = 0;
+ int index, i = 0;
int ret = 0;
if (!drm_enc || !crtc_state || !conn_state) {
@@ -639,6 +639,10 @@ static int dpu_encoder_virt_atomic_check(
}
}
+ index = dpu_enc->disp_info.h_tile_instance[0];
+if (dpu_enc->disp_info.intf_type == DRM_MODE_ENCODER_DSI)
+ dpu_enc->dsc = msm_dsi_get_dsc_config(priv->dsi[index]);
+
topology = dpu_encoder_get_topology(dpu_enc, dpu_kms, adj_mode,
crtc_state);
/*
@@ -1034,7 +1038,7 @@ static void dpu_encoder_virt_atomic_mode_set(struct
drm_encoder *drm_enc,
struct dpu_hw_blk *hw_dsc[MAX_CHANNELS_PER_ENC];
int num_lm, num_ctl, num_pp, num_dsc;
unsigned int dsc_mask = 0;
- int i;
+ int index, i;
if (!drm_enc) {
DPU_ERROR("invalid encoder\n");
@@ -1055,6 +1059,10 @@ static void dpu_encoder_virt_atomic_mode_set(struct
drm_encoder *drm_enc,
trace_dpu_enc_mode_set(DRMID(drm_enc));
+ index = dpu_enc->disp_info.h_tile_instance[0];
+if (dpu_enc->disp_info.intf_type == DRM_MODE_ENCODER_DSI)
+ dpu_enc->dsc = msm_dsi_get_dsc_config(priv->dsi[index]);
+
/* Query resource that have been reserved in atomic check step. */
num_pp = dpu_rm_get_assigned_resources(_kms->rm, global_state,
drm_enc->base.id, DPU_HW_BLK_PINGPONG, hw_pp,
@@ -2121,8 +2129,10 @@ void dpu_encoder_helper_phys_cleanup(struct
dpu_encoder_phys *phys_enc)
phys_enc->hw_pp->merge_3d->idx);
}
- if (dpu_enc->dsc)
+ if (dpu_enc->dsc) {
dpu_encoder_unprep_dsc(dpu_enc);
+ dpu_enc->dsc = NULL;
+ }
intf_cfg.stream_sel = 0; /* Don't care value for video mode */
intf_cfg.mode_3d = dpu_encoder_helper_get_3d_blend_mode(phys_enc);
--
2.7.4
Re: [GIT PULL] fbdev fixes for v6.4-rc5
The pull request you sent on Thu, 1 Jun 2023 21:28:24 +0200: > http://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git > tags/fbdev-for-6.4-rc5 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/9e87b63ed37e202c77aa17d4112da6ae0c7c097c Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [Intel-gfx] [PATCH] drm/i915/pxp: use correct format string for size_t
On Thu, 2023-06-01 at 23:36 +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> While 'unsigned long' needs the %ld format string, size_t needs the %z
> modifier:
alan:snip
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
> @@ -143,7 +143,7 @@ gsccs_send_message(struct intel_pxp *pxp,
>
> reply_size = header->message_size - sizeof(*header);
> if (reply_size > msg_out_size_max) {
> - drm_warn(>drm, "caller with insufficient PXP reply size
> %u (%ld)\n",
> + drm_warn(>drm, "caller with insufficient PXP reply size
> %u (%zd)\n",
>reply_size, msg_out_size_max);
> reply_size = msg_out_size_max;
> }
Thanks Arnd for catching this, although i believe Nathan sumbmitted a patch for
the same fix yesterday and received an RB from Andi.
How to fetch the implicit sync fence for a GPU buffer?
Hi, In the past there has been writing about Wayland's model using implicit synchronization of GPU renderbuffers and KMS commits [1] [2]. It would sometimes be nice to do that waiting explicitly in a compositor before enqueueing a KMS pageflip that references a buffer who may go on rendering for some time still. This stalls the pipeline. I'm wondering whether there's an API -- maybe something analogous to drmPrimeHandleToFD() - that allows userspace to fetch a waitable fence fd for a dmabuf? -Matt [1] https://www.collabora.com/news-and-blog/blog/2022/06/09/bridging-the-synchronization-gap-on-linux/ [2] https://lwn.net/Articles/814587/ Matt Hoosier Staff Software Engineer [auto_oem_sig_96dpi_solid]
[PATCH] drm/amdgpu: fix xclk freq on CHIP_STONEY
According to Alex, most APUs from that time seem to have the same issue
(vbios says 48Mhz, actual is 100Mhz). I only have a CHIP_STONEY so I
limit the fixup to CHIP_STONEY
---
drivers/gpu/drm/amd/amdgpu/vi.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c b/drivers/gpu/drm/amd/amdgpu/vi.c
index 770f2d7a371fc..6a8494f98d3ef 100644
--- a/drivers/gpu/drm/amd/amdgpu/vi.c
+++ b/drivers/gpu/drm/amd/amdgpu/vi.c
@@ -542,8 +542,15 @@ static u32 vi_get_xclk(struct amdgpu_device *adev)
u32 reference_clock = adev->clock.spll.reference_freq;
u32 tmp;
- if (adev->flags & AMD_IS_APU)
- return reference_clock;
+ if (adev->flags & AMD_IS_APU) {
+ switch (adev->asic_type) {
+ case CHIP_STONEY:
+ /* vbios says 48Mhz, but the actual freq is 100Mhz */
+ return 1;
+ default:
+ return reference_clock;
+ }
+ }
tmp = RREG32_SMC(ixCG_CLKPIN_CNTL_2);
if (REG_GET_FIELD(tmp, CG_CLKPIN_CNTL_2, MUX_TCLK_TO_XCLK))
--
2.41.0.rc0.172.g3f132b7071-goog
[PATCH] drm/i915/pxp: use correct format string for size_t
From: Arnd Bergmann
While 'unsigned long' needs the %ld format string, size_t needs the %z
modifier:
drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c: In function 'gsccs_send_message':
include/drm/drm_print.h:456:39: error: format '%ld' expects argument of type
'long int', but argument 4 has type 'size_t' {aka 'unsigned int'}
[-Werror=format=]
456 | dev_##level##type((drm)->dev, "[drm] " fmt, ##__VA_ARGS__)
Fixes: dc9ac125d81fa ("drm/i915/pxp: Add GSC-CS backend to send GSC fw
messages")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
index 8dc41de3f6f74..290ed5ac487de 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
@@ -143,7 +143,7 @@ gsccs_send_message(struct intel_pxp *pxp,
reply_size = header->message_size - sizeof(*header);
if (reply_size > msg_out_size_max) {
- drm_warn(>drm, "caller with insufficient PXP reply size
%u (%ld)\n",
+ drm_warn(>drm, "caller with insufficient PXP reply size
%u (%zd)\n",
reply_size, msg_out_size_max);
reply_size = msg_out_size_max;
}
--
2.39.2
Re: [PATCH v5 3/7] drm/i915/huc: Load GSC-enabled HuC via DMA xfer if the fuse says so
On 5/31/2023 16:54, Daniele Ceraolo Spurio wrote:
In the previous patch we extracted the offset of the legacy-style HuC
binary located within the GSC-enabled blob, so now we can use that to
load the HuC via DMA if the fuse is set that way.
Note that we now need to differentiate between "GSC-enabled binary" and
"loaded by GSC", so the former case has been renamed to "has GSC headers"
for clarity, while the latter is now based on the fuse instead of the
binary format. This way, all the legacy load paths are automatically
taken (including the auth by GuC) without having to implement further
code changes.
v2: s/is_meu_binary/has_gsc_headers/, clearer logs (John)
v3: split check for GSC access, better comments (John)
Signed-off-by: Daniele Ceraolo Spurio
Cc: Alan Previn
Cc: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_huc.c| 49 +--
drivers/gpu/drm/i915/gt/uc/intel_huc.h| 4 +-
drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c | 2 +-
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 12 +++---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 2 +-
5 files changed, 47 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
index 6d795438b3e4..27c5e41fa84c 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
@@ -298,31 +298,54 @@ void intel_huc_init_early(struct intel_huc *huc)
static int check_huc_loading_mode(struct intel_huc *huc)
{
struct intel_gt *gt = huc_to_gt(huc);
- bool fw_needs_gsc = intel_huc_is_loaded_by_gsc(huc);
- bool hw_uses_gsc = false;
+ bool gsc_enabled = huc->fw.has_gsc_headers;
/*
* The fuse for HuC load via GSC is only valid on platforms that have
* GuC deprivilege.
*/
if (HAS_GUC_DEPRIVILEGE(gt->i915))
- hw_uses_gsc = intel_uncore_read(gt->uncore, GUC_SHIM_CONTROL2) &
- GSC_LOADS_HUC;
+ huc->loaded_via_gsc = intel_uncore_read(gt->uncore,
GUC_SHIM_CONTROL2) &
+ GSC_LOADS_HUC;
- if (fw_needs_gsc != hw_uses_gsc) {
- huc_err(huc, "mismatch between FW (%s) and HW (%s) load
modes\n",
- HUC_LOAD_MODE_STRING(fw_needs_gsc),
HUC_LOAD_MODE_STRING(hw_uses_gsc));
+ if (huc->loaded_via_gsc && !gsc_enabled) {
+ huc_err(huc, "HW requires a GSC-enabled blob, but we found a legacy
one\n");
return -ENOEXEC;
}
- /* make sure we can access the GSC via the mei driver if we need it */
- if (!(IS_ENABLED(CONFIG_INTEL_MEI_PXP) && IS_ENABLED(CONFIG_INTEL_MEI_GSC))
&&
- fw_needs_gsc) {
- huc_info(huc, "can't load due to missing MEI modules\n");
- return -EIO;
+ /*
+* On newer platforms we have GSC-enabled binaries but we load the HuC
+* via DMA. To do so we need to find the location of the legacy-style
+* binary inside the GSC-enabled one, which we do at fetch time. Make
+* sure that we were able to do so if the fuse says we need to load via
+* DMA and the binary is GSC-enabled.
+*/
+ if (!huc->loaded_via_gsc && gsc_enabled && !huc->fw.dma_start_offset) {
+ huc_err(huc, "HW in DMA mode, but we have an incompatible
GSC-enabled blob\n");
+ return -ENOEXEC;
+ }
+
+ /*
+* If the HuC is loaded via GSC, we need to be able to access the GSC.
+* On DG2 this is done via the mei components, while on newer platforms
+* it is done via the GSCCS,
+*/
+ if (huc->loaded_via_gsc) {
+ if (IS_DG2(gt->i915)) {
+ if (!IS_ENABLED(CONFIG_INTEL_MEI_PXP) ||
+ !IS_ENABLED(CONFIG_INTEL_MEI_GSC)) {
+ huc_info(huc, "can't load due to missing mei
modules\n");
+ return -EIO;
+ }
+ } else {
+ if (!HAS_ENGINE(gt, GSC0)){
Checkpatch is complaining about lack of a space here. Maybe fix on merge
rather than repost if that is the only issue?
John.
Re: [PATCH v5 4/7] drm/i915/huc: differentiate the 2 steps of the MTL HuC auth flow
On 5/31/2023 16:54, Daniele Ceraolo Spurio wrote:
Before we add the second step of the MTL HuC auth (via GSC), we need to
have the ability to differentiate between them. To do so, the huc
authentication check is duplicated for GuC and GSC auth, with
GSC-enabled binaries being considered fully authenticated only after
the GSC auth step.
To report the difference between the 2 auth steps, a new case is added
to the HuC getparam. This way, the clear media driver can start
submitting before full auth, as partial auth is enough for those
workloads.
v2: fix authentication status check for DG2
v3: add a better comment at the top of the HuC file to explain the
different approaches to load and auth (John)
v4: update call to intel_huc_is_authenticated in the pxp code to check
for GSC authentication
v5: drop references to meu and esclamation mark in huc_auth print (John)
Signed-off-by: Daniele Ceraolo Spurio
Cc: Alan Previn
Cc: John Harrison
Reviewed-by: Alan Previn #v2
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_huc.c | 111 -
drivers/gpu/drm/i915/gt/uc/intel_huc.h | 16 ++-
drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c | 4 +-
drivers/gpu/drm/i915/i915_reg.h| 3 +
drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c | 2 +-
include/uapi/drm/i915_drm.h| 3 +-
6 files changed, 104 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
index 27c5e41fa84c..73efdb027082 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
@@ -10,6 +10,7 @@
#include "intel_huc.h"
#include "intel_huc_print.h"
#include "i915_drv.h"
+#include "i915_reg.h"
#include
#include
@@ -22,15 +23,23 @@
* capabilities by adding HuC specific commands to batch buffers.
*
* The kernel driver is only responsible for loading the HuC firmware and
- * triggering its security authentication, which is performed by the GuC on
- * older platforms and by the GSC on newer ones. For the GuC to correctly
- * perform the authentication, the HuC binary must be loaded before the GuC
one.
+ * triggering its security authentication. This is done differently depending
+ * on the platform:
+ * - older platforms (from Gen9 to most Gen12s): the load is performed via DMA
+ * and the authentication via GuC
+ * - DG2: load and authentication are both performed via GSC.
+ * - MTL and newer platforms: the load is performed via DMA (same as with
+ * not-DG2 older platforms), while the authentication is done in 2-steps,
+ * a first auth for clear-media workloads via GuC and a second one for all
+ * workloads via GSC.
+ * On platforms where the GuC does the authentication, to correctly do so the
+ * HuC binary must be loaded before the GuC one.
* Loading the HuC is optional; however, not using the HuC might negatively
* impact power usage and/or performance of media workloads, depending on the
* use-cases.
* HuC must be reloaded on events that cause the WOPCM to lose its contents
- * (S3/S4, FLR); GuC-authenticated HuC must also be reloaded on GuC/GT reset,
- * while GSC-managed HuC will survive that.
+ * (S3/S4, FLR); on older platforms the HuC must also be reloaded on GuC/GT
+ * reset, while on newer ones it will survive that.
*
* See https://github.com/intel/media-driver for the latest details on HuC
* functionality.
@@ -106,7 +115,7 @@ static enum hrtimer_restart
huc_delayed_load_timer_callback(struct hrtimer *hrti
{
struct intel_huc *huc = container_of(hrtimer, struct intel_huc,
delayed_load.timer);
- if (!intel_huc_is_authenticated(huc)) {
+ if (!intel_huc_is_authenticated(huc, INTEL_HUC_AUTH_BY_GSC)) {
if (huc->delayed_load.status == INTEL_HUC_WAITING_ON_GSC)
huc_notice(huc, "timed out waiting for MEI GSC\n");
else if (huc->delayed_load.status == INTEL_HUC_WAITING_ON_PXP)
@@ -124,7 +133,7 @@ static void huc_delayed_load_start(struct intel_huc *huc)
{
ktime_t delay;
- GEM_BUG_ON(intel_huc_is_authenticated(huc));
+ GEM_BUG_ON(intel_huc_is_authenticated(huc, INTEL_HUC_AUTH_BY_GSC));
/*
* On resume we don't have to wait for MEI-GSC to be re-probed, but we
@@ -284,13 +293,23 @@ void intel_huc_init_early(struct intel_huc *huc)
}
if (GRAPHICS_VER(i915) >= 11) {
- huc->status.reg = GEN11_HUC_KERNEL_LOAD_INFO;
- huc->status.mask = HUC_LOAD_SUCCESSFUL;
- huc->status.value = HUC_LOAD_SUCCESSFUL;
+ huc->status[INTEL_HUC_AUTH_BY_GUC].reg =
GEN11_HUC_KERNEL_LOAD_INFO;
+ huc->status[INTEL_HUC_AUTH_BY_GUC].mask = HUC_LOAD_SUCCESSFUL;
+ huc->status[INTEL_HUC_AUTH_BY_GUC].value = HUC_LOAD_SUCCESSFUL;
} else {
- huc->status.reg = HUC_STATUS2;
- huc->status.mask = HUC_FW_VERIFIED;
-
Re: [PATCH v5 3/7] drm/i915/huc: Load GSC-enabled HuC via DMA xfer if the fuse says so
On 5/31/2023 16:54, Daniele Ceraolo Spurio wrote:
In the previous patch we extracted the offset of the legacy-style HuC
binary located within the GSC-enabled blob, so now we can use that to
load the HuC via DMA if the fuse is set that way.
Note that we now need to differentiate between "GSC-enabled binary" and
"loaded by GSC", so the former case has been renamed to "has GSC headers"
for clarity, while the latter is now based on the fuse instead of the
binary format. This way, all the legacy load paths are automatically
taken (including the auth by GuC) without having to implement further
code changes.
v2: s/is_meu_binary/has_gsc_headers/, clearer logs (John)
v3: split check for GSC access, better comments (John)
Signed-off-by: Daniele Ceraolo Spurio
Cc: Alan Previn
Cc: John Harrison
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_huc.c| 49 +--
drivers/gpu/drm/i915/gt/uc/intel_huc.h| 4 +-
drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c | 2 +-
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 12 +++---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 2 +-
5 files changed, 47 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
index 6d795438b3e4..27c5e41fa84c 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
@@ -298,31 +298,54 @@ void intel_huc_init_early(struct intel_huc *huc)
static int check_huc_loading_mode(struct intel_huc *huc)
{
struct intel_gt *gt = huc_to_gt(huc);
- bool fw_needs_gsc = intel_huc_is_loaded_by_gsc(huc);
- bool hw_uses_gsc = false;
+ bool gsc_enabled = huc->fw.has_gsc_headers;
/*
* The fuse for HuC load via GSC is only valid on platforms that have
* GuC deprivilege.
*/
if (HAS_GUC_DEPRIVILEGE(gt->i915))
- hw_uses_gsc = intel_uncore_read(gt->uncore, GUC_SHIM_CONTROL2) &
- GSC_LOADS_HUC;
+ huc->loaded_via_gsc = intel_uncore_read(gt->uncore,
GUC_SHIM_CONTROL2) &
+ GSC_LOADS_HUC;
- if (fw_needs_gsc != hw_uses_gsc) {
- huc_err(huc, "mismatch between FW (%s) and HW (%s) load
modes\n",
- HUC_LOAD_MODE_STRING(fw_needs_gsc),
HUC_LOAD_MODE_STRING(hw_uses_gsc));
+ if (huc->loaded_via_gsc && !gsc_enabled) {
+ huc_err(huc, "HW requires a GSC-enabled blob, but we found a legacy
one\n");
return -ENOEXEC;
}
- /* make sure we can access the GSC via the mei driver if we need it */
- if (!(IS_ENABLED(CONFIG_INTEL_MEI_PXP) && IS_ENABLED(CONFIG_INTEL_MEI_GSC))
&&
- fw_needs_gsc) {
- huc_info(huc, "can't load due to missing MEI modules\n");
- return -EIO;
+ /*
+* On newer platforms we have GSC-enabled binaries but we load the HuC
+* via DMA. To do so we need to find the location of the legacy-style
+* binary inside the GSC-enabled one, which we do at fetch time. Make
+* sure that we were able to do so if the fuse says we need to load via
+* DMA and the binary is GSC-enabled.
+*/
+ if (!huc->loaded_via_gsc && gsc_enabled && !huc->fw.dma_start_offset) {
+ huc_err(huc, "HW in DMA mode, but we have an incompatible
GSC-enabled blob\n");
+ return -ENOEXEC;
+ }
+
+ /*
+* If the HuC is loaded via GSC, we need to be able to access the GSC.
+* On DG2 this is done via the mei components, while on newer platforms
+* it is done via the GSCCS,
+*/
+ if (huc->loaded_via_gsc) {
+ if (IS_DG2(gt->i915)) {
+ if (!IS_ENABLED(CONFIG_INTEL_MEI_PXP) ||
+ !IS_ENABLED(CONFIG_INTEL_MEI_GSC)) {
+ huc_info(huc, "can't load due to missing mei
modules\n");
+ return -EIO;
+ }
+ } else {
+ if (!HAS_ENGINE(gt, GSC0)){
+ huc_info(huc, "can't load due to missing
GSCCS\n");
+ return -EIO;
+ }
+ }
}
- huc_dbg(huc, "loaded by GSC = %s\n", str_yes_no(fw_needs_gsc));
+ huc_dbg(huc, "loaded by GSC = %s\n", str_yes_no(huc->loaded_via_gsc));
return 0;
}
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.h
b/drivers/gpu/drm/i915/gt/uc/intel_huc.h
index 0789184d81a2..112f0dce4702 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.h
@@ -39,6 +39,8 @@ struct intel_huc {
struct notifier_block nb;
enum intel_huc_delayed_load_status status;
} delayed_load;
+
+ bool loaded_via_gsc;
};
int intel_huc_sanitize(struct intel_huc *huc);
@@ -73,7 +75,7 @@ static
Re: [PATCH v5 2/7] drm/i915/huc: Parse the GSC-enabled HuC binary
On 5/31/2023 16:54, Daniele Ceraolo Spurio wrote:
The new binaries that support the 2-step authentication contain the
legacy-style binary, which we can use for loading the HuC via DMA. To
find out where this is located in the image, we need to parse the
manifest of the GSC-enabled HuC binary. The manifest consist of a
partition header followed by entries, one of which contains the offset
we're looking for.
Note that the DG2 GSC binary contains entries with the same names, but
it doesn't contain a full legacy binary, so we need to skip assigning
the dma offset in that case (which we can do by checking the ccs).
Also, since we're now parsing the entries, we can extract the HuC
version that way instead of using hardcoded offsets.
Note that the GSC binary uses the same structures in its binary header,
so they've been added in their own header file.
v2: fix structure names to match meu defines (s/CPT/CPD/), update commit
message, check ccs validity, drop old version location defines.
v3: drop references to the MEU tool to reduce confusion, fix log (John)
v4: fix log for real (John)
Signed-off-by: Daniele Ceraolo Spurio
Cc: Alan Previn
Cc: John Harrison
Reviewed-by: Alan Previn #v2
Reviewed-by: John Harrison
---
.../drm/i915/gt/uc/intel_gsc_binary_headers.h | 74 ++
drivers/gpu/drm/i915/gt/uc/intel_huc.c| 11 +-
drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c | 136 ++
drivers/gpu/drm/i915/gt/uc/intel_huc_fw.h | 5 +-
drivers/gpu/drm/i915/gt/uc/intel_huc_print.h | 21 +++
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 72 +-
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 2 +
drivers/gpu/drm/i915/gt/uc/intel_uc_fw_abi.h | 6 -
8 files changed, 274 insertions(+), 53 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_binary_headers.h
create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_huc_print.h
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_binary_headers.h
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_binary_headers.h
new file mode 100644
index ..714f0c256118
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_binary_headers.h
@@ -0,0 +1,74 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2023 Intel Corporation
+ */
+
+#ifndef _INTEL_GSC_BINARY_HEADERS_H_
+#define _INTEL_GSC_BINARY_HEADERS_H_
+
+#include
+
+/* Code partition directory (CPD) structures */
+struct intel_gsc_cpd_header_v2 {
+ u32 header_marker;
+#define INTEL_GSC_CPD_HEADER_MARKER 0x44504324
+
+ u32 num_of_entries;
+ u8 header_version;
+ u8 entry_version;
+ u8 header_length; /* in bytes */
+ u8 flags;
+ u32 partition_name;
+ u32 crc32;
+} __packed;
+
+struct intel_gsc_cpd_entry {
+ u8 name[12];
+
+ /*
+* Bits 0-24: offset from the beginning of the code partition
+* Bit 25: huffman compressed
+* Bits 26-31: reserved
+*/
+ u32 offset;
+#define INTEL_GSC_CPD_ENTRY_OFFSET_MASK GENMASK(24, 0)
+#define INTEL_GSC_CPD_ENTRY_HUFFMAN_COMP BIT(25)
+
+ /*
+* Module/Item length, in bytes. For Huffman-compressed modules, this
+* refers to the uncompressed size. For software-compressed modules,
+* this refers to the compressed size.
+*/
+ u32 length;
+
+ u8 reserved[4];
+} __packed;
+
+struct intel_gsc_version {
+ u16 major;
+ u16 minor;
+ u16 hotfix;
+ u16 build;
+} __packed;
+
+struct intel_gsc_manifest_header {
+ u32 header_type; /* 0x4 for manifest type */
+ u32 header_length; /* in dwords */
+ u32 header_version;
+ u32 flags;
+ u32 vendor;
+ u32 date;
+ u32 size; /* In dwords, size of entire manifest (header + extensions) */
+ u32 header_id;
+ u32 internal_data;
+ struct intel_gsc_version fw_version;
+ u32 security_version;
+ struct intel_gsc_version meu_kit_version;
+ u32 meu_manifest_version;
+ u8 general_data[4];
+ u8 reserved3[56];
+ u32 modulus_size; /* in dwords */
+ u32 exponent_size; /* in dwords */
+} __packed;
+
+#endif
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
index 268e036f8f28..6d795438b3e4 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
@@ -6,23 +6,14 @@
#include
#include "gt/intel_gt.h"
-#include "gt/intel_gt_print.h"
#include "intel_guc_reg.h"
#include "intel_huc.h"
+#include "intel_huc_print.h"
#include "i915_drv.h"
#include
#include
-#define huc_printk(_huc, _level, _fmt, ...) \
- gt_##_level(huc_to_gt(_huc), "HuC: " _fmt, ##__VA_ARGS__)
-#define huc_err(_huc, _fmt, ...) huc_printk((_huc), err, _fmt,
##__VA_ARGS__)
-#define huc_warn(_huc, _fmt, ...) huc_printk((_huc), warn, _fmt,
##__VA_ARGS__)
-#define huc_notice(_huc, _fmt, ...)huc_printk((_huc), notice, _fmt,
##__VA_ARGS__)
-#define
Re: [PATCH 21/36] drm/amd/display: add CRTC 3D LUT support
On 5/23/23 18:15, Melissa Wen wrote:
> Wire up DC 3D LUT to DM CRTC color management (post-blending). On AMD
> display HW, we have to set a shaper LUT to delinearize or normalize the
> color space before applying a 3D LUT (since we have a reduced number of
> LUT entries). Therefore, we map DC shaper LUT to DM CRTC color mgmt in
> the next patch.
>
> Signed-off-by: Melissa Wen
> ---
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 6 +
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 17 ++
> .../amd/display/amdgpu_dm/amdgpu_dm_color.c | 158 +-
> 3 files changed, 180 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 0be62fe436b0..a6dd982d7e77 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -9976,6 +9976,12 @@ static int amdgpu_dm_atomic_check(struct drm_device
> *dev,
> goto fail;
> }
>
> + ret = amdgpu_dm_verify_lut3d_size(adev, new_crtc_state);
> + if (ret) {
> + drm_dbg_driver(dev, "amdgpu_dm_verify_lut_sizes()
> failed\n");
> + goto fail;
> + }
> +
> if (!new_crtc_state->enable)
> continue;
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> index e5f9db5a43f4..eebe12c353ad 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> @@ -797,6 +797,21 @@ struct dm_crtc_state {
>
> int abm_level;
>
> + /* AMD driver-private CRTC color management
> + *
> + * DRM provides CRTC degamma/ctm/gamma color mgmt features, but AMD HW
> + * has a larger set of post-blending color calibration. Here, DC MPC
> + * color caps are wired up to DM CRTC state:
> + */
> + /**
> + * @lut3d:
> + *
> + * Post-blending 3D Lookup table for converting pixel data. When
> + * supported by HW (DCN 3+), it is positioned just before post-blending
> + * regamma and always assumes a preceding shaper LUT. The blob (if not
> + * NULL) is an array of drm_color_lut.
> + */
> + struct drm_property_blob *lut3d;
> /**
>* @regamma_tf:
>*
> @@ -868,6 +883,8 @@ void amdgpu_dm_trigger_timing_sync(struct drm_device
> *dev);
> /* 3D LUT max size is 17x17x17 */
> #define MAX_COLOR_3DLUT_ENTRIES 4913
> #define MAX_COLOR_3DLUT_BITDEPTH 12
> +int amdgpu_dm_verify_lut3d_size(struct amdgpu_device *adev,
> + const struct drm_crtc_state *crtc_state);
> /* 1D LUT size */
> #define MAX_COLOR_LUT_ENTRIES 4096
> /* Legacy gamm LUT users such as X doesn't like large LUT sizes */
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
> index 161807e19886..cef8d0d7f37b 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
> @@ -364,6 +364,96 @@ static int __set_input_tf(struct dc_transfer_func *func,
> return res ? 0 : -ENOMEM;
> }
>
> +static void __to_dc_lut3d_color(struct dc_rgb *rgb,
> + const struct drm_color_lut lut,
> + int bit_precision)
> +{
> + rgb->red = drm_color_lut_extract(lut.red, bit_precision);
> + rgb->green = drm_color_lut_extract(lut.green, bit_precision);
> + rgb->blue = drm_color_lut_extract(lut.blue, bit_precision);
> +}
> +
> +static void __drm_3dlut_to_dc_3dlut(const struct drm_color_lut *lut,
> + uint32_t lut3d_size,
> + struct tetrahedral_params *params,
> + bool use_tetrahedral_9,
> + int bit_depth)
> +{
> + struct dc_rgb *lut0;
> + struct dc_rgb *lut1;
> + struct dc_rgb *lut2;
> + struct dc_rgb *lut3;
> + int lut_i, i;
> +
> +
> + if (use_tetrahedral_9) {
> + lut0 = params->tetrahedral_9.lut0;
> + lut1 = params->tetrahedral_9.lut1;
> + lut2 = params->tetrahedral_9.lut2;
> + lut3 = params->tetrahedral_9.lut3;
> + } else {
> + lut0 = params->tetrahedral_17.lut0;
> + lut1 = params->tetrahedral_17.lut1;
> + lut2 = params->tetrahedral_17.lut2;
> + lut3 = params->tetrahedral_17.lut3;
> + }
> +
> + for (lut_i = 0, i = 0; i < lut3d_size - 4; lut_i++, i += 4) {
> + /* We should consider the 3dlut RGB values are distributed
> + * along four arrays lut0-3 where the first sizes 1229 and the
> + * other 1228. The bit depth supported for 3dlut channel is
> + * 12-bit, but
Re: [PATCH -next] drm/amdkfd: clean up one inconsistent indenting
On 2023-05-30 22:08, Yang Li wrote:
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_device.c:1036 kgd2kfd_interrupt()
warn: inconsistent indenting
Signed-off-by: Yang Li
Reviewed-by: Felix Kuehling
I'm applying the patch to amd-staging-drm-next. Thanks!
---
drivers/gpu/drm/amd/amdkfd/kfd_device.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
index 862a50f7b490..0398a8c52a44 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
@@ -1033,7 +1033,7 @@ void kgd2kfd_interrupt(struct kfd_dev *kfd, const void
*ih_ring_entry)
is_patched ? patched_ihre : ih_ring_entry)) {
kfd_queue_work(node->ih_wq, >interrupt_work);
spin_unlock_irqrestore(>interrupt_lock, flags);
- return;
+ return;
}
spin_unlock_irqrestore(>interrupt_lock, flags);
}
Re: [PATCH v3 7/7] drm/msm/dpu: simplify dpu_encoder_phys_wb_init()
On 6/1/2023 10:22 AM, Dmitry Baryshkov wrote: There is no need to assign a result to temp varable just to return it after a goto. Drop the temporary variable and goto and return the result directly. Reviewed-by: Abhinav Kumar Signed-off-by: Dmitry Baryshkov --- Tested-by: Abhinav Kumar # sc7280
Re: [PATCH v3 6/7] drm/msm/dpu: drop temp variable from dpu_encoder_phys_cmd_init()
On 6/1/2023 10:22 AM, Dmitry Baryshkov wrote: There is no need to assign a result to temp varable just to return it two lines below. Drop the temporary variable. Reviewed-by: Abhinav Kumar Signed-off-by: Dmitry Baryshkov --- Tested-by: Abhinav Kumar # sc7280
Re: [PATCH v3 5/7] drm/msm/dpu: call dpu_rm_get_intf() from dpu_encoder_get_intf()
On 6/1/2023 10:22 AM, Dmitry Baryshkov wrote: There is little sense to get intf index just to call dpu_rm_get_intf() on it. Move dpu_rm_get_intf() call to dpu_encoder_get_intf() function. Reviewed-by: Abhinav Kumar Signed-off-by: Dmitry Baryshkov --- Tested-by: Abhinav Kumar # sc7280
Re: [PATCH v3 4/7] drm/msm/dpu: inline dpu_encoder_get_wb()
On 6/1/2023 10:22 AM, Dmitry Baryshkov wrote: The function dpu_encoder_get_wb() returns controller_id if the corresponding WB is present in the catalog. We can inline this function and rely on dpu_rm_get_wb() returning NULL for indices for which the WB is not present on the device. Reviewed-by: Abhinav Kumar Signed-off-by: Dmitry Baryshkov --- Tested-by: Abhinav Kumar # sc7280
Re: [PATCH v3 3/7] drm/msm/dpu: drop duplicated intf/wb indices from encoder structs
On 6/1/2023 10:22 AM, Dmitry Baryshkov wrote: Remove intf_idx and wb_idx fields from struct dpu_encoder_phys and struct dpu_enc_phys_init_params. Set the hw_intf and hw_wb directly and use them to get the instance index. Reviewed-by: Abhinav Kumar Signed-off-by: Dmitry Baryshkov --- Tested-by: Abhinav Kumar # sc7280
Re: [Freedreno] [PATCH v3 2/7] drm/msm/dpu: separate common function to init physical encoder
On 6/1/2023 10:22 AM, Dmitry Baryshkov wrote: Move common DPU physical encoder initialization code to the new function dpu_encoder_phys_init(). Reviewed-by: Abhinav Kumar Signed-off-by: Dmitry Baryshkov --- Tested-by: Abhinav Kumar # sc7280
Re: [PATCH 09/36] drm/amd/display: add plane HDR multiplier driver-specific property
On 5/23/23 18:14, Melissa Wen wrote:
> From: Joshua Ashton
>
> Multiplier to 'gain' the plane. When PQ is decoded using the fixed func
> transfer function to the internal FP16 fb, 1.0 -> 80 nits (on AMD at
> least) When sRGB is decoded, 1.0 -> 1.0. Therefore, 1.0 multiplier = 80
> nits for SDR content. So if you want, 203 nits for SDR content, pass in
> (203.0 / 80.0).
>
> Signed-off-by: Joshua Ashton
> Co-developed-by: Melissa Wen
> Signed-off-by: Melissa Wen
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 6 ++
> drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h| 4
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 12
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c | 13 +
> 4 files changed, 35 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> index fd6c4078c53a..f0e12cca295d 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> @@ -1298,6 +1298,12 @@ amdgpu_display_create_color_properties(struct
> amdgpu_device *adev)
> return -ENOMEM;
> adev->mode_info.plane_degamma_tf_property = prop;
>
> + prop = drm_property_create_range(adev_to_drm(adev),
> + 0, "AMD_PLANE_HDR_MULT", 0, U64_MAX);
> + if (!prop)
> + return -ENOMEM;
> + adev->mode_info.plane_hdr_mult_property = prop;
> +
> return 0;
> }
> #endif
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> index 9d7f47fe6303..c105f51b7b6d 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> @@ -365,6 +365,10 @@ struct amdgpu_mode_info {
>* linearize content with or without LUT.
>*/
> struct drm_property *plane_degamma_tf_property;
> + /**
> + * @plane_hdr_mult_property:
> + */
> + struct drm_property *plane_hdr_mult_property;
> };
>
> #define AMDGPU_MAX_BL_LEVEL 0xFF
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> index b8e432cc8078..dadbef561606 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> @@ -51,6 +51,7 @@
>
> #define AMDGPU_DMUB_NOTIFICATION_MAX 5
>
> +#define AMDGPU_HDR_MULT_DEFAULT (0x1LL)
> /*
> #include "include/amdgpu_dal_power_if.h"
> #include "amdgpu_dm_irq.h"
> @@ -732,6 +733,17 @@ struct dm_plane_state {
>* linearize.
>*/
> enum drm_transfer_function degamma_tf;
> + /**
> + * @hdr_mult:
> + *
> + * Multiplier to 'gain' the plane. When PQ is decoded using the fixed
> + * func transfer function to the internal FP16 fb, 1.0 -> 80 nits (on
> + * AMD at least). When sRGB is decoded, 1.0 -> 1.0, obviously.
> + * Therefore, 1.0 multiplier = 80 nits for SDR content. So if you
> + * want, 203 nits for SDR content, pass in (203.0 / 80.0). Format is
> + * S31.32 sign-magnitude.
> + */
Good explanation.
Harry
> + __u64 hdr_mult;
> };
>
> struct dm_crtc_state {
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
> index 6b71777a525c..bbbf25dd2515 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
> @@ -1322,6 +1322,7 @@ static void dm_drm_plane_reset(struct drm_plane *plane)
>
> __drm_atomic_helper_plane_reset(plane, _state->base);
> amdgpu_state->degamma_tf = DRM_TRANSFER_FUNCTION_DEFAULT;
> + amdgpu_state->hdr_mult = AMDGPU_HDR_MULT_DEFAULT;
> }
>
> static struct drm_plane_state *
> @@ -1345,6 +1346,7 @@ dm_drm_plane_duplicate_state(struct drm_plane *plane)
> drm_property_blob_get(dm_plane_state->degamma_lut);
>
> dm_plane_state->degamma_tf = old_dm_plane_state->degamma_tf;
> + dm_plane_state->hdr_mult = old_dm_plane_state->hdr_mult;
>
> return _plane_state->base;
> }
> @@ -1450,6 +1452,10 @@ dm_atomic_plane_attach_color_mgmt_properties(struct
> amdgpu_display_manager *dm,
>
> dm->adev->mode_info.plane_degamma_tf_property,
> DRM_TRANSFER_FUNCTION_DEFAULT);
> }
> + /* HDR MULT is always available */
> + drm_object_attach_property(>base,
> +dm->adev->mode_info.plane_hdr_mult_property,
> +AMDGPU_HDR_MULT_DEFAULT);
> }
>
> static int
> @@ -1476,6 +1482,11 @@ dm_atomic_plane_set_property(struct drm_plane *plane,
> dm_plane_state->degamma_tf = val;
> dm_plane_state->base.color_mgmt_changed = 1;
> }
> + } else if (property ==
Re: [PATCH 5/6] drm/panel: simple: add support for Rocktech RK043FN48H panel
Hi Dario,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-intel/for-linux-next-fixes]
[also build test WARNING on drm-tip/drm-tip linus/master v6.4-rc4 next-20230601]
[cannot apply to atorgue-stm32/stm32-next drm-misc/drm-misc-next
drm-intel/for-linux-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Dario-Binacchi/ARM-dts-stm32-add-ltdc-support-on-stm32f746-MCU/20230602-010536
base: git://anongit.freedesktop.org/drm-intel for-linux-next-fixes
patch link:
https://lore.kernel.org/r/20230601170320.2845218-6-dario.binacchi%40amarulasolutions.com
patch subject: [PATCH 5/6] drm/panel: simple: add support for Rocktech
RK043FN48H panel
config: mips-allyesconfig
(https://download.01.org/0day-ci/archive/20230602/202306020343.jntwem0p-...@intel.com/config)
compiler: mips-linux-gcc (GCC) 12.3.0
reproduce (this is a W=1 build):
mkdir -p ~/bin
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/intel-lab-lkp/linux/commit/5a692e898df9428078855c58f8e945def084613b
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review
Dario-Binacchi/ARM-dts-stm32-add-ltdc-support-on-stm32f746-MCU/20230602-010536
git checkout 5a692e898df9428078855c58f8e945def084613b
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.3.0 ~/bin/make.cross
W=1 O=build_dir ARCH=mips olddefconfig
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.3.0 ~/bin/make.cross
W=1 O=build_dir ARCH=mips SHELL=/bin/bash drivers/gpu/
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot
| Closes:
https://lore.kernel.org/oe-kbuild-all/202306020343.jntwem0p-...@intel.com/
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/panel/panel-simple.c:3201:68: warning: suggest parentheses
>> around arithmetic in operand of '|' [-Wparentheses]
3201 | .flags = DISPLAY_FLAGS_VSYNC_LOW + DISPLAY_FLAGS_HSYNC_LOW |
|^
vim +3201 drivers/gpu/drm/panel/panel-simple.c
3190
3191 static const struct display_timing rocktech_rk043fn48h_timing = {
3192 .pixelclock = { 600, 900, 1200 },
3193 .hactive = { 480, 480, 480 },
3194 .hback_porch = { 8, 43, 43 },
3195 .hfront_porch = { 2, 8, 8 },
3196 .hsync_len = { 1, 1, 1 },
3197 .vactive = { 272, 272, 272 },
3198 .vback_porch = { 2, 12, 12 },
3199 .vfront_porch = { 1, 4, 4 },
3200 .vsync_len = { 1, 10, 10 },
> 3201 .flags = DISPLAY_FLAGS_VSYNC_LOW + DISPLAY_FLAGS_HSYNC_LOW |
3202 DISPLAY_FLAGS_DE_HIGH | DISPLAY_FLAGS_PIXDATA_POSEDGE,
3203 };
3204
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
Re: [PATCH v3 1/7] drm/msm/dpu: merge dpu_encoder_init() and dpu_encoder_setup()
On 6/1/2023 10:22 AM, Dmitry Baryshkov wrote: There is no reason to split the dpu_encoder interface into separate _init() and _setup() phases. Merge them into a single function. Reviewed-by: Abhinav Kumar Signed-off-by: Dmitry Baryshkov --- Tested-by: Abhinav Kumar # sc7280
[GIT PULL] fbdev fixes for v6.4-rc5
Hi Linus, please pull some fbdev fixes & cleanups for kernel 6.4-rc5. Most noteably is a fix for a null-ptr-deref in fbcon's soft_cursor function which was found by syzbot. Thanks! Helge -- The following changes since commit 44c026a73be8038f03dbdeef028b642880cf1511: Linux 6.4-rc3 (2023-05-21 14:05:48 -0700) are available in the Git repository at: http://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git tags/fbdev-for-6.4-rc5 for you to fetch changes up to d19663edc91de65ae85eea9902addc9d04b0ceb6: fbdev: bw2: Convert to platform remove callback returning void (2023-05-30 18:33:25 +0200) fbdev fixes for kernel 6.4-rc5: - Fix null-ptr-deref in soft_cursor - various remove callback conversions - error path fixes in imsttfb Helge Deller (3): fbdev: imsttfb: Release framebuffer and dealloc cmap on error path fbdev: imsttfb: Fix error path of imsttfb_probe() fbcon: Fix null-ptr-deref in soft_cursor Uwe Kleine-König (7): fbdev: matroxfb ssd1307fb: Switch i2c drivers back to use .probe() fbdev: au1100fb: Drop if with an always false condition fbdev: arcfb: Convert to platform remove callback returning void fbdev: au1100fb: Convert to platform remove callback returning void fbdev: au1200fb: Convert to platform remove callback returning void fbdev: broadsheetfb: Convert to platform remove callback returning void fbdev: bw2: Convert to platform remove callback returning void drivers/video/fbdev/arcfb.c | 5 ++--- drivers/video/fbdev/au1100fb.c | 11 +++ drivers/video/fbdev/au1200fb.c | 6 ++ drivers/video/fbdev/broadsheetfb.c | 5 ++--- drivers/video/fbdev/bw2.c | 6 ++ drivers/video/fbdev/core/bitblit.c | 3 +++ drivers/video/fbdev/imsttfb.c | 12 +--- drivers/video/fbdev/matrox/matroxfb_maven.c | 2 +- drivers/video/fbdev/ssd1307fb.c | 2 +- 9 files changed, 25 insertions(+), 27 deletions(-)
Re: [PATCH 07/36] drm/amd/display: add plane driver-specific properties for degamma LUT
On 5/23/23 18:14, Melissa Wen wrote:
> Create and attach driver-private properties for plane color management.
> First add plane degamma LUT properties that means user-blob and its
> size. We will add more plane color properties in the next commits. In
> addition, we keep these driver-private plane properties limited by
> defining AMD_PRIVATE_COLOR.
>
> Co-developed-by: Joshua Ashton
> Signed-off-by: Joshua Ashton
> Signed-off-by: Melissa Wen
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 14
> drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 8 ++
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 9 +++
> .../amd/display/amdgpu_dm/amdgpu_dm_plane.c | 77 +++
> 4 files changed, 108 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> index 88af075e6c18..fa67c84f5994 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> @@ -1275,6 +1275,20 @@ amdgpu_display_create_color_properties(struct
> amdgpu_device *adev)
> return -ENOMEM;
> adev->mode_info.regamma_tf_property = prop;
>
> + prop = drm_property_create(adev_to_drm(adev),
> +DRM_MODE_PROP_BLOB,
> +"AMD_PLANE_DEGAMMA_LUT", 0);
> + if (!prop)
> + return -ENOMEM;
> + adev->mode_info.plane_degamma_lut_property = prop;
> +
> + prop = drm_property_create_range(adev_to_drm(adev),
> + DRM_MODE_PROP_IMMUTABLE,
> + "AMD_PLANE_DEGAMMA_LUT_SIZE", 0,
> UINT_MAX);
> + if (!prop)
> + return -ENOMEM;
> + adev->mode_info.plane_degamma_lut_size_property = prop;
> +
Same as with previous patch and the following ones... Would be
great to have this sit in amdgpu_dm_color.c.
Harry
> return 0;
> }
> #endif
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> index 881446c51b36..6c165ad9bdf0 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> @@ -352,6 +352,14 @@ struct amdgpu_mode_info {
>* drm_transfer_function`.
>*/
> struct drm_property *regamma_tf_property;
> + /* @plane_degamma_lut_property: Plane property to set a degamma LUT to
> + * convert color space before blending.
> + */
> + struct drm_property *plane_degamma_lut_property;
> + /* @plane_degamma_lut_size_property: Plane property to define the max
> + * size of degamma LUT as supported by the driver (read-only).
> + */
> + struct drm_property *plane_degamma_lut_size_property;
> };
>
> #define AMDGPU_MAX_BL_LEVEL 0xFF
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> index ad5ee28b83dc..22e126654767 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> @@ -716,6 +716,15 @@ enum drm_transfer_function {
> struct dm_plane_state {
> struct drm_plane_state base;
> struct dc_plane_state *dc_state;
> +
> + /* Plane color mgmt */
> + /**
> + * @degamma_lut:
> + *
> + * LUT for converting plane pixel data before going into plane merger.
> + * The blob (if not NULL) is an array of drm_color_lut.
> + */
> + struct drm_property_blob *degamma_lut;
> };
>
> struct dm_crtc_state {
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
> index 322668973747..e9cedc4068f1 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
> @@ -1338,6 +1338,9 @@ dm_drm_plane_duplicate_state(struct drm_plane *plane)
> dc_plane_state_retain(dm_plane_state->dc_state);
> }
>
> + if (dm_plane_state->degamma_lut)
> + drm_property_blob_get(dm_plane_state->degamma_lut);
> +
> return _plane_state->base;
> }
>
> @@ -1405,12 +1408,79 @@ static void dm_drm_plane_destroy_state(struct
> drm_plane *plane,
> {
> struct dm_plane_state *dm_plane_state = to_dm_plane_state(state);
>
> + if (dm_plane_state->degamma_lut)
> + drm_property_blob_put(dm_plane_state->degamma_lut);
> +
> if (dm_plane_state->dc_state)
> dc_plane_state_release(dm_plane_state->dc_state);
>
> drm_atomic_helper_plane_destroy_state(plane, state);
> }
>
> +#ifdef AMD_PRIVATE_COLOR
> +static void
> +dm_atomic_plane_attach_color_mgmt_properties(struct amdgpu_display_manager
> *dm,
> + struct drm_plane *plane)
> +{
> + if (dm->dc->caps.color.dpp.dgam_ram ||
> dm->dc->caps.color.dpp.gamma_corr ) {
> + drm_object_attach_property(>base,
> +
Re: [Freedreno] [PATCH] Revert "drm/msm/dp: Remove INIT_SETUP delay"
Hi Leonard On 5/24/2023 5:58 AM, Leonard Lausen wrote: [ 275.025497] [drm:dpu_encoder_phys_vid_wait_for_commit_done:488] [dpu error]vblank timeout [ 275.025514] [drm:dpu_kms_wait_for_commit_done:510] [dpu error]wait for commit done returned -110 [ 275.064141] [drm:dpu_encoder_frame_done_timeout:2382] [dpu error]enc33 frame done timeout This is a different crash but the root-cause of both the issues is the bridge hpd_enable/disable series. https://patchwork.freedesktop.org/patch/514414/ Yes, the new patch to fix this issue is here https://patchwork.freedesktop.org/patch/538601/?series=118148=3 Apologies if you were not CCed on this, if a next version is CCed, will ask kuogee to cc you. Meanwhile, will be great if you can verify if it works for you and provide Tested-by tags. Hi Leonard, I had cc you with v5 patches. Would you please verify it. Hi Kuogee, thank you. Verified the v6 patch fixes the regression when ported to 6.3.3. One non-fatal issue remains: Suspending and resuming the system while USB-C DP monitor is connected triggers an error, though the system recovers within a second without the need to unplug the cable. [drm:drm_mode_config_helper_resume] *ERROR* Failed to resume (-107) We are not able to recreate this on sc7280 chromebooks , will need to check on sc7180. This does not seem directly related to any of the hotplug changes though so needs to be checked separately. So please feel free to raise a gitlab bug for this and assign to me.
Re: [PATCH 06/36] drm/amd/display: add CRTC driver-specific property for gamma TF
On 5/23/23 18:14, Melissa Wen wrote:
> Hook up driver-specific atomic operations for managing AMD color
> properties and create AMD driver-specific color management properties
> and attach them according to HW capabilities defined by `struct
> dc_color_caps`. Add enumerated transfer function property to DRM CRTC
> gamma to convert to wire encoding with or without a user gamma LUT.
> Enumerated TFs are not supported yet by the DRM color pipeline,
> therefore, create a DRM enum list with the predefined TFs supported by
> the AMD display driver.
>
> Co-developed-by: Joshua Ashton
> Signed-off-by: Joshua Ashton
> Signed-off-by: Melissa Wen
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 36 ++
> drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 8 +++
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 22 ++
> .../amd/display/amdgpu_dm/amdgpu_dm_crtc.c| 72 ++-
> 4 files changed, 137 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> index 389396eac222..88af075e6c18 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> @@ -1247,6 +1247,38 @@ amdgpu_display_user_framebuffer_create(struct
> drm_device *dev,
> return _fb->base;
> }
>
> +static const struct drm_prop_enum_list drm_transfer_function_enum_list[] = {
> + { DRM_TRANSFER_FUNCTION_DEFAULT, "Default" },
> + { DRM_TRANSFER_FUNCTION_SRGB, "sRGB" },
> + { DRM_TRANSFER_FUNCTION_BT709, "BT.709" },
> + { DRM_TRANSFER_FUNCTION_PQ, "PQ (Perceptual Quantizer)" },
> + { DRM_TRANSFER_FUNCTION_LINEAR, "Linear" },
> + { DRM_TRANSFER_FUNCTION_UNITY, "Unity" },
> + { DRM_TRANSFER_FUNCTION_HLG, "HLG (Hybrid Log Gamma)" },
> + { DRM_TRANSFER_FUNCTION_GAMMA22, "Gamma 2.2" },
> + { DRM_TRANSFER_FUNCTION_GAMMA24, "Gamma 2.4" },
> + { DRM_TRANSFER_FUNCTION_GAMMA26, "Gamma 2.6" },
> +};
Let's not use the DRM_/drm_ prefix here. It might clash later when
we introduce DRM_ core interfaces for enumerated transfer functions.
We'll want to specify whether something is an EOTF or an inverse EOTF,
or possibly an OETF. Of course that wouldn't apply to "Linear" or
"Unity" (I'm assuming the two are the same?).
EOTF = electro-optical transfer function
This is the transfer function to go from the encoded value to an
optical (linear) value.
Inverse EOTF = simply the inverse of the EOTF
This is usually intended to go from an optical/linear space (which
might have been used for blending) back to the encoded values.
OETF = opto-electronic transfer function
This is usually used for converting optical signals into encoded
values. Usually that's done on the camera side but I think HLG might
define the OETF instead of the EOTF. A bit fuzzy on that. If you're
unclear about HLG I recommend we don't include it yet.
It would also be good to document a bit more what each of the TFs
mean, but I'm fine if that comes later with a "driver-agnostic"
API. The key thing to clarify is whether we have an EOTF or inv_EOTF,
i.e. whether we use the TF to go from encoded to optical or vice
versa.
I know DC is sloppy and doesn't define those but it will still use
them as either EOTF or inv_EOTF, based on which block they're being
programmed, if I'm not mistaken.
> +
> +#ifdef AMD_PRIVATE_COLOR
> +static int
> +amdgpu_display_create_color_properties(struct amdgpu_device *adev)
> +{
> + struct drm_property *prop;
> +
> + prop = drm_property_create_enum(adev_to_drm(adev),
> + DRM_MODE_PROP_ENUM,
> + "AMD_REGAMMA_TF",
> + drm_transfer_function_enum_list,
> +
> ARRAY_SIZE(drm_transfer_function_enum_list));
> + if (!prop)
> + return -ENOMEM;
> + adev->mode_info.regamma_tf_property = prop;
> +
> + return 0;
> +}
> +#endif
> +
It'd be nice if we have this function and the above enum_list
in amdgpu_dm, possibly in amdgpu_dm_color.c. You could call it
directly after the amdgpu_display_modeset_create_prop() call in
amdgpu_dm_mode_config_init().
> const struct drm_mode_config_funcs amdgpu_mode_funcs = {
> .fb_create = amdgpu_display_user_framebuffer_create,
> };
> @@ -1323,6 +1355,10 @@ int amdgpu_display_modeset_create_props(struct
> amdgpu_device *adev)
> return -ENOMEM;
> }
>
> +#ifdef AMD_PRIVATE_COLOR
> + if (amdgpu_display_create_color_properties(adev))
> + return -ENOMEM;
> +#endif
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> index b8633df418d4..881446c51b36 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> @@ -344,6 +344,14 @@ struct amdgpu_mode_info {
> int disp_priority;
Re: [PATCH v2 2/3] arm64: dts: qcom: sc8280xp: Add GPU related nodes
On Tue, May 30, 2023 at 08:35:14AM -0700, Bjorn Andersson wrote:
>
> On Mon, May 29, 2023 at 02:16:14PM +0530, Manivannan Sadhasivam wrote:
> > On Mon, May 29, 2023 at 09:38:59AM +0200, Konrad Dybcio wrote:
> > > On 28.05.2023 19:07, Manivannan Sadhasivam wrote:
> > > > On Tue, May 23, 2023 at 09:59:53AM +0200, Konrad Dybcio wrote:
> > > >> On 23.05.2023 03:15, Bjorn Andersson wrote:
> > > >>> From: Bjorn Andersson
> [..]
> > > >>> diff --git a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
> > > >>> b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
> [..]
> > > >>> + gmu: gmu@3d6a000 {
> [..]
> > > >>> + status = "disabled";
> > > >> I've recently discovered that - and I am not 100% sure - all GMUs are
> > > >> cache-coherent. Could you please ask somebody at qc about this?
> > > >>
> > > >
> > > > AFAIU, GMU's job is controlling the voltage and clock to the GPU.
> > > Not just that, it's only the limited functionality we've implemented
> > > upstream so far.
> > >
> >
> > Okay, good to know!
> >
> > > It doesn't do
> > > > any data transactions on its own.
> > > Of course it does. AP communication is done through MMIO writes and
> > > the GMU talks to RPMh via the GPU RSC directly. Apart from that, some
> > > of the GPU registers (that nota bene don't have anything to do with
> > > the GMU M3 core itself) lay within the GMU address space.
> > >
>
> But those aren't shared memory accesses.
>
> >
> > That doesn't justify the fact that cache coherency is needed, especially
> > MMIO writes, unless GMU could snoop the MMIO writes to AP caches.
> >
>
> In reviewing the downstream state again I noticed that the GPU smmu is
> marked dma-coherent, so I will adjust that in v3.
Bjorn,
Would you mind sharing a perf delta (preferrably manhattan offscreen)
you see with and without this dma-coherent property?
-Akhil.
>
> Regards,
> Bjorn
Re: [PATCH v2 2/3] arm64: dts: qcom: sc8280xp: Add GPU related nodes
On Mon, May 29, 2023 at 09:38:59AM +0200, Konrad Dybcio wrote:
>
>
>
> On 28.05.2023 19:07, Manivannan Sadhasivam wrote:
> > On Tue, May 23, 2023 at 09:59:53AM +0200, Konrad Dybcio wrote:
> >>
> >>
> >> On 23.05.2023 03:15, Bjorn Andersson wrote:
> >>> From: Bjorn Andersson
> >>>
> >>> Add Adreno SMMU, GPU clock controller, GMU and GPU nodes for the
> >>> SC8280XP.
> >>>
> >>> Signed-off-by: Bjorn Andersson
> >>> Signed-off-by: Bjorn Andersson
> >>> ---
> >> It does not look like you tested the DTS against bindings. Please run
> >> `make dtbs_check` (see
> >> Documentation/devicetree/bindings/writing-schema.rst for instructions).
> >>
> >>>
> >>> Changes since v1:
> >>> - Dropped gmu_pdc_seq region from , as it shouldn't have been used.
> >>> - Added missing compatible to _smmu.
> >>> - Dropped aoss_qmp clock in and _smmu.
> >>>
> >>> arch/arm64/boot/dts/qcom/sc8280xp.dtsi | 169 +
> >>> 1 file changed, 169 insertions(+)
> >>>
> >>> diff --git a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
> >>> b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
> >>> index d2a2224d138a..329ec2119ecf 100644
> >>> --- a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
> >>> +++ b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
> >>> @@ -6,6 +6,7 @@
> >>>
> >>> #include
> >>> #include
> >>> +#include
> >>> #include
> >>> #include
> >>> #include
> >>> @@ -2331,6 +2332,174 @@ tcsr: syscon@1fc {
> >>> reg = <0x0 0x01fc 0x0 0x3>;
> >>> };
> >>>
> >>> + gpu: gpu@3d0 {
> >>> + compatible = "qcom,adreno-690.0", "qcom,adreno";
> >>> +
> >>> + reg = <0 0x03d0 0 0x4>,
> >>> + <0 0x03d9e000 0 0x1000>,
> >>> + <0 0x03d61000 0 0x800>;
> >>> + reg-names = "kgsl_3d0_reg_memory",
> >>> + "cx_mem",
> >>> + "cx_dbgc";
> >>> + interrupts = ;
> >>> + iommus = <_smmu 0 0xc00>, <_smmu 1 0xc00>;
> >>> + operating-points-v2 = <_opp_table>;
> >>> +
> >>> + qcom,gmu = <>;
> >>> + interconnects = <_noc MASTER_GFX3D 0 _virt
> >>> SLAVE_EBI1 0>;
> >>> + interconnect-names = "gfx-mem";
> >>> + #cooling-cells = <2>;
> >>> +
> >>> + status = "disabled";
> >>> +
> >>> + gpu_opp_table: opp-table {
> >>> + compatible = "operating-points-v2";
> >>> +
> >>> + opp-27000 {
> >>> + opp-hz = /bits/ 64 <27000>;
> >>> + opp-level =
> >>> ;
> >>> + opp-peak-kBps = <451000>;
> >>> + };
> >>> +
> >>> + opp-41000 {
> >>> + opp-hz = /bits/ 64 <41000>;
> >>> + opp-level = ;
> >>> + opp-peak-kBps = <1555000>;
> >>> + };
> >>> +
> >>> + opp-5 {
> >>> + opp-hz = /bits/ 64 <5>;
> >>> + opp-level =
> >>> ;
> >>> + opp-peak-kBps = <1555000>;
> >>> + };
> >>> +
> >>> + opp-54700 {
> >>> + opp-hz = /bits/ 64 <54700>;
> >>> + opp-level =
> >>> ;
> >>> + opp-peak-kBps = <1555000>;
> >>> + };
> >>> +
> >>> + opp-60600 {
> >>> + opp-hz = /bits/ 64 <60600>;
> >>> + opp-level = ;
> >>> + opp-peak-kBps = <2736000>;
> >>> + };
> >>> +
> >>> + opp-64000 {
> >>> + opp-hz = /bits/ 64 <64000>;
> >>> + opp-level =
> >>> ;
> >>> + opp-peak-kBps = <2736000>;
> >>> + };
> >>> +
> >>> + opp-69000 {
> >>> + opp-hz = /bits/ 64 <69000>;
> >>> + opp-level =
> >>> ;
> >>> + opp-peak-kBps = <2736000>;
> >>> + };
> >>> + };
> >>> + };
> >>> +
> >>> + gmu: gmu@3d6a000 {
> >>> + compatible = "qcom,adreno-gmu-690.0", "qcom,adreno-gmu";
> >>> + reg = <0 0x03d6a000 0 0x34000>,
> >>> + <0 0x03de 0 0x1>,
> >>> + <0 0x0b29 0 0x1>;
> >>> + reg-names = "gmu", "rscc", "gmu_pdc";
> >>> + interrupts = ,
> >>> +
Re: [PATCH v3 1/3] drm/msm/adreno: Add Adreno A690 support
On Wed, May 31, 2023 at 10:30:09PM +0200, Konrad Dybcio wrote:
>
>
>
> On 31.05.2023 05:09, Bjorn Andersson wrote:
> > From: Bjorn Andersson
> >
> > Introduce support for the Adreno A690, found in Qualcomm SC8280XP.
> >
> > Tested-by: Steev Klimaszewski
> > Reviewed-by: Konrad Dybcio
> > Signed-off-by: Bjorn Andersson
> > Signed-off-by: Bjorn Andersson
> > ---
> Couple of additional nits that you may or may not incorporate:
>
> [...]
>
> > + {REG_A6XX_RBBM_CLOCK_HYST_SP0, 0xF3CF},
> It would be cool if we could stop adding uppercase hex outside preprocessor
> defines..
>
>
> [...]
> > + A6XX_PROTECT_RDONLY(0x0fc00, 0x01fff),
> > + A6XX_PROTECT_NORDWR(0x11c00, 0x0), /*note: infiite range */
> typo
>
>
>
> -- Questions to Rob that don't really concern this patch --
>
> > +static void a690_build_bw_table(struct a6xx_hfi_msg_bw_table *msg)
> Rob, I'll be looking into reworking these into dynamic tables.. would you
> be okay with two more additions (A730, A740) on top of this before I do that?
> The number of these funcs has risen quite a bit and we're abusing the fact
> that so far there's a 1-1 mapping of SoC-Adreno (at the current state of
> mainline, not in general)..
+1. But please leave a618 and 7c3 as it is.
-Akhil
>
> > +{
> > + /*
> > +* Send a single "off" entry just to get things running
> > +* TODO: bus scaling
> > +*/
> Also something I'll be looking into in the near future..
>
> > @@ -531,6 +562,8 @@ static int a6xx_hfi_send_bw_table(struct a6xx_gmu *gmu)
> > adreno_7c3_build_bw_table();
> > else if (adreno_is_a660(adreno_gpu))
> > a660_build_bw_table();
> > + else if (adreno_is_a690(adreno_gpu))
> > + a690_build_bw_table();
> > else
> > a6xx_build_bw_table();
> I think changing the is_adreno_... to switch statements with a gpu_model
> var would make it easier to read.. Should I also rework that?
>
> Konrad
>
> >
> > diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
> > b/drivers/gpu/drm/msm/adreno/adreno_device.c
> > index 8cff86e9d35c..e5a865024e94 100644
> > --- a/drivers/gpu/drm/msm/adreno/adreno_device.c
> > +++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
> > @@ -355,6 +355,20 @@ static const struct adreno_info gpulist[] = {
> > .init = a6xx_gpu_init,
> > .zapfw = "a640_zap.mdt",
> > .hwcg = a640_hwcg,
> > + }, {
> > + .rev = ADRENO_REV(6, 9, 0, ANY_ID),
> > + .revn = 690,
> > + .name = "A690",
> > + .fw = {
> > + [ADRENO_FW_SQE] = "a660_sqe.fw",
> > + [ADRENO_FW_GMU] = "a690_gmu.bin",
> > + },
> > + .gmem = SZ_4M,
> > + .inactive_period = DRM_MSM_INACTIVE_PERIOD,
> > + .init = a6xx_gpu_init,
> > + .zapfw = "a690_zap.mdt",
> > + .hwcg = a690_hwcg,
> > + .address_space_size = SZ_16G,
> > },
> > };
> >
> > diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
> > b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
> > index f62612a5c70f..ac9c429ca07b 100644
> > --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
> > +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
> > @@ -55,7 +55,7 @@ struct adreno_reglist {
> > u32 value;
> > };
> >
> > -extern const struct adreno_reglist a615_hwcg[], a630_hwcg[], a640_hwcg[],
> > a650_hwcg[], a660_hwcg[];
> > +extern const struct adreno_reglist a615_hwcg[], a630_hwcg[], a640_hwcg[],
> > a650_hwcg[], a660_hwcg[], a690_hwcg[];
> >
> > struct adreno_info {
> > struct adreno_rev rev;
> > @@ -272,6 +272,11 @@ static inline int adreno_is_a660(struct adreno_gpu
> > *gpu)
> > return gpu->revn == 660;
> > }
> >
> > +static inline int adreno_is_a690(struct adreno_gpu *gpu)
> > +{
> > + return gpu->revn == 690;
> > +};
> > +
> > /* check for a615, a616, a618, a619 or any derivatives */
> > static inline int adreno_is_a615_family(struct adreno_gpu *gpu)
> > {
> > @@ -280,13 +285,13 @@ static inline int adreno_is_a615_family(struct
> > adreno_gpu *gpu)
> >
> > static inline int adreno_is_a660_family(struct adreno_gpu *gpu)
> > {
> > - return adreno_is_a660(gpu) || adreno_is_7c3(gpu);
> > + return adreno_is_a660(gpu) || adreno_is_a690(gpu) || adreno_is_7c3(gpu);
> > }
> >
> > /* check for a650, a660, or any derivatives */
> > static inline int adreno_is_a650_family(struct adreno_gpu *gpu)
> > {
> > - return gpu->revn == 650 || gpu->revn == 620 ||
> > adreno_is_a660_family(gpu);
> > + return gpu->revn == 650 || gpu->revn == 620 ||
> > adreno_is_a660_family(gpu);
> > }
> >
> > u64 adreno_private_address_space_size(struct msm_gpu *gpu);
Re: [PATCH 4/6] dt-bindings: display: simple: add Rocktech RK043FN48H
On Thu, Jun 01, 2023 at 07:03:18PM +0200, Dario Binacchi wrote: > Add compatible to panel-simple for Rocktech Displays Limited > RK043FN48H 4.3" 480x272 LCD-TFT panel. > > Signed-off-by: Dario Binacchi > --- > > .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > index 01560fe226dd..bd6a92d2b41c 100644 > --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > @@ -280,6 +280,8 @@ properties: >- rocktech,rk101ii01d-ct > # Rocktech Display Ltd. RK070ER9427 800(RGB)x480 TFT LCD panel >- rocktech,rk070er9427 > +# Rocktech Display Ltd. RK043FN48H 4.3" 480x272 LCD-TFT panel > + - rocktech,rk043fn48h I was going to ask why not alphanumerically, but clearly things are not in that order to begin with ¯\_(ツ)_/¯ Acked-by: Conor Dooley Cheers, Conor. > # Samsung 13.3" FHD (1920x1080 pixels) eDP AMOLED panel >- samsung,atna33xc20 > # Samsung 12.2" (2560x1600 pixels) TFT LCD panel > -- > 2.32.0 > signature.asc Description: PGP signature
[PATCH] drm/i915/pxp: Optimize GET_PARAM:PXP_STATUS
After recent discussions with Mesa folks, it was requested
that we optimize i915's GET_PARAM for the PXP_STATUS without
changing the UAPI spec.
This patch adds this additional optimizations:
- If any PXP initializatoin flow failed, then ensure that
we catch it so that we can change the returned PXP_STATUS
from "2" (i.e. 'PXP is supported but not yet ready')
to "-ENODEV". This typically should not happen and if it
does, we have a platform configuration.
- If a PXP arbitration session creation event failed
due to incorrect firmware version or blocking SOC fusing
or blocking BIOS configuration (platform reasons that won't
change if we retry), then reflect that blockage by also
returning -ENODEV in the GET_PARAM-PXP_STATUS.
- GET_PARAM:PXP_STATUS should not wait at all if PXP is
supported but non-i915 dependencies (component-driver /
firmware) we are still pending to complete the init flows.
In this case, just return "2" immediately (i.e. 'PXP is
supported but not yet ready').
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c | 11 +-
drivers/gpu/drm/i915/i915_getparam.c | 2 +-
drivers/gpu/drm/i915/pxp/intel_pxp.c | 25 ++
drivers/gpu/drm/i915/pxp/intel_pxp.h | 2 +-
drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c | 7 +++---
drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 7 +++---
drivers/gpu/drm/i915/pxp/intel_pxp_types.h | 9
7 files changed, 50 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
index fb0984f875f9..4dd744c96a37 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
@@ -42,8 +42,17 @@ static void gsc_work(struct work_struct *work)
}
ret = intel_gsc_proxy_request_handler(gsc);
- if (ret)
+ if (ret) {
+ if (actions & GSC_ACTION_FW_LOAD) {
+ /*
+* a proxy request failure that came together
with the
+* firmware load action means the last part of
init has
+* failed so GSC fw won't be usable after this
+*/
+ intel_uc_fw_change_status(>fw,
INTEL_UC_FIRMWARE_LOAD_FAIL);
+ }
goto out_put;
+ }
/* mark the GSC FW init as done the first time we run this */
if (actions & GSC_ACTION_FW_LOAD) {
diff --git a/drivers/gpu/drm/i915/i915_getparam.c
b/drivers/gpu/drm/i915/i915_getparam.c
index 6f11d7eaa91a..1b2ee98a158a 100644
--- a/drivers/gpu/drm/i915/i915_getparam.c
+++ b/drivers/gpu/drm/i915/i915_getparam.c
@@ -105,7 +105,7 @@ int i915_getparam_ioctl(struct drm_device *dev, void *data,
return value;
break;
case I915_PARAM_PXP_STATUS:
- value = intel_pxp_get_readiness_status(i915->pxp);
+ value = intel_pxp_get_readiness_status(i915->pxp, 1);
if (value < 0)
return value;
break;
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index bb2e15329f34..1478bb9b4e26 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -359,21 +359,38 @@ void intel_pxp_end(struct intel_pxp *pxp)
intel_runtime_pm_put(>runtime_pm, wakeref);
}
+static bool pxp_required_fw_failed(struct intel_pxp *pxp)
+{
+ if (__intel_uc_fw_status(>ctrl_gt->uc.huc.fw) ==
INTEL_UC_FIRMWARE_LOAD_FAIL)
+ return true;
+ if (HAS_ENGINE(pxp->ctrl_gt, GSC0) &&
+ __intel_uc_fw_status(>ctrl_gt->uc.gsc.fw) ==
INTEL_UC_FIRMWARE_LOAD_FAIL)
+ return true;
+
+ return false;
+}
+
/*
* this helper is used by both intel_pxp_start and by
* the GET_PARAM IOCTL that user space calls. Thus, the
* return values here should match the UAPI spec.
*/
-int intel_pxp_get_readiness_status(struct intel_pxp *pxp)
+int intel_pxp_get_readiness_status(struct intel_pxp *pxp, int timeout)
{
if (!intel_pxp_is_enabled(pxp))
return -ENODEV;
+ if (pxp_required_fw_failed(pxp))
+ return -ENODEV;
+
+ if (pxp->platform_cfg_is_bad)
+ return -ENODEV;
+
if (HAS_ENGINE(pxp->ctrl_gt, GSC0)) {
- if (wait_for(intel_pxp_gsccs_is_ready_for_sessions(pxp), 250))
+ if (wait_for(intel_pxp_gsccs_is_ready_for_sessions(pxp),
timeout))
return 2;
} else {
- if (wait_for(pxp_component_bound(pxp), 250))
+ if (wait_for(pxp_component_bound(pxp), timeout))
return 2;
}
return 1;
@@ -387,7 +404,7
Re: [PATCH v2 1/2] dt-bindings: display: bridge: Add NXP i.MX93 parallel display format configuration
On 31/05/2023 11:32, Liu Ying wrote: > NXP i.MX93 mediamix blk-ctrl contains one DISPLAY_MUX register which > configures parallel display format by using the "PARALLEL_DISP_FORMAT" > field. Add device tree bindings for the display format configuration. > > Signed-off-by: Liu Ying > --- > v1->v2: > * No change. How did you implement Rob's comment? > > .../display/bridge/nxp,imx93-pdfc.yaml| 78 +++ > 1 file changed, 78 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/bridge/nxp,imx93-pdfc.yaml > Best regards, Krzysztof
[linux-next:master] BUILD REGRESSION 571d71e886a5edc89b4ea6d0fe6f445282938320
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 571d71e886a5edc89b4ea6d0fe6f445282938320 Add linux-next specific
files for 20230601
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202305230552.wobyqyya-...@intel.com
https://lore.kernel.org/oe-kbuild-all/202305311652.op9x8xkw-...@intel.com
https://lore.kernel.org/oe-kbuild-all/202306010248.g3zqqg4w-...@intel.com
https://lore.kernel.org/oe-kbuild-all/202306011356.mntu7q9z-...@intel.com
https://lore.kernel.org/oe-kbuild-all/202306011435.2bxshfue-...@intel.com
https://lore.kernel.org/oe-kbuild-all/202306011753.7examz0m-...@intel.com
https://lore.kernel.org/oe-kbuild-all/202306011915.bwdy8aj8-...@intel.com
Error/Warning: (recently discovered and may have been fixed)
drivers/net/dsa/qca/qca8k-leds.c:377:31: error: 'struct led_classdev' has no
member named 'hw_control_is_supported'
drivers/net/dsa/qca/qca8k-leds.c:378:31: error: 'struct led_classdev' has no
member named 'hw_control_set'
drivers/net/dsa/qca/qca8k-leds.c:379:31: error: 'struct led_classdev' has no
member named 'hw_control_get'
drivers/net/dsa/qca/qca8k-leds.c:380:31: error: 'struct led_classdev' has no
member named 'hw_control_trigger'
drivers/net/dsa/qca/qca8k-leds.c:406:18: error: no member named
'hw_control_get_device' in 'struct led_classdev'
drivers/net/dsa/qca/qca8k-leds.c:406:31: error: 'struct led_classdev' has no
member named 'hw_control_get_device'
include/drm/drm_print.h:456:39: error: format '%ld' expects argument of type
'long int', but argument 4 has type 'size_t' {aka 'unsigned int'}
[-Werror=format=]
include/linux/usb/typec_mux.h:76:33: warning: 'fwnode_typec_mux_get' used but
never defined
include/linux/usb/typec_mux.h:77:1: error: expected identifier or '('
include/linux/usb/typec_mux.h:77:1: error: expected identifier or '(' before
'{' token
mm/zswap.c:1183:6: warning: variable 'ret' is used uninitialized whenever 'if'
condition is true [-Wsometimes-uninitialized]
Unverified Error/Warning (likely false positive, please contact us if
interested):
arch/arm64/kvm/mmu.c:147:3-9: preceding lock on line 140
fs/smb/client/cifsfs.c:982 cifs_smb3_do_mount() warn: possible memory leak of
'cifs_sb'
fs/smb/client/cifssmb.c:4089 CIFSFindFirst() warn: missing error code? 'rc'
fs/smb/client/cifssmb.c:4216 CIFSFindNext() warn: missing error code? 'rc'
fs/smb/client/connect.c:2725 cifs_match_super() error: 'tlink' dereferencing
possible ERR_PTR()
fs/smb/client/connect.c:2924 generic_ip_connect() error: we previously assumed
'socket' could be null (see line 2912)
fs/xfs/scrub/fscounters.c:459 xchk_fscounters() warn: ignoring unreachable code.
kernel/events/uprobes.c:478 uprobe_write_opcode() warn: passing zero to
'PTR_ERR'
{standard input}:1078: Error: pcrel too far
Error/Warning ids grouped by kconfigs:
gcc_recent_errors
|-- arc-randconfig-c004-20230531
| |--
include-linux-usb-typec_mux.h:error:expected-identifier-or-(-before-token
| `--
include-linux-usb-typec_mux.h:warning:fwnode_typec_mux_get-used-but-never-defined
|-- arm64-randconfig-c033-20230531
| |-- arch-arm64-kvm-mmu.c:preceding-lock-on-line
| |--
include-linux-usb-typec_mux.h:error:expected-identifier-or-(-before-token
| `--
include-linux-usb-typec_mux.h:warning:fwnode_typec_mux_get-used-but-never-defined
|-- arm64-randconfig-r001-20230531
| |--
drivers-net-dsa-qca-qca8k-leds.c:error:struct-led_classdev-has-no-member-named-hw_control_get
| |--
drivers-net-dsa-qca-qca8k-leds.c:error:struct-led_classdev-has-no-member-named-hw_control_get_device
| |--
drivers-net-dsa-qca-qca8k-leds.c:error:struct-led_classdev-has-no-member-named-hw_control_is_supported
| |--
drivers-net-dsa-qca-qca8k-leds.c:error:struct-led_classdev-has-no-member-named-hw_control_set
| `--
drivers-net-dsa-qca-qca8k-leds.c:error:struct-led_classdev-has-no-member-named-hw_control_trigger
|-- arm64-randconfig-r016-20230601
| `--
include-linux-usb-typec_mux.h:error:expected-identifier-or-(-before-token
|-- i386-allyesconfig
| `--
include-drm-drm_print.h:error:format-ld-expects-argument-of-type-long-int-but-argument-has-type-size_t-aka-unsigned-int
|-- i386-randconfig-m021-20230531
| |--
fs-smb-client-cifsfs.c-cifs_smb3_do_mount()-warn:possible-memory-leak-of-cifs_sb
| |-- fs-smb-client-cifssmb.c-CIFSFindFirst()-warn:missing-error-code-rc
| |-- fs-smb-client-cifssmb.c-CIFSFindNext()-warn:missing-error-code-rc
| |--
fs-smb-client-connect.c-cifs_match_super()-error:tlink-dereferencing-possible-ERR_PTR()
| |--
fs-smb-client-connect.c-generic_ip_connect()-error:we-previously-assumed-socket-could-be-null-(see-line-)
| |--
fs-xfs-scrub-fscounters.c-xchk_fscounters()-warn:ignoring-unreachable-code.
| `--
kernel-events-uprobes.c-uprobe_write_opcode()-warn:passing-zero-to-PTR_ERR
|-- riscv-randconfig-m031-20230531
| |--
drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c-amdgpu_gfx_enable_kcq()-warn:inconsistent-indenting
| `--
kernel-events
[PATCH v3 6/7] drm/msm/dpu: drop temp variable from dpu_encoder_phys_cmd_init()
There is no need to assign a result to temp varable just to return it
two lines below. Drop the temporary variable.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
index 2cc6b0cd2710..4f8c9187f76d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
@@ -756,15 +756,13 @@ struct dpu_encoder_phys *dpu_encoder_phys_cmd_init(
{
struct dpu_encoder_phys *phys_enc = NULL;
struct dpu_encoder_phys_cmd *cmd_enc = NULL;
- int ret = 0;
DPU_DEBUG("intf\n");
cmd_enc = kzalloc(sizeof(*cmd_enc), GFP_KERNEL);
if (!cmd_enc) {
- ret = -ENOMEM;
DPU_ERROR("failed to allocate\n");
- return ERR_PTR(ret);
+ return ERR_PTR(-ENOMEM);
}
phys_enc = _enc->base;
--
2.39.2
[PATCH v3 7/7] drm/msm/dpu: simplify dpu_encoder_phys_wb_init()
There is no need to assign a result to temp varable just to return it
after a goto. Drop the temporary variable and goto and return the result
directly.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
index 17575591a4eb..edcac512fe68 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
@@ -693,21 +693,18 @@ struct dpu_encoder_phys *dpu_encoder_phys_wb_init(
{
struct dpu_encoder_phys *phys_enc = NULL;
struct dpu_encoder_phys_wb *wb_enc = NULL;
- int ret = 0;
DPU_DEBUG("\n");
if (!p || !p->parent) {
DPU_ERROR("invalid params\n");
- ret = -EINVAL;
- goto fail_alloc;
+ return ERR_PTR(-EINVAL);
}
wb_enc = kzalloc(sizeof(*wb_enc), GFP_KERNEL);
if (!wb_enc) {
DPU_ERROR("failed to allocate wb phys_enc enc\n");
- ret = -ENOMEM;
- goto fail_alloc;
+ return ERR_PTR(-ENOMEM);
}
phys_enc = _enc->base;
@@ -724,7 +721,4 @@ struct dpu_encoder_phys *dpu_encoder_phys_wb_init(
DPU_DEBUG("Created dpu_encoder_phys for wb %d\n", phys_enc->hw_wb->idx);
return phys_enc;
-
-fail_alloc:
- return ERR_PTR(ret);
}
--
2.39.2
[PATCH v3 5/7] drm/msm/dpu: call dpu_rm_get_intf() from dpu_encoder_get_intf()
There is little sense to get intf index just to call dpu_rm_get_intf()
on it. Move dpu_rm_get_intf() call to dpu_encoder_get_intf() function.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 20
1 file changed, 8 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 94432451e175..c04b551c9d34 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -1270,22 +1270,23 @@ static void dpu_encoder_virt_atomic_disable(struct
drm_encoder *drm_enc,
mutex_unlock(_enc->enc_lock);
}
-static enum dpu_intf dpu_encoder_get_intf(const struct dpu_mdss_cfg *catalog,
+static struct dpu_hw_intf *dpu_encoder_get_intf(const struct dpu_mdss_cfg
*catalog,
+ struct dpu_rm *dpu_rm,
enum dpu_intf_type type, u32 controller_id)
{
int i = 0;
if (type == INTF_WB)
- return INTF_MAX;
+ return NULL;
for (i = 0; i < catalog->intf_count; i++) {
if (catalog->intf[i].type == type
&& catalog->intf[i].controller_id == controller_id) {
- return catalog->intf[i].id;
+ return dpu_rm_get_intf(dpu_rm, catalog->intf[i].id);
}
}
- return INTF_MAX;
+ return NULL;
}
void dpu_encoder_vblank_callback(struct drm_encoder *drm_enc,
@@ -2262,7 +2263,6 @@ static int dpu_encoder_setup_display(struct
dpu_encoder_virt *dpu_enc,
* h_tile_instance_ids[2] = {1, 0}; DSI1 = left, DSI0 = right
*/
u32 controller_id = disp_info->h_tile_instance[i];
- enum dpu_intf intf_idx;
if (disp_info->num_of_h_tiles > 1) {
if (i == 0)
@@ -2276,12 +2276,9 @@ static int dpu_encoder_setup_display(struct
dpu_encoder_virt *dpu_enc,
DPU_DEBUG("h_tile_instance %d = %d, split_role %d\n",
i, controller_id, phys_params.split_role);
- intf_idx = dpu_encoder_get_intf(dpu_kms->catalog,
-
disp_info->intf_type,
- controller_id);
-
- if (intf_idx >= INTF_0 && intf_idx < INTF_MAX)
- phys_params.hw_intf = dpu_rm_get_intf(_kms->rm,
intf_idx);
+ phys_params.hw_intf = dpu_encoder_get_intf(dpu_kms->catalog,
_kms->rm,
+ disp_info->intf_type,
+ controller_id);
if (disp_info->intf_type == INTF_WB && controller_id < WB_MAX)
phys_params.hw_wb = dpu_rm_get_wb(_kms->rm,
controller_id);
@@ -2305,7 +2302,6 @@ static int dpu_encoder_setup_display(struct
dpu_encoder_virt *dpu_enc,
DPU_ERROR_ENC(dpu_enc, "failed to add phys encs\n");
break;
}
-
}
mutex_unlock(_enc->enc_lock);
--
2.39.2
[PATCH v3 3/7] drm/msm/dpu: drop duplicated intf/wb indices from encoder structs
Remove intf_idx and wb_idx fields from struct dpu_encoder_phys and
struct dpu_enc_phys_init_params. Set the hw_intf and hw_wb directly and
use them to get the instance index.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 72 ---
.../gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 12 ++--
.../drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 18 ++---
.../drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 2 +-
.../drm/msm/disp/dpu1/dpu_encoder_phys_wb.c | 8 +--
5 files changed, 47 insertions(+), 65 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 475b30bef72d..0b9f1b3c6c11 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -339,7 +339,8 @@ void dpu_encoder_helper_report_irq_timeout(struct
dpu_encoder_phys *phys_enc,
DRM_ERROR("irq timeout id=%u, intf_mode=%s intf=%d wb=%d, pp=%d,
intr=%d\n",
DRMID(phys_enc->parent),
dpu_encoder_helper_get_intf_type(phys_enc->intf_mode),
- phys_enc->intf_idx - INTF_0, phys_enc->wb_idx - WB_0,
+ phys_enc->hw_intf ? phys_enc->hw_intf->idx - INTF_0 :
-1,
+ phys_enc->hw_wb ? phys_enc->hw_wb->idx - WB_0 : -1,
phys_enc->hw_pp->idx - PINGPONG_0, intr_idx);
dpu_encoder_frame_done_callback(phys_enc->parent, phys_enc,
@@ -1419,7 +1420,8 @@ void dpu_encoder_frame_done_callback(
*/
trace_dpu_enc_frame_done_cb_not_busy(DRMID(drm_enc),
event,
dpu_encoder_helper_get_intf_type(ready_phys->intf_mode),
- ready_phys->intf_idx,
ready_phys->wb_idx);
+ ready_phys->hw_intf ?
ready_phys->hw_intf->idx : -1,
+ ready_phys->hw_wb ?
ready_phys->hw_wb->idx : -1);
return;
}
@@ -1499,7 +1501,8 @@ static void _dpu_encoder_trigger_flush(struct drm_encoder
*drm_enc,
trace_dpu_enc_trigger_flush(DRMID(drm_enc),
dpu_encoder_helper_get_intf_type(phys->intf_mode),
- phys->intf_idx, phys->wb_idx,
+ phys->hw_intf ? phys->hw_intf->idx : -1,
+ phys->hw_wb ? phys->hw_wb->idx : -1,
pending_kickoff_cnt, ctl->idx,
extra_flush_bits, ret);
}
@@ -2110,7 +2113,8 @@ static int _dpu_encoder_status_show(struct seq_file *s,
void *data)
struct dpu_encoder_phys *phys = dpu_enc->phys_encs[i];
seq_printf(s, "intf:%d wb:%d vsync:%8d underrun:%8d",
- phys->intf_idx - INTF_0, phys->wb_idx - WB_0,
+ phys->hw_intf ? phys->hw_intf->idx - INTF_0 :
-1,
+ phys->hw_wb ? phys->hw_wb->idx - WB_0 : -1,
atomic_read(>vsync_cnt),
atomic_read(>underrun_cnt));
@@ -2274,6 +2278,8 @@ static int dpu_encoder_setup_display(struct
dpu_encoder_virt *dpu_enc,
* h_tile_instance_ids[2] = {1, 0}; DSI1 = left, DSI0 = right
*/
u32 controller_id = disp_info->h_tile_instance[i];
+ enum dpu_intf intf_idx;
+ enum dpu_wb wb_idx;
if (disp_info->num_of_h_tiles > 1) {
if (i == 0)
@@ -2287,57 +2293,39 @@ static int dpu_encoder_setup_display(struct
dpu_encoder_virt *dpu_enc,
DPU_DEBUG("h_tile_instance %d = %d, split_role %d\n",
i, controller_id, phys_params.split_role);
- phys_params.intf_idx = dpu_encoder_get_intf(dpu_kms->catalog,
+ intf_idx = dpu_encoder_get_intf(dpu_kms->catalog,
disp_info->intf_type,
controller_id);
- phys_params.wb_idx = dpu_encoder_get_wb(dpu_kms->catalog,
+ wb_idx = dpu_encoder_get_wb(dpu_kms->catalog,
disp_info->intf_type, controller_id);
- /*
-* The phys_params might represent either an INTF or a WB unit,
but not
-* both of them at the same time.
-*/
- if ((phys_params.intf_idx == INTF_MAX) &&
- (phys_params.wb_idx == WB_MAX)) {
- DPU_ERROR_ENC(dpu_enc, "could not get intf or wb: type
%d, id %d\n",
- disp_info->intf_type,
controller_id);
- ret = -EINVAL;
- }
- if ((phys_params.intf_idx !=
[PATCH v3 4/7] drm/msm/dpu: inline dpu_encoder_get_wb()
The function dpu_encoder_get_wb() returns controller_id if the
corresponding WB is present in the catalog. We can inline this function
and rely on dpu_rm_get_wb() returning NULL for indices for which the
WB is not present on the device.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 24 ++---
1 file changed, 2 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 0b9f1b3c6c11..94432451e175 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -1288,22 +1288,6 @@ static enum dpu_intf dpu_encoder_get_intf(const struct
dpu_mdss_cfg *catalog,
return INTF_MAX;
}
-static enum dpu_wb dpu_encoder_get_wb(const struct dpu_mdss_cfg *catalog,
- enum dpu_intf_type type, u32 controller_id)
-{
- int i = 0;
-
- if (type != INTF_WB)
- return WB_MAX;
-
- for (i = 0; i < catalog->wb_count; i++) {
- if (catalog->wb[i].id == controller_id)
- return catalog->wb[i].id;
- }
-
- return WB_MAX;
-}
-
void dpu_encoder_vblank_callback(struct drm_encoder *drm_enc,
struct dpu_encoder_phys *phy_enc)
{
@@ -2279,7 +2263,6 @@ static int dpu_encoder_setup_display(struct
dpu_encoder_virt *dpu_enc,
*/
u32 controller_id = disp_info->h_tile_instance[i];
enum dpu_intf intf_idx;
- enum dpu_wb wb_idx;
if (disp_info->num_of_h_tiles > 1) {
if (i == 0)
@@ -2297,14 +2280,11 @@ static int dpu_encoder_setup_display(struct
dpu_encoder_virt *dpu_enc,
disp_info->intf_type,
controller_id);
- wb_idx = dpu_encoder_get_wb(dpu_kms->catalog,
- disp_info->intf_type, controller_id);
-
if (intf_idx >= INTF_0 && intf_idx < INTF_MAX)
phys_params.hw_intf = dpu_rm_get_intf(_kms->rm,
intf_idx);
- if (wb_idx >= WB_0 && wb_idx < WB_MAX)
- phys_params.hw_wb = dpu_rm_get_wb(_kms->rm, wb_idx);
+ if (disp_info->intf_type == INTF_WB && controller_id < WB_MAX)
+ phys_params.hw_wb = dpu_rm_get_wb(_kms->rm,
controller_id);
if (!phys_params.hw_intf && !phys_params.hw_wb) {
DPU_ERROR_ENC(dpu_enc, "no intf or wb block assigned at
idx: %d\n", i);
--
2.39.2
[PATCH v3 1/7] drm/msm/dpu: merge dpu_encoder_init() and dpu_encoder_setup()
There is no reason to split the dpu_encoder interface into separate
_init() and _setup() phases. Merge them into a single function.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 55 +
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h | 14 +---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 87 -
3 files changed, 56 insertions(+), 100 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index d7cd4734dc7d..d4b759e8f2ae 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -2388,7 +2388,8 @@ static const struct drm_encoder_funcs dpu_encoder_funcs =
{
.early_unregister = dpu_encoder_early_unregister,
};
-int dpu_encoder_setup(struct drm_device *dev, struct drm_encoder *enc,
+struct drm_encoder *dpu_encoder_init(struct drm_device *dev,
+ int drm_enc_mode,
struct msm_display_info *disp_info)
{
struct msm_drm_private *priv = dev->dev_private;
@@ -2397,7 +2398,23 @@ int dpu_encoder_setup(struct drm_device *dev, struct
drm_encoder *enc,
struct dpu_encoder_virt *dpu_enc = NULL;
int ret = 0;
- dpu_enc = to_dpu_encoder_virt(enc);
+ dpu_enc = devm_kzalloc(dev->dev, sizeof(*dpu_enc), GFP_KERNEL);
+ if (!dpu_enc)
+ return ERR_PTR(-ENOMEM);
+
+ ret = drm_encoder_init(dev, _enc->base, _encoder_funcs,
+ drm_enc_mode, NULL);
+ if (ret) {
+ devm_kfree(dev->dev, dpu_enc);
+ return ERR_PTR(ret);
+ }
+
+ drm_encoder_helper_add(_enc->base, _encoder_helper_funcs);
+
+ spin_lock_init(_enc->enc_spinlock);
+ dpu_enc->enabled = false;
+ mutex_init(_enc->enc_lock);
+ mutex_init(_enc->rc_lock);
ret = dpu_encoder_setup_display(dpu_enc, dpu_kms, disp_info);
if (ret)
@@ -2426,44 +2443,14 @@ int dpu_encoder_setup(struct drm_device *dev, struct
drm_encoder *enc,
DPU_DEBUG_ENC(dpu_enc, "created\n");
- return ret;
+ return _enc->base;
fail:
DPU_ERROR("failed to create encoder\n");
if (drm_enc)
dpu_encoder_destroy(drm_enc);
- return ret;
-
-
-}
-
-struct drm_encoder *dpu_encoder_init(struct drm_device *dev,
- int drm_enc_mode)
-{
- struct dpu_encoder_virt *dpu_enc = NULL;
- int rc = 0;
-
- dpu_enc = devm_kzalloc(dev->dev, sizeof(*dpu_enc), GFP_KERNEL);
- if (!dpu_enc)
- return ERR_PTR(-ENOMEM);
-
-
- rc = drm_encoder_init(dev, _enc->base, _encoder_funcs,
- drm_enc_mode, NULL);
- if (rc) {
- devm_kfree(dev->dev, dpu_enc);
- return ERR_PTR(rc);
- }
-
- drm_encoder_helper_add(_enc->base, _encoder_helper_funcs);
-
- spin_lock_init(_enc->enc_spinlock);
- dpu_enc->enabled = false;
- mutex_init(_enc->enc_lock);
- mutex_init(_enc->rc_lock);
-
- return _enc->base;
+ return ERR_PTR(ret);
}
int dpu_encoder_wait_for_event(struct drm_encoder *drm_enc,
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
index 6d14f84dd43f..90e1925d7770 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
@@ -130,20 +130,12 @@ void dpu_encoder_virt_runtime_resume(struct drm_encoder
*encoder);
/**
* dpu_encoder_init - initialize virtual encoder object
* @dev:Pointer to drm device structure
+ * @drm_enc_mode: corresponding DRM_MODE_ENCODER_* constant
* @disp_info: Pointer to display information structure
* Returns: Pointer to newly created drm encoder
*/
-struct drm_encoder *dpu_encoder_init(
- struct drm_device *dev,
- int drm_enc_mode);
-
-/**
- * dpu_encoder_setup - setup dpu_encoder for the display probed
- * @dev: Pointer to drm device structure
- * @enc: Pointer to the drm_encoder
- * @disp_info: Pointer to the display info
- */
-int dpu_encoder_setup(struct drm_device *dev, struct drm_encoder *enc,
+struct drm_encoder *dpu_encoder_init(struct drm_device *dev,
+ int drm_enc_mode,
struct msm_display_info *disp_info);
/**
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 8ce057cc9374..70a17ef8281f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -535,15 +535,23 @@ static int _dpu_kms_initialize_dsi(struct drm_device *dev,
!msm_dsi_is_master_dsi(priv->dsi[i]))
continue;
- encoder = dpu_encoder_init(dev, DRM_MODE_ENCODER_DSI);
+ memset(, 0, sizeof(info));
+
[PATCH v3 2/7] drm/msm/dpu: separate common function to init physical encoder
Move common DPU physical encoder initialization code to the new function
dpu_encoder_phys_init().
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 29 +--
.../gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 3 ++
.../drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 17 ++-
.../drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 17 ++-
.../drm/msm/disp/dpu1/dpu_encoder_phys_wb.c | 17 ++-
5 files changed, 37 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index d4b759e8f2ae..475b30bef72d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -2321,8 +2321,6 @@ static int dpu_encoder_setup_display(struct
dpu_encoder_virt *dpu_enc,
for (i = 0; i < dpu_enc->num_phys_encs; i++) {
struct dpu_encoder_phys *phys = dpu_enc->phys_encs[i];
- atomic_set(>vsync_cnt, 0);
- atomic_set(>underrun_cnt, 0);
if (phys->intf_idx >= INTF_0 && phys->intf_idx < INTF_MAX)
phys->hw_intf = dpu_rm_get_intf(_kms->rm,
phys->intf_idx);
@@ -2524,3 +2522,30 @@ unsigned int dpu_encoder_helper_get_dsc(struct
dpu_encoder_phys *phys_enc)
return dpu_enc->dsc_mask;
}
+
+void dpu_encoder_phys_init(struct dpu_encoder_phys *phys_enc,
+ struct dpu_enc_phys_init_params *p)
+{
+ int i;
+
+ phys_enc->hw_mdptop = p->dpu_kms->hw_mdp;
+ phys_enc->intf_idx = p->intf_idx;
+ phys_enc->wb_idx = p->wb_idx;
+ phys_enc->parent = p->parent;
+ phys_enc->dpu_kms = p->dpu_kms;
+ phys_enc->split_role = p->split_role;
+ phys_enc->enc_spinlock = p->enc_spinlock;
+ phys_enc->enable_state = DPU_ENC_DISABLED;
+
+ for (i = 0; i < ARRAY_SIZE(phys_enc->irq); i++)
+ phys_enc->irq[i] = -EINVAL;
+
+ atomic_set(_enc->vblank_refcount, 0);
+ atomic_set(_enc->pending_kickoff_cnt, 0);
+ atomic_set(_enc->pending_ctlstart_cnt, 0);
+
+ atomic_set(_enc->vsync_cnt, 0);
+ atomic_set(_enc->underrun_cnt, 0);
+
+ init_waitqueue_head(_enc->pending_kickoff_wq);
+}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
index 90f177e43262..aa98bfb70a26 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
@@ -407,4 +407,7 @@ void dpu_encoder_frame_done_callback(
struct drm_encoder *drm_enc,
struct dpu_encoder_phys *ready_phys, u32 event);
+void dpu_encoder_phys_init(struct dpu_encoder_phys *phys,
+ struct dpu_enc_phys_init_params *p);
+
#endif /* __dpu_encoder_phys_H__ */
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
index d8ed85a238af..2bd806c51882 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
@@ -756,7 +756,7 @@ struct dpu_encoder_phys *dpu_encoder_phys_cmd_init(
{
struct dpu_encoder_phys *phys_enc = NULL;
struct dpu_encoder_phys_cmd *cmd_enc = NULL;
- int i, ret = 0;
+ int ret = 0;
DPU_DEBUG("intf %d\n", p->intf_idx - INTF_0);
@@ -767,28 +767,17 @@ struct dpu_encoder_phys *dpu_encoder_phys_cmd_init(
return ERR_PTR(ret);
}
phys_enc = _enc->base;
- phys_enc->hw_mdptop = p->dpu_kms->hw_mdp;
- phys_enc->intf_idx = p->intf_idx;
+
+ dpu_encoder_phys_init(phys_enc, p);
dpu_encoder_phys_cmd_init_ops(_enc->ops);
- phys_enc->parent = p->parent;
- phys_enc->dpu_kms = p->dpu_kms;
- phys_enc->split_role = p->split_role;
phys_enc->intf_mode = INTF_MODE_CMD;
- phys_enc->enc_spinlock = p->enc_spinlock;
cmd_enc->stream_sel = 0;
- phys_enc->enable_state = DPU_ENC_DISABLED;
- for (i = 0; i < ARRAY_SIZE(phys_enc->irq); i++)
- phys_enc->irq[i] = -EINVAL;
phys_enc->has_intf_te = test_bit(DPU_INTF_TE,
_enc->dpu_kms->catalog->intf[p->intf_idx -
INTF_0].features);
- atomic_set(_enc->vblank_refcount, 0);
- atomic_set(_enc->pending_kickoff_cnt, 0);
- atomic_set(_enc->pending_ctlstart_cnt, 0);
atomic_set(_enc->pending_vblank_cnt, 0);
- init_waitqueue_head(_enc->pending_kickoff_wq);
init_waitqueue_head(_enc->pending_vblank_wq);
DPU_DEBUG_CMDENC(cmd_enc, "created\n");
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
index 3a374292f311..dc951fdf473b 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
@@ -699,7 +699,6 @@ struct
[PATCH v3 0/7] drm/msm/dpu: simplify DPU encoder init
Rework dpu_encoder initialization code, simplifying calling sequences and separating common init parts. Changes since v2: - Rebased on top of msm-next-lumag branch Changes since v1: - Withdrawn two pathes for a later consideration - Changed dpu_encoder_phys_init() to return void (Abhinav) - Added small simplifications of dpu_encoder_phys_cmd_init() and dpu_encoder_phys_wb_init() Dmitry Baryshkov (7): drm/msm/dpu: merge dpu_encoder_init() and dpu_encoder_setup() drm/msm/dpu: separate common function to init physical encoder drm/msm/dpu: drop duplicated intf/wb indices from encoder structs drm/msm/dpu: inline dpu_encoder_get_wb() drm/msm/dpu: call dpu_rm_get_intf() from dpu_encoder_get_intf() drm/msm/dpu: drop temp variable from dpu_encoder_phys_cmd_init() drm/msm/dpu: simplify dpu_encoder_phys_wb_init() drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 178 -- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h | 14 +- .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 15 +- .../drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 37 ++-- .../drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 19 +- .../drm/msm/disp/dpu1/dpu_encoder_phys_wb.c | 35 +--- drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 87 - 7 files changed, 141 insertions(+), 244 deletions(-) -- 2.39.2
Re: [Intel-gfx] [PATCH v8 0/7] drm/i915: use ref_tracker library for tracking wakerefs
On Thu, 1 Jun 2023 19:14:50 +0200 Andrzej Hajda wrote: > Ping on the series, everything reviewed. > Eric, Dave, Jakub, could you take patches 1-4 via net tree? Sure thing, would you mind reposting them separately? Easier for us to apply and it's been over a month since posting, a fresh run of build bots won't hurt either.
[PATCH v4 2/2] drm/mediatek: Add DSI support for mt8188 vdosys0
Add DSI as main display output for mt8188 vdosys0.
Signed-off-by: Nathan Lu
Signed-off-by: Jason-JH.Lin
Reviewed-by: Matthias Brugger
---
drivers/gpu/drm/mediatek/mtk_disp_drv.h | 1 +
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 1 +
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 5 +
drivers/gpu/drm/mediatek/mtk_dsi.c | 9 +
4 files changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
index 5f07037670e9..fdaa21b6a9da 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
+++ b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
@@ -48,6 +48,7 @@ unsigned int mtk_dpi_encoder_index(struct device *dev);
void mtk_dsi_ddp_start(struct device *dev);
void mtk_dsi_ddp_stop(struct device *dev);
+unsigned int mtk_dsi_encoder_index(struct device *dev);
int mtk_gamma_clk_enable(struct device *dev);
void mtk_gamma_clk_disable(struct device *dev);
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index 64298d42c6f5..f3f9172a93b4 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -318,6 +318,7 @@ static const struct mtk_ddp_comp_funcs ddp_dsc = {
static const struct mtk_ddp_comp_funcs ddp_dsi = {
.start = mtk_dsi_ddp_start,
.stop = mtk_dsi_ddp_stop,
+ .encoder_index = mtk_dsi_encoder_index,
};
static const struct mtk_ddp_comp_funcs ddp_gamma = {
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 0412a82c1ed0..eb57f0abcaff 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -191,8 +191,13 @@ static const unsigned int mt8188_mtk_ddp_main_routes_0[] =
{
DDP_COMPONENT_DP_INTF0
};
+static const unsigned int mt8188_mtk_ddp_main_routes_1[] = {
+ DDP_COMPONENT_DSI0
+};
+
static const struct mtk_drm_route mt8188_mtk_ddp_main_routes[] = {
{0, ARRAY_SIZE(mt8188_mtk_ddp_main_routes_0),
mt8188_mtk_ddp_main_routes_0},
+ {0, ARRAY_SIZE(mt8188_mtk_ddp_main_routes_1),
mt8188_mtk_ddp_main_routes_1},
};
static const unsigned int mt8192_mtk_ddp_main[] = {
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 7d5250351193..62d5362916a5 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -865,6 +865,15 @@ static int mtk_dsi_encoder_init(struct drm_device *drm,
struct mtk_dsi *dsi)
return ret;
}
+unsigned int mtk_dsi_encoder_index(struct device *dev)
+{
+ struct mtk_dsi *dsi = dev_get_drvdata(dev);
+ unsigned int encoder_index = drm_encoder_index(>encoder);
+
+ dev_dbg(dev, "encoder index:%d", encoder_index);
+ return encoder_index;
+}
+
static int mtk_dsi_bind(struct device *dev, struct device *master, void *data)
{
int ret;
--
2.18.0
[PATCH v4 0/2] Add dynamic connector selection mechanism
To support DSI and eDP as main display connector without modifying mtk-drm driver, we add the dynamic connector selection mechanism. Change in v4: 1. Change variable naming of connector routes number from conn_route_num to num_conn_routes. 2. Chnage he encoder_index function return valuew from int to unsigned int. Change in v3: 1. Change max_num comparison statement to max(). Change in v2: 1. rebase on linux-next: next-20230426 2. Fix alphabetical order and max_num condition check problem. Change in v1: 1. based on mediatek-drm maintainer's tree / mediatek-drm-next branch: https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next Jason-JH.Lin (2): drm/mediatek: Add ability to support dynamic connector selection drm/mediatek: Add DSI support for mt8188 vdosys0 drivers/gpu/drm/mediatek/mtk_disp_drv.h | 2 + drivers/gpu/drm/mediatek/mtk_dpi.c | 9 ++ drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 111 +++- drivers/gpu/drm/mediatek/mtk_drm_crtc.h | 5 +- drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 28 + drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 8 ++ drivers/gpu/drm/mediatek/mtk_drm_drv.c | 49 +++-- drivers/gpu/drm/mediatek/mtk_drm_drv.h | 8 ++ drivers/gpu/drm/mediatek/mtk_dsi.c | 9 ++ 9 files changed, 218 insertions(+), 11 deletions(-) -- 2.18.0
[PATCH v4 1/2] drm/mediatek: Add ability to support dynamic connector selection
1. Move output drm connector from each ddp_path array to connector array.
2. Add dynamic select available connector flow in crtc create and enable.
Signed-off-by: Nancy Lin
Signed-off-by: Nathan Lu
Signed-off-by: Jason-JH.Lin
---
drivers/gpu/drm/mediatek/mtk_disp_drv.h | 1 +
drivers/gpu/drm/mediatek/mtk_dpi.c | 9 ++
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 111 +++-
drivers/gpu/drm/mediatek/mtk_drm_crtc.h | 5 +-
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 27 +
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 8 ++
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 44 ++--
drivers/gpu/drm/mediatek/mtk_drm_drv.h | 8 ++
8 files changed, 202 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
index 2254038519e1..5f07037670e9 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
+++ b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
@@ -44,6 +44,7 @@ void mtk_dither_set_common(void __iomem *regs, struct
cmdq_client_reg *cmdq_reg,
void mtk_dpi_start(struct device *dev);
void mtk_dpi_stop(struct device *dev);
+unsigned int mtk_dpi_encoder_index(struct device *dev);
void mtk_dsi_ddp_start(struct device *dev);
void mtk_dsi_ddp_stop(struct device *dev);
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index 948a53f1f4b3..e58783a9d92c 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -782,6 +782,15 @@ void mtk_dpi_stop(struct device *dev)
mtk_dpi_power_off(dpi);
}
+unsigned int mtk_dpi_encoder_index(struct device *dev)
+{
+ struct mtk_dpi *dpi = dev_get_drvdata(dev);
+ unsigned int encoder_index = drm_encoder_index(>encoder);
+
+ dev_dbg(dev, "encoder index:%d", encoder_index);
+ return encoder_index;
+}
+
static int mtk_dpi_bind(struct device *dev, struct device *master, void *data)
{
struct mtk_dpi *dpi = dev_get_drvdata(dev);
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index d40142842f85..8c5730f526e2 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -60,8 +60,12 @@ struct mtk_drm_crtc {
struct device *mmsys_dev;
struct device *dma_dev;
struct mtk_mutex*mutex;
+ unsigned intddp_comp_nr_ori;
+ unsigned intmax_ddp_comp_nr;
unsigned intddp_comp_nr;
struct mtk_ddp_comp **ddp_comp;
+ unsigned intnum_conn_routes;
+ const struct mtk_drm_route *conn_routes;
/* lock for display hardware access */
struct mutexhw_lock;
@@ -649,6 +653,84 @@ static void mtk_drm_crtc_disable_vblank(struct drm_crtc
*crtc)
mtk_ddp_comp_disable_vblank(comp);
}
+static unsigned int mtk_drm_crtc_max_num_route_comp(struct mtk_drm_crtc
*mtk_crtc)
+{
+ unsigned int max_routes = 0;
+ unsigned int i;
+
+ if (!mtk_crtc->num_conn_routes)
+ return 0;
+
+ for (i = 0; i < mtk_crtc->num_conn_routes; i++)
+ max_routes = max(mtk_crtc->conn_routes[i].route_len,
max_routes);
+
+ return max_routes;
+}
+
+static int mtk_drm_crtc_update_output(struct drm_crtc *crtc,
+ struct drm_atomic_state *state)
+{
+ const struct mtk_drm_route *conn_routes;
+ int crtc_index = drm_crtc_index(crtc);
+ int i;
+ struct device *dev;
+ struct drm_crtc_state *crtc_state = state->crtcs[crtc_index].new_state;
+ struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
+ struct mtk_drm_private *priv = crtc->dev->dev_private;
+ unsigned int comp_id;
+ unsigned int encoder_mask = crtc_state->encoder_mask;
+ unsigned int route_len = 0, route_index = 0;
+
+ if (!mtk_crtc->num_conn_routes)
+ return 0;
+
+ priv = priv->all_drm_private[crtc_index];
+ dev = priv->dev;
+
+ dev_dbg(dev, "connector change:%d, encoder mask0x%x for crtc%d",
+ crtc_state->connectors_changed, encoder_mask, crtc_index);
+
+ if (!crtc_state->connectors_changed)
+ return 0;
+
+ conn_routes = mtk_crtc->conn_routes;
+
+ for (i = 0; i < mtk_crtc->num_conn_routes; i++) {
+ route_len = conn_routes[i].route_len;
+ if (route_len) {
+ comp_id = conn_routes[i].route_ddp[route_len - 1];
+ if (priv->comp_node[comp_id]) {
+ if (encoder_mask &
BIT(priv->ddp_comp[comp_id].encoder_index)) {
+ route_index = i;
+ break;
+ }
+ }
+ }
+ }
+
+
Re: [Intel-gfx] [PATCH v8 0/7] drm/i915: use ref_tracker library for tracking wakerefs
On 08.05.2023 19:16, Andrzej Hajda wrote: On 05.05.2023 22:06, Rodrigo Vivi wrote: On Thu, May 04, 2023 at 06:27:53PM +0200, Andrzej Hajda wrote: Hi maintainers of net and i915, On 25.04.2023 00:05, Andrzej Hajda wrote: This is revived patchset improving ref_tracker library and converting i915 internal tracker to ref_tracker. The old thread ended without consensus about small kernel allocations, which are performed under spinlock. I have tried to solve the problem by splitting the calls, but it results in complicated API, so I went back to original solution. If there are better solutions I am glad to discuss them. Meanwhile I send original patchset with addressed remaining comments. Ping on the series, everything reviewed. Eric, Dave, Jakub, could you take patches 1-4 via net tree? Regards Andrzej To: Jani Nikula To: Joonas Lahtinen To: Rodrigo Vivi To: Tvrtko Ursulin To: David Airlie To: Daniel Vetter To: Eric Dumazet Cc: linux-ker...@vger.kernel.org Cc: intel-...@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Cc: Chris Wilson Cc: net...@vger.kernel.org Cc: Jakub Kicinski Cc: Dmitry Vyukov Cc: "David S. Miller" Cc: Andi Shyti Cc: Das, Nirmoy Signed-off-by: Andrzej Hajda --- Changes in v8: - addressed comments from Eric, Zhou and CI, thanks, - added ref_tracker_dir_init name argument to all callers in one patch - moved intel_wakeref_tracker_show to *.c - s/intel_wakeref_tracker_show/intel_ref_tracker_show/ - removed 'default n' from Kconfig - changed strlcpy to strscpy, - removed assignement from if condition, - removed long lines from patch description - added tags - Link to v7: https://lore.kernel.org/r/20230224-track_gt-v7-0-11f08358c...@intel.com Changes in v7: - removed 8th patch (hold wakeref), as it was already merged - added tags (thx Andi) - Link to v6: https://lore.kernel.org/r/20230224-track_gt-v6-0-0dc8601fd...@intel.com Changes in v6: - rebased to solve minor conflict and allow CI testing - Link to v5: https://lore.kernel.org/r/20230224-track_gt-v5-0-77be86f2c...@intel.com Changes in v5 (thx Andi for review): - use *_locked convention instead of __*, - improved commit messages, - re-worked i915 patches, squashed separation and conversion patches, - added tags, - Link to v4: https://lore.kernel.org/r/20230224-track_gt-v4-0-464e8ab4c...@intel.com Changes in v4: - split "Separate wakeref tracking" to smaller parts - fixed typos, - Link to v1-v3: https://patchwork.freedesktop.org/series/100327/ --- Andrzej Hajda (7): lib/ref_tracker: add unlocked leak print helper lib/ref_tracker: improve printing stats lib/ref_tracker: add printing to memory buffer lib/ref_tracker: remove warnings in case of allocation failure drm/i915: Correct type of wakeref variable drm/i915: Replace custom intel runtime_pm tracker with ref_tracker library drm/i915: Track gt pm wakerefs Finally all patches are reviewed. Question to network and i915 maintainers, how to merge this patchset: 1. Patches 1-4 belongs rather to network domain (especially patch 2). 2. Patches 5-7 are for i915. Well, probably the easiest way to avoid conflicts would be to send this right now through the net repo. And hold patches 5-7 after drm-intel-next can backmerge them. At this point I believe we would be looking at 6.5-rc2 backmerge to drm-intel-next in likely 11 weeks from now. Do we have any urgency on them? Looking to all the changes in i915 I believe we will get many conflicts if we let all these i915 patches go through net tree as well. Eric, Dave, Jakub, could you take patches 1-4? Regards Andrzej What would be the best way to do it? Regards Andrzej drivers/gpu/drm/i915/Kconfig.debug | 18 ++ drivers/gpu/drm/i915/display/intel_display_power.c | 2 +- drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 7 +- .../drm/i915/gem/selftests/i915_gem_coherency.c | 10 +- drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c | 14 +- drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 13 +- drivers/gpu/drm/i915/gt/intel_breadcrumbs_types.h | 3 +- drivers/gpu/drm/i915/gt/intel_context.h | 4 +- drivers/gpu/drm/i915/gt/intel_context_types.h | 2 + drivers/gpu/drm/i915/gt/intel_engine_pm.c | 7 +- drivers/gpu/drm/i915/gt/intel_engine_types.h | 2 + .../gpu/drm/i915/gt/intel_execlists_submission.c | 2 +- drivers/gpu/drm/i915/gt/intel_gt_pm.c | 12 +- drivers/gpu/drm/i915/gt/intel_gt_pm.h | 38 +++- drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c | 4 +- drivers/gpu/drm/i915/gt/selftest_engine_cs.c | 20 +- drivers/gpu/drm/i915/gt/selftest_gt_pm.c | 5 +- drivers/gpu/drm/i915/gt/selftest_reset.c | 10 +- drivers/gpu/drm/i915/gt/selftest_rps.c | 17 +- drivers/gpu/drm/i915/gt/selftest_slpc.c | 5 +-
[PATCH v3 7/7] ARM: dts: qcom: msm8226: Add mdss nodes
Add the nodes that describe the mdss so that display can work on
MSM8226.
Signed-off-by: Luca Weiss
---
arch/arm/boot/dts/qcom-msm8226.dtsi | 127
1 file changed, 127 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-msm8226.dtsi
b/arch/arm/boot/dts/qcom-msm8226.dtsi
index 42acb9ddb8cc..9f53747d2990 100644
--- a/arch/arm/boot/dts/qcom-msm8226.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8226.dtsi
@@ -636,6 +636,133 @@ smd-edge {
label = "lpass";
};
};
+
+ mdss: display-subsystem@fd90 {
+ compatible = "qcom,mdss";
+ reg = <0xfd90 0x100>, <0xfd924000 0x1000>;
+ reg-names = "mdss_phys", "vbif_phys";
+
+ power-domains = < MDSS_GDSC>;
+
+ clocks = < MDSS_AHB_CLK>,
+< MDSS_AXI_CLK>,
+< MDSS_VSYNC_CLK>;
+ clock-names = "iface",
+ "bus",
+ "vsync";
+
+ interrupts = ;
+
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ status = "disabled";
+
+ mdss_mdp: display-controller@fd90 {
+ compatible = "qcom,msm8226-mdp5", "qcom,mdp5";
+ reg = <0xfd900100 0x22000>;
+ reg-names = "mdp_phys";
+
+ interrupt-parent = <>;
+ interrupts = <0>;
+
+ clocks = < MDSS_AHB_CLK>,
+< MDSS_AXI_CLK>,
+< MDSS_MDP_CLK>,
+< MDSS_VSYNC_CLK>;
+ clock-names = "iface",
+ "bus",
+ "core",
+ "vsync";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ mdss_mdp_intf1_out: endpoint {
+ remote-endpoint =
<_dsi0_in>;
+ };
+ };
+ };
+ };
+
+ mdss_dsi0: dsi@fd922800 {
+ compatible = "qcom,msm8226-dsi-ctrl",
+"qcom,mdss-dsi-ctrl";
+ reg = <0xfd922800 0x1f8>;
+ reg-names = "dsi_ctrl";
+
+ interrupt-parent = <>;
+ interrupts = <4>;
+
+ assigned-clocks = < BYTE0_CLK_SRC>,
+ < PCLK0_CLK_SRC>;
+ assigned-clock-parents = <_dsi0_phy 0>,
+<_dsi0_phy 1>;
+
+ clocks = < MDSS_MDP_CLK>,
+< MDSS_AHB_CLK>,
+< MDSS_AXI_CLK>,
+< MDSS_BYTE0_CLK>,
+< MDSS_PCLK0_CLK>,
+< MDSS_ESC0_CLK>,
+< MMSS_MISC_AHB_CLK>;
+ clock-names = "mdp_core",
+ "iface",
+ "bus",
+ "byte",
+ "pixel",
+ "core",
+ "core_mmss";
+
+ phys = <_dsi0_phy>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ mdss_dsi0_in: endpoint {
+ remote-endpoint =
<_mdp_intf1_out>;
+
[PATCH v3 0/7] Display support for MSM8226
This series adds the required configs for MDP5 and DSI blocks that are needed for MDSS on MSM8226. Finally we can add the new nodes into the dts. Tested on apq8026-lg-lenok and msm8926-htc-memul. Signed-off-by: Luca Weiss --- Changes in v3: - Adjust mdss labels to new style (Stephan) - Link to v2: https://lore.kernel.org/r/20230308-msm8226-mdp-v2-0-e005b769e...@z3ntu.xyz Changes in v2: - In dsi-phy-28nm.yaml fix the order of the compatibles 1/7 (Conor) - Remove leftover debugging comments from 6/7 (Konrad) - Rewrap some clock-names lines and move status property last in 7/7 (Konrad) - Pick up tags - Link to v1: https://lore.kernel.org/r/20230308-msm8226-mdp-v1-0-679f335d3...@z3ntu.xyz --- Luca Weiss (7): dt-bindings: msm: dsi-phy-28nm: Document msm8226 compatible dt-bindings: display/msm: dsi-controller-main: Add msm8226 compatible dt-bindings: display/msm: qcom,mdp5: Add msm8226 compatible drm/msm/mdp5: Add MDP5 configuration for MSM8226 drm/msm/dsi: Add configuration for MSM8226 drm/msm/dsi: Add phy configuration for MSM8226 ARM: dts: qcom: msm8226: Add mdss nodes .../bindings/display/msm/dsi-controller-main.yaml | 2 + .../bindings/display/msm/dsi-phy-28nm.yaml | 3 +- .../devicetree/bindings/display/msm/qcom,mdp5.yaml | 1 + .../devicetree/bindings/display/msm/qcom,mdss.yaml | 1 + arch/arm/boot/dts/qcom-msm8226.dtsi| 127 + drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c | 82 + drivers/gpu/drm/msm/dsi/dsi_cfg.c | 2 + drivers/gpu/drm/msm/dsi/dsi_cfg.h | 1 + drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 2 + drivers/gpu/drm/msm/dsi/phy/dsi_phy.h | 3 +- drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c | 97 11 files changed, 319 insertions(+), 2 deletions(-) --- base-commit: 1b3183710d69a48baf728cc1bee9f1fb3cfeb507 change-id: 20230308-msm8226-mdp-6431e8d672a0 Best regards, -- Luca Weiss
[PATCH v3 1/7] dt-bindings: msm: dsi-phy-28nm: Document msm8226 compatible
The MSM8226 SoC uses a slightly different 28nm dsi phy. Add a new compatible for it. And while we're at it, in the dsi-phy-28nm.yaml move the 8960 compatible to its correct place so its sorted alphabetically. Acked-by: Conor Dooley Signed-off-by: Luca Weiss --- Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml | 3 ++- Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml| 1 + 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml b/Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml index cf4a338c4661..62fb3e484eb2 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml +++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml @@ -15,10 +15,11 @@ allOf: properties: compatible: enum: + - qcom,dsi-phy-28nm-8226 + - qcom,dsi-phy-28nm-8960 - qcom,dsi-phy-28nm-hpm - qcom,dsi-phy-28nm-hpm-fam-b - qcom,dsi-phy-28nm-lp - - qcom,dsi-phy-28nm-8960 reg: items: diff --git a/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml index b0100105e428..db9f07c6142d 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml @@ -125,6 +125,7 @@ patternProperties: - qcom,dsi-phy-14nm-660 - qcom,dsi-phy-14nm-8953 - qcom,dsi-phy-20nm + - qcom,dsi-phy-28nm-8226 - qcom,dsi-phy-28nm-hpm - qcom,dsi-phy-28nm-lp - qcom,hdmi-phy-8084 -- 2.40.1
[PATCH v3 4/7] drm/msm/mdp5: Add MDP5 configuration for MSM8226
Add the required config for the v1.1 MDP5 found on MSM8226.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Luca Weiss
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c | 82
1 file changed, 82 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
index 2eec2d78f32a..694d54341337 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
@@ -103,6 +103,87 @@ static const struct mdp5_cfg_hw msm8x74v1_config = {
.max_clk = 2,
};
+static const struct mdp5_cfg_hw msm8x26_config = {
+ .name = "msm8x26",
+ .mdp = {
+ .count = 1,
+ .caps = MDP_CAP_SMP |
+ 0,
+ },
+ .smp = {
+ .mmb_count = 7,
+ .mmb_size = 4096,
+ .clients = {
+ [SSPP_VIG0] = 1,
+ [SSPP_DMA0] = 4,
+ [SSPP_RGB0] = 7,
+ },
+ },
+ .ctl = {
+ .count = 2,
+ .base = { 0x00500, 0x00600 },
+ .flush_hw_mask = 0x0003,
+ },
+ .pipe_vig = {
+ .count = 1,
+ .base = { 0x01100 },
+ .caps = MDP_PIPE_CAP_HFLIP |
+ MDP_PIPE_CAP_VFLIP |
+ MDP_PIPE_CAP_SCALE |
+ MDP_PIPE_CAP_CSC |
+ 0,
+ },
+ .pipe_rgb = {
+ .count = 1,
+ .base = { 0x01d00 },
+ .caps = MDP_PIPE_CAP_HFLIP |
+ MDP_PIPE_CAP_VFLIP |
+ MDP_PIPE_CAP_SCALE |
+ 0,
+ },
+ .pipe_dma = {
+ .count = 1,
+ .base = { 0x02900 },
+ .caps = MDP_PIPE_CAP_HFLIP |
+ MDP_PIPE_CAP_VFLIP |
+ 0,
+ },
+ .lm = {
+ .count = 2,
+ .base = { 0x03100, 0x03d00 },
+ .instances = {
+ { .id = 0, .pp = 0, .dspp = 0,
+ .caps = MDP_LM_CAP_DISPLAY, },
+ { .id = 1, .pp = -1, .dspp = -1,
+ .caps = MDP_LM_CAP_WB },
+},
+ .nb_stages = 2,
+ .max_width = 2048,
+ .max_height = 0x,
+ },
+ .dspp = {
+ .count = 1,
+ .base = { 0x04500 },
+ },
+ .pp = {
+ .count = 1,
+ .base = { 0x21a00 },
+ },
+ .intf = {
+ .base = { 0x0, 0x21200 },
+ .connect = {
+ [0] = INTF_DISABLED,
+ [1] = INTF_DSI,
+ },
+ },
+ .perf = {
+ .ab_inefficiency = 100,
+ .ib_inefficiency = 200,
+ .clk_inefficiency = 125
+ },
+ .max_clk = 2,
+};
+
static const struct mdp5_cfg_hw msm8x74v2_config = {
.name = "msm8x74",
.mdp = {
@@ -1236,6 +1317,7 @@ static const struct mdp5_cfg_hw sdm660_config = {
static const struct mdp5_cfg_handler cfg_handlers_v1[] = {
{ .revision = 0, .config = { .hw = _config } },
+ { .revision = 1, .config = { .hw = _config } },
{ .revision = 2, .config = { .hw = _config } },
{ .revision = 3, .config = { .hw = _config } },
{ .revision = 6, .config = { .hw = _config } },
--
2.40.1
[PATCH v3 6/7] drm/msm/dsi: Add phy configuration for MSM8226
MSM8226 uses a modified PLL lock sequence compared to MSM8974, which is
based on the function dsi_pll_enable_seq_m in the msm-3.10 kernel.
Worth noting that the msm-3.10 downstream kernel also will try other
sequences in case this one doesn't work, but during testing it has shown
that the _m sequence succeeds first time also:
.pll_enable_seqs[0] = dsi_pll_enable_seq_m,
.pll_enable_seqs[1] = dsi_pll_enable_seq_m,
.pll_enable_seqs[2] = dsi_pll_enable_seq_d,
.pll_enable_seqs[3] = dsi_pll_enable_seq_d,
.pll_enable_seqs[4] = dsi_pll_enable_seq_f1,
.pll_enable_seqs[5] = dsi_pll_enable_seq_c,
.pll_enable_seqs[6] = dsi_pll_enable_seq_e,
We may need to expand this in the future.
Signed-off-by: Luca Weiss
---
drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 2 +
drivers/gpu/drm/msm/dsi/phy/dsi_phy.h | 3 +-
drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c | 97 ++
3 files changed, 101 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
index bb09cbe8ff86..9d5795c58a98 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
@@ -541,6 +541,8 @@ static const struct of_device_id dsi_phy_dt_match[] = {
.data = _phy_28nm_hpm_famb_cfgs },
{ .compatible = "qcom,dsi-phy-28nm-lp",
.data = _phy_28nm_lp_cfgs },
+ { .compatible = "qcom,dsi-phy-28nm-8226",
+ .data = _phy_28nm_8226_cfgs },
#endif
#ifdef CONFIG_DRM_MSM_DSI_20NM_PHY
{ .compatible = "qcom,dsi-phy-20nm",
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
index 7137a17ae523..8b640d174785 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
@@ -46,8 +46,9 @@ struct msm_dsi_phy_cfg {
extern const struct msm_dsi_phy_cfg dsi_phy_28nm_hpm_cfgs;
extern const struct msm_dsi_phy_cfg dsi_phy_28nm_hpm_famb_cfgs;
extern const struct msm_dsi_phy_cfg dsi_phy_28nm_lp_cfgs;
-extern const struct msm_dsi_phy_cfg dsi_phy_20nm_cfgs;
+extern const struct msm_dsi_phy_cfg dsi_phy_28nm_8226_cfgs;
extern const struct msm_dsi_phy_cfg dsi_phy_28nm_8960_cfgs;
+extern const struct msm_dsi_phy_cfg dsi_phy_20nm_cfgs;
extern const struct msm_dsi_phy_cfg dsi_phy_14nm_cfgs;
extern const struct msm_dsi_phy_cfg dsi_phy_14nm_660_cfgs;
extern const struct msm_dsi_phy_cfg dsi_phy_14nm_2290_cfgs;
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c
index 4c1bf55c5f38..ceec7bb87bf1 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c
@@ -37,6 +37,7 @@
/* v2.0.0 28nm LP implementation */
#define DSI_PHY_28NM_QUIRK_PHY_LP BIT(0)
+#define DSI_PHY_28NM_QUIRK_PHY_8226BIT(1)
#define LPFR_LUT_SIZE 10
struct lpfr_cfg {
@@ -377,6 +378,74 @@ static int dsi_pll_28nm_vco_prepare_hpm(struct clk_hw *hw)
return ret;
}
+static int dsi_pll_28nm_vco_prepare_8226(struct clk_hw *hw)
+{
+ struct dsi_pll_28nm *pll_28nm = to_pll_28nm(hw);
+ struct device *dev = _28nm->phy->pdev->dev;
+ void __iomem *base = pll_28nm->phy->pll_base;
+ u32 max_reads = 5, timeout_us = 100;
+ bool locked;
+ u32 val;
+ int i;
+
+ DBG("id=%d", pll_28nm->phy->id);
+
+ pll_28nm_software_reset(pll_28nm);
+
+ /*
+* PLL power up sequence.
+* Add necessary delays recommended by hardware.
+*/
+ dsi_phy_write(base + REG_DSI_28nm_PHY_PLL_CAL_CFG1, 0x34);
+
+ val = DSI_28nm_PHY_PLL_GLB_CFG_PLL_PWRDN_B;
+ dsi_phy_write_udelay(base + REG_DSI_28nm_PHY_PLL_GLB_CFG, val, 200);
+
+ val |= DSI_28nm_PHY_PLL_GLB_CFG_PLL_PWRGEN_PWRDN_B;
+ dsi_phy_write_udelay(base + REG_DSI_28nm_PHY_PLL_GLB_CFG, val, 200);
+
+ val |= DSI_28nm_PHY_PLL_GLB_CFG_PLL_LDO_PWRDN_B;
+ val |= DSI_28nm_PHY_PLL_GLB_CFG_PLL_ENABLE;
+ dsi_phy_write_udelay(base + REG_DSI_28nm_PHY_PLL_GLB_CFG, val, 600);
+
+ for (i = 0; i < 7; i++) {
+ /* DSI Uniphy lock detect setting */
+ dsi_phy_write(base + REG_DSI_28nm_PHY_PLL_LKDET_CFG2, 0x0d);
+ dsi_phy_write_udelay(base + REG_DSI_28nm_PHY_PLL_LKDET_CFG2,
+ 0x0c, 100);
+ dsi_phy_write(base + REG_DSI_28nm_PHY_PLL_LKDET_CFG2, 0x0d);
+
+ /* poll for PLL ready status */
+ locked = pll_28nm_poll_for_ready(pll_28nm,
+ max_reads, timeout_us);
+ if (locked)
+ break;
+
+ pll_28nm_software_reset(pll_28nm);
+
+ /*
+* PLL power up sequence.
+* Add necessary delays recommended by hardware.
+*/
+ dsi_phy_write_udelay(base + REG_DSI_28nm_PHY_PLL_PWRGEN_CFG,
0x00, 50);
+
+ val = DSI_28nm_PHY_PLL_GLB_CFG_PLL_PWRDN_B;
[PATCH v3 5/7] drm/msm/dsi: Add configuration for MSM8226
Add the config for the v1.0.2 DSI found on MSM8226. We can reuse
existing bits from other revisions that are identical for v1.0.2.
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Konrad Dybcio
Signed-off-by: Luca Weiss
---
drivers/gpu/drm/msm/dsi/dsi_cfg.c | 2 ++
drivers/gpu/drm/msm/dsi/dsi_cfg.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_cfg.c
b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
index 29ccd755cc2e..8a5fb6df7210 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_cfg.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
@@ -245,6 +245,8 @@ static const struct msm_dsi_cfg_handler dsi_cfg_handlers[]
= {
_dsi_cfg, _dsi_v2_host_ops},
{MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_0,
_apq8084_dsi_cfg, _dsi_6g_host_ops},
+ {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_0_2,
+ _apq8084_dsi_cfg, _dsi_6g_host_ops},
{MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_1,
_apq8084_dsi_cfg, _dsi_6g_host_ops},
{MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_1_1,
diff --git a/drivers/gpu/drm/msm/dsi/dsi_cfg.h
b/drivers/gpu/drm/msm/dsi/dsi_cfg.h
index 91bdaf50bb1a..43f0dd74edb6 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_cfg.h
+++ b/drivers/gpu/drm/msm/dsi/dsi_cfg.h
@@ -11,6 +11,7 @@
#define MSM_DSI_VER_MAJOR_V2 0x02
#define MSM_DSI_VER_MAJOR_6G 0x03
#define MSM_DSI_6G_VER_MINOR_V1_0 0x1000
+#define MSM_DSI_6G_VER_MINOR_V1_0_20x1002
#define MSM_DSI_6G_VER_MINOR_V1_1 0x1001
#define MSM_DSI_6G_VER_MINOR_V1_1_10x10010001
#define MSM_DSI_6G_VER_MINOR_V1_2 0x1002
--
2.40.1
[PATCH v3 2/7] dt-bindings: display/msm: dsi-controller-main: Add msm8226 compatible
Add the compatible for the DSI found on MSM8226. Acked-by: Conor Dooley Signed-off-by: Luca Weiss --- Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml index 130e16d025bc..660e0f496826 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml +++ b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml @@ -15,6 +15,7 @@ properties: - items: - enum: - qcom,apq8064-dsi-ctrl + - qcom,msm8226-dsi-ctrl - qcom,msm8916-dsi-ctrl - qcom,msm8953-dsi-ctrl - qcom,msm8974-dsi-ctrl @@ -256,6 +257,7 @@ allOf: compatible: contains: enum: + - qcom,msm8226-dsi-ctrl - qcom,msm8974-dsi-ctrl then: properties: -- 2.40.1
[PATCH v3 3/7] dt-bindings: display/msm: qcom,mdp5: Add msm8226 compatible
Add the compatible for the MDP5 found on MSM8226. Acked-by: Conor Dooley Signed-off-by: Luca Weiss --- Documentation/devicetree/bindings/display/msm/qcom,mdp5.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/msm/qcom,mdp5.yaml b/Documentation/devicetree/bindings/display/msm/qcom,mdp5.yaml index a763cf8da122..2fe032d0e8f8 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,mdp5.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,mdp5.yaml @@ -22,6 +22,7 @@ properties: - items: - enum: - qcom,apq8084-mdp5 + - qcom,msm8226-mdp5 - qcom,msm8916-mdp5 - qcom,msm8917-mdp5 - qcom,msm8953-mdp5 -- 2.40.1
Re: [PATCH v2] drm/msm/dpu: clean up dpu_kms_get_clk_rate() returns
On 5/26/2023 4:51 AM, Dan Carpenter wrote:
Static analysis tools complain about the -EINVAL error code being
stored in an unsigned variable. Let's change this to match
the clk_get_rate() function which is type unsigned long and returns
zero on error.
Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
Signed-off-by: Dan Carpenter
---
v2: In v1 I change the type to int which was wrong. This is a different
approach. CC the freedreno list this time too.
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 4 ++--
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 0e7a68714e9e..25e6a15eaf9f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -979,13 +979,13 @@ static int _dpu_kms_mmu_init(struct dpu_kms *dpu_kms)
return 0;
}
-u64 dpu_kms_get_clk_rate(struct dpu_kms *dpu_kms, char *clock_name)
+unsigned long dpu_kms_get_clk_rate(struct dpu_kms *dpu_kms, char *clock_name)
{
struct clk *clk;
clk = msm_clk_bulk_get_clock(dpu_kms->clocks, dpu_kms->num_clocks, clock_name);
if (!clk)
- return -EINVAL;
+ return 0;
Currently, the only caller of this API is
dpu_encoder_phys_cmd_tearcheck_config which seems to handle <=0 so this
change should be fine. Hence
Reviewed-by: Abhinav Kumar
Re: [Freedreno] [PATCH] drm/msm: Remove unnecessary (void*) conversions
On 5/21/2023 6:32 PM, Su Hui wrote: Pointer variables of (void*) type do not require type cast. Signed-off-by: Su Hui --- Reviewed-by: Abhinav Kumar
Re: [PATCH v5 11/13] drm/msm: Use regular fbdev I/O helpers
On 5/30/2023 8:02 AM, Thomas Zimmermann wrote: Use the regular fbdev helpers for framebuffer I/O instead of DRM's helpers. Msm does not use damage handling, so DRM's fbdev helpers are mere wrappers around the fbdev code. By using fbdev helpers directly within each DRM fbdev emulation, we can eventually remove DRM's wrapper functions entirely. Msm's fbdev emulation has been incomplete as it didn't implement damage handling. Partilly fix this by implementing damage handling for write and draw operation. It is still missing for mmaped pages. v4: * use initializer macros for struct fb_ops * partially support damage handling v2: * use FB_SYS_HELPERS option Signed-off-by: Thomas Zimmermann Reviewed-by: Dmitry Baryshkov Acked-by: Sam Ravnborg Cc: Rob Clark Cc: Abhinav Kumar Cc: Dmitry Baryshkov Cc: Sean Paul --- Reviewed-by: Abhinav Kumar
Re: [PATCH] gpu: drm/panel: Optimize the workflow of s6d7aa0_lock
Hi Lu,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on next-20230601]
[cannot apply to linus/master v6.4-rc4]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Lu-Hongfei/gpu-drm-panel-Optimize-the-workflow-of-s6d7aa0_lock/20230531-190848
base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link:
https://lore.kernel.org/r/20230531110717.36896-1-luhongfei%40vivo.com
patch subject: [PATCH] gpu: drm/panel: Optimize the workflow of s6d7aa0_lock
config: x86_64-allyesconfig
(https://download.01.org/0day-ci/archive/20230601/202306012354.obljxas6-...@intel.com/config)
compiler: gcc-12 (Debian 12.2.0-14) 12.2.0
reproduce (this is a W=1 build):
#
https://github.com/intel-lab-lkp/linux/commit/e1ade7d20fb0efb9aa0b332d5ac5da2863f8e68e
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review
Lu-Hongfei/gpu-drm-panel-Optimize-the-workflow-of-s6d7aa0_lock/20230531-190848
git checkout e1ade7d20fb0efb9aa0b332d5ac5da2863f8e68e
# save the config file
mkdir build_dir && cp config build_dir/.config
make W=1 O=build_dir ARCH=x86_64 olddefconfig
make W=1 O=build_dir ARCH=x86_64 SHELL=/bin/bash drivers/gpu/drm/panel/
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot
| Closes:
https://lore.kernel.org/oe-kbuild-all/202306012354.obljxas6-...@intel.com/
All warnings (new ones prefixed by >>):
In file included from drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c:17:
drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c: In function 's6d7aa0_lock':
include/drm/drm_mipi_dsi.h:326:9: error: expected expression before 'do'
326 | do {
\
| ^~
drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c:72:23: note: in expansion of
macro 'mipi_dsi_dcs_write_seq'
72 | ret = mipi_dsi_dcs_write_seq(dsi, MCS_PASSWD1, 0xa5,
0xa5);
| ^~
include/drm/drm_mipi_dsi.h:326:9: error: expected expression before 'do'
326 | do {
\
| ^~
drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c:75:23: note: in expansion of
macro 'mipi_dsi_dcs_write_seq'
75 | ret = mipi_dsi_dcs_write_seq(dsi, MCS_PASSWD2, 0xa5,
0xa5);
| ^~
include/drm/drm_mipi_dsi.h:326:9: error: expected expression before 'do'
326 | do {
\
| ^~
drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c:79:31: note: in expansion of
macro 'mipi_dsi_dcs_write_seq'
79 | ret = mipi_dsi_dcs_write_seq(dsi,
MCS_PASSWD3, 0x5a, 0x5a);
| ^~
include/drm/drm_mipi_dsi.h:326:9: error: expected expression before 'do'
326 | do {
\
| ^~
drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c:84:23: note: in expansion of
macro 'mipi_dsi_dcs_write_seq'
84 | ret = mipi_dsi_dcs_write_seq(dsi, MCS_PASSWD1, 0x5a,
0x5a);
| ^~
include/drm/drm_mipi_dsi.h:326:9: error: expected expression before 'do'
326 | do {
\
| ^~
drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c:87:23: note: in expansion of
macro 'mipi_dsi_dcs_write_seq'
87 | ret = mipi_dsi_dcs_write_seq(dsi, MCS_PASSWD2, 0x5a,
0x5a);
| ^~
include/drm/drm_mipi_dsi.h:326:9: error: expected expression before 'do'
326 | do {
\
| ^~
drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c:91:31: note: in expansion of
macro 'mipi_dsi_dcs_write_seq'
91 | ret = mipi_dsi_dcs_write_seq(dsi,
MCS_PASSWD3, 0xa5, 0xa5);
| ^~
>> drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c:68:33: warning: unused
>> variable 'dsi' [-Wunused-variable]
68 | struct mipi_dsi_device *dsi = ctx->dsi;
| ^~~
vim +/dsi +68 drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c
6810bb390282bb Artur Weber 2023-05-19 65
6810bb390282bb Artur Weber 2023-05-19
Re: DRM debugfs cleanup take 4
On Wed, Apr 12, 2023 at 5:52 PM Christian König wrote: > > Hi guys, > > took me some tries to get the Intel CI happy with this patch set. > > This is the version rebased on drm-misc-next, for a CI run you actually > need to rebase the last patch to drm-tip. So I'm planning to merge 1-4 > for this cycle and the last one after everything merged together again. > > Please review, > Christian. > > Hi Christian, Are we on track with this plan ? I think I didn't see the patches getting merged yet, but perhaps I'm wrong. We are actually waiting for them to do the move in habanalabs to /dev/accel nodes, so it will really be helpful if you can merge them at your earliest convenience. Thanks, Oded
[PATCH] drm/i915/pxp/mtl: intel_pxp_init_hw needs runtime-pm inside pm-complete
In the case of failed suspend flow or cases where the kernel does not go
into full suspend but goes from suspend_prepare back to resume_complete,
we get called for a pm_complete but without runtime_pm guaranteed.
Thus, ensure we take the runtime_pm when calling intel_pxp_init_hw
from within intel_pxp_resume_complete.
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/pxp/intel_pxp_pm.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
index 1a04067f61fc..1d184dcd63c7 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
@@ -36,6 +36,8 @@ void intel_pxp_suspend(struct intel_pxp *pxp)
void intel_pxp_resume_complete(struct intel_pxp *pxp)
{
+ intel_wakeref_t wakeref;
+
if (!intel_pxp_is_enabled(pxp))
return;
@@ -48,7 +50,8 @@ void intel_pxp_resume_complete(struct intel_pxp *pxp)
if (!HAS_ENGINE(pxp->ctrl_gt, GSC0) && !pxp->pxp_component)
return;
- intel_pxp_init_hw(pxp);
+ with_intel_runtime_pm(>ctrl_gt->i915->runtime_pm, wakeref)
+ intel_pxp_init_hw(pxp);
}
void intel_pxp_runtime_suspend(struct intel_pxp *pxp)
base-commit: a66da4c33d8ede541aea9ba6d0d73b556a072d54
--
2.39.0
Re: [PATCH] accel/ivpu: Use struct_size()
On 2023-05-29 15:28, Christophe JAILLET wrote:
> Use struct_size() instead of hand-writing it. It is less verbose, more
> robust and more informative.
>
> Signed-off-by: Christophe JAILLET
Reviewed-by: Marco Pagani
> ---
> drivers/accel/ivpu/ivpu_job.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/accel/ivpu/ivpu_job.c b/drivers/accel/ivpu/ivpu_job.c
> index 3c6f1e16cf2f..0a09bba8da24 100644
> --- a/drivers/accel/ivpu/ivpu_job.c
> +++ b/drivers/accel/ivpu/ivpu_job.c
> @@ -289,15 +289,13 @@ ivpu_create_job(struct ivpu_file_priv *file_priv, u32
> engine_idx, u32 bo_count)
> {
> struct ivpu_device *vdev = file_priv->vdev;
> struct ivpu_job *job;
> - size_t buf_size;
> int ret;
>
> ret = ivpu_rpm_get(vdev);
> if (ret < 0)
> return NULL;
>
> - buf_size = sizeof(*job) + bo_count * sizeof(struct ivpu_bo *);
> - job = kzalloc(buf_size, GFP_KERNEL);
> + job = kzalloc(struct_size(job, bos, bo_count), GFP_KERNEL);
> if (!job)
> goto err_rpm_put;
>
Re: [v4 4/4] drm/panel: Support for Starry-ili9882t TDDI MIPI-DSI panel
Hi, On Thu, May 25, 2023 at 2:32 AM Cong Yang wrote: > > The Starry-ili9882 is a 10.51" WUXGA TFT panel. which fits in nicely with > the existing panel-boe-tv101wum-nl6 driver. From the datasheet,MIPI need > to keep the LP11 state before the lcm_reset pin is pulled high. So add > lp11_before_reset flag. > > Signed-off-by: Cong Yang > Reviewed-by: Douglas Anderson > --- > .../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 371 ++ > 1 file changed, 371 insertions(+) Applied to drm-misc-next: 8716a6473e6c drm/panel: Support for Starry-ili9882t TDDI MIPI-DSI panel
Re: [v4 3/4] dt-bindings: display: panel: Add compatible for Starry ili9882t
Hi, On Thu, May 25, 2023 at 2:32 AM Cong Yang wrote: > > The STARRY ili9882t is a 10.51" WUXGA TFT LCD panel, > which fits in nicely with the existing panel-boe-tv101wum-nl6 > driver. Hence, we add a new compatible with panel specific config. > > Signed-off-by: Cong Yang > Reviewed-by: Douglas Anderson > Acked-by: Conor Dooley > --- > .../devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml | 2 ++ > 1 file changed, 2 insertions(+) Applied to drm-misc-next: 0a73471ca1f7 dt-bindings: display: panel: Add compatible for Starry ili9882t
Re: [v4 2/4] drm/panel: Support for Starry-himax83102-j02 TDDI MIPI-DSI panel
Hi, On Thu, May 25, 2023 at 2:32 AM Cong Yang wrote: > > The Starry-himax83102-j02 is a 10.51" WUXGA TFT panel. which fits in nicely > with the existing panel-boe-tv101wum-nl6 driver. From the datasheet[1], MIPI > needs to keep the LP11 state before the lcm_reset pin is pulled high, so > increase lp11_before_reset flag. > > [1]: > https://github.com/HimaxSoftware/Doc/tree/main/Himax_Chipset_Power_Sequence > > Signed-off-by: Cong Yang > Reviewed-by: Douglas Anderson > --- > .../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 100 ++ > 1 file changed, 100 insertions(+) Applied to drm-misc-next: 1bc2ef065f13 drm/panel: Support for Starry-himax83102-j02 TDDI MIPI-DSI panel
Re: [v4 1/4] dt-bindings: display: panel: Add compatible for Starry himax83102-j02
Hi, On Thu, May 25, 2023 at 2:32 AM Cong Yang wrote: > > The STARRY himax83102-j02 is a 10.51" WUXGA TFT LCD panel, > which fits in nicely with the existing panel-boe-tv101wum-nl6 > driver. Hence, we add a new compatible with panel specific config. > > Signed-off-by: Cong Yang > Reviewed-by: Douglas Anderson > Acked-by: Conor Dooley > --- > .../devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml | 2 ++ > 1 file changed, 2 insertions(+) Applied to drm-misc-next: 06c3269cd574 dt-bindings: display: panel: Add compatible for Starry himax83102-j02
Re: [v4 0/4] Support Starry-himax83102-j02 and Starry-ili9882t TDDI MIPI-DSI panel
Hi, On Thu, May 25, 2023 at 2:32 AM Cong Yang wrote: > > Copare V3:Resend without Conor's acks on patches 2 and 4. > > Cong Yang (4): > dt-bindings: display: panel: Add compatible for Starry himax83102-j02 > drm/panel: Support for Starry-himax83102-j02 TDDI MIPI-DSI panel > dt-bindings: display: panel: Add compatible for Starry ili9882t > drm/panel: Support for Starry-ili9882t TDDI MIPI-DSI panel > > .../display/panel/boe,tv101wum-nl6.yaml | 4 + > .../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 471 ++ > 2 files changed, 475 insertions(+) For future reference: please don't send your patch series "In-Reply-To" the previous version (or in In-Reply-To anything). This messes up a bunch of threading and generally people don't like it. No need to resend this patch series.
Re: [PATCH v5 08/12] drm/msm/dpu: Add SM6375 support
On 2023-05-23 09:46:19, Konrad Dybcio wrote:
> Add basic SM6375 support to the DPU1 driver to enable display output.
Nit: The SM6350 commit doesn't use the word "basic" here: what does it
mean? Is this addition not complete (because it seems so)?
> Reviewed-by: Dmitry Baryshkov
> Signed-off-by: Konrad Dybcio
> ---
> .../gpu/drm/msm/disp/dpu1/catalog/dpu_6_9_sm6375.h | 139
> +
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 1 +
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 1 +
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c| 1 +
> 4 files changed, 142 insertions(+)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_9_sm6375.h
> b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_9_sm6375.h
> new file mode 100644
> index ..924f2526c06a
> --- /dev/null
> +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_9_sm6375.h
> @@ -0,0 +1,139 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Copyright (c) 2022. Qualcomm Innovation Center, Inc. All rights reserved.
> + * Copyright (c) 2015-2018, 2020 The Linux Foundation. All rights reserved.
> + * Copyright (c) 2023, Linaro Limited
> + */
> +
> +#ifndef _DPU_6_9_SM6375_H
> +#define _DPU_6_9_SM6375_H
> +
> +static const struct dpu_caps sm6375_dpu_caps = {
> + .max_mixer_width = DEFAULT_DPU_LINE_WIDTH,
> + .max_mixer_blendstages = 0x4,
> + .qseed_type = DPU_SSPP_SCALER_QSEED4,
> + .has_dim_layer = true,
> + .has_idle_pc = true,
> + .max_linewidth = 2160,
> + .pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
> +};
> +
> +static const struct dpu_ubwc_cfg sm6375_ubwc_cfg = {
> + .ubwc_version = DPU_HW_UBWC_VER_20,
> + .ubwc_swizzle = 6,
> + .highest_bank_bit = 1,
> +};
> +
> +static const struct dpu_mdp_cfg sm6375_mdp[] = {
> + {
> + .name = "top_0", .id = MDP_TOP,
> + .base = 0x0, .len = 0x494,
> + .features = 0,
> + .clk_ctrls[DPU_CLK_CTRL_VIG0] = { .reg_off = 0x2ac, .bit_off = 0 },
> + .clk_ctrls[DPU_CLK_CTRL_DMA0] = { .reg_off = 0x2ac, .bit_off = 8 },
> + },
> +};
> +
> +static const struct dpu_ctl_cfg sm6375_ctl[] = {
> + {
> + .name = "ctl_0", .id = CTL_0,
> + .base = 0x1000, .len = 0x1dc,
> + .features = BIT(DPU_CTL_ACTIVE_CFG),
> + .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 9),
> + },
> +};
> +
> +static const struct dpu_sspp_cfg sm6375_sspp[] = {
> + SSPP_BLK("sspp_0", SSPP_VIG0, 0x4000, 0x1f8, VIG_SC7180_MASK,
> + sm6115_vig_sblk_0, 0, SSPP_TYPE_VIG, DPU_CLK_CTRL_VIG0),
> + SSPP_BLK("sspp_8", SSPP_DMA0, 0x24000, 0x1f8, DMA_SDM845_MASK,
> + sdm845_dma_sblk_0, 1, SSPP_TYPE_DMA, DPU_CLK_CTRL_DMA0),
> +};
> +
> +static const struct dpu_lm_cfg sm6375_lm[] = {
> + LM_BLK("lm_0", LM_0, 0x44000, MIXER_QCM2290_MASK,
> + _lm_sblk, PINGPONG_0, 0, DSPP_0),
> +};
> +
> +static const struct dpu_dspp_cfg sm6375_dspp[] = {
> + DSPP_BLK("dspp_0", DSPP_0, 0x54000, DSPP_SC7180_MASK,
> + _dspp_sblk),
> +};
> +
> +static const struct dpu_pingpong_cfg sm6375_pp[] = {
> + PP_BLK("pingpong_0", PINGPONG_0, 0x7, PINGPONG_SM8150_MASK, 0,
> sdm845_pp_sblk,
> + DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 8),
> + -1),
> +};
> +
> +static const struct dpu_dsc_cfg sm6375_dsc[] = {
> + DSC_BLK("dsc_0", DSC_0, 0x8, BIT(DPU_DSC_OUTPUT_CTRL)),
> +};
> +
> +static const struct dpu_intf_cfg sm6375_intf[] = {
> + INTF_BLK("intf_0", INTF_0, 0x0, 0x280, INTF_NONE, 0, 0, 0, 0, 0),
> + INTF_BLK_DSI_TE("intf_1", INTF_1, 0x6a800, 0x2c0, INTF_DSI, 0, 24,
> INTF_SC7280_MASK,
Did you forget to set this back to SC7180? This will be enabling
DPU_INTF_DATA_COMPRESS otherwise, which is a DPU 7.x feature.
- Marijn
> + DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 26),
> + DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 27),
> + DPU_IRQ_IDX(MDP_INTF1_TEAR_INTR, 2)),
> +};
> +
> +static const struct dpu_perf_cfg sm6375_perf_data = {
> + .max_bw_low = 520,
> + .max_bw_high = 620,
> + .min_core_ib = 250,
> + .min_llcc_ib = 0, /* No LLCC on this SoC */
> + .min_dram_ib = 160,
> + .min_prefill_lines = 24,
> + /* TODO: confirm danger_lut_tbl */
> + .danger_lut_tbl = {0x, 0x, 0x0},
> + .safe_lut_tbl = {0xfe00, 0xfe00, 0x},
> + .qos_lut_tbl = {
> + {.nentry = ARRAY_SIZE(sm6350_qos_linear_macrotile),
> + .entries = sm6350_qos_linear_macrotile
> + },
> + {.nentry = ARRAY_SIZE(sm6350_qos_linear_macrotile),
> + .entries = sm6350_qos_linear_macrotile
> + },
> + {.nentry = ARRAY_SIZE(sc7180_qos_nrt),
> + .entries = sc7180_qos_nrt
> + },
> + },
> + .cdp_cfg = {
> + {.rd_enable = 1, .wr_enable = 1},
> + {.rd_enable = 1, .wr_enable = 0}
> + },
> + .clk_inefficiency_factor = 105,
> + .bw_inefficiency_factor = 120,
> +};
> +
> +const
Re: [PATCH v3 1/2] drm/mediatek: Add ability to support dynamic connector selection
Re: [PATCH] gpu: drm/panel: Optimize the workflow of s6d7aa0_lock
Hi Lu,
kernel test robot noticed the following build errors:
[auto build test ERROR on drm-misc/drm-misc-next]
[also build test ERROR on next-20230601]
[cannot apply to linus/master v6.4-rc4]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Lu-Hongfei/gpu-drm-panel-Optimize-the-workflow-of-s6d7aa0_lock/20230531-190848
base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link:
https://lore.kernel.org/r/20230531110717.36896-1-luhongfei%40vivo.com
patch subject: [PATCH] gpu: drm/panel: Optimize the workflow of s6d7aa0_lock
config: powerpc-allmodconfig
(https://download.01.org/0day-ci/archive/20230601/202306012249.sm2dlqlk-...@intel.com/config)
compiler: powerpc-linux-gcc (GCC) 12.3.0
reproduce (this is a W=1 build):
mkdir -p ~/bin
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/intel-lab-lkp/linux/commit/e1ade7d20fb0efb9aa0b332d5ac5da2863f8e68e
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review
Lu-Hongfei/gpu-drm-panel-Optimize-the-workflow-of-s6d7aa0_lock/20230531-190848
git checkout e1ade7d20fb0efb9aa0b332d5ac5da2863f8e68e
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.3.0 ~/bin/make.cross
W=1 O=build_dir ARCH=powerpc olddefconfig
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.3.0 ~/bin/make.cross
W=1 O=build_dir ARCH=powerpc SHELL=/bin/bash drivers/gpu/drm/panel/
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot
| Closes:
https://lore.kernel.org/oe-kbuild-all/202306012249.sm2dlqlk-...@intel.com/
All errors (new ones prefixed by >>):
In file included from drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c:17:
drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c: In function 's6d7aa0_lock':
>> include/drm/drm_mipi_dsi.h:326:9: error: expected expression before 'do'
326 | do {
\
| ^~
drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c:72:23: note: in expansion of
macro 'mipi_dsi_dcs_write_seq'
72 | ret = mipi_dsi_dcs_write_seq(dsi, MCS_PASSWD1, 0xa5,
0xa5);
| ^~
>> include/drm/drm_mipi_dsi.h:326:9: error: expected expression before 'do'
326 | do {
\
| ^~
drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c:75:23: note: in expansion of
macro 'mipi_dsi_dcs_write_seq'
75 | ret = mipi_dsi_dcs_write_seq(dsi, MCS_PASSWD2, 0xa5,
0xa5);
| ^~
>> include/drm/drm_mipi_dsi.h:326:9: error: expected expression before 'do'
326 | do {
\
| ^~
drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c:79:31: note: in expansion of
macro 'mipi_dsi_dcs_write_seq'
79 | ret = mipi_dsi_dcs_write_seq(dsi,
MCS_PASSWD3, 0x5a, 0x5a);
| ^~
>> include/drm/drm_mipi_dsi.h:326:9: error: expected expression before 'do'
326 | do {
\
| ^~
drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c:84:23: note: in expansion of
macro 'mipi_dsi_dcs_write_seq'
84 | ret = mipi_dsi_dcs_write_seq(dsi, MCS_PASSWD1, 0x5a,
0x5a);
| ^~
>> include/drm/drm_mipi_dsi.h:326:9: error: expected expression before 'do'
326 | do {
\
| ^~
drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c:87:23: note: in expansion of
macro 'mipi_dsi_dcs_write_seq'
87 | ret = mipi_dsi_dcs_write_seq(dsi, MCS_PASSWD2, 0x5a,
0x5a);
| ^~
>> include/drm/drm_mipi_dsi.h:326:9: error: expected expression before 'do'
326 | do {
\
| ^~
drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c:91:31: note: in expansion of
macro 'mipi_dsi_dcs_write_seq'
91 | ret = mipi_dsi_dcs_write_seq(dsi,
MCS_PASSWD3, 0xa5, 0xa5);
| ^~
drivers/gpu/drm/panel/panel-samsung-s6d7aa0.
RE: [Intel-gfx] [PATCH] drm/i915/gt: Use the correct error value when kernel_context() fails
> -Original Message-
> From: Intel-gfx On Behalf Of
> Andrzej Hajda
> Sent: Thursday, June 1, 2023 6:14 PM
> To: Andi Shyti ; Intel GFX g...@lists.freedesktop.org>; DRI Devel
> Cc: Chris Wilson ; sta...@vger.kernel.org; Dan
> Carpenter ; Andi Shyti
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/gt: Use the correct error value
> when kernel_context() fails
>
> On 26.05.2023 14:41, Andi Shyti wrote:
> > kernel_context() returns an error pointer. Use pointer-error
> > conversion functions to evaluate its return value, rather than
> > checking for a '0' return.
> >
> > Fixes: eb5c10cbbc2f ("drm/i915: Remove I915_USER_PRIORITY_SHIFT")
> > Reported-by: Dan Carpenter
> > Signed-off-by: Andi Shyti
> > Cc: Chris Wilson < ch...@chris-wilson.co.uk>
> > Cc: # v5.13+
>
> Reviewed-by: Andrzej Hajda
>
> Regards
> Andrzej
>
> > ---
> > drivers/gpu/drm/i915/gt/selftest_execlists.c | 12
> > 1 file changed, 8 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/selftest_execlists.c
> > b/drivers/gpu/drm/i915/gt/selftest_execlists.c
> > index 736b89a8ecf54..4202df5b8c122 100644
> > --- a/drivers/gpu/drm/i915/gt/selftest_execlists.c
> > +++ b/drivers/gpu/drm/i915/gt/selftest_execlists.c
> > @@ -1530,8 +1530,8 @@ static int live_busywait_preempt(void *arg)
> > struct drm_i915_gem_object *obj;
> > struct i915_vma *vma;
> > enum intel_engine_id id;
> > - int err = -ENOMEM;
> > u32 *map;
> > + int err;
We could initialize err with 0 and remove err = 0 assignment below but leaving
up to you.
> >
> > /*
> > * Verify that even without HAS_LOGICAL_RING_PREEMPTION, we
> can @@
> > -1539,13 +1539,17 @@ static int live_busywait_preempt(void *arg)
> > */
> >
> > ctx_hi = kernel_context(gt->i915, NULL);
> > - if (!ctx_hi)
> > - return -ENOMEM;
> > + if (IS_ERR(ctx_hi))
> > + return PTR_ERR(ctx_hi);
> > +
> > ctx_hi->sched.priority = I915_CONTEXT_MAX_USER_PRIORITY;
> >
> > ctx_lo = kernel_context(gt->i915, NULL);
> > - if (!ctx_lo)
> > + if (IS_ERR(ctx_lo)) {
> > + err = PTR_ERR(ctx_lo);
> > goto err_ctx_hi;
> > + }
> > +
Looks fine,
Acked-by: Tejas Upadhyay
> > ctx_lo->sched.priority = I915_CONTEXT_MIN_USER_PRIORITY;
> >
> > obj = i915_gem_object_create_internal(gt->i915, PAGE_SIZE);
Re: [Intel-gfx] [PATCH] drm/i915/gt: Use the correct error value when kernel_context() fails
Hi Tejas,
> > > @@ -1530,8 +1530,8 @@ static int live_busywait_preempt(void *arg)
> > > struct drm_i915_gem_object *obj;
> > > struct i915_vma *vma;
> > > enum intel_engine_id id;
> > > - int err = -ENOMEM;
> > > u32 *map;
> > > + int err;
>
> We could initialize err with 0 and remove err = 0 assignment below but
> leaving up to you.
that assignement must be a leftover from previous patches because
err is already initialized here:
err = i915_vma_pin(vma, 0, 0, PIN_GLOBAL);
will remove it. Thanks!
> > >
> > > /*
> > >* Verify that even without HAS_LOGICAL_RING_PREEMPTION, we
> > can @@
> > > -1539,13 +1539,17 @@ static int live_busywait_preempt(void *arg)
> > >*/
> > >
> > > ctx_hi = kernel_context(gt->i915, NULL);
> > > - if (!ctx_hi)
> > > - return -ENOMEM;
> > > + if (IS_ERR(ctx_hi))
> > > + return PTR_ERR(ctx_hi);
> > > +
> > > ctx_hi->sched.priority = I915_CONTEXT_MAX_USER_PRIORITY;
> > >
> > > ctx_lo = kernel_context(gt->i915, NULL);
> > > - if (!ctx_lo)
> > > + if (IS_ERR(ctx_lo)) {
> > > + err = PTR_ERR(ctx_lo);
> > > goto err_ctx_hi;
> > > + }
> > > +
>
> Looks fine,
> Acked-by: Tejas Upadhyay
Thank you!
Andi
>
> > > ctx_lo->sched.priority = I915_CONTEXT_MIN_USER_PRIORITY;
> > >
> > > obj = i915_gem_object_create_internal(gt->i915, PAGE_SIZE);
>
Re: [PATCH] drm/radeon: fix race condition UAF in radeon_gem_set_domain_ioctl
Am 26.05.23 um 14:37 schrieb Min Li: Userspace can race to free the gobj(robj converted from), robj should not be accessed again after drm_gem_object_put, otherwith it will result in use-after-free. Signed-off-by: Min Li --- drivers/gpu/drm/radeon/radeon_gem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/radeon/radeon_gem.c b/drivers/gpu/drm/radeon/radeon_gem.c index bdc5af23f005..450c7cbdd28a 100644 --- a/drivers/gpu/drm/radeon/radeon_gem.c +++ b/drivers/gpu/drm/radeon/radeon_gem.c @@ -478,7 +478,7 @@ int radeon_gem_set_domain_ioctl(struct drm_device *dev, void *data, drm_gem_object_put(gobj); up_read(>exclusive_lock); - r = radeon_gem_handle_lockup(robj->rdev, r); + r = radeon_gem_handle_lockup(rdev, r); This also makes the robj unused which the kernel test robot also complained about. Please remove that local variable and re-submit. Apart from that the patch looks good to me, Christian. return r; }
Re: (subset) [PATCH v5 00/17] drm/meson: add support for MIPI DSI Display
Hi, On Tue, 30 May 2023 09:38:01 +0200, Neil Armstrong wrote: > The Amlogic G12A, G12B & SM1 SoCs embeds a Synopsys DW-MIPI-DSI transceiver > (ver 1.21a), > with a custom glue managing the IP resets, clock and data input similar to > the DW-HDMI > glue on the same Amlogic SoCs. > > This adds support for the glue managing the transceiver, mimicing the init > flow provided > by Amlogic to setup the ENCL encoder, the glue, the transceiver, the digital > D-PHY and the > Analog PHY in the proper way. > > [...] Thanks, Applied to https://anongit.freedesktop.org/git/drm/drm-misc.git (drm-misc-next) [06/17] dt-bindings: display: add Amlogic MIPI DSI Host Controller bindings https://cgit.freedesktop.org/drm/drm-misc/commit/?id=0628f2341e96213c9f2d074853b255f65acd3795 [07/17] dt-bindings: display: meson-vpu: add third DPI output port https://cgit.freedesktop.org/drm/drm-misc/commit/?id=25b3b35cd51ef0d98165666d250a51f39db6a1fc [08/17] drm/meson: fix unbind path if HDMI fails to bind https://cgit.freedesktop.org/drm/drm-misc/commit/?id=6a044642988b5f8285f3173b8e88784bef2bc306 [09/17] drm/meson: only use components with dw-hdmi https://cgit.freedesktop.org/drm/drm-misc/commit/?id=44e16166e0e9b94d8bcdf55fc0e5fcceca1154f0 [10/17] drm/meson: venc: add ENCL encoder setup for MIPI-DSI output https://cgit.freedesktop.org/drm/drm-misc/commit/?id=51fc01a03442cce5e4c21375a1ceb2e4ec93c833 [11/17] drm/meson: add DSI encoder https://cgit.freedesktop.org/drm/drm-misc/commit/?id=42dcf15f901c8222352da31d622b4ee844068f42 [12/17] drm/meson: add support for MIPI-DSI transceiver https://cgit.freedesktop.org/drm/drm-misc/commit/?id=77d9e1e6b8468f701ab024a060aa9c0339356870 [13/17] drm/panel: khadas-ts050: update timings to achieve 60Hz refresh rate https://cgit.freedesktop.org/drm/drm-misc/commit/?id=29c6df0d942454cb43334cf0e36de068f4124b94 -- Neil
Re: [PATCH] drm/panel: khadas-ts050: update timings to achieve 60Hz refresh rate
Hi, On Thu, 26 Jan 2023 10:39:42 +0100, Neil Armstrong wrote: > This updates the panel timings to achieve a clean 60Hz refresh rate. > > Thanks, Applied to https://anongit.freedesktop.org/git/drm/drm-misc.git (drm-misc-next) [1/1] drm/panel: khadas-ts050: update timings to achieve 60Hz refresh rate https://cgit.freedesktop.org/drm/drm-misc/commit/?id=29c6df0d942454cb43334cf0e36de068f4124b94 -- Neil
[PULL] drm-intel-fixes
Hi Dave & Daniel, One fix appeared this morning, related to OA API for non-power-of-two reports. Full CI results not in yet, BAT is looking good so please check before pulling the trigger. Regards, Joonas *** drm-intel-fixes-2023-06-01: - Fix for OA reporting to allow detecting non-power-of-two reports The following changes since commit 7877cb91f1081754a1487c144d85dc0d2e2e7fc4: Linux 6.4-rc4 (2023-05-28 07:49:00 -0400) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2023-06-01 for you to fetch changes up to 62fe398761cd06a428e6f367aba84732a2f1c268: drm/i915/perf: Clear out entire reports after reading if not power of 2 size (2023-06-01 09:41:58 +0300) - Fix for OA reporting to allow detecting non-power-of-two reports Ashutosh Dixit (1): drm/i915/perf: Clear out entire reports after reading if not power of 2 size drivers/gpu/drm/i915/i915_perf.c | 17 +++-- 1 file changed, 11 insertions(+), 6 deletions(-)
Re: [PATCH v6 2/6] drm/etnaviv: add a dedicated function to get various clocks
Hi,
On 2023/6/1 02:07, Lucas Stach wrote:
+static int etnaviv_gpu_clk_get(struct etnaviv_gpu *gpu)
+{
+ struct device *dev = gpu->dev;
+
+ if (gpu->no_clk)
+ return 0;
+
+ gpu->clk_reg = devm_clk_get_optional(dev, "reg");
+ DBG("clk_reg: %p", gpu->clk_reg);
+ if (IS_ERR(gpu->clk_reg))
+ return PTR_ERR(gpu->clk_reg);
+
+ gpu->clk_bus = devm_clk_get_optional(dev, "bus");
+ DBG("clk_bus: %p", gpu->clk_bus);
+ if (IS_ERR(gpu->clk_bus))
+ return PTR_ERR(gpu->clk_bus);
+
+ gpu->clk_core = devm_clk_get(dev, "core");
+ DBG("clk_core: %p", gpu->clk_core);
+ if (IS_ERR(gpu->clk_core))
+ return PTR_ERR(gpu->clk_core);
+ gpu->base_rate_core = clk_get_rate(gpu->clk_core);
+
+ gpu->clk_shader = devm_clk_get_optional(dev, "shader");
+ DBG("clk_shader: %p", gpu->clk_shader);
+ if (IS_ERR(gpu->clk_shader))
+ return PTR_ERR(gpu->clk_shader);
+ gpu->base_rate_shader = clk_get_rate(gpu->clk_shader);
+
+ return 0;
+}
+
static int etnaviv_gpu_clk_enable(struct etnaviv_gpu *gpu)
{
int ret;
+ if (gpu->no_clk)
+ return 0;
+
I don't see why this would be needed?
I have just tested, this do not needed.
If your platform doesn't provide
CONFIG_HAVE_CLK all those functions should be successful no-ops, so
there is no need to special case this in the driver.
My platform do enable CONFIG_HAVE_CLK,
for ls3a5000 + ls7a1000, my system do not provide device tree support,
that's is to say, there is no DT support.
For ls3a4000 + ls7a1000 platform, the system has DT support, but don't
has CLK drivers implement toward the clock tree.
typically, our platform's firmware will do such thing(setting a default
working frequency).
When I first saw etnaviv, I'm also astonishing.
I don't know why there so much clock controllable.
As far as I can understand, my system/hardware have only one clock,
It shall corresponding to the core clk.
Or does your platform in fact provide a clk subsystem, just the GPU
clocks are managed by it?
Also all those functions are fine with being called on a NULL clk, so
shouldn't it be enough to simply avoid calling etnaviv_gpu_clk_get() in
the PCI device case?
Regards,
Lucas
--
Jingfeng
Re: [PATCH 1/2] dt-bindings: display: bridge: tc358762: Document reset-gpios
From: Robert Foss On Tue, 30 May 2023 21:28:04 +0200, Marek Vasut wrote: > This chip has one reset GPIO input, document it. The reset GPIO > is optional as it is sometimes not connected on some hardware. > > Applied, thanks! [1/2] dt-bindings: display: bridge: tc358762: Document reset-gpios https://cgit.freedesktop.org/drm/drm-misc/commit/?id=e8001973bb45 [2/2] drm/bridge: tc358762: Add reset GPIO support https://cgit.freedesktop.org/drm/drm-misc/commit/?id=3355f4ee561d Rob
Re: [Intel-gfx] [PATCH] drm/i915/gt: Use the correct error value when kernel_context() fails
On 26.05.2023 14:41, Andi Shyti wrote:
kernel_context() returns an error pointer. Use pointer-error
conversion functions to evaluate its return value, rather than
checking for a '0' return.
Fixes: eb5c10cbbc2f ("drm/i915: Remove I915_USER_PRIORITY_SHIFT")
Reported-by: Dan Carpenter
Signed-off-by: Andi Shyti
Cc: Chris Wilson < ch...@chris-wilson.co.uk>
Cc: # v5.13+
Reviewed-by: Andrzej Hajda
Regards
Andrzej
---
drivers/gpu/drm/i915/gt/selftest_execlists.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_execlists.c
b/drivers/gpu/drm/i915/gt/selftest_execlists.c
index 736b89a8ecf54..4202df5b8c122 100644
--- a/drivers/gpu/drm/i915/gt/selftest_execlists.c
+++ b/drivers/gpu/drm/i915/gt/selftest_execlists.c
@@ -1530,8 +1530,8 @@ static int live_busywait_preempt(void *arg)
struct drm_i915_gem_object *obj;
struct i915_vma *vma;
enum intel_engine_id id;
- int err = -ENOMEM;
u32 *map;
+ int err;
/*
* Verify that even without HAS_LOGICAL_RING_PREEMPTION, we can
@@ -1539,13 +1539,17 @@ static int live_busywait_preempt(void *arg)
*/
ctx_hi = kernel_context(gt->i915, NULL);
- if (!ctx_hi)
- return -ENOMEM;
+ if (IS_ERR(ctx_hi))
+ return PTR_ERR(ctx_hi);
+
ctx_hi->sched.priority = I915_CONTEXT_MAX_USER_PRIORITY;
ctx_lo = kernel_context(gt->i915, NULL);
- if (!ctx_lo)
+ if (IS_ERR(ctx_lo)) {
+ err = PTR_ERR(ctx_lo);
goto err_ctx_hi;
+ }
+
ctx_lo->sched.priority = I915_CONTEXT_MIN_USER_PRIORITY;
obj = i915_gem_object_create_internal(gt->i915, PAGE_SIZE);
[PATCH] drm: bridge: dw_hdmi: fix connector access for scdc
Commit 5d844091f237 ("drm/scdc-helper: Pimp SCDC debugs") changed the scdc
interface to pick up an i2c adapter from a connector instead. However, in
the case of dw-hdmi, the wrong connector was being used to pass i2c adapter
information, since dw-hdmi's embedded connector structure is only populated
when the bridge attachment callback explicitly asks for it.
drm-meson is handling connector creation, so this won't happen, leading to
a NULL pointer dereference.
Fix it by having scdc functions access dw-hdmi's current connector pointer
instead, which is assigned during the bridge enablement stage.
Signed-off-by: Adrián Larumbe
Fixes: 5d844091f237 ("drm/scdc-helper: Pimp SCDC debugs")
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 0accfb51509c..69c0e80b8525 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -1412,9 +1412,9 @@ void dw_hdmi_set_high_tmds_clock_ratio(struct dw_hdmi
*hdmi,
/* Control for TMDS Bit Period/TMDS Clock-Period Ratio */
if (dw_hdmi_support_scdc(hdmi, display)) {
if (mtmdsclock > HDMI14_MAX_TMDSCLK)
- drm_scdc_set_high_tmds_clock_ratio(>connector, 1);
+ drm_scdc_set_high_tmds_clock_ratio(hdmi->curr_conn, 1);
else
- drm_scdc_set_high_tmds_clock_ratio(>connector, 0);
+ drm_scdc_set_high_tmds_clock_ratio(hdmi->curr_conn, 0);
}
}
EXPORT_SYMBOL_GPL(dw_hdmi_set_high_tmds_clock_ratio);
@@ -2102,7 +2102,7 @@ static void hdmi_av_composer(struct dw_hdmi *hdmi,
min_t(u8, bytes, SCDC_MIN_SOURCE_VERSION));
/* Enabled Scrambling in the Sink */
- drm_scdc_set_scrambling(>connector, 1);
+ drm_scdc_set_scrambling(hdmi->curr_conn, 1);
/*
* To activate the scrambler feature, you must ensure
@@ -2118,7 +2118,7 @@ static void hdmi_av_composer(struct dw_hdmi *hdmi,
hdmi_writeb(hdmi, 0, HDMI_FC_SCRAMBLER_CTRL);
hdmi_writeb(hdmi, (u8)~HDMI_MC_SWRSTZ_TMDSSWRST_REQ,
HDMI_MC_SWRSTZ);
- drm_scdc_set_scrambling(>connector, 0);
+ drm_scdc_set_scrambling(hdmi->curr_conn, 0);
}
}
@@ -3546,6 +3546,7 @@ struct dw_hdmi *dw_hdmi_probe(struct platform_device
*pdev,
hdmi->bridge.ops = DRM_BRIDGE_OP_DETECT | DRM_BRIDGE_OP_EDID
| DRM_BRIDGE_OP_HPD;
hdmi->bridge.interlace_allowed = true;
+ hdmi->bridge.ddc = hdmi->ddc;
#ifdef CONFIG_OF
hdmi->bridge.of_node = pdev->dev.of_node;
#endif
--
2.40.0
RE: [PATCH v9 RESEND 0/5] Add RZ/{G2L,G2LC} and RZ/V2L Display Unit support
Hi Laurent,
Thanks for the feedback.
> Subject: Re: [PATCH v9 RESEND 0/5] Add RZ/{G2L,G2LC} and RZ/V2L Display
> Unit support
>
> On Mon, May 29, 2023 at 02:22:06PM +, Biju Das wrote:
> > HI Laurent,
> >
> > Thanks for the feedback.
> >
> > > Subject: Re: [PATCH v9 RESEND 0/5] Add RZ/{G2L,G2LC} and RZ/V2L
> > > Display Unit support
> > >
> > > Hi Biju,
> > >
> > > On Thu, May 25, 2023 at 02:30:10PM +, Biju Das wrote:
> > > > Hi DRM maintainers,
> > > >
> > > > Gentle ping.
> > >
> > > Sorry, I was on holidays the last two weeks.
> > >
> > > > Are we happy with moving all Renesas drm drivers to Renesas
> > > > specific directory or preference is for separate one??
> > >
> > > This works for me.
> > >
> > > > If it is later, I can send RZ/G2L drm driver separate.
> > > >
> > > > Otherwise, I need to rebase and resend.
> > >
> > > Your series applies cleanly on top of the latest drm-next branch. Is
> > > there a specific need to rebase and resend ?
> >
> > Nope. After my patch series there were some patches from Geert for
> > drm/shmobile merged to drm-misc-next by Thomas.
> >
> > Maybe git managed this automatically??
>
> Probably, git is nice :-)
>
> > > I haven't had time to review patch 4/5 (the driver) yet. All the
> > > rest looks good to me. Should I already include 1/5 in my next pull
> request ?
> >
> > Yes, please.
>
> OK, I will do so. I've reviewed 4/5 in the meantime, but changes are
> needed, so I won't wait for v10 before applying 1/5.
>
I have incorporated review comments for v9. I need to rebase my changes.
Is the pull request being done to drm-misc-next?
Cheers,
Biju
> > > > Please let me know your preference.
> > > >
> > > > Cheers,
> > > > Biju
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: Biju Das
> > > > > Sent: Monday, May 15, 2023 8:58 AM
> > > > > To: David Airlie ; Daniel Vetter
> > > > > ; Philipp Zabel ; Geert
> > > > > Uytterhoeven ; Laurent Pinchart
> > > > > ; Kieran Bingham
> > > > >
> > > > > Cc: dri-devel@lists.freedesktop.org;
> > > > > linux-renesas-...@vger.kernel.org;
> > > > > Fabrizio Castro ; Prabhakar
> > > > > Mahadev Lad
> > > > > Subject: RE: [PATCH v9 RESEND 0/5] Add RZ/{G2L,G2LC} and RZ/V2L
> > > > > Display Unit support
> > > > >
> > > > > Hi All,
> > > > >
> > > > > Gentle ping. Are we happy with this patch series?
> > > > >
> > > > > Cheers,
> > > > > Biju
> > > > >
> > > > > > Subject: [PATCH v9 RESEND 0/5] Add RZ/{G2L,G2LC} and RZ/V2L
> > > > > > Display Unit support
> > > > > >
> > > > > > RZ/G2L LCD controller composed of Frame compression
> > > > > > Processor(FCPVD), Video signal processor (VSPD) and Display
> > > > > > unit(DU). The output of LCDC is connected to Display parallel
> > > > > > interface and MIPI link video interface.
> > > > > >
> > > > > > The output from DSI is connected to ADV7535.
> > > > > >
> > > > > > Created a vendor specific directory renesas and moved all
> > > > > > renesas drm drivers to it (rcar-du and shmobile). Then added
> > > > > > support for RZ/G2L DU DRM driver by creating rz_du directory.
> > > > > >
> > > > > > Ref:
> > > > > >
> > > > > >
> > > > > > v8->v9:
> > > > > > * Added Rb tag from Laurent and Acked-by tag from Kieran for
> > > patch#1.
> > > > > > * Added Rb tag from Laurent and Geert for patch#3.
> > > > > > * Dropped reset_control_assert() from error patch for
> > > > > > rzg2l_du_crtc_get() as
> > > > > >suggested by Philipp Zabel.
> > > > > > * Added Rb tag from Laurent oatch#5.
> > > > > > * Updated MAINTAINERS entries for common parts(Makefile and
> > > Kconfig).
> > > > > > v7->v8:
> > > > > > * Moved rcar-du and shmobile DRM drivers to renesas specific
> > > > > > vendor directory.
> > > > > > * Fixed the typo vsp2->du in RZ/V2L DU bindings patch.
> > > > > > * Added Rb tag from Rob for RZ/V2L DU bindings patch.
> > > > > > * Dropped RCar du lib and created RZ/G2L DU DRM driver by
> > > > > > creating rz_du folder.
> > > > > > * Updated MAINTAINERS entries.
> > > > > > v6->v7:
> > > > > > * Split DU lib and RZ/G2L du driver as separate patch series
> as
> > > > > >DU support added to more platforms based on RZ/G2L alike
> SoCs.
> > > > > > * Rebased to latest drm-tip.
> > > > > > * Added patch #2 for binding support for RZ/V2L DU
> > > > > > * Added patch #4 for driver support for RZ/V2L DU
> > > > > > * Added patch #5 for SoC DTSI support for RZ/G2L DU
> > > > > > * Added patch #6 for SoC DTSI support for RZ/V2L DU
> > > > > > * Added patch #7 for Enabling DU on SMARC EVK based on
> > > > > > RZ/{G2L,V2L} SoCs.
> > > > > > * Added patch #8 for Enabling DU on SMARC EVK based on
> > > > > > RZ/G2LC
> > > SoC.
> > > > > > v5->v6:
> > > > > > * Merged DU lib and RZ/G2L du driver in same patch series
> > > > > > * Rebased to latest drm-misc.
> > > > > > * Merged patch#1 to RZ/G2L Driver patch.
> > > > > > * Updated KConfig dependency from ARCH_RENESAS->ARCH_RZG2L.
> > > > > > * Optimized rzg2l_du_output_name() by removing
