[Intel-xe] [Intel-gfx] [PATCH v3 1/6] drm/i915: Initialize dkl_phy spin lock from display code path

[Lucas De Marchi]

On Tue, Apr 11, 2023 at 10:51:04AM -0400, Rodrigo Vivi wrote:
>On Tue, Apr 11, 2023 at 12:14:36PM +0300, Jani Nikula wrote:
>> On Tue, 11 Apr 2023, Ville Syrjälä <ville.syrjala at linux.intel.com> wrote:
>> > On Tue, Apr 11, 2023 at 11:51:33AM +0300, Jani Nikula wrote:
>> >> On Tue, 11 Apr 2023, Ville Syrjälä <ville.syrjala at linux.intel.com> wrote:
>> >> > On Mon, Apr 10, 2023 at 11:32:14AM -0700, José Roberto de Souza wrote:
>> >> >> Start to move the initialization of some lock from
>> >> >> i915_driver_early_probe().
>> >> >> No dkl function is called prior to intel_setup_outputs(), so this is
>> >> >> a good place to initialize it.
>> >> >
>> >> > I disagree. We don't want to sprinke these all over the place.
>> >>
>> >> I'm thinking if only foo.c uses a lock, foo.c should initialize it, not
>> >> someone else.
>> >
>> > Perhaps. But I think there should be some consistent place in the higher
>> > level code where all such things get called instead of dropping each one
>> > individually into some random spot in the overlall display init flow.
>>
>> Agreed.
>
>Ops, I just saw this now, right after I cc'ed you in the other thread.
>
>So, probably good to hold this and do the entire refactor together of all
>those locks initialization so we find this common consistent place apparently...

"internal" sw initialization of display-related stuff. It doesn't belong in
i915_driver_early_probe(), it makes harder to follow the sequence if we sprinkle
them around, like here in intel_setup_outputs.

But I don't see why this couldn't be done in a higher level "sw
initialization of display-related stuff".  Should we add an equivalent
of i915_driver_early_probe(), e.g.  intel_display_early_probe()[1],  and
move the display-related things from i915_driver_early_probe()?

In that case, from xe we would call this function rather than
initializing these fields in xe_display_create()

Lucas De Marchi

[1] I don't like the name, but it follows what is already there

>
>>
>> --
>> Jani Nikula, Intel Open Source Graphics Center