On Fri, 2018-01-05 at 10:09 -0800, Rodrigo Vivi wrote: > On Fri, Jan 05, 2018 at 11:23:54AM +0000, Maarten Lankhorst wrote: > > Op 04-01-18 om 22:51 schreef Pandiyan, Dhinakaran: > > > On Thu, 2018-01-04 at 12:35 +0100, Maarten Lankhorst wrote: > > >> Wouldn't it be better to make intel_power_domains_verify_state work > > >> correctly with the vblank irq? > > > I tried to :) Since I changed the domain_use_count to atomic_t and moved > > > it outside of the locks, verify_state became racy. Let me take another > > > look. > > > > > > -DK > > > > It sucks that we end up with 2 ways to handle power domains.. > > I also don't like that, but if we need to go with that I believe > we need to go with a generic approach. > > > > > I'm trying to think of a cleaner way, coming up with none. :( > > me neither :( > > > > > It would have been nice if we could do something like a seqlock for > > the refcounts, but that would prevent us from blocking too.. > > reader does't block and writer doesn't wait for the reader so not > sure we could use this. > > > > > Is it only the DC off power well we care about? > Yeah, that is sufficient to deal with frame counter resets. > It is the only call to any power well that comes from an spin-locked > region. So we can't sleep. > > I think we looked to the option of changing the entire pw to spin locks > instead of mutexs, but we concluded it wasn't a viable option as well. > I just can't remember why right now. Enable/disable for other power wells have wait_for_register() > > Thanks, > Rodrigo. > > > > > ~Maarten > > _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
