All of lore.kernel.org
 help / color / mirror / Atom feed
From: marek.vasut@gmail.com (Marek Vasut)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] PXA: Colibri320: Add M41T00 RTC support
Date: Sat, 31 Jul 2010 12:34:50 +0200	[thread overview]
Message-ID: <201007311234.50775.marek.vasut@gmail.com> (raw)
In-Reply-To: <20100731090554.GX17833@buzzloop.caiaq.de>

Dne So 31. ?ervence 2010 11:05:54 Daniel Mack napsal(a):
> On Sat, Jul 31, 2010 at 09:33:05AM +0200, Marek Vasut wrote:
> > Dne So 31. ?ervence 2010 09:26:03 pieterg napsal(a):
> > > On Saturday 31 July 2010 04:30:53 Marek Vasut wrote:
> > > > +#if defined(CONFIG_RTC_DRV_DS1307) ||
> > > > defined(CONFIG_RTC_DRV_DS1307_MODULE)
> > > > +static mfp_cfg_t colibri_pxa320_i2c_pin_config[] __initdata = {
> > > > +	GPIO32_I2C_SCL,
> > > > +	GPIO33_I2C_SDA,
> > > > +};
> > > 
> > > Should the i2c pins really depend on the DS1307 config?
> > > On my board, I use a different rtc. So I do need the I2C pins to be
> > > configured, but I don't need the DS1307.
> 
> Yes, I think you're right. The I2C pins should only be set up if I2C
> support for PXA is in fact enabled. If someone manages to build a kernel
> which has support for this driver (which should depend on the I2C core
> as its transport layer) but not for PXA I2C, that's an unfortunate
> exception.
> 
> You could think about something like
> 
>   select I2C_PXA if RTC_DRV_DS1307
> 
> in the Colibri block of mach-pxa/Kconfig, but that's somewhat overdone
> maybe.

You're right, probably. I'll see what I can do about it (maybe I'll just queue 
this patch after the rework).

> 
> > Well I'd like to rework the colibri pxa3xx stuff later, but I'll have to
> > discuss it with Dan. I believe reworking it the same way as pxa270
> > colibri would be nice (and it'd solve your problem too as you use custom
> > board I think?).
> 
> Yes, that'd be nice.

It's a mess, true indeed. But now I need to get some sleep :-)
> 
> > Actually, there is one thing that puzzles me. Eric/Dan, shall I stick all
> > the MFP configs into one (or two, one for board and once for cpu card)
> > array or keep it split in multiple smaller arrays for each device? I
> > think putting it all in one place would be more readable.
> 
> Hmm, GPIOs for peripherals that are assembled on the module itself can
> safely be configured unconditionally as it is impossible to use them for
> anything else. For GPIOs that are allocted by a specific base board,
> things are different though, especially for the the Colibri eval board
> with it hundreds of jumpers on it. It's a convenience feature to have
> them free for general purpose use just by disabling a certain config
> directive.

Ok, I'd agree on this ;-)
> 
> Daniel

  parent reply	other threads:[~2010-07-31 10:34 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-31  2:30 [PATCH] PXA: Colibri320: Add M41T00 RTC support Marek Vasut
2010-07-31  7:26 ` pieterg
2010-07-31  7:33   ` Marek Vasut
2010-07-31  9:05     ` Daniel Mack
2010-07-31  9:22       ` Russell King - ARM Linux
2010-08-04  6:25         ` Eric Miao
2010-07-31 10:34       ` Marek Vasut [this message]
2010-07-31  9:16     ` Russell King - ARM Linux

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=201007311234.50775.marek.vasut@gmail.com \
    --to=marek.vasut@gmail.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.