From: Christophe LEROY <christophe.leroy@c-s.fr>
To: Scott Wood <scottwood@freescale.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>,
Michael Ellerman <mpe@ellerman.id.au>,
sojkam1@fel.cvut.cz, linux-kernel@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v3] powerpc32: memset: only use dcbz once cache is enabled
Date: Mon, 14 Sep 2015 17:44:31 +0200 [thread overview]
Message-ID: <55F6EB5F.1070203@c-s.fr> (raw)
In-Reply-To: <1442244054.2909.66.camel@freescale.com>
Le 14/09/2015 17:20, Scott Wood a écrit :
> On Mon, 2015-09-14 at 08:21 +0200, Christophe Leroy wrote:
>> memset() uses instruction dcbz to speed up clearing by not wasting time
>> loading cache line with data that will be overwritten.
>> Some platform like mpc52xx do no have cache active at startup and
>> can therefore not use memset(). Allthough no part of the code
>> explicitly uses memset(), GCC may makes calls to it.
>>
>> This patch modifies memset() such that at startup, memset()
>> unconditionally jumps to simple_memset() which doesn't use
>> the dcbz instruction.
>>
>> Once the initial MMU is set up, in machine_init() we patch memset()
>> by replacing this inconditional jump by a NOP
>>
>> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
>> ---
>> This patch goes on to of [v3] powerpc32: memcpy: only use dcbz once cache
>> is enabled
>>
>> Changes in v2:
>> was part of [v2] powerpc32: memcpy/memset: only use dcbz once cache is
>> enabled
>> changes in v3:
>> Not using anymore feature-fixups
>> Handling of memcpy() and memset() split in two patches
>>
>> arch/powerpc/kernel/setup_32.c | 1 +
>> arch/powerpc/lib/copy_32.S | 15 +++++++++++++++
>> 2 files changed, 16 insertions(+)
>>
>> diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
>> index 362495f..345ec3a 100644
>> --- a/arch/powerpc/kernel/setup_32.c
>> +++ b/arch/powerpc/kernel/setup_32.c
>> @@ -124,6 +124,7 @@ notrace void __init machine_init(u64 dt_ptr)
>> udbg_early_init();
>>
>> patch_instruction((unsigned int *)&memcpy, PPC_INST_NOP);
>> + patch_instruction((unsigned int *)&memset, PPC_INST_NOP);
>>
>> /* Do some early initialization based on the flat device tree */
>> early_init_devtree(__va(dt_ptr));
>> diff --git a/arch/powerpc/lib/copy_32.S b/arch/powerpc/lib/copy_32.S
>> index da5847d..68a59d4 100644
>> --- a/arch/powerpc/lib/copy_32.S
>> +++ b/arch/powerpc/lib/copy_32.S
>> @@ -73,8 +73,13 @@ CACHELINE_MASK = (L1_CACHE_BYTES-1)
>> * Use dcbz on the complete cache lines in the destination
>> * to set them to zero. This requires that the destination
>> * area is cacheable. -- paulus
>> + *
>> + * During early init, cache might not be active yet, so dcbz cannot be
>> used.
>> + * We therefore jump to simple_memset which doesn't use dcbz. This jump is
>> + * replaced by a nop once cache is active. This is done in machine_init()
>> */
>> _GLOBAL(memset)
>> + b simple_memset
>> rlwimi r4,r4,8,16,23
>> rlwimi r4,r4,16,0,15
>>
>> @@ -122,6 +127,16 @@ _GLOBAL(memset)
>> bdnz 8b
>> blr
>>
>> +/* Simple version of memset used during early boot until cache is enabled
>> */
>> +simple_memset:
>> + cmplwi cr0,r5,0
>> + addi r6,r3,-1
>> + beqlr
>> + mtctr r5
>> +1: stbu r4,1(r6)
>> + bdnz 1b
>> + blr
> Instead couldn't you use the generic memset at label 2: and patch the "bne
> 2f"?
Yes I could but it means adding a global symbol there at the "bne 2f". I
thought it was what Michael didn't like in my v1 of memcpy().
What name could I give to that symbol ? Something like
memcpy_nocache_patch: ?
What would be the best ? Having b 2f, and replacing it with bne 2f ? Or
have b 2f just above and replace it by nop once cache is up ?
Christophe
next prev parent reply other threads:[~2015-09-14 15:44 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-14 6:21 [PATCH v3] powerpc32: memset: only use dcbz once cache is enabled Christophe Leroy
2015-09-14 7:15 ` Michal Sojka
2015-09-14 15:20 ` Scott Wood
2015-09-14 15:44 ` Christophe LEROY [this message]
2015-09-14 16:13 ` Scott Wood
2015-09-14 23:52 ` Michael Ellerman
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=55F6EB5F.1070203@c-s.fr \
--to=christophe.leroy@c-s.fr \
--cc=benh@kernel.crashing.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=paulus@samba.org \
--cc=scottwood@freescale.com \
--cc=sojkam1@fel.cvut.cz \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.