On Wed, Nov 29, 2017 at 11:59:04AM +0000, Chris Wilson wrote: > Quoting Tvrtko Ursulin (2017-11-29 11:53:41) > > > > On 29/11/2017 11:40, Chris Wilson wrote: > > > Quoting Tvrtko Ursulin (2017-11-29 11:34:27) > > >> > > >> On 29/11/2017 11:12, Daniel Vetter wrote: > > >>> I think given that DMC is strongly recommended there shouldn't be a real > > >>> cost with making this unconditional. > > >> > > >> I don't know, not liking it on the first go. But then again I have no > > >> idea how much power would that waste for use cases where DMC fw is > > >> deliberately not present. > > >> > > >> Perhaps it would be acceptable to mark GT busy during the async CSR > > >> load. Chris, any thoughts? > > > > > > It's tightly coupled to requests, adding in an external call seems > > > troublesome. > > > > > > What's the reason for depending on the CSR being loaded? The old fw is > > > broke no matter what, it doesn't get any more broken by us holding a > > > powerwell wakeref. I think we should go for simplicity and always take > > > the powerwell along with the rpm? > > > > It's the unknown, maybe only for me, on how much power always holding > > the power well would waste for use cases where DMC firmware has been > > deliberately removed. > > > > If I understand correctly that the Daniel's and your proposal is to just > > got with HAS_CSR as the wa/ criteria, instead of fw loaded check. > > If I am reading the powerwell code correctly, it already takes the dmc > fw into account. I would transfer the problem to there :) i.e. we have > an unconditional call from gt:mark_busy, gt:mark_idle and the powerwell > code knows what needs to be done under the different circumstances. Yes, a power well ref for all domains is held while the firmware is being loaded, or the firmware fails to load. So taking it unconditionally is ok (not counting the platform check due to the corruption issue). > -Chris > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/intel-gfx _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
