On Tue, 28 Jan 2020 17:50:03 +0100 Giulio Benetti <giulio.bene...@benettiengineering.com> wrote:
> On 1/28/20 9:10 AM, Lukasz Majewski wrote: > > Hi Giulio, > > > >> Since some driver > > > > I would prefer more verbose commit message. Please share which > > driver requires this change. > > Yes, you were right, this is a quite dumb commit log. > > Now commit log can't be changed, anyway this is the list of drivers > that use it: > drivers/video/mvebu_lcd.c > drivers/video/mxsfb.c (that I'm going to use soon) > drivers/video/bcm2835.c > drivers/video/fsl_dcu_fb.c > drivers/video/tegra.c > drivers/video/imx/mxc_ipuv3_fb.c > > drivers/net/zynq_gem.c > drivers/net/mvneta.c > drivers/net/mvpp2.c > > And this function prototype is provided by > arch/arm/include/asm/system.h > > Everything came out when I've tried to build mxsfb.c. > > But after this e-mail I've dug deeper and see that sometimes > mmu_set_region_dcache_behaviour() call is guarded by > CONFIG_IS_ENABLED(SYS_DCACHE_OFF) and sometimes i.e. > arch/arm/cpu/armv8/cache_v8.c that function is defined both > implemented and empty according to CONFIG_IS_ENABLED(SYS_DCACHE_OFF). > So one chance is to put a check to guard against > CONFIG_IS_ENABLED(SYS_DCACHE_OFF) on every call(the files listed > above), otherwise, where is guarded we should remove the guard and > adding missing mmu_set_region_dcache_behaviour() empty > implementation. ~5 files to touch, but if you say it's worth, I can > do patches for that, and I don't see any drawbacks expect having a > standard way on dealing with the cache function. > > What about that? IMHO, it would be best to to this change when you decide to add support for DCACHE/ICACHE on this SoC. > > Kind regards Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de
pgpYABEy19QBS.pgp
Description: OpenPGP digital signature
