[Question] cacheline sharing problem on DMA for custom outer-cache

[linux@arm.linux.org.uk (Russell King - ARM Linux)]

On Mon, Jan 18, 2016 at 09:05:15PM +0900, Masahiro Yamada wrote:
> L1_CACHE_BYTES is not a configuration.  It is a hardware property.
> 
> Actually, Tegra is the only hardware that has L1 cache with 64byte line-size.

We have a load of paltforms which select ARM_L1_CACHE_SHIFT_6, plus
Cortex-A8 and Cortex-A15 both have 64-byte L1 line size.

It's all in the git history, please research.

$ git log -p -- arch/arm/Kconfig arch/arm/mm/Kconfig

and search for "ARM_L1_CACHE_SHIFT_6".

> The other SoCs in multi_v7_defconfig run software configured for
> 64byte line-size on CPUs with 32byte line-size.  Weird.

Nothing weird here.  A kernel configured for a 64 byte cache line size
can be run on a system with a 32 byte cache line size, but not vice
versa.

> And, deciding the DMA aligment only with L1 line-size does not seem nice.
> I admit the outer-cache on my SoC is odd, though.

Currently, the L1 defines the biggest restriction on DMA cache line
alignment that we have.  However, you should be wary of changing
only the DMA cache alignment - I think you'll find a lot of things
assume that aligning to L1_CACHE_BYTES will be DMA safe.

> If we could parse "line-size" DT-property in the early stage
> and change the DMA alignment run-time, it would avoid degrading
> performance on other SoCs.

You can't realign data structures in the kernel image at runtime.

L1_CACHE_BYTES is used as a constant in several places for this
purpose.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.