On 15:40-20150103, Tomasz Figa wrote: > Hi Nishanth, > > 2015-01-03 2:43 GMT+09:00 Nishanth Menon <nm@xxxxxx>: > > AM437x generation of processors support programming the PL310 L2Cache > > controller's address filter start and end registers using a secure > > montior service. > > typo: s/montior/monitor/ > > [snip] Uggh.. yes indeed. I will post a v3 updating the comments. If the following is ok. > > > + base = omap4_get_l2cache_base(); > > + filter_start = (reg == L310_ADDR_FILTER_START) ? val : > > + readl_relaxed(base + L310_ADDR_FILTER_START); > > + filter_end = (reg == L310_ADDR_FILTER_END) ? val : > > + readl_relaxed(base + L310_ADDR_FILTER_END); > > + omap_smc1_2(AM43X_MON_L2X0_SETFILTER_INDEX, filter_start, > > + filter_end); > > + return; > > I don't have any significant comments about this patch in particular, > but just noticed that you need to do read-backs here (and the typo > thanks to the spell checker of my mailing app). Maybe you should > consider switching to the .configure() API I introduced in my series? > This would let you get rid of the hardcoded static mapping. Yeah, I have two choices there.. Either I provide the fundamental write function for the generic l2c code to use OR I provide a duplicate of resultant l2c_configure(aux write) + l2c310_configure. To allow for reuse of improvements or anything like errata implementations in the future, OMAP L2C implementation has chosen to provide the low level code and allow the higherlevel configure/write/whatever of the future to stay in arch/arm/mm/cache-l2x0.c. The write_sec operation is not too complicated enough to warrant a replication of l2c310_configure. So, I prefer the current implementation than providing a .configure handler for outer_cache.configure from SoC level. Let me know if anyone has a strong objection to this. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
