[PATCH 00/19] drm/i915/tc: Fix enabled/disconnected DP-alt sink handling
Luca Coelho
luca at coelho.fi
Wed Aug 6 13:16:32 UTC 2025
On Wed, 2025-08-06 at 16:12 +0300, Imre Deak wrote:
> On Wed, Aug 06, 2025 at 03:54:00PM +0300, Luca Coelho wrote:
> > On Wed, 2025-08-06 at 14:54 +0300, Imre Deak wrote:
> > > On Wed, Aug 06, 2025 at 02:44:41PM +0300, Luca Coelho wrote:
> > > > On Tue, 2025-08-05 at 10:36 +0300, Imre Deak wrote:
> > > > > This patchset fixes an issue on LNL+, where the TypeC PHY's mode/state
> > > > > is detected incorrectly during HW readout for a DP-alt sink that got
> > > > > enabled by BIOS/GOP, but later the sink got disconnected by the user
> > > > > before the driver got loaded.
> > > > >
> > > > > The issue in the driver is due to overlooking a change on LNL+ in the
> > > > > way the PHY ready flag and pin assignment is set/cleared in the PHY
> > > > > registers by the HW/FW wrt. how this works on all the earlier (ICL-MTL)
> > > > > TypeC platforms.
> > > > >
> > > > > The first 5 patches fix the issue, the rest refactor the PHY's max lane
> > > > > count and pin assignment query functions, sanitizing the code, removing
> > > > > duplications and validating the register values read out from the HW.
> > > >
> > > > If you have 5 fix patches and the rest is refactoring, wouldn't it be
> > > > better to split the series in two?
> > >
> > > The refactoring part depends on the changes in the fixes part, so I
> > > couldn't send the refactoring part separately.
> >
> > Okay, fair enough. I'd usually send the second part _after_ sending
> > the first one, of course, but you'd have to somehow mark the dependency
> > for CI and such. Is that possible with our infra?
>
> Not aware of such. (There was a way to specify an IGT patchset to test
> the kernel changes with, but that's a different thing.)
>
> I agree it's better to have a separate CI run for the fixes part and
> also merge it separately. I think the reviewing could still happen for
> the current patchset and I could resend the fixes part only for CI. Are
> you ok with that?
Of course, totally okay and I'll review them in a bit. Resending the
fixes part only, for CI, would indeed be a good idea, so we'll know if
there are any issues if they're taken without the refactoring (as what
would happen for stable or other cherry-picks).
--
Cheers,
Luca.
More information about the Intel-gfx
mailing list