linux-arm-kernel.lists.infradead.org archive mirror
 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

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

Thread overview: 20+ 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 ` [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 ` [PATCH 2/7] staging: fsl-mc: use generic memory barriers laurentiu.tudor at nxp.com
2017-07-17 13:38   ` Robin Murphy
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 ` [PATCH 4/7] staging: fsl-mc: fix compilation with non-generic msi domain ops laurentiu.tudor at nxp.com
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 ` [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:43   ` Robin Murphy
2017-07-17 14:53     ` Laurentiu Tudor
2017-07-17 13:45   ` Arnd Bergmann
2017-07-17 14:27     ` Laurentiu Tudor [this message]
2017-07-17 15:00       ` Arnd Bergmann
2017-07-18 11:08         ` Laurentiu Tudor
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-19 16:09   ` kbuild test robot
2017-07-19 17:31   ` kbuild test robot
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 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).