[Intel-gfx] [PATCH v3 1/6] drm/i915/tc/tgl: Implement TCCOLD sequences
Imre Deak
imre.deak at intel.com
Tue Mar 31 15:47:55 UTC 2020
On Mon, Mar 30, 2020 at 11:23:24PM +0300, Souza, Jose wrote:
> On Sat, 2020-03-28 at 11:57 +0200, Imre Deak wrote:
> [...]
> > > + if (ret == 0) {
> > > + if (block &&
> > > + low_val & TGL_PCODE_EXIT_TCCOLD_DATA_L_EXIT_FAILED)
> > > + ret = -EIO;
> > > + else
> > > + break;
> > > + }
> > > +
> > > + if (ret != -EAGAIN)
> > > + tries++;
> > > + } while (tries < 3);
> > > +
> > > + return ret;
> >
> > The return value isn't used and I think we can't do much about it, so
> > just make the function a void type and warn about a timeout?
>
> The return is usefull to have just one warm message between ICL and
> TGL.
Ah, in tc_cold_request(), but then we won't use the return value from
that.
> > [...]
> > ICL, I think we need a tc_cold_off power well/domain. The tc_cold_off
> > power ref would be get/put around the FIA access sequence here
> > (intel_tc_port_reset_mode()) and would be held whenever we hold an
> > AUX power ref.
>
> For TGL the tc_cold_off power well would work and would be pretty easy
> to implement but for ICL I'm not sure.
>
> For ICL, because of preemptions we need to get the aux power of the TC
> port before request PCODE to exit TC cold.
>
> So a single tc_cold_off would need to depend into all aux's?
> Even if we have one tc_cold_off per TC DDI, if we make it depend into aux
> we would get aux power enable timeouts. So we would need to enable aux
> power inside of the tc_cold_off enable function and the aux enable call
> would need to not check the HW status.
>
> Thoughts?
On ICL we wouldn't have a power domain/well for tc-cold, since the PCODE
request for it has anyway the strange timeout semantics, without the
proper block/unblock interface like TGL has.
So for ICL you'd need to get an AUX power domain ref here, and the AUX
power well enable hook would do the
enable AUX
block tc-cold
wait for AUX ACK
sequence in the AUX power well's enable hook (for legacy ports).
--Imre
More information about the Intel-gfx
mailing list