On Sun, 2017-02-26 at 20:36 +0100, Noralf Trønnes wrote: > Den 26.02.2017 19.11, skrev Stefan Wahren: > > > Eric Anholt <eric@xxxxxxxxxx> hat am 26. Februar 2017 um 18:16 > > > geschrieben: > > > > > > ... > > > > > > For staging, Greg has been taking patches without platform > > > maintainer > > > ack. I think this is great -- the staging code needs *lots* of > > > work, > > > and it generally doesn't need any platform knowledge. > > > > > > As far as this patch, I don't know why we wouldn't just use > > > cache_line_size() instead of asking DT. > > > > AFAIK this isn't implemented for arm32 yet only for arm64 > > cache_line_size() is available on arm32 as well. > > Here's the logic: > > arch/arm/mm/Kconfig: > > config ARM_L1_CACHE_SHIFT_6 > bool > default y if CPU_V7 > help > Setting ARM L1 cache line size to 64 Bytes. > > config ARM_L1_CACHE_SHIFT > int > default 7 if ARM_L1_CACHE_SHIFT_7 > default 6 if ARM_L1_CACHE_SHIFT_6 > default 5 > > > arch/arm/include/asm/cache.h: > > #define L1_CACHE_SHIFT CONFIG_ARM_L1_CACHE_SHIFT > #define L1_CACHE_BYTES (1 << L1_CACHE_SHIFT) > > > include/linux/cache.h: > > #ifndef CONFIG_ARCH_HAS_CACHE_LINE_SIZE > #define cache_line_size() L1_CACHE_BYTES > #endif > > > The only reason for using a DT property is if one should build a > kernel > that can boot on both Pi1 and Pi2/3. In theory it should be possible, > but when I did the downstream "move to mainline arch code" work, I > couldn't get such a unified kernel image to work. All kinds of memory > corruption problems that seemed to be dma related. > > > Noralf. > The firmware also had a bug/feature that if the "cache-line-size" property is missing, it assuming the kernel is very old and forces a small cache line even on RPI 3 and even with arm64. So we would still need to require the property even if it wasn't used unless the firmware can be changed. I hit this the hard way when experimenting with converting vchiq to a non platform driver and it why I submitted this patch in the first place. Things will work without the property, just they will be subtly broken. _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
