public inbox for linux-omap@vger.kernel.org
 help / color / mirror / Atom feed
From: Igor Stoppa <igor.stoppa@nokia.com>
To: "ext Gadiyar, Anand" <gadiyar@ti.com>
Cc: ext Felipe Balbi <me@felipebalbi.com>,
	Jouni Hogander <jouni.hogander@nokia.com>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>
Subject: RE: [PATCH 1/7] 34XX: PM: Workaround to build omap hsmmc as a	module
Date: Wed, 25 Jun 2008 16:23:47 +0300	[thread overview]
Message-ID: <1214400227.24418.66.camel@mort> (raw)
In-Reply-To: <5A47E75E594F054BAF48C5E4FC4B92AB022BED2575@dbde02.ent.ti.com>

Hi,

On Wed, 2008-06-25 at 18:10 +0530, ext Gadiyar, Anand wrote:

> My main bone of contention was the statement that there was no reason for
> not building something as a module. There is a case for building drivers
> into the kernel. Whether it is the best choice is something that depends
> on what one is trying to achieve.

As Felipe wrote, it is easy to reconfigure a module to be build in than
it is to get a build in and have it to be compilable and usable as
module. Developing a module gives you for free the builtin case.
The other way is not always true.

Your case of "let's veryfy all the modules at once by converting them to
built-ins" is more the exception than the rule.

> > And on top of that, having modules allows to makes it simpler to address
> > in one go different boards and subarchitectures.
> 
> I'm afraid I don't understand. How would having a driver as a module or
> built-in make a difference when targetting different boards?

I can do just one build and use the same binary to do the deployment to
different boards.

That's the direction the kernel is currently going to, with code that
probes for OMAP version and uses the appropriate register addresses.

The bootloader can pass the board type as option.

-- 

Cheers, Igor

---

Igor Stoppa
Maemo Software - Nokia Devices R&D - Helsinki

  reply	other threads:[~2008-06-25 13:34 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-25  9:11 [PATCH 0/7] 34XX: PM: Workarounds to get omap3 to retention 3rd Jouni Hogander
2008-06-25  9:13 ` [PATCH 1/7] 34XX: PM: Workaround to build omap hsmmc as a module Jouni Hogander
2008-06-25  9:50   ` Felipe Balbi
2008-06-25 11:17     ` Gadiyar, Anand
2008-06-25 12:03       ` Felipe Balbi
2008-06-25 12:11         ` Igor Stoppa
2008-06-25 12:40           ` Gadiyar, Anand
2008-06-25 13:23             ` Igor Stoppa [this message]
2008-06-26  4:25               ` Gadiyar, Anand
2008-06-26  7:28                 ` Felipe Balbi
2008-06-26  8:31                   ` Gadiyar, Anand
2008-06-26 13:20                     ` Tony Lindgren
2008-06-25  9:13 ` [PATCH 2/7] 34XX: PM: Workaround to enable autoidle for clocks and plls Jouni Hogander
2008-06-26  2:30   ` Paul Walmsley
2008-06-27  8:59   ` Rajendra Nayak
2008-06-27  9:08     ` Högander Jouni
2008-06-25  9:13 ` [PATCH 3/7] 34XX: PM: Workaround to reset all wkdeps Jouni Hogander
2008-06-25  9:13 ` [PATCH 4/7] 34XX: PM: Workaround to check wether any fck is active before entering sleep Jouni Hogander
2008-06-25  9:13 ` [PATCH 5/7] OMAP: PM: Add new sysfs option for disabling clocks when entering idle Jouni Hogander
2008-06-25  9:13 ` [PATCH 6/7] 34XX: PM: Workaround for taking care of gpio clocks Jouni Hogander
2008-06-26 11:54   ` Rajendra Nayak
2008-06-26 12:16     ` Högander Jouni
2008-06-26 12:30       ` Rajendra Nayak
2008-06-26 12:40         ` Högander Jouni
2008-06-25  9:13 ` [PATCH 7/7] Added sleep support to UART Jouni Hogander
2008-06-25 11:38 ` [PATCH 0/7] 34XX: PM: Workarounds to get omap3 to retention 3rd Rajendra Nayak
2008-06-25 11:43   ` Högander Jouni

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=1214400227.24418.66.camel@mort \
    --to=igor.stoppa@nokia.com \
    --cc=gadiyar@ti.com \
    --cc=jouni.hogander@nokia.com \
    --cc=linux-omap@vger.kernel.org \
    --cc=me@felipebalbi.com \
    /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