Re: [PATCH v4 07/11] drm/i915/xe3p_lpd: Extend Type-C flow for static DDI allocation

[Imre Deak <imre.deak@intel.com>]

On Mon, Nov 17, 2025 at 12:02:37PM -0300, Gustavo Sousa wrote:
> [...]
> >> > >> +        if (iom_dp_resource_lock(tc))
> >> > >> +                return false;
> >> > >> +
> >> > >> +        val = intel_de_read(display, IOM_DP_RESOURCE_MNG);
> >> > >> +
> >> > >> +        consumer = val & IOM_DDI_CONSUMER_MASK(tc_port);
> >> > >> +        consumer >>= IOM_DDI_CONSUMER_SHIFT(tc_port);
> >> > >> +
> >> > >> +        /*
> >> > >> +         * Bspec instructs to select first available DDI, but our driver is not
> >> > >> +         * ready for such dynamic allocation yet. For now, we force a "static"
> >> > >> +         * allocation: map the physical port (where HPD happens) to the
> >> > >> +         * encoder's DDI (logical TC port, represented by tc_port).
> >> > >> +         */
> >> > >> +        expected_consumer = IOM_DDI_CONSUMER_STATIC_TC(tc_port);
> >> > >> +        expected_consumer >>= IOM_DDI_CONSUMER_SHIFT(tc_port);
> >> 
> >> One more thing occured to me: why can't this allocate any free DDI? IOW
> >> does the address of DDI_BUF_CTL (aka DDI_CTL_DE) used for tc_port depend
> >> on which DDI gets allocated (or is there any other dependency on which
> >> DDI got allocated)? AFAICS there is no such dependency and the above
> >> address would be DDI_BUF_CTL(encoder->port) regardless of the allocated
> >> DDI. In that case any free DDI could be allocated here.
> >
> >Ok, checking this again, DDI_BUF_CTL etc. DDI register addresses will
> >depend on the allocated DDI. So nvm the above, the mapping needs to
> >stay 1:1 for now until all the DDI reg accesses are converted to index
> >the registers with the allocated DDI index.
> 
> As far as I understand this, especially after talking with Windows
> folks, the allocated DDI will define the port index for the whole
> programming, including the registers used to program the PHY - and the
> hardware would take care of routing to the correct PHY.

Correct, that's how I also understood it after "checking this again".

> Thus, it appears we would need to do the allocation at hotplug time,
> like saying "this PHY will be driven by DDI x".

To clarify, if the mapping is 1:1, as in this patch, the allocation can
be done statically during driver loading as discussed earlier. This is
the only way it will work atm, because the DDI allocation cannot fail
during runtime.

> One of the reasons I think we can't allocate a free DDI at the moment is
> that the driver is expecting a 1:1 static mapping for HPD interations.
> We will neeed to make the driver aware of the mapping in order to use
> the correct encoder when handling HPD events.

Again clarifying, that the above is true only for legacy connectors. IOW
for a TBT/DP-alt connector, where IOM does the DDI allocation, the HPD
IRQ delivered to the driver will be already according to the allocated
DDI. That is those connectors are _different_ wrt. to the mapping
requirement than the dynamic legacy connectors, for those TBT/DP-alt
connectors the DDI registers will be accessed based on the
tc_port/encoder->port to which the HPD IRQ is delivered.

> --
> Gustavo Sousa