All of lore.kernel.org
 help / color / mirror / Atom feed
From: u.kleine-koenig@pengutronix.de (Uwe Kleine-König)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/1] arm: imx: share imx5x_register_gpios for mach-mx5
Date: Thu, 25 Nov 2010 09:14:06 +0100	[thread overview]
Message-ID: <20101125081406.GG4693@pengutronix.de> (raw)
In-Reply-To: <AANLkTikZkXRmddSYN0-7eSBKO_BpXbz+xuJRhDfKeU02@mail.gmail.com>

On Thu, Nov 25, 2010 at 04:01:04PM +0800, Richard Zhao wrote:
> 2010/11/25 Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>:
> > Hey Richard,
> >
> > On Thu, Nov 25, 2010 at 02:44:48PM +0800, Richard Zhao wrote:
> >> > IMO the machine files shouldn't need to know how many gpio banks are
> >> > available. ?This is a per-SoC thing and so should be set in a SoC function.
> >> But we don't have SoC level device file.
> > Check how I did it for imx{1,21,27,25} in arch/arm/plat-mxc/gpio.c.
> I considered put it there too. but we can not add new defconfig, and
> even can not create new items in Kconfig. So we can not use ifdefs.
Why not add new Kconfig symbols?  Up to now I was unfettered by scruples
adding new ones.

> And per my understanding, mx5x is going to use one zImage, correct?
It should be possible to have a single image for more than one SoC, yes.

> >> > How do you want to continue this change? ?mx51 and mx53 have the same
> >> > number of ports? ?Does mx50 have more or less? ?The addresses are the
> >> > same?
> >> mx53 and mx50 have similar memory map. but mx51 is different. ?Sorry,
> >> I forgot upstream version IO_ADDR can not handler differnt SoC base
> >> addr offset.
> > It might even work in this case, still I prefer a more explicit way.
> >
> >> ? ? ? ? ? ? ?It can not be shared with mx51, but it can be shared with
> >> mx50/53, correct? May plan is mx53/50 share
> >> arch/arm/plat-mxc/include/mach/mx5x.h file.
> > mx5x.h is for mx50 and mx53 but not mx51? ?No please.
> For memory map, mx51 is a special case. From mx53 on , IC tuned memory
> map to support large memory.
> If we use things like mx53-50.h, symbols is hard to define.
> MX53_50_XXX_XXX is wired. Any possibly, we need to add new SoC with
> similar memory map in the future.
I still think defining symbols for a single SoC is fine most of the
time.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

  reply	other threads:[~2010-11-25  8:14 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-25 14:28 [PATCH 1/1] arm: imx: share imx5x_register_gpios for mach-mx5 Richard Zhao
2010-11-25  6:29 ` Uwe Kleine-König
2010-11-25  6:44   ` Richard Zhao
2010-11-25  7:42     ` Uwe Kleine-König
2010-11-25  8:01       ` Richard Zhao
2010-11-25  8:14         ` Uwe Kleine-König [this message]
2010-11-25  8:43           ` Sascha Hauer
2010-11-25 11:10             ` Richard Zhao
2010-11-25 12:17               ` Uwe Kleine-König
2010-11-25 14:40                 ` Richard Zhao

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=20101125081406.GG4693@pengutronix.de \
    --to=u.kleine-koenig@pengutronix.de \
    --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.