linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: dinguyen@altera.com (Dinh Nguyen)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCHv1 1/2] ARM: socfpga: initial support for Altera's SOCFPGA platform.
Date: Fri, 29 Jun 2012 14:54:47 -0500	[thread overview]
Message-ID: <1340999687.8634.9.camel@dinguyen-VirtualBox> (raw)
In-Reply-To: <20120627204018.0bfef362@skate>

On Wed, 2012-06-27 at 20:40 +0200, Thomas Petazzoni wrote:
> Le Wed, 27 Jun 2012 20:05:16 +0200,
> Pavel Machek <pavel@denx.de> a ?crit :
> 
> > > Is SOCFPGA a good name? It seems like a very generic name. Shouldn't it
> > > be ARCH_ALTERA_SOCFPGA a better name? I suspect other vendors will
> > > provide a SoC together with a FPGA.
> > 
> > I guess for config option name, ALTERA_SOCFPGA is okay, but for
> > directory name it would be a little bit long. Would that work?
> 
> Hum, yes, maybe. Maybe just MACH_ALTERA, and mach-altera then?
> Hopefully others will have better ideas.

First off, thanks for the thoughtful review, its very much appreciated.

Unless its a really strong objection, I'd like to stick with
mach-socfpga. This is a name that Altera has started to market this hw
around and I would like to stick with it.

> 
> > > And even more: for a given SoC
> > > variant, we now generally only want one config options, the board-level
> > > details being abstracted out by the device tree.
> > 
> > Will look into that later.
> 
> Ok. If you look at other platforms, they now typically have only one
> DT_MACHINE_START, and one configuration option associated to it, for
> each SoC variant. The different boards are only described using DT.
> 
> > Ok.
> > 
> > arch/arm/mach-socfpga/socfpga_cyclone5.c:119: error:
> > 'IRQ_SOCFPGA_L4_OSC1_TIMER0' undeclared (first use in this function)
> > 
> > Looks like we'll meed a bit more of dt :-).
> 
> Yes, you need more DT. You need a DT node for the timer, which will
> contain all the details like base I/O address and IRQ.
> 
> > > > +#define NR_IRQS			512
> > > 
> > > You should be looking at using SPARSE_IRQ to avoid having a maximum
> > > number of irqs. See for example mach-highbank/.
> > 
> > Is maximum number of interrupts a problem? 512 does not seem
> > excessive.
> 
> Regardless of the value of NR_IRQS, there is apparently a trend to use
> SPARSE_IRQ anyway. However, I am not at the best place to explain why
> SPARSE_IRQ is now considered the right thing to use.
> 
> Best regards,
> 
> Thomas

BR,
Dinh

  reply	other threads:[~2012-06-29 19:54 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-27 13:50 [RFC]Add initial support for Altera's SOCFPGA hardward dinguyen at altera.com
2012-06-27 13:50 ` [RFC PATCHv1 1/2] ARM: socfpga: initial support for Altera's SOCFPGA platform dinguyen at altera.com
2012-06-27 14:20   ` Thomas Petazzoni
2012-06-27 18:05     ` Pavel Machek
2012-06-27 18:40       ` Thomas Petazzoni
2012-06-29 19:54         ` Dinh Nguyen [this message]
2012-06-29 22:18           ` Thomas Petazzoni
2012-07-04 16:11             ` Thomas Petazzoni
2012-06-30 21:04         ` Arnd Bergmann
2012-07-01 18:41           ` Pavel Machek
2012-07-02 16:52             ` Arnd Bergmann
2012-07-02 21:53               ` Pavel Machek
2012-10-17 18:16             ` [PATCH] Fix socfpga compilation with early_printk() enabled Pavel Machek
2012-10-25 14:58               ` Arnd Bergmann
2012-10-27 11:56                 ` Pavel Machek
2012-10-27 15:39                   ` Arnd Bergmann
2012-10-28 23:01                     ` arm-soc tree was " Pavel Machek
2012-10-28 23:13                       ` Pavel Machek
2012-10-29  4:41                         ` Arnd Bergmann
2012-10-30 16:03                           ` Pawel Moll
2012-10-29  4:45                       ` Arnd Bergmann
2012-10-29  0:27                     ` [PATCH for soc] socfpga: map uart into virtual address space so that early_printk() works Pavel Machek
2012-11-03 11:26                       ` Pavel Machek
2012-11-05 17:18                         ` Olof Johansson
2012-06-27 20:27     ` [RFC PATCHv1 1/2] ARM: socfpga: initial support for Altera's SOCFPGA platform Pavel Machek
2012-06-30 18:57     ` Pavel Machek
2012-07-01 18:10       ` Pavel Machek
2012-07-04 10:56     ` Pavel Machek
2012-07-04 11:10       ` Thomas Petazzoni
2012-07-04 11:23         ` Pavel Machek
2012-07-04 14:30           ` Dinh Nguyen
2012-07-09 10:58             ` Pavel Machek
2012-07-04 11:15     ` Pavel Machek
2012-07-04 11:21       ` Thomas Petazzoni
2012-07-04 17:56   ` Rob Herring
2012-07-09 11:30     ` Pavel Machek
2012-07-09 13:25       ` Rob Herring
2012-07-10  9:48         ` Pavel Machek
2012-07-09 11:52     ` Pavel Machek
2012-07-09 12:06     ` Pavel Machek
2012-07-09 12:10     ` Pavel Machek
2012-06-27 13:50 ` [RFC PATCHv1 2/2] ARM: socfpga: Add board support for Altera's SOCFPGA Cyclone 5 HW dinguyen at altera.com
2012-06-27 14:25   ` Thomas Petazzoni
2012-06-27 21:06     ` Pavel Machek
2012-06-27 22:19       ` Thomas Petazzoni
2012-06-28  0:00     ` Pavel Machek
2012-07-10 11:15     ` Pavel Machek

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=1340999687.8634.9.camel@dinguyen-VirtualBox \
    --to=dinguyen@altera.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).