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 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: 71f9fd5bcf09, using the plane type for judging if rounding up is needed is correct.
Fixes: 71f9fd5bcf09 ("drm/imx: ipuv3-plane: Fix overlay plane width") Cc: stable@vger.kernel.org
Signed-off-by: Paul Pu hui.pu@gehealthcare.com --- drivers/gpu/drm/imx/ipuv3/ipuv3-plane.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/imx/ipuv3/ipuv3-plane.c b/drivers/gpu/drm/imx/ipuv3/ipuv3-plane.c index 704c549750f9..cee83ac70ada 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 (ipu_plane->base.type == DRM_PLANE_TYPE_PRIMARY) width = ipu_src_rect_width(new_state); else width = drm_rect_width(&new_state->src) >> 16;
base-commit: 431c1646e1f86b949fa3685efc50b660a364c2b6
Hi Paul,
Thanks for your patch.
On 09/04/2024, Paul Pu wrote:
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 the plane is a PRIMARY one.
s/even/even if/
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: 71f9fd5bcf09, using the plane type for
Commit 71f9fd5bcf09 is a commit that only exists in downstream kernel.
judging if rounding up is needed is correct.
Fixes: 71f9fd5bcf09 ("drm/imx: ipuv3-plane: Fix overlay plane width")
Commit 4333472f8d7b is the one to fix in upstream kernel.
s/71f9fd5bcf09/4333472f8d7b/
Cc: stable@vger.kernel.org
Better to mark the versions for backporting the fix. Cc: stable@vger.kernel.org # 6.3+
No blank line between tags.
Signed-off-by: Paul Pu hui.pu@gehealthcare.com
drivers/gpu/drm/imx/ipuv3/ipuv3-plane.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Maybe, the patch subject can be something like: drm/imx/ipuv3: ipuv3-plane: Round up plane width for IPUV3_CHANNEL_MEM_DC_SYNC
You may find example patch subject prefixes by looking at previous commits which touch the same file, like commit 71e3657cb126 ("drm/imx/ipuv3: ipuv3-plane: reuse local variable height in atomic_update")
You may specify those fixed odd screen resolutions of your "HDMI" case in commit message.
diff --git a/drivers/gpu/drm/imx/ipuv3/ipuv3-plane.c b/drivers/gpu/drm/imx/ipuv3/ipuv3-plane.c index 704c549750f9..cee83ac70ada 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 (ipu_plane->base.type == DRM_PLANE_TYPE_PRIMARY)
plane->type is more readable.
width = ipu_src_rect_width(new_state);else width = drm_rect_width(&new_state->src) >> 16;
base-commit: 431c1646e1f86b949fa3685efc50b660a364c2b6
Hi Liu Ying,
Thank you very much for guiding me with so detailed comments.
V2 is coming.
Hi Paul,
Thanks for your patch.
On 09/04/2024, Paul Pu wrote:
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 the plane is a PRIMARY one.
s/even/even if/
Yep, looks better.
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: 71f9fd5bcf09, using the plane type for
Commit 71f9fd5bcf09 is a commit that only exists in downstream kernel.
judging if rounding up is needed is correct.
Fixes: 71f9fd5bcf09 ("drm/imx: ipuv3-plane: Fix overlay plane width")
Commit 4333472f8d7b is the one to fix in upstream kernel.
s/71f9fd5bcf09/4333472f8d7b/
OK, thanks for finding the commit for me.
Cc: stable@vger.kernel.org
Better to mark the versions for backporting the fix. Cc: stable@vger.kernel.org # 6.3+
Ah, yes, I see.
No blank line between tags.
OK.
Signed-off-by: Paul Pu hui.pu@gehealthcare.com
drivers/gpu/drm/imx/ipuv3/ipuv3-plane.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Maybe, the patch subject can be something like: drm/imx/ipuv3: ipuv3-plane: Round up plane width for IPUV3_CHANNEL_MEM_DC_SYNC
You may find example patch subject prefixes by looking at previous commits which touch the same file, like commit 71e3657cb126 ("drm/imx/ipuv3: ipuv3-plane: reuse local variable height in atomic_update")
You may specify those fixed odd screen resolutions of your "HDMI" case in commit message.
Looks explaining better. Will do.
diff --git a/drivers/gpu/drm/imx/ipuv3/ipuv3-plane.c
b/drivers/gpu/drm/imx/ipuv3/ipuv3-plane.c
index 704c549750f9..cee83ac70ada 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 (ipu_plane->base.type == DRM_PLANE_TYPE_PRIMARY)plane->type is more readable.
Nice catch.
width = ipu_src_rect_width(new_state); else width = drm_rect_width(&new_state->src) >> 16;base-commit: 431c1646e1f86b949fa3685efc50b660a364c2b6
-- Regards, Liu Ying
On Wed, Sep 04, 2024 at 05:43:15AM +0300, Paul Pu wrote:
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 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: 71f9fd5bcf09, using the plane type for judging if rounding up is needed is correct.
Fixes: 71f9fd5bcf09 ("drm/imx: ipuv3-plane: Fix overlay plane width")
That id is not in Linus's tree :(
Cc: stable@vger.kernel.org
Signed-off-by: Paul Pu hui.pu@gehealthcare.com
No need for the blank line before this.
thanks,
greg k-h
On Wed, Sep 04, 2024 at 05:43:15AM +0300, Paul Pu wrote:
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 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: 71f9fd5bcf09, using the plane type for judging if rounding up is needed is correct.
Fixes: 71f9fd5bcf09 ("drm/imx: ipuv3-plane: Fix overlay plane width")
That id is not in Linus's tree :(
Thank you, I got it.
Cc: stable@vger.kernel.org
Signed-off-by: Paul Pu hui.pu@gehealthcare.com
No need for the blank line before this.
OK.
thanks,
greg k-h
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(-)
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;
base-commit: 431c1646e1f86b949fa3685efc50b660a364c2b6
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(-)
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;
base-commit: 431c1646e1f86b949fa3685efc50b660a364c2b6
On Mi, 2024-09-04 at 10:54 +0300, Paul Pu wrote:
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(-)
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;
base-commit: 431c1646e1f86b949fa3685efc50b660a364c2b6
Thank you,
Reviewed-by: Philipp Zabel p.zabel@pengutronix.de
regards Philipp
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
linux-stable-mirror@lists.linaro.org
-
Greg KH -
Liu Ying -
Paul Pu -
Philipp Zabel -
Pu, Hui