[PATCH 00/19] drm/i915/tc: Fix enabled/disconnected DP-alt sink handling

[Imre Deak]

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?

> --
> Cheers,
> Luca.