From: Tomasz Figa <t.figa@samsung.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: linux-samsung-soc@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org,
Kukjin Kim <kgene.kim@samsung.com>,
Laura Abbott <lauraa@codeaurora.org>,
Linus Walleij <linus.walleij@linaro.org>,
Santosh Shilimkar <santosh.shilimkar@ti.com>,
Tony Lindgren <tony@atomide.com>,
Tomasz Figa <tomasz.figa@gmail.com>,
Daniel Drake <drake@endlessm.com>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Arnd Bergmann <arnd@arndb.de>, Olof Johansson <olof@lixom.net>
Subject: Re: [PATCH v2 0/6] Enable L2 cache support on Exynos4210/4x12 SoCs
Date: Wed, 25 Jun 2014 17:46:43 +0200 [thread overview]
Message-ID: <53AAEEE3.1000004@samsung.com> (raw)
In-Reply-To: <20140625143728.GN3705@n2100.arm.linux.org.uk>
On 25.06.2014 16:37, Russell King - ARM Linux wrote:
> On Wed, Jun 25, 2014 at 04:13:16PM +0200, Tomasz Figa wrote:
>> On 25.06.2014 15:50, Russell King - ARM Linux wrote:
>>> On Wed, Jun 25, 2014 at 03:37:25PM +0200, Tomasz Figa wrote:
>>>> This series intends to add support for L2 cache on Exynos4 SoCs on boards
>>>> running under secure firmware, which requires certain initialization steps
>>>> to be done with help of firmware, as selected registers are writable only
>>>> from secure mode.
>>>
>>> What I said in my message on June 12th applies to this series. I'm
>>> not having the virtual address exposed via the write_sec call.
>>>
>>> Yes, you need to read other registers in order to use your secure
>>> firmware implementation. Let's fix that by providing a better write_sec
>>> interface so you don't have to read back these registers, rather than
>>> working around this short-coming.
>>
>> Do you have anything in particular in mind? I would be glad to implement
>> it and send patches.
>
> As I've already said, you are not the only ones who need fuller information
> to make your secure monitor calls. So, what that implies is that rather
> than the interface being "please write register X with value V", and then
> having platforms work-around that by reading various registers, we need
> a more flexible interface which passes the desired state.
>
So it's still not clear to me how this should be done correctly.
One thing that comes to my mind is precomputing register values to some
kind of structure, then calling some kind of magical platform-specific
.enable() or .configure() callback, which takes the structure and, in
one shot, configures the L2C according to firmware requirements. Then
the generic code would read back those values to verify the final
configuration (as it does right now) and rest of the operation would be
identical.
Is this something you would deem acceptable?
Best regards,
Tomasz
prev parent reply other threads:[~2014-06-25 15:47 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-25 13:37 [PATCH v2 0/6] Enable L2 cache support on Exynos4210/4x12 SoCs Tomasz Figa
2014-06-25 13:37 ` [PATCH v2 1/6] ARM: mm: cache-l2x0: Add base address argument to write_sec callback Tomasz Figa
2014-06-27 7:44 ` Linus Walleij
2014-06-25 13:37 ` [PATCH v2 2/6] ARM: Get outer cache .write_sec callback from mach_desc only if not NULL Tomasz Figa
2014-06-25 13:37 ` [PATCH v2 3/6] ARM: mm: cache-l2x0: Use l2c_write_sec() for LATENCY_CTRL registers Tomasz Figa
2014-06-25 13:37 ` [PATCH v2 4/6] ARM: mm: l2x0: Add support for overriding prefetch settings Tomasz Figa
2014-06-25 13:37 ` [PATCH v2 5/6] ARM: EXYNOS: Add .write_sec outer cache callback for L2C-310 Tomasz Figa
2014-06-25 13:37 ` [PATCH v2 6/6] ARM: dts: exynos4: Add nodes for L2 cache controller Tomasz Figa
2014-06-25 13:50 ` [PATCH v2 0/6] Enable L2 cache support on Exynos4210/4x12 SoCs Russell King - ARM Linux
2014-06-25 14:13 ` Tomasz Figa
2014-06-25 14:37 ` Russell King - ARM Linux
2014-06-25 15:46 ` Tomasz Figa [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53AAEEE3.1000004@samsung.com \
--to=t.figa@samsung.com \
--cc=arnd@arndb.de \
--cc=drake@endlessm.com \
--cc=kgene.kim@samsung.com \
--cc=lauraa@codeaurora.org \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=m.szyprowski@samsung.com \
--cc=olof@lixom.net \
--cc=santosh.shilimkar@ti.com \
--cc=tomasz.figa@gmail.com \
--cc=tony@atomide.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).