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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
