[PATCH v2 2/6] memory: ti-aemif: Export aemif_set_cs_timings()

Miquel Raynal miquel.raynal at bootlin.com
Tue Nov 12 03:17:17 PST 2024


Hi Bastien,

On 12/11/2024 at 10:13:38 +01, Bastien Curutchet <bastien.curutchet at bootlin.com> wrote:

> Hi Miquèl,
>
> On 11/11/24 8:21 PM, Miquel Raynal wrote:
>> Hello Bastien,
>> On 06/11/2024 at 09:55:03 +01, Bastien Curutchet
>> <bastien.curutchet at bootlin.com> wrote:
>> 
>>> Export the aemif_set_cs_timing() symbol so it can be used by other
>>> drivers
>>>
>>> Add a spinlock to protect the CS configuration register from concurrent
>>> accesses.
>> What concurrent accesses are you trying to protect yourself against?
>> I fail to see the use case, but TBH I haven't tried hard enough maybe.
>> 
>
> The register that handles the CS configuration belongs to the AEMIF
> component but it will also be accessed by the AEMIF 'children' with the
> aemif_set_cs_timing() function. So far, concurrent accesses shouldn't
> occur because the AEMIF configures the CS timings only once and does so
> before probing its 'children'; but I don't know how things can evolve in
> the future.

Okay, and I guess we can have more than one children, in this case
indeed we need serialization.

>> Also, what justifies the use of a spin-lock in this case?
>> 
>
> TBH, I always struggle to choose between mutexes and spin-locks. I chose
> spin-lock because it only protects one memory-mapped register so I think
> it doesn't worth going to sleep when waiting for the lock.

In general, I believe in a path that is not a hot-path and if you can
sleep, you should go for a mutex.

Cheers,
Miquèl



More information about the linux-mtd mailing list