From: Simon Horman <horms@verge.net.au>
To: linux-sh@vger.kernel.org
Subject: Re: [PATCH 01/02] ARM: shmobile: Add shared R-Car Gen2 CMA reservation code
Date: Tue, 10 Jun 2014 23:40:17 +0000 [thread overview]
Message-ID: <20140610234012.GA20738@verge.net.au> (raw)
In-Reply-To: <20140306032824.10814.21953.sendpatchset@w520>
On Tue, Jun 10, 2014 at 07:51:38PM +0900, Magnus Damm wrote:
> Hi Geert,
>
> Thanks for your feedback!
>
> On Tue, Jun 10, 2014 at 4:19 PM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
> > Hi Magnus,
> >
> > On Mon, Jun 9, 2014 at 2:38 PM, Magnus Damm <magnus.damm@gmail.com> wrote:
> >> --- 0001/arch/arm/mach-shmobile/setup-rcar-gen2.c
> >> +++ work/arch/arm/mach-shmobile/setup-rcar-gen2.c 2014-06-09 21:01:33.000000000 +0900
> >
> >> +static int __init rcar_gen2_scan_mem(unsigned long node, const char *uname,
> >> + int depth, void *data)
> >> +{
> >
> >> + u64 lpae_start = (u64)1 << 32;
> >
> > Casts are evil:
> >
> > 1ULL << 32
> >
> > (I hope one day gcc will gain a "-Wcast" option, so we can easily find and
> > inspect all casts, as C-style casts are much more difficult to grep for than
> > C++-style casts).
>
> Oh, right, I totally forgot I added that one. =)
>
> >> + /* We are scanning "memory" nodes only */
> >> + if (type = NULL) {
> >> + /*
> >> + * The longtrail doesn't have a device_type on the
> >> + * /memory node, so look for the node called /memory@0.
> >> + */
> >> + if (depth != 1 || strcmp(uname, "memory@0") != 0)
> >> + return 0;
> >
> > AFAIK Open Firmware in the LongTrail does not support plugging in ARM CPUs
> > in its PPC 603e/604e-compatible CPU socket ;-)
>
> You never know - anything is possible with DT. =)
>
> But yes, I get your point - will clean up.
>
> >> +struct cma *rcar_gen2_dma_contiguous;
> >> +
> >> +void __init rcar_gen2_reserve(void)
> >> +{
> >
> >> +#ifdef CONFIG_DMA_CMA
> >> + if (mrc.size)
> >> + dma_contiguous_reserve_area(mrc.size, mrc.base, 0,
> >> + &rcar_gen2_dma_contiguous);
> >> +#endif
> >
> > I assume one day rcar_gen2_dma_contiguous will become used?
>
> That's the idea, yes!
>
> Since Simon kindly queued this up already I will submit an incremental
> fix to deal with the issues that you pointed out.
Thanks. FWIW I quite dislike casts.
next prev parent reply other threads:[~2014-06-10 23:40 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-06 3:28 [PATCH 00/02] ARM: shmobile: Consolidate early delay setup code Magnus Damm
2014-03-06 3:28 ` Magnus Damm
2014-03-06 3:28 ` [PATCH 01/02] ARM: shmobile: Add shared shmobile_init_delay() Magnus Damm
2014-03-06 3:28 ` Magnus Damm
2014-03-07 0:00 ` Simon Horman
2014-03-07 0:00 ` Simon Horman
2014-03-07 1:48 ` Simon Horman
2014-03-07 1:48 ` Simon Horman
2014-06-09 12:38 ` [PATCH 01/02] ARM: shmobile: Add shared R-Car Gen2 CMA reservation code Magnus Damm
2014-06-10 7:19 ` Geert Uytterhoeven
2014-06-10 10:51 ` Magnus Damm
2014-06-10 23:40 ` Simon Horman [this message]
2014-03-06 3:28 ` [PATCH 02/02] ARM: shmobile: Use shmobile_init_delay() on r8a7791/Koelsch Magnus Damm
2014-03-06 3:28 ` Magnus Damm
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=20140610234012.GA20738@verge.net.au \
--to=horms@verge.net.au \
--cc=linux-sh@vger.kernel.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.