| Message ID | 20240904075417.53-1-hui.pu@gehealthcare.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v2] drm/imx/ipuv3: ipuv3-plane: Round up plane width for IPUV3_CHANNEL_MEM_DC_SYNC | expand |
On 09/04/2024, Paul Pu wrote:
> Cc: stable@vger.kernel.org # 5.15+
Why 5.15+ ?
I think it should be 6.3+ because below commit introduced in v6.3
moves ipuv3-plane.c from one directory to another, which makes
this patch not being applicable to v6.2.
commit 4b6cb2b67da8 ("drm/imx: move IPUv3 driver into separate subdirectory")
Or, it could be 6.2+ because the culprit commit 4333472f8d7b was
introduced in v6.2.
> On 09/04/2024, Paul Pu wrote: > > Cc: stable@vger.kernel.org # 5.15+ > > Why 5.15+ ? > > I think it should be 6.3+ because below commit introduced in v6.3 > moves ipuv3-plane.c from one directory to another, which makes > this patch not being applicable to v6.2. > commit 4b6cb2b67da8 ("drm/imx: move IPUv3 driver into separate > subdirectory") > > Or, it could be 6.2+ because the culprit commit 4333472f8d7b was > introduced in v6.2. Sorry, I may be not very sure about how to identify the correct version for backporting, but the commit to fix has also been cherry-picked to v5.15: a23e8376e613 v6.1: 71f9fd5bcf09 not found on v5.14. I tried also that `cherry-pick` can succeed on both v5.15 and v6.1. (I suppose 4b6cb2b67da8 has also been cherry-picked to v5.15+) Thank you. - Paul > > -- > Regards, > Liu Ying
On Wed, Sep 04, 2024 at 04:48:51PM +0800, Liu Ying wrote: > On 09/04/2024, Paul Pu wrote: > > Cc: stable@vger.kernel.org # 5.15+ > > Why 5.15+ ? Because the commit referenced in Fixes: was backported there. If you want to be picky, just drop the "# 5.15+" and our tools will rely on the Fixes: tag and everyone will be happy. thanks, greg k-h
On 09/04/2024, Greg KH wrote: > On Wed, Sep 04, 2024 at 04:48:51PM +0800, Liu Ying wrote: >> On 09/04/2024, Paul Pu wrote: >>> Cc: stable@vger.kernel.org # 5.15+ >> >> Why 5.15+ ? > > Because the commit referenced in Fixes: was backported there. Sorry, really? It doesn't seem to be backported. > > If you want to be picky, just drop the "# 5.15+" and our tools will rely > on the Fixes: tag and everyone will be happy. Great, thanks for pointing this out. With the "# 5.15+" dropped, Acked-by: Liu Ying <victor.liu@nxp.com> > > thanks, > > greg k-h
diff --git a/drivers/gpu/drm/imx/ipuv3/ipuv3-plane.c b/drivers/gpu/drm/imx/ipuv3/ipuv3-plane.c index 704c549750f9..3ef8ad7ab2a1 100644 --- a/drivers/gpu/drm/imx/ipuv3/ipuv3-plane.c +++ b/drivers/gpu/drm/imx/ipuv3/ipuv3-plane.c @@ -614,7 +614,7 @@ static void ipu_plane_atomic_update(struct drm_plane *plane, break; } - if (ipu_plane->dp_flow == IPU_DP_FLOW_SYNC_BG) + if (plane->type == DRM_PLANE_TYPE_PRIMARY) width = ipu_src_rect_width(new_state); else width = drm_rect_width(&new_state->src) >> 16;
This changes the judgement of if needing to round up the width or not, from using the `dp_flow` to the plane's type. The `dp_flow` can be -22(-EINVAL) even if the plane is a PRIMARY one. See `client_reg[]` in `ipu-common.c`. [ 0.605141] [drm:ipu_plane_init] channel 28, dp flow -22, possible_crtcs=0x0 Per the commit message in commit: 4333472f8d7b, using the plane type for judging if rounding up is needed is correct. This fixes HDMI cannot work for odd screen resolutions, e.g. 1366x768. Fixes: 4333472f8d7b ("drm/imx: ipuv3-plane: Fix overlay plane width") Cc: stable@vger.kernel.org # 5.15+ Signed-off-by: Paul Pu <hui.pu@gehealthcare.com> --- v1 -> v2: Fixed addressed review comments --- drivers/gpu/drm/imx/ipuv3/ipuv3-plane.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) base-commit: 431c1646e1f86b949fa3685efc50b660a364c2b6