public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Scott Wood <scottwood@freescale.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 2/3] Data types defined for 64 bit physical address
Date: Fri, 31 Jul 2015 13:56:00 -0500	[thread overview]
Message-ID: <1438368960.19345.25.camel@freescale.com> (raw)
In-Reply-To: <DM2PR0301MB1312132478D58C5D981FF805F08A0@DM2PR0301MB1312.namprd03.prod.outlook.com>

On Fri, 2015-07-31 at 13:32 -0500, Bansal Aneesh-B39320 wrote:
> > > > > diff --git a/arch/powerpc/include/asm/io.h
> > > > > b/arch/powerpc/include/asm/io.h index a5257e9..8c6f47e 100644
> > > > > --- a/arch/powerpc/include/asm/io.h
> > > > > +++ b/arch/powerpc/include/asm/io.h
> > > > > @@ -246,6 +246,19 @@ extern inline void out_be32(volatile unsigned
> > > > > __iomem *addr, u32 val)
> > > > >       __asm__ __volatile__("sync; stw%U0%X0 %1,%0" : "=m" (*addr) :
> > > > > "r" (val));  }
> > > > > 
> > > > > +extern inline u64 in_be64(const u64 *addr) {
> > > > > +     return ((u64)in_be32((u32 *)addr) << 32) |
> > > > > +     (in_be32((u32 *)addr + 1));
> > > > > +}
> > > > > +
> > > > > +extern inline void out_be64(u64 *addr, u64 val) {
> > > > > +     out_be32((u32 *)addr, (u32)(val >> 32));
> > > > > +     out_be32((u32 *)addr + 1, (u32)val); }
> > > > 
> > > > What do you need these for?  I don't think it's a good idea to have
> > > > I/O accessors that look atomic but aren't (same goes for arm32).
> > > > 
> > > 64 bit read and writes are required for CAAM operations. That is why I
> > > have added these in powerpc and arm.
> > 
> > No, it's not required.  You could just as well perform multiple 
> > out_be32() in the driver.
> > 
> > -Scott
> > 
> It is required to define I/O accessor for 64 bit access.

It is only required if you need to do actual 64-bit I/O, which you can't do 
in a 32-bit U-Boot (and all PPC U-Boot is 32-bit).

> It is already defined in arm.

I think that should be limited to arm64.

> The driver will just call OUT_64 or IN_64.
> Now that might be a be64 or le64 depending upon the endianness of IP block 
> on that SoC.
> Further the definition of be64 and le64 will be different for ARM and 
> PowerPC.
> 
> We have a common CAAM driver which can't just have multiple out_be32() 
> instead of OUT_64.
> All PowerPC SOC's : Core is BE and CAAM is BE
> LS1020        : Core is LE and CAAM is LE

You already had addr_lo and addr_hi, with an CONFIG_SYS_FSL_SEC_LE ifdef.  
Why was that not sufficient?

> The problem is with LS1043, where core in LE and CAAM is BE.

The core's endianness is irrelevant.

> So in order, to have a unified CAAM driver we need accessors for 64 bit.
> 
> For ARM, these functions are directly defined in C as:
> out_16                (*(volatile unsigned short *)(a) = (v))
> out_32                (*(volatile unsigned int *)(a) = (v))
> out_64                (*(volatile unsigned long long *)(a) = (v))
> There is another macro defined which takes care of byte-swapping the value 
> for BE or LE
> 
> But in PowerPC, for 16 and 32 bit these are defined in ASM.
> I could not find asm instructions for 64 bit read/write. So, I defined 
> these in C.

You couldn't find them because they don't exist (except for floating point 
and such, but there's no reason to use that here), and thus the accessor 
shouldn't exist.

BTW, why are the patches of this series posted in separate threads?  Are you 
invoking git send-email separately for each patch?

-Scott

      reply	other threads:[~2015-07-31 18:56 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-31  9:53 [U-Boot] [PATCH 2/3] Data types defined for 64 bit physical address Aneesh Bansal
2015-07-31 17:20 ` Scott Wood
2015-07-31 17:28   ` Bansal Aneesh
2015-07-31 17:37     ` Scott Wood
2015-07-31 18:32       ` Bansal Aneesh
2015-07-31 18:56         ` Scott Wood [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=1438368960.19345.25.camel@freescale.com \
    --to=scottwood@freescale.com \
    --cc=u-boot@lists.denx.de \
    /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