Hi Russell,
2016-01-18 21:32 GMT+09:00 Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx>:
> 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".
Ah, I missed that.
Thanks for clarifying this.
>> 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.
OK, I understand that it is difficult to change the definition of this macro.
If I submitted something like follows, would it be accepted?
config ARM_L1_CACHE_SHIFT
int
+ default 7 if CACHE_UNIPHIER
default 6 if ARM_L1_CACHE_SHIFT_6
default 5
--
Best Regards
Masahiro Yamada
--
To unsubscribe from this list: send the line "unsubscribe dmaengine" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
