All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lukasz Majewski <l.majewski@samsung.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [RFC PATCH] ARM: asm: types: Introduce DMA_ADDR_T_64BIT
Date: Thu, 24 Mar 2016 09:41:42 +0100	[thread overview]
Message-ID: <20160324094142.27282f4b@amdc2363> (raw)
In-Reply-To: <1458797172-7031-1-git-send-email-lokeshvutla@ti.com>

Hi Lokesh,

> dma_addr_t holds any valid DMA address. If the DMA API only uses
> 32-bit addresses, dma_addr_t need only be 32 bits wide.  Bus
> addresses, e.g., PCI BARs, may be wider than 32 bits, but drivers do
> memory-mapped I/O to ioremapped kernel virtual addresses, so they
> don't care about the size of the actual bus addresses.
> Also 32 bit ARM systems with LPAE enabled can use 64bit address
> space, but DMA still use 32bit address like in case of DRA7 and
> Keystone platforms.

I've already stumbled upon this issue...

> 
> This is inspired from the Linux kernel types implementation[1]
> 
> [1]
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/linux/types.h#n142
> 
> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
> ---
>  arch/arm/include/asm/types.h | 17 +++++++++++++++--
>  1 file changed, 15 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/include/asm/types.h
> b/arch/arm/include/asm/types.h index 388058e..d108915 100644
> --- a/arch/arm/include/asm/types.h
> +++ b/arch/arm/include/asm/types.h
> @@ -46,16 +46,29 @@ typedef unsigned long long u64;
>  #endif	/* CONFIG_ARM64 */
>  
>  #ifdef CONFIG_PHYS_64BIT
> -typedef unsigned long long dma_addr_t;
>  typedef unsigned long long phys_addr_t;
>  typedef unsigned long long phys_size_t;
>  #else
>  /* DMA addresses are 32-bits wide */
> -typedef u32 dma_addr_t;
>  typedef unsigned long phys_addr_t;
>  typedef unsigned long phys_size_t;
>  #endif
>  
> +/*
> + * A dma_addr_t can hold any valid DMA address, i.e., any address
> returned
> + * by the DMA API.
> + *
> + * If the DMA API only uses 32-bit addresses, dma_addr_t need only
> be 32
> + * bits wide.  Bus addresses, e.g., PCI BARs, may be wider than 32
> bits,
> + * but drivers do memory-mapped I/O to ioremapped kernel virtual
> addresses,
> + * so they don't care about the size of the actual bus addresses.
> + */
> +#ifdef CONFIG_DMA_ADDR_T_64BIT

Generally this approach is correct, but please pay attention to the
CONFIG_PHYS_64BIT.

The actual size of dma_addr_t (64 or 32 bits) is decided by defining or
undefining CONFIG_PHYS_64BIT at arch/arm/include/asm/config.h. This is
based on the status of CONFIG_ARM64.

To avoid regression we need to take into account status of CONFIG_ARM64
to be sure that CONFIG_DMA_ADDR_T_64BIT is set on ARM64 systems.

> +typedef unsigned long long dma_addr_t;
> +#else
> +typedef u32 dma_addr_t;
> +#endif
> +
>  #endif /* __KERNEL__ */
>  
>  typedef unsigned long resource_size_t;



-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group

  reply	other threads:[~2016-03-24  8:41 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-24  5:26 [U-Boot] [RFC PATCH] ARM: asm: types: Introduce DMA_ADDR_T_64BIT Lokesh Vutla
2016-03-24  8:41 ` Lukasz Majewski [this message]
2016-03-24  9:03   ` Lokesh Vutla
2016-03-24 10:33     ` Lukasz Majewski

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=20160324094142.27282f4b@amdc2363 \
    --to=l.majewski@samsung.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 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.