Re: [PATCH 6.6.y] drm/i915/dsi: Use TRANS_DDI_FUNC_CTL's own port width macro

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Tue, Feb 25, 2025 at 11:13:59AM -0500, Sasha Levin wrote:
> [ Sasha's backport helper bot ]
> 
> Hi,
> 
> Summary of potential issues:
> ⚠️ Provided upstream commit SHA1 does not match found commit
> 
> The claimed upstream commit SHA1 (76120b3a304aec28fef4910204b81a12db8974da) was not found.
> However, I found a matching commit: 879f70382ff3e92fc854589ada3453e3f5f5b601

thanks for the report. The original commit is 76120b3a304a (see [1]),
but indeed it's not upstream yet, as it was merged to the drm-intel-next
branch which will be only part of a later drm pull request.

Since the change is a fix it was also cherry-picked to drm-intel-fixes
as 879f70382ff3 and merged upstream via an earlier drm-fixes pull
request.

The same happened in two other backports I sent (see [2] and [3]).

> Note: The patch differs from the upstream commit:

The patches differ from the upstream ones, as they had to be rebased due
to upstream changes that are not in the stable trees.

Is it ok if I resend this and [2], [3], with the commit ... upstream
lines changed to the SHA1 actually upstream (166ce267ae3f for [2] and
879f70382ff3 for this and [3])?

Thanks,
Imre

[1] https://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-next&id=76120b3a304aec28fef4910204b81a12db8974da
[2] https://lore.kernel.org/stable/20250225091539-d02fffb8792ca6dd@xxxxxxxxxxxxxxxxx
[3] https://lore.kernel.org/stable/20250225092150-aa652f5ea80fe710@xxxxxxxxxxxxxxxxx

> ---
> 1:  879f70382ff3e ! 1:  b3874f246c67b drm/i915/dsi: Use TRANS_DDI_FUNC_CTL's own port width macro
>     @@ Metadata
>       ## Commit message ##
>          drm/i915/dsi: Use TRANS_DDI_FUNC_CTL's own port width macro
>      
>     +    commit 76120b3a304aec28fef4910204b81a12db8974da upstream.
>     +
>          The format of the port width field in the DDI_BUF_CTL and the
>          TRANS_DDI_FUNC_CTL registers are different starting with MTL, where the
>          x3 lane mode for HDMI FRL has a different encoding in the two registers.
>     @@ Commit message
>          Link: https://patchwork.freedesktop.org/patch/msgid/20250214142001.552916-2-imre.deak@xxxxxxxxx
>          (cherry picked from commit 76120b3a304aec28fef4910204b81a12db8974da)
>          Signed-off-by: Rodrigo Vivi <rodrigo.vivi@xxxxxxxxx>
>     +    (cherry picked from commit 879f70382ff3e92fc854589ada3453e3f5f5b601)
>     +    [Imre: Rebased on v6.6.y, due to upstream API changes for intel_de_read(),
>     +     TRANS_DDI_FUNC_CTL()]
>     +    Signed-off-by: Imre Deak <imre.deak@xxxxxxxxx>
>      
>       ## drivers/gpu/drm/i915/display/icl_dsi.c ##
>      @@ drivers/gpu/drm/i915/display/icl_dsi.c: gen11_dsi_configure_transcoder(struct intel_encoder *encoder,
>     + 
>       		/* select data lane width */
>     - 		tmp = intel_de_read(display,
>     - 				    TRANS_DDI_FUNC_CTL(display, dsi_trans));
>     + 		tmp = intel_de_read(dev_priv, TRANS_DDI_FUNC_CTL(dsi_trans));
>      -		tmp &= ~DDI_PORT_WIDTH_MASK;
>      -		tmp |= DDI_PORT_WIDTH(intel_dsi->lane_count);
>      +		tmp &= ~TRANS_DDI_PORT_WIDTH_MASK;
> ---
> 
> Results of testing on various branches:
> 
> | Branch                    | Patch Apply | Build Test |
> |---------------------------|-------------|------------|
> | stable/linux-6.6.y        |  Success    |  Success   |





[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux