All of lore.kernel.org
 help / color / mirror / Atom feed
From: laurentiu.tudor@nxp.com (Laurentiu Tudor)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 6/7] staging: fsl-mc: rewrite mc command send/receive to work on 32-bits
Date: Mon, 17 Jul 2017 14:27:57 +0000	[thread overview]
Message-ID: <596CC912.3020709@nxp.com> (raw)
In-Reply-To: <CAK8P3a3KDh=MgfjG+sKNqcrQwq1yf-DgQN0=HigPaPYYJq0Uug@mail.gmail.com>

Hi Arnd,

On 07/17/2017 04:45 PM, Arnd Bergmann wrote:
> On Mon, Jul 17, 2017 at 3:26 PM,  <laurentiu.tudor@nxp.com> wrote:
>> From: Laurentiu Tudor <laurentiu.tudor@nxp.com>
>>
>> Split the 64-bit accesses in 32-bit accesses because there's no real
>> constrain in MC to do only atomic 64-bit. There's only one place
>> where ordering is important: when writing the MC command header the
>> first 32-bit part of the header must be written last.
>> We do this switch in order to allow compiling the driver on 32-bit.
>>
>> Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
>> ---
>>   drivers/staging/fsl-mc/bus/mc-sys.c | 31 ++++++++++++-------------------
>>   1 file changed, 12 insertions(+), 19 deletions(-)
>>
>> diff --git a/drivers/staging/fsl-mc/bus/mc-sys.c b/drivers/staging/fsl-mc/bus/mc-sys.c
>> index 195d9f3..dd2828e 100644
>> --- a/drivers/staging/fsl-mc/bus/mc-sys.c
>> +++ b/drivers/staging/fsl-mc/bus/mc-sys.c
>> @@ -124,14 +124,15 @@ static inline void mc_write_command(struct mc_command __iomem *portal,
>>   {
>>          int i;
>>
>> -       /* copy command parameters into the portal */
>> -       for (i = 0; i < MC_CMD_NUM_OF_PARAMS; i++)
>> -               __raw_writeq(cmd->params[i], &portal->params[i]);
>> -       /* ensure command params are committed before submitting it */
>> -       wmb();
>> -
>> -       /* submit the command by writing the header */
>> -       __raw_writeq(cmd->header, &portal->header);
>> +       /*
>> +        * copy command parameters into the portal. Final write
>> +        * triggers the submission of the command.
>> +        */
>> +       for (i = sizeof(struct mc_command) / sizeof(u32) - 1; i >= 0; i--) {
>> +               __raw_writel(((u32 *)cmd)[i], &((u32 *)portal)[i]);
>> +               /* ensure command params are committed before submitting it */
>> +               wmb();
>> +       }
>>   }
>
> What is the byte order requirement on this buffer?

Endianness is handled by the callers so this function must leave
the binary blob intact.

> If this is a byte string
> rather than individual registers, you should probably just use
> memcpy_toio()

It's a header followed by an opaque command. The protocol for queueing a 
command says that the first 32-bit half of the header must be written 
last, this triggering the command handling in the MC.

> but if these are separate registers, then using the
> __raw_* accessors is still wrong, at least on kernels that have a
> different byteorder from the hardware.

As mentioned above, endianness is handled by the caller. This function
takes raw data and must leave it unchanged.

> Also, are you sure that adding those six extra barriers has no
> performance impact?

This is a slow interface used in slow paths, so i don't think those 
extra barriers will have any performance impact.

---
Thanks & Best Regards, Laurentiu

WARNING: multiple messages have this Message-ID (diff)
From: Laurentiu Tudor <laurentiu.tudor@nxp.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: gregkh <gregkh@linuxfoundation.org>,
	Stuart Yoder <stuyoder@gmail.com>,
	"devel@driverdev.osuosl.org" <devel@driverdev.osuosl.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	Marc Zyngier <marc.zyngier@arm.com>,
	Alexander Graf <agraf@suse.de>,
	Ioana Ciornei <ioana.ciornei@nxp.com>,
	Ruxandra Ioana Radulescu <ruxandra.radulescu@nxp.com>,
	Bharat Bhushan <bharat.bhushan@nxp.com>,
	Catalin Horghidan <catalin.horghidan@nxp.com>,
	Leo Li <leoyang.li@nxp.com>, Roy Pledge <roy.pledge@nxp.com>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 6/7] staging: fsl-mc: rewrite mc command send/receive to work on 32-bits
Date: Mon, 17 Jul 2017 14:27:57 +0000	[thread overview]
Message-ID: <596CC912.3020709@nxp.com> (raw)
In-Reply-To: <CAK8P3a3KDh=MgfjG+sKNqcrQwq1yf-DgQN0=HigPaPYYJq0Uug@mail.gmail.com>

Hi Arnd,

On 07/17/2017 04:45 PM, Arnd Bergmann wrote:
> On Mon, Jul 17, 2017 at 3:26 PM,  <laurentiu.tudor@nxp.com> wrote:
>> From: Laurentiu Tudor <laurentiu.tudor@nxp.com>
>>
>> Split the 64-bit accesses in 32-bit accesses because there's no real
>> constrain in MC to do only atomic 64-bit. There's only one place
>> where ordering is important: when writing the MC command header the
>> first 32-bit part of the header must be written last.
>> We do this switch in order to allow compiling the driver on 32-bit.
>>
>> Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
>> ---
>>   drivers/staging/fsl-mc/bus/mc-sys.c | 31 ++++++++++++-------------------
>>   1 file changed, 12 insertions(+), 19 deletions(-)
>>
>> diff --git a/drivers/staging/fsl-mc/bus/mc-sys.c b/drivers/staging/fsl-mc/bus/mc-sys.c
>> index 195d9f3..dd2828e 100644
>> --- a/drivers/staging/fsl-mc/bus/mc-sys.c
>> +++ b/drivers/staging/fsl-mc/bus/mc-sys.c
>> @@ -124,14 +124,15 @@ static inline void mc_write_command(struct mc_command __iomem *portal,
>>   {
>>          int i;
>>
>> -       /* copy command parameters into the portal */
>> -       for (i = 0; i < MC_CMD_NUM_OF_PARAMS; i++)
>> -               __raw_writeq(cmd->params[i], &portal->params[i]);
>> -       /* ensure command params are committed before submitting it */
>> -       wmb();
>> -
>> -       /* submit the command by writing the header */
>> -       __raw_writeq(cmd->header, &portal->header);
>> +       /*
>> +        * copy command parameters into the portal. Final write
>> +        * triggers the submission of the command.
>> +        */
>> +       for (i = sizeof(struct mc_command) / sizeof(u32) - 1; i >= 0; i--) {
>> +               __raw_writel(((u32 *)cmd)[i], &((u32 *)portal)[i]);
>> +               /* ensure command params are committed before submitting it */
>> +               wmb();
>> +       }
>>   }
>
> What is the byte order requirement on this buffer?

Endianness is handled by the callers so this function must leave
the binary blob intact.

> If this is a byte string
> rather than individual registers, you should probably just use
> memcpy_toio()

It's a header followed by an opaque command. The protocol for queueing a 
command says that the first 32-bit half of the header must be written 
last, this triggering the command handling in the MC.

> but if these are separate registers, then using the
> __raw_* accessors is still wrong, at least on kernels that have a
> different byteorder from the hardware.

As mentioned above, endianness is handled by the caller. This function
takes raw data and must leave it unchanged.

> Also, are you sure that adding those six extra barriers has no
> performance impact?

This is a slow interface used in slow paths, so i don't think those 
extra barriers will have any performance impact.

---
Thanks & Best Regards, Laurentiu

  reply	other threads:[~2017-07-17 14:27 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-17 13:26 [PATCH 0/7] staging: fsl-mc: make the driver compile on other architectures laurentiu.tudor at nxp.com
2017-07-17 13:26 ` laurentiu.tudor
2017-07-17 13:26 ` [PATCH 1/7] staging: fsl-mc: add missing fsl_mc comment in struct msi_desc laurentiu.tudor at nxp.com
2017-07-17 13:26   ` laurentiu.tudor
2017-07-17 13:26 ` [PATCH 2/7] staging: fsl-mc: use generic memory barriers laurentiu.tudor at nxp.com
2017-07-17 13:26   ` laurentiu.tudor
2017-07-17 13:38   ` Robin Murphy
2017-07-17 13:38     ` Robin Murphy
2017-07-17 13:46     ` Laurentiu Tudor
2017-07-17 13:46       ` Laurentiu Tudor
2017-07-17 13:26 ` [PATCH 3/7] staging: fsl-mc: drop useless gic v3 related #include laurentiu.tudor at nxp.com
2017-07-17 13:26   ` laurentiu.tudor
2017-07-17 13:26 ` [PATCH 4/7] staging: fsl-mc: fix compilation with non-generic msi domain ops laurentiu.tudor at nxp.com
2017-07-17 13:26   ` laurentiu.tudor
2017-07-17 13:26 ` [PATCH 5/7] staging: fsl-mc: fix formating of phys_addr_t on 32 bits laurentiu.tudor at nxp.com
2017-07-17 13:26   ` laurentiu.tudor
2017-07-17 13:26 ` [PATCH 6/7] staging: fsl-mc: rewrite mc command send/receive to work on 32-bits laurentiu.tudor at nxp.com
2017-07-17 13:26   ` laurentiu.tudor
2017-07-17 13:43   ` Robin Murphy
2017-07-17 13:43     ` Robin Murphy
2017-07-17 14:53     ` Laurentiu Tudor
2017-07-17 14:53       ` Laurentiu Tudor
2017-07-17 13:45   ` Arnd Bergmann
2017-07-17 13:45     ` Arnd Bergmann
2017-07-17 14:27     ` Laurentiu Tudor [this message]
2017-07-17 14:27       ` Laurentiu Tudor
2017-07-17 15:00       ` Arnd Bergmann
2017-07-17 15:00         ` Arnd Bergmann
2017-07-18 11:08         ` Laurentiu Tudor
2017-07-18 11:08           ` Laurentiu Tudor
2017-07-18 11:39           ` Arnd Bergmann
2017-07-18 11:39             ` Arnd Bergmann
2017-07-17 13:26 ` [PATCH 7/7] staging: fsl-mc: allow the driver compile multi-arch laurentiu.tudor at nxp.com
2017-07-17 13:26   ` laurentiu.tudor
2017-07-19 16:09   ` kbuild test robot
2017-07-19 16:09     ` kbuild test robot
2017-07-19 17:31   ` kbuild test robot
2017-07-19 17:31     ` kbuild test robot
2017-07-20 13:47     ` Laurentiu Tudor
2017-07-20 13:47       ` Laurentiu Tudor

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=596CC912.3020709@nxp.com \
    --to=laurentiu.tudor@nxp.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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.