RE: [PATCH] drm/i915: avoid concurrent writes to aux_inv
>>> diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
>>> b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
>>> index e1470bb60f34..7e8552414275 100644
>>> --- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
>>> +++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
>>> @@ -1258,6 +1258,34 @@ static bool completed(const struct i915_request
>>> *rq)
>>> return __i915_request_is_complete(rq); }
>>>
>>> +static i915_reg_t aux_inv_reg(const struct intel_engine_cs *engine) {
>>> + static const i915_reg_t vd[] = {
>>> + GEN12_VD0_AUX_NV,
>>> + GEN12_VD1_AUX_NV,
>>> + GEN12_VD2_AUX_NV,
>>> + GEN12_VD3_AUX_NV,
>>> + };
>>> +
>>> + static const i915_reg_t ve[] = {
>>> + GEN12_VE0_AUX_NV,
>>> + GEN12_VE1_AUX_NV,
>>> + };
>>> +
>>> + if (engine->class == VIDEO_DECODE_CLASS) {
>>> + GEM_BUG_ON(engine->instance >= ARRAY_SIZE(vd));
>>> + return vd[engine->instance];
>>> + }
>>> +
>>> + if (engine->class == VIDEO_ENHANCEMENT_CLASS) {
>>> + GEM_BUG_ON(engine->instance >= ARRAY_SIZE(ve));
>>> + return ve[engine->instance];
>>> + }
>>> +
>>> + GEM_BUG_ON("unknown aux_inv reg\n");
>>> + return INVALID_MMIO_REG;
>>> +}
>>> +
>>> static void execlists_dequeue(struct intel_engine_cs *engine)
>>
>> So in the previous implementation, this "worked" for both execlists and guc
>> submission. But how will this work now for GuC based submission?
>> This flow and the address of the engine is owned by the GuC.
>>
>> If we are going to say this is an execlist only requirement (e.g.
>> platforms using GuC submission don't need this workaround), you should add
>> an if (!using guc submission) in the sequence you added to the various
>> emit_flush() routines above.
>
> Good point.
> I didn't consider GuC submission because Chrome doesn't enable GuC for TGL.
> But it is true that the implementation will have problem with GuC submission.
> I'm not sure if it's possible for i915 to know which engine will eventually
> carry out the request because it might be scheduled by GuC. I will need to
> investigate.
I think the same can be done in intel_guc_submission.c after
__i915_request_submit(rq) calls.
>> Thanks,
>> Stuart
Re: [PATCH v3 5/5] drm/msm: allow compile time selection of driver components
On 16/03/2022 03:28, Abhinav Kumar wrote: On 3/3/2022 7:21 PM, Dmitry Baryshkov wrote: MSM DRM driver already allows one to compile out the DP or DSI support. Add support for disabling other features like MDP4/MDP5/DPU drivers or direct HDMI output support. Suggested-by: Stephen Boyd Signed-off-by: Dmitry Baryshkov --- drivers/gpu/drm/msm/Kconfig | 50 -- drivers/gpu/drm/msm/Makefile | 18 ++-- drivers/gpu/drm/msm/msm_drv.h | 33 ++ drivers/gpu/drm/msm/msm_mdss.c | 13 +++-- 4 files changed, 106 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig index 9b019598e042..3735fd41eb3b 100644 --- a/drivers/gpu/drm/msm/Kconfig +++ b/drivers/gpu/drm/msm/Kconfig @@ -46,12 +46,39 @@ config DRM_MSM_GPU_SUDO Only use this if you are a driver developer. This should *not* be enabled for production kernels. If unsure, say N. -config DRM_MSM_HDMI_HDCP - bool "Enable HDMI HDCP support in MSM DRM driver" +config DRM_MSM_MDSS + bool + depends on DRM_MSM + default n shouldnt DRM_MSM_MDSS be defaulted to y? No, it will be selected either by MDP5 or by DPU1. It is not used if DRM_MSM is compiled with just MDP4 or headless support in mind. Another question is the compilation validation of the combinations of these. So we need to try: 1) DRM_MSM_MDSS + DRM_MSM_MDP4 2) DRM_MSM_MDSS + DRM_MSM_MDP5 3) DRM_MSM_MDSS + DRM_MSM_DPU Earlier since all of them were compiled together any inter-dependencies will not show up. Now since we are separating it out, just wanted to make sure each of the combos compile? I think you meant: - headless - MDP4 - MDP5 - DPU1 - MDP4 + MDP5 - MDP4 + DPU1 - MDP5 + DPU1 - all three drivers + +config DRM_MSM_MDP4 + bool "Enable MDP4 support in MSM DRM driver" depends on DRM_MSM default y help - Choose this option to enable HDCP state machine + Compile in support for the Mobile Display Processor v4 (MDP4) in + the MSM DRM driver. It is the older display controller found in + devices using APQ8064/MSM8960/MSM8x60 platforms. + +config DRM_MSM_MDP5 + bool "Enable MDP5 support in MSM DRM driver" + depends on DRM_MSM + select DRM_MSM_MDSS + default y + help + Compile in support for the Mobile Display Processor v5 (MDP4) in + the MSM DRM driver. It is the display controller found in devices + using e.g. APQ8016/MSM8916/APQ8096/MSM8996/MSM8974/SDM6x0 platforms. + +config DRM_MSM_DPU + bool "Enable DPU support in MSM DRM driver" + depends on DRM_MSM + select DRM_MSM_MDSS + default y + help + Compile in support for the Display Processing Unit in + the MSM DRM driver. It is the display controller found in devices + using e.g. SDM845 and newer platforms. config DRM_MSM_DP bool "Enable DisplayPort support in MSM DRM driver" @@ -116,3 +143,20 @@ config DRM_MSM_DSI_7NM_PHY help Choose this option if DSI PHY on SM8150/SM8250/SC7280 is used on the platform. + +config DRM_MSM_HDMI + bool "Enable HDMI support in MSM DRM driver" + depends on DRM_MSM + default y + help + Compile in support for the HDMI output MSM DRM driver. It can + be a primary or a secondary display on device. Note that this is used + only for the direct HDMI output. If the device outputs HDMI data + throught some kind of DSI-to-HDMI bridge, this option can be disabled. + +config DRM_MSM_HDMI_HDCP + bool "Enable HDMI HDCP support in MSM DRM driver" + depends on DRM_MSM && DRM_MSM_HDMI + default y + help + Choose this option to enable HDCP state machine diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile index e76927b42033..5fe9c20ab9ee 100644 --- a/drivers/gpu/drm/msm/Makefile +++ b/drivers/gpu/drm/msm/Makefile @@ -16,6 +16,8 @@ msm-y := \ adreno/a6xx_gpu.o \ adreno/a6xx_gmu.o \ adreno/a6xx_hfi.o \ + +msm-$(CONFIG_DRM_MSM_HDMI) += \ hdmi/hdmi.o \ hdmi/hdmi_audio.o \ hdmi/hdmi_bridge.o \ @@ -27,8 +29,8 @@ msm-y := \ hdmi/hdmi_phy_8x60.o \ hdmi/hdmi_phy_8x74.o \ hdmi/hdmi_pll_8960.o \ - disp/mdp_format.o \ - disp/mdp_kms.o \ + +msm-$(CONFIG_DRM_MSM_MDP4) += \ disp/mdp4/mdp4_crtc.o \ disp/mdp4/mdp4_dtv_encoder.o \ disp/mdp4/mdp4_lcdc_encoder.o \ @@ -37,6 +39,8 @@ msm-y := \ disp/mdp4/mdp4_irq.o \ disp/mdp4/mdp4_kms.o \ disp/mdp4/mdp4_plane.o \ + +msm-$(CONFIG_DRM_MSM_MDP5) += \ disp/mdp5/mdp5_cfg.o \ disp/mdp5/mdp5_ctl.o \ disp/mdp5/mdp5_crtc.o \ @@ -47,6 +51,8 @@ msm-y := \ disp/mdp5/mdp5_mixer.o \ disp/mdp5/mdp5_plane.o \ disp/mdp5/mdp5_smp.o \ + +msm-$(CONFIG_DRM_MSM_DPU) += \ disp/dpu1/dpu_core_perf.o \ disp/dpu1/dpu_crtc.o \ disp/dpu1/dpu_encoder.o \ @@ -69,6 +75,13 @@ msm-y := \ disp/dpu1/dpu_plane.o \ disp/dpu1/dp
RE: [Intel-gfx] [PATCH v6 2/2] drm/i915/gem: Don't try to map and fence large scanout buffers (v9)
Hi Tvrtko,
>
> On 15/03/2022 07:28, Kasireddy, Vivek wrote:
> > Hi Tvrtko, Daniel,
> >
> >>
> >> On 11/03/2022 09:39, Daniel Vetter wrote:
> >>> On Mon, 7 Mar 2022 at 21:38, Vivek Kasireddy
> >>> wrote:
>
> On platforms capable of allowing 8K (7680 x 4320) modes, pinning 2 or
> more framebuffers/scanout buffers results in only one that is mappable/
> fenceable. Therefore, pageflipping between these 2 FBs where only one
> is mappable/fenceable creates latencies large enough to miss alternate
> vblanks thereby producing less optimal framerate.
>
> This mainly happens because when i915_gem_object_pin_to_display_plane()
> is called to pin one of the FB objs, the associated vma is identified
> as misplaced and therefore i915_vma_unbind() is called which unbinds and
> evicts it. This misplaced vma gets subseqently pinned only when
> i915_gem_object_ggtt_pin_ww() is called without PIN_MAPPABLE. This
> results in a latency of ~10ms and happens every other vblank/repaint
> cycle.
> Therefore, to fix this issue, we try to see if there is space to map
> at-least two objects of a given size and return early if there isn't.
> This
> would ensure that we do not try with PIN_MAPPABLE for any objects that
> are too big to map thereby preventing unncessary unbind.
>
> Testcase:
> Running Weston and weston-simple-egl on an Alderlake_S (ADLS) platform
> with a 8K@60 mode results in only ~40 FPS. Since upstream Weston submits
> a frame ~7ms before the next vblank, the latencies seen between atomic
> commit and flip event are 7, 24 (7 + 16.66), 7, 24. suggesting that
> it misses the vblank every other frame.
>
> Here is the ftrace snippet that shows the source of the ~10ms latency:
> i915_gem_object_pin_to_display_plane() {
> 0.102 us |i915_gem_object_set_cache_level();
> i915_gem_object_ggtt_pin_ww() {
> 0.390 us | i915_vma_instance();
> 0.178 us | i915_vma_misplaced();
> i915_vma_unbind() {
> __i915_active_wait() {
> 0.082 us |i915_active_acquire_if_busy();
> 0.475 us | }
> intel_runtime_pm_get() {
> 0.087 us |intel_runtime_pm_acquire();
> 0.259 us | }
> __i915_active_wait() {
> 0.085 us |i915_active_acquire_if_busy();
> 0.240 us | }
> __i915_vma_evict() {
> ggtt_unbind_vma() {
> gen8_ggtt_clear_range() {
> 10507.255 us |}
> 10507.689 us | }
> 10508.516 us | }
>
> v2: Instead of using bigjoiner checks, determine whether a scanout
> buffer is too big by checking to see if it is possible to map
> two of them into the ggtt.
>
> v3 (Ville):
> - Count how many fb objects can be fit into the available holes
> instead of checking for a hole twice the object size.
> - Take alignment constraints into account.
> - Limit this large scanout buffer check to >= Gen 11 platforms.
>
> v4:
> - Remove existing heuristic that checks just for size. (Ville)
> - Return early if we find space to map at-least two objects. (Tvrtko)
> - Slightly update the commit message.
>
> v5: (Tvrtko)
> - Rename the function to indicate that the object may be too big to
> map into the aperture.
> - Account for guard pages while calculating the total size required
> for the object.
> - Do not subject all objects to the heuristic check and instead
> consider objects only of a certain size.
> - Do the hole walk using the rbtree.
> - Preserve the existing PIN_NONBLOCK logic.
> - Drop the PIN_MAPPABLE check while pinning the VMA.
>
> v6: (Tvrtko)
> - Return 0 on success and the specific error code on failure to
> preserve the existing behavior.
>
> v7: (Ville)
> - Drop the HAS_GMCH(i915), DISPLAY_VER(i915) < 11 and
> size < ggtt->mappable_end / 4 checks.
> - Drop the redundant check that is based on previous heuristic.
>
> v8:
> - Make sure that we are holding the mutex associated with ggtt vm
> as we traverse the hole nodes.
>
> v9: (Tvrtko)
> - Use mutex_lock_interruptible_nested() instead of mutex_lock().
>
> Cc: Ville Syrjälä
> Cc: Maarten Lankhorst
> Cc: Tvrtko Ursulin
> Cc: Manasi Navare
> Reviewed-by: Tvrtko Ursulin
> Signed-off-by: Vivek Kasireddy
> ---
> drivers/gpu/drm/i915/i915_gem.c | 128 +++-
> 1 file changed, 94 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c
> b
Re: [PATCH v8 22/24] drm: rockchip: Add VOP2 driver
On Tue, Mar 15, 2022 at 02:46:35PM +0800, Andy Yan wrote: > Hi Sascha: > > On 3/11/22 16:33, Sascha Hauer wrote: > > From: Andy Yan > > > > The VOP2 unit is found on Rockchip SoCs beginning with rk3566/rk3568. > > It replaces the VOP unit found in the older Rockchip SoCs. > > > > This driver has been derived from the downstream Rockchip Kernel and > > heavily modified: > > > > - All nonstandard DRM properties have been removed > > - dropped struct vop2_plane_state and pass around less data between > >functions > > - Dropped all DRM_FORMAT_* not known on upstream > > - rework register access to get rid of excessively used macros > > - Drop all waiting for framesyncs > > > > The driver is tested with HDMI and MIPI-DSI display on a RK3568-EVB > > board. Overlay support is tested with the modetest utility. AFBC support > > on the cluster windows is tested with weston-simple-dmabuf-egl on > > weston using the (yet to be upstreamed) panfrost driver support. > > Do we need some modification to test AFBC by weston-simple-dma-egl ? By default weston-simple-dma-egl uses DRM_FORMAT_XRGB which in the panfrost driver ends up as PIPE_FORMAT_B8G8R8_UNORM and panfrost_afbc_format() returns PIPE_FORMAT_NONE for that. Change the format to DRM_FORMAT_ABGR using weston-simple-dma-egl -f 0x34324241. This ends up as PIPE_FORMAT_R8G8B8A8_UNORM in panfrost_afbc_format() which is a supported format. > > I have a buildroot system with weston-10.0.9 and mesa 21.3.5. > > After launch weston, I run weston-simple-dmabuf-egl, but from the output > > of sys/kernel/debug/dri/0/state, the weston is still use Smart0-win0, which > is > > a non-AFBC window. > > Do i need to modify the vop2 driver to set one Cluster window as primary > plane? I never used a Cluster window as primary plane. Sascha -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
Re: [PATCH v2 0/6] Allow drm_writeback_connector to accept pointer to drm_encoder
Hi Abhinav, On 16/03/2022 02:11, Abhinav Kumar wrote: There are some vendor drivers for which the writeback encoder shares hardware resources such as clocks and interrupts with the rest of the display pipeline. In addition, there can be use-cases where the writeback encoder could be a shared encoder between the physical display path and the writeback path. To accommodate for such cases, change the drm_writeback_connector to accept a pointer to drm_encoder. For existing users of drm_writeback_connector there will not be any change in functionality due to this change. This approach was first posted by Suraj Kandpal here [1] for both encoder and connector. But after discussions [2], the consensus was reached to split this change for the drm_encoder first and the drm_connector part can be reworked in a subsequent change later. Validation of this change was done using igt_writeback tests on MSM based RB5 board using the changes posted here [3]. For all other chipsets, these changes were compile-tested. [1] https://patchwork.kernel.org/project/dri-devel/patch/20220202081702.22119-1-suraj.kand...@intel.com/ [2] https://patchwork.kernel.org/project/dri-devel/patch/20220202085429.22261-6-suraj.kand...@intel.com/ [3] https://patchwork.freedesktop.org/series/99724/ changes in v2: - introduce a new API drm_writeback_connector_init_with_encoder() - allow passing possible_crtcs for existing users of drm_writeback_connector_init() Abhinav Kumar (6): drm: allow real encoder to be passed for drm_writeback_connector drm/komeda: pass possible_crtcs as parameter for drm_writeback_connector drm/vkms: pass possible_crtcs as parameter for drm_writeback_connector drm/vc4: change vc4 driver to use drm_writeback_connector_init_with_encoder() drm/rcar_du: pass possible_crtcs as parameter for drm_writeback_connector drm/malidp: pass possible_crtcs as parameter for drm_writeback_connector I think we expect that at each commit point the kernel should be compilable. Could you please squash patches accordingly? I'd suggest the following patch sequence: - Add possible_crtcs to the drm_writeback_connector_init() including all the driver changes (all drivers must be compilable, including vc4) - Add drm_writeback_connector_init_with_encoder() - Modify vc4 to use new API WDYT? .../drm/arm/display/komeda/komeda_wb_connector.c | 3 +- drivers/gpu/drm/arm/malidp_mw.c| 5 +- drivers/gpu/drm/drm_writeback.c| 144 +++-- drivers/gpu/drm/rcar-du/rcar_du_writeback.c| 5 +- drivers/gpu/drm/vc4/vc4_txp.c | 30 - drivers/gpu/drm/vkms/vkms_writeback.c | 3 +- include/drm/drm_writeback.h| 27 +++- 7 files changed, 161 insertions(+), 56 deletions(-) -- With best wishes Dmitry
[PATCH] drm/blend: fix typo in the comment
The documentation for drm_rotation_simplify() uses DRM_MODE_ROTATE_X,
while it's clear the the comment should mention DRM_MODE_REFLECT_X
instead. The example passes all flags except the DRM_MODE_REFLECT_X as
supported and expects to eliminate this flag.
Fixes: c2c446ad2943 ("drm: Add DRM_MODE_ROTATE_ and DRM_MODE_REFLECT_ to UAPI")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/drm_blend.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
index ec37cbfabb50..46ee5d5df6b4 100644
--- a/drivers/gpu/drm/drm_blend.c
+++ b/drivers/gpu/drm/drm_blend.c
@@ -317,7 +317,7 @@ EXPORT_SYMBOL(drm_plane_create_rotation_property);
* DRM_MODE_ROTATE_90 | DRM_MODE_ROTATE_180 |
* DRM_MODE_ROTATE_270 | DRM_MODE_REFLECT_Y);
*
- * to eliminate the DRM_MODE_ROTATE_X flag. Depending on what kind of
+ * to eliminate the DRM_MODE_REFLECT_X flag. Depending on what kind of
* transforms the hardware supports, this function may not
* be able to produce a supported transform, so the caller should
* check the result afterwards.
--
2.35.1
Re: [Intel-gfx] [PATCH 18/22] drm/i915: Use drm_mode_init() for on-stack modes
On Fri, 18 Feb 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Initialize on-stack modes with drm_mode_init() to guarantee
> no stack garbage in the list head, or that we aren't copying
> over another mode's list head.
>
> Based on the following cocci script, with manual fixups:
> @decl@
> identifier M;
> expression E;
> @@
> - struct drm_display_mode M = E;
> + struct drm_display_mode M;
>
> @@
> identifier decl.M;
> expression decl.E;
> statement S, S1;
> @@
> struct drm_display_mode M;
> ... when != S
> + drm_mode_init(&M, &E);
> +
> S1
>
> @@
> expression decl.E;
> @@
> - &*E
> + E
>
> Signed-off-by: Ville Syrjälä
I wonder if that cocci could be added to scripts/coccinelle or something
to detect anyone adding new ones?
Anyway,
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 740620ef07ad..74c5a99ab276 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -6898,8 +6898,9 @@ intel_crtc_update_active_timings(const struct
> intel_crtc_state *crtc_state)
> {
> struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> - struct drm_display_mode adjusted_mode =
> - crtc_state->hw.adjusted_mode;
> + struct drm_display_mode adjusted_mode;
> +
> + drm_mode_init(&adjusted_mode, &crtc_state->hw.adjusted_mode);
>
> if (crtc_state->vrr.enable) {
> adjusted_mode.crtc_vtotal = crtc_state->vrr.vmax;
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH 19/22] drm/i915: Use drm_mode_copy()
On Fri, 18 Feb 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> struct drm_display_mode embeds a list head, so overwriting
> the full struct with another one will corrupt the list
> (if the destination mode is on a list). Use drm_mode_copy()
> instead which explicitly preserves the list head of
> the destination mode.
>
> Even if we know the destination mode is not on any list
> using drm_mode_copy() seems decent as it sets a good
> example. Bad examples of not using it might eventually
> get copied into code where preserving the list head
> actually matters.
>
> Obviously one case not covered here is when the mode
> itself is embedded in a larger structure and the whole
> structure is copied. But if we are careful when copying
> into modes embedded in structures I think we can be a
> little more reassured that bogus list heads haven't been
> propagated in.
>
> @is_mode_copy@
> @@
> drm_mode_copy(...)
> {
> ...
> }
>
> @depends on !is_mode_copy@
> struct drm_display_mode *mode;
> expression E, S;
> @@
> (
> - *mode = E
> + drm_mode_copy(mode, &E)
> |
> - memcpy(mode, E, S)
> + drm_mode_copy(mode, E)
> )
>
> @depends on !is_mode_copy@
> struct drm_display_mode mode;
> expression E;
> @@
> (
> - mode = E
> + drm_mode_copy(&mode, &E)
> |
> - memcpy(&mode, E, S)
> + drm_mode_copy(&mode, E)
> )
>
> @@
> struct drm_display_mode *mode;
> @@
> - &*mode
> + mode
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 15 ++-
> 1 file changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 74c5a99ab276..661e36435793 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -5506,8 +5506,10 @@ intel_crtc_copy_uapi_to_hw_state_modeset(struct
> intel_atomic_state *state,
>
> crtc_state->hw.enable = crtc_state->uapi.enable;
> crtc_state->hw.active = crtc_state->uapi.active;
> - crtc_state->hw.mode = crtc_state->uapi.mode;
> - crtc_state->hw.adjusted_mode = crtc_state->uapi.adjusted_mode;
> + drm_mode_copy(&crtc_state->hw.mode,
> + &crtc_state->uapi.mode);
> + drm_mode_copy(&crtc_state->hw.adjusted_mode,
> + &crtc_state->uapi.adjusted_mode);
> crtc_state->hw.scaling_filter = crtc_state->uapi.scaling_filter;
>
> intel_crtc_copy_uapi_to_hw_state_nomodeset(state, crtc);
> @@ -5584,9 +5586,12 @@ copy_bigjoiner_crtc_state_modeset(struct
> intel_atomic_state *state,
> memset(&slave_crtc_state->hw, 0, sizeof(slave_crtc_state->hw));
> slave_crtc_state->hw.enable = master_crtc_state->hw.enable;
> slave_crtc_state->hw.active = master_crtc_state->hw.active;
> - slave_crtc_state->hw.mode = master_crtc_state->hw.mode;
> - slave_crtc_state->hw.pipe_mode = master_crtc_state->hw.pipe_mode;
> - slave_crtc_state->hw.adjusted_mode =
> master_crtc_state->hw.adjusted_mode;
> + drm_mode_copy(&slave_crtc_state->hw.mode,
> + &master_crtc_state->hw.mode);
> + drm_mode_copy(&slave_crtc_state->hw.pipe_mode,
> + &master_crtc_state->hw.pipe_mode);
> + drm_mode_copy(&slave_crtc_state->hw.adjusted_mode,
> + &master_crtc_state->hw.adjusted_mode);
> slave_crtc_state->hw.scaling_filter =
> master_crtc_state->hw.scaling_filter;
>
> copy_bigjoiner_crtc_state_nomodeset(state, slave_crtc);
--
Jani Nikula, Intel Open Source Graphics Center
Re: [PATCH] drm/blend: fix typo in the comment
Reviewed-by: Simon Ser
Re: [PATCH v8 08/16] drm/meson: dw-hdmi: Don't open code devm_clk_get_enabled()
On 14/03/2022 15:16, Uwe Kleine-König wrote:
devm_clk_get_enabled() returns a clock prepared and enabled and already
registers a devm exit handler to disable (and unprepare) the clock.
There is slight change in behavior as a failure to enable the clock
now results in an error message, too. Also the actual error code is added
to the message.
Signed-off-by: Uwe Kleine-König
---
drivers/gpu/drm/meson/meson_dw_hdmi.c | 48 +--
1 file changed, 16 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c
b/drivers/gpu/drm/meson/meson_dw_hdmi.c
index 5cd2b2ebbbd3..6034e80c5b2e 100644
--- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
+++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
@@ -670,29 +670,6 @@ static void meson_disable_regulator(void *data)
regulator_disable(data);
}
-static void meson_disable_clk(void *data)
-{
- clk_disable_unprepare(data);
-}
-
-static int meson_enable_clk(struct device *dev, char *name)
-{
- struct clk *clk;
- int ret;
-
- clk = devm_clk_get(dev, name);
- if (IS_ERR(clk)) {
- dev_err(dev, "Unable to get %s pclk\n", name);
- return PTR_ERR(clk);
- }
-
- ret = clk_prepare_enable(clk);
- if (!ret)
- ret = devm_add_action_or_reset(dev, meson_disable_clk, clk);
-
- return ret;
-}
-
static int meson_dw_hdmi_bind(struct device *dev, struct device *master,
void *data)
{
@@ -702,6 +679,7 @@ static int meson_dw_hdmi_bind(struct device *dev, struct
device *master,
struct drm_device *drm = data;
struct meson_drm *priv = drm->dev_private;
struct dw_hdmi_plat_data *dw_plat_data;
+ struct clk *clk;
int irq;
int ret;
@@ -763,17 +741,23 @@ static int meson_dw_hdmi_bind(struct device *dev, struct device *master,
if (IS_ERR(meson_dw_hdmi->hdmitx))
return PTR_ERR(meson_dw_hdmi->hdmitx);
- ret = meson_enable_clk(dev, "isfr");
- if (ret)
- return ret;
+ clk = devm_clk_get_enabled(dev, "isfr");
+ if (IS_ERR(clk)) {
+ dev_err(dev, "Failed to get enabled isfr pclk (%pe)\n", clk);
+ return PTR_ERR(clk);
+ }
- ret = meson_enable_clk(dev, "iahb");
- if (ret)
- return ret;
+ clk = devm_clk_get_enabled(dev, "iahb");
+ if (IS_ERR(clk)) {
+ dev_err(dev, "Failed to get enabled iahb pclk (%pe)\n", clk);
+ return PTR_ERR(clk);
+ }
- ret = meson_enable_clk(dev, "venci");
- if (ret)
- return ret;
+ clk = devm_clk_get_enabled(dev, "venci");
+ if (IS_ERR(clk)) {
+ dev_err(dev, "Failed to get enabled venci pclk (%pe)\n", clk);
+ return PTR_ERR(clk);
+ }
dw_plat_data->regm = devm_regmap_init(dev, NULL, meson_dw_hdmi,
&meson_dw_hdmi_regmap_config);
Acked-by: Neil Armstrong
Re: (subset) [PATCH] drm/blend: fix typo in the comment
On Wed, 16 Mar 2022 10:46:48 +0300, Dmitry Baryshkov wrote: > The documentation for drm_rotation_simplify() uses DRM_MODE_ROTATE_X, > while it's clear the the comment should mention DRM_MODE_REFLECT_X > instead. The example passes all flags except the DRM_MODE_REFLECT_X as > supported and expects to eliminate this flag. > > Applied to drm/drm-misc (drm-misc-next). Thanks! Maxime
Re: [PATCH v7 00/12] clk: Improve clock range handling
Hi, On Fri, Mar 11, 2022 at 07:08:39PM -0800, Stephen Boyd wrote: > Quoting Maxime Ripard (2022-02-25 06:35:22) > > Hi, > > > > This is a follow-up of the discussion here: > > https://lore.kernel.org/linux-clk/20210319150355.xzw7ikwdaga2dwhv@gilmour/ > > > > and here: > > https://lore.kernel.org/all/20210914093515.260031-1-max...@cerno.tech/ > > > > While the initial proposal implemented a new API to temporarily raise and > > lower > > clock rates based on consumer workloads, Stephen suggested an > > alternative approach implemented here. > > > > The main issue that needed to be addressed in our case was that in a > > situation where we would have multiple calls to clk_set_rate_range, we > > would end up with a clock at the maximum of the minimums being set. This > > would be expected, but the issue was that if one of the users was to > > relax or drop its requirements, the rate would be left unchanged, even > > though the ideal rate would have changed. > > > > So something like > > > > clk_set_rate(user1_clk, 1000); > > clk_set_min_rate(user1_clk, 2000); > > clk_set_min_rate(user2_clk, 3000); > > clk_set_min_rate(user2_clk, 1000); > > > > Would leave the clock running at 3000Hz, while the minimum would now be > > 2000Hz. > > > > This was mostly due to the fact that the core only triggers a rate > > change in clk_set_rate_range() if the current rate is outside of the > > boundaries, but not if it's within the new boundaries. > > > > That series changes that and will trigger a rate change on every call, > > with the former rate being tried again. This way, providers have a > > chance to follow whatever policy they see fit for a given clock each > > time the boundaries change. > > > > This series also implements some kunit tests, first to test a few rate > > related functions in the CCF, and then extends it to make sure that > > behaviour has some test coverage. > > > > Let me know what you think > > Thanks. I'm going to apply this to clk-next but not the last two drm > patches. That is OK? Yes, that will be perfect, thanks! Maxime signature.asc Description: PGP signature
[PATCH] drm/amdgpu: fix off by one in amdgpu_gfx_kiq_acquire()
This post-op should be a pre-op so that we do not pass -1 as the bit
number to test_bit(). The current code will loop downwards from 63 to
-1. After changing to a pre-op, it loops from 63 to 0.
Fixes: 71c37505e7ea ("drm/amdgpu/gfx: move more common KIQ code to
amdgpu_gfx.c")
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
index 8fe939976224..28a736c507bb 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
@@ -266,7 +266,7 @@ static int amdgpu_gfx_kiq_acquire(struct amdgpu_device
*adev,
* adev->gfx.mec.num_pipe_per_mec
* adev->gfx.mec.num_queue_per_pipe;
- while (queue_bit-- >= 0) {
+ while (--queue_bit >= 0) {
if (test_bit(queue_bit, adev->gfx.mec.queue_bitmap))
continue;
--
2.20.1
Re: [PATCH v2 1/2] drm: Add GPU reset sysfs event
On Tue, 15 Mar 2022 10:54:38 -0400 Alex Deucher wrote: > On Mon, Mar 14, 2022 at 11:26 AM Pekka Paalanen wrote: > > > > On Mon, 14 Mar 2022 10:23:27 -0400 > > Alex Deucher wrote: > > > > > On Fri, Mar 11, 2022 at 3:30 AM Pekka Paalanen > > > wrote: > > > > > > > > On Thu, 10 Mar 2022 11:56:41 -0800 > > > > Rob Clark wrote: > > > > > > > > > For something like just notifying a compositor that a gpu crash > > > > > happened, perhaps drm_event is more suitable. See > > > > > virtio_gpu_fence_event_create() for an example of adding new event > > > > > types. Although maybe you want it to be an event which is not device > > > > > specific. This isn't so much of a debugging use-case as simply > > > > > notification. > > > > > > > > Hi, > > > > > > > > for this particular use case, are we now talking about the display > > > > device (KMS) crashing or the rendering device (OpenGL/Vulkan) crashing? > > > > > > > > If the former, I wasn't aware that display device crashes are a thing. > > > > How should a userspace display server react to those? > > > > > > > > If the latter, don't we have EGL extensions or Vulkan API already to > > > > deliver that? > > > > > > > > The above would be about device crashes that directly affect the > > > > display server. Is that the use case in mind here, or is it instead > > > > about notifying the display server that some application has caused a > > > > driver/hardware crash? If the latter, how should a display server react > > > > to that? Disconnect the application? > > > > > > > > Shashank, what is the actual use case you are developing this for? > > > > > > > > I've read all the emails here so far, and I don't recall seeing it > > > > explained. > > > > > > > > > > The idea is that a support daemon or compositor would listen for GPU > > > reset notifications and do something useful with them (kill the guilty > > > app, restart the desktop environment, etc.). Today when the GPU > > > resets, most applications just continue assuming nothing is wrong, > > > meanwhile the GPU has stopped accepting work until the apps re-init > > > their context so all of their command submissions just get rejected. > > > > > > > Btw. somewhat relatedly, there has been work aiming to allow > > > > graceful hot-unplug of DRM devices. There is a kernel doc outlining how > > > > the various APIs should react towards userspace when a DRM device > > > > suddenly disappears. That seems to have some overlap here IMO. > > > > > > > > See > > > > https://www.kernel.org/doc/html/latest/gpu/drm-uapi.html#device-hot-unplug > > > > which also has a couple pointers to EGL and Vulkan APIs. > > > > > > The problem is most applications don't use the GL or VK robustness > > > APIs. > > > > Hi, > > > > how would this new event help with that? > > This event would provide notification that a GPU reset occurred. > > > > > I mean, yeah, there could be a daemon that kills those GPU users, but > > then what? You still lose any unsaved work, and may need to manually > > restart them. > > > > Is the idea that it is better to have the app crash and disappear than > > to look like it froze while it otherwise still runs? > > Yes. Ok. That was just a wild guess. > The daemon could also send the user some sort of notification > that a GPU reset occurred. > > > > > If some daemon or compositor goes killing apps that trigger GPU resets, > > then how do we stop that for an app that actually does use the > > appropriate EGL or Vulkan APIs to detect and remedy that situation > > itself? > > I guess the daemon could keep some sort of whitelist. OTOH, very few > if any applications, especially games actually support these > extensions. I would think that a white-list is a non-starter due to the maintenance nightmare and the "wrong by default" design for well behaving programs. I am not a fan of optimising for broken software. I understand that with games this is routine, but we're talking about everything here, not just games. Games cannot be fixed, but the rest could if the problem was not sweeped under the rug. It's like the inverse of the platform problem. > > > You could use something like that in the compositor, but those > > > APIs tend to be focused more on the application itself rather than the > > > GPU in general. E.g., Is my context lost. Which is fine for > > > restarting your context, but doesn't really help if you want to try > > > and do something with another application (i.e., the likely guilty > > > app). Also, on dGPU at least, when you reset the GPU, vram is usually > > > lost (either due to the memory controller being reset, or vram being > > > zero'd on init due to ECC support), so even if you are not the guilty > > > process, in that case you'd need to re-init your context anyway. > > > > Why should something like a compositor listen for this and kill apps > > that triggered GPU resets, instead of e.g. Mesa noticing that in the app > > and killing itself? Mesa i
Re: [Intel-gfx] [PATCH v3 2/3] drm/i915/gem: Remove logic for wbinvd_on_all_cpus
Hi, Michael, others.
This is the response from Linus last time we copied that already
pre-existing wbinvd_on_all_cpus() macro to another place in the driver:
https://lists.freedesktop.org/archives/dri-devel/2021-November/330928.html
My first interpretation of this is that even if there currently are
similar patterns in drm_cache.c, we shouldn't introduce more,
encouraging other drivers to use incoherent IO.
Other than that I think we should move whatever wbinvds we can over to
the ranged versions, unless that is proven to be a performance drop.
Finally for any wbinvds left in our driver, ensure that they are never
executed for any gpu where we provide full coherency. That is all
discrete gpus (and to be discussed integrated gpus moving forward).
Might be that drm maintainers want to chime in here with other views.
Thanks,
Thomas
On 3/15/22 17:59, Michael Cheng wrote:
+Daniel for additional feedback!
On 2022-03-14 4:06 p.m., Michael Cheng wrote:
On 2022-03-08 10:58 a.m., Lucas De Marchi wrote:
On Tue, Feb 22, 2022 at 08:24:31PM +0100, Thomas Hellström (Intel)
wrote:
Hi, Michael,
On 2/22/22 18:26, Michael Cheng wrote:
This patch removes logic for wbinvd_on_all_cpus and brings in
drm_cache.h. This header has the logic that outputs a warning
when wbinvd_on_all_cpus when its being used on a non-x86 platform.
Signed-off-by: Michael Cheng
Linus has been pretty clear that he won't accept patches that add
macros that works on one arch and warns on others anymore in i915
and I figure even less so in drm code.
So we shouldn't try to move this out to drm. Instead we should
restrict the wbinvd() inside our driver to integrated and X86 only.
For discrete on all architectures we should be coherent and hence
not be needing wbinvd().
the warn is there to guarantee we don't forget a code path. However
simply adding the warning is the real issue: we should rather guarantee
we can't take that code path. I.e., as you said refactor the code to
guarantee it works on discrete without that logic.
$ git grep wbinvd_on_all_cpus -- drivers/gpu/drm/
drivers/gpu/drm/drm_cache.c: if (wbinvd_on_all_cpus())
drivers/gpu/drm/drm_cache.c: if (wbinvd_on_all_cpus())
drivers/gpu/drm/drm_cache.c: if (wbinvd_on_all_cpus())
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c: * Currently we
just do a heavy handed wbinvd_on_all_cpus() here since
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c: wbinvd_on_all_cpus();
It looks like we actually go through this on other discrete
graphics. Is
this missing an update like s/IS_DG1/IS_DGFX/? Or should we be doing
something else?
drivers/gpu/drm/i915/gem/i915_gem_pm.c:#define
wbinvd_on_all_cpus() \
drivers/gpu/drm/i915/gem/i915_gem_pm.c: wbinvd_on_all_cpus();
Those are for suspend. Revert ac05a22cd07a ("drm/i915/gem:
Almagamate clflushes on suspend")
or extract that part to a helper function and implement it differently
for arches != x86?
drivers/gpu/drm/i915/gem/i915_gem_pm.c: wbinvd_on_all_cpus();
Probably take a similar approach to the suspend case?
drivers/gpu/drm/i915/gt/intel_ggtt.c: wbinvd_on_all_cpus();
For a helper function, I have a #define for all non x86 architecture
that gives a warn on [1] within drm_cache.h Or would it be better to
implement a helper function instead?
[1]. https://patchwork.freedesktop.org/patch/475750/?series=1&rev=5
This one comes from 64b95df91f44 ("drm/i915: Assume exclusive access
to objects inside resume")
Shouldn't that be doing the invalidate if the write domain is
I915_GEM_DOMAIN_CPU
In the end I think the warning would be ok if it was the cherry on top,
to guarantee we don't take those paths. We should probably have a
warn_once() to avoid spamming the console. But we also have to rework
the code to guarantee we are the only ones who may eventually get that
warning, and not the end user.
Could we first add the helper function/#define for now, and rework
the code in a different patch series?
Lucas De Marchi
Thanks,
/Thomas
Re: Parallel modesets and private state objects broken, where to go with MST?
On Mon, 14 Mar 2022 18:16:36 -0400 Lyude Paul wrote: > So, the actual problem: following a conversation with Daniel Vetter today I've > gotten the impression that private modesetting objects are basically just > broken with parallel modesets? I'm still wrapping my head around all of this > honestly, but from what I've gathered: CRTC atomic infra knows how to do waits > in the proper places for when other CRTCs need to be waited on to continue a > modeset, but there's no such tracking with private objects. If I understand > this correctly, that means that even if two CRTC modesets require pulling in > the same private object state for the MST mgr: we're only provided a guarantee > that the atomic checks pulling in that private object state won't > concurrently. But when it comes to commits, it doesn't sound like there's any > actual tracking for this and as such - two CRTC modesets which have both > pulled in the MST private state object are not prevented from running > concurrently. > > This unfortunately throws an enormous wrench into the MST atomic conversion > I've been working on - as I was under the understanding while writing the code > for this that all objects in an atomic state are blocked from being used in > any new atomic commits (not checks, as parallel checks should be fine in my > case) until there's no commits active with said object pulled into the atomic > state. I certainly am not aware of any way parallel modesetting could actually > be supported on MST, so it's not really a feature we want to deal with at all > besides stopping it from happening. This also unfortunately means that the > current atomic modesetting code we have for MST is potentially broken, > although I assume we've never hit any real world issues with it because of the > non-atomic locking we currently have for the payload table. > > So, Daniel had mentioned that supposedly you've been dealing with similar > issues with VC4 and might have already made progress on coming up with ways to > deal with it. If this is all correct, I'd definitely appreciate being able to > take a look at your work on this to see how I can help move things forward. > I've got a WIP of my atomic only MST branch as well: > > https://gitlab.freedesktop.org/lyudess/linux/-/commits/wip/mst-atomic-only-v1 > > However it's very certainly broken right now (it compiles and I had thought it > worked already, but I realized I totally forgot to come up with a way of doing > bookkeeping for VC start slots atomically - which is what led me down this > current rabbit hole), but it should at least give a general idea of what I'm > trying to do. > > Anyway, let me know what you think. Hi Lyude, as mentioned in IRC, I believe parallel atomic modesets on separate CRTCs have very limited use, so serialising them in the kernel is good. Any userspace that wants to reliably program more than one CRTC will collect all CRTCs into the same atomic commit. The reason is that userspace does TEST_ONLY commits first to see if things will work, and then do the real commit. If some other commit lands in between, then the test results are invalid and would need to be re-done. So parallel modesets are a gamble at best. However, parallel modesets are not just an attack vector, they can happen accidentally through DRM leasing. With DRM leasing, the DRM master gives access to some CRTC to another process, which will be doing modesets of its own. These two processes will race each other, not having any idea what the other one is doing or when. Thanks, pq pgpTwCyhwjFWo.pgp Description: OpenPGP digital signature
Re: [PATCH v8 09/24] drm/rockchip: dw_hdmi: Add support for niu clk
On Mon, Mar 14, 2022 at 08:54:27PM +0300, Dmitry Osipenko wrote: > On 3/14/22 11:18, Sascha Hauer wrote: > > On Sun, Mar 13, 2022 at 12:07:56AM +0300, Dmitry Osipenko wrote: > >> On 3/11/22 11:33, Sascha Hauer wrote: > >>> The rk3568 HDMI has an additional clock that needs to be enabled for the > >>> HDMI controller to work. This clock is not needed for the HDMI > >>> controller itself, but to make the SoC internal bus logic work. From the > >>> reference manual: > >>> > 2.8.6 NIU Clock gating reliance > > A part of niu clocks have a dependence on another niu clock in order to > sharing the internal bus. When these clocks are in use, another niu > clock must be opened, and cannot be gated. These clocks and the special > clock on which they are relied are as following: > > Clocks which have dependency The clock which can not be gated > - > ... > pclk_vo_niu, hclk_vo_s_niu hclk_vo_niu > ... > >>> The clock framework does not support turning on a clock whenever another > >>> clock is turned on, so this patch adds support for the dependent clock > >>> to the HDMI driver. We call it "NIU", which is for "Native Interface > >>> Unit" > >> > >> This still doesn't make sense to me. You're saying that "pclk_vo_niu, > >> hclk_vo_s_niu" depend on "hclk_vo_niu", but HDMI doesn't use pclk_vo, it > >> uses pclk_hdmi. > > > > pclk_hdmi_host is a child clock of pclk_vo: > > > > aclk_vo 220 3 0 > > 0 5 Y > > aclk_hdcp 000 3 0 > > 0 5 N > > pclk_vo 2307500 0 > > 0 5 Y > >pclk_edp_ctrl 0007500 0 > > 0 5 N > >pclk_dsitx_1 0007500 0 > > 0 5 N > >pclk_dsitx_0 1207500 0 > > 0 5 Y > >pclk_hdmi_host 1207500 0 > > 0 5 Y > >pclk_hdcp 0007500 0 > > 0 5 N > > hclk_vo 250 15000 0 > > 0 5 Y > >hclk_hdcp 000 15000 0 > > 0 5 N > >hclk_vop 020 15000 0 > > 0 5 N > > It was unclear that the pclk_hdmi is the child of pclk_vo by looking at > the clk driver's code, thank you! > > Won't be better if the implicit clk dependency would be handled > internally by the RK clk driver? I have considered handling something like coupled clocks in the clock framework, but I have not yet considered handling this internally in the Rockchip clock driver. I just had a quick look at the driver. While it sounds like an easy task to enable gate A whenever gate B is enabled I haven't found a good way to integrate that into the clk driver. It seems to me that it's not easier to implement in the clk driver than it is to implement it in the clk framework where it could be used by others as well. > For example, by making the common gate > shared/refcounted. Have you considered this variant? Then we won't need > to change the DT bindings. For the DT bindings it is just an additional clock. Should we have a better way to handle that case in the future we could simply ignore the additional clock. I wouldn't bother too much about this. Sascha -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
Re: [PATCH v4 00/24] DEPT(Dependency Tracker)
On Wed, Mar 16, 2022 at 01:32:13PM +0900, Byungchul Park wrote: > On Sat, Mar 12, 2022 at 01:53:26AM +, Hyeonggon Yoo wrote: > > On Fri, Mar 04, 2022 at 04:06:19PM +0900, Byungchul Park wrote: > > > Hi Linus and folks, > > > > > > I've been developing a tool for detecting deadlock possibilities by > > > tracking wait/event rather than lock(?) acquisition order to try to > > > cover all synchonization machanisms. It's done on v5.17-rc1 tag. > > > > > > https://github.com/lgebyungchulpark/linux-dept/commits/dept1.14_on_v5.17-rc1 > > > > > > > Small feedback unrelated to thread: > > I'm not sure "Need to expand the ring buffer" is something to call > > WARN(). Is this stack trace useful for something? > > > > > > Hello Byungchul. These are two warnings of DEPT on system. > > Hi Hyeonggon, > > Could you run scripts/decode_stacktrace.sh and share the result instead > of the raw format below if the reports still appear with PATCH v5? It'd > be appreciated (: > Hi Byungchul. on dept1.18_on_v5.17-rc7, the kernel_clone() warning has gone. There is one warning remaining on my system: It warns when running kunit-try-catch-test testcase. === DEPT: Circular dependency has been detected. 5.17.0-rc7+ #4 Not tainted --- summary --- *** AA DEADLOCK *** context A [S] (unknown)(&try_completion:0) [W] wait_for_completion_timeout(&try_completion:0) [E] complete(&try_completion:0) [S]: start of the event context [W]: the wait blocked [E]: the event not reachable --- context A's detail --- context A [S] (unknown)(&try_completion:0) [W] wait_for_completion_timeout(&try_completion:0) [E] complete(&try_completion:0) [S] (unknown)(&try_completion:0): (N/A) [W] wait_for_completion_timeout(&try_completion:0): kunit_try_catch_run (lib/kunit/try-catch.c:78 (discriminator 1)) stacktrace: dept_wait (kernel/dependency/dept.c:2149) wait_for_completion_timeout (kernel/sched/completion.c:119 (discriminator 4) kernel/sched/completion.c:165 (discriminator 4)) kunit_try_catch_run (lib/kunit/try-catch.c:78 (discriminator 1)) kunit_test_try_catch_successful_try_no_catch (lib/kunit/kunit-test.c:43) kunit_try_run_case (lib/kunit/test.c:333 lib/kunit/test.c:374) kunit_generic_run_threadfn_adapter (lib/kunit/try-catch.c:30) kthread (kernel/kthread.c:379) ret_from_fork (arch/arm64/kernel/entry.S:757) [E] complete(&try_completion:0): kthread_complete_and_exit (kernel/kthread.c:327) stacktrace: dept_event (kernel/dependency/dept.c:2376 (discriminator 2)) complete (kernel/sched/completion.c:33 (discriminator 4)) kthread_complete_and_exit (kernel/kthread.c:327) kunit_try_catch_throw (lib/kunit/try-catch.c:18) kthread (kernel/kthread.c:379) ret_from_fork (arch/arm64/kernel/entry.S:757) --- information that might be helpful --- Hardware name: linux,dummy-virt (DT) Call trace: dump_backtrace.part.0 (arch/arm64/kernel/stacktrace.c:186) show_stack (arch/arm64/kernel/stacktrace.c:193) dump_stack_lvl (lib/dump_stack.c:107 (discriminator 4)) dump_stack (lib/dump_stack.c:114) print_circle (./arch/arm64/include/asm/atomic_ll_sc.h:112 ./arch/arm64/include/asm/atomic.h:30 ./include/linux/atomic/atomic-arch-fallback.h:511 ./include/linux/atomic/atomic-instrumented.h:258 kernel/dependency/dept.c:140 kernel/dependency/dept.c:748) cb_check_dl (kernel/dependency/dept.c:1083 kernel/dependency/dept.c:1064) bfs (kernel/dependency/dept.c:833) add_dep (kernel/dependency/dept.c:1409) do_event (kernel/dependency/dept.c:175 kernel/dependency/dept.c:1644) dept_event (kernel/dependency/dept.c:2376 (discriminator 2)) complete (kernel/sched/completion.c:33 (discriminator 4)) kthread_complete_and_exit (kernel/kthread.c:327) kunit_try_catch_throw (lib/kunit/try-catch.c:18) kthread (kernel/kthread.c:379) ret_from_fork (arch/arm64/kernel/entry.S:757) -- Thank you, You are awesome! Hyeonggon :-) > https://lkml.org/lkml/2022/3/15/1277 > (or > https://github.com/lgebyungchulpark/linux-dept/commits/dept1.18_on_v5.17-rc7) > > Thank you very much! > > -- > Byungchul > > > Both cases look similar. > > > > In what case DEPT says (unknown)? > > I'm not sure we can properly debug this. > > > > === > > DEPT: Circular dependency has been detected. > > 5.17.0-rc1+ #3 Tainted: GW > > --- > > summary > > --- > > *** AA DEADLOCK *** > > > > context A > > [S] (unknown)(&vfork:0) > > [W] wait_for_completion_killable(&vfork:0) > > [E] complete(&vfork:0) > > > > [S]: start of the event context > > [W]: the wait blocked > > [E]: the event
Re: [PATCH v2] drm: Fix a infinite loop condition when order becomes 0
Am 16.03.22 um 07:34 schrieb Arunpravin Paneer Selvam:
handle a situation in the condition order-- == min_order,
when order = 0 and min_order = 0, leading to order = -1,
it now won't exit the loop. To avoid this problem,
added a order check in the same condition, (i.e)
when order is 0, we return -ENOSPC
v2: use full name in email program and in Signed-off tag
Signed-off-by: Arunpravin Paneer Selvam
Acked-by: Christian König
BTW while going over the code I've seen this here in the function:
...
if (!pages)
break;
} while (1);
Can that be changed to "} while (pages);" instead? Would probably be a
little bit cleaner.
Regards,
Christian.
---
drivers/gpu/drm/drm_buddy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index 72f52f293249..5ab66aaf2bbd 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -685,7 +685,7 @@ int drm_buddy_alloc_blocks(struct drm_buddy *mm,
if (!IS_ERR(block))
break;
- if (order-- == min_order) {
+ if (!order || order-- == min_order) {
err = -ENOSPC;
goto err_free;
}
base-commit: 3bd60c0259406c5ca3ce5cdc958fb910ad4b8175
Re: [RFC PATCH 5/7] drm/ttm: add range busy check for range manager
Am 15.03.22 um 19:04 schrieb Robert Beckett:
RFC: do we want this to become a generic interface in
ttm_resource_manager_func?
RFC: would we prefer a different interface? e.g.
for_each_resource_in_range or for_each_bo_in_range
Well completely NAK to that. Why do you need that?
The long term goal is to completely remove the range checks from TTM
instead.
Regards,
Christian.
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/ttm/ttm_range_manager.c | 21 +
include/drm/ttm/ttm_range_manager.h | 3 +++
2 files changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/ttm/ttm_range_manager.c
b/drivers/gpu/drm/ttm/ttm_range_manager.c
index 8cd4f3fb9f79..5662627bb933 100644
--- a/drivers/gpu/drm/ttm/ttm_range_manager.c
+++ b/drivers/gpu/drm/ttm/ttm_range_manager.c
@@ -206,3 +206,24 @@ int ttm_range_man_fini_nocheck(struct ttm_device *bdev,
return 0;
}
EXPORT_SYMBOL(ttm_range_man_fini_nocheck);
+
+/**
+ * ttm_range_man_range_busy - Check whether anything is allocated with a range
+ *
+ * @man: memory manager to check
+ * @fpfn: first page number to check
+ * @lpfn: last page number to check
+ *
+ * Return: true if anything allocated within the range, false otherwise.
+ */
+bool ttm_range_man_range_busy(struct ttm_resource_manager *man,
+ unsigned fpfn, unsigned lpfn)
+{
+ struct ttm_range_manager *rman = to_range_manager(man);
+ struct drm_mm *mm = &rman->mm;
+
+ if (__drm_mm_interval_first(mm, PFN_PHYS(fpfn), PFN_PHYS(lpfn + 1) - 1))
+ return true;
+ return false;
+}
+EXPORT_SYMBOL(ttm_range_man_range_busy);
diff --git a/include/drm/ttm/ttm_range_manager.h
b/include/drm/ttm/ttm_range_manager.h
index 7963b957e9ef..86794a3f9101 100644
--- a/include/drm/ttm/ttm_range_manager.h
+++ b/include/drm/ttm/ttm_range_manager.h
@@ -53,4 +53,7 @@ static __always_inline int ttm_range_man_fini(struct
ttm_device *bdev,
BUILD_BUG_ON(__builtin_constant_p(type) && type >= TTM_NUM_MEM_TYPES);
return ttm_range_man_fini_nocheck(bdev, type);
}
+
+bool ttm_range_man_range_busy(struct ttm_resource_manager *man,
+ unsigned fpfn, unsigned lpfn);
#endif
Re: [Intel-gfx] [PATCH] drm/i915: avoid concurrent writes to aux_inv
On 04/03/2022 22:14, fei.y...@intel.com wrote:
From: Fei Yang
GPU hangs have been observed when multiple engines write to the
same aux_inv register at the same time. To avoid this each engine
should only invalidate its own auxiliary table. The function
gen12_emit_flush_xcs() currently invalidate the auxiliary table for
all engines because the rq->engine is not necessarily the engine
eventually carrying out the request, and potentially the engine
could even be a virtual one (with engine->instance being -1).
With this patch, auxiliary table invalidation is done only for the
engine executing the request. And the mmio address for the aux_inv
register is set after the engine instance becomes certain.
Signed-off-by: Chris Wilson
Signed-off-by: Fei Yang
---
drivers/gpu/drm/i915/gt/gen2_engine_cs.c | 9 +++
drivers/gpu/drm/i915/gt/gen6_engine_cs.c | 9 +++
drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 61 ---
.../drm/i915/gt/intel_execlists_submission.c | 35 +++
drivers/gpu/drm/i915/i915_request.h | 2 +
5 files changed, 82 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/gen2_engine_cs.c
b/drivers/gpu/drm/i915/gt/gen2_engine_cs.c
index 1c82caf525c3..0ec4986e4805 100644
--- a/drivers/gpu/drm/i915/gt/gen2_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen2_engine_cs.c
@@ -37,6 +37,9 @@ int gen2_emit_flush(struct i915_request *rq, u32 mode)
intel_ring_advance(rq, cs);
+ /* hsdes: 1809175790. No fixup needed for gen2 */
+ rq->aux_inv_fixup = NULL;
Same thing that Stuart mentioned - would it not work for instance to
initialize this in __i915_request_create?
+
return 0;
}
@@ -123,6 +126,9 @@ int gen4_emit_flush_rcs(struct i915_request *rq, u32 mode)
intel_ring_advance(rq, cs);
+ /* hsdes: 1809175790. No fixup needed for gen4 rcs */
+ rq->aux_inv_fixup = NULL;
+
return 0;
}
@@ -138,6 +144,9 @@ int gen4_emit_flush_vcs(struct i915_request *rq, u32 mode)
*cs++ = MI_NOOP;
intel_ring_advance(rq, cs);
+ /* hsdes: 1809175790. No fixup needed for gen4 vcs */
+ rq->aux_inv_fixup = NULL;
+
return 0;
}
diff --git a/drivers/gpu/drm/i915/gt/gen6_engine_cs.c b/drivers/gpu/drm/i915/gt/gen6_engine_cs.c
index 5e65550b4dfb..efe51c4662fe 100644
--- a/drivers/gpu/drm/i915/gt/gen6_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen6_engine_cs.c
@@ -137,6 +137,9 @@ int gen6_emit_flush_rcs(struct i915_request *rq, u32 mode)
*cs++ = 0;
intel_ring_advance(rq, cs);
+ /* hsdes: 1809175790. No fixup needed for gen6 */
+ rq->aux_inv_fixup = NULL;
+
return 0;
}
@@ -208,6 +211,9 @@ static int mi_flush_dw(struct i915_request *rq, u32 flags)
intel_ring_advance(rq, cs);
+ /* hsdes: 1809175790. No fixup needed for gen6 */
+ rq->aux_inv_fixup = NULL;
+
return 0;
}
@@ -347,6 +353,9 @@ int gen7_emit_flush_rcs(struct i915_request *rq, u32 mode)
*cs++ = 0;
intel_ring_advance(rq, cs);
+ /* hsdes: 1809175790. No fixup needed for gen7 rcs */
+ rq->aux_inv_fixup = NULL;
+
return 0;
}
diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index b1b9c3fd7bf9..b6374cf53314 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -73,6 +73,9 @@ int gen8_emit_flush_rcs(struct i915_request *rq, u32 mode)
intel_ring_advance(rq, cs);
+ /* hsdes: 1809175790. No fixup needed for gen8 rcs */
+ rq->aux_inv_fixup = NULL;
+
return 0;
}
@@ -106,6 +109,9 @@ int gen8_emit_flush_xcs(struct i915_request *rq, u32 mode)
*cs++ = 0; /* value */
intel_ring_advance(rq, cs);
+ /* hsdes: 1809175790. No fixup needed for gen8 xcs */
+ rq->aux_inv_fixup = NULL;
+
return 0;
}
@@ -157,6 +163,9 @@ int gen11_emit_flush_rcs(struct i915_request *rq, u32 mode)
intel_ring_advance(rq, cs);
}
+ /* hsdes: 1809175790. No fixup needed for gen11 rcs */
+ rq->aux_inv_fixup = NULL;
+
return 0;
}
@@ -165,30 +174,6 @@ static u32 preparser_disable(bool state)
return MI_ARB_CHECK | 1 << 8 | state;
}
-static i915_reg_t aux_inv_reg(const struct intel_engine_cs *engine)
-{
- static const i915_reg_t vd[] = {
- GEN12_VD0_AUX_NV,
- GEN12_VD1_AUX_NV,
- GEN12_VD2_AUX_NV,
- GEN12_VD3_AUX_NV,
- };
-
- static const i915_reg_t ve[] = {
- GEN12_VE0_AUX_NV,
- GEN12_VE1_AUX_NV,
- };
-
- if (engine->class == VIDEO_DECODE_CLASS)
- return vd[engine->instance];
-
- if (engine->class == VIDEO_ENHANCEMENT_CLASS)
- return ve[engine->instance];
-
- GEM_BUG_ON("unknown aux_inv reg\n");
- return INVALID_MMIO_REG;
-}
-
static u32 *gen12_emit_aux_table_inv(const i915_reg_t inv_
Re: [PATCH 1/2] drm: mediatek: mtk_drm_plane: Use kmalloc in mtk_plane_duplicate_state
Il 25/01/22 17:36, Chun-Kuang Hu ha scritto: Hi, AngeloGioacchino: AngeloGioacchino Del Regno 於 2022年1月18日 週二 下午9:38寫道： There is no need to zero out the newly allocated memory because we are duplicating all members of struct mtk_plane_state: switch to kmalloc to save some overhead. Reviewed-by: Chun-Kuang Hu Signed-off-by: AngeloGioacchino Del Regno --- drivers/gpu/drm/mediatek/mtk_drm_plane.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Hello, this series was sent and reviewed two months ago, but it hasn't been picked in any maintainer tree. This is a friendly ping to not let these two patches to be lost and forgotten. Cheers, Angelo
RE: [PATCH] WIP: drm/dp_mst: Add support for dumping topology ref histories from debugfs
[Public] > -Original Message- > From: Lyude Paul > Sent: Wednesday, March 16, 2022 8:48 AM > To: Lin, Wayne > Cc: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org > Subject: Re: [PATCH] WIP: drm/dp_mst: Add support for dumping topology ref > histories from debugfs > > (Adding this back to the dri-devel mailing list since I didn't notice it got > dropped from there) > > Hm, some comments on this issue down below. Sorry for the delayed response, I > was going to try this right after I finished the MST legacy removal but that's > ending up taking longer than I hoped. > > On Tue, 2022-03-08 at 01:46 +, Lin, Wayne wrote: > > [AMD Official Use Only] > > > > Oops... > > I didn't notice that I replied to wrong mail previously : P > > Sorry for the confusion and reply to the correct thread. > > > > Good day! > > I probably know why you can't reproduce the issue there. Please refer to the > > attached > > patch file which makes me easier to explain this. > > > > In dm_dp_mst_get_modes(), we will create a new dc_sink by calling > > dc_link_add_remote_sink() and add that dc_sink into the array dc_link- > > >remote_sinks[]. > > However, if we find that aconnector->dc_sink is not null, then we won't > > create a new > > dc_sink for that aconnector and won't add the sink to the array dc_link- > > >remote_sinks[]. > > > > When the issue that I mentioned before occurs, we won't be able to release > > the dc_sink > > for the aconnector when we unplug the sst monitor. Hence, we can't create > > new dc_sink > > for the latter on connected new stream sink of that port. Which leads to two > > issues > > 1. Unplug monitor and plug in another monitor "to the same port" > > => Since we use the same dc_sink to reflect the capability of the new > > connected stream > > sink, we might send out inappropriate stream to the new connected sink. > > 2. Because we can't release dc_sink in the array dc_link->remote_sinks[], > > when we > > plug/unplug sst monitor to more than 4 different mst port, we will break the > > criteria > > "dc_link->sink_count >= MAX_SINKS_PER_LINK" in > > link_add_remote_sink_helper(). > > Ok, a lot of this seems to be happening in amdgpu which certainly explains why > I had so much trouble following along with this originally (also, having > learned a bit more about how DC works definitely has helped a bit). I already > see a bunch of issues though with how this code is structured that would > definitely break things, though note I haven't sat down and tried this on a > real machine yet - will try tomorrow. > > So - it seems like dc_sink == a bunch of hotplugging state for a dm connector, > which actually tells me for one that this is definitely the wrong spot for > this code. get_modes() really should just handle filling out DRM modes and > pretty much nothing else, because callers from DRM aren't going to expect > side-effects like this when get_modes() is called - which could potentially > lead to all sorts of weirdness down the line if the DRM call paths that use > this ever change. i915 and nouveau have good examples of what these functions > should typically look like, and amdgpu actually seems to mostly follow this > advice for it's other get_modes() callback. > > Note there's also another problem here: the assumption "no EDID == > disconnected" isn't correct. It's totally possible to run into EDID-less > displays if the display is some ancient pre-historic relic, or if the ROM (or > EEPROM? can't remember what type of chip computer displays tend to use...) > chip > in the monitor containing the EDID has died. Note that the second situation is > suprisingly more common then one might think! I ran into a 140Hz 4k ASUS > display where this happened, and I know another friend of mine who had the ROM > in their display die randomly as well. > > So with this being said: I, think the solution here is actually just to > add/remove dc_sink from dm_dp_mst_detect() based on the CSN, and drop the > calls from get_modes()? detect() should always be called before the connector > has been removed, and we could use the return status from > drm_dp_mst_detect_port() in order to tell whether or not we should add/remove > the dc_sink. Thank you Lyude for guiding me through! After your elaboration, I think I roughly know the idea from drm perspective now. Let me get through this and will get back to you. > > If you don't get to it first tomorrow, I'll see if I can reproduce this > locally and try writing up a patch. > > Also a final note: I don't think it's a good idea in general for there to be a > fixed size array of dc_sinks like this. Those probably should just be stored > somehow on a per-connector basis. I say this because in addition to the fact Understand and agree with that. I plan to remove the constraint as well. Thanks! > MST connectors aren't destroyed immediately (which could lead to a situation > where we have more then 6 connected MST ports briefly before their destructors
Re: Parallel modesets and private state objects broken, where to go with MST?
On Mon, Mar 14, 2022 at 06:16:36PM -0400, Lyude Paul wrote: > Hi! First a little bit of background: I've recently been trying to get rid of > all of the non-atomic payload bandwidth management code in the MST helpers in > order to make it easier to implement DSC and fallback link rate retraining > support down the line. Currently bandwidth information is stored in two > places, partially in the MST atomic state and partially in the mst manager's > payload table (which exists outside of the atomic state and has its own > locking). The portions in the atomic state are used to try to determine if a > given display configuration can fit within the given bandwidth limitations > during the atomic check phase, and are implemented through the use of private > state objects. > > My current goal has been to move as much of this as possible over to the > atomic state and entirely get rid of the payload table along with it's locks. > My main reason for doing this is that it both decomplicates things quite a > bit, and I'm really also hoping that getting rid of that payload code will > make it clearer to others how it works - and stop the influx of bandaid > patches (e.g. adding more and more special cases to MST to fix poorly > understood issues being hit in one specific driver and nowhere else) that I've > had to spend way more time then I'd like trying to investigate and review. > > So, the actual problem: following a conversation with Daniel Vetter today I've > gotten the impression that private modesetting objects are basically just > broken with parallel modesets? I'm still wrapping my head around all of this > honestly, but from what I've gathered: CRTC atomic infra knows how to do waits > in the proper places for when other CRTCs need to be waited on to continue a > modeset, but there's no such tracking with private objects. If I understand > this correctly, that means that even if two CRTC modesets require pulling in > the same private object state for the MST mgr: we're only provided a guarantee > that the atomic checks pulling in that private object state won't > concurrently. But when it comes to commits, it doesn't sound like there's any > actual tracking for this and as such - two CRTC modesets which have both > pulled in the MST private state object are not prevented from running > concurrently. > > This unfortunately throws an enormous wrench into the MST atomic conversion > I've been working on - as I was under the understanding while writing the code > for this that all objects in an atomic state are blocked from being used in > any new atomic commits (not checks, as parallel checks should be fine in my > case) until there's no commits active with said object pulled into the atomic > state. I certainly am not aware of any way parallel modesetting could actually > be supported on MST, so it's not really a feature we want to deal with at all > besides stopping it from happening. This also unfortunately means that the > current atomic modesetting code we have for MST is potentially broken, > although I assume we've never hit any real world issues with it because of the > non-atomic locking we currently have for the payload table. > > So, Daniel had mentioned that supposedly you've been dealing with similar > issues with VC4 and might have already made progress on coming up with ways to > deal with it. If this is all correct, I'd definitely appreciate being able to > take a look at your work on this to see how I can help move things forward. > I've got a WIP of my atomic only MST branch as well: > > https://gitlab.freedesktop.org/lyudess/linux/-/commits/wip/mst-atomic-only-v1 > > However it's very certainly broken right now (it compiles and I had thought it > worked already, but I realized I totally forgot to come up with a way of doing > bookkeeping for VC start slots atomically - which is what led me down this > current rabbit hole), but it should at least give a general idea of what I'm > trying to do. > > Anyway, let me know what you think. For MST in particular parallel modeset on the same physical link sounds pretty crazy to me. Trying to make sure everything happens in the right order would not be pleasant. I think a simple solution would be just to add all the crtcs on the affected link to the state and call it a day. i915 already does that on modern platforms actually because the hardware architecture kinda needs it. Although we could perhaps optimize it a bit to skip it in some cases, but not sure the extra complexity would really be justified. In i915 we also serialize *all* modesets by running them on a ordered wq (+ explicit flush_workqueue() to serialize non-blocking vs. blocking modesets). We did semi-accidentally enable parallel modesets once but I undid that because there was just way too much pre-existing code that wasn't even considering the possibility of a parallel modeset, and I didn't really feel like reviewing the entire codebase to find all of it. -- Ville Syrjälä Inte
Re: [Intel-gfx] [PATCH] drm/i915/uapi: Add DRM_I915_QUERY_GEOMETRY_SUBSLICES
Quoting Tvrtko Ursulin (2022-03-14 17:35:17)
>
> On 12/03/2022 04:16, Matt Atwood wrote:
> > On Thu, Mar 10, 2022 at 12:26:12PM +, Tvrtko Ursulin wrote:
> >>
> >> On 10/03/2022 05:18, Matt Atwood wrote:
> >>> Newer platforms have DSS that aren't necessarily available for both
> >>> geometry and compute, two queries will need to exist. This introduces
> >>> the first, when passing a valid engine class and engine instance in the
> >>> flags returns a topology describing geometry.
> >>>
> >>> v2: fix white space errors
> >>>
> >>> Cc: Ashutosh Dixit
> >>> Cc: Matt Roper
> >>> Cc: Joonas Lahtinen
> >>> UMD (mesa):
> >>> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14143
> >>> Signed-off-by: Matt Atwood
> >>> @@ -2714,6 +2715,9 @@ struct drm_i915_query_item {
> >>> * - DRM_I915_QUERY_PERF_CONFIG_LIST
> >>> * - DRM_I915_QUERY_PERF_CONFIG_DATA_FOR_UUID
> >>> * - DRM_I915_QUERY_PERF_CONFIG_FOR_UUID
> >>> +*
> >>> +* When query_id == DRM_I915_QUERY_GEOMETRY_SUBSLICES must have bits
> >>> 0:7 set
> >>> +* as a valid engine class, and bits 8:15 must have a valid engine
> >>> instance.
> >>
> >> Alternatively, all other uapi uses struct i915_engine_class_instance to
> >> address engines which uses u16:u16.
> >>
> >> How ugly it is to stuff a struct into u32 flags is the question... But you
> >> could at least use u16:u16 for consistency. Unless you wanted to leave some
> >> bits free for the future?
> > Originally when I wrote this I was wanting to leave space in case it was
> > ever needed. I'm not particularly for or against keeping the space now.
>
> Yes, shrug... Neither I can't guess if we are ever likely to hit a
> problem by having fewer bits for class:instance here compared to other
> uapi, or if stuffing struct i915_engine_class_instance into flags would
> just be too ugly. I mean there is option to define a new struct and not
> use flags at all but that's probably to complicated for what it is.
>
> Anyone else with an opinion? Consistency or should be fine even like it is?
Stuffing a full i915_engine_class_instance was definitely intended when
putting it into the flags was suggested.
If that is hit with a complication, the next proposed alternative was a
new struct. That's why the query interface was made easily extensible,
after all...
Regards, Joonas
Re: [PATCH v2] drm: Fix a infinite loop condition when order becomes 0
On 16/03/2022 06:34, Arunpravin Paneer Selvam wrote:
handle a situation in the condition order-- == min_order,
when order = 0 and min_order = 0, leading to order = -1,
it now won't exit the loop. To avoid this problem,
added a order check in the same condition, (i.e)
when order is 0, we return -ENOSPC
v2: use full name in email program and in Signed-off tag
Signed-off-by: Arunpravin Paneer Selvam
---
drivers/gpu/drm/drm_buddy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index 72f52f293249..5ab66aaf2bbd 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -685,7 +685,7 @@ int drm_buddy_alloc_blocks(struct drm_buddy *mm,
if (!IS_ERR(block))
break;
- if (order-- == min_order) {
+ if (!order || order-- == min_order) {
It shouldn't be possible to enter an infinite loop here, without first
tripping up the BUG_ON(order < min_order) further up, and for that, as
we discussed here[1], it sounded like the conclusion was to rather add a
simple check somewhere in drm_buddy_alloc_blocks() to reject any size
not aligned to the min_page_size?
[1] https://patchwork.freedesktop.org/patch/477414/?series=101108&rev=1
err = -ENOSPC;
goto err_free;
}
base-commit: 3bd60c0259406c5ca3ce5cdc958fb910ad4b8175
Re: [PATCH v8 22/24] drm: rockchip: Add VOP2 driver
Hi Sascha and Daniel: On 3/16/22 15:40, Sascha Hauer wrote: On Tue, Mar 15, 2022 at 02:46:35PM +0800, Andy Yan wrote: Hi Sascha: On 3/11/22 16:33, Sascha Hauer wrote: From: Andy Yan The VOP2 unit is found on Rockchip SoCs beginning with rk3566/rk3568. It replaces the VOP unit found in the older Rockchip SoCs. This driver has been derived from the downstream Rockchip Kernel and heavily modified: - All nonstandard DRM properties have been removed - dropped struct vop2_plane_state and pass around less data between functions - Dropped all DRM_FORMAT_* not known on upstream - rework register access to get rid of excessively used macros - Drop all waiting for framesyncs The driver is tested with HDMI and MIPI-DSI display on a RK3568-EVB board. Overlay support is tested with the modetest utility. AFBC support on the cluster windows is tested with weston-simple-dmabuf-egl on weston using the (yet to be upstreamed) panfrost driver support. Do we need some modification to test AFBC by weston-simple-dma-egl ? By default weston-simple-dma-egl uses DRM_FORMAT_XRGB which in the panfrost driver ends up as PIPE_FORMAT_B8G8R8_UNORM and panfrost_afbc_format() returns PIPE_FORMAT_NONE for that. Change the format to DRM_FORMAT_ABGR using weston-simple-dma-egl -f 0x34324241. This ends up as PIPE_FORMAT_R8G8B8A8_UNORM in panfrost_afbc_format() which is a supported format. I also try weston-simple-dmabuf-egl -f 0x34324241 command, but I got this output log from weston[0]: Layer 5 (pos 0x5000): View 0 (role xdg_toplevel, PID 375, surface ID 3, top-level window 'simple-dmabuf-egl' of org.freedesktop.weston. simple-dmabuf-egl, 0xd08275e0): position: (871, 174) -> (1127, 430) [not opaque] outputs: 0 (HDMI-A-1) (primary) dmabuf buffer format: 0x34324241 ABGR modifier: ARM_BLOCK_SIZE=16x16,MODE=YTR|SPARSE (0x851) Layer 6 (pos 0x2): View 0 (role (null), PID 372, surface ID 18, background for output HDMI-A-1, 0xd0863520): position: (0, 0) -> (1920, 1080) [fully opaque] outputs: 0 (HDMI-A-1) (primary) [buffer not available] [repaint] preparing state for output HDMI-A-1 (0) [repaint] trying planes-only build state [view] evaluating view 0xd083b0f0 for output HDMI-A-1 (0) [view] not assigning view 0xd083b0f0 to plane (no buffer available) [view] failing state generation: placing view 0xd083b0f0 to renderer not allowed [repaint] could not build planes-only state, trying mixed [state] using renderer FB ID 73 for mixed mode for output HDMI-A-1 (0) [state] scanout will use for zpos 0 [view] evaluating view 0xd083b0f0 for output HDMI-A-1 (0) [view] not assigning view 0xd083b0f0 to plane (no buffer available) [view] view 0xd083b0f0 will be placed on the renderer [view] evaluating view 0xd08275e0 for output HDMI-A-1 (0) [plane] started with zpos 18446744073709551615 [view] view 0xd08275e0 will be placed on the renderer [view] evaluating view 0xd0863520 for output HDMI-A-1 (0) [view] not assigning view 0xd0863520 to plane (no buffer available) [view] not assigning view 0xd0863520 to plane (occluded by renderer views) [view] view 0xd0863520 will be placed on the renderer From the log we can find that Layer5 view 0(0xd08275e0) is the afbc view rendered by Panfrost. But it at last put on a render not a afbc window of vop "view] view 0xd083b0f0 will be placed on the renderer " The output message from sys/kernel/debug/dri/state can also provide that only non-AFBC window smart0-win0 is used. It seems that it failed in weston drm_output_prepare_plane_view. Maybe I need a deeper dig. [0] https://pastebin.com/8CfiP7u1 I have a buildroot system with weston-10.0.9 and mesa 21.3.5. After launch weston, I run weston-simple-dmabuf-egl, but from the output of sys/kernel/debug/dri/0/state, the weston is still use Smart0-win0, which is a non-AFBC window. Do i need to modify the vop2 driver to set one Cluster window as primary plane? I never used a Cluster window as primary plane. Sascha
Re: [PATCH v2] drm: Fix a infinite loop condition when order becomes 0
Am 16.03.22 um 12:31 schrieb Matthew Auld:
On 16/03/2022 06:34, Arunpravin Paneer Selvam wrote:
handle a situation in the condition order-- == min_order,
when order = 0 and min_order = 0, leading to order = -1,
it now won't exit the loop. To avoid this problem,
added a order check in the same condition, (i.e)
when order is 0, we return -ENOSPC
v2: use full name in email program and in Signed-off tag
Signed-off-by: Arunpravin Paneer Selvam
---
drivers/gpu/drm/drm_buddy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index 72f52f293249..5ab66aaf2bbd 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -685,7 +685,7 @@ int drm_buddy_alloc_blocks(struct drm_buddy *mm,
if (!IS_ERR(block))
break;
- if (order-- == min_order) {
+ if (!order || order-- == min_order) {
It shouldn't be possible to enter an infinite loop here, without first
tripping up the BUG_ON(order < min_order) further up, and for that, as
we discussed here[1], it sounded like the conclusion was to rather add
a simple check somewhere in drm_buddy_alloc_blocks() to reject any
size not aligned to the min_page_size?
Sounds good to me as well.
And just to make it clear: I don't review the functionality here, that's
up to you guys.
Just giving my Ack on things like style and pushing the end result
upstream as necessary.
So let me know when you have settled on a solution.
Regards,
Christian.
[1] https://patchwork.freedesktop.org/patch/477414/?series=101108&rev=1
err = -ENOSPC;
goto err_free;
}
base-commit: 3bd60c0259406c5ca3ce5cdc958fb910ad4b8175
Re: [PATCH v5] drm/msm/disp/dpu1: add inline rotation support for sc7280 target
On 15/03/2022 13:07, Vinod Polimera wrote:
- Some DPU versions support inline rot90. It is supported only for
limited amount of UBWC formats.
- There are two versions of inline rotators, v1 (present on sm8250 and
sm7250) and v2 (sc7280). These versions differ in the list of supported
formats and in the scaler possibilities.
Changes in RFC:
- Rebase changes to the latest code base.
- Append rotation config variables with v2 and
remove unused variables.(Dmitry)
- Move pixel_ext setup separately from scaler3 config.(Dmitry)
- Add 270 degree rotation to supported rotation list.(Dmitry)
Changes in V2:
- Remove unused macros and fix indentation.
- Add check if 90 rotation is supported and
add supported rotations to rot_cfg.
Changes in V3:
- Fix indentation.
- Move rot_supported to sspp capabilities. (Dmitry)
- Config pixel_ext based on src_h/src_w directly. (Dmitry)
- Misc changes.
Changes in V4:
- Pass boolean value to sspp blk based on supported rotations for each hw.
Changes in V5:
- update boolean value to true/false and add it for qcm2290.
Co-developed-by: Kalyan Thota
Signed-off-by: Kalyan Thota
Signed-off-by: Vinod Polimera
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 187 ++---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 18 +++
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 113 ---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h | 2 +
4 files changed, 215 insertions(+), 105 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index a4fe77c..060bf53 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -35,6 +35,9 @@
BIT(DPU_SSPP_TS_PREFILL) | BIT(DPU_SSPP_TS_PREFILL_REC1) |\
BIT(DPU_SSPP_CDP) | BIT(DPU_SSPP_EXCL_RECT))
+#define VIG_SC7280_MASK \
+ (VIG_SC7180_MASK | BIT(DPU_SSPP_INLINE_ROTATION))
+
#define DMA_SDM845_MASK \
(BIT(DPU_SSPP_SRC) | BIT(DPU_SSPP_QOS) | BIT(DPU_SSPP_QOS_8LVL) |\
BIT(DPU_SSPP_TS_PREFILL) | BIT(DPU_SSPP_TS_PREFILL_REC1) |\
@@ -203,6 +206,11 @@ static const uint32_t plane_formats_yuv[] = {
DRM_FORMAT_YVU420,
};
+static const u32 rotation_v2_formats[] = {
+ DRM_FORMAT_NV12,
+ /* TODO add formats after validation */
+};
+
/*
* DPU sub blocks config
*/
@@ -642,8 +650,7 @@ static const struct dpu_ctl_cfg qcm2290_ctl[] = {
*/
/* SSPP common configuration */
-
-#define _VIG_SBLK(num, sdma_pri, qseed_ver) \
+#define _VIG_SBLK(num, sdma_pri, qseed_ver, rot_cfg) \
{ \
.maxdwnscale = MAX_DOWNSCALE_RATIO, \
.maxupscale = MAX_UPSCALE_RATIO, \
@@ -660,6 +667,7 @@ static const struct dpu_ctl_cfg qcm2290_ctl[] = {
.num_formats = ARRAY_SIZE(plane_formats_yuv), \
.virt_format_list = plane_formats, \
.virt_num_formats = ARRAY_SIZE(plane_formats), \
+ .rotation_cfg = rot_cfg, \
}
#define _DMA_SBLK(num, sdma_pri) \
@@ -676,22 +684,28 @@ static const struct dpu_ctl_cfg qcm2290_ctl[] = {
}
static const struct dpu_sspp_sub_blks msm8998_vig_sblk_0 =
- _VIG_SBLK("0", 0, DPU_SSPP_SCALER_QSEED3);
+ _VIG_SBLK("0", 0, DPU_SSPP_SCALER_QSEED3, NULL);
static const struct dpu_sspp_sub_blks msm8998_vig_sblk_1 =
- _VIG_SBLK("1", 0, DPU_SSPP_SCALER_QSEED3);
+ _VIG_SBLK("1", 0, DPU_SSPP_SCALER_QSEED3, NULL);
static const struct dpu_sspp_sub_blks msm8998_vig_sblk_2 =
- _VIG_SBLK("2", 0, DPU_SSPP_SCALER_QSEED3);
+ _VIG_SBLK("2", 0, DPU_SSPP_SCALER_QSEED3, NULL);
static const struct dpu_sspp_sub_blks msm8998_vig_sblk_3 =
- _VIG_SBLK("3", 0, DPU_SSPP_SCALER_QSEED3);
+ _VIG_SBLK("3", 0, DPU_SSPP_SCALER_QSEED3, NULL);
+
+static const struct dpu_rotation_cfg dpu_rot_sc7280_cfg_v2 = {
+ .rot_maxheight = 1088,
+ .rot_num_formats = ARRAY_SIZE(rotation_v2_formats),
+ .rot_format_list = rotation_v2_formats,
+};
static const struct dpu_sspp_sub_blks sdm845_vig_sblk_0 =
- _VIG_SBLK("0", 5, DPU_SSPP_SCALER_QSEED3);
+ _VIG_SBLK("0", 5, DPU_SSPP_SCALER_QSEED3, NULL);
static const struct dpu_sspp_sub_blks sdm845_vig_sblk_1 =
- _VIG_SBLK("1", 6, DPU_SSPP_SCALER_QSEED3);
+ _VIG_SBLK("1", 6, DPU_SSPP_SCALER_QSEED3, NULL);
static const struct dpu_sspp_sub_blks sdm845_vig_sblk_2 =
- _VIG_SBLK("2", 7, DPU_SSPP_SCALER_QSEED3);
+ _VIG_SBLK("2", 7, DPU_SSPP
Re: [PATCH v2 4/8] drm/virtio: Improve DMA API usage for shmem BOs
On 2022-03-14 22:42, Dmitry Osipenko wrote:
DRM API requires the DRM's driver to be backed with the device that can
be used for generic DMA operations. The VirtIO-GPU device can't perform
DMA operations if it uses PCI transport because PCI device driver creates
a virtual VirtIO-GPU device that isn't associated with the PCI. Use PCI's
GPU device for the DRM's device instead of the VirtIO-GPU device and drop
DMA-related hacks from the VirtIO-GPU driver.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/virtio/virtgpu_drv.c| 22 +++---
drivers/gpu/drm/virtio/virtgpu_drv.h| 5 +--
drivers/gpu/drm/virtio/virtgpu_kms.c| 7 ++--
drivers/gpu/drm/virtio/virtgpu_object.c | 56 +
drivers/gpu/drm/virtio/virtgpu_vq.c | 13 +++---
5 files changed, 37 insertions(+), 66 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c
b/drivers/gpu/drm/virtio/virtgpu_drv.c
index 5f25a8d15464..8449dad3e65c 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.c
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.c
@@ -46,9 +46,9 @@ static int virtio_gpu_modeset = -1;
MODULE_PARM_DESC(modeset, "Disable/Enable modesetting");
module_param_named(modeset, virtio_gpu_modeset, int, 0400);
-static int virtio_gpu_pci_quirk(struct drm_device *dev, struct virtio_device *vdev)
+static int virtio_gpu_pci_quirk(struct drm_device *dev)
{
- struct pci_dev *pdev = to_pci_dev(vdev->dev.parent);
+ struct pci_dev *pdev = to_pci_dev(dev->dev);
const char *pname = dev_name(&pdev->dev);
bool vga = (pdev->class >> 8) == PCI_CLASS_DISPLAY_VGA;
char unique[20];
@@ -101,6 +101,7 @@ static int virtio_gpu_pci_quirk(struct drm_device *dev,
struct virtio_device *vd
static int virtio_gpu_probe(struct virtio_device *vdev)
{
struct drm_device *dev;
+ struct device *dma_dev;
int ret;
if (drm_firmware_drivers_only() && virtio_gpu_modeset == -1)
@@ -109,18 +110,29 @@ static int virtio_gpu_probe(struct virtio_device *vdev)
if (virtio_gpu_modeset == 0)
return -EINVAL;
- dev = drm_dev_alloc(&driver, &vdev->dev);
+ /*
+* If GPU's parent is a PCI device, then we will use this PCI device
+* for the DRM's driver device because GPU won't have PCI's IOMMU DMA
+* ops in this case since GPU device is sitting on a separate (from PCI)
+* virtio-bus.
+*/
+ if (!strcmp(vdev->dev.parent->bus->name, "pci"))
Nit: dev_is_pci() ?
However, what about other VirtIO transports? Wouldn't virtio-mmio with
F_ACCESS_PLATFORM be in a similar situation?
Robin.
+ dma_dev = vdev->dev.parent;
+ else
+ dma_dev = &vdev->dev;
+
+ dev = drm_dev_alloc(&driver, dma_dev);
if (IS_ERR(dev))
return PTR_ERR(dev);
vdev->priv = dev;
if (!strcmp(vdev->dev.parent->bus->name, "pci")) {
- ret = virtio_gpu_pci_quirk(dev, vdev);
+ ret = virtio_gpu_pci_quirk(dev);
if (ret)
goto err_free;
}
- ret = virtio_gpu_init(dev);
+ ret = virtio_gpu_init(vdev, dev);
if (ret)
goto err_free;
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h b/drivers/gpu/drm/virtio/virtgpu_drv.h
index 0a194aaad419..b2d93cb12ebf 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -100,8 +100,6 @@ struct virtio_gpu_object {
struct virtio_gpu_object_shmem {
struct virtio_gpu_object base;
- struct sg_table *pages;
- uint32_t mapped;
};
struct virtio_gpu_object_vram {
@@ -214,7 +212,6 @@ struct virtio_gpu_drv_cap_cache {
};
struct virtio_gpu_device {
- struct device *dev;
struct drm_device *ddev;
struct virtio_device *vdev;
@@ -282,7 +279,7 @@ extern struct drm_ioctl_desc
virtio_gpu_ioctls[DRM_VIRTIO_NUM_IOCTLS];
void virtio_gpu_create_context(struct drm_device *dev, struct drm_file *file);
/* virtgpu_kms.c */
-int virtio_gpu_init(struct drm_device *dev);
+int virtio_gpu_init(struct virtio_device *vdev, struct drm_device *dev);
void virtio_gpu_deinit(struct drm_device *dev);
void virtio_gpu_release(struct drm_device *dev);
int virtio_gpu_driver_open(struct drm_device *dev, struct drm_file *file);
diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c
b/drivers/gpu/drm/virtio/virtgpu_kms.c
index 3313b92db531..0d1e3eb61bee 100644
--- a/drivers/gpu/drm/virtio/virtgpu_kms.c
+++ b/drivers/gpu/drm/virtio/virtgpu_kms.c
@@ -110,7 +110,7 @@ static void virtio_gpu_get_capsets(struct virtio_gpu_device
*vgdev,
vgdev->num_capsets = num_capsets;
}
-int virtio_gpu_init(struct drm_device *dev)
+int virtio_gpu_init(struct virtio_device *vdev, struct drm_device *dev)
{
static vq_callback_t *callbacks[] = {
virtio_gpu_ctrl_ack, virtio_gpu_cursor_ack
@@ -123,7 +123,7 @@ int virtio_gpu_init(struct drm_device *dev)
Re: [PATCH 0/3] Move FPU related code from DCN3.1x drivers to DML folder
On 2022-03-07 10:47, Melissa Wen wrote: This series moves FPU code from DCN 3.1x drivers to dml/dcn31 folder to isolate FPU operations. For this, it creates dcn31_fpu files to centralize FPU operations and structs from dcn31x drivers, that include: - _vcs_dpi_ip_params_st and _vcs_dpi_soc_bounding_box_st structs - dcn31x_update_bw_bounding_box() functions - dcn31_calculate_wm_and_dlg_fp() Also, it adds dc_assert_fp_enabled() in public dml-fpu functions, as required, and I've checked if their calls are properly wrapped by DC_FP_START/END (and removed when inside dml/fpu files too). Melissa Wen (3): drm/amd/dicplay: move FPU related code from dcn31 to dml/dcn31 folder drm/amd/display: move FPU related code from dcn315 to dml/dcn31 folder drm/amd/display: move FPU related code from dcn316 to dml/dcn31 folder drivers/gpu/drm/amd/display/dc/dcn31/Makefile | 26 - .../drm/amd/display/dc/dcn31/dcn31_resource.c | 355 +-- .../drm/amd/display/dc/dcn31/dcn31_resource.h | 4 +- .../gpu/drm/amd/display/dc/dcn315/Makefile| 26 - .../amd/display/dc/dcn315/dcn315_resource.c | 232 + .../amd/display/dc/dcn315/dcn315_resource.h | 3 + .../gpu/drm/amd/display/dc/dcn316/Makefile| 26 - .../amd/display/dc/dcn316/dcn316_resource.c | 231 + .../amd/display/dc/dcn316/dcn316_resource.h | 3 + drivers/gpu/drm/amd/display/dc/dml/Makefile | 2 + .../drm/amd/display/dc/dml/dcn31/dcn31_fpu.c | 863 ++ .../drm/amd/display/dc/dml/dcn31/dcn31_fpu.h | 44 + 12 files changed, 921 insertions(+), 894 deletions(-) create mode 100644 drivers/gpu/drm/amd/display/dc/dml/dcn31/dcn31_fpu.c create mode 100644 drivers/gpu/drm/amd/display/dc/dml/dcn31/dcn31_fpu.h Hi Melissa, Thanks a lot for your patchset. We have already tested it with IGT, and we are running some manual tests to ensure that everything is fine. We will include your patch in this week's DC upstream, and if everything is alright, we will merge it next Monday.
Re: [PATCH v8 09/24] drm/rockchip: dw_hdmi: Add support for niu clk
On 3/16/22 12:12, Sascha Hauer wrote: > On Mon, Mar 14, 2022 at 08:54:27PM +0300, Dmitry Osipenko wrote: >> On 3/14/22 11:18, Sascha Hauer wrote: >>> On Sun, Mar 13, 2022 at 12:07:56AM +0300, Dmitry Osipenko wrote: On 3/11/22 11:33, Sascha Hauer wrote: > The rk3568 HDMI has an additional clock that needs to be enabled for the > HDMI controller to work. This clock is not needed for the HDMI > controller itself, but to make the SoC internal bus logic work. From the > reference manual: > >> 2.8.6 NIU Clock gating reliance >> >> A part of niu clocks have a dependence on another niu clock in order to >> sharing the internal bus. When these clocks are in use, another niu >> clock must be opened, and cannot be gated. These clocks and the special >> clock on which they are relied are as following: >> >> Clocks which have dependency The clock which can not be gated >> - >> ... >> pclk_vo_niu, hclk_vo_s_niu hclk_vo_niu >> ... > The clock framework does not support turning on a clock whenever another > clock is turned on, so this patch adds support for the dependent clock > to the HDMI driver. We call it "NIU", which is for "Native Interface > Unit" This still doesn't make sense to me. You're saying that "pclk_vo_niu, hclk_vo_s_niu" depend on "hclk_vo_niu", but HDMI doesn't use pclk_vo, it uses pclk_hdmi. >>> >>> pclk_hdmi_host is a child clock of pclk_vo: >>> >>> aclk_vo 220 3 0 >>> 0 5 Y >>> aclk_hdcp 000 3 0 >>> 0 5 N >>> pclk_vo 2307500 0 >>> 0 5 Y >>>pclk_edp_ctrl 0007500 0 >>> 0 5 N >>>pclk_dsitx_1 0007500 0 >>> 0 5 N >>>pclk_dsitx_0 1207500 0 >>> 0 5 Y >>>pclk_hdmi_host 1207500 0 >>> 0 5 Y >>>pclk_hdcp 0007500 0 >>> 0 5 N >>> hclk_vo 250 15000 0 >>> 0 5 Y >>>hclk_hdcp 000 15000 0 >>> 0 5 N >>>hclk_vop 020 15000 0 >>> 0 5 N >> >> It was unclear that the pclk_hdmi is the child of pclk_vo by looking at >> the clk driver's code, thank you! >> >> Won't be better if the implicit clk dependency would be handled >> internally by the RK clk driver? > > I have considered handling something like coupled clocks in the clock > framework, but I have not yet considered handling this internally in the > Rockchip clock driver. > > I just had a quick look at the driver. While it sounds like an easy task > to enable gate A whenever gate B is enabled I haven't found a good way to > integrate that into the clk driver. It seems to me that it's not easier > to implement in the clk driver than it is to implement it in the clk > framework where it could be used by others as well. > >> For example, by making the common gate >> shared/refcounted. Have you considered this variant? Then we won't need >> to change the DT bindings. > > For the DT bindings it is just an additional clock. Should we have a > better way to handle that case in the future we could simply ignore the > additional clock. I wouldn't bother too much about this. To me that NIU quirk should be internal to the clk h/w module, so it doesn't feel nice to mix the clk h/w description with the HDMI h/w description. On the other hand, making clk driver to handle this case indeed will take some effort as I see now. For example, clk driver of NVIDIA Tegra has concept of shared gates, but bringing it to the RK clk driver will be quite messy. Alright, let's work around the clk limitation like you're suggesting. I agree that it shouldn't really be a problem to deprecate the extra clock later on. I have last questions.. 1. Previously you said that the PD driver takes care of enabling all the clocks it can find in the device by itself on RPM-resume, then why HDMI driver needs to enable the clock explicitly? 2. You added clk_prepare_enable(), but there is no corresponding clk_disable_unprepare(), AFAICS. Why?
[PATCH v2 0/7] Add RZ/G2L Display 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.
This patch series aims to add basic display support on RZ/G2L SMARC EVK
platform. The output from DSI is connected to ADV7535.
The DU controller is similar to R-Car as it is connected to VSPD,
so reusing most of R-Car code with new CRTC driver specific to
RZ/G2L
v1->v2:
* Based on [1], all references to 'rzg2l_lcdc' replaced with 'rzg2l_du'
* Updated commit description for bindings
* Removed LCDC references from bindings
* Changed clock name from du.0->aclk from bindings
* Changed reset name from du.0->du from bindings
* Replaced crtc_helper_funcs->rcar_crtc_helper_funcs
* Updated macro DRM_RZG2L_LCDC->DRM_RZG2L_DU
* Replaced rzg2l-lcdc-drm->rzg2l-du-drm
* Added forward declaration for struct reset_control
[1]
https://patchwork.kernel.org/project/linux-renesas-soc/patch/20220312084205.31462-2-biju.das...@bp.renesas.com/
RFC->v1:
* Changed minItems->maxItems for renesas,vsps.
* Added RZ/G2L LCDC driver with special handling for CRTC reusing
most of RCar DU code
* Fixed the comments for num_rpf from rpf's->RPFs/ and vsp->VSP.
RFC:
https://patchwork.kernel.org/project/linux-renesas-soc/patch/20220112174612.10773-18-biju.das...@bp.renesas.com/
https://patchwork.kernel.org/project/linux-renesas-soc/patch/20220112174612.10773-12-biju.das...@bp.renesas.com/
https://patchwork.kernel.org/project/linux-renesas-soc/patch/20220112174612.10773-13-biju.das...@bp.renesas.com/
https://patchwork.kernel.org/project/linux-renesas-soc/patch/20220112174612.10773-19-biju.das...@bp.renesas.com/
Biju Das (7):
dt-bindings: display: renesas,du: Document r9a07g044l bindings
drm: rcar-du: Add num_rpf to struct rcar_du_device_info
drm: rcar-du: Add max_width and max_height to struct
rcar_du_device_info
drm: rcar-du: Move rcar_du_output_name() to rcar_du_common.c
drm: rcar-du: Factorise rcar_du_{atomic_check,modeset_init}
drm: rcar-du: Factorise
rcar_du_vsp{complete,enable,plane_atomic_check}
drm: rcar-du: Add RZ/G2L DU Support
.../bindings/display/renesas,du.yaml | 54 ++
drivers/gpu/drm/rcar-du/Kconfig | 18 +-
drivers/gpu/drm/rcar-du/Makefile | 13 +
drivers/gpu/drm/rcar-du/rcar_du_common.c | 30 +
drivers/gpu/drm/rcar-du/rcar_du_crtc.h| 8 +
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 100 ++-
drivers/gpu/drm/rcar-du/rcar_du_drv.h | 31 +
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 23 +-
drivers/gpu/drm/rcar-du/rcar_du_plane.h | 12 +
drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 18 +-
drivers/gpu/drm/rcar-du/rzg2l_du_crtc.c | 705 ++
drivers/gpu/drm/rcar-du/rzg2l_du_drv.c| 221 ++
drivers/gpu/drm/rcar-du/rzg2l_du_plane.c | 82 ++
drivers/gpu/drm/rcar-du/rzg2l_du_regs.h | 64 ++
14 files changed, 1334 insertions(+), 45 deletions(-)
create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_common.c
create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_du_crtc.c
create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_du_drv.c
create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_du_plane.c
create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_du_regs.h
--
2.17.1
[PATCH v2 1/7] dt-bindings: display: renesas, du: Document r9a07g044l bindings
Extend the Renesas DU display bindings to support the r9a07g044l DU module found on RZ/G2L LCDC. Signed-off-by: Biju Das --- v1->v2: * Updated commit description. * Removed LCDC references * Changed clock name from du.0->aclk * Changed reset name from du.0->du RFC->v1: * Changed minItems->maxItems for renesas,vsps. RFC: https://patchwork.kernel.org/project/linux-renesas-soc/patch/20220112174612.10773-18-biju.das...@bp.renesas.com/ --- .../bindings/display/renesas,du.yaml | 54 +++ 1 file changed, 54 insertions(+) diff --git a/Documentation/devicetree/bindings/display/renesas,du.yaml b/Documentation/devicetree/bindings/display/renesas,du.yaml index 13efea574584..f560608bf4e8 100644 --- a/Documentation/devicetree/bindings/display/renesas,du.yaml +++ b/Documentation/devicetree/bindings/display/renesas,du.yaml @@ -40,6 +40,7 @@ properties: - renesas,du-r8a77990 # for R-Car E3 compatible DU - renesas,du-r8a77995 # for R-Car D3 compatible DU - renesas,du-r8a779a0 # for R-Car V3U compatible DU + - renesas,du-r9a07g044l # for RZ/G2L compatible DU reg: maxItems: 1 @@ -824,6 +825,59 @@ allOf: - reset-names - renesas,vsps + - if: + properties: +compatible: + contains: +enum: + - renesas,du-r9a07g044l +then: + properties: +clocks: + items: +- description: Main clock +- description: Register access clock +- description: Video clock + +clock-names: + items: +- const: aclk +- const: pclk +- const: vclk + +interrupts: + maxItems: 1 + +resets: + maxItems: 1 + +reset-names: + items: +- const: du + +ports: + properties: +port@0: + description: DPAD 0 +port@1: + description: DSI 0 +port@2: false +port@3: false + + required: +- port@0 +- port@1 + +renesas,vsps: + maxItems: 1 + + required: +- clock-names +- interrupts +- resets +- reset-names +- renesas,vsps + additionalProperties: false examples: -- 2.17.1
[PATCH v2 2/7] drm: rcar-du: Add num_rpf to struct rcar_du_device_info
Number of RPF's VSP is different on R-Car and RZ/G2L
R-Car Gen3 -> 5 RPFs
R-Car Gen2 -> 4 RPFs
RZ/G2L -> 2 RPFs
Add num_rpf to struct rcar_du_device_info to support later
SoC without any code changes.
Signed-off-by: Biju Das
---
v1->v2:
* No change
RFC->v1:
* Fixed the comment for num_rpf s/rpf's/RPFs/ and s/vsp/VSP/
RFC:
*
https://patchwork.kernel.org/project/linux-renesas-soc/patch/20220112174612.10773-12-biju.das...@bp.renesas.com/
---
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 17 +
drivers/gpu/drm/rcar-du/rcar_du_drv.h | 2 ++
drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 6 +-
3 files changed, 20 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index 957ea97541d5..1bc7325aa356 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -55,6 +55,7 @@ static const struct rcar_du_device_info rzg1_du_r8a7743_info
= {
},
},
.num_lvds = 1,
+ .num_rpf = 4,
};
static const struct rcar_du_device_info rzg1_du_r8a7745_info = {
@@ -77,6 +78,7 @@ static const struct rcar_du_device_info rzg1_du_r8a7745_info
= {
.port = 1,
},
},
+ .num_rpf = 4,
};
static const struct rcar_du_device_info rzg1_du_r8a77470_info = {
@@ -104,6 +106,7 @@ static const struct rcar_du_device_info
rzg1_du_r8a77470_info = {
.port = 2,
},
},
+ .num_rpf = 4,
};
static const struct rcar_du_device_info rcar_du_r8a774a1_info = {
@@ -133,6 +136,7 @@ static const struct rcar_du_device_info
rcar_du_r8a774a1_info = {
},
},
.num_lvds = 1,
+ .num_rpf = 5,
.dpll_mask = BIT(1),
};
@@ -163,6 +167,7 @@ static const struct rcar_du_device_info
rcar_du_r8a774b1_info = {
},
},
.num_lvds = 1,
+ .num_rpf = 5,
.dpll_mask = BIT(1),
};
@@ -190,6 +195,7 @@ static const struct rcar_du_device_info
rcar_du_r8a774c0_info = {
},
},
.num_lvds = 2,
+ .num_rpf = 4,
.lvds_clk_mask = BIT(1) | BIT(0),
};
@@ -220,6 +226,7 @@ static const struct rcar_du_device_info
rcar_du_r8a774e1_info = {
},
},
.num_lvds = 1,
+ .num_rpf = 5,
.dpll_mask = BIT(1),
};
@@ -272,6 +279,7 @@ static const struct rcar_du_device_info
rcar_du_r8a7790_info = {
},
},
.num_lvds = 2,
+ .num_rpf = 4,
};
/* M2-W (r8a7791) and M2-N (r8a7793) are identical */
@@ -297,6 +305,7 @@ static const struct rcar_du_device_info
rcar_du_r8a7791_info = {
},
},
.num_lvds = 1,
+ .num_rpf = 4,
};
static const struct rcar_du_device_info rcar_du_r8a7792_info = {
@@ -317,6 +326,7 @@ static const struct rcar_du_device_info
rcar_du_r8a7792_info = {
.port = 1,
},
},
+ .num_rpf = 4,
};
static const struct rcar_du_device_info rcar_du_r8a7794_info = {
@@ -340,6 +350,7 @@ static const struct rcar_du_device_info
rcar_du_r8a7794_info = {
.port = 1,
},
},
+ .num_rpf = 4,
};
static const struct rcar_du_device_info rcar_du_r8a7795_info = {
@@ -373,6 +384,7 @@ static const struct rcar_du_device_info
rcar_du_r8a7795_info = {
},
},
.num_lvds = 1,
+ .num_rpf = 5,
.dpll_mask = BIT(2) | BIT(1),
};
@@ -403,6 +415,7 @@ static const struct rcar_du_device_info
rcar_du_r8a7796_info = {
},
},
.num_lvds = 1,
+ .num_rpf = 5,
.dpll_mask = BIT(1),
};
@@ -433,6 +446,7 @@ static const struct rcar_du_device_info
rcar_du_r8a77965_info = {
},
},
.num_lvds = 1,
+ .num_rpf = 5,
.dpll_mask = BIT(1),
};
@@ -459,6 +473,7 @@ static const struct rcar_du_device_info
rcar_du_r8a77970_info = {
},
},
.num_lvds = 1,
+ .num_rpf = 5,
};
static const struct rcar_du_device_info rcar_du_r8a7799x_info = {
@@ -486,6 +501,7 @@ static const struct rcar_du_device_info
rcar_du_r8a7799x_info = {
},
},
.num_lvds = 2,
+ .num_rpf = 5,
.lvds_clk_mask = BIT(1) | BIT(0),
};
@@ -505,6 +521,7 @@ static const struct rcar_du_device_info
rcar_du_r8a779a0_info = {
.port = 1,
},
},
+ .num_rpf = 5,
.dsi_clk_mask = BIT(1) | BIT(0),
};
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
index 101f42df86ea..68c5de59d18d 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
@@ -69,6 +69,7 @@ struct rcar_du_output_routing {
* @channels_mask: bit mask of available DU channels
* @routes: array of CRTC to output routes, inde
[PATCH v2 3/7] drm: rcar-du: Add max_width and max_height to struct rcar_du_device_info
There are some differences related to max frame size supported by different
R-Car/RZ-G family of SoC's
Max frame size supported by R-Car Gen1 & R-Car Gen2 is 4095x2047
Max frame size supported by R-Car Gen3 is 8190x8190
Max frame size supported by RZ/G2L is 1920x1080
Add max_width and max_height to struct rcar_du_device_info to support later
SoC without any code changes.
Signed-off-by: Biju Das
---
v1->v2:
* No Change
RFC->V1:
* No Change
RFC:
*
https://patchwork.kernel.org/project/linux-renesas-soc/patch/20220112174612.10773-13-biju.das...@bp.renesas.com/
---
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 36 +++
drivers/gpu/drm/rcar-du/rcar_du_drv.h | 4 +++
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 17 +
3 files changed, 46 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index 1bc7325aa356..4640c356a532 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -56,6 +56,8 @@ static const struct rcar_du_device_info rzg1_du_r8a7743_info
= {
},
.num_lvds = 1,
.num_rpf = 4,
+ .max_width = 4095,
+ .max_height = 2047,
};
static const struct rcar_du_device_info rzg1_du_r8a7745_info = {
@@ -79,6 +81,8 @@ static const struct rcar_du_device_info rzg1_du_r8a7745_info
= {
},
},
.num_rpf = 4,
+ .max_width = 4095,
+ .max_height = 2047,
};
static const struct rcar_du_device_info rzg1_du_r8a77470_info = {
@@ -107,6 +111,8 @@ static const struct rcar_du_device_info
rzg1_du_r8a77470_info = {
},
},
.num_rpf = 4,
+ .max_width = 4095,
+ .max_height = 2047,
};
static const struct rcar_du_device_info rcar_du_r8a774a1_info = {
@@ -137,6 +143,8 @@ static const struct rcar_du_device_info
rcar_du_r8a774a1_info = {
},
.num_lvds = 1,
.num_rpf = 5,
+ .max_width = 8190,
+ .max_height = 8190,
.dpll_mask = BIT(1),
};
@@ -168,6 +176,8 @@ static const struct rcar_du_device_info
rcar_du_r8a774b1_info = {
},
.num_lvds = 1,
.num_rpf = 5,
+ .max_width = 8190,
+ .max_height = 8190,
.dpll_mask = BIT(1),
};
@@ -196,6 +206,8 @@ static const struct rcar_du_device_info
rcar_du_r8a774c0_info = {
},
.num_lvds = 2,
.num_rpf = 4,
+ .max_width = 8190,
+ .max_height = 8190,
.lvds_clk_mask = BIT(1) | BIT(0),
};
@@ -227,6 +239,8 @@ static const struct rcar_du_device_info
rcar_du_r8a774e1_info = {
},
.num_lvds = 1,
.num_rpf = 5,
+ .max_width = 8190,
+ .max_height = 8190,
.dpll_mask = BIT(1),
};
@@ -249,6 +263,8 @@ static const struct rcar_du_device_info
rcar_du_r8a7779_info = {
.port = 1,
},
},
+ .max_width = 4095,
+ .max_height = 2047,
};
static const struct rcar_du_device_info rcar_du_r8a7790_info = {
@@ -280,6 +296,8 @@ static const struct rcar_du_device_info
rcar_du_r8a7790_info = {
},
.num_lvds = 2,
.num_rpf = 4,
+ .max_width = 4095,
+ .max_height = 2047,
};
/* M2-W (r8a7791) and M2-N (r8a7793) are identical */
@@ -306,6 +324,8 @@ static const struct rcar_du_device_info
rcar_du_r8a7791_info = {
},
.num_lvds = 1,
.num_rpf = 4,
+ .max_width = 4095,
+ .max_height = 2047,
};
static const struct rcar_du_device_info rcar_du_r8a7792_info = {
@@ -327,6 +347,8 @@ static const struct rcar_du_device_info
rcar_du_r8a7792_info = {
},
},
.num_rpf = 4,
+ .max_width = 4095,
+ .max_height = 2047,
};
static const struct rcar_du_device_info rcar_du_r8a7794_info = {
@@ -351,6 +373,8 @@ static const struct rcar_du_device_info
rcar_du_r8a7794_info = {
},
},
.num_rpf = 4,
+ .max_width = 4095,
+ .max_height = 2047,
};
static const struct rcar_du_device_info rcar_du_r8a7795_info = {
@@ -385,6 +409,8 @@ static const struct rcar_du_device_info
rcar_du_r8a7795_info = {
},
.num_lvds = 1,
.num_rpf = 5,
+ .max_width = 8190,
+ .max_height = 8190,
.dpll_mask = BIT(2) | BIT(1),
};
@@ -416,6 +442,8 @@ static const struct rcar_du_device_info
rcar_du_r8a7796_info = {
},
.num_lvds = 1,
.num_rpf = 5,
+ .max_width = 8190,
+ .max_height = 8190,
.dpll_mask = BIT(1),
};
@@ -447,6 +475,8 @@ static const struct rcar_du_device_info
rcar_du_r8a77965_info = {
},
.num_lvds = 1,
.num_rpf = 5,
+ .max_width = 8190,
+ .max_height = 8190,
.dpll_mask = BIT(1),
};
@@ -474,6 +504,8 @@ static const struct rcar_du_device_info
rcar_du_r8a77970_info = {
},
.num_lvds = 1,
.num_rpf = 5,
+ .max_width = 8190,
+ .max
[PATCH v2 6/7] drm: rcar-du: Factorise rcar_du_vsp{complete, enable, plane_atomic_check}
RZ/G2L SoC's does not have group/plane registers compared to RCar, hence
it needs a different CRTC implementation. Factorise rcar_du_vsp{complete,
enable,plane_atomic_check} so that it can support RZ/G2L SoC without any
code changes.
Signed-off-by: Biju Das
---
v1->v2:
* No change
RFC->v1:
* New patch
---
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 3 +++
drivers/gpu/drm/rcar-du/rcar_du_drv.h | 9 +
drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 12
3 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index 0df1430b9664..b944885d7f65 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -38,6 +38,9 @@ static struct rcar_du_crtc_helper_funcs
rcar_crtc_helper_funcs = {
.du_planes_init = rcar_du_planes_init,
.du_crtc_create = rcar_du_crtc_create,
.du_atomic_check_planes = rcar_du_atomic_check_planes,
+ .__du_plane_setup = __rcar_du_plane_setup,
+ .__du_plane_atomic_check = __rcar_du_plane_atomic_check,
+ .du_crtc_finish_page_flip = rcar_du_crtc_finish_page_flip,
};
static const struct rcar_du_device_info rzg1_du_r8a7743_info = {
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
index 164cd9854aaf..bb2146621eb4 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
@@ -66,6 +66,9 @@ struct rcar_du_output_routing {
* @du_planes_init: pointer to du_plane_init function
* @du_crtc_create: pointer to du_crtc_create function
* @du_atomic_check_planes: pointer to du_atomic_check_planes function
+ * @__du_plane_setup: pointer to __du_plane_setup function
+ * @__du_plane_atomic_check: pointer to __du_plane_atomic_check function
+ * @du_crtc_finish_page_flip: pointer to du_crtc_finish_page_flip function
*/
struct rcar_du_crtc_helper_funcs {
int (*du_planes_init)(struct rcar_du_group *rgrp);
@@ -73,6 +76,12 @@ struct rcar_du_crtc_helper_funcs {
unsigned int hwindex);
int (*du_atomic_check_planes)(struct drm_device *dev,
struct drm_atomic_state *state);
+ void (*__du_plane_setup)(struct rcar_du_group *rgrp,
+const struct rcar_du_plane_state *state);
+ int (*__du_plane_atomic_check)(struct drm_plane *plane,
+ struct drm_plane_state *state,
+ const struct rcar_du_format_info **format);
+ void (*du_crtc_finish_page_flip)(struct rcar_du_crtc *rcrtc);
};
/*
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
index cf045a203aa5..41928a94c903 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
@@ -35,12 +35,13 @@
static void rcar_du_vsp_complete(void *private, unsigned int status, u32 crc)
{
struct rcar_du_crtc *crtc = private;
+ struct rcar_du_device *rcdu = crtc->dev;
if (crtc->vblank_enable)
drm_crtc_handle_vblank(&crtc->crtc);
if (status & VSP1_DU_STATUS_COMPLETE)
- rcar_du_crtc_finish_page_flip(crtc);
+ rcdu->info->fns->du_crtc_finish_page_flip(crtc);
if (status & VSP1_DU_STATUS_WRITEBACK)
rcar_du_writeback_complete(crtc);
@@ -82,7 +83,7 @@ void rcar_du_vsp_enable(struct rcar_du_crtc *crtc)
else
state.hwindex = crtc->index % 2;
- __rcar_du_plane_setup(crtc->group, &state);
+ rcdu->info->fns->__du_plane_setup(crtc->group, &state);
/*
* Ensure that the plane source configuration takes effect by requesting
@@ -294,12 +295,15 @@ static void rcar_du_vsp_plane_cleanup_fb(struct drm_plane
*plane,
static int rcar_du_vsp_plane_atomic_check(struct drm_plane *plane,
struct drm_atomic_state *state)
{
+ struct rcar_du_vsp *vsp = to_rcar_vsp_plane(plane)->vsp;
+ struct rcar_du_device *rcdu = vsp->dev;
+
struct drm_plane_state *new_plane_state =
drm_atomic_get_new_plane_state(state,
plane);
struct rcar_du_vsp_plane_state *rstate =
to_rcar_vsp_plane_state(new_plane_state);
- return __rcar_du_plane_atomic_check(plane, new_plane_state,
- &rstate->format);
+ return rcdu->info->fns->__du_plane_atomic_check(plane, new_plane_state,
+ &rstate->format);
}
static void rcar_du_vsp_plane_atomic_update(struct drm_plane *plane,
--
2.17.1
[PATCH v2 5/7] drm: rcar-du: Factorise rcar_du_{atomic_check, modeset_init}
RZ/G2L SoC's does not have group/plane registers compared to RCar, hence it
needs a different CRTC implementation. Factorise rcar_du_{atomic_check,
modeset_init} by adding struct rcar_du_crtc_helper_funcs to struct
rcar_du_device_info, so that it can support RZ/G2L SoC without any code
changes.
Signed-off-by: Biju Das
---
v1->v2:
* Changed crtc_helper_funcs->rcar_crtc_helper_funcs
RFC->v1:
* New patch
---
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 24
drivers/gpu/drm/rcar-du/rcar_du_drv.h | 16
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 6 +++---
3 files changed, 43 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index f6e234dafb72..0df1430b9664 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -34,6 +34,12 @@
* Device Information
*/
+static struct rcar_du_crtc_helper_funcs rcar_crtc_helper_funcs = {
+ .du_planes_init = rcar_du_planes_init,
+ .du_crtc_create = rcar_du_crtc_create,
+ .du_atomic_check_planes = rcar_du_atomic_check_planes,
+};
+
static const struct rcar_du_device_info rzg1_du_r8a7743_info = {
.gen = 2,
.features = RCAR_DU_FEATURE_CRTC_IRQ
@@ -58,6 +64,7 @@ static const struct rcar_du_device_info rzg1_du_r8a7743_info
= {
.num_rpf = 4,
.max_width = 4095,
.max_height = 2047,
+ .fns = &rcar_crtc_helper_funcs,
};
static const struct rcar_du_device_info rzg1_du_r8a7745_info = {
@@ -83,6 +90,7 @@ static const struct rcar_du_device_info rzg1_du_r8a7745_info
= {
.num_rpf = 4,
.max_width = 4095,
.max_height = 2047,
+ .fns = &rcar_crtc_helper_funcs,
};
static const struct rcar_du_device_info rzg1_du_r8a77470_info = {
@@ -113,6 +121,7 @@ static const struct rcar_du_device_info
rzg1_du_r8a77470_info = {
.num_rpf = 4,
.max_width = 4095,
.max_height = 2047,
+ .fns = &rcar_crtc_helper_funcs,
};
static const struct rcar_du_device_info rcar_du_r8a774a1_info = {
@@ -146,6 +155,7 @@ static const struct rcar_du_device_info
rcar_du_r8a774a1_info = {
.max_width = 8190,
.max_height = 8190,
.dpll_mask = BIT(1),
+ .fns = &rcar_crtc_helper_funcs,
};
static const struct rcar_du_device_info rcar_du_r8a774b1_info = {
@@ -179,6 +189,7 @@ static const struct rcar_du_device_info
rcar_du_r8a774b1_info = {
.max_width = 8190,
.max_height = 8190,
.dpll_mask = BIT(1),
+ .fns = &rcar_crtc_helper_funcs,
};
static const struct rcar_du_device_info rcar_du_r8a774c0_info = {
@@ -209,6 +220,7 @@ static const struct rcar_du_device_info
rcar_du_r8a774c0_info = {
.max_width = 8190,
.max_height = 8190,
.lvds_clk_mask = BIT(1) | BIT(0),
+ .fns = &rcar_crtc_helper_funcs,
};
static const struct rcar_du_device_info rcar_du_r8a774e1_info = {
@@ -242,6 +254,7 @@ static const struct rcar_du_device_info
rcar_du_r8a774e1_info = {
.max_width = 8190,
.max_height = 8190,
.dpll_mask = BIT(1),
+ .fns = &rcar_crtc_helper_funcs,
};
static const struct rcar_du_device_info rcar_du_r8a7779_info = {
@@ -265,6 +278,7 @@ static const struct rcar_du_device_info
rcar_du_r8a7779_info = {
},
.max_width = 4095,
.max_height = 2047,
+ .fns = &rcar_crtc_helper_funcs,
};
static const struct rcar_du_device_info rcar_du_r8a7790_info = {
@@ -298,6 +312,7 @@ static const struct rcar_du_device_info
rcar_du_r8a7790_info = {
.num_rpf = 4,
.max_width = 4095,
.max_height = 2047,
+ .fns = &rcar_crtc_helper_funcs,
};
/* M2-W (r8a7791) and M2-N (r8a7793) are identical */
@@ -326,6 +341,7 @@ static const struct rcar_du_device_info
rcar_du_r8a7791_info = {
.num_rpf = 4,
.max_width = 4095,
.max_height = 2047,
+ .fns = &rcar_crtc_helper_funcs,
};
static const struct rcar_du_device_info rcar_du_r8a7792_info = {
@@ -349,6 +365,7 @@ static const struct rcar_du_device_info
rcar_du_r8a7792_info = {
.num_rpf = 4,
.max_width = 4095,
.max_height = 2047,
+ .fns = &rcar_crtc_helper_funcs,
};
static const struct rcar_du_device_info rcar_du_r8a7794_info = {
@@ -375,6 +392,7 @@ static const struct rcar_du_device_info
rcar_du_r8a7794_info = {
.num_rpf = 4,
.max_width = 4095,
.max_height = 2047,
+ .fns = &rcar_crtc_helper_funcs,
};
static const struct rcar_du_device_info rcar_du_r8a7795_info = {
@@ -412,6 +430,7 @@ static const struct rcar_du_device_info
rcar_du_r8a7795_info = {
.max_width = 8190,
.max_height = 8190,
.dpll_mask = BIT(2) | BIT(1),
+ .fns = &rcar_crtc_helper_funcs,
};
static const struct rcar_du_device_info rcar_du_r8a7796_info = {
@@ -445,6 +464,7 @@ static const struct rcar_du_device_info
rcar_du_r8a7796_info = {
.max_widt
[PATCH v2 7/7] drm: rcar-du: Add RZ/G2L DU Support
The LCD controller is composed of Frame Compression Processor (FCPVD), Video Signal Processor (VSPD), and Display Unit (DU). It has DPI/DSI interfaces and supports a maximum resolution of 1080p along with 2 RPFs to support blending of two picture layers and raster operations (ROPs). The DU part is similar to RCar like DU is connected to VSPD, so reusing most of the functionality from RCar. This patch introduces separate CRTC handling as it does not have plane/group registers. Signed-off-by: Biju Das --- v1->v2: * Based on [1], all references to 'rzg2l_lcdc' replaced with 'rzg2l_du' * Updated commit header * Updated macro DRM_RZG2L_LCDC->DRM_RZG2L_DU * Replaced rzg2l-lcdc-drm->rzg2l-du-drm * Added forward declaration for struct reset_control [1] https://patchwork.kernel.org/project/linux-renesas-soc/patch/20220312084205.31462-2-biju.das...@bp.renesas.com/ RFC->v1: * Added RZ/G2L LCDC driver with special handling for CRTC reusing most of RCar DU code RFC: https://patchwork.kernel.org/project/linux-renesas-soc/patch/20220112174612.10773-19-biju.das...@bp.renesas.com/ --- drivers/gpu/drm/rcar-du/Kconfig | 18 +- drivers/gpu/drm/rcar-du/Makefile | 12 + drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 8 + drivers/gpu/drm/rcar-du/rcar_du_plane.h | 12 + drivers/gpu/drm/rcar-du/rzg2l_du_crtc.c | 705 +++ drivers/gpu/drm/rcar-du/rzg2l_du_drv.c | 221 +++ drivers/gpu/drm/rcar-du/rzg2l_du_plane.c | 82 +++ drivers/gpu/drm/rcar-du/rzg2l_du_regs.h | 64 ++ 8 files changed, 1120 insertions(+), 2 deletions(-) create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_du_crtc.c create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_du_drv.c create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_du_plane.c create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_du_regs.h diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig index f6e6a6d5d987..e40fb0c53f9b 100644 --- a/drivers/gpu/drm/rcar-du/Kconfig +++ b/drivers/gpu/drm/rcar-du/Kconfig @@ -11,6 +11,19 @@ config DRM_RCAR_DU Choose this option if you have an R-Car chipset. If M is selected the module will be called rcar-du-drm. +config DRM_RZG2L_DU + tristate "DRM Support for RZ/G2L DU" + depends on DRM && OF + depends on ARM || ARM64 + depends on ARCH_RENESAS || COMPILE_TEST + select DRM_KMS_HELPER + select DRM_GEM_CMA_HELPER + select VIDEOMODE_HELPERS + help + Choose this option if you have an RZ/G2L chipset. + If M is selected the module will be called rzg2l-du-drm. + + config DRM_RCAR_USE_CMM bool "R-Car DU Color Management Module (CMM) Support" depends on DRM_RCAR_DU @@ -54,12 +67,13 @@ config DRM_RCAR_MIPI_DSI config DRM_RCAR_VSP bool "R-Car DU VSP Compositor Support" if ARM default y if ARM64 - depends on DRM_RCAR_DU + depends on DRM_RCAR_DU || DRM_RZG2L_DU depends on VIDEO_RENESAS_VSP1=y || (VIDEO_RENESAS_VSP1 && DRM_RCAR_DU=m) + depends on VIDEO_RENESAS_VSP1=y || (VIDEO_RENESAS_VSP1 && DRM_RZG2L_DU=m) help Enable support to expose the R-Car VSP Compositor as KMS planes. config DRM_RCAR_WRITEBACK bool default y if ARM64 - depends on DRM_RCAR_DU + depends on DRM_RCAR_DU || DRM_RZG2L_DU diff --git a/drivers/gpu/drm/rcar-du/Makefile b/drivers/gpu/drm/rcar-du/Makefile index 331e12d65a6b..01ba78e56b53 100644 --- a/drivers/gpu/drm/rcar-du/Makefile +++ b/drivers/gpu/drm/rcar-du/Makefile @@ -7,15 +7,27 @@ rcar-du-drm-y := rcar_du_crtc.o \ rcar_du_kms.o \ rcar_du_plane.o \ +rzg2l-du-drm-y := rzg2l_du_crtc.o \ + rcar_du_common.o \ + rzg2l_du_drv.o \ + rcar_du_encoder.o \ + rcar_du_kms.o \ + rzg2l_du_plane.o \ + rcar-du-drm-$(CONFIG_DRM_RCAR_VSP) += rcar_du_vsp.o rcar-du-drm-$(CONFIG_DRM_RCAR_WRITEBACK) += rcar_du_writeback.o +rzg2l-du-drm-$(CONFIG_DRM_RCAR_VSP)+= rcar_du_vsp.o +rzg2l-du-drm-$(CONFIG_DRM_RCAR_WRITEBACK) += rcar_du_writeback.o + obj-$(CONFIG_DRM_RCAR_CMM) += rcar_cmm.o obj-$(CONFIG_DRM_RCAR_DU) += rcar-du-drm.o obj-$(CONFIG_DRM_RCAR_DW_HDMI) += rcar_dw_hdmi.o obj-$(CONFIG_DRM_RCAR_LVDS)+= rcar_lvds.o obj-$(CONFIG_DRM_RCAR_MIPI_DSI)+= rcar_mipi_dsi.o +obj-$(CONFIG_DRM_RZG2L_DU) += rzg2l-du-drm.o + # 'remote-endpoint' is fixed up at run-time DTC_FLAGS_rcar_du_of_lvds_r8a7790 += -Wno-graph_endpoint DTC_FLAGS_rcar_du_of_lvds_r8a7791 += -Wno-graph_endpoint diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h index 66e8839db708..65c1bf9a7e97 100644 --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h @@ -21,6 +21,7 @@ struct rcar_du_group; struct rcar_du_vsp; +struct reset_control; /** * struct rcar_du_crtc - the C
[PATCH v2 4/7] drm: rcar-du: Move rcar_du_output_name() to rcar_du_common.c
RZ/G2L SoC's does not have group/plane registers compared to RCar, hence it
needs a different CRTC implementation.
Move rcar_du_output_name() to a new common file rcar_du_common.c, So that
the same function can be reused by RZ/G2L SoC later.
Signed-off-by: Biju Das
---
v1->v2:
* No change
RFC->v1:
New patch
---
drivers/gpu/drm/rcar-du/Makefile | 1 +
drivers/gpu/drm/rcar-du/rcar_du_common.c | 30
drivers/gpu/drm/rcar-du/rcar_du_drv.c| 20
3 files changed, 31 insertions(+), 20 deletions(-)
create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_common.c
diff --git a/drivers/gpu/drm/rcar-du/Makefile b/drivers/gpu/drm/rcar-du/Makefile
index e7275b5e7ec8..331e12d65a6b 100644
--- a/drivers/gpu/drm/rcar-du/Makefile
+++ b/drivers/gpu/drm/rcar-du/Makefile
@@ -1,5 +1,6 @@
# SPDX-License-Identifier: GPL-2.0
rcar-du-drm-y := rcar_du_crtc.o \
+rcar_du_common.o \
rcar_du_drv.o \
rcar_du_encoder.o \
rcar_du_group.o \
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_common.c
b/drivers/gpu/drm/rcar-du/rcar_du_common.c
new file mode 100644
index ..f9f9908cda6d
--- /dev/null
+++ b/drivers/gpu/drm/rcar-du/rcar_du_common.c
@@ -0,0 +1,30 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * rcar_du_common.c -- R-Car Display Unit Common
+ *
+ * Copyright (C) 2013-2022 Renesas Electronics Corporation
+ *
+ * Contact: Laurent Pinchart (laurent.pinch...@ideasonboard.com)
+ */
+
+#include "rcar_du_drv.h"
+
+const char *rcar_du_output_name(enum rcar_du_output output)
+{
+ static const char * const names[] = {
+ [RCAR_DU_OUTPUT_DPAD0] = "DPAD0",
+ [RCAR_DU_OUTPUT_DPAD1] = "DPAD1",
+ [RCAR_DU_OUTPUT_DSI0] = "DSI0",
+ [RCAR_DU_OUTPUT_DSI1] = "DSI1",
+ [RCAR_DU_OUTPUT_HDMI0] = "HDMI0",
+ [RCAR_DU_OUTPUT_HDMI1] = "HDMI1",
+ [RCAR_DU_OUTPUT_LVDS0] = "LVDS0",
+ [RCAR_DU_OUTPUT_LVDS1] = "LVDS1",
+ [RCAR_DU_OUTPUT_TCON] = "TCON",
+ };
+
+ if (output >= ARRAY_SIZE(names) || !names[output])
+ return "UNKNOWN";
+
+ return names[output];
+}
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index 4640c356a532..f6e234dafb72 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -591,26 +591,6 @@ static const struct of_device_id rcar_du_of_table[] = {
MODULE_DEVICE_TABLE(of, rcar_du_of_table);
-const char *rcar_du_output_name(enum rcar_du_output output)
-{
- static const char * const names[] = {
- [RCAR_DU_OUTPUT_DPAD0] = "DPAD0",
- [RCAR_DU_OUTPUT_DPAD1] = "DPAD1",
- [RCAR_DU_OUTPUT_DSI0] = "DSI0",
- [RCAR_DU_OUTPUT_DSI1] = "DSI1",
- [RCAR_DU_OUTPUT_HDMI0] = "HDMI0",
- [RCAR_DU_OUTPUT_HDMI1] = "HDMI1",
- [RCAR_DU_OUTPUT_LVDS0] = "LVDS0",
- [RCAR_DU_OUTPUT_LVDS1] = "LVDS1",
- [RCAR_DU_OUTPUT_TCON] = "TCON",
- };
-
- if (output >= ARRAY_SIZE(names) || !names[output])
- return "UNKNOWN";
-
- return names[output];
-}
-
/*
-
* DRM operations
*/
--
2.17.1
Re: [PATCH 07/22] drm/gma500: Use drm_mode_copy()
On Fri, Feb 18, 2022 at 11:04 AM Ville Syrjala
wrote:
>
> From: Ville Syrjälä
>
> struct drm_display_mode embeds a list head, so overwriting
> the full struct with another one will corrupt the list
> (if the destination mode is on a list). Use drm_mode_copy()
> instead which explicitly preserves the list head of
> the destination mode.
>
> Even if we know the destination mode is not on any list
> using drm_mode_copy() seems decent as it sets a good
> example. Bad examples of not using it might eventually
> get copied into code where preserving the list head
> actually matters.
>
> Obviously one case not covered here is when the mode
> itself is embedded in a larger structure and the whole
> structure is copied. But if we are careful when copying
> into modes embedded in structures I think we can be a
> little more reassured that bogus list heads haven't been
> propagated in.
>
> @is_mode_copy@
> @@
> drm_mode_copy(...)
> {
> ...
> }
>
> @depends on !is_mode_copy@
> struct drm_display_mode *mode;
> expression E, S;
> @@
> (
> - *mode = E
> + drm_mode_copy(mode, &E)
> |
> - memcpy(mode, E, S)
> + drm_mode_copy(mode, E)
> )
>
> @depends on !is_mode_copy@
> struct drm_display_mode mode;
> expression E;
> @@
> (
> - mode = E
> + drm_mode_copy(&mode, &E)
> |
> - memcpy(&mode, E, S)
> + drm_mode_copy(&mode, E)
> )
>
> @@
> struct drm_display_mode *mode;
> @@
> - &*mode
> + mode
>
> Cc: Patrik Jakobsson
> Signed-off-by: Ville Syrjälä
Looks good. Thanks!
Acked-by: Patrik Jakobsson
> ---
> drivers/gpu/drm/gma500/oaktrail_crtc.c | 8 ++--
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/gma500/oaktrail_crtc.c
> b/drivers/gpu/drm/gma500/oaktrail_crtc.c
> index 36c7c2686c90..79fc602b35bc 100644
> --- a/drivers/gpu/drm/gma500/oaktrail_crtc.c
> +++ b/drivers/gpu/drm/gma500/oaktrail_crtc.c
> @@ -385,12 +385,8 @@ static int oaktrail_crtc_mode_set(struct drm_crtc *crtc,
> if (!gma_power_begin(dev, true))
> return 0;
>
> - memcpy(&gma_crtc->saved_mode,
> - mode,
> - sizeof(struct drm_display_mode));
> - memcpy(&gma_crtc->saved_adjusted_mode,
> - adjusted_mode,
> - sizeof(struct drm_display_mode));
> + drm_mode_copy(&gma_crtc->saved_mode, mode);
> + drm_mode_copy(&gma_crtc->saved_adjusted_mode, adjusted_mode);
>
> list_for_each_entry(connector, &mode_config->connector_list, head) {
> if (!connector->encoder || connector->encoder->crtc != crtc)
> --
> 2.34.1
>
Re: [RFC PATCH 5/7] drm/ttm: add range busy check for range manager
On 16/03/2022 09:54, Christian König wrote:
Am 15.03.22 um 19:04 schrieb Robert Beckett:
RFC: do we want this to become a generic interface in
ttm_resource_manager_func?
RFC: would we prefer a different interface? e.g.
for_each_resource_in_range or for_each_bo_in_range
Well completely NAK to that. Why do you need that?
The long term goal is to completely remove the range checks from TTM
instead.
ah, I did not know that.
I wanted it just to enable parity with a selftest that checks whether a
range is allocated before initializing a given range with test data
behind the allocator's back. It needs to check the range so that it
doesn't destroy in use data.
I suppose we could add another drm_mm range tracker just for testing and
shadow track each allocation in the range, but that seemed like a lot of
extra infrastructure for no general runtime use.
would you mind explaining the rationale for removing range checks? It
seems to me like a natural fit for a memory manager
Regards,
Christian.
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/ttm/ttm_range_manager.c | 21 +
include/drm/ttm/ttm_range_manager.h | 3 +++
2 files changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/ttm/ttm_range_manager.c
b/drivers/gpu/drm/ttm/ttm_range_manager.c
index 8cd4f3fb9f79..5662627bb933 100644
--- a/drivers/gpu/drm/ttm/ttm_range_manager.c
+++ b/drivers/gpu/drm/ttm/ttm_range_manager.c
@@ -206,3 +206,24 @@ int ttm_range_man_fini_nocheck(struct ttm_device
*bdev,
return 0;
}
EXPORT_SYMBOL(ttm_range_man_fini_nocheck);
+
+/**
+ * ttm_range_man_range_busy - Check whether anything is allocated
with a range
+ *
+ * @man: memory manager to check
+ * @fpfn: first page number to check
+ * @lpfn: last page number to check
+ *
+ * Return: true if anything allocated within the range, false otherwise.
+ */
+bool ttm_range_man_range_busy(struct ttm_resource_manager *man,
+ unsigned fpfn, unsigned lpfn)
+{
+ struct ttm_range_manager *rman = to_range_manager(man);
+ struct drm_mm *mm = &rman->mm;
+
+ if (__drm_mm_interval_first(mm, PFN_PHYS(fpfn), PFN_PHYS(lpfn +
1) - 1))
+ return true;
+ return false;
+}
+EXPORT_SYMBOL(ttm_range_man_range_busy);
diff --git a/include/drm/ttm/ttm_range_manager.h
b/include/drm/ttm/ttm_range_manager.h
index 7963b957e9ef..86794a3f9101 100644
--- a/include/drm/ttm/ttm_range_manager.h
+++ b/include/drm/ttm/ttm_range_manager.h
@@ -53,4 +53,7 @@ static __always_inline int ttm_range_man_fini(struct
ttm_device *bdev,
BUILD_BUG_ON(__builtin_constant_p(type) && type >=
TTM_NUM_MEM_TYPES);
return ttm_range_man_fini_nocheck(bdev, type);
}
+
+bool ttm_range_man_range_busy(struct ttm_resource_manager *man,
+ unsigned fpfn, unsigned lpfn);
#endif
Re: [Intel-gfx] [PATCH v6 2/2] drm/i915/gem: Don't try to map and fence large scanout buffers (v9)
On 16/03/2022 07:37, Kasireddy, Vivek wrote:
Hi Tvrtko,
On 15/03/2022 07:28, Kasireddy, Vivek wrote:
Hi Tvrtko, Daniel,
On 11/03/2022 09:39, Daniel Vetter wrote:
On Mon, 7 Mar 2022 at 21:38, Vivek Kasireddy wrote:
On platforms capable of allowing 8K (7680 x 4320) modes, pinning 2 or
more framebuffers/scanout buffers results in only one that is mappable/
fenceable. Therefore, pageflipping between these 2 FBs where only one
is mappable/fenceable creates latencies large enough to miss alternate
vblanks thereby producing less optimal framerate.
This mainly happens because when i915_gem_object_pin_to_display_plane()
is called to pin one of the FB objs, the associated vma is identified
as misplaced and therefore i915_vma_unbind() is called which unbinds and
evicts it. This misplaced vma gets subseqently pinned only when
i915_gem_object_ggtt_pin_ww() is called without PIN_MAPPABLE. This
results in a latency of ~10ms and happens every other vblank/repaint cycle.
Therefore, to fix this issue, we try to see if there is space to map
at-least two objects of a given size and return early if there isn't. This
would ensure that we do not try with PIN_MAPPABLE for any objects that
are too big to map thereby preventing unncessary unbind.
Testcase:
Running Weston and weston-simple-egl on an Alderlake_S (ADLS) platform
with a 8K@60 mode results in only ~40 FPS. Since upstream Weston submits
a frame ~7ms before the next vblank, the latencies seen between atomic
commit and flip event are 7, 24 (7 + 16.66), 7, 24. suggesting that
it misses the vblank every other frame.
Here is the ftrace snippet that shows the source of the ~10ms latency:
i915_gem_object_pin_to_display_plane() {
0.102 us |i915_gem_object_set_cache_level();
i915_gem_object_ggtt_pin_ww() {
0.390 us | i915_vma_instance();
0.178 us | i915_vma_misplaced();
i915_vma_unbind() {
__i915_active_wait() {
0.082 us |i915_active_acquire_if_busy();
0.475 us | }
intel_runtime_pm_get() {
0.087 us |intel_runtime_pm_acquire();
0.259 us | }
__i915_active_wait() {
0.085 us |i915_active_acquire_if_busy();
0.240 us | }
__i915_vma_evict() {
ggtt_unbind_vma() {
gen8_ggtt_clear_range() {
10507.255 us |}
10507.689 us | }
10508.516 us | }
v2: Instead of using bigjoiner checks, determine whether a scanout
buffer is too big by checking to see if it is possible to map
two of them into the ggtt.
v3 (Ville):
- Count how many fb objects can be fit into the available holes
instead of checking for a hole twice the object size.
- Take alignment constraints into account.
- Limit this large scanout buffer check to >= Gen 11 platforms.
v4:
- Remove existing heuristic that checks just for size. (Ville)
- Return early if we find space to map at-least two objects. (Tvrtko)
- Slightly update the commit message.
v5: (Tvrtko)
- Rename the function to indicate that the object may be too big to
map into the aperture.
- Account for guard pages while calculating the total size required
for the object.
- Do not subject all objects to the heuristic check and instead
consider objects only of a certain size.
- Do the hole walk using the rbtree.
- Preserve the existing PIN_NONBLOCK logic.
- Drop the PIN_MAPPABLE check while pinning the VMA.
v6: (Tvrtko)
- Return 0 on success and the specific error code on failure to
preserve the existing behavior.
v7: (Ville)
- Drop the HAS_GMCH(i915), DISPLAY_VER(i915) < 11 and
size < ggtt->mappable_end / 4 checks.
- Drop the redundant check that is based on previous heuristic.
v8:
- Make sure that we are holding the mutex associated with ggtt vm
as we traverse the hole nodes.
v9: (Tvrtko)
- Use mutex_lock_interruptible_nested() instead of mutex_lock().
Cc: Ville Syrjälä
Cc: Maarten Lankhorst
Cc: Tvrtko Ursulin
Cc: Manasi Navare
Reviewed-by: Tvrtko Ursulin
Signed-off-by: Vivek Kasireddy
---
drivers/gpu/drm/i915/i915_gem.c | 128 +++-
1 file changed, 94 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 9747924cc57b..e0d731b3f215 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -49,6 +49,7 @@
#include "gem/i915_gem_pm.h"
#include "gem/i915_gem_region.h"
#include "gem/i915_gem_userptr.h"
+#include "gem/i915_gem_tiling.h"
#include "gt/intel_engine_user.h"
#include "gt/intel_gt.h"
#include "gt/intel_gt_pm.h"
@@ -882,6 +883,96 @@ static void discard_ggtt_vma(struct i915_vma *vma)
spin_unlock(&obj->vma.lock);
}
+static int
+i915_gem_object_fits_in_aperture(struct drm_i915_gem_object *obj,
+u64 alignment, u64 flags)
Tvrtko as
Re: [PATCH v8 18/19] drm/mediatek: change the aux retries times when receiving AUX_DEFER
On Fri, Feb 18, 2022 at 11:15 PM Guillaume Ranquet wrote: > > From: Jitao Shi > > DP 1.4a Section 2.8.7.1.5.6.1: > A DP Source device shall retry at least seven times upon receiving > AUX_DEFER before giving up the AUX transaction. > > Aux should retry to send msg whether how many bytes. > > Signed-off-by: Jitao Shi > Signed-off-by: Guillaume Ranquet Reviewed-by: Chen-Yu Tsai
Re: [RFC PATCH 5/7] drm/ttm: add range busy check for range manager
Am 16.03.22 um 14:19 schrieb Robert Beckett:
On 16/03/2022 09:54, Christian König wrote:
Am 15.03.22 um 19:04 schrieb Robert Beckett:
RFC: do we want this to become a generic interface in
ttm_resource_manager_func?
RFC: would we prefer a different interface? e.g.
for_each_resource_in_range or for_each_bo_in_range
Well completely NAK to that. Why do you need that?
The long term goal is to completely remove the range checks from TTM
instead.
ah, I did not know that.
I wanted it just to enable parity with a selftest that checks whether
a range is allocated before initializing a given range with test data
behind the allocator's back. It needs to check the range so that it
doesn't destroy in use data.
Mhm, of hand that doesn't sounds like a valid test case. Do you have the
code at hand?
I suppose we could add another drm_mm range tracker just for testing
and shadow track each allocation in the range, but that seemed like a
lot of extra infrastructure for no general runtime use.
I have no idea what you mean with that.
would you mind explaining the rationale for removing range checks? It
seems to me like a natural fit for a memory manager
TTM manages buffer objects and resources, not address space. The
lpfn/fpfn parameter for the resource allocators are actually used as
just two independent parameters and not define any range. We just keep
the names for historical reasons.
The only places we still use and compare them as ranges are
ttm_resource_compat() and ttm_bo_eviction_valuable() and I already have
patches to clean up those and move them into the backend resource handling.
Regards,
Christian.
Regards,
Christian.
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/ttm/ttm_range_manager.c | 21 +
include/drm/ttm/ttm_range_manager.h | 3 +++
2 files changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/ttm/ttm_range_manager.c
b/drivers/gpu/drm/ttm/ttm_range_manager.c
index 8cd4f3fb9f79..5662627bb933 100644
--- a/drivers/gpu/drm/ttm/ttm_range_manager.c
+++ b/drivers/gpu/drm/ttm/ttm_range_manager.c
@@ -206,3 +206,24 @@ int ttm_range_man_fini_nocheck(struct
ttm_device *bdev,
return 0;
}
EXPORT_SYMBOL(ttm_range_man_fini_nocheck);
+
+/**
+ * ttm_range_man_range_busy - Check whether anything is allocated
with a range
+ *
+ * @man: memory manager to check
+ * @fpfn: first page number to check
+ * @lpfn: last page number to check
+ *
+ * Return: true if anything allocated within the range, false
otherwise.
+ */
+bool ttm_range_man_range_busy(struct ttm_resource_manager *man,
+ unsigned fpfn, unsigned lpfn)
+{
+ struct ttm_range_manager *rman = to_range_manager(man);
+ struct drm_mm *mm = &rman->mm;
+
+ if (__drm_mm_interval_first(mm, PFN_PHYS(fpfn), PFN_PHYS(lpfn +
1) - 1))
+ return true;
+ return false;
+}
+EXPORT_SYMBOL(ttm_range_man_range_busy);
diff --git a/include/drm/ttm/ttm_range_manager.h
b/include/drm/ttm/ttm_range_manager.h
index 7963b957e9ef..86794a3f9101 100644
--- a/include/drm/ttm/ttm_range_manager.h
+++ b/include/drm/ttm/ttm_range_manager.h
@@ -53,4 +53,7 @@ static __always_inline int
ttm_range_man_fini(struct ttm_device *bdev,
BUILD_BUG_ON(__builtin_constant_p(type) && type >=
TTM_NUM_MEM_TYPES);
return ttm_range_man_fini_nocheck(bdev, type);
}
+
+bool ttm_range_man_range_busy(struct ttm_resource_manager *man,
+ unsigned fpfn, unsigned lpfn);
#endif
Re: [PATCH v2 4/8] drm/virtio: Improve DMA API usage for shmem BOs
On 3/16/22 15:41, Robin Murphy wrote:
> On 2022-03-14 22:42, Dmitry Osipenko wrote:
>> DRM API requires the DRM's driver to be backed with the device that can
>> be used for generic DMA operations. The VirtIO-GPU device can't perform
>> DMA operations if it uses PCI transport because PCI device driver creates
>> a virtual VirtIO-GPU device that isn't associated with the PCI. Use PCI's
>> GPU device for the DRM's device instead of the VirtIO-GPU device and drop
>> DMA-related hacks from the VirtIO-GPU driver.
>>
>> Signed-off-by: Dmitry Osipenko
>> ---
>> drivers/gpu/drm/virtio/virtgpu_drv.c | 22 +++---
>> drivers/gpu/drm/virtio/virtgpu_drv.h | 5 +--
>> drivers/gpu/drm/virtio/virtgpu_kms.c | 7 ++--
>> drivers/gpu/drm/virtio/virtgpu_object.c | 56 +
>> drivers/gpu/drm/virtio/virtgpu_vq.c | 13 +++---
>> 5 files changed, 37 insertions(+), 66 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c
>> b/drivers/gpu/drm/virtio/virtgpu_drv.c
>> index 5f25a8d15464..8449dad3e65c 100644
>> --- a/drivers/gpu/drm/virtio/virtgpu_drv.c
>> +++ b/drivers/gpu/drm/virtio/virtgpu_drv.c
>> @@ -46,9 +46,9 @@ static int virtio_gpu_modeset = -1;
>> MODULE_PARM_DESC(modeset, "Disable/Enable modesetting");
>> module_param_named(modeset, virtio_gpu_modeset, int, 0400);
>> -static int virtio_gpu_pci_quirk(struct drm_device *dev, struct
>> virtio_device *vdev)
>> +static int virtio_gpu_pci_quirk(struct drm_device *dev)
>> {
>> - struct pci_dev *pdev = to_pci_dev(vdev->dev.parent);
>> + struct pci_dev *pdev = to_pci_dev(dev->dev);
>> const char *pname = dev_name(&pdev->dev);
>> bool vga = (pdev->class >> 8) == PCI_CLASS_DISPLAY_VGA;
>> char unique[20];
>> @@ -101,6 +101,7 @@ static int virtio_gpu_pci_quirk(struct drm_device
>> *dev, struct virtio_device *vd
>> static int virtio_gpu_probe(struct virtio_device *vdev)
>> {
>> struct drm_device *dev;
>> + struct device *dma_dev;
>> int ret;
>> if (drm_firmware_drivers_only() && virtio_gpu_modeset == -1)
>> @@ -109,18 +110,29 @@ static int virtio_gpu_probe(struct virtio_device
>> *vdev)
>> if (virtio_gpu_modeset == 0)
>> return -EINVAL;
>> - dev = drm_dev_alloc(&driver, &vdev->dev);
>> + /*
>> + * If GPU's parent is a PCI device, then we will use this PCI device
>> + * for the DRM's driver device because GPU won't have PCI's IOMMU
>> DMA
>> + * ops in this case since GPU device is sitting on a separate
>> (from PCI)
>> + * virtio-bus.
>> + */
>> + if (!strcmp(vdev->dev.parent->bus->name, "pci"))
>
> Nit: dev_is_pci() ?
Yes, thank you.
> However, what about other VirtIO transports? Wouldn't virtio-mmio with
> F_ACCESS_PLATFORM be in a similar situation?
I couldn't find anyone using virtio-mmio for the GPU, both Qemu and
crosvm support only PCI transport for GPU.
But I'm now looking at virtio_mmio_probe() and see that virtio-mmio
devices actually should be in the exactly same position as PCI devices.
So you should be right and we need to use vdev->dev.parent for the DRM
device universally. I'll improve it in the v3, thank you again.
Re: [PATCH v8 09/24] drm/rockchip: dw_hdmi: Add support for niu clk
On 2022-03-16 13:01, Dmitry Osipenko wrote: On 3/16/22 12:12, Sascha Hauer wrote: On Mon, Mar 14, 2022 at 08:54:27PM +0300, Dmitry Osipenko wrote: On 3/14/22 11:18, Sascha Hauer wrote: On Sun, Mar 13, 2022 at 12:07:56AM +0300, Dmitry Osipenko wrote: On 3/11/22 11:33, Sascha Hauer wrote: The rk3568 HDMI has an additional clock that needs to be enabled for the HDMI controller to work. This clock is not needed for the HDMI controller itself, but to make the SoC internal bus logic work. From the reference manual: 2.8.6 NIU Clock gating reliance A part of niu clocks have a dependence on another niu clock in order to sharing the internal bus. When these clocks are in use, another niu clock must be opened, and cannot be gated. These clocks and the special clock on which they are relied are as following: Clocks which have dependency The clock which can not be gated - ... pclk_vo_niu, hclk_vo_s_niu hclk_vo_niu ... The clock framework does not support turning on a clock whenever another clock is turned on, so this patch adds support for the dependent clock to the HDMI driver. We call it "NIU", which is for "Native Interface Unit" This still doesn't make sense to me. You're saying that "pclk_vo_niu, hclk_vo_s_niu" depend on "hclk_vo_niu", but HDMI doesn't use pclk_vo, it uses pclk_hdmi. pclk_hdmi_host is a child clock of pclk_vo: aclk_vo 220 3 0 0 5 Y aclk_hdcp 000 3 0 0 5 N pclk_vo 2307500 0 0 5 Y pclk_edp_ctrl 0007500 0 0 5 N pclk_dsitx_1 0007500 0 0 5 N pclk_dsitx_0 1207500 0 0 5 Y pclk_hdmi_host 1207500 0 0 5 Y pclk_hdcp 0007500 0 0 5 N hclk_vo 250 15000 0 0 5 Y hclk_hdcp 000 15000 0 0 5 N hclk_vop 020 15000 0 0 5 N It was unclear that the pclk_hdmi is the child of pclk_vo by looking at the clk driver's code, thank you! Won't be better if the implicit clk dependency would be handled internally by the RK clk driver? I have considered handling something like coupled clocks in the clock framework, but I have not yet considered handling this internally in the Rockchip clock driver. I just had a quick look at the driver. While it sounds like an easy task to enable gate A whenever gate B is enabled I haven't found a good way to integrate that into the clk driver. It seems to me that it's not easier to implement in the clk driver than it is to implement it in the clk framework where it could be used by others as well. For example, by making the common gate shared/refcounted. Have you considered this variant? Then we won't need to change the DT bindings. For the DT bindings it is just an additional clock. Should we have a better way to handle that case in the future we could simply ignore the additional clock. I wouldn't bother too much about this. To me that NIU quirk should be internal to the clk h/w module, so it doesn't feel nice to mix the clk h/w description with the HDMI h/w description. On the other hand, making clk driver to handle this case indeed will take some effort as I see now. For example, clk driver of NVIDIA Tegra has concept of shared gates, but bringing it to the RK clk driver will be quite messy. From a quick look, it seems like it could be straightforward conceptually at least. Presumably: subclass clk_gate_ops to enable/disable a required clock before enabling/disabling normally, have rockchip_clk_register_branch() resolve an optional required clock and pick gate_ops as appropriate, then the rest is basically just boilerplate for describing the dependencies in the first place. However I'd agree that in practical implementation terms it does look even simpler and cleaner for the clk_hw abstraction to provide the appropriate ops and resolution itself. Alright, let's work around the clk limitation like you're suggesting. I agree that it shouldn't really be a problem to deprecate the extra clock later on. If there's a realistic chance that someone will actually work on a proper coupled/dependent/whatever clock abstraction before the rest of RK3588 is supported well enough for mainline users to start really caring about power efficiency, then arguably the simplest and cleanest workaround would be the other option t
Re: [PATCH v8 09/24] drm/rockchip: dw_hdmi: Add support for niu clk
On 3/16/22 16:55, Robin Murphy wrote: >> To me that NIU quirk should be internal to the clk h/w module, so it >> doesn't feel nice to mix the clk h/w description with the HDMI h/w >> description. >> >> On the other hand, making clk driver to handle this case indeed will >> take some effort as I see now. For example, clk driver of NVIDIA Tegra >> has concept of shared gates, but bringing it to the RK clk driver will >> be quite messy. > > From a quick look, it seems like it could be straightforward > conceptually at least. Presumably: subclass clk_gate_ops to > enable/disable a required clock before enabling/disabling normally, have > rockchip_clk_register_branch() resolve an optional required clock and > pick gate_ops as appropriate, then the rest is basically just > boilerplate for describing the dependencies in the first place. However > I'd agree that in practical implementation terms it does look even > simpler and cleaner for the clk_hw abstraction to provide the > appropriate ops and resolution itself. > >> Alright, let's work around the clk limitation like you're suggesting. I >> agree that it shouldn't really be a problem to deprecate the extra clock >> later on. > > If there's a realistic chance that someone will actually work on a > proper coupled/dependent/whatever clock abstraction before the rest of > RK3588 is supported well enough for mainline users to start really > caring about power efficiency, then arguably the simplest and cleanest > workaround would be the other option that Elaine mentioned, of just > marking hclk_vo as critical for now. If it's likely to turn into a > "nothing's as permanent as a temporary fix" situation, though, then the > DT binding has less functional impact, even if it does leave us > developers with baggage down the line. I missed that suggestion about marking hclk_vo as critical. That's a good idea, I like it.
Re: [PATCH v2 1/2] drm: Add GPU reset sysfs event
On Wed, Mar 16, 2022 at 4:48 AM Pekka Paalanen wrote: > > On Tue, 15 Mar 2022 10:54:38 -0400 > Alex Deucher wrote: > > > On Mon, Mar 14, 2022 at 11:26 AM Pekka Paalanen wrote: > > > > > > On Mon, 14 Mar 2022 10:23:27 -0400 > > > Alex Deucher wrote: > > > > > > > On Fri, Mar 11, 2022 at 3:30 AM Pekka Paalanen > > > > wrote: > > > > > > > > > > On Thu, 10 Mar 2022 11:56:41 -0800 > > > > > Rob Clark wrote: > > > > > > > > > > > For something like just notifying a compositor that a gpu crash > > > > > > happened, perhaps drm_event is more suitable. See > > > > > > virtio_gpu_fence_event_create() for an example of adding new event > > > > > > types. Although maybe you want it to be an event which is not > > > > > > device > > > > > > specific. This isn't so much of a debugging use-case as simply > > > > > > notification. > > > > > > > > > > Hi, > > > > > > > > > > for this particular use case, are we now talking about the display > > > > > device (KMS) crashing or the rendering device (OpenGL/Vulkan) > > > > > crashing? > > > > > > > > > > If the former, I wasn't aware that display device crashes are a thing. > > > > > How should a userspace display server react to those? > > > > > > > > > > If the latter, don't we have EGL extensions or Vulkan API already to > > > > > deliver that? > > > > > > > > > > The above would be about device crashes that directly affect the > > > > > display server. Is that the use case in mind here, or is it instead > > > > > about notifying the display server that some application has caused a > > > > > driver/hardware crash? If the latter, how should a display server > > > > > react > > > > > to that? Disconnect the application? > > > > > > > > > > Shashank, what is the actual use case you are developing this for? > > > > > > > > > > I've read all the emails here so far, and I don't recall seeing it > > > > > explained. > > > > > > > > > > > > > The idea is that a support daemon or compositor would listen for GPU > > > > reset notifications and do something useful with them (kill the guilty > > > > app, restart the desktop environment, etc.). Today when the GPU > > > > resets, most applications just continue assuming nothing is wrong, > > > > meanwhile the GPU has stopped accepting work until the apps re-init > > > > their context so all of their command submissions just get rejected. > > > > > > > > > Btw. somewhat relatedly, there has been work aiming to allow > > > > > graceful hot-unplug of DRM devices. There is a kernel doc outlining > > > > > how > > > > > the various APIs should react towards userspace when a DRM device > > > > > suddenly disappears. That seems to have some overlap here IMO. > > > > > > > > > > See > > > > > https://www.kernel.org/doc/html/latest/gpu/drm-uapi.html#device-hot-unplug > > > > > which also has a couple pointers to EGL and Vulkan APIs. > > > > > > > > The problem is most applications don't use the GL or VK robustness > > > > APIs. > > > > > > Hi, > > > > > > how would this new event help with that? > > > > This event would provide notification that a GPU reset occurred. > > > > > > > > I mean, yeah, there could be a daemon that kills those GPU users, but > > > then what? You still lose any unsaved work, and may need to manually > > > restart them. > > > > > > Is the idea that it is better to have the app crash and disappear than > > > to look like it froze while it otherwise still runs? > > > > Yes. > > Ok. That was just a wild guess. > > > The daemon could also send the user some sort of notification > > that a GPU reset occurred. > > > > > > > > If some daemon or compositor goes killing apps that trigger GPU resets, > > > then how do we stop that for an app that actually does use the > > > appropriate EGL or Vulkan APIs to detect and remedy that situation > > > itself? > > > > I guess the daemon could keep some sort of whitelist. OTOH, very few > > if any applications, especially games actually support these > > extensions. > > I would think that a white-list is a non-starter due to the maintenance > nightmare and the "wrong by default" design for well behaving programs. > > I am not a fan of optimising for broken software. I understand that > with games this is routine, but we're talking about everything here, > not just games. Games cannot be fixed, but the rest could if the > problem was not sweeped under the rug. It's like the inverse of the > platform problem. Fair enough, but it hasn't happened in the last 15 years or so. > > > > > You could use something like that in the compositor, but those > > > > APIs tend to be focused more on the application itself rather than the > > > > GPU in general. E.g., Is my context lost. Which is fine for > > > > restarting your context, but doesn't really help if you want to try > > > > and do something with another application (i.e., the likely guilty > > > > app). Also, on dGPU at least, when you reset the GPU, vram is usually > > > > lost (either due to the memory controller bein
Re: [PATCH v2 7/8] drm/virtio: Support memory shrinking
On 3/15/22 15:43, Emil Velikov wrote:
> Greetings everyone,
>
> Food for thought: Would it make sense to have the madvise ioctl as
> generic DRM one?
> Looking around - i915, msm & panfrost already have one and the virtio
> implementation [below] seems as generic as it gets.
>
> On Mon, 14 Mar 2022 at 22:44, Dmitry Osipenko
> wrote:
>
>> +#define VIRTGPU_MADV_WILLNEED 0
>> +#define VIRTGPU_MADV_DONTNEED 1
>> +struct drm_virtgpu_madvise {
>> + __u32 bo_handle;
>> + __u32 retained; /* out, non-zero if BO can be used */
>> + __u32 madv;
>> + __u32 pad;
>
> This seems to be based on panfrost/msm yet names (bo_handle vs
> handle), layout and documentation varies.
> Why is that - copy/paste is cheap :-P
Indeed, there is copy/pasting among drivers. But I'm doubtful about
making madvise a generic ioctl because some drivers already have own
ioctl for that and h/w capabilities vary, so some drivers may want to
have extra features later on and then this doesn't feel like a common
thing anymore.
Re: [RFC PATCH 5/7] drm/ttm: add range busy check for range manager
On 16/03/2022 13:43, Christian König wrote:
Am 16.03.22 um 14:19 schrieb Robert Beckett:
On 16/03/2022 09:54, Christian König wrote:
Am 15.03.22 um 19:04 schrieb Robert Beckett:
RFC: do we want this to become a generic interface in
ttm_resource_manager_func?
RFC: would we prefer a different interface? e.g.
for_each_resource_in_range or for_each_bo_in_range
Well completely NAK to that. Why do you need that?
The long term goal is to completely remove the range checks from TTM
instead.
ah, I did not know that.
I wanted it just to enable parity with a selftest that checks whether
a range is allocated before initializing a given range with test data
behind the allocator's back. It needs to check the range so that it
doesn't destroy in use data.
Mhm, of hand that doesn't sounds like a valid test case. Do you have the
code at hand?
https://patchwork.freedesktop.org/patch/478347/?series=101396&rev=1
this is where I replace an existing range check via drm_mm with the
range check I added in this patch.
I suppose we could add another drm_mm range tracker just for testing
and shadow track each allocation in the range, but that seemed like a
lot of extra infrastructure for no general runtime use.
I have no idea what you mean with that.
I meant as a potential solution to tracking allocations without a range
check, we would need to add something external. e.g. adding a shadow
drm_mm range tracker, or a bitmask across the range, or stick objects in
a list etc.
would you mind explaining the rationale for removing range checks? It
seems to me like a natural fit for a memory manager
TTM manages buffer objects and resources, not address space. The
lpfn/fpfn parameter for the resource allocators are actually used as
just two independent parameters and not define any range. We just keep
the names for historical reasons.
The only places we still use and compare them as ranges are
ttm_resource_compat() and ttm_bo_eviction_valuable() and I already have
patches to clean up those and move them into the backend resource handling.
except the ttm_range_manager seems to still use them as a range specifier.
If the general design going forward is to not consider ranges, how would
you recommend constructing buffers around pre-allocated regions e.g.
uefi frame buffers who's range is dictated externally?
Regards,
Christian.
Regards,
Christian.
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/ttm/ttm_range_manager.c | 21 +
include/drm/ttm/ttm_range_manager.h | 3 +++
2 files changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/ttm/ttm_range_manager.c
b/drivers/gpu/drm/ttm/ttm_range_manager.c
index 8cd4f3fb9f79..5662627bb933 100644
--- a/drivers/gpu/drm/ttm/ttm_range_manager.c
+++ b/drivers/gpu/drm/ttm/ttm_range_manager.c
@@ -206,3 +206,24 @@ int ttm_range_man_fini_nocheck(struct
ttm_device *bdev,
return 0;
}
EXPORT_SYMBOL(ttm_range_man_fini_nocheck);
+
+/**
+ * ttm_range_man_range_busy - Check whether anything is allocated
with a range
+ *
+ * @man: memory manager to check
+ * @fpfn: first page number to check
+ * @lpfn: last page number to check
+ *
+ * Return: true if anything allocated within the range, false
otherwise.
+ */
+bool ttm_range_man_range_busy(struct ttm_resource_manager *man,
+ unsigned fpfn, unsigned lpfn)
+{
+ struct ttm_range_manager *rman = to_range_manager(man);
+ struct drm_mm *mm = &rman->mm;
+
+ if (__drm_mm_interval_first(mm, PFN_PHYS(fpfn), PFN_PHYS(lpfn +
1) - 1))
+ return true;
+ return false;
+}
+EXPORT_SYMBOL(ttm_range_man_range_busy);
diff --git a/include/drm/ttm/ttm_range_manager.h
b/include/drm/ttm/ttm_range_manager.h
index 7963b957e9ef..86794a3f9101 100644
--- a/include/drm/ttm/ttm_range_manager.h
+++ b/include/drm/ttm/ttm_range_manager.h
@@ -53,4 +53,7 @@ static __always_inline int
ttm_range_man_fini(struct ttm_device *bdev,
BUILD_BUG_ON(__builtin_constant_p(type) && type >=
TTM_NUM_MEM_TYPES);
return ttm_range_man_fini_nocheck(bdev, type);
}
+
+bool ttm_range_man_range_busy(struct ttm_resource_manager *man,
+ unsigned fpfn, unsigned lpfn);
#endif
Re: [PATCH v8 09/24] drm/rockchip: dw_hdmi: Add support for niu clk
On Wed, Mar 16, 2022 at 04:01:49PM +0300, Dmitry Osipenko wrote: > On 3/16/22 12:12, Sascha Hauer wrote: > > On Mon, Mar 14, 2022 at 08:54:27PM +0300, Dmitry Osipenko wrote: > >> On 3/14/22 11:18, Sascha Hauer wrote: > >>> On Sun, Mar 13, 2022 at 12:07:56AM +0300, Dmitry Osipenko wrote: > On 3/11/22 11:33, Sascha Hauer wrote: > > The rk3568 HDMI has an additional clock that needs to be enabled for the > > HDMI controller to work. This clock is not needed for the HDMI > > controller itself, but to make the SoC internal bus logic work. From the > > reference manual: > > > >> 2.8.6 NIU Clock gating reliance > >> > >> A part of niu clocks have a dependence on another niu clock in order to > >> sharing the internal bus. When these clocks are in use, another niu > >> clock must be opened, and cannot be gated. These clocks and the > >> special > >> clock on which they are relied are as following: > >> > >> Clocks which have dependency The clock which can not be gated > >> - > >> ... > >> pclk_vo_niu, hclk_vo_s_niu hclk_vo_niu > >> ... > > The clock framework does not support turning on a clock whenever another > > clock is turned on, so this patch adds support for the dependent clock > > to the HDMI driver. We call it "NIU", which is for "Native Interface > > Unit" > > This still doesn't make sense to me. You're saying that "pclk_vo_niu, > hclk_vo_s_niu" depend on "hclk_vo_niu", but HDMI doesn't use pclk_vo, it > uses pclk_hdmi. > >>> > >>> pclk_hdmi_host is a child clock of pclk_vo: > >>> > >>> aclk_vo 220 3 0 > >>>0 5 Y > >>> aclk_hdcp 000 3 0 > >>>0 5 N > >>> pclk_vo 2307500 0 > >>>0 5 Y > >>>pclk_edp_ctrl 0007500 0 > >>>0 5 N > >>>pclk_dsitx_1 0007500 0 > >>>0 5 N > >>>pclk_dsitx_0 1207500 0 > >>>0 5 Y > >>>pclk_hdmi_host 1207500 0 > >>>0 5 Y > >>>pclk_hdcp 0007500 0 > >>>0 5 N > >>> hclk_vo 250 15000 0 > >>>0 5 Y > >>>hclk_hdcp 000 15000 0 > >>>0 5 N > >>>hclk_vop 020 15000 0 > >>>0 5 N > >> > >> It was unclear that the pclk_hdmi is the child of pclk_vo by looking at > >> the clk driver's code, thank you! > >> > >> Won't be better if the implicit clk dependency would be handled > >> internally by the RK clk driver? > > > > I have considered handling something like coupled clocks in the clock > > framework, but I have not yet considered handling this internally in the > > Rockchip clock driver. > > > > I just had a quick look at the driver. While it sounds like an easy task > > to enable gate A whenever gate B is enabled I haven't found a good way to > > integrate that into the clk driver. It seems to me that it's not easier > > to implement in the clk driver than it is to implement it in the clk > > framework where it could be used by others as well. > > > >> For example, by making the common gate > >> shared/refcounted. Have you considered this variant? Then we won't need > >> to change the DT bindings. > > > > For the DT bindings it is just an additional clock. Should we have a > > better way to handle that case in the future we could simply ignore the > > additional clock. I wouldn't bother too much about this. > > To me that NIU quirk should be internal to the clk h/w module, so it > doesn't feel nice to mix the clk h/w description with the HDMI h/w > description. > > On the other hand, making clk driver to handle this case indeed will > take some effort as I see now. For example, clk driver of NVIDIA Tegra > has concept of shared gates, but bringing it to the RK clk driver will > be quite messy. > > Alright, let's work around the clk limitation like you're suggesting. I > agree that it shouldn't really be a problem to deprecate the extra clock > later on. > > I have last questions.. > > 1. Previously you said that the PD driver takes care of enabling all the > clocks it can find in the device by itself on RPM-resume, then why HDMI > driver needs to enable the clock explicitly? The PD driver only does so when the device has pm_runtime enabled. Currently that's not the case for the hdmi driver. That could be changed of course, but I am
Re: [RFC PATCH 5/7] drm/ttm: add range busy check for range manager
Am 16.03.22 um 15:26 schrieb Robert Beckett:
[SNIP]
this is where I replace an existing range check via drm_mm with the
range check I added in this patch.
Mhm, I still don't get the use case from the code, but I don't think it
matters any more.
I suppose we could add another drm_mm range tracker just for testing
and shadow track each allocation in the range, but that seemed like
a lot of extra infrastructure for no general runtime use.
I have no idea what you mean with that.
I meant as a potential solution to tracking allocations without a
range check, we would need to add something external. e.g. adding a
shadow drm_mm range tracker, or a bitmask across the range, or stick
objects in a list etc.
Ah! So you are trying to get access to the drm_mm inside the
ttm_range_manager and not add some additional range check function! Now
I got your use case.
would you mind explaining the rationale for removing range checks?
It seems to me like a natural fit for a memory manager
TTM manages buffer objects and resources, not address space. The
lpfn/fpfn parameter for the resource allocators are actually used as
just two independent parameters and not define any range. We just
keep the names for historical reasons.
The only places we still use and compare them as ranges are
ttm_resource_compat() and ttm_bo_eviction_valuable() and I already
have patches to clean up those and move them into the backend
resource handling.
except the ttm_range_manager seems to still use them as a range specifier.
Yeah, because the range manager is the backend which handles ranges
using the drm_mm :)
If the general design going forward is to not consider ranges, how
would you recommend constructing buffers around pre-allocated regions
e.g. uefi frame buffers who's range is dictated externally?
Call ttm_bo_mem_space() with the fpfn/lpfn filled in as required. See
function amdgpu_bo_create_kernel_at() for an example.
Regards,
Christian.
Regards,
Christian.
Regards,
Christian.
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/ttm/ttm_range_manager.c | 21 +
include/drm/ttm/ttm_range_manager.h | 3 +++
2 files changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/ttm/ttm_range_manager.c
b/drivers/gpu/drm/ttm/ttm_range_manager.c
index 8cd4f3fb9f79..5662627bb933 100644
--- a/drivers/gpu/drm/ttm/ttm_range_manager.c
+++ b/drivers/gpu/drm/ttm/ttm_range_manager.c
@@ -206,3 +206,24 @@ int ttm_range_man_fini_nocheck(struct
ttm_device *bdev,
return 0;
}
EXPORT_SYMBOL(ttm_range_man_fini_nocheck);
+
+/**
+ * ttm_range_man_range_busy - Check whether anything is allocated
with a range
+ *
+ * @man: memory manager to check
+ * @fpfn: first page number to check
+ * @lpfn: last page number to check
+ *
+ * Return: true if anything allocated within the range, false
otherwise.
+ */
+bool ttm_range_man_range_busy(struct ttm_resource_manager *man,
+ unsigned fpfn, unsigned lpfn)
+{
+ struct ttm_range_manager *rman = to_range_manager(man);
+ struct drm_mm *mm = &rman->mm;
+
+ if (__drm_mm_interval_first(mm, PFN_PHYS(fpfn), PFN_PHYS(lpfn
+ 1) - 1))
+ return true;
+ return false;
+}
+EXPORT_SYMBOL(ttm_range_man_range_busy);
diff --git a/include/drm/ttm/ttm_range_manager.h
b/include/drm/ttm/ttm_range_manager.h
index 7963b957e9ef..86794a3f9101 100644
--- a/include/drm/ttm/ttm_range_manager.h
+++ b/include/drm/ttm/ttm_range_manager.h
@@ -53,4 +53,7 @@ static __always_inline int
ttm_range_man_fini(struct ttm_device *bdev,
BUILD_BUG_ON(__builtin_constant_p(type) && type >=
TTM_NUM_MEM_TYPES);
return ttm_range_man_fini_nocheck(bdev, type);
}
+
+bool ttm_range_man_range_busy(struct ttm_resource_manager *man,
+ unsigned fpfn, unsigned lpfn);
#endif
Re: [PATCH v2 6/8] drm/shmem-helper: Add generic memory shrinker
On 14/03/2022 22:42, Dmitry Osipenko wrote:
> Introduce a common DRM SHMEM shrinker. It allows to reduce code
> duplication among DRM drivers, it also handles complicated lockings
> for the drivers. This is initial version of the shrinker that covers
> basic needs of GPU drivers.
>
> This patch is based on a couple ideas borrowed from Rob's Clark MSM
> shrinker and Thomas' Zimmermann variant of SHMEM shrinker.
>
> GPU drivers that want to use generic DRM memory shrinker must support
> generic GEM reservations.
>
> Signed-off-by: Daniel Almeida
> Signed-off-by: Dmitry Osipenko
This looks fine to me, but one nitpick: you should update the comment in
struct drm_gem_shmem_object:
> /**
>* @madv: State for madvise
>*
>* 0 is active/inuse.
>* A negative value is the object is purged.
>* Positive values are driver specific and not used by the helpers.
>*/
> int madv;
This is adding a helper which cares about the positive values.
Steve
> ---
> drivers/gpu/drm/drm_gem_shmem_helper.c | 194 +
> include/drm/drm_device.h | 4 +
> include/drm/drm_gem.h | 11 ++
> include/drm/drm_gem_shmem_helper.h | 25
> 4 files changed, 234 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
> b/drivers/gpu/drm/drm_gem_shmem_helper.c
> index 37009418cd28..35be2ee98f11 100644
> --- a/drivers/gpu/drm/drm_gem_shmem_helper.c
> +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
> @@ -139,6 +139,9 @@ void drm_gem_shmem_free(struct drm_gem_shmem_object
> *shmem)
> {
> struct drm_gem_object *obj = &shmem->base;
>
> + /* take out shmem GEM object from the memory shrinker */
> + drm_gem_shmem_madvise(shmem, 0);
> +
> WARN_ON(shmem->vmap_use_count);
>
> if (obj->import_attach) {
> @@ -163,6 +166,42 @@ void drm_gem_shmem_free(struct drm_gem_shmem_object
> *shmem)
> }
> EXPORT_SYMBOL_GPL(drm_gem_shmem_free);
>
> +static void drm_gem_shmem_update_purgeable_status(struct
> drm_gem_shmem_object *shmem)
> +{
> + struct drm_gem_object *obj = &shmem->base;
> + struct drm_gem_shmem_shrinker *gem_shrinker = obj->dev->shmem_shrinker;
> + size_t page_count = obj->size >> PAGE_SHIFT;
> +
> + if (!gem_shrinker || obj->import_attach || !obj->funcs->purge)
> + return;
> +
> + mutex_lock(&shmem->vmap_lock);
> + mutex_lock(&shmem->pages_lock);
> + mutex_lock(&gem_shrinker->lock);
> +
> + if (shmem->madv < 0) {
> + list_del_init(&shmem->madv_list);
> + goto unlock;
> + } else if (shmem->madv > 0) {
> + if (!list_empty(&shmem->madv_list))
> + goto unlock;
> +
> + WARN_ON(gem_shrinker->shrinkable_count + page_count <
> page_count);
> + gem_shrinker->shrinkable_count += page_count;
> +
> + list_add_tail(&shmem->madv_list, &gem_shrinker->lru);
> + } else if (!list_empty(&shmem->madv_list)) {
> + list_del_init(&shmem->madv_list);
> +
> + WARN_ON(gem_shrinker->shrinkable_count < page_count);
> + gem_shrinker->shrinkable_count -= page_count;
> + }
> +unlock:
> + mutex_unlock(&gem_shrinker->lock);
> + mutex_unlock(&shmem->pages_lock);
> + mutex_unlock(&shmem->vmap_lock);
> +}
> +
> static int drm_gem_shmem_get_pages_locked(struct drm_gem_shmem_object *shmem)
> {
> struct drm_gem_object *obj = &shmem->base;
> @@ -366,6 +405,8 @@ int drm_gem_shmem_vmap(struct drm_gem_shmem_object *shmem,
> ret = drm_gem_shmem_vmap_locked(shmem, map);
> mutex_unlock(&shmem->vmap_lock);
>
> + drm_gem_shmem_update_purgeable_status(shmem);
> +
> return ret;
> }
> EXPORT_SYMBOL(drm_gem_shmem_vmap);
> @@ -409,6 +450,8 @@ void drm_gem_shmem_vunmap(struct drm_gem_shmem_object
> *shmem,
> mutex_lock(&shmem->vmap_lock);
> drm_gem_shmem_vunmap_locked(shmem, map);
> mutex_unlock(&shmem->vmap_lock);
> +
> + drm_gem_shmem_update_purgeable_status(shmem);
> }
> EXPORT_SYMBOL(drm_gem_shmem_vunmap);
>
> @@ -451,6 +494,8 @@ int drm_gem_shmem_madvise(struct drm_gem_shmem_object
> *shmem, int madv)
>
> mutex_unlock(&shmem->pages_lock);
>
> + drm_gem_shmem_update_purgeable_status(shmem);
> +
> return (madv >= 0);
> }
> EXPORT_SYMBOL(drm_gem_shmem_madvise);
> @@ -763,6 +808,155 @@ drm_gem_shmem_prime_import_sg_table(struct drm_device
> *dev,
> }
> EXPORT_SYMBOL_GPL(drm_gem_shmem_prime_import_sg_table);
>
> +static struct drm_gem_shmem_shrinker *
> +to_drm_shrinker(struct shrinker *shrinker)
> +{
> + return container_of(shrinker, struct drm_gem_shmem_shrinker, base);
> +}
> +
> +static unsigned long
> +drm_gem_shmem_shrinker_count_objects(struct shrinker *shrinker,
> + struct shrink_control *sc)
> +{
> + struct drm_gem_shmem_shrinker *gem_shrinker = to_drm_shrinker(shrinker);
> + u64 count = gem_shrin
Re: [PATCH v2 8/8] drm/panfrost: Switch to generic memory shrinker
On 14/03/2022 22:42, Dmitry Osipenko wrote:
> Replace Panfrost's memory shrinker with a generic DRM memory shrinker.
>
> Signed-off-by: Dmitry Osipenko
> ---
I gave this a spin on my Firefly-RK3288 board and everything seems to
work. So feel free to add a:
Tested-by: Steven Price
As Alyssa has already pointed out you need to remove the
panfrost_gem_shrinker.c file. But otherwise everything looks fine, and
I'm very happy to see the shrinker code gone ;)
Thanks,
Steve
> drivers/gpu/drm/panfrost/Makefile | 1 -
> drivers/gpu/drm/panfrost/panfrost_device.h | 4
> drivers/gpu/drm/panfrost/panfrost_drv.c| 19 ++-
> drivers/gpu/drm/panfrost/panfrost_gem.c| 27 ++
> drivers/gpu/drm/panfrost/panfrost_gem.h| 9
> drivers/gpu/drm/panfrost/panfrost_job.c| 22 +-
> 6 files changed, 40 insertions(+), 42 deletions(-)
>
> diff --git a/drivers/gpu/drm/panfrost/Makefile
> b/drivers/gpu/drm/panfrost/Makefile
> index b71935862417..ecf0864cb515 100644
> --- a/drivers/gpu/drm/panfrost/Makefile
> +++ b/drivers/gpu/drm/panfrost/Makefile
> @@ -5,7 +5,6 @@ panfrost-y := \
> panfrost_device.o \
> panfrost_devfreq.o \
> panfrost_gem.o \
> - panfrost_gem_shrinker.o \
> panfrost_gpu.o \
> panfrost_job.o \
> panfrost_mmu.o \
> diff --git a/drivers/gpu/drm/panfrost/panfrost_device.h
> b/drivers/gpu/drm/panfrost/panfrost_device.h
> index 8b25278f34c8..fe04b21fc044 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_device.h
> +++ b/drivers/gpu/drm/panfrost/panfrost_device.h
> @@ -115,10 +115,6 @@ struct panfrost_device {
> atomic_t pending;
> } reset;
>
> - struct mutex shrinker_lock;
> - struct list_head shrinker_list;
> - struct shrinker shrinker;
> -
> struct panfrost_devfreq pfdevfreq;
> };
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
> b/drivers/gpu/drm/panfrost/panfrost_drv.c
> index 94b6f0a19c83..b014dadcf51f 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_drv.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
> @@ -160,7 +160,6 @@ panfrost_lookup_bos(struct drm_device *dev,
> break;
> }
>
> - atomic_inc(&bo->gpu_usecount);
> job->mappings[i] = mapping;
> }
>
> @@ -390,7 +389,6 @@ static int panfrost_ioctl_madvise(struct drm_device *dev,
> void *data,
> {
> struct panfrost_file_priv *priv = file_priv->driver_priv;
> struct drm_panfrost_madvise *args = data;
> - struct panfrost_device *pfdev = dev->dev_private;
> struct drm_gem_object *gem_obj;
> struct panfrost_gem_object *bo;
> int ret = 0;
> @@ -403,7 +401,6 @@ static int panfrost_ioctl_madvise(struct drm_device *dev,
> void *data,
>
> bo = to_panfrost_bo(gem_obj);
>
> - mutex_lock(&pfdev->shrinker_lock);
> mutex_lock(&bo->mappings.lock);
> if (args->madv == PANFROST_MADV_DONTNEED) {
> struct panfrost_gem_mapping *first;
> @@ -429,17 +426,8 @@ static int panfrost_ioctl_madvise(struct drm_device
> *dev, void *data,
>
> args->retained = drm_gem_shmem_madvise(&bo->base, args->madv);
>
> - if (args->retained) {
> - if (args->madv == PANFROST_MADV_DONTNEED)
> - list_add_tail(&bo->base.madv_list,
> - &pfdev->shrinker_list);
> - else if (args->madv == PANFROST_MADV_WILLNEED)
> - list_del_init(&bo->base.madv_list);
> - }
> -
> out_unlock_mappings:
> mutex_unlock(&bo->mappings.lock);
> - mutex_unlock(&pfdev->shrinker_lock);
>
> drm_gem_object_put(gem_obj);
> return ret;
> @@ -570,9 +558,6 @@ static int panfrost_probe(struct platform_device *pdev)
> ddev->dev_private = pfdev;
> pfdev->ddev = ddev;
>
> - mutex_init(&pfdev->shrinker_lock);
> - INIT_LIST_HEAD(&pfdev->shrinker_list);
> -
> err = panfrost_device_init(pfdev);
> if (err) {
> if (err != -EPROBE_DEFER)
> @@ -594,7 +579,7 @@ static int panfrost_probe(struct platform_device *pdev)
> if (err < 0)
> goto err_out1;
>
> - panfrost_gem_shrinker_init(ddev);
> + drm_gem_shmem_shrinker_register(ddev);
>
> return 0;
>
> @@ -612,8 +597,8 @@ static int panfrost_remove(struct platform_device *pdev)
> struct panfrost_device *pfdev = platform_get_drvdata(pdev);
> struct drm_device *ddev = pfdev->ddev;
>
> + drm_gem_shmem_shrinker_unregister(ddev);
> drm_dev_unregister(ddev);
> - panfrost_gem_shrinker_cleanup(ddev);
>
> pm_runtime_get_sync(pfdev->dev);
> pm_runtime_disable(pfdev->dev);
> diff --git a/drivers/gpu/drm/panfrost/panfrost_gem.c
> b/drivers/gpu/drm/panfrost/panfrost_gem.c
> index 293e799e2fe8..d164d05ed84e 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_gem.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_gem.c
> @@ -19,16 +19,6 @@ sta
Re: [PATCH 1/2] drm: mediatek: mtk_drm_plane: Use kmalloc in mtk_plane_duplicate_state
Hi, Angelo: AngeloGioacchino Del Regno 於 2022年3月16日 週三 下午6:40寫道： > > Il 25/01/22 17:36, Chun-Kuang Hu ha scritto: > > Hi, AngeloGioacchino: > > > > AngeloGioacchino Del Regno 於 > > 2022年1月18日 週二 下午9:38寫道： > >> > >> There is no need to zero out the newly allocated memory because we are > >> duplicating all members of struct mtk_plane_state: switch to kmalloc > >> to save some overhead. > > > > Reviewed-by: Chun-Kuang Hu > > > >> > >> Signed-off-by: AngeloGioacchino Del Regno > >> > >> --- > >> drivers/gpu/drm/mediatek/mtk_drm_plane.c | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > > Hello, > > this series was sent and reviewed two months ago, but it hasn't been picked > in any maintainer tree. > > This is a friendly ping to not let these two patches to be lost and forgotten. For this series, applied to mediatek-drm-next [1], thanks. [1] https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next Regards, Chun-Kuang. > > Cheers, > Angelo
Re: [PATCH -next] drm/solomon: Make DRM_SSD130X depends on MMU
On 3/15/22 10:18, Javier Martinez Canillas wrote:
> Hello YueHaibing,
>
> Thanks for the patch.
>
> On 3/12/22 07:34, YueHaibing wrote:
>> WARNING: unmet direct dependencies detected for DRM_GEM_SHMEM_HELPER
>> Depends on [n]: HAS_IOMEM [=y] && DRM [=m] && MMU [=n]
>> Selected by [m]:
>> - DRM_SSD130X [=m] && HAS_IOMEM [=y] && DRM [=m]
>>
>> DRM_GEM_SHMEM_HELPER depends on MMU, DRM_SSD130X should also depends on MMU.
>>
>> Fixes: a61732e80867 ("drm: Add driver for Solomon SSD130x OLED displays")
>> Signed-off-by: YueHaibing
>> ---
>
> Indeed. All the DRM drivers that select DRM_GEM_SHMEM_HELPER depend on MMU.
>
> Acked-by: Javier Martinez Canillas
>
Pushed to drm-misc (drm-misc-next). Thanks!
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
Re: [PATCH V8 1/5] dt-bindings: display: mediatek: add aal binding for MT8183
On 16/03/2022 12:51, Rex-BC Chen wrote: > Add aal binding for MT8183. > > Signed-off-by: Rex-BC Chen > --- > .../devicetree/bindings/display/mediatek/mediatek,aal.yaml| 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git > a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml > b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml > index 61f0ed1e388f..eb0299b80522 100644 > --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml > +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml > @@ -22,7 +22,9 @@ properties: >compatible: > oneOf: >- items: > - - const: mediatek,mt8173-disp-aal > + - enum: > + - mediatek,mt8173-disp-aal > + - mediatek,mt8183-disp-aal This should not be under items. You have just one element here, so directly "enum" under oneOf. Best regards, Krzysztof
Re: [RFC PATCH 5/7] drm/ttm: add range busy check for range manager
On 16/03/2022 14:39, Christian König wrote:
Am 16.03.22 um 15:26 schrieb Robert Beckett:
[SNIP]
this is where I replace an existing range check via drm_mm with the
range check I added in this patch.
Mhm, I still don't get the use case from the code, but I don't think it
matters any more.
I suppose we could add another drm_mm range tracker just for testing
and shadow track each allocation in the range, but that seemed like
a lot of extra infrastructure for no general runtime use.
I have no idea what you mean with that.
I meant as a potential solution to tracking allocations without a
range check, we would need to add something external. e.g. adding a
shadow drm_mm range tracker, or a bitmask across the range, or stick
objects in a list etc.
Ah! So you are trying to get access to the drm_mm inside the
ttm_range_manager and not add some additional range check function! Now
I got your use case.
well, specifically I was trying to avoid having to get access to the drm_mm.
I wanted to maintain an abstract interface at the resource manager
level, hence the rfc to ask if we could add a range check to
ttm_resource_manager_func.
I don't like the idea of code external to ttm having to poke in to the
implementation details of the manager to get it's underlying drm_mm.
would you mind explaining the rationale for removing range checks?
It seems to me like a natural fit for a memory manager
TTM manages buffer objects and resources, not address space. The
lpfn/fpfn parameter for the resource allocators are actually used as
just two independent parameters and not define any range. We just
keep the names for historical reasons.
The only places we still use and compare them as ranges are
ttm_resource_compat() and ttm_bo_eviction_valuable() and I already
have patches to clean up those and move them into the backend
resource handling.
except the ttm_range_manager seems to still use them as a range
specifier.
Yeah, because the range manager is the backend which handles ranges
using the drm_mm :)
If the general design going forward is to not consider ranges, how
would you recommend constructing buffers around pre-allocated regions
e.g. uefi frame buffers who's range is dictated externally?
Call ttm_bo_mem_space() with the fpfn/lpfn filled in as required. See
function amdgpu_bo_create_kernel_at() for an example.
ah, I see, thanks.
To allow similar code to before, which was conceptually just trying to
see if a range was currently free, would you be okay with a new
ttm_bo_mem_try_space, which does not do the force to evict, but instead
returns -EBUSY?
If so, the test can try to alloc, and immediately free if successful
which would imply it was free.
Regards,
Christian.
Regards,
Christian.
Regards,
Christian.
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/ttm/ttm_range_manager.c | 21 +
include/drm/ttm/ttm_range_manager.h | 3 +++
2 files changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/ttm/ttm_range_manager.c
b/drivers/gpu/drm/ttm/ttm_range_manager.c
index 8cd4f3fb9f79..5662627bb933 100644
--- a/drivers/gpu/drm/ttm/ttm_range_manager.c
+++ b/drivers/gpu/drm/ttm/ttm_range_manager.c
@@ -206,3 +206,24 @@ int ttm_range_man_fini_nocheck(struct
ttm_device *bdev,
return 0;
}
EXPORT_SYMBOL(ttm_range_man_fini_nocheck);
+
+/**
+ * ttm_range_man_range_busy - Check whether anything is allocated
with a range
+ *
+ * @man: memory manager to check
+ * @fpfn: first page number to check
+ * @lpfn: last page number to check
+ *
+ * Return: true if anything allocated within the range, false
otherwise.
+ */
+bool ttm_range_man_range_busy(struct ttm_resource_manager *man,
+ unsigned fpfn, unsigned lpfn)
+{
+ struct ttm_range_manager *rman = to_range_manager(man);
+ struct drm_mm *mm = &rman->mm;
+
+ if (__drm_mm_interval_first(mm, PFN_PHYS(fpfn), PFN_PHYS(lpfn
+ 1) - 1))
+ return true;
+ return false;
+}
+EXPORT_SYMBOL(ttm_range_man_range_busy);
diff --git a/include/drm/ttm/ttm_range_manager.h
b/include/drm/ttm/ttm_range_manager.h
index 7963b957e9ef..86794a3f9101 100644
--- a/include/drm/ttm/ttm_range_manager.h
+++ b/include/drm/ttm/ttm_range_manager.h
@@ -53,4 +53,7 @@ static __always_inline int
ttm_range_man_fini(struct ttm_device *bdev,
BUILD_BUG_ON(__builtin_constant_p(type) && type >=
TTM_NUM_MEM_TYPES);
return ttm_range_man_fini_nocheck(bdev, type);
}
+
+bool ttm_range_man_range_busy(struct ttm_resource_manager *man,
+ unsigned fpfn, unsigned lpfn);
#endif
Re: [PATCH v2 1/2] drm: Add GPU reset sysfs event
On Wed, Mar 16, 2022 at 7:12 AM Alex Deucher wrote: > > On Wed, Mar 16, 2022 at 4:48 AM Pekka Paalanen wrote: > > [snip] > > With new UAPI comes the demand of userspace proof, not hand-waving. You > > would not be proposing this new interface if you didn't have use cases > > in mind, even just one. You have to document what you imagine the new > > thing to be used for, so that the appropriateness can be evaluated. If > > the use case is deemed inappropriate for the proposed UAPI, you need to > > find another use case to justify adding the new UAPI. If there is no > > use for the UAPI, it shouldn't be added, right? Adding UAPI and hoping > > someone finds use for it seems backwards to me. > > We do have a use case. It's what I described originally. There is a > user space daemon (could be a compositor, could be something else) > that runs and listens for GPU reset notifications. When it receives a > notification, it takes action and kills the guilty app and restarts > the compositer and gathers any relevant data related to the GPU hang > (if possible). We can revisit this discussion once we have the whole > implementation complete. Other drivers seem to do similar things > already today via different means (msm using devcoredump, i915 seems > to have its own GPU reset notification mechanism, etc.). It just > seemed like there was value in having a generic drm GPU reset > notification, but maybe not yet. just one point of clarification.. in the msm and i915 case it is purely for debugging and telemetry (ie. sending crash logs back to distro for analysis if user has crash reporting enabled).. it isn't used for triggering any action like killing app or compositor. I would however *strongly* recommend devcoredump support in other GPU drivers (i915's thing pre-dates devcoredump by a lot).. I've used it to debug and fix a couple obscure issues that I was not able to reproduce by myself. BR, -R
Re: [PATCH v2 1/2] drm: Add GPU reset sysfs event
On Wed, Mar 16, 2022 at 11:35 AM Rob Clark wrote: > > On Wed, Mar 16, 2022 at 7:12 AM Alex Deucher wrote: > > > > On Wed, Mar 16, 2022 at 4:48 AM Pekka Paalanen wrote: > > > > [snip] > > > With new UAPI comes the demand of userspace proof, not hand-waving. You > > > would not be proposing this new interface if you didn't have use cases > > > in mind, even just one. You have to document what you imagine the new > > > thing to be used for, so that the appropriateness can be evaluated. If > > > the use case is deemed inappropriate for the proposed UAPI, you need to > > > find another use case to justify adding the new UAPI. If there is no > > > use for the UAPI, it shouldn't be added, right? Adding UAPI and hoping > > > someone finds use for it seems backwards to me. > > > > We do have a use case. It's what I described originally. There is a > > user space daemon (could be a compositor, could be something else) > > that runs and listens for GPU reset notifications. When it receives a > > notification, it takes action and kills the guilty app and restarts > > the compositer and gathers any relevant data related to the GPU hang > > (if possible). We can revisit this discussion once we have the whole > > implementation complete. Other drivers seem to do similar things > > already today via different means (msm using devcoredump, i915 seems > > to have its own GPU reset notification mechanism, etc.). It just > > seemed like there was value in having a generic drm GPU reset > > notification, but maybe not yet. > > just one point of clarification.. in the msm and i915 case it is > purely for debugging and telemetry (ie. sending crash logs back to > distro for analysis if user has crash reporting enabled).. it isn't > used for triggering any action like killing app or compositor. Sure. you could use this proposed event for telemetry gathering as well. The important part is the event. What you do with it is up to the user. > > I would however *strongly* recommend devcoredump support in other GPU > drivers (i915's thing pre-dates devcoredump by a lot).. I've used it > to debug and fix a couple obscure issues that I was not able to > reproduce by myself. Agreed. I think devcoredump makes sense and we'll ultimately enable support for that in amdgpu. I think there is value in a GPU specific reset event as well for the use case I outlined, but maybe the devcoredump one is enough. We'd just need to rely on the userspace side to filter as appropriate for events it cares about. I'm not sure how many other devcore dump events are commonly seen. Alex
Re: [PATCH v2 0/6] Allow drm_writeback_connector to accept pointer to drm_encoder
Hi Dmitry On 3/16/2022 12:40 AM, Dmitry Baryshkov wrote: Hi Abhinav, On 16/03/2022 02:11, Abhinav Kumar wrote: There are some vendor drivers for which the writeback encoder shares hardware resources such as clocks and interrupts with the rest of the display pipeline. In addition, there can be use-cases where the writeback encoder could be a shared encoder between the physical display path and the writeback path. To accommodate for such cases, change the drm_writeback_connector to accept a pointer to drm_encoder. For existing users of drm_writeback_connector there will not be any change in functionality due to this change. This approach was first posted by Suraj Kandpal here [1] for both encoder and connector. But after discussions [2], the consensus was reached to split this change for the drm_encoder first and the drm_connector part can be reworked in a subsequent change later. Validation of this change was done using igt_writeback tests on MSM based RB5 board using the changes posted here [3]. For all other chipsets, these changes were compile-tested. [1] https://patchwork.kernel.org/project/dri-devel/patch/20220202081702.22119-1-suraj.kand...@intel.com/ [2] https://patchwork.kernel.org/project/dri-devel/patch/20220202085429.22261-6-suraj.kand...@intel.com/ [3] https://patchwork.freedesktop.org/series/99724/ changes in v2: - introduce a new API drm_writeback_connector_init_with_encoder() - allow passing possible_crtcs for existing users of drm_writeback_connector_init() Abhinav Kumar (6): drm: allow real encoder to be passed for drm_writeback_connector drm/komeda: pass possible_crtcs as parameter for drm_writeback_connector drm/vkms: pass possible_crtcs as parameter for drm_writeback_connector drm/vc4: change vc4 driver to use drm_writeback_connector_init_with_encoder() drm/rcar_du: pass possible_crtcs as parameter for drm_writeback_connector drm/malidp: pass possible_crtcs as parameter for drm_writeback_connector I think we expect that at each commit point the kernel should be compilable. Could you please squash patches accordingly? I'd suggest the following patch sequence: - Add possible_crtcs to the drm_writeback_connector_init() including all the driver changes (all drivers must be compilable, including vc4) - Add drm_writeback_connector_init_with_encoder() - Modify vc4 to use new API WDYT? Yes I also thought if each commit point should be compilable. The way this started out was that in the original series https://patchwork.kernel.org/project/dri-devel/patch/20220202081702.22119-1-suraj.kand...@intel.com/ every commit was separated vendor-wise even though it will not compile individually. So I thought that, for ease of code-review perhaps it was alright to separate it that way so that individual vendors can review separately. But if we need to make each of the commits compilable we will have to squash the way you have mentioned. .../drm/arm/display/komeda/komeda_wb_connector.c | 3 +- drivers/gpu/drm/arm/malidp_mw.c | 5 +- drivers/gpu/drm/drm_writeback.c | 144 +++-- drivers/gpu/drm/rcar-du/rcar_du_writeback.c | 5 +- drivers/gpu/drm/vc4/vc4_txp.c | 30 - drivers/gpu/drm/vkms/vkms_writeback.c | 3 +- include/drm/drm_writeback.h | 27 +++- 7 files changed, 161 insertions(+), 56 deletions(-)
Re: [PATCH v2 1/2] drm: Add GPU reset sysfs event
On Wed, Mar 16, 2022 at 8:48 AM Alex Deucher wrote: > > On Wed, Mar 16, 2022 at 11:35 AM Rob Clark wrote: > > > > On Wed, Mar 16, 2022 at 7:12 AM Alex Deucher wrote: > > > > > > On Wed, Mar 16, 2022 at 4:48 AM Pekka Paalanen > > > wrote: > > > > > > [snip] > > > > With new UAPI comes the demand of userspace proof, not hand-waving. You > > > > would not be proposing this new interface if you didn't have use cases > > > > in mind, even just one. You have to document what you imagine the new > > > > thing to be used for, so that the appropriateness can be evaluated. If > > > > the use case is deemed inappropriate for the proposed UAPI, you need to > > > > find another use case to justify adding the new UAPI. If there is no > > > > use for the UAPI, it shouldn't be added, right? Adding UAPI and hoping > > > > someone finds use for it seems backwards to me. > > > > > > We do have a use case. It's what I described originally. There is a > > > user space daemon (could be a compositor, could be something else) > > > that runs and listens for GPU reset notifications. When it receives a > > > notification, it takes action and kills the guilty app and restarts > > > the compositer and gathers any relevant data related to the GPU hang > > > (if possible). We can revisit this discussion once we have the whole > > > implementation complete. Other drivers seem to do similar things > > > already today via different means (msm using devcoredump, i915 seems > > > to have its own GPU reset notification mechanism, etc.). It just > > > seemed like there was value in having a generic drm GPU reset > > > notification, but maybe not yet. > > > > just one point of clarification.. in the msm and i915 case it is > > purely for debugging and telemetry (ie. sending crash logs back to > > distro for analysis if user has crash reporting enabled).. it isn't > > used for triggering any action like killing app or compositor. > > Sure. you could use this proposed event for telemetry gathering as > well. The important part is the event. What you do with it is up to > the user. True, but for that purpose (telemetry) let's leverage something that userspace already has support for > > I would however *strongly* recommend devcoredump support in other GPU > > drivers (i915's thing pre-dates devcoredump by a lot).. I've used it > > to debug and fix a couple obscure issues that I was not able to > > reproduce by myself. > > Agreed. I think devcoredump makes sense and we'll ultimately enable > support for that in amdgpu. I think there is value in a GPU specific > reset event as well for the use case I outlined, but maybe the > devcoredump one is enough. We'd just need to rely on the userspace > side to filter as appropriate for events it cares about. I'm not sure > how many other devcore dump events are commonly seen. They are, like CPU coredumps, not expected to be a frequent thing. There are a number of other non-GPU drivers which also use devcoredump (mostly wifi and remoteproc, ie. things like DSPs). We did also recently add msm devcoredump support for the display side of things, in addition to gpu, to dump display state if we hit underruns, link training fail, etc. Each "crash" creates a new transient devcore device so crashes from different devices can be reported in parallel. But we do rate-limit the GPU crash reports by not reporting another one until the previous one is read out and cleared by userspace. (You don't strictly need to do that, but it is probably a good idea.. usually the first crash is the interesting one.) The ChromeOS crash-reporter does have an allow-list for which devcore dumps are sent back, mainly because in the case of wifi drivers it is hard to ensure that the dump does not include PII (like network names, etc). It would be pretty trivial to add amdgpu to the allow-list and setup a "magic signature" so that queries could be run on amdgpu devcore dumps. I can help out with that, since I went through the same process already for msm. I'm not entirely sure what other distros do in this area. BR, -R
RE: [RFC PATCH v2 5/5] drm/msm/dp: remove extra wrappers and public functions
> Subject: [RFC PATCH v2 5/5] drm/msm/dp: remove extra wrappers and
> public functions
> Date: Sat, 12 Feb 2022 01:40:06 +0300
> From: Dmitry Baryshkov
> To: Bjorn Andersson , Rob Clark
> , Sean Paul , Abhinav Kumar
> , Kuogee Hsieh
> CC: Stephen Boyd , David Airlie ,
> Daniel Vetter , linux-arm-...@vger.kernel.org, dri-
> de...@lists.freedesktop.org, freedr...@lists.freedesktop.org
>
> dp_bridge's functions are thin wrappers around the msm_dp_display_*
> family. Squash dp_bridge callbacks into respective msm_dp_display
> functions, removing the latter functions from public space.
>
> Signed-off-by: Dmitry Baryshkov
Tested-by: Sankeerth Billakanti
> ---
> drivers/gpu/drm/msm/dp/dp_display.c | 54 +++---
> drivers/gpu/drm/msm/dp/dp_display.h | 1 -
> drivers/gpu/drm/msm/dp/dp_drm.c | 72 ++---
> drivers/gpu/drm/msm/dp/dp_drm.h | 22 -
> drivers/gpu/drm/msm/msm_drv.h | 31 -
> 5 files changed, 60 insertions(+), 120 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
> b/drivers/gpu/drm/msm/dp/dp_display.c
> index 59e5e5b8e5b4..a9b641a68bff 100644
> --- a/drivers/gpu/drm/msm/dp/dp_display.c
> +++ b/drivers/gpu/drm/msm/dp/dp_display.c
> @@ -10,7 +10,6 @@
> #include
> #include
> #include
> -#include
>#include "msm_drv.h"
> #include "msm_kms.h"
> @@ -945,18 +944,36 @@ int dp_display_set_plugged_cb(struct msm_dp
> *dp_display,
> return 0;
> }
> -int dp_display_validate_mode(struct msm_dp *dp, u32 mode_pclk_khz)
> +/**
> + * dp_bridge_mode_valid - callback to determine if specified mode is
> +valid
> + * @bridge: Pointer to drm bridge structure
> + * @info: display info
> + * @mode: Pointer to drm mode structure
> + * Returns: Validity status for specified mode */ enum drm_mode_status
> +dp_bridge_mode_valid(struct drm_bridge *bridge,
> + const struct drm_display_info *info,
> + const struct drm_display_mode
> *mode)
> {
> const u32 num_components = 3, default_bpp = 24;
> struct dp_display_private *dp_display;
> struct dp_link_info *link_info;
> u32 mode_rate_khz = 0, supported_rate_khz = 0, mode_bpp = 0;
> + struct msm_dp *dp;
> + int mode_pclk_khz = mode->clock;
> +
> + dp = to_dp_bridge(bridge)->dp_display;
> if (!dp || !mode_pclk_khz || !dp->connector) {
> DRM_ERROR("invalid params\n");
> return -EINVAL;
> }
> + if ((dp->max_pclk_khz <= 0) ||
> + (dp->max_pclk_khz > DP_MAX_PIXEL_CLK_KHZ) ||
> + (mode->clock > dp->max_pclk_khz))
> + return MODE_BAD;
> +
> dp_display = container_of(dp, struct dp_display_private,
> dp_display);
> link_info = &dp_display->panel->link_info;
> @@ -1501,7 +1518,7 @@ int msm_dp_modeset_init(struct msm_dp
> *dp_display, struct drm_device *dev,
> dp_display->encoder = encoder;
> - dp_display->bridge = msm_dp_bridge_init(dp_display, dev,
> encoder);
> + dp_display->bridge = dp_bridge_init(dp_display, dev, encoder);
> if (IS_ERR(dp_display->bridge)) {
> ret = PTR_ERR(dp_display->bridge);
> DRM_DEV_ERROR(dev->dev,
> @@ -1528,8 +1545,10 @@ int msm_dp_modeset_init(struct msm_dp
> *dp_display, struct drm_device *dev,
> return 0;
> }
> -int msm_dp_display_enable(struct msm_dp *dp, struct drm_encoder
> *encoder)
> +void dp_bridge_enable(struct drm_bridge *drm_bridge)
> {
> + struct msm_dp_bridge *dp_bridge = to_dp_bridge(drm_bridge);
> + struct msm_dp *dp = dp_bridge->dp_display;
> int rc = 0;
> struct dp_display_private *dp_display;
> u32 state;
> @@ -1537,7 +1556,7 @@ int msm_dp_display_enable(struct msm_dp *dp,
> struct drm_encoder *encoder)
> dp_display = container_of(dp, struct dp_display_private,
> dp_display);
> if (!dp_display->dp_mode.drm_mode.clock) {
> DRM_ERROR("invalid params\n");
> - return -EINVAL;
> + return;
> }
> mutex_lock(&dp_display->event_mutex);
> @@ -1549,14 +1568,14 @@ int msm_dp_display_enable(struct msm_dp *dp,
> struct drm_encoder *encoder)
> if (rc) {
> DRM_ERROR("Failed to perform a mode set, rc=%d\n", rc);
> mutex_unlock(&dp_display->event_mutex);
> - return rc;
> + return;
> }
> rc = dp_display_prepare(dp);
> if (rc) {
> DRM_ERROR("DP display prepare failed, rc=%d\n", rc);
> mutex_unlock(&dp_display->event_mutex);
> - return rc;
> + return;
> }
> state = dp_display->hpd_state;
> @@ -1581,23 +1600,23 @@ int msm_dp_display_enable(struct msm_dp *dp,
> struct drm_encoder *encoder)
> dp_display->hpd_state = ST_CONNECTED;
> mutex_unlock(&dp_display->event_mutex);
> -
> - return rc;
> }
> -int msm_dp_display_pre_dis
RE: [RFC PATCH v2 4/5] drm/msm/dp: replace dp_connector with drm_bridge_connector
> Subject: Re: [RFC PATCH v2 4/5] drm/msm/dp: replace dp_connector with
> drm_bridge_connector
> Date: Wed, 23 Feb 2022 16:40:56 -0800
> From: Kuogee Hsieh
> To: Stephen Boyd , Dmitry Baryshkov
>
> CC: Abhinav Kumar , Bjorn Andersson
> , Rob Clark , Sean Paul
> , David Airlie , Daniel Vetter
> , linux-arm-...@vger.kernel.org, dri-
> de...@lists.freedesktop.org, freedr...@lists.freedesktop.org
>
>
> On 2/23/2022 1:33 PM, Stephen Boyd wrote:
> > Quoting Kuogee Hsieh (2022-02-23 10:27:26)
> >> On 2/23/2022 10:22 AM, Dmitry Baryshkov wrote:
> >>> On 23/02/2022 20:21, Kuogee Hsieh wrote:
> >>>
> >>> In the panel device node.
> >>>
> >>> Can you please share it too?
> >>
> >> &soc {
> >> edp_power_supply: edp_power {
> >> compatible = "regulator-fixed";
> >> regulator-name = "edp_backlight_power";
> >>
> >> regulator-always-on;
> >> regulator-boot-on;
> >> };
> >>
> >> edp_backlight: edp_backlight {
> >> compatible = "pwm-backlight";
> >>
> >> pwms = <&pm8350c_pwm 3 65535>;
> >> power-supply = <&edp_power_supply>;
> >> enable-gpio = <&pm8350c_gpios 7 GPIO_ACTIVE_HIGH>;
> >>
> >> pinctrl-names = "default";
> >> pinctrl-0 = <&backlight_pwm_default>;
> >> };
> >>
> >> edp_panel: edp_panel {
> >> compatible = "sharp_lq140m1jw46";
> > Is that supposed to be sharp,lq140m1jw46 with a comma instead of an
> > underscore?
>
> Stephen,
>
> This is our internal branch which does not have patches up to date yet.
>
> I will cherry-pick newer edp related patches which are under review now to
> re test it.
Tested-by: Sankeerth Billakanti
Detect returned eDP not connected because the panel power was not on and
mode_valid was failing because the DP mode_valid is different from eDP
Re: [PATCH v2 00/12] drm/gma500: Various cleanups to GEM code
On Tue, Mar 8, 2022 at 8:52 PM Thomas Zimmermann wrote:
>
> Refactor and simplify various parts of the memory management. This
> includes locking, initialization and finalizer functions, and code
> organization.
>
> Tested on Atom N2800 hardware.
>
> v2:
> * put common code in psb_gtt_{init,fini,resume}() into
> helpers (Sam, Patrik)
>
The series is pushed to drm-misc-next
Thanks
Patrik
> Thomas Zimmermann (12):
> drm/gma500: Remove struct psb_gem_object.npage
> drm/gma500: Acquire reservation lock for GEM objects
> drm/gma500: Move GTT locking into GTT helpers
> drm/gma500: Remove struct psb_gtt.sem sempahore
> drm/gma500: Move GTT setup and restoration into helper funtions
> drm/gma500: Move GTT resume logic out of psb_gtt_init()
> drm/gma500: Cleanup GTT uninit and error handling
> drm/gma500: Split GTT init/resume/fini into GTT and GEM functions
> drm/gma500: Inline psb_gtt_restore()
> drm/gma500: Move GEM memory management functions to gem.c
> drm/gma500: Move GTT enable and disable code into helpers
> drm/gma500: Move GTT memory-range setup into helper
>
> drivers/gpu/drm/gma500/gem.c | 161 ++-
> drivers/gpu/drm/gma500/gem.h | 13 +-
> drivers/gpu/drm/gma500/gma_display.c | 8 +-
> drivers/gpu/drm/gma500/gtt.c | 295 +--
> drivers/gpu/drm/gma500/gtt.h | 8 +-
> drivers/gpu/drm/gma500/power.c | 5 +-
> drivers/gpu/drm/gma500/psb_drv.c | 13 +-
> drivers/gpu/drm/gma500/psb_drv.h | 1 -
> 8 files changed, 317 insertions(+), 187 deletions(-)
>
>
> base-commit: 710a019ad85e96e66f7d75ee7f4733cdd8a2b0d0
> prerequisite-patch-id: c2b2f08f0eccc9f5df0c0da49fa1d36267deb11d
> prerequisite-patch-id: c67e5d886a47b7d0266d81100837557fda34cb24
> prerequisite-patch-id: 6e1032c6302461624f33194c8b8f37103a3fa6ef
> --
> 2.35.1
>
Re: [PATCH v1 1/1] staging: fbtft: Consider type of init sequence values in fbtft_init_display()
On Mon, Mar 14, 2022 at 06:28:41PM +0100, Greg Kroah-Hartman wrote:
> On Fri, Mar 04, 2022 at 09:34:14PM +0200, Andy Shevchenko wrote:
...
> Any reason you didn't test build this?
My test build doesn't include the WERROR for this driver, so I missed the
warning. Sorry for that. Now fixed.
> drivers/staging/fbtft/fbtft-core.c: In function ‘fbtft_init_display’:
> drivers/staging/fbtft/fbtft-core.c:1038:48: error: passing argument 3 of
> ‘fbtft_dbg_hex’ discards ‘const’ qualifier from pointer target type
> [-Werror=discarded-qualifiers]
> 1038 | s16, &par->init_sequence[i
> + 1], j,
> |
> ^~
> drivers/staging/fbtft/fbtft.h:441:50: note: in definition of macro
> ‘fbtft_par_dbg_hex’
> 441 | fbtft_dbg_hex(dev, sizeof(type), buf,\
> | ^~~
> drivers/staging/fbtft/fbtft-core.c:52:26: note: expected ‘void *’ but
> argument is of type ‘const s16 *’ {aka ‘const short int *’}
>52 |void *buf, size_t len, const char *fmt, ...)
> |~~^~~
> LD [M] drivers/staging/gdm724x/gdmulte.o
> cc1: all warnings being treated as errors
--
With Best Regards,
Andy Shevchenko
[PATCH v2 1/2] staging: fbtft: Constify buf parameter in fbtft_dbg_hex()
It's obvious that we don't and shouldn't modify buffer that
is about to be dumped. Constify parameter in fbtft_dbg_hex()
to make it clear.
Fixes: c296d5f9957c ("staging: fbtft: core support")
Signed-off-by: Andy Shevchenko
---
v2: new patch to fix a warning (Greg)
drivers/staging/fbtft/fbtft-core.c | 2 +-
drivers/staging/fbtft/fbtft.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/fbtft/fbtft-core.c
b/drivers/staging/fbtft/fbtft-core.c
index f2684d2d6851..6dc77895a87c 100644
--- a/drivers/staging/fbtft/fbtft-core.c
+++ b/drivers/staging/fbtft/fbtft-core.c
@@ -49,7 +49,7 @@ int fbtft_write_buf_dc(struct fbtft_par *par, void *buf,
size_t len, int dc)
EXPORT_SYMBOL(fbtft_write_buf_dc);
void fbtft_dbg_hex(const struct device *dev, int groupsize,
- void *buf, size_t len, const char *fmt, ...)
+ const void *buf, size_t len, const char *fmt, ...)
{
va_list args;
static char textbuf[512];
diff --git a/drivers/staging/fbtft/fbtft.h b/drivers/staging/fbtft/fbtft.h
index 55677efc0138..c3d8b2aae607 100644
--- a/drivers/staging/fbtft/fbtft.h
+++ b/drivers/staging/fbtft/fbtft.h
@@ -240,7 +240,7 @@ struct fbtft_par {
int fbtft_write_buf_dc(struct fbtft_par *par, void *buf, size_t len, int dc);
__printf(5, 6)
void fbtft_dbg_hex(const struct device *dev, int groupsize,
- void *buf, size_t len, const char *fmt, ...);
+ const void *buf, size_t len, const char *fmt, ...);
struct fb_info *fbtft_framebuffer_alloc(struct fbtft_display *display,
struct device *dev,
struct fbtft_platform_data *pdata);
--
2.35.1
[PATCH v2 2/2] staging: fbtft: Consider type of init sequence values in fbtft_init_display()
In the fbtft_init_display() the init sequence is printed for
the debug purposes. Unfortunately the current code doesn't take
into account that values in the buffer are of the s16 type.
Consider that and replace the printing code with fbtft_par_dbg_hex()
call.
Fixes: b97014a9 ("staging/fbtft: Remove all strcpy() uses")
Signed-off-by: Andy Shevchenko
---
v2: no changes, just based on prerequisite
drivers/staging/fbtft/fbtft-core.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/fbtft/fbtft-core.c
b/drivers/staging/fbtft/fbtft-core.c
index 6dc77895a87c..3b182115bd6e 100644
--- a/drivers/staging/fbtft/fbtft-core.c
+++ b/drivers/staging/fbtft/fbtft-core.c
@@ -1034,10 +1034,9 @@ int fbtft_init_display(struct fbtft_par *par)
for (j = 0; par->init_sequence[i + 1 + j] >= 0; j++)
;
- fbtft_par_dbg(DEBUG_INIT_DISPLAY, par,
- "init: write(0x%02X) %*ph\n",
- par->init_sequence[i], j,
- &par->init_sequence[i + 1]);
+ fbtft_par_dbg_hex(DEBUG_INIT_DISPLAY, par,
par->info->device,
+ s16, &par->init_sequence[i + 1], j,
+ "init: write(0x%02X)",
par->init_sequence[i]);
/* Write */
j = 0;
--
2.35.1
Re: [Freedreno] [PATCH v3 5/5] drm/msm: allow compile time selection of driver components
On 3/16/2022 12:31 AM, Dmitry Baryshkov wrote: On 16/03/2022 03:28, Abhinav Kumar wrote: On 3/3/2022 7:21 PM, Dmitry Baryshkov wrote: MSM DRM driver already allows one to compile out the DP or DSI support. Add support for disabling other features like MDP4/MDP5/DPU drivers or direct HDMI output support. Suggested-by: Stephen Boyd Signed-off-by: Dmitry Baryshkov --- drivers/gpu/drm/msm/Kconfig | 50 -- drivers/gpu/drm/msm/Makefile | 18 ++-- drivers/gpu/drm/msm/msm_drv.h | 33 ++ drivers/gpu/drm/msm/msm_mdss.c | 13 +++-- 4 files changed, 106 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig index 9b019598e042..3735fd41eb3b 100644 --- a/drivers/gpu/drm/msm/Kconfig +++ b/drivers/gpu/drm/msm/Kconfig @@ -46,12 +46,39 @@ config DRM_MSM_GPU_SUDO Only use this if you are a driver developer. This should *not* be enabled for production kernels. If unsure, say N. -config DRM_MSM_HDMI_HDCP - bool "Enable HDMI HDCP support in MSM DRM driver" +config DRM_MSM_MDSS + bool + depends on DRM_MSM + default n shouldnt DRM_MSM_MDSS be defaulted to y? No, it will be selected either by MDP5 or by DPU1. It is not used if DRM_MSM is compiled with just MDP4 or headless support in mind. Ok got it. Another question is the compilation validation of the combinations of these. So we need to try: 1) DRM_MSM_MDSS + DRM_MSM_MDP4 2) DRM_MSM_MDSS + DRM_MSM_MDP5 3) DRM_MSM_MDSS + DRM_MSM_DPU Earlier since all of them were compiled together any inter-dependencies will not show up. Now since we are separating it out, just wanted to make sure each of the combos compile? I think you meant: - headless - MDP4 - MDP5 - DPU1 - MDP4 + MDP5 - MDP4 + DPU1 - MDP5 + DPU1 - all three drivers Yes, each of these combinations. + +config DRM_MSM_MDP4 + bool "Enable MDP4 support in MSM DRM driver" depends on DRM_MSM default y help - Choose this option to enable HDCP state machine + Compile in support for the Mobile Display Processor v4 (MDP4) in + the MSM DRM driver. It is the older display controller found in + devices using APQ8064/MSM8960/MSM8x60 platforms. + +config DRM_MSM_MDP5 + bool "Enable MDP5 support in MSM DRM driver" + depends on DRM_MSM + select DRM_MSM_MDSS + default y + help + Compile in support for the Mobile Display Processor v5 (MDP4) in + the MSM DRM driver. It is the display controller found in devices + using e.g. APQ8016/MSM8916/APQ8096/MSM8996/MSM8974/SDM6x0 platforms. + +config DRM_MSM_DPU + bool "Enable DPU support in MSM DRM driver" + depends on DRM_MSM + select DRM_MSM_MDSS + default y + help + Compile in support for the Display Processing Unit in + the MSM DRM driver. It is the display controller found in devices + using e.g. SDM845 and newer platforms. config DRM_MSM_DP bool "Enable DisplayPort support in MSM DRM driver" @@ -116,3 +143,20 @@ config DRM_MSM_DSI_7NM_PHY help Choose this option if DSI PHY on SM8150/SM8250/SC7280 is used on the platform. + +config DRM_MSM_HDMI + bool "Enable HDMI support in MSM DRM driver" + depends on DRM_MSM + default y + help + Compile in support for the HDMI output MSM DRM driver. It can + be a primary or a secondary display on device. Note that this is used + only for the direct HDMI output. If the device outputs HDMI data + throught some kind of DSI-to-HDMI bridge, this option can be disabled. + +config DRM_MSM_HDMI_HDCP + bool "Enable HDMI HDCP support in MSM DRM driver" + depends on DRM_MSM && DRM_MSM_HDMI + default y + help + Choose this option to enable HDCP state machine diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile index e76927b42033..5fe9c20ab9ee 100644 --- a/drivers/gpu/drm/msm/Makefile +++ b/drivers/gpu/drm/msm/Makefile @@ -16,6 +16,8 @@ msm-y := \ adreno/a6xx_gpu.o \ adreno/a6xx_gmu.o \ adreno/a6xx_hfi.o \ + +msm-$(CONFIG_DRM_MSM_HDMI) += \ hdmi/hdmi.o \ hdmi/hdmi_audio.o \ hdmi/hdmi_bridge.o \ @@ -27,8 +29,8 @@ msm-y := \ hdmi/hdmi_phy_8x60.o \ hdmi/hdmi_phy_8x74.o \ hdmi/hdmi_pll_8960.o \ - disp/mdp_format.o \ - disp/mdp_kms.o \ + +msm-$(CONFIG_DRM_MSM_MDP4) += \ disp/mdp4/mdp4_crtc.o \ disp/mdp4/mdp4_dtv_encoder.o \ disp/mdp4/mdp4_lcdc_encoder.o \ @@ -37,6 +39,8 @@ msm-y := \ disp/mdp4/mdp4_irq.o \ disp/mdp4/mdp4_kms.o \ disp/mdp4/mdp4_plane.o \ + +msm-$(CONFIG_DRM_MSM_MDP5) += \ disp/mdp5/mdp5_cfg.o \ disp/mdp5/mdp5_ctl.o \ disp/mdp5/mdp5_crtc.o \ @@ -47,6 +51,8 @@ msm-y := \ disp/mdp5/mdp5_mixer.o \ disp/mdp5/mdp5_plane.o \ disp/mdp5/mdp5_smp.o \ + +msm-$(CONFIG_DRM_MSM_DPU) += \ disp/dpu1/dpu_core_perf.o \ disp/dpu1/dpu_crtc.o \ disp/dp
[PATCH v5 0/9] Add support for the eDP panel on sc7280 CRD
This series adds support for eDP on sc7280 CRD platform. These changes are dependent on the following series in order: https://patchwork.kernel.org/project/linux-arm-msm/list/?series=620127&state=* https://patchwork.kernel.org/project/linux-arm-msm/list/?series=616587&state=* https://patchwork.kernel.org/project/linux-arm-msm/list/?series=613654&state=* Sankeerth Billakanti (9): arm64: dts: qcom: sc7280: rename edp_out label to mdss_edp_out arm64: dts: qcom: sc7280: Add support for eDP panel on CRD arm64: dts: qcom: sc7280: Enable backlight for eDP panel drm/panel-edp: add LQ140M1JW46 edp panel entry drm/msm/dp: Add eDP support via aux_bus drm/msm/dp: wait for hpd high before any sink interaction drm/msm/dp: Support only IRQ_HPD and REPLUG interrupts for eDP drm/msm/dp: Handle eDP mode_valid case drm/msm/dp: Support edp/dp without hpd arch/arm64/boot/dts/qcom/sc7280-crd.dts | 111 arch/arm64/boot/dts/qcom/sc7280.dtsi| 2 +- drivers/gpu/drm/msm/dp/dp_aux.c | 6 ++ drivers/gpu/drm/msm/dp/dp_catalog.c | 38 --- drivers/gpu/drm/msm/dp/dp_catalog.h | 1 + drivers/gpu/drm/msm/dp/dp_display.c | 95 +-- drivers/gpu/drm/msm/dp/dp_drm.c | 10 +-- drivers/gpu/drm/msm/dp/dp_parser.c | 21 +- drivers/gpu/drm/msm/dp/dp_parser.h | 1 + drivers/gpu/drm/msm/dp/dp_reg.h | 7 +- drivers/gpu/drm/panel/panel-edp.c | 1 + 11 files changed, 254 insertions(+), 39 deletions(-) -- 2.7.4
[PATCH v5 1/9] arm64: dts: qcom: sc7280: rename edp_out label to mdss_edp_out
Rename the edp_out label in the sc7280 platform to mdss_edp_out
so that the nodes related to mdss are all grouped together in
the board specific files.
Signed-off-by: Sankeerth Billakanti
---
Changes in v5:
- Change the order of patches
- Modify commit text
arch/arm64/boot/dts/qcom/sc7280.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
b/arch/arm64/boot/dts/qcom/sc7280.dtsi
index c07765d..bcf7562 100644
--- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
@@ -3332,7 +3332,7 @@
port@1 {
reg = <1>;
- edp_out: endpoint { };
+ mdss_edp_out: endpoint { };
};
};
--
2.7.4
[PATCH v5 2/9] arm64: dts: qcom: sc7280: Add support for eDP panel on CRD
Enable support for eDP interface via aux_bus on CRD platform.
Signed-off-by: Sankeerth Billakanti
---
Changes in v5:
- Change the order of patches
- Remove the backlight nodes
- Remove the bias setting
- Fix compilation issue
- Model VREG_EDP_BP for backlight power
Changes in v4:
- Create new patch for name changes
- Remove output-low
Changes in v3:
- Sort the nodes alphabetically
- Use - instead of _ as node names
- Place the backlight and panel nodes under root
- Change the name of edp_out to mdss_edp_out
- Change the names of regulator nodes
- Delete unused properties in the board file
Changes in v2:
- Sort node references alphabetically
- Improve readability
- Move the pwm pinctrl to pwm node
- Move the regulators to root
- Define backlight power
- Remove dummy regulator node
- Cleanup pinctrl definitions
arch/arm64/boot/dts/qcom/sc7280-crd.dts | 93 +
1 file changed, 93 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7280-crd.dts
b/arch/arm64/boot/dts/qcom/sc7280-crd.dts
index e2efbdd..2df654e 100644
--- a/arch/arm64/boot/dts/qcom/sc7280-crd.dts
+++ b/arch/arm64/boot/dts/qcom/sc7280-crd.dts
@@ -7,6 +7,7 @@
/dts-v1/;
+#include
#include "sc7280-idp.dtsi"
#include "sc7280-idp-ec-h1.dtsi"
@@ -21,6 +22,27 @@
chosen {
stdout-path = "serial0:115200n8";
};
+
+ edp_3v3_regulator: edp-3v3-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "edp_3v3_regulator";
+
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+
+ gpio = <&tlmm 80 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&edp_panel_power>;
+ };
+
+ vreg_edp_bp: vreg-edp-bp-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vreg_edp_bp";
+ regulator-always-on;
+ regulator-boot-on;
+ };
};
&apps_rsc {
@@ -76,6 +98,58 @@ ap_ts_pen_1v8: &i2c13 {
};
};
+&mdss {
+ status = "okay";
+};
+
+&mdss_dp {
+ status = "okay";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&dp_hot_plug_det>;
+ data-lanes = <0 1>;
+ vdda-1p2-supply = <&vreg_l6b_1p2>;
+ vdda-0p9-supply = <&vreg_l1b_0p8>;
+};
+
+&mdss_edp {
+ status = "okay";
+
+ data-lanes = <0 1 2 3>;
+ vdda-1p2-supply = <&vreg_l6b_1p2>;
+ vdda-0p9-supply = <&vreg_l10c_0p8>;
+
+ aux-bus {
+ edp_panel: edp-panel {
+ compatible = "edp-panel";
+
+ power-supply = <&edp_3v3_regulator>;
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@0 {
+ reg = <0>;
+ edp_panel_in: endpoint {
+ remote-endpoint =
<&mdss_edp_out>;
+ };
+ };
+ };
+ };
+ };
+};
+
+&mdss_edp_out {
+ remote-endpoint = <&edp_panel_in>;
+};
+
+&mdss_edp_phy {
+ status = "okay";
+};
+
+&mdss_mdp {
+ status = "okay";
+};
+
&nvme_3v3_regulator {
gpio = <&tlmm 51 GPIO_ACTIVE_HIGH>;
};
@@ -84,7 +158,26 @@ ap_ts_pen_1v8: &i2c13 {
pins = "gpio51";
};
+&pm8350c_gpios {
+ edp_bl_power: edp-bl-power {
+ pins = "gpio7";
+ function = "normal";
+ qcom,drive-strength = ;
+ };
+
+ edp_bl_pwm: edp-bl-pwm {
+ pins = "gpio8";
+ function = "func1";
+ qcom,drive-strength = ;
+ };
+};
+
&tlmm {
+ edp_panel_power: edp-panel-power {
+ pins = "gpio80";
+ function = "gpio";
+ };
+
tp_int_odl: tp-int-odl {
pins = "gpio7";
function = "gpio";
--
2.7.4
[PATCH v5 3/9] arm64: dts: qcom: sc7280: Enable backlight for eDP panel
Enable backlight support for eDP panel on CRD platform for sc7280.
Signed-off-by: Sankeerth Billakanti
---
Changes in v5:
- Separate out backlight nodes
arch/arm64/boot/dts/qcom/sc7280-crd.dts | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7280-crd.dts
b/arch/arm64/boot/dts/qcom/sc7280-crd.dts
index 2df654e..16d1a5b 100644
--- a/arch/arm64/boot/dts/qcom/sc7280-crd.dts
+++ b/arch/arm64/boot/dts/qcom/sc7280-crd.dts
@@ -37,6 +37,15 @@
pinctrl-0 = <&edp_panel_power>;
};
+ edp_backlight: edp-backlight {
+ compatible = "pwm-backlight";
+
+ power-supply = <&vreg_edp_bp>;
+ pwms = <&pm8350c_pwm 3 65535>;
+
+ enable-gpios = <&pm8350c_gpios 7 GPIO_ACTIVE_HIGH>;
+ };
+
vreg_edp_bp: vreg-edp-bp-regulator {
compatible = "regulator-fixed";
regulator-name = "vreg_edp_bp";
@@ -123,7 +132,9 @@ ap_ts_pen_1v8: &i2c13 {
edp_panel: edp-panel {
compatible = "edp-panel";
+ backlight = <&edp_backlight>;
power-supply = <&edp_3v3_regulator>;
+
ports {
#address-cells = <1>;
#size-cells = <0>;
@@ -172,6 +183,13 @@ ap_ts_pen_1v8: &i2c13 {
};
};
+&pm8350c_pwm {
+ status = "okay";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&edp_bl_pwm>;
+};
+
&tlmm {
edp_panel_power: edp-panel-power {
pins = "gpio80";
--
2.7.4
[PATCH v5 4/9] drm/panel-edp: add LQ140M1JW46 edp panel entry
Add panel identification entry for the sharp LQ140M1JW46 eDP panel
with power sequencing delay information.
Signed-off-by: Sankeerth Billakanti
---
drivers/gpu/drm/panel/panel-edp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/panel/panel-edp.c
b/drivers/gpu/drm/panel/panel-edp.c
index f7bfcf6..e15e62f 100644
--- a/drivers/gpu/drm/panel/panel-edp.c
+++ b/drivers/gpu/drm/panel/panel-edp.c
@@ -1859,6 +1859,7 @@ static const struct edp_panel_entry edp_panels[] = {
EDP_PANEL_ENTRY('K', 'D', 'B', 0x0624,
&kingdisplay_kd116n21_30nv_a010.delay, "116N21-30NV-A010"),
EDP_PANEL_ENTRY('K', 'D', 'B', 0x1120, &delay_200_500_e80_d50,
"116N29-30NK-C007"),
+ EDP_PANEL_ENTRY('S', 'H', 'P', 0x1523, &sharp_lq140m1jw46.delay,
"LQ140M1JW46"),
EDP_PANEL_ENTRY('S', 'H', 'P', 0x154c, &delay_200_500_p2e100,
"LQ116M1JW10"),
EDP_PANEL_ENTRY('S', 'T', 'A', 0x0100, &delay_100_500_e200,
"2081116HHD028001-51D"),
--
2.7.4
[PATCH v5 5/9] drm/msm/dp: Add eDP support via aux_bus
This patch adds support for generic eDP sink through aux_bus.
The eDP/DP controller driver should support aux transactions originating
from the panel-edp driver and hence should be initialized and ready.
The panel bridge supporting the panel should be ready before
the bridge connector is initialized. The generic panel probe needs the
controller resources to be enabled to support aux tractions originating
from it. So, the host_init and phy_init are moved to execute before the
panel probe.
The host_init has to return early if the core is already
initialized so that the regulator and clock votes for the controller
resources are balanced.
EV_HPD_INIT_SETUP needs to execute immediately to enable the
interrupts for the aux transactions from panel-edp to get the modes
supported.
Signed-off-by: Sankeerth Billakanti
---
drivers/gpu/drm/msm/dp/dp_display.c | 65 +++--
drivers/gpu/drm/msm/dp/dp_drm.c | 10 +++---
drivers/gpu/drm/msm/dp/dp_parser.c | 21 +---
drivers/gpu/drm/msm/dp/dp_parser.h | 1 +
4 files changed, 70 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index 382b3aa..688bbed 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include "msm_drv.h"
#include "msm_kms.h"
@@ -265,8 +266,6 @@ static int dp_display_bind(struct device *dev, struct
device *master,
goto end;
}
- dp->dp_display.next_bridge = dp->parser->next_bridge;
-
dp->aux->drm_dev = drm;
rc = dp_aux_register(dp->aux);
if (rc) {
@@ -421,6 +420,11 @@ static void dp_display_host_init(struct dp_display_private
*dp)
dp->dp_display.connector_type, dp->core_initialized,
dp->phy_initialized);
+ if (dp->core_initialized) {
+ DRM_DEBUG_DP("DP core already initialized\n");
+ return;
+ }
+
dp_power_init(dp->power, false);
dp_ctrl_reset_irq_ctrl(dp->ctrl, true);
dp_aux_init(dp->aux);
@@ -433,6 +437,11 @@ static void dp_display_host_deinit(struct
dp_display_private *dp)
dp->dp_display.connector_type, dp->core_initialized,
dp->phy_initialized);
+ if (!dp->core_initialized) {
+ DRM_DEBUG_DP("DP core not initialized\n");
+ return;
+ }
+
dp_ctrl_reset_irq_ctrl(dp->ctrl, false);
dp_aux_deinit(dp->aux);
dp_power_deinit(dp->power);
@@ -1502,7 +1511,7 @@ void msm_dp_irq_postinstall(struct msm_dp *dp_display)
dp_hpd_event_setup(dp);
- dp_add_event(dp, EV_HPD_INIT_SETUP, 0, 100);
+ dp_add_event(dp, EV_HPD_INIT_SETUP, 0, 0);
}
void msm_dp_debugfs_init(struct msm_dp *dp_display, struct drm_minor *minor)
@@ -1524,6 +1533,52 @@ void msm_dp_debugfs_init(struct msm_dp *dp_display,
struct drm_minor *minor)
}
}
+static int dp_display_get_next_bridge(struct msm_dp *dp)
+{
+ int rc = 0;
+ struct dp_display_private *dp_priv;
+ struct device_node *aux_bus;
+ struct device *dev;
+
+ dp_priv = container_of(dp, struct dp_display_private, dp_display);
+ dev = &dp_priv->pdev->dev;
+ aux_bus = of_get_child_by_name(dev->of_node, "aux-bus");
+
+ if (aux_bus) {
+ dp_display_host_init(dp_priv);
+ dp_catalog_ctrl_hpd_config(dp_priv->catalog);
+ enable_irq(dp_priv->irq);
+ dp_display_host_phy_init(dp_priv);
+
+ devm_of_dp_aux_populate_ep_devices(dp_priv->aux);
+
+ disable_irq(dp_priv->irq);
+ }
+
+ /*
+* External bridges are mandatory for eDP interfaces: one has to
+* provide at least an eDP panel (which gets wrapped into panel-bridge).
+*
+* For DisplayPort interfaces external bridges are optional, so
+* silently ignore an error if one is not present (-ENODEV).
+*/
+ rc = dp_parser_find_next_bridge(dp_priv->parser);
+ if (rc == -ENODEV) {
+ if (dp->connector_type == DRM_MODE_CONNECTOR_eDP) {
+ DRM_ERROR("eDP: next bridge is not present\n");
+ return rc;
+ }
+ } else if (rc) {
+ if (rc != -EPROBE_DEFER)
+ DRM_ERROR("DP: error parsing next bridge: %d\n", rc);
+ return rc;
+ }
+
+ dp->next_bridge = dp_priv->parser->next_bridge;
+
+ return 0;
+}
+
int msm_dp_modeset_init(struct msm_dp *dp_display, struct drm_device *dev,
struct drm_encoder *encoder)
{
@@ -1547,6 +1602,10 @@ int msm_dp_modeset_init(struct msm_dp *dp_display,
struct drm_device *dev,
dp_display->encoder = encoder;
+ ret = dp_display_get_next_bridge(dp_display);
+ if (ret)
+ re
[PATCH v5 6/9] drm/msm/dp: wait for hpd high before any sink interaction
The source device should ensure the sink is ready before
proceeding to read the sink capability or performing any aux transactions.
The sink will indicate its readiness by asserting the HPD line.
The eDP sink requires power from the source and its HPD line will
be asserted only after the panel is powered on. The panel power will be
enabled from the panel-edp driver.
The controller driver needs to wait for the hpd line to be asserted
by the sink.
Signed-off-by: Sankeerth Billakanti
---
drivers/gpu/drm/msm/dp/dp_aux.c | 6 ++
drivers/gpu/drm/msm/dp/dp_catalog.c | 23 +++
drivers/gpu/drm/msm/dp/dp_catalog.h | 1 +
drivers/gpu/drm/msm/dp/dp_reg.h | 7 ++-
4 files changed, 36 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_aux.c b/drivers/gpu/drm/msm/dp/dp_aux.c
index 6d36f63..2ddc303 100644
--- a/drivers/gpu/drm/msm/dp/dp_aux.c
+++ b/drivers/gpu/drm/msm/dp/dp_aux.c
@@ -337,6 +337,12 @@ static ssize_t dp_aux_transfer(struct drm_dp_aux *dp_aux,
goto exit;
}
+ ret = dp_catalog_aux_wait_for_hpd_connect_state(aux->catalog);
+ if (ret) {
+ DRM_DEBUG_DP("DP sink not ready for aux transactions\n");
+ goto exit;
+ }
+
dp_aux_update_offset_and_segment(aux, msg);
dp_aux_transfer_helper(aux, msg, true);
diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c
b/drivers/gpu/drm/msm/dp/dp_catalog.c
index fac815f..2c3b0f7 100644
--- a/drivers/gpu/drm/msm/dp/dp_catalog.c
+++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
@@ -242,6 +242,29 @@ void dp_catalog_aux_update_cfg(struct dp_catalog
*dp_catalog)
phy_calibrate(phy);
}
+int dp_catalog_aux_wait_for_hpd_connect_state(struct dp_catalog *dp_catalog)
+{
+ u32 state, hpd_en, timeout;
+ struct dp_catalog_private *catalog = container_of(dp_catalog,
+ struct dp_catalog_private, dp_catalog);
+
+ hpd_en = dp_read_aux(catalog, REG_DP_DP_HPD_CTRL) &
+ DP_DP_HPD_CTRL_HPD_EN;
+
+ /* no-hpd case */
+ if (!hpd_en)
+ return 0;
+
+ /* Poll for HPD connected status */
+ timeout = dp_read_aux(catalog, REG_DP_DP_HPD_EVENT_TIME_0) &
+ DP_HPD_CONNECT_TIME_MASK;
+
+ return readl_poll_timeout(catalog->io->dp_controller.aux.base +
+ REG_DP_DP_HPD_INT_STATUS,
+ state, state & DP_DP_HPD_STATE_STATUS_CONNECTED,
+ 2000, timeout);
+}
+
static void dump_regs(void __iomem *base, int len)
{
int i;
diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.h
b/drivers/gpu/drm/msm/dp/dp_catalog.h
index 7dea101..45140a3 100644
--- a/drivers/gpu/drm/msm/dp/dp_catalog.h
+++ b/drivers/gpu/drm/msm/dp/dp_catalog.h
@@ -84,6 +84,7 @@ int dp_catalog_aux_clear_hw_interrupts(struct dp_catalog
*dp_catalog);
void dp_catalog_aux_reset(struct dp_catalog *dp_catalog);
void dp_catalog_aux_enable(struct dp_catalog *dp_catalog, bool enable);
void dp_catalog_aux_update_cfg(struct dp_catalog *dp_catalog);
+int dp_catalog_aux_wait_for_hpd_connect_state(struct dp_catalog *dp_catalog);
u32 dp_catalog_aux_get_irq(struct dp_catalog *dp_catalog);
/* DP Controller APIs */
diff --git a/drivers/gpu/drm/msm/dp/dp_reg.h b/drivers/gpu/drm/msm/dp/dp_reg.h
index 2686028..d68c71b 100644
--- a/drivers/gpu/drm/msm/dp/dp_reg.h
+++ b/drivers/gpu/drm/msm/dp/dp_reg.h
@@ -53,9 +53,14 @@
#define DP_DP_HPD_REFTIMER_ENABLE (1 << 16)
#define REG_DP_DP_HPD_EVENT_TIME_0 (0x001C)
-#define REG_DP_DP_HPD_EVENT_TIME_1 (0x0020)
#define DP_DP_HPD_EVENT_TIME_0_VAL (0x3E800FA)
+#define DP_HPD_GLITCH_TIME_MASK(0xFFFC)
+#define DP_HPD_CONNECT_TIME_MASK (0x0003)
+
+#define REG_DP_DP_HPD_EVENT_TIME_1 (0x0020)
#define DP_DP_HPD_EVENT_TIME_1_VAL (0x1F407D0)
+#define DP_HPD_DISCONNECT_TIME_MASK(0xC000)
+#define DP_IRQ_HPD_MAX_TIME_MASK (0x3FFF)
#define REG_DP_AUX_CTRL(0x0030)
#define DP_AUX_CTRL_ENABLE (0x0001)
--
2.7.4
[PATCH v5 7/9] drm/msm/dp: Support only IRQ_HPD and REPLUG interrupts for eDP
The panel-edp enables the eDP panel power during probe, get_modes
and enable. The eDP connect and disconnect interrupts for the eDP/DP
controller are directly dependent on panel power. As eDP display can be
assumed as always connected, the controller driver can skip the eDP
connect and disconnect interrupts. Any disruption in the link status
will be indicated via the IRQ_HPD interrupts.
So, the eDP controller driver can just enable the IRQ_HPD and
replug interrupts. The DP controller driver still needs to enable all
the interrupts.
The interrupt register will still reflect the connect and
disconnect interrupt status without generating an actual HW interrupt.
The controller driver should not handle those masked interrupts.
Signed-off-by: Sankeerth Billakanti
---
drivers/gpu/drm/msm/dp/dp_catalog.c | 9 +++--
drivers/gpu/drm/msm/dp/dp_display.c | 24 ++--
2 files changed, 25 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c
b/drivers/gpu/drm/msm/dp/dp_catalog.c
index 2c3b0f7..f15316b 100644
--- a/drivers/gpu/drm/msm/dp/dp_catalog.c
+++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
@@ -592,10 +592,6 @@ void dp_catalog_ctrl_hpd_config(struct dp_catalog
*dp_catalog)
u32 reftimer = dp_read_aux(catalog, REG_DP_DP_HPD_REFTIMER);
- /* enable HPD plug and unplug interrupts */
- dp_catalog_hpd_config_intr(dp_catalog,
- DP_DP_HPD_PLUG_INT_MASK | DP_DP_HPD_UNPLUG_INT_MASK, true);
-
/* Configure REFTIMER and enable it */
reftimer |= DP_DP_HPD_REFTIMER_ENABLE;
dp_write_aux(catalog, REG_DP_DP_HPD_REFTIMER, reftimer);
@@ -622,13 +618,14 @@ u32 dp_catalog_hpd_get_intr_status(struct dp_catalog
*dp_catalog)
{
struct dp_catalog_private *catalog = container_of(dp_catalog,
struct dp_catalog_private, dp_catalog);
- int isr = 0;
+ int isr, mask;
isr = dp_read_aux(catalog, REG_DP_DP_HPD_INT_STATUS);
dp_write_aux(catalog, REG_DP_DP_HPD_INT_ACK,
(isr & DP_DP_HPD_INT_MASK));
+ mask = dp_read_aux(catalog, REG_DP_DP_HPD_INT_MASK);
- return isr;
+ return isr & (DP_DP_HPD_STATE_STATUS_MASK | mask);
}
int dp_catalog_ctrl_get_interrupt(struct dp_catalog *dp_catalog)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index 688bbed..5775db8 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -687,7 +687,8 @@ static int dp_hpd_unplug_handle(struct dp_display_private
*dp, u32 data)
dp_display_handle_plugged_change(&dp->dp_display, false);
/* enable HDP plug interrupt to prepare for next plugin */
- dp_catalog_hpd_config_intr(dp->catalog, DP_DP_HPD_PLUG_INT_MASK, true);
+ if (dp->dp_display.connector_type == DRM_MODE_CONNECTOR_DisplayPort)
+ dp_catalog_hpd_config_intr(dp->catalog,
DP_DP_HPD_PLUG_INT_MASK, true);
DRM_DEBUG_DP("After, type=%d hpd_state=%d\n",
dp->dp_display.connector_type, state);
@@ -1096,10 +1097,17 @@ void msm_dp_snapshot(struct msm_disp_state *disp_state,
struct msm_dp *dp)
static void dp_display_config_hpd(struct dp_display_private *dp)
{
-
dp_display_host_init(dp);
+
dp_catalog_ctrl_hpd_config(dp->catalog);
+ /* Enable plug and unplug interrupts only for external DisplayPort */
+ if (dp->dp_display.connector_type == DRM_MODE_CONNECTOR_DisplayPort)
+ dp_catalog_hpd_config_intr(dp->catalog,
+ DP_DP_HPD_PLUG_INT_MASK |
+ DP_DP_HPD_UNPLUG_INT_MASK,
+ true);
+
/* Enable interrupt first time
* we are leaving dp clocks on during disconnect
* and never disable interrupt
@@ -1383,6 +1391,12 @@ static int dp_pm_resume(struct device *dev)
dp_catalog_ctrl_hpd_config(dp->catalog);
+ if (dp->dp_display.connector_type == DRM_MODE_CONNECTOR_DisplayPort)
+ dp_catalog_hpd_config_intr(dp->catalog,
+ DP_DP_HPD_PLUG_INT_MASK |
+ DP_DP_HPD_UNPLUG_INT_MASK,
+ true);
+
if (dp_catalog_link_is_connected(dp->catalog)) {
/*
* set sink to normal operation mode -- D0
@@ -1647,6 +1661,9 @@ void dp_bridge_enable(struct drm_bridge *drm_bridge)
return;
}
+ if (dp->connector_type == DRM_MODE_CONNECTOR_eDP)
+ dp_hpd_plug_handle(dp_display, 0);
+
mutex_lock(&dp_display->event_mutex);
/* stop sentinel checking */
@@ -1711,6 +1728,9 @@ void dp_bridge_post_disable(struct drm_bridge *drm_bridge)
dp_display = container_of(dp, struct dp_display_private, dp_display);
+ if (dp->connector_type == DRM_MODE_CONNECTOR_eDP)
+ dp_hpd_unplu
[PATCH v5 8/9] drm/msm/dp: Handle eDP mode_valid case
The panel-edp driver modes needs to be validated differently from DP
because the link capabilities are not available for EDP by that time.
Signed-off-by: Sankeerth Billakanti
---
drivers/gpu/drm/msm/dp/dp_display.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index 5775db8..8b150d1 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -1002,6 +1002,12 @@ enum drm_mode_status dp_bridge_mode_valid(struct
drm_bridge *bridge,
return -EINVAL;
}
+ if (dp->connector_type == DRM_MODE_CONNECTOR_eDP) {
+ if (mode_pclk_khz > DP_MAX_PIXEL_CLK_KHZ)
+ return MODE_CLOCK_HIGH;
+ return MODE_OK;
+ }
+
if ((dp->max_pclk_khz <= 0) ||
(dp->max_pclk_khz > DP_MAX_PIXEL_CLK_KHZ) ||
(mode->clock > dp->max_pclk_khz))
--
2.7.4
[PATCH v5 9/9] drm/msm/dp: Support edp/dp without hpd
Some eDP sinks or platform boards will not support hpd. This patch adds support for those cases. Signed-off-by: Sankeerth Billakanti --- drivers/gpu/drm/msm/dp/dp_catalog.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c b/drivers/gpu/drm/msm/dp/dp_catalog.c index f15316b..f8ddc73 100644 --- a/drivers/gpu/drm/msm/dp/dp_catalog.c +++ b/drivers/gpu/drm/msm/dp/dp_catalog.c @@ -596,8 +596,10 @@ void dp_catalog_ctrl_hpd_config(struct dp_catalog *dp_catalog) reftimer |= DP_DP_HPD_REFTIMER_ENABLE; dp_write_aux(catalog, REG_DP_DP_HPD_REFTIMER, reftimer); - /* Enable HPD */ - dp_write_aux(catalog, REG_DP_DP_HPD_CTRL, DP_DP_HPD_CTRL_HPD_EN); + /* Enable HPD if supported*/ + if (!of_property_read_bool(catalog->dev->of_node, "no-hpd")) + dp_write_aux(catalog, REG_DP_DP_HPD_CTRL, + DP_DP_HPD_CTRL_HPD_EN); } u32 dp_catalog_link_is_connected(struct dp_catalog *dp_catalog) -- 2.7.4
RE: [Intel-gfx] [PATCH] drm/i915: avoid concurrent writes to aux_inv
>> diff --git a/drivers/gpu/drm/i915/gt/gen2_engine_cs.c
>> b/drivers/gpu/drm/i915/gt/gen2_engine_cs.c
>> index 1c82caf525c3..0ec4986e4805 100644
>> --- a/drivers/gpu/drm/i915/gt/gen2_engine_cs.c
>> +++ b/drivers/gpu/drm/i915/gt/gen2_engine_cs.c
>> @@ -37,6 +37,9 @@ int gen2_emit_flush(struct i915_request *rq, u32
>> mode)
>>
>> intel_ring_advance(rq, cs);
>>
>> +/* hsdes: 1809175790. No fixup needed for gen2 */
>> +rq->aux_inv_fixup = NULL;
>
> Same thing that Stuart mentioned - would it not work for instance to
> initialize this in __i915_request_create?
I didn't try __i915_request_create because there is code like the following in
the driver, and I'm not sure how many such allocation is there. I will give it
a shot.
struct measure_breadcrumb {
struct i915_request rq;
struct intel_ring ring;
u32 cs[2048];
};
static int measure_breadcrumb_dw(struct intel_context *ce)
{
struct intel_engine_cs *engine = ce->engine;
struct measure_breadcrumb *frame;
int dw;
GEM_BUG_ON(!engine->gt->scratch);
frame = kzalloc(sizeof(*frame), GFP_KERNEL);
if (!frame)
return -ENOMEM;
frame->rq.engine = engine;
frame->rq.context = ce;
...
}
>> +
>> return 0;
>> }
>>
[PATCH] drm/panel: add CONFIG_DRM_KMS_HELPER dependencies
From: Arnd Bergmann The driver fails to build when the KMS helpers are disabled: ld.lld: error: undefined symbol: drm_gem_fb_get_obj >>> referenced by drm_mipi_dbi.c >>> gpu/drm/drm_mipi_dbi.o:(mipi_dbi_buf_copy) in archive >>> drivers/built-in.a >>> referenced by drm_mipi_dbi.c >>> gpu/drm/drm_mipi_dbi.o:(mipi_dbi_fb_dirty) in archive >>> drivers/built-in.a ld.lld: error: undefined symbol: drm_gem_fb_begin_cpu_access >>> referenced by drm_mipi_dbi.c >>> gpu/drm/drm_mipi_dbi.o:(mipi_dbi_buf_copy) in archive >>> drivers/built-in.a ld.lld: error: undefined symbol: drm_fb_swab >>> referenced by drm_mipi_dbi.c >>> gpu/drm/drm_mipi_dbi.o:(mipi_dbi_buf_copy) in archive >>> drivers/built-in.a ld.lld: error: undefined symbol: drm_fb_xrgb_to_rgb565 >>> referenced by drm_mipi_dbi.c >>> gpu/drm/drm_mipi_dbi.o:(mipi_dbi_buf_copy) in archive >>> drivers/built-in.a ld.lld: error: undefined symbol: drm_fb_memcpy >>> referenced by drm_mipi_dbi.c >>> gpu/drm/drm_mipi_dbi.o:(mipi_dbi_buf_copy) in archive >>> drivers/built-in.a This is fairly hard to hit in randconfig drivers, but it eventually did trigger for me in a configuration where all other DRM drivers are loadable modules, but DRM_PANEL_WIDECHIPS_WS2401 was built-in. Adding a dependency in all drivers that select DRM_MIPI_DBI avoids the problem for now, adding the dependency in DRM_MIPI_DBI as well should help make it easier to figure out why it breaks if someone forgets the dependency the next time. Signed-off-by: Arnd Bergmann --- drivers/gpu/drm/Kconfig | 2 +- drivers/gpu/drm/panel/Kconfig | 4 2 files changed, 5 insertions(+), 1 deletion(-) I see this warning on 5.17-rc8, but did not test it on linux-next, which may already have a fix. diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index b1f22e457fd0..d5ec0b77c010 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -30,7 +30,7 @@ menuconfig DRM config DRM_MIPI_DBI tristate - depends on DRM + depends on DRM_KMS_HELPER config DRM_MIPI_DSI bool diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig index 0aec5a10b064..96887d0efb9f 100644 --- a/drivers/gpu/drm/panel/Kconfig +++ b/drivers/gpu/drm/panel/Kconfig @@ -425,6 +425,7 @@ config DRM_PANEL_SAMSUNG_DB7430 tristate "Samsung DB7430-based DPI panels" depends on OF && SPI && GPIOLIB depends on BACKLIGHT_CLASS_DEVICE + depends on DRM_KMS_HELPER select DRM_MIPI_DBI help Say Y here if you want to enable support for the Samsung @@ -440,6 +441,7 @@ config DRM_PANEL_SAMSUNG_S6D16D0 config DRM_PANEL_SAMSUNG_S6D27A1 tristate "Samsung S6D27A1 DPI panel driver" depends on OF && SPI && GPIOLIB + depends on DRM_KMS_HELPER select DRM_MIPI_DBI help Say Y here if you want to enable support for the Samsung @@ -476,6 +478,7 @@ config DRM_PANEL_SAMSUNG_S6E63M0_SPI depends on SPI depends on DRM_PANEL_SAMSUNG_S6E63M0 default DRM_PANEL_SAMSUNG_S6E63M0 + depends on DRM_KMS_HELPER select DRM_MIPI_DBI help Say Y here if you want to be able to access the Samsung @@ -677,6 +680,7 @@ config DRM_PANEL_WIDECHIPS_WS2401 tristate "Widechips WS2401 DPI panel driver" depends on SPI && GPIOLIB depends on BACKLIGHT_CLASS_DEVICE + depends on DRM_KMS_HELPER select DRM_MIPI_DBI help Say Y here if you want to enable support for the Widechips WS2401 DPI -- 2.29.2
[PATCH] drm/tegra: vic: fix unused-function warnings
From: Arnd Bergmann
The use of the old-style SET_RUNTIME_PM_OPS() and
SET_SYSTEM_SLEEP_PM_OPS() macros requires function definitions
to be hidden to avoid
drivers/gpu/drm/tegra/vic.c:326:12: error: 'vic_runtime_suspend' defined but
not used [-Werror=unused-function]
326 | static int vic_runtime_suspend(struct device *dev)
|^~~
drivers/gpu/drm/tegra/vic.c:292:12: error: 'vic_runtime_resume' defined but not
used [-Werror=unused-function]
292 | static int vic_runtime_resume(struct device *dev)
|^~
Use the new-style SYSTEM_SLEEP_PM_OPS() and RUNTIME_PM_OPS() instead.
Fixes: 1e15f5b911d6 ("drm/tegra: vic: Stop channel on suspend")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/tegra/vic.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
I see this warning on 5.17-rc8, but did not test it on linux-next,
which may already have a fix.
diff --git a/drivers/gpu/drm/tegra/vic.c b/drivers/gpu/drm/tegra/vic.c
index 1e342fa3d27b..f56f5921a8c2 100644
--- a/drivers/gpu/drm/tegra/vic.c
+++ b/drivers/gpu/drm/tegra/vic.c
@@ -513,9 +513,8 @@ static int vic_remove(struct platform_device *pdev)
}
static const struct dev_pm_ops vic_pm_ops = {
- SET_RUNTIME_PM_OPS(vic_runtime_suspend, vic_runtime_resume, NULL)
- SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
- pm_runtime_force_resume)
+ RUNTIME_PM_OPS(vic_runtime_suspend, vic_runtime_resume, NULL)
+ SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend, pm_runtime_force_resume)
};
struct platform_driver tegra_vic_driver = {
--
2.29.2
[PATCH v3 0/3] Allow drm_writeback_connector to accept pointer to drm_encoder
There are some vendor drivers for which the writeback encoder shares hardware resources such as clocks and interrupts with the rest of the display pipeline. In addition, there can be use-cases where the writeback encoder could be a shared encoder between the physical display path and the writeback path. To accommodate for such cases, change the drm_writeback_connector to accept a pointer to drm_encoder. For existing users of drm_writeback_connector there will not be any change in functionality due to this change. This approach was first posted by Suraj Kandpal here [1] for both encoder and connector. But after discussions [2], the consensus was reached to split this change for the drm_encoder first and the drm_connector part can be reworked in a subsequent change later. Validation of this change was done using igt_writeback tests on MSM based RB5 board using the changes posted here [3]. For all other chipsets, these changes were compile-tested. [1] https://patchwork.kernel.org/project/dri-devel/patch/20220202081702.22119-1-suraj.kand...@intel.com/ [2] https://patchwork.kernel.org/project/dri-devel/patch/20220202085429.22261-6-suraj.kand...@intel.com/ [3] https://patchwork.freedesktop.org/series/99724/ changes in v3: - squash the vendor changes into the same commit so that each patch in the series can compile individually Abhinav Kumar (3): drm: allow real encoder to be passed for drm_writeback_connector drm: introduce drm_writeback_connector_init_with_encoder API drm/vc4: change vc4 driver to use drm_writeback_connector_init_with_encoder() .../drm/arm/display/komeda/komeda_wb_connector.c | 3 +- drivers/gpu/drm/arm/malidp_mw.c| 5 +- drivers/gpu/drm/drm_writeback.c| 145 +++-- drivers/gpu/drm/rcar-du/rcar_du_writeback.c| 5 +- drivers/gpu/drm/vc4/vc4_txp.c | 35 +++-- drivers/gpu/drm/vkms/vkms_writeback.c | 3 +- include/drm/drm_writeback.h| 27 +++- 7 files changed, 165 insertions(+), 58 deletions(-) -- 2.7.4
[PATCH v3 1/3] drm: allow real encoder to be passed for drm_writeback_connector
For some vendor driver implementations, display hardware can
be shared between the encoder used for writeback and the physical
display.
In addition resources such as clocks and interrupts can
also be shared between writeback and the real encoder.
To accommodate such vendor drivers and hardware, allow
real encoder to be passed for drm_writeback_connector using a new
drm_writeback_connector_init_with_encoder() API.
In addition, to preserve the same call flows for the existing
users of drm_writeback_connector_init(), also allow passing
possible_crtcs as a parameter so that encoder can be initialized
with it.
changes in v3:
- allow passing possible_crtcs for existing users of
drm_writeback_connector_init()
- squash the vendor changes into the same commit so
that each patch in the series can compile individually
Co-developed-by: Kandpal Suraj
Signed-off-by: Abhinav Kumar
---
.../drm/arm/display/komeda/komeda_wb_connector.c | 3 +-
drivers/gpu/drm/arm/malidp_mw.c| 5 +-
drivers/gpu/drm/drm_writeback.c| 103 +
drivers/gpu/drm/rcar-du/rcar_du_writeback.c| 5 +-
drivers/gpu/drm/vc4/vc4_txp.c | 19 ++--
drivers/gpu/drm/vkms/vkms_writeback.c | 3 +-
include/drm/drm_writeback.h| 22 -
7 files changed, 103 insertions(+), 57 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
b/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
index e465cc4..40774e6 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
@@ -155,7 +155,6 @@ static int komeda_wb_connector_add(struct komeda_kms_dev
*kms,
kwb_conn->wb_layer = kcrtc->master->wb_layer;
wb_conn = &kwb_conn->base;
- wb_conn->encoder.possible_crtcs = BIT(drm_crtc_index(&kcrtc->base));
formats = komeda_get_layer_fourcc_list(&mdev->fmt_tbl,
kwb_conn->wb_layer->layer_type,
@@ -164,7 +163,7 @@ static int komeda_wb_connector_add(struct komeda_kms_dev
*kms,
err = drm_writeback_connector_init(&kms->base, wb_conn,
&komeda_wb_connector_funcs,
&komeda_wb_encoder_helper_funcs,
- formats, n_formats);
+ formats, n_formats,
BIT(drm_crtc_index(&kcrtc->base)));
komeda_put_fourcc_list(formats);
if (err) {
kfree(kwb_conn);
diff --git a/drivers/gpu/drm/arm/malidp_mw.c b/drivers/gpu/drm/arm/malidp_mw.c
index f5847a7..b882066 100644
--- a/drivers/gpu/drm/arm/malidp_mw.c
+++ b/drivers/gpu/drm/arm/malidp_mw.c
@@ -208,11 +208,12 @@ int malidp_mw_connector_init(struct drm_device *drm)
struct malidp_drm *malidp = drm->dev_private;
u32 *formats;
int ret, n_formats;
+ uint32_t possible_crtcs;
if (!malidp->dev->hw->enable_memwrite)
return 0;
- malidp->mw_connector.encoder.possible_crtcs = 1 <<
drm_crtc_index(&malidp->crtc);
+ possible_crtcs = 1 << drm_crtc_index(&malidp->crtc);
drm_connector_helper_add(&malidp->mw_connector.base,
&malidp_mw_connector_helper_funcs);
@@ -223,7 +224,7 @@ int malidp_mw_connector_init(struct drm_device *drm)
ret = drm_writeback_connector_init(drm, &malidp->mw_connector,
&malidp_mw_connector_funcs,
&malidp_mw_encoder_helper_funcs,
- formats, n_formats);
+ formats, n_formats, possible_crtcs);
kfree(formats);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/drm_writeback.c b/drivers/gpu/drm/drm_writeback.c
index dccf4504..17c1471 100644
--- a/drivers/gpu/drm/drm_writeback.c
+++ b/drivers/gpu/drm/drm_writeback.c
@@ -149,36 +149,15 @@ static const struct drm_encoder_funcs
drm_writeback_encoder_funcs = {
.destroy = drm_encoder_cleanup,
};
-/**
- * drm_writeback_connector_init - Initialize a writeback connector and its
properties
- * @dev: DRM device
- * @wb_connector: Writeback connector to initialize
- * @con_funcs: Connector funcs vtable
- * @enc_helper_funcs: Encoder helper funcs vtable to be used by the internal
encoder
- * @formats: Array of supported pixel formats for the writeback engine
- * @n_formats: Length of the formats array
- *
- * This function creates the writeback-connector-specific properties if they
- * have not been already created, initializes the connector as
- * type DRM_MODE_CONNECTOR_WRITEBACK, and correctly initializes the property
- * values. It will also create an internal encoder associated with the
- * drm_writeback_connector and set it to
[PATCH v3 3/3] drm/vc4: change vc4 driver to use drm_writeback_connector_init_with_encoder()
vc4 driver currently embeds the drm_encoder into struct vc4_txp
and later on uses container_of to retrieve the vc4_txp from
the drm_encoder.
Since drm_encoder has now been made a pointer inside
drm_writeback_connector, make vc4 driver use the new API
so that the embedded encoder model can be retained in the
driver and there is no change in functionality.
changes in v3:
- none
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/vc4/vc4_txp.c | 22 ++
1 file changed, 18 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_txp.c b/drivers/gpu/drm/vc4/vc4_txp.c
index 32c4fb0..36dffcf 100644
--- a/drivers/gpu/drm/vc4/vc4_txp.c
+++ b/drivers/gpu/drm/vc4/vc4_txp.c
@@ -370,6 +370,10 @@ static const struct drm_encoder_helper_funcs
vc4_txp_encoder_helper_funcs = {
.disable = vc4_txp_encoder_disable,
};
+static const struct drm_encoder_funcs vc4_txp_encoder_funcs = {
+ .destroy = drm_encoder_cleanup,
+};
+
static int vc4_txp_enable_vblank(struct drm_crtc *crtc)
{
return 0;
@@ -498,13 +502,23 @@ static int vc4_txp_bind(struct device *dev, struct device
*master, void *data)
wb_conn = &txp->connector;
wb_conn->encoder = &txp->drm_enc;
+ drm_encoder_helper_add(wb_conn->encoder, &vc4_txp_encoder_helper_funcs);
+
+ ret = drm_encoder_init(drm, wb_conn->encoder,
+ &vc4_txp_encoder_funcs,
+ DRM_MODE_ENCODER_VIRTUAL, NULL);
+
+ if (ret)
+ return ret;
+
drm_connector_helper_add(&wb_conn->base,
&vc4_txp_connector_helper_funcs);
- ret = drm_writeback_connector_init(drm, wb_conn,
- &vc4_txp_connector_funcs, &vc4_txp_encoder_helper_funcs,
- drm_fmts, ARRAY_SIZE(drm_fmts), 0);
- if (ret)
+ ret = drm_writeback_connector_init_with_encoder(drm, wb_conn,
+ &vc4_txp_connector_funcs, drm_fmts,
ARRAY_SIZE(drm_fmts));
+ if (ret) {
+ drm_encoder_cleanup(wb_conn->encoder);
return ret;
+ }
ret = vc4_crtc_init(drm, vc4_crtc,
&vc4_txp_crtc_funcs, &vc4_txp_crtc_helper_funcs);
--
2.7.4
[PATCH v3 2/3] drm: introduce drm_writeback_connector_init_with_encoder API
For vendors drivers which pass an already allocated and
initialized encoder especially for cases where the encoder
hardware is shared OR the writeback encoder shares the resources
with the rest of the display pipeline introduce a new API,
drm_writeback_connector_init_with_encoder() which expects
an initialized encoder as a parameter and only sets up the
writeback connector.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/drm_writeback.c | 42 +
include/drm/drm_writeback.h | 5 +
2 files changed, 47 insertions(+)
diff --git a/drivers/gpu/drm/drm_writeback.c b/drivers/gpu/drm/drm_writeback.c
index 17c1471..373b7e9 100644
--- a/drivers/gpu/drm/drm_writeback.c
+++ b/drivers/gpu/drm/drm_writeback.c
@@ -265,6 +265,48 @@ int drm_writeback_connector_init(struct drm_device *dev,
}
EXPORT_SYMBOL(drm_writeback_connector_init);
+/**
+ * drm_writeback_connector_init_with_encoder - Initialize a writeback
connector and its properties
+ * using the encoder which already assigned and initialized
+ *
+ * @dev: DRM device
+ * @wb_connector: Writeback connector to initialize
+ * @con_funcs: Connector funcs vtable
+ * @enc_helper_funcs: Encoder helper funcs vtable to be used by the internal
encoder
+ * @formats: Array of supported pixel formats for the writeback engine
+ * @n_formats: Length of the formats array
+ *
+ * This function creates the writeback-connector-specific properties if they
+ * have not been already created, initializes the connector as
+ * type DRM_MODE_CONNECTOR_WRITEBACK, and correctly initializes the property
+ * values.
+ *
+ * This function assumes that the drm_writebac_connector's encoder has already
been
+ * created and initialized before invoking this function.
+ *
+ * In addition, this function also assumes that callers of this API will manage
+ * assigning the encoder helper functions, possible_crtcs and any other encoder
+ * specific operation which is otherwise handled by
drm_writeback_connector_init().
+ *
+ * Drivers should always use this function instead of drm_connector_init() to
+ * set up writeback connectors.
+ *
+ * Returns: 0 on success, or a negative error code
+ */
+int drm_writeback_connector_init_with_encoder(struct drm_device *dev,
+ struct drm_writeback_connector *wb_connector,
+ const struct drm_connector_funcs *con_funcs, const u32 *formats,
+ int n_formats)
+{
+ int ret = 0;
+
+ ret = drm_writeback_connector_setup(dev, wb_connector, con_funcs,
formats,
+ n_formats);
+
+ return ret;
+}
+EXPORT_SYMBOL(drm_writeback_connector_init_with_encoder);
+
int drm_writeback_set_fb(struct drm_connector_state *conn_state,
struct drm_framebuffer *fb)
{
diff --git a/include/drm/drm_writeback.h b/include/drm/drm_writeback.h
index 5e002bc..5e752c8 100644
--- a/include/drm/drm_writeback.h
+++ b/include/drm/drm_writeback.h
@@ -168,6 +168,11 @@ int drm_writeback_connector_init(struct drm_device *dev,
const struct drm_encoder_helper_funcs
*enc_helper_funcs,
const u32 *formats, int n_formats, uint32_t
possible_crtcs);
+int drm_writeback_connector_init_with_encoder(struct drm_device *dev,
+ struct drm_writeback_connector *wb_connector,
+ const struct drm_connector_funcs *con_funcs, const u32 *formats,
+ int n_formats);
+
int drm_writeback_set_fb(struct drm_connector_state *conn_state,
struct drm_framebuffer *fb);
--
2.7.4
Re: [PATCH] drm/panel: add CONFIG_DRM_KMS_HELPER dependencies
Hi Am 16.03.22 um 19:36 schrieb Arnd Bergmann: From: Arnd Bergmann The driver fails to build when the KMS helpers are disabled: ld.lld: error: undefined symbol: drm_gem_fb_get_obj referenced by drm_mipi_dbi.c gpu/drm/drm_mipi_dbi.o:(mipi_dbi_buf_copy) in archive drivers/built-in.a referenced by drm_mipi_dbi.c gpu/drm/drm_mipi_dbi.o:(mipi_dbi_fb_dirty) in archive drivers/built-in.a ld.lld: error: undefined symbol: drm_gem_fb_begin_cpu_access referenced by drm_mipi_dbi.c gpu/drm/drm_mipi_dbi.o:(mipi_dbi_buf_copy) in archive drivers/built-in.a ld.lld: error: undefined symbol: drm_fb_swab referenced by drm_mipi_dbi.c gpu/drm/drm_mipi_dbi.o:(mipi_dbi_buf_copy) in archive drivers/built-in.a ld.lld: error: undefined symbol: drm_fb_xrgb_to_rgb565 referenced by drm_mipi_dbi.c gpu/drm/drm_mipi_dbi.o:(mipi_dbi_buf_copy) in archive drivers/built-in.a ld.lld: error: undefined symbol: drm_fb_memcpy referenced by drm_mipi_dbi.c gpu/drm/drm_mipi_dbi.o:(mipi_dbi_buf_copy) in archive drivers/built-in.a This is fairly hard to hit in randconfig drivers, but it eventually did trigger for me in a configuration where all other DRM drivers are loadable modules, but DRM_PANEL_WIDECHIPS_WS2401 was built-in. Adding a dependency in all drivers that select DRM_MIPI_DBI avoids the problem for now, adding the dependency in DRM_MIPI_DBI as well should help make it easier to figure out why it breaks if someone forgets the dependency the next time. Signed-off-by: Arnd Bergmann --- drivers/gpu/drm/Kconfig | 2 +- drivers/gpu/drm/panel/Kconfig | 4 2 files changed, 5 insertions(+), 1 deletion(-) I see this warning on 5.17-rc8, but did not test it on linux-next, which may already have a fix. diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index b1f22e457fd0..d5ec0b77c010 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -30,7 +30,7 @@ menuconfig DRM config DRM_MIPI_DBI tristate - depends on DRM + depends on DRM_KMS_HELPER This symbol cannot be selected by users, so it's maybe not a good idea to depend on it. In fact, I've had to remove such a statement because it created a cyclic dependency. [1] Making the drivers depend on KMS helpers is the right thing though. If there's a better solution, please let me know. Best regards Thomas config DRM_MIPI_DSI bool diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig index 0aec5a10b064..96887d0efb9f 100644 --- a/drivers/gpu/drm/panel/Kconfig +++ b/drivers/gpu/drm/panel/Kconfig @@ -425,6 +425,7 @@ config DRM_PANEL_SAMSUNG_DB7430 tristate "Samsung DB7430-based DPI panels" depends on OF && SPI && GPIOLIB depends on BACKLIGHT_CLASS_DEVICE + depends on DRM_KMS_HELPER select DRM_MIPI_DBI help Say Y here if you want to enable support for the Samsung @@ -440,6 +441,7 @@ config DRM_PANEL_SAMSUNG_S6D16D0 config DRM_PANEL_SAMSUNG_S6D27A1 tristate "Samsung S6D27A1 DPI panel driver" depends on OF && SPI && GPIOLIB + depends on DRM_KMS_HELPER select DRM_MIPI_DBI help Say Y here if you want to enable support for the Samsung @@ -476,6 +478,7 @@ config DRM_PANEL_SAMSUNG_S6E63M0_SPI depends on SPI depends on DRM_PANEL_SAMSUNG_S6E63M0 default DRM_PANEL_SAMSUNG_S6E63M0 + depends on DRM_KMS_HELPER select DRM_MIPI_DBI help Say Y here if you want to be able to access the Samsung @@ -677,6 +680,7 @@ config DRM_PANEL_WIDECHIPS_WS2401 tristate "Widechips WS2401 DPI panel driver" depends on SPI && GPIOLIB depends on BACKLIGHT_CLASS_DEVICE + depends on DRM_KMS_HELPER select DRM_MIPI_DBI help Say Y here if you want to enable support for the Widechips WS2401 DPI -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev OpenPGP_signature Description: OpenPGP digital signature
Re: [PATCH v2 00/12] drm/gma500: Various cleanups to GEM code
Hi
Am 16.03.22 um 17:45 schrieb Patrik Jakobsson:
On Tue, Mar 8, 2022 at 8:52 PM Thomas Zimmermann wrote:
Refactor and simplify various parts of the memory management. This
includes locking, initialization and finalizer functions, and code
organization.
Tested on Atom N2800 hardware.
v2:
* put common code in psb_gtt_{init,fini,resume}() into
helpers (Sam, Patrik)
The series is pushed to drm-misc-next
Thanks a lot, Patrik!
Best regards
Thomas
Thanks
Patrik
Thomas Zimmermann (12):
drm/gma500: Remove struct psb_gem_object.npage
drm/gma500: Acquire reservation lock for GEM objects
drm/gma500: Move GTT locking into GTT helpers
drm/gma500: Remove struct psb_gtt.sem sempahore
drm/gma500: Move GTT setup and restoration into helper funtions
drm/gma500: Move GTT resume logic out of psb_gtt_init()
drm/gma500: Cleanup GTT uninit and error handling
drm/gma500: Split GTT init/resume/fini into GTT and GEM functions
drm/gma500: Inline psb_gtt_restore()
drm/gma500: Move GEM memory management functions to gem.c
drm/gma500: Move GTT enable and disable code into helpers
drm/gma500: Move GTT memory-range setup into helper
drivers/gpu/drm/gma500/gem.c | 161 ++-
drivers/gpu/drm/gma500/gem.h | 13 +-
drivers/gpu/drm/gma500/gma_display.c | 8 +-
drivers/gpu/drm/gma500/gtt.c | 295 +--
drivers/gpu/drm/gma500/gtt.h | 8 +-
drivers/gpu/drm/gma500/power.c | 5 +-
drivers/gpu/drm/gma500/psb_drv.c | 13 +-
drivers/gpu/drm/gma500/psb_drv.h | 1 -
8 files changed, 317 insertions(+), 187 deletions(-)
base-commit: 710a019ad85e96e66f7d75ee7f4733cdd8a2b0d0
prerequisite-patch-id: c2b2f08f0eccc9f5df0c0da49fa1d36267deb11d
prerequisite-patch-id: c67e5d886a47b7d0266d81100837557fda34cb24
prerequisite-patch-id: 6e1032c6302461624f33194c8b8f37103a3fa6ef
--
2.35.1
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PATCH] drm/panel: add CONFIG_DRM_KMS_HELPER dependencies
Am 16.03.22 um 20:12 schrieb Thomas Zimmermann: Hi Am 16.03.22 um 19:36 schrieb Arnd Bergmann: From: Arnd Bergmann The driver fails to build when the KMS helpers are disabled: ld.lld: error: undefined symbol: drm_gem_fb_get_obj referenced by drm_mipi_dbi.c gpu/drm/drm_mipi_dbi.o:(mipi_dbi_buf_copy) in archive drivers/built-in.a referenced by drm_mipi_dbi.c gpu/drm/drm_mipi_dbi.o:(mipi_dbi_fb_dirty) in archive drivers/built-in.a ld.lld: error: undefined symbol: drm_gem_fb_begin_cpu_access referenced by drm_mipi_dbi.c gpu/drm/drm_mipi_dbi.o:(mipi_dbi_buf_copy) in archive drivers/built-in.a ld.lld: error: undefined symbol: drm_fb_swab referenced by drm_mipi_dbi.c gpu/drm/drm_mipi_dbi.o:(mipi_dbi_buf_copy) in archive drivers/built-in.a ld.lld: error: undefined symbol: drm_fb_xrgb_to_rgb565 referenced by drm_mipi_dbi.c gpu/drm/drm_mipi_dbi.o:(mipi_dbi_buf_copy) in archive drivers/built-in.a ld.lld: error: undefined symbol: drm_fb_memcpy referenced by drm_mipi_dbi.c gpu/drm/drm_mipi_dbi.o:(mipi_dbi_buf_copy) in archive drivers/built-in.a This is fairly hard to hit in randconfig drivers, but it eventually did trigger for me in a configuration where all other DRM drivers are loadable modules, but DRM_PANEL_WIDECHIPS_WS2401 was built-in. Adding a dependency in all drivers that select DRM_MIPI_DBI avoids the problem for now, adding the dependency in DRM_MIPI_DBI as well should help make it easier to figure out why it breaks if someone forgets the dependency the next time. Signed-off-by: Arnd Bergmann --- drivers/gpu/drm/Kconfig | 2 +- drivers/gpu/drm/panel/Kconfig | 4 2 files changed, 5 insertions(+), 1 deletion(-) I see this warning on 5.17-rc8, but did not test it on linux-next, which may already have a fix. diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index b1f22e457fd0..d5ec0b77c010 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -30,7 +30,7 @@ menuconfig DRM config DRM_MIPI_DBI tristate - depends on DRM + depends on DRM_KMS_HELPER This symbol cannot be selected by users, so it's maybe not a good idea to depend on it. In fact, I've had to remove such a statement because it created a cyclic dependency. [1] [1] https://lore.kernel.org/dri-devel/20220315084559.23510-1-tzimmerm...@suse.de/ Making the drivers depend on KMS helpers is the right thing though. If there's a better solution, please let me know. Best regards Thomas config DRM_MIPI_DSI bool diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig index 0aec5a10b064..96887d0efb9f 100644 --- a/drivers/gpu/drm/panel/Kconfig +++ b/drivers/gpu/drm/panel/Kconfig @@ -425,6 +425,7 @@ config DRM_PANEL_SAMSUNG_DB7430 tristate "Samsung DB7430-based DPI panels" depends on OF && SPI && GPIOLIB depends on BACKLIGHT_CLASS_DEVICE + depends on DRM_KMS_HELPER select DRM_MIPI_DBI help Say Y here if you want to enable support for the Samsung @@ -440,6 +441,7 @@ config DRM_PANEL_SAMSUNG_S6D16D0 config DRM_PANEL_SAMSUNG_S6D27A1 tristate "Samsung S6D27A1 DPI panel driver" depends on OF && SPI && GPIOLIB + depends on DRM_KMS_HELPER select DRM_MIPI_DBI help Say Y here if you want to enable support for the Samsung @@ -476,6 +478,7 @@ config DRM_PANEL_SAMSUNG_S6E63M0_SPI depends on SPI depends on DRM_PANEL_SAMSUNG_S6E63M0 default DRM_PANEL_SAMSUNG_S6E63M0 + depends on DRM_KMS_HELPER select DRM_MIPI_DBI help Say Y here if you want to be able to access the Samsung @@ -677,6 +680,7 @@ config DRM_PANEL_WIDECHIPS_WS2401 tristate "Widechips WS2401 DPI panel driver" depends on SPI && GPIOLIB depends on BACKLIGHT_CLASS_DEVICE + depends on DRM_KMS_HELPER select DRM_MIPI_DBI help Say Y here if you want to enable support for the Widechips WS2401 DPI -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev OpenPGP_signature Description: OpenPGP digital signature
2022 X.Org Board of Directors Elections Nomination period is NOW
The Board consists of directors elected from the membership. Each year, an election is held to bring the total number of directors to eight. The four members receiving the highest vote totals will serve as directors for two year terms. The directors who received two year terms starting in 2021 were Lyude Paul, Samuel Iglesias Gonsálvez, Manasi D Navare and Daniel Vetter. They will continue to serve until their term ends in 2023. Current directors whose term expires in 2022 are Emma Anholt, Keith Packard, Harry Wentland and Mark Filion. A director is expected to participate in the fortnightly IRC meeting to discuss current business and to attend the annual meeting of the X.Org Foundation, which will be held at a location determined in advance by the Board of Directors. A member may nominate themselves or any other member they feel is qualified. Nominations should be sent to the Election Committee at elections at x.org. Nominees shall be required to be current members of the X.Org Foundation, and submit a personal statement of up to 200 words that will be provided to prospective voters. The collected statements, along with the statement of contribution to the X.Org Foundation in the member's account page on http://members.x.org, will be made available to all voters to help them make their voting decisions. Nominations, membership applications or renewals and completed personal statements must be received no later than 23:59 UTC on 20th March 2022. The slate of candidates will be published 28th March 2022 and candidate Q&A will begin then. The deadline for Xorg membership applications and renewals is 31st March 2022. Cheers, Lyude Paul, on behalf of the X.Org BoD
2022 X.Org Foundation Membership deadline for voting in the election
The 2022 X.Org Foundation elections are rapidly approaching. We will be forwarding the election schedule and nominating process to the membership shortly. Please note that only current members can vote in the upcoming election, and that the deadline for new memberships or renewals to vote in the upcoming election is 31 March 2022 at 23:59 UTC. If you are interested in joining the X.Org Foundation or in renewing your membership, please visit the membership system site at: https://members.x.org/ Lyude Paul, on behalf of the X.Org elections committee
[PATCH] drm/ttm: fix uninit ptr deref in range manager alloc error path
ttm_range_man_alloc would try to ttm_resource_fini the res pointer
before it is allocated.
Fixes: de3688e469b0 (drm/ttm: add ttm_resource_fini v2)
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/ttm/ttm_range_manager.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_range_manager.c
b/drivers/gpu/drm/ttm/ttm_range_manager.c
index 5662627bb933..1b4d8ca52f68 100644
--- a/drivers/gpu/drm/ttm/ttm_range_manager.c
+++ b/drivers/gpu/drm/ttm/ttm_range_manager.c
@@ -89,7 +89,7 @@ static int ttm_range_man_alloc(struct ttm_resource_manager
*man,
spin_unlock(&rman->lock);
if (unlikely(ret)) {
- ttm_resource_fini(man, *res);
+ ttm_resource_fini(man, &node->base);
kfree(node);
return ret;
}
--
2.25.1
Re: [PATCH v2 6/8] drm/shmem-helper: Add generic memory shrinker
On Mon, Mar 14, 2022 at 3:44 PM Dmitry Osipenko
wrote:
>
> Introduce a common DRM SHMEM shrinker. It allows to reduce code
> duplication among DRM drivers, it also handles complicated lockings
> for the drivers. This is initial version of the shrinker that covers
> basic needs of GPU drivers.
>
> This patch is based on a couple ideas borrowed from Rob's Clark MSM
> shrinker and Thomas' Zimmermann variant of SHMEM shrinker.
>
> GPU drivers that want to use generic DRM memory shrinker must support
> generic GEM reservations.
>
> Signed-off-by: Daniel Almeida
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/gpu/drm/drm_gem_shmem_helper.c | 194 +
> include/drm/drm_device.h | 4 +
> include/drm/drm_gem.h | 11 ++
> include/drm/drm_gem_shmem_helper.h | 25
> 4 files changed, 234 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
> b/drivers/gpu/drm/drm_gem_shmem_helper.c
> index 37009418cd28..35be2ee98f11 100644
> --- a/drivers/gpu/drm/drm_gem_shmem_helper.c
> +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
> @@ -139,6 +139,9 @@ void drm_gem_shmem_free(struct drm_gem_shmem_object
> *shmem)
> {
> struct drm_gem_object *obj = &shmem->base;
>
> + /* take out shmem GEM object from the memory shrinker */
> + drm_gem_shmem_madvise(shmem, 0);
> +
> WARN_ON(shmem->vmap_use_count);
>
> if (obj->import_attach) {
> @@ -163,6 +166,42 @@ void drm_gem_shmem_free(struct drm_gem_shmem_object
> *shmem)
> }
> EXPORT_SYMBOL_GPL(drm_gem_shmem_free);
>
> +static void drm_gem_shmem_update_purgeable_status(struct
> drm_gem_shmem_object *shmem)
> +{
> + struct drm_gem_object *obj = &shmem->base;
> + struct drm_gem_shmem_shrinker *gem_shrinker =
> obj->dev->shmem_shrinker;
> + size_t page_count = obj->size >> PAGE_SHIFT;
> +
> + if (!gem_shrinker || obj->import_attach || !obj->funcs->purge)
> + return;
> +
> + mutex_lock(&shmem->vmap_lock);
> + mutex_lock(&shmem->pages_lock);
> + mutex_lock(&gem_shrinker->lock);
> +
> + if (shmem->madv < 0) {
> + list_del_init(&shmem->madv_list);
> + goto unlock;
> + } else if (shmem->madv > 0) {
> + if (!list_empty(&shmem->madv_list))
> + goto unlock;
> +
> + WARN_ON(gem_shrinker->shrinkable_count + page_count <
> page_count);
> + gem_shrinker->shrinkable_count += page_count;
> +
> + list_add_tail(&shmem->madv_list, &gem_shrinker->lru);
> + } else if (!list_empty(&shmem->madv_list)) {
> + list_del_init(&shmem->madv_list);
> +
> + WARN_ON(gem_shrinker->shrinkable_count < page_count);
> + gem_shrinker->shrinkable_count -= page_count;
> + }
> +unlock:
> + mutex_unlock(&gem_shrinker->lock);
> + mutex_unlock(&shmem->pages_lock);
> + mutex_unlock(&shmem->vmap_lock);
> +}
> +
> static int drm_gem_shmem_get_pages_locked(struct drm_gem_shmem_object *shmem)
> {
> struct drm_gem_object *obj = &shmem->base;
> @@ -366,6 +405,8 @@ int drm_gem_shmem_vmap(struct drm_gem_shmem_object *shmem,
> ret = drm_gem_shmem_vmap_locked(shmem, map);
> mutex_unlock(&shmem->vmap_lock);
>
> + drm_gem_shmem_update_purgeable_status(shmem);
> +
> return ret;
> }
> EXPORT_SYMBOL(drm_gem_shmem_vmap);
> @@ -409,6 +450,8 @@ void drm_gem_shmem_vunmap(struct drm_gem_shmem_object
> *shmem,
> mutex_lock(&shmem->vmap_lock);
> drm_gem_shmem_vunmap_locked(shmem, map);
> mutex_unlock(&shmem->vmap_lock);
> +
> + drm_gem_shmem_update_purgeable_status(shmem);
> }
> EXPORT_SYMBOL(drm_gem_shmem_vunmap);
>
> @@ -451,6 +494,8 @@ int drm_gem_shmem_madvise(struct drm_gem_shmem_object
> *shmem, int madv)
>
> mutex_unlock(&shmem->pages_lock);
>
> + drm_gem_shmem_update_purgeable_status(shmem);
> +
> return (madv >= 0);
> }
> EXPORT_SYMBOL(drm_gem_shmem_madvise);
> @@ -763,6 +808,155 @@ drm_gem_shmem_prime_import_sg_table(struct drm_device
> *dev,
> }
> EXPORT_SYMBOL_GPL(drm_gem_shmem_prime_import_sg_table);
>
> +static struct drm_gem_shmem_shrinker *
> +to_drm_shrinker(struct shrinker *shrinker)
> +{
> + return container_of(shrinker, struct drm_gem_shmem_shrinker, base);
> +}
> +
> +static unsigned long
> +drm_gem_shmem_shrinker_count_objects(struct shrinker *shrinker,
> +struct shrink_control *sc)
> +{
> + struct drm_gem_shmem_shrinker *gem_shrinker =
> to_drm_shrinker(shrinker);
> + u64 count = gem_shrinker->shrinkable_count;
> +
> + if (count >= SHRINK_EMPTY)
> + return SHRINK_EMPTY - 1;
> +
> + return count ?: SHRINK_EMPTY;
> +}
> +
> +static unsigned long
> +drm_gem_shmem_shrinker_scan_objects(struct shrinker *shrinker,
> + struct shrink_control *sc)
> +{
> + st
Re: Parallel modesets and private state objects broken, where to go with MST?
On Wed, 2022-03-16 at 13:01 +0200, Ville Syrjälä wrote: > On Mon, Mar 14, 2022 at 06:16:36PM -0400, Lyude Paul wrote: > > Hi! First a little bit of background: I've recently been trying to get rid > > of > > all of the non-atomic payload bandwidth management code in the MST helpers > > in > > order to make it easier to implement DSC and fallback link rate retraining > > support down the line. Currently bandwidth information is stored in two > > places, partially in the MST atomic state and partially in the mst > > manager's > > payload table (which exists outside of the atomic state and has its own > > locking). The portions in the atomic state are used to try to determine if > > a > > given display configuration can fit within the given bandwidth limitations > > during the atomic check phase, and are implemented through the use of > > private > > state objects. > > > > My current goal has been to move as much of this as possible over to the > > atomic state and entirely get rid of the payload table along with it's > > locks. > > My main reason for doing this is that it both decomplicates things quite a > > bit, and I'm really also hoping that getting rid of that payload code will > > make it clearer to others how it works - and stop the influx of bandaid > > patches (e.g. adding more and more special cases to MST to fix poorly > > understood issues being hit in one specific driver and nowhere else) that > > I've > > had to spend way more time then I'd like trying to investigate and review. > > > > So, the actual problem: following a conversation with Daniel Vetter today > > I've > > gotten the impression that private modesetting objects are basically just > > broken with parallel modesets? I'm still wrapping my head around all of > > this > > honestly, but from what I've gathered: CRTC atomic infra knows how to do > > waits > > in the proper places for when other CRTCs need to be waited on to continue > > a > > modeset, but there's no such tracking with private objects. If I > > understand > > this correctly, that means that even if two CRTC modesets require pulling > > in > > the same private object state for the MST mgr: we're only provided a > > guarantee > > that the atomic checks pulling in that private object state won't > > concurrently. But when it comes to commits, it doesn't sound like there's > > any > > actual tracking for this and as such - two CRTC modesets which have both > > pulled in the MST private state object are not prevented from running > > concurrently. > > > > This unfortunately throws an enormous wrench into the MST atomic > > conversion > > I've been working on - as I was under the understanding while writing the > > code > > for this that all objects in an atomic state are blocked from being used > > in > > any new atomic commits (not checks, as parallel checks should be fine in > > my > > case) until there's no commits active with said object pulled into the > > atomic > > state. I certainly am not aware of any way parallel modesetting could > > actually > > be supported on MST, so it's not really a feature we want to deal with at > > all > > besides stopping it from happening. This also unfortunately means that the > > current atomic modesetting code we have for MST is potentially broken, > > although I assume we've never hit any real world issues with it because of > > the > > non-atomic locking we currently have for the payload table. > > > > So, Daniel had mentioned that supposedly you've been dealing with similar > > issues with VC4 and might have already made progress on coming up with > > ways to > > deal with it. If this is all correct, I'd definitely appreciate being able > > to > > take a look at your work on this to see how I can help move things > > forward. > > I've got a WIP of my atomic only MST branch as well: > > > > https://gitlab.freedesktop.org/lyudess/linux/-/commits/wip/mst-atomic-only-v1 > > > > However it's very certainly broken right now (it compiles and I had > > thought it > > worked already, but I realized I totally forgot to come up with a way of > > doing > > bookkeeping for VC start slots atomically - which is what led me down this > > current rabbit hole), but it should at least give a general idea of what > > I'm > > trying to do. > > > > Anyway, let me know what you think. > > For MST in particular parallel modeset on the same physical link sounds > pretty crazy to me. Trying to make sure everything happens in the right > order would not be pleasant. I think a simple solution would be just to > add all the crtcs on the affected link to the state and call it a day. JFYI I definitely don't have any kind of plan to try parallel modesetting with MST, I think it'd be near impossible to actually get working correctly for pretty little benefit :). I was just not entirely sure of the work that would be required to get private objects to do the right thing here in parallel modesets (e.g. make sure we wait on all CRTC commits like you mentioned
Re: [PATCH] drm/nouveau: Fix spelling mistake "endianess" -> "endianness"
Reviewed-by: Lyude Paul
Will push to drm-misc-next in just a moment
On Tue, 2022-03-15 at 22:19 +, Colin Ian King wrote:
> There is a spelling mistake in a nvdev_error error message. Fix it.
>
> Signed-off-by: Colin Ian King
> ---
> drivers/gpu/drm/nouveau/nvkm/engine/device/base.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
> b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
> index 88d262ba648c..62efbd0f3846 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
> @@ -2935,7 +2935,7 @@ nvkm_device_ctor(const struct nvkm_device_func *func,
> /* switch mmio to cpu's native endianness */
> if (!nvkm_device_endianness(device)) {
> nvdev_error(device,
> - "Couldn't switch GPU to CPUs
> endianess\n");
> + "Couldn't switch GPU to CPUs
> endianness\n");
> ret = -ENOSYS;
> goto done;
> }
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
Re: [PATCH] drm/panel: add CONFIG_DRM_KMS_HELPER dependencies
On Wed, Mar 16, 2022 at 8:31 PM Thomas Zimmermann wrote: > Am 16.03.22 um 20:12 schrieb Thomas Zimmermann: > >> > >> Adding a dependency in all drivers that select DRM_MIPI_DBI avoids > >> the problem for now, adding the dependency in DRM_MIPI_DBI as well > >> should help make it easier to figure out why it breaks if someone > >> forgets the dependency the next time. > >> > >> tristate > >> -depends on DRM > >> +depends on DRM_KMS_HELPER > > > > This symbol cannot be selected by users, so it's maybe not a good idea > > to depend on it. In fact, I've had to remove such a statement because it > > created a cyclic dependency. [1] I tried to explain above what I was thinking here: the added dependency is both a correct statement (DRM_MIPI_DBI depends on DRM_KMS_HELPER because it cannot be built without DRM_KMS_HELPER) and helpful as an indication what went wrong if we run into the same problem with a new driver, instead of the cryptic link failure you get something like WARNING: unmet direct dependencies detected for DRM_MIPI_DBI Depends on [m]: HAS_IOMEM [=y] && DRM_KMS_HELPER [=m] Selected by [y]: - DRM_PANEL_WIDECHIPS_WS2401 [=y] && HAS_IOMEM [=y] && DRM [=y] && DRM_PANEL [=y] && SPI [=y] && GPIOLIB [=y] && BACKLIGHT_CLASS_DEVICE [=y] Selected by [m]: - TINYDRM_ILI9225 [=m] && HAS_IOMEM [=y] && DRM [=y] && SPI [=y] > [1] > https://lore.kernel.org/dri-devel/20220315084559.23510-1-tzimmerm...@suse.de/ I was going for 'depends on' in the panel drivers because I saw the same being done for other panel drivers, and mixing the two methods causes dependency loops. I looked again now, and find that 'select DRM_KMS_HELPER' is more common for other drivers, and makes sense here because it is generally not user-selectable. The easiest replacement for my patch would then be to just use 'select DRM_KMS_HELPER' from CONFIG_DRM_MIPI_DBI, which makes it safer and more consistent with your change. If you like, I'll send an updated version. One thing I'm not sure about is whether there is still use for ever having CONFIG_DRM without CONFIG_DRM_KMS_HELPER if it gets selected by almost every driver anyway. Is this actually a configuration that users rely on, or should we just remove the symbol completely and build the KMS helpers unconditionally? Arnd
Re: [PATCH] drm: Don't make DRM_PANEL_BRIDGE dependent on DRM_KMS_HELPERS
On Tue, Mar 15, 2022 at 09:45:59AM +0100, Thomas Zimmermann wrote:
> Fix a number of undefined references to drm_kms_helper.ko in
> drm_dp_helper.ko:
>
> arm-suse-linux-gnueabi-ld: drivers/gpu/drm/dp/drm_dp_mst_topology.o: in
> function `drm_dp_mst_duplicate_state':
> drm_dp_mst_topology.c:(.text+0x2df0): undefined reference to
> `__drm_atomic_helper_private_obj_duplicate_state'
> arm-suse-linux-gnueabi-ld: drivers/gpu/drm/dp/drm_dp_mst_topology.o: in
> function `drm_dp_delayed_destroy_work':
> drm_dp_mst_topology.c:(.text+0x370c): undefined reference to
> `drm_kms_helper_hotplug_event'
> arm-suse-linux-gnueabi-ld: drivers/gpu/drm/dp/drm_dp_mst_topology.o: in
> function `drm_dp_mst_up_req_work':
> drm_dp_mst_topology.c:(.text+0x7938): undefined reference to
> `drm_kms_helper_hotplug_event'
> arm-suse-linux-gnueabi-ld: drivers/gpu/drm/dp/drm_dp_mst_topology.o: in
> function `drm_dp_mst_link_probe_work':
> drm_dp_mst_topology.c:(.text+0x82e0): undefined reference to
> `drm_kms_helper_hotplug_event'
>
> This happens if panel-edp.ko has been configured with
>
> DRM_PANEL_EDP=y
> DRM_DP_HELPER=y
> DRM_KMS_HELPER=m
>
> which builds DP helpers into the kernel and KMS helpers sa a module.
> Making DRM_PANEL_EDP select DRM_KMS_HELPER resolves this problem.
>
> To avoid a resulting cyclic dependency with DRM_PANEL_BRIDGE, don't
> make the latter depend on DRM_KMS_HELPER and fix the one DRM bridge
> drivers that doesn't already select DRM_KMS_HELPER. As KMS helpers
> cannot be selected directly by the user, config symbols should avoid
> depending on it anyway.
>
> Signed-off-by: Thomas Zimmermann
> Fixes: 3755d35ee1d2 ("drm/panel: Select DRM_DP_HELPER for DRM_PANEL_EDP")
> Reported-by: kernel test robot
> Cc: Thomas Zimmermann
> Cc: Naresh Kamboju
> Cc: Linux Kernel Functional Testing
> Cc: Lyude Paul
> Cc: Sam Ravnborg
> Cc: Daniel Vetter
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: dri-devel@lists.freedesktop.org
> Cc: Dave Airlie
> Cc: Thierry Reding
This patch fixes the build error that I see with qcom_defconfig in
linux-next.
Tested-by: Brian Masney
Re: [PATCH v2 1/2] drm: Add GPU reset sysfs event
On Tue, Mar 8, 2022 at 11:40 PM Shashank Sharma
wrote:
>
> From: Shashank Sharma
>
> This patch adds a new sysfs event, which will indicate
> the userland about a GPU reset, and can also provide
> some information like:
> - process ID of the process involved with the GPU reset
> - process name of the involved process
> - the GPU status info (using flags)
>
> This patch also introduces the first flag of the flags
> bitmap, which can be appended as and when required.
>
> V2: Addressed review comments from Christian and Amar
>- move the reset information structure to DRM layer
>- drop _ctx from struct name
>- make pid 32 bit(than 64)
>- set flag when VRAM invalid (than valid)
>- add process name as well (Amar)
>
> Cc: Alexandar Deucher
> Cc: Christian Koenig
> Cc: Amaranath Somalapuram
> Signed-off-by: Shashank Sharma
> ---
> drivers/gpu/drm/drm_sysfs.c | 31 +++
> include/drm/drm_sysfs.h | 10 ++
> 2 files changed, 41 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
> index 430e00b16eec..840994810910 100644
> --- a/drivers/gpu/drm/drm_sysfs.c
> +++ b/drivers/gpu/drm/drm_sysfs.c
> @@ -409,6 +409,37 @@ void drm_sysfs_hotplug_event(struct drm_device *dev)
> }
> EXPORT_SYMBOL(drm_sysfs_hotplug_event);
>
> +/**
> + * drm_sysfs_reset_event - generate a DRM uevent to indicate GPU reset
> + * @dev: DRM device
> + * @reset_info: The contextual information about the reset (like PID, flags)
> + *
> + * Send a uevent for the DRM device specified by @dev. This informs
> + * user that a GPU reset has occurred, so that an interested client
> + * can take any recovery or profiling measure.
> + */
> +void drm_sysfs_reset_event(struct drm_device *dev, struct drm_reset_event
> *reset_info)
> +{
> + unsigned char pid_str[13];
> + unsigned char flags_str[15];
> + unsigned char pname_str[TASK_COMM_LEN + 6];
> + unsigned char reset_str[] = "RESET=1";
> + char *envp[] = { reset_str, pid_str, pname_str, flags_str, NULL };
> +
> + if (!reset_info) {
> + DRM_WARN("No reset info, not sending the event\n");
> + return;
> + }
> +
> + DRM_DEBUG("generating reset event\n");
> +
> + snprintf(pid_str, ARRAY_SIZE(pid_str), "PID=%u", reset_info->pid);
> + snprintf(pname_str, ARRAY_SIZE(pname_str), "NAME=%s",
> reset_info->pname);
> + snprintf(flags_str, ARRAY_SIZE(flags_str), "FLAGS=%u",
> reset_info->flags);
> + kobject_uevent_env(&dev->primary->kdev->kobj, KOBJ_CHANGE, envp);
> +}
> +EXPORT_SYMBOL(drm_sysfs_reset_event);
> +
> /**
> * drm_sysfs_connector_hotplug_event - generate a DRM uevent for any
> connector
> * change
> diff --git a/include/drm/drm_sysfs.h b/include/drm/drm_sysfs.h
> index 6273cac44e47..5ba11c760619 100644
> --- a/include/drm/drm_sysfs.h
> +++ b/include/drm/drm_sysfs.h
> @@ -1,16 +1,26 @@
> /* SPDX-License-Identifier: GPL-2.0 */
> #ifndef _DRM_SYSFS_H_
> #define _DRM_SYSFS_H_
> +#include
> +
> +#define DRM_GPU_RESET_FLAG_VRAM_INVALID (1 << 0)
>
> struct drm_device;
> struct device;
> struct drm_connector;
> struct drm_property;
>
> +struct drm_reset_event {
> + uint32_t pid;
One side note, unrelated to devcoredump vs this..
AFAIU you probably want to be passing around a `struct pid *`, and
then somehow use pid_vnr() in the context of the process reading the
event to get the numeric pid. Otherwise things will not do what you
expect if the process triggering the crash is in a different pid
namespace from the compositor.
BR,
-R
> + uint32_t flags;
> + char pname[TASK_COMM_LEN];
> +};
> +
> int drm_class_device_register(struct device *dev);
> void drm_class_device_unregister(struct device *dev);
>
> void drm_sysfs_hotplug_event(struct drm_device *dev);
> +void drm_sysfs_reset_event(struct drm_device *dev, struct drm_reset_event
> *reset_info);
> void drm_sysfs_connector_hotplug_event(struct drm_connector *connector);
> void drm_sysfs_connector_status_event(struct drm_connector *connector,
> struct drm_property *property);
> --
> 2.32.0
>
[PATCH] drm/i915/uapi: Add DRM_I915_QUERY_GEOMETRY_SUBSLICES
Newer platforms have DSS that aren't necessarily available for both
geometry and compute, two queries will need to exist. This introduces
the first, when passing a valid engine class and engine instance in the
flags returns a topology describing geometry.
v2: fix white space errors
v3: change flags from hosting 2 8 bit numbers to holding a
i915_engine_class_instance struct
Cc: Ashutosh Dixit
Cc: Matt Roper
Cc: Joonas Lahtinen
UMD (mesa): https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14143
Signed-off-by: Matt Atwood
---
drivers/gpu/drm/i915/i915_query.c | 68 ++-
include/uapi/drm/i915_drm.h | 24 +++
2 files changed, 65 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_query.c
b/drivers/gpu/drm/i915/i915_query.c
index 2dfbc22857a3..fcb374201edb 100644
--- a/drivers/gpu/drm/i915/i915_query.c
+++ b/drivers/gpu/drm/i915/i915_query.c
@@ -9,6 +9,7 @@
#include "i915_drv.h"
#include "i915_perf.h"
#include "i915_query.h"
+#include "gt/intel_engine_user.h"
#include
static int copy_query_item(void *query_hdr, size_t query_sz,
@@ -28,36 +29,30 @@ static int copy_query_item(void *query_hdr, size_t query_sz,
return 0;
}
-static int query_topology_info(struct drm_i915_private *dev_priv,
- struct drm_i915_query_item *query_item)
+static int fill_topology_info(const struct sseu_dev_info *sseu,
+ struct drm_i915_query_item *query_item,
+ const u8 *subslice_mask)
{
- const struct sseu_dev_info *sseu = &to_gt(dev_priv)->info.sseu;
struct drm_i915_query_topology_info topo;
u32 slice_length, subslice_length, eu_length, total_length;
int ret;
- if (query_item->flags != 0)
- return -EINVAL;
+ BUILD_BUG_ON(sizeof(u8) != sizeof(sseu->slice_mask));
if (sseu->max_slices == 0)
return -ENODEV;
- BUILD_BUG_ON(sizeof(u8) != sizeof(sseu->slice_mask));
-
slice_length = sizeof(sseu->slice_mask);
subslice_length = sseu->max_slices * sseu->ss_stride;
eu_length = sseu->max_slices * sseu->max_subslices * sseu->eu_stride;
total_length = sizeof(topo) + slice_length + subslice_length +
eu_length;
- ret = copy_query_item(&topo, sizeof(topo), total_length,
- query_item);
+ ret = copy_query_item(&topo, sizeof(topo), total_length, query_item);
+
if (ret != 0)
return ret;
- if (topo.flags != 0)
- return -EINVAL;
-
memset(&topo, 0, sizeof(topo));
topo.max_slices = sseu->max_slices;
topo.max_subslices = sseu->max_subslices;
@@ -69,27 +64,61 @@ static int query_topology_info(struct drm_i915_private
*dev_priv,
topo.eu_stride = sseu->eu_stride;
if (copy_to_user(u64_to_user_ptr(query_item->data_ptr),
- &topo, sizeof(topo)))
+&topo, sizeof(topo)))
return -EFAULT;
if (copy_to_user(u64_to_user_ptr(query_item->data_ptr + sizeof(topo)),
- &sseu->slice_mask, slice_length))
+&sseu->slice_mask, slice_length))
return -EFAULT;
if (copy_to_user(u64_to_user_ptr(query_item->data_ptr +
- sizeof(topo) + slice_length),
- sseu->subslice_mask, subslice_length))
+sizeof(topo) + slice_length),
+subslice_mask, subslice_length))
return -EFAULT;
if (copy_to_user(u64_to_user_ptr(query_item->data_ptr +
- sizeof(topo) +
- slice_length + subslice_length),
- sseu->eu_mask, eu_length))
+sizeof(topo) +
+slice_length + subslice_length),
+sseu->eu_mask, eu_length))
return -EFAULT;
return total_length;
}
+static int query_topology_info(struct drm_i915_private *dev_priv,
+ struct drm_i915_query_item *query_item)
+{
+ const struct sseu_dev_info *sseu = &to_gt(dev_priv)->info.sseu;
+
+ if (query_item->flags != 0)
+ return -EINVAL;
+
+ return fill_topology_info(sseu, query_item, sseu->subslice_mask);
+}
+
+static int query_geometry_subslices(struct drm_i915_private *i915,
+ struct drm_i915_query_item *query_item)
+{
+ const struct sseu_dev_info *sseu;
+ struct intel_engine_cs *engine;
+ struct i915_engine_class_instance classinstance;
+
+ if (GRAPHICS_VER_FULL(i915) < IP_VER(12, 50))
+ return -ENODEV;
+
+ classinstance = *((struct i915_engine_class_instance
*)&quer
