From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [GIT PULL] Renesas ARM Based SoC Soc Updates for v3.19
Date: Thu, 27 Nov 2014 20:48:12 +0000 [thread overview]
Message-ID: <2367916.IecTPygCF4@avalon> (raw)
In-Reply-To: <201411192205.57149.arnd@arndb.de>
Hi Arnd,
On Wednesday 19 November 2014 22:05:56 Arnd Bergmann wrote:
> On Tuesday 04 November 2014, Simon Horman wrote:
> > ----------------------------------------------------------------
> > Renesas ARM Based SoC Soc Updates for v3.19
> >
> > * Select CONFIG_ZONE_DMA when CONFIG_ARM_LPAE is enabled
> > * Add CA7 arch_timer initialization for r8a7794
> > * Handle CA7 arch timer delay
> > * Add shmobile_init_late() to sh7372
> >
> > - This is consistent with other shmobile SoCs
>
> Pulled into next/soc.
>
> Note that the CONFIG_ZONE_DMA change might not be the best solution, we
> should probably have CONFIG_ZONE_DMA32 instead as some other architectures
> do, so you can use the entire lowmem area for DMA allocations.
I might be mistaken, but if the machine description doesn't set the
dma_zone_size field, arm_dma_zone_size and arm_dma_limit are set to 0 and
0xffffffff respectively. This results in MAX_DMA_ADDRESS being set to
0xffffffff. Doesn't that allow using the entire lowmem area for DMA
allocations ?
--
Regards,
Laurent Pinchart
WARNING: multiple messages have this Message-ID (diff)
From: laurent.pinchart@ideasonboard.com (Laurent Pinchart)
To: linux-arm-kernel@lists.infradead.org
Subject: [GIT PULL] Renesas ARM Based SoC Soc Updates for v3.19
Date: Thu, 27 Nov 2014 22:48:12 +0200 [thread overview]
Message-ID: <2367916.IecTPygCF4@avalon> (raw)
In-Reply-To: <201411192205.57149.arnd@arndb.de>
Hi Arnd,
On Wednesday 19 November 2014 22:05:56 Arnd Bergmann wrote:
> On Tuesday 04 November 2014, Simon Horman wrote:
> > ----------------------------------------------------------------
> > Renesas ARM Based SoC Soc Updates for v3.19
> >
> > * Select CONFIG_ZONE_DMA when CONFIG_ARM_LPAE is enabled
> > * Add CA7 arch_timer initialization for r8a7794
> > * Handle CA7 arch timer delay
> > * Add shmobile_init_late() to sh7372
> >
> > - This is consistent with other shmobile SoCs
>
> Pulled into next/soc.
>
> Note that the CONFIG_ZONE_DMA change might not be the best solution, we
> should probably have CONFIG_ZONE_DMA32 instead as some other architectures
> do, so you can use the entire lowmem area for DMA allocations.
I might be mistaken, but if the machine description doesn't set the
dma_zone_size field, arm_dma_zone_size and arm_dma_limit are set to 0 and
0xffffffff respectively. This results in MAX_DMA_ADDRESS being set to
0xffffffff. Doesn't that allow using the entire lowmem area for DMA
allocations ?
--
Regards,
Laurent Pinchart
next prev parent reply other threads:[~2014-11-27 20:48 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-04 1:50 [GIT PULL] Renesas ARM Based SoC Soc Updates for v3.19 Simon Horman
2014-11-04 1:50 ` Simon Horman
2014-11-04 1:50 ` [PATCH 1/4] ARM: shmobile: Handle CA7 arch timer delay Simon Horman
2014-11-04 1:50 ` Simon Horman
2014-11-04 1:50 ` [PATCH 2/4] ARM: shmobile: sh7372: Add shmobile_init_late() Simon Horman
2014-11-04 1:50 ` Simon Horman
2014-11-04 1:50 ` [PATCH 3/4] ARM: shmobile: rcar-gen2: Add CA7 arch_timer initialization for r8a7794 Simon Horman
2014-11-04 1:50 ` Simon Horman
2014-11-11 18:27 ` Arnd Bergmann
2014-11-11 18:27 ` Arnd Bergmann
2014-11-11 19:00 ` Geert Uytterhoeven
2014-11-11 19:00 ` Geert Uytterhoeven
2014-11-11 23:59 ` Simon Horman
2014-11-11 23:59 ` Simon Horman
2014-11-12 8:53 ` Arnd Bergmann
2014-11-12 8:53 ` Arnd Bergmann
2014-11-12 9:14 ` Simon Horman
2014-11-12 9:14 ` Simon Horman
2014-11-04 1:50 ` [PATCH 4/4] ARM: shmobile: Select CONFIG_ZONE_DMA when CONFIG_ARM_LPAE is enabled Simon Horman
2014-11-04 1:50 ` Simon Horman
2014-11-19 21:05 ` [GIT PULL] Renesas ARM Based SoC Soc Updates for v3.19 Arnd Bergmann
2014-11-19 21:05 ` Arnd Bergmann
2014-11-27 20:48 ` Laurent Pinchart [this message]
2014-11-27 20:48 ` Laurent Pinchart
2014-12-04 12:52 ` Arnd Bergmann
2014-12-04 12:52 ` Arnd Bergmann
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=2367916.IecTPygCF4@avalon \
--to=laurent.pinchart@ideasonboard.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.