[PATCH 2/4] drm/i915: Break intel_dbuf_mbus_update into 2

Gustavo Sousa gustavo.sousa at intel.com
Mon Mar 25 13:40:08 UTC 2024


Hey, guys.

Sorry, I wasn't subscribed to this list and didn't get this thread in
my inbox.

Now I just subscribed, but couldn't find a way to ask the list system to
send this thread to me, so I'm kind of crafting this message by hand and
hoping that I have set the correct In-Reply-To header.

>> > And one thing that should be fixed at least are the
>> > redundant intel_atomic_lock_global_state() calls in 
>> > intel_cdclk_state_set_joined_mbus() and
>> > intel_dbuf_state_set_mdclk_cdclk_ratio().
>> 
>> Why are they redundant?
>> I think we should involve Gustavo here probably, since
>> that was his recent changes.
>
>Locking is needed when the state changes. Those things don't check
>if anything changed.

Yeah... When I implemented those functions, I had the mindset that those
functions would only be called when the related state values did change.
In their current call sites, I did add checks so that they were only
called when the state indeed changed (or at least thought to have done
correctly).

Looking back now, yeah... Maybe it would be safer to have the check
inside the functions themselves?

--
Gustavo Sousa


More information about the Intel-gfx-trybot mailing list