[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <018ef330788ac4d5f3cc6a9b9b98578eefabbbb9.camel@collabora.com>
Date: Mon, 17 Nov 2025 08:45:27 -0500
From: Nicolas Dufresne <nicolas.dufresne@...labora.com>
To: "jackson.lee" <jackson.lee@...psnmedia.com>, "mchehab@...nel.org"
<mchehab@...nel.org>, "hverkuil-cisco@...all.nl"
<hverkuil-cisco@...all.nl>, "bob.beckett@...labora.com"
<bob.beckett@...labora.com>
Cc: "linux-media@...r.kernel.org" <linux-media@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"lafley.kim" <lafley.kim@...psnmedia.com>, "b-brnich@...com"
<b-brnich@...com>, "hverkuil@...all.nl" <hverkuil@...all.nl>, Nas Chung
<nas.chung@...psnmedia.com>
Subject: Re: [PATCH v6 4/4] media: chips-media: wave5: Improve performance
of decoder
Hi,
Le lundi 17 novembre 2025 à 02:07 +0000, jackson.lee a écrit :
> > > } else {
> > > + spin_lock_irqsave(&inst->state_spinlock, flags);
> >
> > Move the locking inside the set_state function.
> >
> > cheers,
> > Nicolas
>
> I think the locking should not be move into the set_state
> function(switch_state).
> Because the send_eos_event, handle_dynamic_resolution_change and
> flag_last_buffer_done already have the lockdep_assert_held(&inst-
> >state_spinlock); inside those function,
> So to concisify the above code, even if the locking is moved into
> switch_statue, the locking should be called again outside.
My suggestion is to try and reduce code redundancy, another method commonly used
is to have a small version of the function that takes the locking, this you can
turn 3 lines into one in many places.
Nicolas
Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)
Powered by blists - more mailing lists