From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752074AbbACPf2 (ORCPT ); Sat, 3 Jan 2015 10:35:28 -0500 Received: from bear.ext.ti.com ([192.94.94.41]:41929 "EHLO bear.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751018AbbACPf0 (ORCPT ); Sat, 3 Jan 2015 10:35:26 -0500 Date: Sat, 3 Jan 2015 09:34:46 -0600 From: Nishanth Menon To: Tomasz Figa CC: Tony Lindgren , Russell King , linux-omap , linux-kernel , linux-arm-kernel , Marek Szyprowski , Santosh , Sekhar Nori Subject: Re: [PATCH V2 2/2] ARM: l2c: AM437x: Introduce support for cache filter programming Message-ID: <20150103153446.GA23591@kahuna> References: <1420220628-23742-1-git-send-email-nm@ti.com> <1420220628-23742-3-git-send-email-nm@ti.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 15:40-20150103, Tomasz Figa wrote: > Hi Nishanth, > > 2015-01-03 2:43 GMT+09:00 Nishanth Menon : > > 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