On 03/19/2015 10:42 AM, Daniel Vetter wrote: > On Wed, Mar 18, 2015 at 11:41:48AM -0700, Jesse Barnes wrote: >> This updates my old patch for this, but w/o fixing the locking issue >> Ville mentioned. In looking at it, it seems like the sync point should >> be at a higher level, maybe at the level of the atomic mode setting async >> serialization points? Another possibility would be to make it a lazy >> init type function, sprinkled about but only running once when we first >> need it. >> >> Any thoughts from anyone? I don't think I can just do a lock drop here, >> since other threads may jump in and mess with underlying state. That >> shouldn't affect the eDP state we fill out, but may affect the state the >> caller depended on in the first place... > > Imo the real issue is that we register a connector and then throw it away > again. Not that big a problem any more since mst dp happened meanwhile but > still might result in confusion. > > I think we should try to at least get the "is this an edp or not" question > right, and only postpone the other init steps. So maybe start with making > that edp failed to init issue really loud and then rip it out? > > Postponing all the other init work would be comparitively a lot easier I > think. I didn't view that as a big issue, but it should be easy to solve. I think the synchronization problems are still just as thorny though, even with the question of is_edp() solved early. The eDP init is kind of like a boot time mode set, but one that needs to complete before any activity on the port. I'll check those init paths; hopefully answering is_edp() won't have a bunch of delay in itself. Jesse _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
