Re: [PATCH 1/3] ARM: uniphier: add outer cache support
On 09/08/2015 08:09 AM, Linus Walleij wrote: > On Fri, Aug 28, 2015 at 12:24 PM, Masahiro Yamada > wrote: >> 2015-08-26 22:39 GMT+09:00 Linus Walleij : > >>> cache-unified and cache-level are *not* optional and should be required. >> >> "cache-unified" is mentioned in "3.7.3 Internal (L1) Cache Properties" >> (Table 3-8), >> but it is not in "3.8 Multi-level and Shared Caches" (Table 3-9) >> >> Are the rules in Table 3-8 also applied for L2? > > Your guess is as good as mine unless someone involved in > actually writing that spec says something :/ Maybe you'd have to be crazy to have Harvard cache for 2nd+ level. I've got no clue. Doesn't hurt to have it. > >>> (I'm just assuming this cache is unified, anything else would be baffling.) >> >> In fact, unified/harvard is configurable thru a register of this cache >> controller. > > Jesus Christ. Hardware designers either hate software folks or ensure our job security. > >> It is usually used as a unified cached, though. > > I would, too. > >> So,I am planning to use the same compatible for L2 and L3, like this: >> >> >>l2-cache@500c { >>compatible = "socionext,uniphier-cache"; >>reg = <0x500c 0x2000>, <0x503c0100 0x8>, >> <0x506c 0x400>; >>cache-unified; >>cache-level = <2>; >>next-level-cache = <>; Next level of the L2 is the L2? >>cache-size = <0x20>; >>cache-sets = <256>; >>cache-line-size = <128>; >> }; >> >>/* Not all of UniPhier SoCs have L3 cache */ >>l3-cache@500c8000 { >>compatible = "socionext,uniphier-cache"; >>reg = <0x500c8000 0x2000>, <0x503c8100 0x8>, >> <0x506c8000 0x400>; >>cache-unified; >>cache-level = <3>; >>cache-size = <0x40>; >>cache-sets = <256>; >>cache-line-size = <256>; >>}; > > This LooksGoodToMe. > >> The Table 3-9 in ePAPR v1.1 says >> the compatible should be "cache", but I do not think it makes sense here. > > Agree. It could be useful for finding all cache nodes, but we've generally failed to use it, so at this point it doesn't matter. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ARM: uniphier: add outer cache support
On Fri, Aug 28, 2015 at 12:24 PM, Masahiro Yamada wrote: > 2015-08-26 22:39 GMT+09:00 Linus Walleij : >> cache-unified and cache-level are *not* optional and should be required. > > "cache-unified" is mentioned in "3.7.3 Internal (L1) Cache Properties" > (Table 3-8), > but it is not in "3.8 Multi-level and Shared Caches" (Table 3-9) > > Are the rules in Table 3-8 also applied for L2? Your guess is as good as mine unless someone involved in actually writing that spec says something :/ >> (I'm just assuming this cache is unified, anything else would be baffling.) > > In fact, unified/harvard is configurable thru a register of this cache > controller. Jesus Christ. > It is usually used as a unified cached, though. I would, too. > So,I am planning to use the same compatible for L2 and L3, like this: > > >l2-cache@500c { >compatible = "socionext,uniphier-cache"; >reg = <0x500c 0x2000>, <0x503c0100 0x8>, > <0x506c 0x400>; >cache-unified; >cache-level = <2>; >next-level-cache = <>; >cache-size = <0x20>; >cache-sets = <256>; >cache-line-size = <128>; > }; > >/* Not all of UniPhier SoCs have L3 cache */ >l3-cache@500c8000 { >compatible = "socionext,uniphier-cache"; >reg = <0x500c8000 0x2000>, <0x503c8100 0x8>, > <0x506c8000 0x400>; >cache-unified; >cache-level = <3>; >cache-size = <0x40>; >cache-sets = <256>; >cache-line-size = <256>; >}; This LooksGoodToMe. > The Table 3-9 in ePAPR v1.1 says > the compatible should be "cache", but I do not think it makes sense here. Agree. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ARM: uniphier: add outer cache support
On Fri, Aug 28, 2015 at 12:24 PM, Masahiro Yamadawrote: > 2015-08-26 22:39 GMT+09:00 Linus Walleij : >> cache-unified and cache-level are *not* optional and should be required. > > "cache-unified" is mentioned in "3.7.3 Internal (L1) Cache Properties" > (Table 3-8), > but it is not in "3.8 Multi-level and Shared Caches" (Table 3-9) > > Are the rules in Table 3-8 also applied for L2? Your guess is as good as mine unless someone involved in actually writing that spec says something :/ >> (I'm just assuming this cache is unified, anything else would be baffling.) > > In fact, unified/harvard is configurable thru a register of this cache > controller. Jesus Christ. > It is usually used as a unified cached, though. I would, too. > So,I am planning to use the same compatible for L2 and L3, like this: > > >l2-cache@500c { >compatible = "socionext,uniphier-cache"; >reg = <0x500c 0x2000>, <0x503c0100 0x8>, > <0x506c 0x400>; >cache-unified; >cache-level = <2>; >next-level-cache = <>; >cache-size = <0x20>; >cache-sets = <256>; >cache-line-size = <128>; > }; > >/* Not all of UniPhier SoCs have L3 cache */ >l3-cache@500c8000 { >compatible = "socionext,uniphier-cache"; >reg = <0x500c8000 0x2000>, <0x503c8100 0x8>, > <0x506c8000 0x400>; >cache-unified; >cache-level = <3>; >cache-size = <0x40>; >cache-sets = <256>; >cache-line-size = <256>; >}; This LooksGoodToMe. > The Table 3-9 in ePAPR v1.1 says > the compatible should be "cache", but I do not think it makes sense here. Agree. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ARM: uniphier: add outer cache support
On 09/08/2015 08:09 AM, Linus Walleij wrote: > On Fri, Aug 28, 2015 at 12:24 PM, Masahiro Yamada >wrote: >> 2015-08-26 22:39 GMT+09:00 Linus Walleij : > >>> cache-unified and cache-level are *not* optional and should be required. >> >> "cache-unified" is mentioned in "3.7.3 Internal (L1) Cache Properties" >> (Table 3-8), >> but it is not in "3.8 Multi-level and Shared Caches" (Table 3-9) >> >> Are the rules in Table 3-8 also applied for L2? > > Your guess is as good as mine unless someone involved in > actually writing that spec says something :/ Maybe you'd have to be crazy to have Harvard cache for 2nd+ level. I've got no clue. Doesn't hurt to have it. > >>> (I'm just assuming this cache is unified, anything else would be baffling.) >> >> In fact, unified/harvard is configurable thru a register of this cache >> controller. > > Jesus Christ. Hardware designers either hate software folks or ensure our job security. > >> It is usually used as a unified cached, though. > > I would, too. > >> So,I am planning to use the same compatible for L2 and L3, like this: >> >> >>l2-cache@500c { >>compatible = "socionext,uniphier-cache"; >>reg = <0x500c 0x2000>, <0x503c0100 0x8>, >> <0x506c 0x400>; >>cache-unified; >>cache-level = <2>; >>next-level-cache = <>; Next level of the L2 is the L2? >>cache-size = <0x20>; >>cache-sets = <256>; >>cache-line-size = <128>; >> }; >> >>/* Not all of UniPhier SoCs have L3 cache */ >>l3-cache@500c8000 { >>compatible = "socionext,uniphier-cache"; >>reg = <0x500c8000 0x2000>, <0x503c8100 0x8>, >> <0x506c8000 0x400>; >>cache-unified; >>cache-level = <3>; >>cache-size = <0x40>; >>cache-sets = <256>; >>cache-line-size = <256>; >>}; > > This LooksGoodToMe. > >> The Table 3-9 in ePAPR v1.1 says >> the compatible should be "cache", but I do not think it makes sense here. > > Agree. It could be useful for finding all cache nodes, but we've generally failed to use it, so at this point it doesn't matter. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ARM: uniphier: add outer cache support
Hi Linus, 2015-08-26 22:39 GMT+09:00 Linus Walleij : > On Mon, Aug 24, 2015 at 4:18 AM, Masahiro Yamada > wrote: >> This commit adds support for UniPhier outer cache controller. >> All the UniPhier SoCs are equipped with the L2 cache, while the L3 >> cache is currently only integrated on PH1-Pro5 SoC. >> >> Signed-off-by: Masahiro Yamada > > Wow it is really a custom L2$ controller. Wow. Just wow. That's > really brave, given all the problems we've seen in l2x0. Looks like my company is crazy... ARM Ltd. people said we are the only vendor that still uses a custom outer cache. >> +UniPhier SoCs are integrated with a level 2 cache controller that resides >> +outside of the ARM cores, some of them also have a level 3 cache controller. >> + >> +Required properties: >> +- compatible: should be one of the followings: >> + "socionext,uniphier-l2-cache" (L2 cache) >> + "socionext,uniphier-l3-cache" (L3 cache) > > Refer to and use the 3.7.3 ePAPR v1.1 specification too: > https://www.power.org/wp-content/uploads/2012/06/Power_ePAPR_APPROVED_v1.1.pdf I've checked it out. Thanks, but I had some doubts. > cache-unified and cache-level are *not* optional and should be required. "cache-unified" is mentioned in "3.7.3 Internal (L1) Cache Properties" (Table 3-8), but it is not in "3.8 Multi-level and Shared Caches" (Table 3-9) Are the rules in Table 3-8 also applied for L2? > So: > >> +The L2 cache must exist to use the L3 cache; adding only an L3 cache device >> +node to the device tree causes the initialization failure of the whole outer >> +cache system. >> + >> +Example: >> + l2-cache@500c { >> + compatible = "socionext,uniphier-l2-cache"; >> + reg = <0x500c 0x2000>, <0x503c0100 0x8>, >> + <0x506c 0x400>; > > cache-unified; > cache-level = <2>; > >> + /* Not all of UniPhier SoCs have L3 cache */ >> + l3-cache@500c8000 { >> + compatible = "socionext,uniphier-l3-cache"; >> + reg = <0x500c8000 0x2000>, <0x503c8100 0x8>, >> + <0x506c8000 0x400>; > > cache-unified; > cache-level = <3>; > > (I'm just assuming this cache is unified, anything else would be baffling.) In fact, unified/harvard is configurable thru a register of this cache controller. It is usually used as a unified cached, though. > Further the ePAPR spec optionally supports specifying things like the > cache size, number of sets, block size and line size, unless this can > be hard coded. > > Yours, > Linus Walleij > Given that cache-level specifies the level and next-level-cache specifies the topology, I think "socionext,uniphier-l*-cache" gives redundant information. The L2 and L3 cache controller look the same; they have the same register maps. The differences between them are register-base, cache-size, cache-sets, line-size, which are specified by properties. So,I am planning to use the same compatible for L2 and L3, like this: l2-cache@500c { compatible = "socionext,uniphier-cache"; reg = <0x500c 0x2000>, <0x503c0100 0x8>, <0x506c 0x400>; cache-unified; cache-level = <2>; next-level-cache = <>; cache-size = <0x20>; cache-sets = <256>; cache-line-size = <128>; }; /* Not all of UniPhier SoCs have L3 cache */ l3-cache@500c8000 { compatible = "socionext,uniphier-cache"; reg = <0x500c8000 0x2000>, <0x503c8100 0x8>, <0x506c8000 0x400>; cache-unified; cache-level = <3>; cache-size = <0x40>; cache-sets = <256>; cache-line-size = <256>; }; The Table 3-9 in ePAPR v1.1 says the compatible should be "cache", but I do not think it makes sense here. -- Best Regards Masahiro Yamada -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ARM: uniphier: add outer cache support
On Wed, Aug 26, 2015 at 02:52:45PM +0200, Arnd Bergmann wrote: > On Wednesday 26 August 2015 10:38:59 Masahiro Yamada wrote: > > Moreover, outer-cache init seems to be unrelated to > > IRQ init. > > Agreed, this is also just a historic artifact, as we don't really > have a place to put cache controller initialization, and the Arnd, I'm afraid you're completely wrong there. It's not a historic artifact by any of the kind. I explicitly placed the L2 cache initialisation there based upon which callbacks into architecture code were available from init/main.c and where in the initialisation sequence I wanted the L2 cache to be initialised _for_ _everyone_. That being, before SMP is brought up, preferably before the delay loop calibration (so we don't calibrate the loop without the L2 cache, and then invalidate that calibration when we enable the cache), but sufficiently late that various services that the L2 cache code wants (like kmalloc) have been initialised. That rules out setup_arch(), leaving trap_init(), init_IRQ(), time_init() and late_time_init(). I chose init_IRQ() out of that lot because it seemed to be a sensible point to initialise it, though trap_init() looks like it could have been another good site. All L2 caches should be initialised at a similar point IMHO - not only does this give us a more consistent initialisation sequence, but it avoids issues such as the one I mention above with delay loop calibration being wrong. > A first step would be to add the tauros2 and uniphier outer cache > init to the init_IRQ() function, and then have another patch > that moves all the outercache initialization into a new place > like arch/arm/mm/outercache.c so we don't clutter up irq.c arch/arm/mm/l2c-common.c > with unrelated stuff. -- FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ARM: uniphier: add outer cache support
Hi Arnd, Russell, 2015-08-26 21:52 GMT+09:00 Arnd Bergmann : > On Wednesday 26 August 2015 10:38:59 Masahiro Yamada wrote: >> >> 2015-08-25 4:59 GMT+09:00 Arnd Bergmann : >> > On Monday 24 August 2015 11:18:10 Masahiro Yamada wrote: > >> Nothing. >> >> This outer cache is not a variant of l2x0/pl310. >> It was designed only for our SoCs from scratch. > > Ok, I see. > >> > Would it make sense to at least share the >> > common entry point at l2x0_of_init() so you don't need to call it from >> > the platform file? >> >> I do not think so. >> >> >> l2x0_of_init() checks L2X0_AUX_CTRL register, >> but the cache-uniphier does not have such register, >> so the boot code crashes. >> >> >> >> BTW, what makes l2x0_of_init() so special? >> >> Only L2x0/L310 and variants can be initialized >> directly from init_IRQ(). > > The only thing that is special about it is that almost everyone > uses it because it is often licensed together with the Cortex-A > cores from ARM. There are a few variants that are closely related > (tauros3 and aurora, both from Marvell. All other outer_cache > implementations (feroceon, xscale, tauros2) are for older > Marvell (or Intel) cores that have since been replaced with > Cortex-A cores in newer products. > >> Moreover, outer-cache init seems to be unrelated to >> IRQ init. > > Agreed, this is also just a historic artifact, as we don't really > have a place to put cache controller initialization, and the > irq init callback was already there at the time when people > added code to init their outer caches. It often does not matter > much where you call it, but doing it early speeds up the boot > time. > > It would be nice to unify the cache initialization a bit further, > apparently only a few older platforms still call the l2x0 init > manually and we can probably all convert them to the implicit > configuration in one way or another. > > As we now have three kinds of cache controllers (l2x0, tauros2 > and uniphier) that we need to support using DT, it would be nice > for generalize that init sequence a bit more. > > A first step would be to add the tauros2 and uniphier outer cache > init to the init_IRQ() function, and then have another patch > that moves all the outercache initialization into a new place > like arch/arm/mm/outercache.c so we don't clutter up irq.c > with unrelated stuff. > > Russell probably also has some ideas on this topic, in doubt > just do what he suggests. In my v1 patch, the outer cache init is called from .init_machine as some other SoCs do, but if moving my cache_init to init_IRQ() is acceptable, that would be better for faster boot. I will follow Arnd's suggestion in v2 unless Russell is opposed to it. Thanks! -- Best Regards Masahiro Yamada -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ARM: uniphier: add outer cache support
Hi Arnd, Russell, 2015-08-26 21:52 GMT+09:00 Arnd Bergmann a...@arndb.de: On Wednesday 26 August 2015 10:38:59 Masahiro Yamada wrote: 2015-08-25 4:59 GMT+09:00 Arnd Bergmann a...@arndb.de: On Monday 24 August 2015 11:18:10 Masahiro Yamada wrote: Nothing. This outer cache is not a variant of l2x0/pl310. It was designed only for our SoCs from scratch. Ok, I see. Would it make sense to at least share the common entry point at l2x0_of_init() so you don't need to call it from the platform file? I do not think so. l2x0_of_init() checks L2X0_AUX_CTRL register, but the cache-uniphier does not have such register, so the boot code crashes. BTW, what makes l2x0_of_init() so special? Only L2x0/L310 and variants can be initialized directly from init_IRQ(). The only thing that is special about it is that almost everyone uses it because it is often licensed together with the Cortex-A cores from ARM. There are a few variants that are closely related (tauros3 and aurora, both from Marvell. All other outer_cache implementations (feroceon, xscale, tauros2) are for older Marvell (or Intel) cores that have since been replaced with Cortex-A cores in newer products. Moreover, outer-cache init seems to be unrelated to IRQ init. Agreed, this is also just a historic artifact, as we don't really have a place to put cache controller initialization, and the irq init callback was already there at the time when people added code to init their outer caches. It often does not matter much where you call it, but doing it early speeds up the boot time. It would be nice to unify the cache initialization a bit further, apparently only a few older platforms still call the l2x0 init manually and we can probably all convert them to the implicit configuration in one way or another. As we now have three kinds of cache controllers (l2x0, tauros2 and uniphier) that we need to support using DT, it would be nice for generalize that init sequence a bit more. A first step would be to add the tauros2 and uniphier outer cache init to the init_IRQ() function, and then have another patch that moves all the outercache initialization into a new place like arch/arm/mm/outercache.c so we don't clutter up irq.c with unrelated stuff. Russell probably also has some ideas on this topic, in doubt just do what he suggests. In my v1 patch, the outer cache init is called from .init_machine as some other SoCs do, but if moving my cache_init to init_IRQ() is acceptable, that would be better for faster boot. I will follow Arnd's suggestion in v2 unless Russell is opposed to it. Thanks! -- Best Regards Masahiro Yamada -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ARM: uniphier: add outer cache support
On Wed, Aug 26, 2015 at 02:52:45PM +0200, Arnd Bergmann wrote: On Wednesday 26 August 2015 10:38:59 Masahiro Yamada wrote: Moreover, outer-cache init seems to be unrelated to IRQ init. Agreed, this is also just a historic artifact, as we don't really have a place to put cache controller initialization, and the Arnd, I'm afraid you're completely wrong there. It's not a historic artifact by any of the kind. I explicitly placed the L2 cache initialisation there based upon which callbacks into architecture code were available from init/main.c and where in the initialisation sequence I wanted the L2 cache to be initialised _for_ _everyone_. That being, before SMP is brought up, preferably before the delay loop calibration (so we don't calibrate the loop without the L2 cache, and then invalidate that calibration when we enable the cache), but sufficiently late that various services that the L2 cache code wants (like kmalloc) have been initialised. That rules out setup_arch(), leaving trap_init(), init_IRQ(), time_init() and late_time_init(). I chose init_IRQ() out of that lot because it seemed to be a sensible point to initialise it, though trap_init() looks like it could have been another good site. All L2 caches should be initialised at a similar point IMHO - not only does this give us a more consistent initialisation sequence, but it avoids issues such as the one I mention above with delay loop calibration being wrong. A first step would be to add the tauros2 and uniphier outer cache init to the init_IRQ() function, and then have another patch that moves all the outercache initialization into a new place like arch/arm/mm/outercache.c so we don't clutter up irq.c arch/arm/mm/l2c-common.c with unrelated stuff. -- FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ARM: uniphier: add outer cache support
Hi Linus, 2015-08-26 22:39 GMT+09:00 Linus Walleij linus.wall...@linaro.org: On Mon, Aug 24, 2015 at 4:18 AM, Masahiro Yamada yamada.masah...@socionext.com wrote: This commit adds support for UniPhier outer cache controller. All the UniPhier SoCs are equipped with the L2 cache, while the L3 cache is currently only integrated on PH1-Pro5 SoC. Signed-off-by: Masahiro Yamada yamada.masah...@socionext.com Wow it is really a custom L2$ controller. Wow. Just wow. That's really brave, given all the problems we've seen in l2x0. Looks like my company is crazy... ARM Ltd. people said we are the only vendor that still uses a custom outer cache. +UniPhier SoCs are integrated with a level 2 cache controller that resides +outside of the ARM cores, some of them also have a level 3 cache controller. + +Required properties: +- compatible: should be one of the followings: + socionext,uniphier-l2-cache (L2 cache) + socionext,uniphier-l3-cache (L3 cache) Refer to and use the 3.7.3 ePAPR v1.1 specification too: https://www.power.org/wp-content/uploads/2012/06/Power_ePAPR_APPROVED_v1.1.pdf I've checked it out. Thanks, but I had some doubts. cache-unified and cache-level are *not* optional and should be required. cache-unified is mentioned in 3.7.3 Internal (L1) Cache Properties (Table 3-8), but it is not in 3.8 Multi-level and Shared Caches (Table 3-9) Are the rules in Table 3-8 also applied for L2? So: +The L2 cache must exist to use the L3 cache; adding only an L3 cache device +node to the device tree causes the initialization failure of the whole outer +cache system. + +Example: + l2-cache@500c { + compatible = socionext,uniphier-l2-cache; + reg = 0x500c 0x2000, 0x503c0100 0x8, + 0x506c 0x400; cache-unified; cache-level = 2; + /* Not all of UniPhier SoCs have L3 cache */ + l3-cache@500c8000 { + compatible = socionext,uniphier-l3-cache; + reg = 0x500c8000 0x2000, 0x503c8100 0x8, + 0x506c8000 0x400; cache-unified; cache-level = 3; (I'm just assuming this cache is unified, anything else would be baffling.) In fact, unified/harvard is configurable thru a register of this cache controller. It is usually used as a unified cached, though. Further the ePAPR spec optionally supports specifying things like the cache size, number of sets, block size and line size, unless this can be hard coded. Yours, Linus Walleij Given that cache-level specifies the level and next-level-cache specifies the topology, I think socionext,uniphier-l*-cache gives redundant information. The L2 and L3 cache controller look the same; they have the same register maps. The differences between them are register-base, cache-size, cache-sets, line-size, which are specified by properties. So,I am planning to use the same compatible for L2 and L3, like this: l2-cache@500c { compatible = socionext,uniphier-cache; reg = 0x500c 0x2000, 0x503c0100 0x8, 0x506c 0x400; cache-unified; cache-level = 2; next-level-cache = L2; cache-size = 0x20; cache-sets = 256; cache-line-size = 128; }; /* Not all of UniPhier SoCs have L3 cache */ l3-cache@500c8000 { compatible = socionext,uniphier-cache; reg = 0x500c8000 0x2000, 0x503c8100 0x8, 0x506c8000 0x400; cache-unified; cache-level = 3; cache-size = 0x40; cache-sets = 256; cache-line-size = 256; }; The Table 3-9 in ePAPR v1.1 says the compatible should be cache, but I do not think it makes sense here. -- Best Regards Masahiro Yamada -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ARM: uniphier: add outer cache support
On Mon, Aug 24, 2015 at 4:18 AM, Masahiro Yamada wrote: > This commit adds support for UniPhier outer cache controller. > All the UniPhier SoCs are equipped with the L2 cache, while the L3 > cache is currently only integrated on PH1-Pro5 SoC. > > Signed-off-by: Masahiro Yamada Wow it is really a custom L2$ controller. Wow. Just wow. That's really brave, given all the problems we've seen in l2x0. > +UniPhier SoCs are integrated with a level 2 cache controller that resides > +outside of the ARM cores, some of them also have a level 3 cache controller. > + > +Required properties: > +- compatible: should be one of the followings: > + "socionext,uniphier-l2-cache" (L2 cache) > + "socionext,uniphier-l3-cache" (L3 cache) Refer to and use the 3.7.3 ePAPR v1.1 specification too: https://www.power.org/wp-content/uploads/2012/06/Power_ePAPR_APPROVED_v1.1.pdf cache-unified and cache-level are *not* optional and should be required. So: > +The L2 cache must exist to use the L3 cache; adding only an L3 cache device > +node to the device tree causes the initialization failure of the whole outer > +cache system. > + > +Example: > + l2-cache@500c { > + compatible = "socionext,uniphier-l2-cache"; > + reg = <0x500c 0x2000>, <0x503c0100 0x8>, > + <0x506c 0x400>; cache-unified; cache-level = <2>; > + /* Not all of UniPhier SoCs have L3 cache */ > + l3-cache@500c8000 { > + compatible = "socionext,uniphier-l3-cache"; > + reg = <0x500c8000 0x2000>, <0x503c8100 0x8>, > + <0x506c8000 0x400>; cache-unified; cache-level = <3>; (I'm just assuming this cache is unified, anything else would be baffling.) Further the ePAPR spec optionally supports specifying things like the cache size, number of sets, block size and line size, unless this can be hard coded. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ARM: uniphier: add outer cache support
On Wednesday 26 August 2015 10:38:59 Masahiro Yamada wrote: > > 2015-08-25 4:59 GMT+09:00 Arnd Bergmann : > > On Monday 24 August 2015 11:18:10 Masahiro Yamada wrote: > Nothing. > > This outer cache is not a variant of l2x0/pl310. > It was designed only for our SoCs from scratch. Ok, I see. > > Would it make sense to at least share the > > common entry point at l2x0_of_init() so you don't need to call it from > > the platform file? > > I do not think so. > > > l2x0_of_init() checks L2X0_AUX_CTRL register, > but the cache-uniphier does not have such register, > so the boot code crashes. > > > > BTW, what makes l2x0_of_init() so special? > > Only L2x0/L310 and variants can be initialized > directly from init_IRQ(). The only thing that is special about it is that almost everyone uses it because it is often licensed together with the Cortex-A cores from ARM. There are a few variants that are closely related (tauros3 and aurora, both from Marvell. All other outer_cache implementations (feroceon, xscale, tauros2) are for older Marvell (or Intel) cores that have since been replaced with Cortex-A cores in newer products. > Moreover, outer-cache init seems to be unrelated to > IRQ init. Agreed, this is also just a historic artifact, as we don't really have a place to put cache controller initialization, and the irq init callback was already there at the time when people added code to init their outer caches. It often does not matter much where you call it, but doing it early speeds up the boot time. It would be nice to unify the cache initialization a bit further, apparently only a few older platforms still call the l2x0 init manually and we can probably all convert them to the implicit configuration in one way or another. As we now have three kinds of cache controllers (l2x0, tauros2 and uniphier) that we need to support using DT, it would be nice for generalize that init sequence a bit more. A first step would be to add the tauros2 and uniphier outer cache init to the init_IRQ() function, and then have another patch that moves all the outercache initialization into a new place like arch/arm/mm/outercache.c so we don't clutter up irq.c with unrelated stuff. Russell probably also has some ideas on this topic, in doubt just do what he suggests. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ARM: uniphier: add outer cache support
On Wednesday 26 August 2015 10:38:59 Masahiro Yamada wrote: 2015-08-25 4:59 GMT+09:00 Arnd Bergmann a...@arndb.de: On Monday 24 August 2015 11:18:10 Masahiro Yamada wrote: Nothing. This outer cache is not a variant of l2x0/pl310. It was designed only for our SoCs from scratch. Ok, I see. Would it make sense to at least share the common entry point at l2x0_of_init() so you don't need to call it from the platform file? I do not think so. l2x0_of_init() checks L2X0_AUX_CTRL register, but the cache-uniphier does not have such register, so the boot code crashes. BTW, what makes l2x0_of_init() so special? Only L2x0/L310 and variants can be initialized directly from init_IRQ(). The only thing that is special about it is that almost everyone uses it because it is often licensed together with the Cortex-A cores from ARM. There are a few variants that are closely related (tauros3 and aurora, both from Marvell. All other outer_cache implementations (feroceon, xscale, tauros2) are for older Marvell (or Intel) cores that have since been replaced with Cortex-A cores in newer products. Moreover, outer-cache init seems to be unrelated to IRQ init. Agreed, this is also just a historic artifact, as we don't really have a place to put cache controller initialization, and the irq init callback was already there at the time when people added code to init their outer caches. It often does not matter much where you call it, but doing it early speeds up the boot time. It would be nice to unify the cache initialization a bit further, apparently only a few older platforms still call the l2x0 init manually and we can probably all convert them to the implicit configuration in one way or another. As we now have three kinds of cache controllers (l2x0, tauros2 and uniphier) that we need to support using DT, it would be nice for generalize that init sequence a bit more. A first step would be to add the tauros2 and uniphier outer cache init to the init_IRQ() function, and then have another patch that moves all the outercache initialization into a new place like arch/arm/mm/outercache.c so we don't clutter up irq.c with unrelated stuff. Russell probably also has some ideas on this topic, in doubt just do what he suggests. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ARM: uniphier: add outer cache support
On Mon, Aug 24, 2015 at 4:18 AM, Masahiro Yamada yamada.masah...@socionext.com wrote: This commit adds support for UniPhier outer cache controller. All the UniPhier SoCs are equipped with the L2 cache, while the L3 cache is currently only integrated on PH1-Pro5 SoC. Signed-off-by: Masahiro Yamada yamada.masah...@socionext.com Wow it is really a custom L2$ controller. Wow. Just wow. That's really brave, given all the problems we've seen in l2x0. +UniPhier SoCs are integrated with a level 2 cache controller that resides +outside of the ARM cores, some of them also have a level 3 cache controller. + +Required properties: +- compatible: should be one of the followings: + socionext,uniphier-l2-cache (L2 cache) + socionext,uniphier-l3-cache (L3 cache) Refer to and use the 3.7.3 ePAPR v1.1 specification too: https://www.power.org/wp-content/uploads/2012/06/Power_ePAPR_APPROVED_v1.1.pdf cache-unified and cache-level are *not* optional and should be required. So: +The L2 cache must exist to use the L3 cache; adding only an L3 cache device +node to the device tree causes the initialization failure of the whole outer +cache system. + +Example: + l2-cache@500c { + compatible = socionext,uniphier-l2-cache; + reg = 0x500c 0x2000, 0x503c0100 0x8, + 0x506c 0x400; cache-unified; cache-level = 2; + /* Not all of UniPhier SoCs have L3 cache */ + l3-cache@500c8000 { + compatible = socionext,uniphier-l3-cache; + reg = 0x500c8000 0x2000, 0x503c8100 0x8, + 0x506c8000 0x400; cache-unified; cache-level = 3; (I'm just assuming this cache is unified, anything else would be baffling.) Further the ePAPR spec optionally supports specifying things like the cache size, number of sets, block size and line size, unless this can be hard coded. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ARM: uniphier: add outer cache support
Hi Arnd, 2015-08-25 4:59 GMT+09:00 Arnd Bergmann : > On Monday 24 August 2015 11:18:10 Masahiro Yamada wrote: >> diff --git >> a/Documentation/devicetree/bindings/arm/uniphier/cache-uniphier.txt >> b/Documentation/devicetree/bindings/arm/uniphier/cache-uniphier.txt >> new file mode 100644 >> index 000..6428289 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/arm/uniphier/cache-uniphier.txt >> @@ -0,0 +1,30 @@ >> +UniPhier outer cache controller >> + >> +UniPhier SoCs are integrated with a level 2 cache controller that resides >> +outside of the ARM cores, some of them also have a level 3 cache controller. >> + >> +Required properties: >> +- compatible: should be one of the followings: >> + "socionext,uniphier-l2-cache" (L2 cache) >> + "socionext,uniphier-l3-cache" (L3 cache) >> +- reg: offsets and lengths of the register sets for the device. It should >> + contain 3 regions: control registers, revision registers, operation >> + registers, in this order. >> + >> +The L2 cache must exist to use the L3 cache; adding only an L3 cache device >> +node to the device tree causes the initialization failure of the whole outer >> +cache system. >> > > How much does this outer cache have in common with the l2x0/pl310 cache > controller model? Nothing. This outer cache is not a variant of l2x0/pl310. It was designed only for our SoCs from scratch. > Would it make sense to at least share the > common entry point at l2x0_of_init() so you don't need to call it from > the platform file? I do not think so. l2x0_of_init() checks L2X0_AUX_CTRL register, but the cache-uniphier does not have such register, so the boot code crashes. BTW, what makes l2x0_of_init() so special? Only L2x0/L310 and variants can be initialized directly from init_IRQ(). Moreover, outer-cache init seems to be unrelated to IRQ init. -- Best Regards Masahiro Yamada -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ARM: uniphier: add outer cache support
Hi Arnd, 2015-08-25 4:59 GMT+09:00 Arnd Bergmann a...@arndb.de: On Monday 24 August 2015 11:18:10 Masahiro Yamada wrote: diff --git a/Documentation/devicetree/bindings/arm/uniphier/cache-uniphier.txt b/Documentation/devicetree/bindings/arm/uniphier/cache-uniphier.txt new file mode 100644 index 000..6428289 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/uniphier/cache-uniphier.txt @@ -0,0 +1,30 @@ +UniPhier outer cache controller + +UniPhier SoCs are integrated with a level 2 cache controller that resides +outside of the ARM cores, some of them also have a level 3 cache controller. + +Required properties: +- compatible: should be one of the followings: + socionext,uniphier-l2-cache (L2 cache) + socionext,uniphier-l3-cache (L3 cache) +- reg: offsets and lengths of the register sets for the device. It should + contain 3 regions: control registers, revision registers, operation + registers, in this order. + +The L2 cache must exist to use the L3 cache; adding only an L3 cache device +node to the device tree causes the initialization failure of the whole outer +cache system. How much does this outer cache have in common with the l2x0/pl310 cache controller model? Nothing. This outer cache is not a variant of l2x0/pl310. It was designed only for our SoCs from scratch. Would it make sense to at least share the common entry point at l2x0_of_init() so you don't need to call it from the platform file? I do not think so. l2x0_of_init() checks L2X0_AUX_CTRL register, but the cache-uniphier does not have such register, so the boot code crashes. BTW, what makes l2x0_of_init() so special? Only L2x0/L310 and variants can be initialized directly from init_IRQ(). Moreover, outer-cache init seems to be unrelated to IRQ init. -- Best Regards Masahiro Yamada -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ARM: uniphier: add outer cache support
On Monday 24 August 2015 11:18:10 Masahiro Yamada wrote: > diff --git > a/Documentation/devicetree/bindings/arm/uniphier/cache-uniphier.txt > b/Documentation/devicetree/bindings/arm/uniphier/cache-uniphier.txt > new file mode 100644 > index 000..6428289 > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/uniphier/cache-uniphier.txt > @@ -0,0 +1,30 @@ > +UniPhier outer cache controller > + > +UniPhier SoCs are integrated with a level 2 cache controller that resides > +outside of the ARM cores, some of them also have a level 3 cache controller. > + > +Required properties: > +- compatible: should be one of the followings: > + "socionext,uniphier-l2-cache" (L2 cache) > + "socionext,uniphier-l3-cache" (L3 cache) > +- reg: offsets and lengths of the register sets for the device. It should > + contain 3 regions: control registers, revision registers, operation > + registers, in this order. > + > +The L2 cache must exist to use the L3 cache; adding only an L3 cache device > +node to the device tree causes the initialization failure of the whole outer > +cache system. > How much does this outer cache have in common with the l2x0/pl310 cache controller model? Would it make sense to at least share the common entry point at l2x0_of_init() so you don't need to call it from the platform file? Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ARM: uniphier: add outer cache support
On Monday 24 August 2015 11:18:10 Masahiro Yamada wrote: diff --git a/Documentation/devicetree/bindings/arm/uniphier/cache-uniphier.txt b/Documentation/devicetree/bindings/arm/uniphier/cache-uniphier.txt new file mode 100644 index 000..6428289 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/uniphier/cache-uniphier.txt @@ -0,0 +1,30 @@ +UniPhier outer cache controller + +UniPhier SoCs are integrated with a level 2 cache controller that resides +outside of the ARM cores, some of them also have a level 3 cache controller. + +Required properties: +- compatible: should be one of the followings: + socionext,uniphier-l2-cache (L2 cache) + socionext,uniphier-l3-cache (L3 cache) +- reg: offsets and lengths of the register sets for the device. It should + contain 3 regions: control registers, revision registers, operation + registers, in this order. + +The L2 cache must exist to use the L3 cache; adding only an L3 cache device +node to the device tree causes the initialization failure of the whole outer +cache system. How much does this outer cache have in common with the l2x0/pl310 cache controller model? Would it make sense to at least share the common entry point at l2x0_of_init() so you don't need to call it from the platform file? Arnd -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ARM: uniphier: add outer cache support
Hi Joe, 2015-08-24 11:29 GMT+09:00 Joe Perches : > On Mon, 2015-08-24 at 11:18 +0900, Masahiro Yamada wrote: >> This commit adds support for UniPhier outer cache controller. >> All the UniPhier SoCs are equipped with the L2 cache, while the L3 >> cache is currently only integrated on PH1-Pro5 SoC. > > style trivia: > > You might add and use > #define pr_fmt(fmt) "uniphier: " fmt > before any other #include so all of the pr_ > uses are automatically prefixed. I did not know that. Thanks! I will do so for the whole series in v2. -- Best Regards Masahiro Yamada -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ARM: uniphier: add outer cache support
On Mon, 2015-08-24 at 11:18 +0900, Masahiro Yamada wrote: > This commit adds support for UniPhier outer cache controller. > All the UniPhier SoCs are equipped with the L2 cache, while the L3 > cache is currently only integrated on PH1-Pro5 SoC. style trivia: You might add and use #define pr_fmt(fmt) "uniphier: " fmt before any other #include so all of the pr_ uses are automatically prefixed. > diff --git a/arch/arm/mm/cache-uniphier.c b/arch/arm/mm/cache-uniphier.c [] > +static int __init __uniphier_cache_init(void) > +{ [] > + if (uniphier_outer_levels == 0) { > + ret = ret ?: -ENODEV; > + pr_err("uniphier: failed to initialize outer cache\n"); So this becomes: pr_err("failed to initialize outer cache\n"); > +int __init uniphier_cache_init(void) > +{ [] > + pr_info("uniphier: enabled outer cache (%s)\n", > + uniphier_outer_levels >= 2 ? "L2 and L3" : "L2"); pr_info("enabled outer cache (%s)\n", uniphier_outer_levels >= 2 ? "L2 and L3" : "L2"); etc... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] ARM: uniphier: add outer cache support
This commit adds support for UniPhier outer cache controller. All the UniPhier SoCs are equipped with the L2 cache, while the L3 cache is currently only integrated on PH1-Pro5 SoC. Signed-off-by: Masahiro Yamada --- .../bindings/arm/uniphier/cache-uniphier.txt | 30 ++ MAINTAINERS| 2 + arch/arm/include/asm/hardware/cache-uniphier.h | 40 ++ arch/arm/mach-uniphier/uniphier.c | 11 + arch/arm/mm/Kconfig| 10 + arch/arm/mm/Makefile | 1 + arch/arm/mm/cache-uniphier.c | 518 + 7 files changed, 612 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/uniphier/cache-uniphier.txt create mode 100644 arch/arm/include/asm/hardware/cache-uniphier.h create mode 100644 arch/arm/mm/cache-uniphier.c diff --git a/Documentation/devicetree/bindings/arm/uniphier/cache-uniphier.txt b/Documentation/devicetree/bindings/arm/uniphier/cache-uniphier.txt new file mode 100644 index 000..6428289 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/uniphier/cache-uniphier.txt @@ -0,0 +1,30 @@ +UniPhier outer cache controller + +UniPhier SoCs are integrated with a level 2 cache controller that resides +outside of the ARM cores, some of them also have a level 3 cache controller. + +Required properties: +- compatible: should be one of the followings: + "socionext,uniphier-l2-cache" (L2 cache) + "socionext,uniphier-l3-cache" (L3 cache) +- reg: offsets and lengths of the register sets for the device. It should + contain 3 regions: control registers, revision registers, operation + registers, in this order. + +The L2 cache must exist to use the L3 cache; adding only an L3 cache device +node to the device tree causes the initialization failure of the whole outer +cache system. + +Example: + l2-cache@500c { + compatible = "socionext,uniphier-l2-cache"; + reg = <0x500c 0x2000>, <0x503c0100 0x8>, + <0x506c 0x400>; + }; + + /* Not all of UniPhier SoCs have L3 cache */ + l3-cache@500c8000 { + compatible = "socionext,uniphier-l3-cache"; + reg = <0x500c8000 0x2000>, <0x503c8100 0x8>, + <0x506c8000 0x400>; + }; diff --git a/MAINTAINERS b/MAINTAINERS index a4fbfc8..62e0784 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1578,7 +1578,9 @@ M:Masahiro Yamada L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) S: Maintained F: arch/arm/boot/dts/uniphier* +F: arch/arm/include/asm/hardware/cache-uniphier.h F: arch/arm/mach-uniphier/ +F: arch/arm/mm/cache-uniphier.c F: drivers/pinctrl/uniphier/ F: drivers/tty/serial/8250/8250_uniphier.c N: uniphier diff --git a/arch/arm/include/asm/hardware/cache-uniphier.h b/arch/arm/include/asm/hardware/cache-uniphier.h new file mode 100644 index 000..641d32f --- /dev/null +++ b/arch/arm/include/asm/hardware/cache-uniphier.h @@ -0,0 +1,40 @@ +/* + * Copyright (C) 2015 Masahiro Yamada + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#ifndef __CACHE_UNIPHIER_H +#define __CACHE_UNIPHIER_H + +#ifdef CONFIG_CACHE_UNIPHIER +int uniphier_cache_init(void); +int uniphier_cache_init_locked(void); +void uniphier_cache_touch_range(unsigned long start, unsigned long end); +#else +static inline int uniphier_cache_init(void) +{ + return -ENODEV; +} + +static inline int uniphier_cache_init_locked(void) +{ + return -ENODEV; +} + +static inline void uniphier_cache_touch_range(unsigned long start, + unsigned long end) +{ +} + +#endif + +#endif /* __CACHE_UNIPHIER_H */ diff --git a/arch/arm/mach-uniphier/uniphier.c b/arch/arm/mach-uniphier/uniphier.c index 9be10ef..6aed136 100644 --- a/arch/arm/mach-uniphier/uniphier.c +++ b/arch/arm/mach-uniphier/uniphier.c @@ -12,6 +12,8 @@ * GNU General Public License for more details. */ +#include +#include #include static const char * const uniphier_dt_compat[] __initconst = { @@ -25,6 +27,15 @@ static const char * const uniphier_dt_compat[] __initconst = { NULL, }; +static void __init uniphier_init_machine(void) +{ + if (uniphier_cache_init()) + pr_warn("outer cache was not enabled"); + + of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL); +} + DT_MACHINE_START(UNIPHIER,
Re: [PATCH 1/3] ARM: uniphier: add outer cache support
On Mon, 2015-08-24 at 11:18 +0900, Masahiro Yamada wrote: This commit adds support for UniPhier outer cache controller. All the UniPhier SoCs are equipped with the L2 cache, while the L3 cache is currently only integrated on PH1-Pro5 SoC. style trivia: You might add and use #define pr_fmt(fmt) uniphier: fmt before any other #include so all of the pr_level uses are automatically prefixed. diff --git a/arch/arm/mm/cache-uniphier.c b/arch/arm/mm/cache-uniphier.c [] +static int __init __uniphier_cache_init(void) +{ [] + if (uniphier_outer_levels == 0) { + ret = ret ?: -ENODEV; + pr_err(uniphier: failed to initialize outer cache\n); So this becomes: pr_err(failed to initialize outer cache\n); +int __init uniphier_cache_init(void) +{ [] + pr_info(uniphier: enabled outer cache (%s)\n, + uniphier_outer_levels = 2 ? L2 and L3 : L2); pr_info(enabled outer cache (%s)\n, uniphier_outer_levels = 2 ? L2 and L3 : L2); etc... -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] ARM: uniphier: add outer cache support
This commit adds support for UniPhier outer cache controller. All the UniPhier SoCs are equipped with the L2 cache, while the L3 cache is currently only integrated on PH1-Pro5 SoC. Signed-off-by: Masahiro Yamada yamada.masah...@socionext.com --- .../bindings/arm/uniphier/cache-uniphier.txt | 30 ++ MAINTAINERS| 2 + arch/arm/include/asm/hardware/cache-uniphier.h | 40 ++ arch/arm/mach-uniphier/uniphier.c | 11 + arch/arm/mm/Kconfig| 10 + arch/arm/mm/Makefile | 1 + arch/arm/mm/cache-uniphier.c | 518 + 7 files changed, 612 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/uniphier/cache-uniphier.txt create mode 100644 arch/arm/include/asm/hardware/cache-uniphier.h create mode 100644 arch/arm/mm/cache-uniphier.c diff --git a/Documentation/devicetree/bindings/arm/uniphier/cache-uniphier.txt b/Documentation/devicetree/bindings/arm/uniphier/cache-uniphier.txt new file mode 100644 index 000..6428289 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/uniphier/cache-uniphier.txt @@ -0,0 +1,30 @@ +UniPhier outer cache controller + +UniPhier SoCs are integrated with a level 2 cache controller that resides +outside of the ARM cores, some of them also have a level 3 cache controller. + +Required properties: +- compatible: should be one of the followings: + socionext,uniphier-l2-cache (L2 cache) + socionext,uniphier-l3-cache (L3 cache) +- reg: offsets and lengths of the register sets for the device. It should + contain 3 regions: control registers, revision registers, operation + registers, in this order. + +The L2 cache must exist to use the L3 cache; adding only an L3 cache device +node to the device tree causes the initialization failure of the whole outer +cache system. + +Example: + l2-cache@500c { + compatible = socionext,uniphier-l2-cache; + reg = 0x500c 0x2000, 0x503c0100 0x8, + 0x506c 0x400; + }; + + /* Not all of UniPhier SoCs have L3 cache */ + l3-cache@500c8000 { + compatible = socionext,uniphier-l3-cache; + reg = 0x500c8000 0x2000, 0x503c8100 0x8, + 0x506c8000 0x400; + }; diff --git a/MAINTAINERS b/MAINTAINERS index a4fbfc8..62e0784 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1578,7 +1578,9 @@ M:Masahiro Yamada yamada.masah...@socionext.com L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) S: Maintained F: arch/arm/boot/dts/uniphier* +F: arch/arm/include/asm/hardware/cache-uniphier.h F: arch/arm/mach-uniphier/ +F: arch/arm/mm/cache-uniphier.c F: drivers/pinctrl/uniphier/ F: drivers/tty/serial/8250/8250_uniphier.c N: uniphier diff --git a/arch/arm/include/asm/hardware/cache-uniphier.h b/arch/arm/include/asm/hardware/cache-uniphier.h new file mode 100644 index 000..641d32f --- /dev/null +++ b/arch/arm/include/asm/hardware/cache-uniphier.h @@ -0,0 +1,40 @@ +/* + * Copyright (C) 2015 Masahiro Yamada yamada.masah...@socionext.com + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#ifndef __CACHE_UNIPHIER_H +#define __CACHE_UNIPHIER_H + +#ifdef CONFIG_CACHE_UNIPHIER +int uniphier_cache_init(void); +int uniphier_cache_init_locked(void); +void uniphier_cache_touch_range(unsigned long start, unsigned long end); +#else +static inline int uniphier_cache_init(void) +{ + return -ENODEV; +} + +static inline int uniphier_cache_init_locked(void) +{ + return -ENODEV; +} + +static inline void uniphier_cache_touch_range(unsigned long start, + unsigned long end) +{ +} + +#endif + +#endif /* __CACHE_UNIPHIER_H */ diff --git a/arch/arm/mach-uniphier/uniphier.c b/arch/arm/mach-uniphier/uniphier.c index 9be10ef..6aed136 100644 --- a/arch/arm/mach-uniphier/uniphier.c +++ b/arch/arm/mach-uniphier/uniphier.c @@ -12,6 +12,8 @@ * GNU General Public License for more details. */ +#include linux/of_platform.h +#include asm/hardware/cache-uniphier.h #include asm/mach/arch.h static const char * const uniphier_dt_compat[] __initconst = { @@ -25,6 +27,15 @@ static const char * const uniphier_dt_compat[] __initconst = { NULL, }; +static void __init uniphier_init_machine(void) +{ + if (uniphier_cache_init()) + pr_warn(outer cache
Re: [PATCH 1/3] ARM: uniphier: add outer cache support
Hi Joe, 2015-08-24 11:29 GMT+09:00 Joe Perches j...@perches.com: On Mon, 2015-08-24 at 11:18 +0900, Masahiro Yamada wrote: This commit adds support for UniPhier outer cache controller. All the UniPhier SoCs are equipped with the L2 cache, while the L3 cache is currently only integrated on PH1-Pro5 SoC. style trivia: You might add and use #define pr_fmt(fmt) uniphier: fmt before any other #include so all of the pr_level uses are automatically prefixed. I did not know that. Thanks! I will do so for the whole series in v2. -- Best Regards Masahiro Yamada -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/