[PATCH 07/16] ARM: bL_platsmp.c: close the kernel entry gate before hot-unplugging a CPU

[dave.martin@linaro.org (Dave Martin)]

On Mon, Jan 14, 2013 at 06:26:04PM +0000, Russell King - ARM Linux wrote:
> On Mon, Jan 14, 2013 at 12:15:07PM -0500, Nicolas Pitre wrote:
> > The same could be said about the outer cache ops.  If a DSB is needed 
> > for their intent to be valid, then why isn't this DSB always implied by 
> > the corresponding cache op calls?
> 
> Hmm, just been thinking about this.
> 
> The L2x0 calls do contain a DSB but it's not obvious.  They hold a
> raw spinlock, and when that spinlock is dropped, we issue a dsb and
> sev instruction.
> 
> Whether the other L2 implementations do this or not I'm not sure -
> but the above is a requirement of the spinlock implementation, and
> it just happens to provide the right behaviour for L2x0.
> 
> But... we _probably_ don't want to impose that down at the L2 cache
> level of things - at least not for DMA ops, particular for the sanity
> of the scatter-list operating operations.  We really want to avoid
> doing one DSB per scatterlist entry, doing one DSB per scatterlist
> operation instead.
> 
> That does affect how the L2 cache API gets used - maybe we want to
> separate out the DMA stuff from the other users so that we can have
> dsbs in that path for non-DMA users.
> 
> Thoughts?

Perhaps the existing functions could be renamed to things like:

outer_XXX_flush_range()
outer_XXX_sync()

Where XXX is something like "batch" or "background".  Optionally these
could be declared somewhere separate to discourage non-DMA code from
using them.  Other code could still want to do batches of outer cache
operations efficiently, but I guess DMA is the main user.

Then we could provide simple non-background wrappers which also do
the appropriate CPU-side synchronisation, and provide the familiar
interface for that.

It might be less invasive to rename the new functions instead of the
old ones.  It partly depends on what proportion of existing uses
of these functions are incorrect (i.e., assume full synchronisation).

Cheers
---Dave